[jmm-dev] VarHandle.safepoint() methods

Doug Lea dl at cs.oswego.edu
Thu Jan 5 16:34:14 UTC 2017

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.


More information about the jmm-dev mailing list