JDK-8251990 : Improve default method handling of private static methods in java.lang.Object
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 16
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • Submitted: 2020-08-18
  • Updated: 2021-06-28
  • Resolved: 2021-06-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdResolved
Related Reports
Relates :  
JDK-8219713 - Reduce work in DefaultMethods::generate_default_methods
Relates :  
JDK-8028438 - Lambda: default methods static superclass method masking default
Description
When a private static method is added to java.lang.Object, it is examined by default method processing.  This can be seen when running with -Xlog:defaultmethods=debug.

It seems like those methods should be immediately excluded as default methods.
Comments
When the default method processing determines that a class or interface requires default method processing and -Xlog:defaultmethods=debug is specified then it prints out the class's hierarchy. Since java.lang.Object is in every class's hierarchy, it gets outputted a lot. Here's the code in generate_default_methods() where the hierarchy gets logged: LogTarget(Debug, defaultmethods) lt; if (lt.is_enabled()) { ResourceMark rm(THREAD); lt.print("%s %s requires default method processing", klass->is_interface() ? "Interface" : "Class", klass->name()->as_klass_external_name()); LogStream ls(lt); PrintHierarchy printer(&ls); printer.run(klass); } Repeated scanning of the methods in java.lang.Object is prevented by use of this method, added as part of https://bugs.openjdk.java.net/browse/JDK-8219713 // Since the starting point can be an interface, we must ensure we catch // j.l.Object as the super once in those cases. The _visited_Object flag // only ensures we don't then repeatedly enqueue Object for each interface // in the class hierarchy. bool has_super(InstanceKlass* cls) { return cls->super() != NULL && (!_visited_Object || !cls->is_interface()); }
28-06-2021
JDK-8219713 flags the issue with private static methods, but then didn't seem to do anything about that part. It could be that the logging makes this look worse than it is.
26-08-2020