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

[Ioi Lam]

On Wed, 12 Mar 2025 21:03:04 GMT, John R Rose <jrose 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...
>
> That said, I think this PR can be pushed, even with the FIXMEs.  You might need to open a second tracking bug for the remaining work. That remaining work may include my suggestion, of adding error-detection logic in the reference queue processors defined by the JDK.

Thanks @rose00 for the review. I will try to work on the ReferenceQueue processing in a future RFE.

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

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