[concurrency-interest] DirectByteBuffers and reachabilityFence

Vitaly Davidovich vitalyd at gmail.com
Wed Dec 9 12:47:11 EST 2015


This is no different than your previous examples in spirit.  Your explicit
triggering of GC is contorting the real thing we want to check.  You're
also using a loop with a long counter, which will automatically place
safepoint polls in that loop.  I'm trying to understand how DBB.get()
happens to work today, not how the above doesn't as it's obvious to me why
it doesn't. :)

On Wed, Dec 9, 2015 at 12:39 PM, Alexandre De Champeaux <adc at quartetfs.com>
wrote:

>
>
>> This is why I suggested to ask the Hotspot compiler devs who may be able
>> to answer this (relatively) quickly and definitively, or at least as
>> definitive as we'll get at this point.  Jason's example? You mean
>> Alexandre's? The only case demonstrated in this thread that actually
>> segfaults is what Alexandre showed, but as mentioned a few times, it's
>> slightly different from DBB.
>>
>>
> Well it's not that different from the get() method of a DBB.
> If you like, you can replace the copy method of my previous example with
> something like
>
> public byte[] copy() {
> final byte[] a = new byte[1];
> final long addr = this.addr;
> if (ctr++ >= 31_000l * 1000) {
> // Counter is there to wait for JIT compilation
> System.out.println("Must be compiled now, start doing some GCs " + ctr);
> // Here we simulate a safepoint, and a GC at this safepoint
> System.gc();
> try {
> // And here we wait for the reference handler to perform the cleaning to
> simulate a fast cleaning.
> Thread.sleep(1000);
> } catch (InterruptedException e) {
> Thread.currentThread().interrupt();
> }
> }
> a[0] = unsafe.getByte(addr);
> return a;
> }
>
> This crashes as well.
>
> Alexandre
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20151209/34f70da2/attachment.html>


More information about the Concurrency-interest mailing list