Re: Low-latency pause in JDK

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.

-Nathan

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.
>
_______________________________________________
Concurrency-interest mailing list
[email protected]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest