[jmm-dev] VarHandle.safepoint() methods

[Doug Lea]

On 01/05/2017 11:00 AM, Andrew Haley wrote:
> On 05/01/17 15:40, Doug Lea wrote:
>> On 01/05/2017 09:09 AM, Andrew Haley wrote:
>>>
>>>   if (VarHandles.checkPointed()) // returns true if safepoint
>>>      VarHandles.fullFence();
>>>
>>> It'd certainly be easier to implement, and it naturally matches
>>> exactly what a safepoint does.
>>>
>>
>> It matches it so well that it makes sense to specify the
>> method to perform fullFence after safepoint execution.
>>
>> You'd still need epoch-returning form to deal with
>> safepoints occurring in nested calls in loops.
>>
>>    e = VH.safePointEpoch();
>>    for (...) {
>>      use(x.get());
>>      e = VH.safePointCheck(e);
>>    }
>
> I can't see how this might work in the MappedByteBuffer case.
> The user is only going to be writing things like
>
>   for (int i = 0; i < n; i ++) {
>     sum += buf.get(i);
>   }
>
> I'm not proposing any change to the MappedByteBuffer API.  What
> would insert the call to safePointEpoch() ?

Some sort of annotation? I realize that this trades off one kind of
messiness for another, but users would otherwise need to know to
use your proposed getSafePoint() method vs plain get(). I can't
think of anything that automatically does either of these or
any of Gil's variants.


>> The difference between implicit and explicit safepoint checks is
>> that in the implicit ones, some variables can be restored
>> to those saved on safepoint entry, but not so in the explicit
>> case -- they must be freshly read.
>
> In the case of a real safepoint, nothing is saved around a safepoint
> call.  What actually happens is that an interrupt occurs, as a
> consequence of which live registers are pushed onto the stack,
> safepoint code is run, registers are restored, and we continue.
>

Right; that's what I meant by save/restore. And it would be fine
to do this followed by fullFence in explicit case.

-Doug