RFR: 8048556: Unnecessary GCLocker-initiated young GCs

[Fairoz Matte]

Hi Kim,

Thanks for looking into this.
What you have suggested is totally different approach.
I will investigate more.

Thanks,
Fairoz

> -----Original Message-----
> From: Kim Barrett
> Sent: Thursday, July 25, 2019 5:06 AM
> To: Fairoz Matte <fairoz.matte at oracle.com>
> Cc: Hotspot-Gc-Dev <hotspot-gc-dev at openjdk.java.net>
> Subject: Re: RFR: 8048556: Unnecessary GCLocker-initiated young GCs
> 
> > On Jul 24, 2019, at 7:12 PM, Kim Barrett <kim.barrett at oracle.com> wrote:
> > When G1 has an allocation failure that might require a GC, and it
> > can't satisfy the allocation in some other way (such as by allocating
> > more young regions), then if GCLocker::needs_gc() is true it will
> > stall and wait for the gc-locker gc request to be processed, and then
> > retry the allocation.
> 
> Looking at the history of the G1 code, the present behavior of deferring to a
> pending gc-locker gc request was introduced by
> 
> 7143858: G1: Back to back young GCs with the second GC having a minimally
> sized eden
> 
> Sound familiar?  There are even comments in that CR discussing exactly the
> race described by Tony in JDK-8048556.  Pity other GCs weren't examined for
> the same problem and similarly modified at the same time.
>