On Tue, 15 Oct 2024 05:16:58 GMT, Ioi Lam <ik...@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 15 additional commits since the > last revision: > > - reviews from @iwanowww and @rose00 -- move USE_SOFT_CACHE to > MethodHandleNatives as a @Stable field; use system prop for init > - 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 > - 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 > - @liach and @cl4es 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 > - @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 > - ... and 5 more: https://git.openjdk.org/jdk/compare/144bcc30...e46b910a
> This is good although hacky, due to incomplete "build out" of Leyden-related > functionality. For a first JEP it is fine. But it leaves some debt to pay off > later. > > Later, we need to decide how to more fully embrace SoftReference. There is > nothing inherently wrong with mixing SR's and AOT, even if they interfere > somewhat. I think the right answer might be forcing them to get along better. > We need to get their queueing status into a quiet state order to push them > into the AOT cache (and then pull them out as the production run states). It > seems to me we should (first) try pruning away most of the queueing > infrastructure during the assembly phase, and patching it up in the > production run (at some appropriate `VM::initState` level), so that the SRs > "go live" at a controlled point during boot-up. > > Or, we could do a Three Table (or Two Table) solution. This PR is an example > of a Two Table solution. (One could say the handoff from AOT table to runtime > table is overly subtle but it works, and maybe that subtlety just comes with > the territory.) The various cache variables (`Transform.cache` and > `MTF.LFs/MHs`) right now are polymorphically SRs or hard references. The > variable `MethodHandleStatics.NO_SOFT_CACHE` controls which "table" is > active. (This is a sort of "sharded" table, not a centralized table object.) > Cached values are inserted into the table using soft or hard refs, depending > on NO_SOFT_CACHE. They are extracted in a robust way, using instanceof, which > is good. There is no plan for converting hard to soft refs, which is probably > OK; we can fix this later if we need to. > > If we have a sudden flash of insight how to support AOT of soft references > (SRs), then this PR goes away. Otherwise, I have one request, related to > MethodHandleStatics. I think we should be moving towards respecting the > finals of that class, like any other class, as AOT-able values. Using just > one static as a secret channel for AOT logic is too edgy for my taste. > > First, `NO_SOFT_CACHE should probably be a @Stable variable, not a final, so > it can be patched. And it should be inverted: `@stable boolean > USE_SOFT_CACHES`. When the VM goes to the right init-phase (but never during > assembly phase), that boolean should be set true, and it will act like a > constant true boolean forever after. > > Also, consider moving it (as a stable non-final) to `MethodHandleNatives`, > since its state depends on stuff below the level of Java proper. I think > `MethodHandleStatics` stuff has a different area of responsibility than > `USE_SOFT_CACHES`. Hi John, I've moved the variable to `MethodHandleNatives` as `static @Stable boolean USE_SOFT_CACHE`. Please let me know if it looks good to you. ------------- PR Comment: https://git.openjdk.org/jdk/pull/21049#issuecomment-2412919559
