On Mon, 25 Mar 2024 19:26:41 GMT, Brent Christian <bchri...@openjdk.org> wrote:
>> Classes in the `java.lang.ref` package would benefit from an update to bring >> the spec in line with how the VM already behaves. The changes would focus on >> _happens-before_ edges at some key points during reference processing. >> >> A couple key things we want to be able to say are: >> - `Reference.reachabilityFence(x)` _happens-before_ reference processing >> occurs for 'x'. >> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the >> registered cleaning action. >> >> This will bring Cleaner in line (or close) with the memory visibility >> guarantees made for finalizers in [JLS >> 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5): >> _"There is a happens-before edge from the end of a constructor of an object >> to the start of a finalizer (ยง12.6) for that object."_ > > Brent Christian has updated the pull request incrementally with one > additional commit since the last revision: > > Small updates to reachabilityFence, per review src/java.base/share/classes/java/lang/ref/Reference.java line 638: > 636: * > 637: * <p> It is sometimes possible to better encapsulate use of > 638: * {@code reachabilityFence}. Continuing the above example, if it > were [Per Hans in email,](https://mail.openjdk.org/pipermail/core-libs-dev/2024-March/120747.html) I agree that this is not a good example, and is misleading. Even if `update()` could be called without harm if the finalizer has already executed: the user has called `action()` expecting some action (involving the `externalResource`) to take place. With the `reachabilityFence()` call "refactored" in this way, it is unclear whether that action actually takes place. Better to stick with the try/finally/reachabilityFence() pattern, and have `action()` behave consistently. This passage/example should be removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1538183404
