JDK-8251839 : [lworld] Scalarize inline type receiver through default method calls
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: repo-valhalla
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2020-08-14
  • Updated: 2022-06-08
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
repo-valhallaUnresolved
Related Reports
Relates :  
Description
From a discussion with [~jrose]:

John Rose:
[...]
The other case which I’m trying to get at is harder, because it requires specialization.  Suppose there is a default method in the interface, whose receiver is of the interface type itself.  That’s the problem I’m trying to push on here:  Calling this method on an inline reciever appears to require buffering, to match up with the calling sequence of the default method.  And there’s no way to guess at which inline types (implementors of that interface) might eventually execute that default method on themselves.  The good case is if (a) the default method call is devirtualized and inlined; then you basically get a custom copy of the default method, just for that inline receiver and for that call site.  The not-so-good case is if inlining fails (maybe the default method is a complex algorithm); that case seems to require that the method fall all the down to full polymorphism.
I’d like to see a story where such a default method (and if we do abstract supers for inlines, then non-abstract methods in abstract supers) gets recompiled for each inline receiver that needs it.  That way it doesn’t need to be inlined in order to operate at full speed.
[...]

Tobias Hartmann:
If the abstract interface method is implemented by an inline receiver method, and if the reciever is already scalarized in the caller, then I suppose the call is devirtualized, and the scalarized receiver in the caller is copied to the entry point of the callee method.  Right?
Correct. The virtual call will always be devirtualized in that case and the receiver will be passed in a scalarized form. If the callee is C2 compiled as well, no handshake is required. Otherwise, buffering in the entry point of the C1 compiled callee or the c2i adapter (for the interpreter) is necessary.
For the default method scenario, which requires specialization of the method, we first need support for multiple compiled methods per Java method (JDK-8038356). We then need to make sure that the devirtualized call points to the specialized method which requires that the specialized method is available before the caller is (re-)compiled.