RFR: 8311071: Avoid SoftReferences in LambdaFormEditor and MethodTypeForm when storing heap objects into AOT cache [v3]

Chen Liang liach at openjdk.org
Wed Sep 18 05:22:06 UTC 2024


On Wed, 18 Sep 2024 03:04:50 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is the 6th PR for [JEP 483: Ahead-of-Time Class Loading & Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>> 
>> The implementation of java.lang.invoke uses SoftReferences so that unused MethodHandles, LambdaForms, etc, can be garbage collected.
>> 
>> However, if we want to store java.lang.invoke objects in the AOT cache ([JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336), the final step in JEP 493), it's difficult to cache these SoftReferences -- SoftReferences in turn point to ReferenceQueues, etc, which have dependencies on the current execution state (Threads, etc) which are difficult to cache.
>> 
>> The proposal is to add a new flag: `MethodHandleStatics.NO_SOFT_CACHE`. When this flag is true, we avoid using SoftReferences, and store a direct reference to the target object instead.
>> 
>> [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336) stores only java.lang.invoke objects that refer to classes loaded by the boot/platform/app loaders. These classes are never unloaded, so it's not necessary to point to them using SoftReferences.
>> 
>> This RFE modifies only the LambdaFormEditor and MethodTypeForm classes, as that's the minimal modification required by [JDK-8293336](https://bugs.openjdk.org/browse/JDK-8293336).
>> 
>> ---
>> See [here](https://bugs.openjdk.org/browse/JDK-8315737) for the sequence of dependent RFEs for implementing JEP 483.
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - @dholmes-ora review comments
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Do not use system property to limit usage to only CDS static dumps
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yam/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yak/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - Merge branch 'jep-483-step-05-8293337-archive-method-handle-intrinsics' of /jdk3/yak/open into jep-483-step-06-8311071-avoid-soft-refs-in-java-lang-invoke
>  - 8311071: Add an option to avoid using SoftReferences in java.lang.invoke.MethodHandle

src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java line 148:

> 146:         public LambdaForm get() {
> 147:             if (cache instanceof LambdaForm) {
> 148:                 return (LambdaForm)cache;

Suggestion:

            if (cache instanceof LambdaForm lf) {
                return lf;

src/java.base/share/classes/java/lang/invoke/MethodTypeForm.java line 119:

> 117:             return null;
> 118:         } else if (entry instanceof MethodHandle) {
> 119:             return (MethodHandle) entry;

Suggestion:

        } else if (entry instanceof MethodHandle mh) {
            return mh;

src/java.base/share/classes/java/lang/invoke/MethodTypeForm.java line 145:

> 143:             return null;
> 144:         } else if (entry instanceof LambdaForm) {
> 145:             return (LambdaForm) entry;

Suggestion:

        } else if (entry instanceof LambdaForm lf) {
            return lf;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21049#discussion_r1764400587
PR Review Comment: https://git.openjdk.org/jdk/pull/21049#discussion_r1764400920
PR Review Comment: https://git.openjdk.org/jdk/pull/21049#discussion_r1764401134


More information about the core-libs-dev mailing list