[concurrency-interest] DirectByteBuffers and reachabilityFence
vitalyd at gmail.com
Mon Dec 7 10:15:04 EST 2015
JIT knows about Unsafe operations, and it also knows the type of memory
being accessed (or sometimes knows it doesn't know :)). So I don't think
it'll mark a DBB as unreachable while these operations are in-flight.
Peter's scenario is unique to WeakReference since it's intentionally not
considered a strong reference and there's otherwise plain java code in his
example (that JIT can reason about easily otherwise).
sent from my phone
On Dec 7, 2015 8:10 AM, "Alexandre De Champeaux" <adc at quartetfs.com> wrote:
> Hi all,
> I recently had a look at the discussion started by Peter Levart on October
> 21 (
> It was a very insightful discussion, and made me aware that the "this"
> object could be garbage collected while being inside a call of one of its
> However, this got me concerned about the java.nio.DirectByteBuffer read
> and write methods:
> If the "this" object is garbage collected when making a call like
> ByteBuffer.allocateDirect(int).someGetOrPutMethod(), the native pointer
> that is passed to sun.misc.Unsafe might be freed, and accessing it will
> cause the read/write to occur in an invalid memory area, which might lead
> to a segfault, or other major issues.
> This would be quite unlikely: JIT compilation needs to occur while keeping
> a safepoint, then a GC must happen, and finally the ReferenceHandler thread
> needs to perform its cleanup fast enough.
> I am particularly concerned by the get(byte dst, int offset, int length)
> method, that in turns calls Bits.copyToArray, which purposely splits its
> calls to Unsafe.copyMemory to allow for safepoints to sneak in.
> Am I correct, or does the JVM performs specific protection for instances
> of DirectByteBuffer?
> Alexandre de Champeaux
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest