Proposal: Improve java.lang.ref processing in Java SE 8 and JDK 8

[Iris Clark]

A critical issue has been identified in the Java SE 8 Platform, pertaining to
the cloning of java.lang.ref.Reference objects.

While investigating this issue, two related issues were identified in the
processing of Reference objects.

The issues are:

  - (Critical) The Java SE 8 Specification does not clearly define the
    semantics of cloning a Reference object.  During Java SE 11 development,
    it was determined that a Reference object cannot be meaningfully cloned
    since its reachability may change during garbage collection reference
    processing.  Thus, Reference.clone() was specified in Java SE 11 to always
    throw a CloneNotSupportedException. [0]

  - (Related) The Java SE 8 Specification does not prohibit the referent of a
    phantom reference from being retrieved between the time that the reference
    is enqueued and the time it is cleared by the garbage collector.  To
    eliminate this possibility, the specification of PhantomReference was
    updated in Java SE 9 to automatically clear reference objects when they
    are enqueued.  This update better aligned PhantomReference with
    SoftReference and WeakReference. [1]

  - (Related) The Java SE 8 Specification allows an application to explicitly
    add a Reference object to its registered queue before it is cleared by the
    garbage collector.  In Java SE 9, the specification of Reference.enqueue()
    was modified to always clear the reference object before it is enqueued.
    This aligns application code invocations of this method with the behaviour
    of garbage collectors. [2]

To resolve these issues for future JDK updates, I'll shortly propose a
Maintenance Release of the Java SE 8 Platform JSR [3] in the JCP to backport
these three changes from Java SE 9 and 11.  This will require updates to the
Specification and the Reference Implementation (RI), which I and my colleagues
at Oracle will provide.  The TCK does not require updates.  I expect the
Maintenance Release process to complete by July 2022, in time for these
changes to be merged into the October security releases of JDK 8.

Following the practice introduced in the previous Maintenance Release
(February 2020), we want to reduce risk by basing the open-source RI on
OpenJDK 8u41 [4], the RI for the previous Maintenance Release, rather than the
most recent OpenJDK 8 Updates release.  We propose to label the RI build as
"8u42" in order to convey that it is outside the contemporary train of update
releases, and (like the 8u41 build before it) is neither meant for production
use nor updated with security fixes.

If it's not too much work then we'll also contribute the changes required by
the MR to the next appropriate OpenJDK 8 Updates release, most likely 8u352.

Comments?

Iris

[0]: https://bugs.openjdk.java.net/browse/JDK-8202260
[1]: https://bugs.openjdk.java.net/browse/CCC-8071507
[2]: https://bugs.openjdk.java.net/browse/CCC-8175797
[3]: https://jcp.org/en/jsr/detail?id=337
[4]: https://hg.openjdk.java.net/jdk8u/jdk8u41