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

[Albert Mingkun Yang]

On Fri, 14 Feb 2025 23:44:25 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge branch 'master' into gclocker
>>  - review
>>  - Merge branch 'master' into gclocker
>>  - gclocker
>
> src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 385:
> 
>> 383: 
>> 384: HeapWord* ParallelScavengeHeap::mem_allocate_old_gen(size_t size) {
>> 385:   if (!should_alloc_in_eden(size) || GCLocker::is_active()) {
> 
> I don't understand why we are checking is_active() here.  The value is not reliable if we aren't at a safepoint, and iterating over all threads seems expensive.

The intention is to avoid blocking java threads if possible, but there is no fundamental reason why it has be to this way. I have removed it for simpler (or less magical) code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23367#discussion_r1957098815