JDK-8001106 : Bytecodes should be shared between similar lambda forms.
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang.invoke
  • Affected Version: 8u40,9
  • Priority: P3
  • Status: Resolved
  • Resolution: Duplicate
  • Submitted: 2012-10-18
  • Updated: 2019-09-13
  • Resolved: 2014-09-19
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 9
9Resolved
Related Reports
Blocks :  
JDK-8001107 - @Stable annotation for constant folding of lazily evaluated variables
Description
Many method handle transforms, such as MethodHandles.filterReturnValue, create a new LambdaForm code block for each transformed method handle.  This leads to excessive loading of tiny methods.

The solution is to generate the bytecodes so that they can be reused.

This can be done partly by using the BoundMethodHandle mechanism more vigorously, for performance-critical cases such as MethodHandle.bindTo.

As a more general backup, bytecodes should be generated to pick constants out of the method handle's LambdaForm itself.  Currently, they inline constants as "ldc" constants.  This is the single greatest reason for bytecodes to be regenerated.  In order for such methods to be optimized, we need a @Stable array mechanism, which is the subject of a different bug report.
Comments
It duplicates JEP-210 (JDK-8046703).
19-09-2014
It seems to me that if this is the case that Nashorn gets OOM during a test262 run post b65, it might be beneficial to bump the priority...
27-11-2012
Cannot optimize factored bytecodes unless we can load constants from the original LambdaForm.
18-10-2012