JEP 134: Intuitive Semantics for Nested Reference Objects
|Component||hotspot / gc|
|Discussion||hostspot dash dev at openjdk dot java dot net|
|Endorsed by||Mikael Vidstedt|
|Relates to||6990442: (ref) Regression to clearing of a softly reachable object|
|6990438: (ref) Soft reference could consider strong if GC decides not to clear|
Implement a more-intuitive semantics for nested reference objects.
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.
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
- 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.
- Compatibility: New JCK test development
- Documentation: Updates to the tutorial/guides