[concurrency-interest] DirectByteBuffers and reachabilityFence
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
On Tue, Dec 15, 2015 at 7:58 AM, thurstonn <thurston at nomagicsoftware.com>
> 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:
> Sent from the JSR166 Concurrency mailing list archive at Nabble.com.
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest