JDK-8184777 : Factor out species generation logic from BoundMethodHandle
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang.invoke
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2017-07-18
  • Updated: 2018-01-11
  • Resolved: 2017-11-15
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 10
10 b32Fixed
Related Reports
Relates :  
Relates :  
Relates :  
The logic which creates and tracks BMH species is complex and error-prone.
It should be refactored into a smaller "specializer" engine which has no direct coupling to BMH, plus a smaller BMH-specific subclass that embodies the particulars of BMH logic.

The current combined logic is almost impossible to analyze, and will be difficult to enhance in the future.  Future enhancements include support for value types and additional applications of specialization.  One such application is sharable lambda implementations instead of per-site bespoke inner classes.  The current specialization mechanism is too BMH-specific to support such experiments.  Another specialization application is an argument-list API.  Value types will strain the present BMH framework past its breaking point (since each value type is potentially a distinct "LambdaForm.BasicType").  Other specialization tasks may include generating families of vector types (for the Panama Vector API) or for generating families of foreign types such as C pointers (again, Panama).

A prototype refactoring has been completed and seems promising.  For a toy example of non=BMH specialization, see the regression test:


Current patch: http://cr.openjdk.java.net/~redestad/81814777/open.00 Tests are still running, but so far so good. After ensuring the refactoring jives with the jlink --generate-jli-classes plugin and rewriting the ClassSpecializer to not use reflection, overhead is down to a small number of extra classes being loaded during BMH bootstrap. This tiny cost is likely to be paid off in full once we put the ClassSpecializer to use elsewhere.

I'll do some analysis on the prototype and experiments to see if we can improve the interaction with the pregeneration of BMH species classes at link time.

Prototype refactoring: http://cr.openjdk.java.net/~jrose/jdk/8184777/webrev.0