JDK-8043004 : Reduce variability at JavaAdapter call sites
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: jdk.nashorn
  • Affected Version: 9
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2014-05-13
  • Updated: 2015-01-21
  • Resolved: 2014-05-14
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 8 JDK 9
8u40Fixed 9 b17Fixed
Description
It turns out our invokeExact call sites in code generated by JavaAdapterBytecodeGenerator go megamorphic real fast. The reason for that is that every ScriptFunction method handle that we delegate to is also wrapped in a converter method handle using asType(), making it unique per adapter instance.

The strategy to fix this is to avoid argument conversion when possible, and to make it explicit in bytecode when avoidance is not possible. Instead of asType()ing the function method handle, we retrieve it as-is (the generic version that takes Object arguments and returns Object), and perform boxing of arguments and unboxing of the return value separately.

Conversion to primitive types, void, and String is handled with explicit static method invocations. Conversion to SAM types, Java array types, List type etc. are handled by retrieving and storing a converter method handle through LinkerServices, and invoking it in a separate invokeExact immediately after the delegate method's invokeExact.

For reasons of security, when the return value conversion needs a method handle, we need to retrieve those converter method handles during either adapter class (class-level overrides) or adapter instance creation and store them into fields. This will work exactly as Bootstrap's asType() worked before, and will respect the MethodHandles.Lookup related to the currently processed call site.