Besides GC Stop-The-World safepoints there are a lot of reasons why a JVM can stop a java application in a safepoint. One of these reason to evaluate safepoints stop is a guaranteed safepoint interval.
Can we forcast when guaranteed safepoint stop is to be taken ? Or maybe if it was taken recently ?
Why do I need it ? I do shared memory file pretouching in a thread. If pretouching is taking place when safepoint stop is evaluated it makes the Time-to-safepoint much longer. If I can only wait till just after safepoint evaluation.
Cleanup safepoint (aka "Guaranteed safepoint") happens only when there is some cleanup work to do, e.g. JVM needs to deflate idle monitors or purge inline cache buffers. There is no way to predict such safepoints. But the good news is that you don't need to.
So, the original problem is to prevent long time-to-safepoint pauses when pretouching a memory-mapped file, right? The solution is to pretouch it in a way that is not affected by safepoints at all.
When you call a JNI method, a thread switches to in_native state. JVM does not wait for threads in this state. So, just move pretouching to a native method, and it will not affect safepoints, whether they happen or not.
One option is to use regular FileChannel API. E.g. instead of accessing Mapped ByteBuffer, pretouch by reading (or writing) 1 byte from a FileChannel. I/O will happen in a native method which is not subject to safepoints.