[concurrency-interest] DirectByteBuffers and reachabilityFence
vitalyd at gmail.com
Mon Dec 7 10:20:22 EST 2015
If reachabilityFence use is going to proliferate, especially in perf
sensitive places, Hotspot will need to make this method simply a liveness
marker and not emit a call like the current prototype/version is doing.
sent from my phone
On Dec 7, 2015 10:07 AM, "Andrew Haley" <aph at redhat.com> wrote:
> On 12/07/2015 12:40 PM, Alexandre De Champeaux wrote:
> > However, this got me concerned about the java.nio.DirectByteBuffer read
> > 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
> > a safepoint, then a GC must happen, and finally the ReferenceHandler
> > needs to perform its cleanup fast enough.
> > I am particularly concerned by the get(byte dst, int offset, int
> > 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
> > DirectByteBuffer?
> There are many places where we need to insert a reachabilityFence.
> This is one such. Some non-HotSpot JVMs perform their cleanups
> very aggressively, so it's more likely there.
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest