Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8046703

JEP 210: LambdaForm Reduction and Caching

    Details

    • Author:
      Christian Thalinger
    • JEP Type:
      Feature
    • Exposure:
      Open
    • Subcomponent:
    • Scope:
      Implementation
    • Discussion:
      hotspot dash compiler dash dev at openjdk dot java dot net
    • Effort:
      M
    • Duration:
      M
    • Alert Status:
       Green
    • JEP Number:
      210

      Description

      Summary

      Reduce LambdaForm creation and use caching to improve the performance of dynamic languages.

      Goals

      Considerably reduce memory footprint while preserving current peak-performance metrics.

      Motivation

      Many method-handle transforms (e.g., MethodHandles::filterReturnValue) create many new LambdaForm instances for each transformed method handle. This induces excessive memory usage in applications that make heavy use of method handles.

      Description

      The current method-handle implementation instantiates LambdaForms too aggressively. The proposed approach is two-fold: Share LambdaForm instances and their bytecodes for similar transformations, and cache lambda forms for different combinators on a per-basic-type basis (see MethodTypeForm.lambdaForms).

      Testing

      Existing tests give good coverage of functionality. Some focused tests (i.e., white-box tests verifying actual sharing in different cases) are also desirable.

      Existing tests:

      • jdk/test/java/{lang/invoke,util/stream}
      • mlvm tests
      • Nashorn unit tests
      • ECMA test262
      • Octane benchmarks

      Testing modes:

      • out-of-box: no flags
      • assertions: -ea -esa
      • interpreted vs. compiled LFs: -Djava.lang.invoke.MethodHandle.COMPILE_THRESHOLD={0,30}.

      Risks and Assumptions

      The implementation shouldn't cause any regression in peak performance. Experiments show, however, that preserving peak performance may prevent maximal sharing in some situations (e.g., MethodHandles.guardWithTest, where profile pollution due to sharing distorts inlining decisions of JIT compiler). We'll need to find a suitable balance between footprint reduction and peak performance during development.

      Impact

      The changes are concentrated in Java portion of the method-handle implementation (i.e., the java.lang.invoke and sun.invoke packages). There is no impact upon those who don't use method handles. No new APIs will be added and no existing APIs will be changed.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                vlivanov Vladimir Ivanov
                Reporter:
                twisti Christian Thalinger
                Owner:
                Vladimir Ivanov
                Reviewed By:
                Brian Goetz, Mikael Vidstedt
                Endorsed By:
                Mikael Vidstedt
              • Votes:
                0 Vote for this issue
                Watchers:
                13 Start watching this issue

                Dates

                • Due:
                  Created:
                  Updated:
                  Resolved:
                  Integration Due: