Перед тем, как старая версия сборщика мусора в Java запускала сборку мусора,
она должна была дождаться момента, пока все нити приложения дойдут до специальных точек (которые называют GC-Safe points)
Вот здесь москвич Алексей Рогозин рассказывает об этом ясным английским языком:
http://blog.ragozin.info/2012/10/safepo … t-jvm.html
Обычно эти точки вставляются перед командой возврата из подпрограммы, и в конце цикла перед командой перехода на следующую итерацию.
Safepoint status check itself is implemented in very cunning way. Normal memory variable check would require expensive memory barriers. Though, safepoint check is implemented as memory reads a barrier. Then safepoint is required, JVM unmaps page with that address provoking page fault on application thread (which is handled by JVM’s handler). This way, HotSpot maintains its JITed code CPU pipeline friendly, yet ensures correct memory semantic (page unmap is forcing memory barrier to processing cores).
when reaching the safepoint check, the thread will check if the safepoint is required (e.g. FullGC is scheduled), if yes, then the thread blocks.
Azul is using custom page mapping to facilitate software read barrier, but this technique does not rely on page faults.
Не могу перевести (т.е. перевод ясен, но смысл ускользает, потому что я не знаю, что такое "custom page mapping")
![Лис [О]](https://forumavatars.ru/img/avatars/0018/41/1a/4-1532130981.gif "Лис [О]")
)))
)))