RFR: 8260044: Parallel GC: Concurrent allocation after heap expansion may cause unnecessary full gc

[Kim Barrett]

On Fri, 29 Jan 2021 10:15:28 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Please review this change to ParallelGC to avoid unnecessary full GCs when
>> concurrent threads attempt oldgen allocations during evacuation.
>> 
>> When a GC thread fails an oldgen allocation it expands the heap and retries
>> the allocation.  If the second allocation attempt fails then allocation
>> failure is reported to the caller, which can lead to a full GC.  But the
>> retried allocation could fail because, after expansion, some other thread
>> allocated enough of the available space that the retry fails.  This can
>> happen even though there is plenty of space available, if only that retry
>> were to perform another expansion.
>> 
>> Rather than trying to combine the allocation retry with the expansion (it's
>> not clear there's a way to do so without breaking invariants), we instead
>> simply loop on the allocation attempt + expand, until either the allocation
>> succeeds or the expand fails.  If some other thread "steals" space from the
>> expanding thread and causes its next allocation attempt to fail and do
>> another expansion, that's functionally no different from the expanding
>> thread succeeding and causing the other thread to fail allocation and do the
>> expand instead.
>> 
>> This change includes modifying PSOldGen::expand_to_reserved to return false
>> when there is no space available, where it previously returned true.  It's
>> not clear why it returned true; that seems wrong, but was harmless.  But it
>> must not do so with the new looping behavior for allocation, else it would
>> never terminate.
>> 
>> Testing:
>> mach5 tier1-3, tier5 (tier2-3, 5 do a lot of ParallelGC testing)
>
> src/hotspot/share/gc/parallel/psOldGen.cpp line 192:
> 
>> 190: bool PSOldGen::expand(size_t bytes) {
>> 191:   if (bytes == 0) {
>> 192:     return true;
> 
> I'd prefer if the code would `guarantee` or at least `assert` that `bytes > 0` because returning `true` here seems scary wrt to the loop.
> 
> All code paths seem to cover this situation already, i.e. with `word_size == 0` this should not be called.
> 
> But if you think it's not a big issue, we can keep it. This is pre-existing of course.

Good point.  I will make sure a 0 size never gets here and assert/guarantee, or otherwise figure out what to do.

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

PR: https://git.openjdk.java.net/jdk/pull/2309