If you are looking to do this sort of thing in a GC and want to keep things flowing without STW pauses, using a checkpoint (or similar mechanism that ensures all threads have crossed a safepoint opportunity) is very useful, and maybe even necessary. A full-blown stop-the-world safepoint qualifies for the same purpose, but is often not needed when all you need is to establish that something has taken place before you proceed.
There are various useful qualities enforced at safepoint opportunities in mutators that are critical for many GC algorithms (STW or not), and can be relied on even if you never make the mutator stop at the safepoint opportunity. One of the most important is that un-described references or things that derive from them (e.g. like native pointers that cannot be manipulated) do not survive a safepoint-opportunity-crossing. The interaction of handles with safepoint opportunities is critically useful: the fact that any and all native pointers into the heap must be re-established from handles after each safepoint opportunity is crossed makes it possible to use a checkpoint mechanism to establish useful knowledge for many mechanisms, proving that no native pointers that pre-date a certain operation or observation exist. We use it not just for GC, but also for things like concurrent monitor deflation... The nice thing is that in the presence of ANY relocating collector (even a Stop-the-world one, like SerialGC or ParallelGC in Java), mutator code is already required to be written and generated with safepoint opportunities that adhere to these rules, since e.g. a relocating STW collector may have relocated objects during a STW safepoint taken at any of the safepoint opportunity points). This makes adding concurrent algorithms that rely on non-STW safepoint-opportunity-crossing acknowledgements for synchronization relatively easy for existing runtimes. On Wednesday, May 3, 2017 at 6:03:21 PM UTC-7, Yichao Yu wrote: > > > We don't care if the > > other threads see the changes or not. Until we do care. And then we just > > need to know that the changes have applied everywhere before we do > something > > that needs that fact to be known. We establish it not just with the TLB > > invalidate, but with some sort of additional explicit synchronization > that > > follows it. > > > We don't rely on the TLB stuff being strong But we establish the > boundaries > > with explicit > > I see. This might be what I'm missing since I'm used to using mprotect > for synchronization itself.... > > Thanks again for the very detailed answers. > -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
