Looking at JDK-8369283 logs, I believe we have a minor performance opportunity, look:

[5448421640ns] Safepoint synchronization begins
[5448472227ns] Suspending GC threads
[5448489199ns] Blocking threads from starting/exiting
[5448504629ns] Arming futex wait barrier
[5448520860ns] Setting thread local yield flag for threads
[5448541169ns] 26 total threads, waiting for 15 threads to block
[5448557199ns] Checking thread status
...
[5448597837ns] Waiting for 15 threads to block
...
[5448668341ns] Safepoint synchronization finished

So the total synchronization took 246us, out of which we spent 17us waiting for GC (G1 in this case) to suspend its threads. But we can probably do this concurrently: announce the safepoint first, let Java threads block, and before going in and checking for Java thread status, we can ask GC to suspend. This would hide all those 17us in the time we wait for Java threads to respond. Additionally, Java threads that are blocking now would likely free up CPUs to let GC STS suspension to complete more promptly.

I think STS that GCs use to suspend/resume are oblivious of safepoint state, so it should be safe to rearrange. We need to check if it really is.