[concurrency-interest] DirectByteBuffers and reachabilityFence
gil at azul.com
Wed Dec 9 12:53:28 EST 2015
[re-sending since it appears that my previous e-mails were not making it into the list earlier (my fault)].
> On Dec 9, 2015, at 5:11 AM, Doug Lea <dl at cs.oswego.edu> wrote:
> On 12/09/2015 05:33 AM, Andrew Haley wrote:
>>> In my opinion, the current lack of optimization (accidental or not)
>>> should be somehow encoded/made intentional.
>> I have in the past argued that methods of classes with finalizers
>> should automagically extend the lifetime of the "this" object.
>> However, I was on the losing side, and reachabilityFence() is the
>> compromise result. That's okay, really: it solves the practical
> I don't think anyone "lost" these arguments, but further action
> was postponed at least in the context of JMM-related updates.
> Among the options is to introduce a @Finalized annotation
> for a field of an object. Front-end compilers would
> then insert reachabilityFence() after each use. Not necessarily
> immediately after though. Optimal placement is non-trivial, which
> is one reason this wasn't widely agreed on. It would be great
> if some IDE's tried out this kind of support inside IDEs though.
Since this issue is in no way contained to finalizers, and effects all phantom/weak/soft refs and cleaners, anything that only applies to classes with finalizers would not be sufficient. E.g. DBB would still need to be fixed.
I also don't think that an annotation on a field that implies a reachability fence (regardless office we name it) would suffice or help much. DBB is a great example of why I think this: the buffer management in DBB is an internal concern, and the current reachability bugs in its get() and put() implementations are internal implementation bugs. As such, it would clearly make no sense for a user of DBB to place an @Finalized (or equivalent) annotation on their instance fields that refers to a DBB. But inside of DBB, field annotation can't be used since there is no field to annotate, since it is 'this' that needs its reachability extended to the end of its instance methods.
My take on this would be to change the JLS and JVM spec to state that 'this' remains reachable until after the last instruction of every instance method. Period. This would basically equate to placing an implicit reachability fence at all exist points of every instance method (I.e. The equivalent of a try...finally). The "nice״ thing about such an implicit reachability fence is that it does not really defeat any optimizations, as it only serves to extend the lifetime of an oop (so potentially pressing slightly harder on the register allocator). IMO this would auto-magically fix lots of current rarely occurring bugs (like those on DBB, but also in user code), and prevent many future ones.
For now I'm happy to see reachabilityFence, because I'm convinced that we have many resource cleanup race bugs in the JDK that are currently in fixable without it. But I think we should consider this implementing this implicit behavior (extending 'this' reachability to the end of all instance methods) even if the spec is not changed, because it would save us the manual work of fixing all the existing bugs by adding reachability fences. And would obviously provide better coverage than anything we could do manually.
> See discussions on jmm-dev list mostly in August 2014.
> (Also, someday, the JLS probably should be updated to explicitly
> mention impact of reachabilityFence. The wording change
> would basically be the same as the method spec, but a few other
> clarifications done at the same time might be helpful.
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the Concurrency-interest