[concurrency-interest] DirectByteBuffers and reachabilityFence

Justin Sampson jsampson at guidewire.com
Sat Dec 12 20:46:06 EST 2015

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



More information about the Concurrency-interest mailing list