RFR: 8048556: Unnecessary GCLocker-initiated young GCs

[Fairoz Matte]

Hi Kim,

Below is the updated webrev specific to GenCollectedHeap and ParalleGC
http://cr.openjdk.java.net/~fmatte/8048556/webrev.01/

Thanks,
Fairoz

> -----Original Message-----
> From: Fairoz Matte
> Sent: Thursday, July 25, 2019 6:03 PM
> To: Kim Barrett <kim.barrett at oracle.com>
> Cc: Hotspot-Gc-Dev <hotspot-gc-dev at openjdk.java.net>
> Subject: RE: RFR: 8048556: Unnecessary GCLocker-initiated young GCs
> 
> 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.
> >