RFR: 8351464: Shenandoah: Hang on ShenandoahController::handle_alloc_failure when run test TestAllocHumongousFragment#generational [v4]

Y. Srinivas Ramakrishna ysr at openjdk.org
Wed Mar 19 00:25:07 UTC 2025


On Wed, 12 Mar 2025 17:25:20 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> I believe that is the correct behavior. The mutators are waiting until there is memory available. If mutator B cannot allocate, there is no reason to believe mutator A would be able to allocate. In this case, it is fine for both mutators to wait (even if it means A has to wait an extra cycle).
>
> Thanks for the explanation, re-read the relevant codes I think it make sense, when Mutator B fails to allocate when Concurrent GC is at `op_final_update_refs`, very unlikely there is enough space for Mutator A.

In the case of the stop world collectors, the waiters would form cohorts behind GC count epochs, the idea being that if your failure to allocate happened during a specific epoch, you didn't have sufficient head room to allocate which would then require at least a new GC.

Depending on how we think of the allocation failures interacting with potential freeing of memory by a concurrent collector and the sizes of the allocations being attempted, I could see this going either way. I do realize that a large number of notifications when space is exhausted might extract a cost, but if we are allocating and collecting concurrently, I can imagine that some notion of a monotonically increasing count and notifying all of the early waiters might yield some benefit.

I assume we would need to do collect the dustribution of the allocation failure sizes and the space available to really tell if it makes a difference.

A benchmark such as SPECjbb might be able to tell the difference but I am not sure. Intuition can sometimes mislead in these scenarios, so empirical data might help. Can probably be tackled/investigated in the fullness of time, but I thought it was worth leaving my thoughts here anyway.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23997#discussion_r2002191328


More information about the shenandoah-dev mailing list