JEP 134: Intuitive Semantics for Nested Reference Objects

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