RFR: 8351004: [leyden] Add test cases for cached Reference objects

[John R Rose]

On Sun, 2 Mar 2025 05:32:47 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> [JDK-8341587](https://bugs.openjdk.org/browse/JDK-8341587) allows Soft/Weak `Reference` objects to be stored in the AOT cache. Currently Soft/Weak references are used only for supporting method handles. However, we need to make sure that the support for cached Reference is correctly implemented:
> 
> 1. When we add other types of objects to the AOT cache that use `Reference` objects (e.g., [JDK-8351005](https://bugs.openjdk.org/browse/JDK-8351005) "Revert back to SoftReference for Class::reflectionData"), they should work as expected.
> 2. The cached `Reference` objects used by the method handles implementation (such as those used by `MethodType.internTable`) should not be unnecessarily coupled with unrelated Reference (e.g., via the `Reference::link` field due to operations in `java.lang.ref.ReferenceQueue` or `java.lang.ref.Finalizer`). Otherwise, this could cause unrelated objects to be unintentionally stored in the AOT cache.
> 3. `java.lang.ref.Cleaner` should work as expected during both the AOT assembly phase and production run.
> 4. Finalization should work as expected during both the AOT assembly phase and production run.
> 
> This RFE adds a flag (`-XX:AOTInitTestClass=...`, available **only** in debug builds) to store arbitrary heap objects into the AOT cache. With this flag, we can the behavior of `Reference` in the AOT cache so that we can determine if the current support for Reference objects in Leyden is good enough for upstreaming to the mainline.
> 
> This RFE doesn't not test everything as listed above cases. Some additional test cases may be added by a subsequent commit.
> 
> I have observed the following:
> 
> **[A]** Cached `WeakReference` objects seem to be supported by the GC in the production run. See `testWeakReferenceCollection()`: if a referent is no longer reachable, `ref.get()` returns `null`.
> 
> **[B]** Case (2) doesn't seem to be a concern: `testQueue()` shows that the assembly phase won't accidentally find unrelated `WeakReference` objects even if they share the same queue as a `WeakReference` that's destined to be cached. See comments in `testQueue()` for more details.
> 
> **[C]** `MethodType.internTable` is a `ReferencedKeySet` that internally uses `WeakReference` to automatically remove elements that are no longer referenced. However, with `grep -n referent.*null cds.oops.txt` in the test's output directory, we can see a few `WeakReferenceKeys` whose `referent` has been collected, but we didn't remove these keys from the `internTable` at `(0xfffcd3e1)`...

This is excellent work.  I agree that we must be cautious about executing arbitrary code in the assembly phase, and that includes reference queue logic.

That said, I think we can largely trust what the reference queues are doing here, and therefore benefit from their work.

The big goal here is to disallow arbitrary user-defined code in the assembly phase.  A secondary goal (which helps use learn how to meet the big goal) is keeping tight control on which JDK-defined code gets run.

Both those goals suggest that the problem is not running reference queue threads, but rather the problem is restricting what happens when a cleaner or finalizer runs.  While the assembly phase is running, I think it would be good to "watch carefully" in the reference processor code (which we trust) for attempts to execute finalizers or cleaners which are not on our "OK list" of cleaners and finalizers.  Even if JDK code defines them, if they would surprise us, the surprise needs to be conveyed in the form of an error, saying "hey, I know this is JDK logic, but you didn't list it as OK to run".

Can we install such a test in the RQ code?  Find the class responsible, and ask if it is on our short list of trusted RQ handler classes?

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

PR Comment: https://git.openjdk.org/leyden/pull/45#issuecomment-2719093091