[jmm-dev] VarHandle.safepoint() methods

[Andrew Haley]

On 05/01/17 01:03, Gil Tene wrote:

> To avoid confusion with (and ties to) the under-the-hood notion of a
> safepoint in JVMs, I'd suggest we use another term to describe
> this. "Checkpoint", "Line in the Sand", "Phase", are useful example
> terms to play with perhaps.

Thanks, yes.  I was hoping for something like that.

> Epoch based an RCU based schemes share a lot of what you are looking
> to do, I think. But as I understand it, you are looking to avoid
> forcing participating threads into some specific behaviors
> (e.g. like periodically ticking as would be needing by RCU schemes,
> or tracking of phase numbers in Epoch schemes), and you are hoping
> that the semantic behavior chosen could be optimized by JVMs into a
> "virtually no cost" operation by leveraging the already-paid-for
> safepoint polling mechanisms that exist in all generated and runtime
> code. I like the notion of sinking the cost into that stuff...

Right, exactly.

> As Sanjoy notes, if you are looking to have JITs fold this into the
> existing safepoint polling stuff, there is an issue with compound
> operations that may include implicit safepoint/checkpoint polling
> opportunities (e..g between each and every bytebode executed in the
> interpreter].

Sure, but I don't really care about the interpreter.  In there,
getSafepoint() can simply be a volatile get().  In the JITs we know
precisely where safepoints are, and can optimize on that basis.

> So the operation you would need to use in place of buf().get() is
> probably something more like "vh.followAsMappedByteBufferAndGet()"
> and "vh.followAsMappedByteBufferAndSet(byte vaiue)". And that gets
> messy…
> 
> However, here is a scheme that is abstracted away, but could be made
> to work IMO:
> 
> Using the term "checkpoint", we would describe this as:
> 
> The runtime is free to insert "checkpoint crossing boundaries"
> anywhere in code (between any two bytecodes), except where
> specifically prohibited by contract.
> 
> "Accessors" perform sets operations that [by contract[ cannot be
> reordered across checkpoint crossing boundaries, but are otherwise
> schedule-able like any other operation.
> 
> And:
> 
> "Modifiers" performs checkpoint operations that will initiate a
> global checkpoint transition, and will only return when all threads
> are assured to no longer be executing code that preceded a
> checkpoint crossing boundary that executes after the checkpoint
> operation has been initiated.

I think I see.  The underlying implementation mechanism would be
essentially the same, and would still allow references to be hoisted
out of loops, but we have an easier way to describe it in the
specification language.  On the other hand, implementing it in the
compiler looks considerably more difficult, and the JIT would miss
optimization opportunities because of the visibility horizon.
Something like this:

>   public void put(byte val) {
>      Runtime.runWithNoCheckpointBoundaries( (val) -> _buf.put(val) );
>   }

would generate truly awful code when not fully inlined.

I wonder if there's some way to use a similar specification language
without all the fussiness of this implementation.

Andrew.