Hi Hans, On 22/07/2021 7:54 am, Hans Boehm wrote:
Is this an appropriate list to discuss JNI?
No - hotspot-dev (to get runtime and GC folk) is the place to discuss JNI. Thanks, David
I'm concerned that the current semantics of JNI WeakGlobalRefs are still dangerous in a very subtle way that is hidden in the spec. The current (14+) spec says: “Weak global references are related to Java phantom references (java.lang.ref.PhantomReference). A weak global reference to a specific object is treated as a phantom reference referring to that object when determining whether the object is phantom reachable (see java.lang.ref). ---> Such a weak global reference will become functionally equivalent to NULL at the same time as a PhantomReference referring to that same object would be cleared by the garbage collector. <---” (This was the result of JDK-8220617, and is IMO a large improvement over the prior version, but ...) Consider what happens if I have a WeakGlobalRef W that refers to a Java object A which, possibly indirectly, relies on an object F, where F is finalizable, i.e. W - - -> A -----> ... -----> F Assume that F becomes invalid once it is finalized, e.g. because the finalizer deallocates a native object that F relies on. This seems to be a very common case. We are then exposed to the following scenario: 0) At some point, there are no longer any other references to A or F. 1) F is enqueued for finalization. 2) W is dereferenced by Thread 1, yielding a strong reference to A and transitively to F. 3) F is finalized. 4) Thread 1 uses A and F, accessing F, which is no longer valid. 5) Crash, or possibly memory corruption followed by a later crash elsewhere. (3) and (4) actually race, so there is some synchronization effort and cost required to prevent F from corrupting memory. Commonly the implementer of W will have no idea that F even exists. I believe that typically there is no way to prevent this scenario, unless the developer adding W actually knows how every class that A could possibly rely on, including those in the Java standard library, are implemented. This is reminiscent of finalizer ordering issues. But it seems to be worse, in that there isn't even a semi-plausible workaround. I believe all of this is exactly the reason PhantomReference.get() always returns null, while WeakReference provides significantly different semantics, and WeakReferences are enqueued when an object is enqueued for finalization. The situation improves, but the problem doesn't fully disappear, in a hypothetical world without finalizers. It's still possible to use WeakGlobalRef to get a strong reference to A after a WeakReference to A has been cleared and enqueued. I think the problem does go away if all cleanup code were to use PhantomReference-based Cleaners. AFAICT, backward-compatibility aside, the obvious solution here is to have WeakGlobalRefs behave like WeakReferences. My impression is that this would fix significantly more broken clients than it would break correct ones, so it is arguably still a viable option. There is a case in which the current semantics are actually the desired ones, namely when implementing, say, a String intern table. In this case it's important the reference not be cleared even if the referent is, at some point, only reachable via a finalizer. But this use case again relies on the programmer knowing that no part of the referent is invalidated by a finalizer. That's a reasonable assumption for the Java-implementation-provided String intern table. But I'm not sure it's reasonable for any user-written code. There seem to be two ways forward here: 1) Make WeakGlobalRefs behave like WeakReferences instead of PhantomReferences, or 2) Add strong warnings to the spec that basically suggest using a strong GlobalRef to a WeakReference instead. Has there been prior discussion of this? Are there reasonable use cases for the current semantics? Is there something else that I'm overlooking? If not, what's the best way forward here? (I found some discussion from JDK-8220617, including a message I posted. Unfortunately, it seems to me that all of us overlooked this issue?) Hans
