RFR: 8192647: GClocker induced GCs can starve threads requiring memory leading to OOME [v2]

[Albert Mingkun Yang]

On Thu, 6 Feb 2025 06:35:46 GMT, David Holmes <dholmes at openjdk.org> wrote:

> can you explain how this protocol is intended to work please. 

When a GC is requested, the `block()` function sets `_is_gc_request_pending` to `true` and then waits until all threads have exited their critical regions. Any thread attempting to enter a critical region during this time will detect the pending GC flag in `enter()` and follow the slow path, effectively waiting until the GC completes. The storeload barrier is critical to ensure that these two variables -- `_is_gc_request_pending` and the thread-local `_jni_active_critical` -- are accessed in the proper order.

> If you think you need an atomic load here, then it would be needed for in_critical() so just add it there.

`in_critical()` is used only by the owning thread, which has exclusive write access. Therefore, its access does not need to be atomic. However, the reads performed by other threads must be atomic, I believe.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/23367#issuecomment-2641116616