[jmm-dev] VarHandle.safepoint() methods

[Gil Tene]

> On Jan 5, 2017, at 2:34 AM, Andrew Haley <aph at redhat.com> wrote:
> 
> On 05/01/17 01:03, Gil Tene wrote:
> 
>> Runtime.runWithNoCheckpointBoundaries(Runnable r) will run r,
>> guaranteeing that no checkpoint crossing boundaries exist within the
>> execution of r.
> 
> But this is surely impossible: many operations include safepoints.
> And I was trying to piggyback this on the existing mechanism.

It is very possible. Easy even.

The way I envision a JVM implementing checkpoints using the existing safepoint mechanisms is this: All checkpoint crossing boundaries are at safepoint polling points. But NOT all safepoint polling points are checkpoint crossing opportunities.

Specifically, when code executed under e.g. runWithNoCheckpointBoundaries(), triggered safepoint polling opportunities will not act as a checkpoint crossing boundary. Safepoint triggered at such places will complete normally and return to execution, and only subsequent safepoints triggered outside of the "no checkpoint boundary" executions will act as a checkpoint crossing. This would be fairly easy, 

Awaiting a checkpoint (in Runtime.checkpoint()) will involve getting all threads to trigger a safepoint polling that will actually act as a checkpoint crossing boundary. When not all safepointed threads have crossed the boundary at a given safepoint request, you just ask them to go to a safepoint again. All threads will eventually trigger at a safepoint that does count as a checkpoint crossing boundary [staying in a runWithNoCheckpointBoundaries indefinitely would be considered an application bug].

Keep in mind that the same APIs I propose can be implemented with no JVM support at all, by simply having each thread hold on to it's "Checkpoint Lock Indicator" when running runWithNoCheckpointBoundaries. The obvious downside to such an implementation is that each buf.get() will involved grabbing and releasing the lock indicator (hence the much better optimized mapped-to-safepoint suggestion). Btu it will be semantically equivalent.

> Andrew.