Re: Low-latency pause in JDK
Andrew Haley via Concurrency-interest <[email protected]>
| Newsgroups | gmane.comp.java.jsr.166-concurrency |
|---|---|
| Message-ID | <[email protected]> |
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. -- Andrew Haley (he/him) Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> https://keybase.io/andrewhaley EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 _______________________________________________ Concurrency-interest mailing list [email protected] http://cs.oswego.edu/mailman/listinfo/concurrency-interest