[concurrency-interest] DirectByteBuffers and reachabilityFence
gil at azul.com
Wed Dec 9 14:15:00 EST 2015
> On Dec 9, 2015, at 10:26 AM, Andrew Haley <aph at redhat.com> wrote:
> On 12/09/2015 05:23 PM, Gil Tene wrote:
>>> On Dec 9, 2015, at 9:18 AM, Andrew Haley <aph at redhat.com> wrote:
>>> On 12/09/2015 04:16 PM, Vitaly Davidovich wrote:
>>>>> an implicit implication that 'this' must remain reachable until after the
>>>>> last instruction in each of its instance methods
>>>> Why wouldn't this work, at least as a compromise?
>>> It would, but it would hurt performance because of increased register
>> Actually, it would only add a stack slot. And a spill into it if needed.
> Hesitant as I am to argue with you, I'm not so sure. There'd
> definitely have to be a USE in order to keep the oop alive, and C2
> would surely try not to spill the oop. The USE would be at the end of
> every method. Unless there's some sort of "sink" node in the ideal
> graph which keeps an oop alive but does not refill from a stack slot,
> and I don't think there is.
Well, this all depends on how it's actually implemented.
Implementations can vary from an opaque non-inlineable method call that takes the 'this'
ref as an argument, to ones that just maintain a USE on the exit paths that doesn't get
optimized away (and as you note may mislead/drive the register allocator to want to keep the
thing in a register), to ones that somehow eliminate the actual use and the wish to hold
it in a register for that use, but prevent the recycling of the virtual register and/or associated
What is minimally required is that the oop remain around in the frame, and for it to be
described in the oopmaps. Which is why I see the minimal cost as that stack slot and the
potential spill into it.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the Concurrency-interest