[concurrency-interest] Low-latency pause in JDK

Nathan and Ila Reynolds nathanila at gmail.com
Wed Oct 30 11:03:07 EDT 2019

For blocking file I/O, the native method will check the stop-the-world 
flag after returning from the OS API call.  GC can then assume these 
threads are effectively stopped.

If the "pause" instruction does not wake up the thread immediately due 
to a stop-the-world event, we could add similar logic as what is in file 
I/O.  However, this will make pause performance suffer.


On 10/30/2019 4:04 AM, Andrew Haley wrote:
> On 10/26/19 2:52 PM, Nathan and Ila Reynolds via Concurrency-interest wrote:
>> The downside of pausing the threads execution of instructions is
>> that the thread cannot respond to stop the world events.  This will
>> increase the time it takes to stop the world.
> Good point.
> I don't think that's necessarily true, though. When a stop-the-world
> event is needed a common technique is to read-protect a page. At the
> hardware level this is [usually?] done by sending an inter-processor
> interrupt broadcast to invalidate the TLBs of all processors. This
> will kick every processor out of MWAIT/WFE.
> On Arm any event which clears the "global monitor" (i.e. the state
> machine used by load locked / store conditional) will kick the
> processor out of WFE, and both TLB invalidate and exception return
> clear the global monitor. I very much suspect Intel will do the same,
> but that's not guaranteed.
> Also, the longest MWAIT pause time I've ever measured on AArch64
> systems is orders of magnitude less than our time to safepoint in
> HotSpot. There's no guarantee of that either.

More information about the Concurrency-interest mailing list