JDK-8046124 : JEP 134: Intuitive Semantics for Nested Reference Objects
  • Type: JEP
  • Component: hotspot
  • Sub-Component: gc
  • Priority: P4
  • Status: Candidate
  • Resolution: Unresolved
  • Submitted: 2011-10-31
  • Updated: 2021-10-14
Related Reports
Relates :  
JDK-6990442 - (ref) Regression to clearing of a softly reachable object
Relates :  
JDK-8051680 - (ref) unnecessary process_soft_ref_reconsider
Relates :  
JDK-6990438 - (ref) Soft reference could consider strong if GC decides not to clear
Description
Summary
-------

Implement a more-intuitive semantics for nested reference objects.


Motivation
----------

There has been confusion and misinterpretation of the different levels of
reachability defined in the `java.lang.ref` specification involving weak
and soft references as described in 6990438 and 6990442 (see also
4214755). Several customers have requested a more intuitive behavior.
Clarifying the specification would avoid ambiguities and help improve the
JCK tests for this API.


Description
-----------

Below is a object graph depicting the issue:

    Root ->  ... ->  SR ->  A ->  ... ->  WR ->  B ->  ...

SR and WR represent a soft reference and a weak reference, respectively.
According to the current spec, when the GC processes SR and decides not
to clear it, it goes on to mark the entire object graph reachable from A,
including the object graph reachable from B, and does not clear WR
because B is considered as not weakly-reachable but instead softly
reachable. Such behavior is not intuitive. It would be more intuitive to
consider SR a strong reference for the rest of the GC operation when the
GC decides not to clear soft references. In other words, WR would be
cleared as it would be weakly reachable.

The bulk of the work for this enhancement is in the VM to implement the
proposed intuitive behavior in all collectors.  For the HotSpot VM
implementation, due to a performance fix for 6684579 in 6u14, the
stop-the-world collectors in the HotSpot VM unintentionally give the new
intuitive semantics as a side effect. There are no customer reports
related to this behavioral change. The remaining work for this
enhancement is to have CMS and G1 implement the intuitive behavior, and
to update the `java.lang.ref` specification.


Testing
-------

  - All tests (including JCK, regressions, SQE tests) for reference
    processing must pass
  - No performance regressions
  - Must verify early with customers that there is no compatibility issue
    caused by the change of behavior


Risks and Assumptions
---------------------

Compatibility is a potential risk that would require us to retain the
current behavior as the default and allow the new behavior to be enabled
with a flag.  However, the fix for 6684578 was released in 6u14 but there
have not been any regressions reported due to that change of behavior.
We should engage with many customers to test existing applications with
the new behavior to detect if there are any compatibility issues.


Impact
------

  - Compatibility: New JCK test development
  - Documentation: Updates to the tutorial/guides
Comments
The current specification is unclear of this semantics. If this current implementation already supports this semantics, the remaining work will be the specification clarification and new tests to be written. That would not be JEP-sized work while it might be okay to leave it as a JEP for visibility.
14-10-2021
With the resolution of JDK-8269596 and JDK-8051680 (along with the removal of CMS - JDK-8229049), I think the "intuitive behavior" described by this proposal is now provided by all currently supported GCs (except Epsilon, of course). Before those two changes G1 would *sometimes* do something else, that could be surprising and inconsistent. It might be that the current specification already requires this behavior, or at least allows it. But the reasoning to show that is not simple (and might not be correct), so it would be better if the specification could be clarified.
16-07-2021