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

Thomas Schatzl tschatzl at openjdk.java.net
Fri Jan 29 10:20:46 UTC 2021


On Fri, 29 Jan 2021 08:24:13 GMT, Kim Barrett <kbarrett 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.hpp line 141:

> 139:     do {
> 140:       res = cas_allocate_noexpand(word_size);
> 141:       // Retry failed allocation if expand succeeds.

"... but allocation did not." would be nice to be added to this comment to be complete.

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.

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

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



More information about the hotspot-gc-dev mailing list