[jmm-dev] VarHandle.safepoint() methods

Andrew Haley aph at redhat.com
Thu Jan 5 13:49:32 UTC 2017


On 05/01/17 13:03, David Holmes wrote:
> On 5/01/2017 7:35 PM, Andrew Haley wrote:
>> On 04/01/17 21:47, David Holmes wrote:
>>> I'm no compiler guy but I would think, given the compiler has no idea
>>> what may lead to a safepoint, that this would have to preclude any
>>> reordering of any kind around the load.
>> We have a pretty good idea what needs to be done to the compiler to
>> make this work.  It's not easy, but neither is it impossible.
> I understand that the JIT knows when it inserts a safepoint poll, but 
> otherwise I don't believe the JIT knows which calls into the runtime 
> might lead to safepoints. I guess it will just have to assume the worst.

All calls lead to safepoints AFAIK.

>> Well, the global synchronization mechanism exists already in most
>> JVMs, and there's not much chance of it going away.  All this does
>> is expose it.
> Exposing it - when "it" is an internal implementation detail - is what I 
> am concerned about.

Sure, me too.

>>> In terms of implementation the existing VM safepoint mechanism has no
>>> means to "wait for a safepoint", but could trivially request one. I'll
>>> also note that we're always looking at ways to remove the need for
>>> global safepoints in the VM, so a request may be essential - though when
>>> using GuaranteedSafepointInterval a sleep of that duration would ensure
>>> a global safepoint has occurred.
>> Sure.  I was thinking of a version of VarHandle.safepoint() which took a
>> timeout: if a safepoint didn't arrive after N seconds, force one.
> I'd be interested to hear what mechanism you envisage for waiting for, 
> and detecting, that a safepoint has arrived.

I'm a bit bewildered by this question.  When a thread is safepointed
it gets told by the VM to safepoint.  All it has to do is wait for that
to happen.  Why does that matter anyway?


More information about the jmm-dev mailing list