[concurrency-interest] DirectByteBuffers and reachabilityFence

Gil Tene gil at azul.com
Sat Dec 12 21:20:45 EST 2015


A small note: This is a resource management  vs. reachability race. It is not really a memory model issue IMO, at least not in a conventional way. The fact that the resource being managed here (in DBB) happens to be native memory does the make this memory related. It would be no different and no less problematic if the opaque id stored in the private field on DBB instance didn't refer to a native memory address, and instead represented a file descriptor number, or a window frame id, or a TCP port number, or a slot position in some custom managed arrays of widgets. It is a resource that is being accessed after resource-release actions have been executed on it, and that's all there is to it.

Sent from Gil's iPhone

> On Dec 12, 2015, at 5:53 PM, Justin Sampson <jsampson at guidewire.com> wrote:
> 
> Timo Kinnunen wrote:
> 
>> There's many ways DBB.get() could be written and many ways a
>> compiler could transform it when inlining it inside a calling
>> method. The implementation that I looked at returns the receiver
>> as the method call completes.
> 
> Well, that's the thing: If the method is inlined in a context where
> the returned value is ignored, then the compiler is free to get rid
> of the return statement iself. If there's no return statement, then
> the object can indeed become unreachable at some earlier point in
> the method.
> 
>> As for the theory side of the issue, my position there is that
>> asking what sort of data races thread t1 could observe in the
>> presence of some garbage collection thread GC1 is fruitless,
>> because garbage collection isn't a synchronization action, the JMM
>> doesn't recognize that these threads synchronize with each other
>> and in any case if thread T1 won't attempt to synchronize with the
>> possibly-non-existent GC1 then the whole of JLS 17.4 doesn't even
>> apply.
> 
> For the most part, garbage collection isn't part of the memory model
> because it's supposed to be invisible. And as long as you're not
> trying to manage native memory yourself, it mostly IS invisible. But
> DirectByteBuffer DOES manage native memory itself, which leads to
> some surprising interactions with garbage collection.
> 
> There is some discussion of how garbage collection interacts with
> the memory model in section 12.6.2. That section introduces yet
> another ordering concept, "comes-before," which is only barely
> related to happens-before. It seems primarily intended to ensure
> that an object is only considered unreachable if no thread could
> possibly observe a reference to it. DBB's management of its own
> native memory undermines that logic, leading to a potential
> segfault.
> 
> https://docs.oracle.com/javase/specs/jls/se8/html/jls-12.html#jls-12.6.2
> 
> Cheers,
> Justin
> 
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest



More information about the Concurrency-interest mailing list