[jmm-dev] VarHandle.safepoint() methods

[Andrew Haley]

Hi,

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?

Andrew.