RFR: Added -XX:AOTInitTestClass flag; added a test case for archived WeakReference

[Ioi Lam]

[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 mechanism to test 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 REF.

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)`:


0x00000007ffe6b2e8: @@ Object  jdk.internal.util.WeakReferenceKey
 - klass: 'jdk/internal/util/WeakReferenceKey' 0x00000008002f9ad8
 - fields (4 words):
 - private 'referent' 'Ljava/lang/Object;' @12 null
 - volatile 'queue' 'Ljava/lang/ref/ReferenceQueue;' @16 0x00000007ffe6afb0 (0xfffcd5f6) java.lang.ref.ReferenceQueue
 - volatile 'next' 'Ljava/lang/ref/Reference;' @20 null
 - private transient 'discovered' 'Ljava/lang/ref/Reference;' @24 0x00000007ffe6b308 (0xfffcd661) jdk.internal.util.WeakReferenceKey
 - private final 'hashcode' 'I' @28  52198401 (0x031c7c01)

0x00000007ffe6afb0: @@ Object (0xfffcd5f6) java.lang.ref.ReferenceQueue
 - klass: 'java/lang/ref/ReferenceQueue' 0x000000080014f178
 - fields (4 words):
 - private volatile 'head' 'Ljava/lang/ref/Reference;' @12 null
 - private 'queueLength' 'J' @16  0 (0x0000000000000000)
 - private final 'lock' 'Ljava/lang/ref/ReferenceQueue$Lock;' @24 0x00000007ffee0c78 (0xfffdc18f) java.lang.ref.ReferenceQueue$Lock

0x00000007ffe69f08: @@ Object (0xfffcd3e1) jdk.internal.util.ReferencedKeyMap
 - klass: 'jdk/internal/util/ReferencedKeyMap' 0x00000008002f7298
 - fields (3 words):
 - private final 'isSoft' 'Z' @12  false (0x00)
 - private final 'map' 'Ljava/util/Map;' @16 0x00000007ffe69f20 (0xfffcd3e4) java.util.concurrent.ConcurrentHashMap
 - private final 'stale' 'Ljava/lang/ref/ReferenceQueue;' @20 0x00000007ffe6afb0 (0xfffcd5f6) java.lang.ref.ReferenceQueue


The `(0xfffcd65d) WeakReferenceKey` should have been added to the `ReferencedKeyMap::stale` queue, but we can see that the queue is empty.

We can see a few non-null  `Reference::discovered` field in `cds.oops.txt`. These are waiting for the `Reference$ReferenceHandler` thread to move them onto the target `ReferenceQueue.`

However, take a look at the following two lines in the `WeakReferenceTestApp.aot.log` file from the test's output directory: The `Reference$ReferenceHandler` thread is disabled in the assembly phase.


[0.137s][info ][cds] JVM_StartThread() ignored: java.lang.ref.Reference$ReferenceHandler
[0.137s][info ][cds] JVM_StartThread() ignored: java.lang.ref.Finalizer$FinalizerThread


There are two reasons that we run only a single Java thread during the assembly phase:

- Historically, we wanted the contents of the CDS archive deterministic. Concurrently executing Java threads made this very difficult, so we basically hijacked `Thread::start()` to disallow the launching of new Java threads.
- Right before we enter a safepoint to dump the AOT cache, we execute a small amount of Java code (in the main Java thread) to clean up global states. Concurrent Java threads may step on these clean up operations.

Maybe we can enable multiple Java threads for Leyden

- With new Leyden optimizations such as profiling and AOT compilation, the AOT cache is no longer deterministic anyway. It will be exceedingly difficult to get deterministic contents.
- As @shipilev mentioned offline, we may need a way for the GC to tell us that it "has finished all (concurrent) work". At that point, we can wait for the ReferenceHandler/FinalizerThread to become quiescent before we start the global clean up operations. We need to restrict these operations such that they won't cause additional GCs, etc.

Also, we need to call `jdk.internal.util.ReferencedKeyMap::removeStaleReferences()` during the global clean up:


    public void removeStaleReferences() {
        while (true) {
            Object key = stale.poll();
            if (key == null) {
                break;
            }
            map.remove(key);
        }
    }

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

Commit messages:
 - Added -XX:AOTInitTestClass flag; added a test case for archived WeakReference

Changes: https://git.openjdk.org/leyden/pull/45/files
  Webrev: https://webrevs.openjdk.org/?repo=leyden&pr=45&range=00
  Stats: 353 lines in 6 files changed: 351 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/leyden/pull/45.diff
  Fetch: git fetch https://git.openjdk.org/leyden.git pull/45/head:pull/45

PR: https://git.openjdk.org/leyden/pull/45