JDK-8036580 : CHA: Improve default method support
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9,10
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2014-03-04
  • Updated: 2021-06-07
  • Resolved: 2021-06-01
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.
JDK 17
17 b25Fixed
Related Reports
Blocks :  
JDK-8267807 - C2: Downcast receiver to target holder during inlining
Blocks :  
JDK-8267806 - C1: Relax inlining checks for not yet initialized classes
Duplicate :  
JDK-8036153 - Default method returns true for a while, and then returns false
Relates :  
JDK-8065760 - CHA: Improve abstract method support
Relates :  
JDK-8208237 - Re-examine defmeth tests and update as needed
Relates :  
JDK-8036100 - Default method returns true for a while, and then returns false
Description
CHA doesn't handle default methods right (see JDK-8036100). 
Need to improve the analysis to take default methods into account.
Comments
Changeset: 74b70a56 Author: Vladimir Ivanov <vlivanov@openjdk.org> Date: 2021-06-01 12:14:48 +0000 URL: https://git.openjdk.java.net/jdk/commit/74b70a56774e7bf716356cf38395f8e7d7dadc78
01-06-2021
I made a couple of attempts, but haven't got satisfactory results yet. Still, the results are promising and I'm in the middle of another iteration.
12-01-2021
Just checking whether there was planned action on this enhancement?
07-01-2021
[~dnsimon] [~never] I'll try to look into that for 13. The main obstacle so far was poor test coverage, but JDK-6986483 laid a groundwork in that area.
08-02-2019
And to clarify the reason this is important, if you use an interface default method as a alternative to providing abstract base class you don't get CHA on that method. interface InterfaceAbstract { default void interfaceAbstract() { } } abstract class ClassAbstract implements InterfaceAbstract { void classAbstract() { } } class Concrete extends ClassAbstract { } So ClassAbstract.classAbstract can be bound using CHA against Concrete but InterfaceAbstract.interfaceAbstract cannot.
08-02-2019
[~vlivanov] is there a rough timeline as to when CHA support for default methods may be added? This is obviously something we'd be interested in using in Graal.
08-02-2019
Need to be careful to see if there is a need to distinguish between Java-level defaults method (public, non-static, uses virtual invocation) and private interface methods (private, non-static, uses non-virtual invocation). At present a lot of the VM functionality that refers to "default_methods" (some incorrect comments not withstanding) actually covers default and private interface methods.
15-09-2016
This should probably be given higher priority. Default methods just don't participate in CHA at all which seems like some serious missed performance.
14-09-2016
Considering that any class method (both concrete and abstract) hides inherited default methods, there are 2 set of cases to cover: - if root_m is a class method, then all default methods down the hierarchy can be ignored - if root_m is a default method, then: (1) any default method found is a witness of possible non-uniqueness of implementation (2) any concrete method hides root_m, so in case a single method is found, it is a unique implementation
04-03-2014
JDK-8036100 is a bug in CHA for default methods.
04-03-2014