[concurrency-interest] Is Reference.reachabilityFence() needed in Reference constructor? (original) (raw)

Peter Levart peter.levart at gmail.com
Thu Oct 22 11:22:48 UTC 2015

Hi,

Thanks for the insight.

I'd like to note that I'm not concerned about the reachability of the Reference object itself (program code takes care of that - for example in Cleaner API it hooks Reference objects into a doubly-linked list exactly for them to stay reachable until discovered by GC and enqueued by ReferenceHandler thread into the associated ReferenceQueue). I'm merely interested in the reachability of the referent until the Reference (and any possible Reference subclass constructor) fully constructs the Reference instance.

The situation where this would manifest as a malfunction is improbable (as the referent is usually passed to other parts of code too and is reachable from elsewhere for some time). But in case it isn't, the following is possible:

 Reference(T referent, ReferenceQueue<? super T> queue) {
     this.referent = referent;
     // - safepoint with GC happens, 'referent' is found

weakly-reachable, 'this' Reference is hooked on the pending chain // - ReferenceHandler thread unhooks 'this' from pending chain and tries to enqueue it, but this.queue is still null // - BANG! NPE in Referencehandler thread which terminates it! this.queue = (queue == null) ? ReferenceQueue.NULL : queue; }

A pre-requisite for above scenario is a safepoint between "this.referent = referent" and "this.queue = ...". In interpreter, safepoint check is after every bytecode instruction right? But in Interpreter, I think arguments are also kept on the stack and are therefore reachable at least until the end of constructor. How probable is a safepoint between those two statements in JIT-ed code? Maybe the Reference constructor itself is not in danger because it is very trivial, but what about subclasses that must do their own part of initialization too (for example Cleaner API discussed on core-libs-dev)?

Regards, Peter

On 10/22/2015 12:25 AM, Vitaly Davidovich wrote:

Yes, if runtime stripes that instance before it is exposed anywhere (e.g. scalarizes the weakref)

If you look at escape analysis code (http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/file/a60bd3d34158/src/share/vm/opto/escape.cpp#l803), Reference and subclasses get special treatment and marked as GlobalEscape. On Wed, Oct 21, 2015 at 1:08 PM, Aleksey Shipilev <aleksey.shipilev at oracle.com <mailto:aleksey.shipilev at oracle.com>> wrote: On 10/21/2015 06:53 PM, Andrew Haley wrote: > On 10/21/2015 04:44 PM, Aleksey Shipilev wrote: >> Of course, this does not tell another (scary) part of the story, what if >> the Reference itself is not discovered as strong ref by GC, e.g. when it >> isn't published on heap, or scalarized by compiler, etc. >> reachabilityFence, as currently implemented, extends the "liveness" >> scope of the local variable, but does not convey anything special to the >> GC/runtime otherwise. > > If the Reference itself is not reachable from a strong root then the > Reference is dead so we don't care what happens to it. But if the > Reference is put on a reachable ReferenceQueue, then it's fine. Yes, if runtime stripes that instance before it is exposed anywhere (e.g. scalarizes the weakref), or those references are dead (e.g. the weakref is buried somewhere deep in garbage subgraph, and purged on sweep), then everything goes awry. But the thing is, a WeakReference is put on ReferenceQueue by the GC itself. In the object graph, ReferenceQueue does not normally reference weakrefs back. Before enqueueing the reference GC has to first discover that WeakReference -- but from where? In other words, "registering" on a reachable RefQueue does not make weakref to be reachable. Case in point: public class WhereIsWaldo { public static void main(String... args) throws Exception { for (int c = 0; true; c++) { new WhereIsWaldo().work(c); } } final ReferenceQueue rq = new ReferenceQueue<>(); void work(int id) throws Exception { hideWaldo(id); findWaldo(id); } WeakReference gwr; void hideWaldo(int id) { // Does not work, d'uh new WeakReference<>(new Object(), rq); // Does not work either :( WeakReference wr = new WeakReference<>(new Object(), rq); // This also does not help... once you leave the method, // the weakref is gone. Reference.reachabilityFence(wr); // This one helps, makes Waldo reachable // gwr = wr; } void findWaldo(int id) throws Exception { while (Thread.currentThread().isAlive()) { System.gc(); Reference ref = rq.remove(1000); if (ref != null) { return; } else { System.out.println("Where's Waldo #" + id + "?"); } } } } Thanks, -Aleksey

More information about the core-libs-dev mailing list