[concurrency-interest] DirectByteBuffers and reachabilityFence

Vitaly Davidovich vitalyd at gmail.com
Tue Dec 15 09:50:12 EST 2015


I wonder if this example is hiding some optimization problem.  Although
it's clear that the TPE does not escape, I'm having a hard time seeing how
the JIT was able to prove that it could shorten the lifetime of the TPE
through the swath of code in TPE::execute with all of its atomic ops to
boot.

On Tue, Dec 15, 2015 at 7:58 AM, thurstonn <thurston at nomagicsoftware.com>
wrote:

> David Holmes-6 wrote
> > Here’s another nasty little reachability/finalize example:
> >
> >
> >
> > https://bugs.openjdk.java.net/browse/JDK-8145304
> >
> >
> >
> > David
>
> I think this is an actual bug, i.e. it's a violation of the spec.
> If you look at TPE's code and the test case, #reject is being executed
> *after* #finalize has done it's dirty, and #reject() references an instance
> variable (#handler) - surely that's not allowed; I mean accessing an
> instance variable counts toward reachability, surely
>
>
>
>
>
>
> --
> View this message in context:
> http://jsr166-concurrency.10961.n7.nabble.com/DirectByteBuffers-and-reachabilityFence-tp12935p13081.html
> Sent from the JSR166 Concurrency mailing list archive at Nabble.com.
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20151215/112c6ec7/attachment.html>


More information about the Concurrency-interest mailing list