RFR(S): 8179953: [ppc] TLABWasteIncrement not loaded correctly

Lindenmaier, Goetz goetz.lindenmaier at sap.com
Fri May 12 06:45:32 UTC 2017


Hi David, 

the broken code is protected by 
   if (allow_shared_alloc) {
which evaluates to true with ParallelGC but not with G1GC.
It might be true with other GCs, too, but the design of 
JVMOptionsUtils:addNameDependency() is quite simple,
and I just did it as for other flags.
I could put in more logic into that case there, like
   if (GCType == G1GC || GCTyep == ... ) {
         option.addPrepend("-XX:+UseParallelGC");
   }
enumerating all GCs that don't support TLABWastIncrement.
But I thought one test case for the flag is fine.  The way it is
we missed the error, so I would like to fix the test.

Yes, in JVMOption I must exclude setting G1GC else I get 
an error claiming that two different GCs are set.

Best regards,
  Goetz.




> -----Original Message-----
> From: David Holmes [mailto:david.holmes at oracle.com]
> Sent: Wednesday, May 10, 2017 5:19 AM
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; hotspot-runtime-
> dev at openjdk.java.net
> Subject: Re: RFR(S): 8179953: [ppc] TLABWasteIncrement not loaded
> correctly
> 
> Hi Goetz,
> 
> On 10/05/2017 12:56 AM, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > Please review this change.  As I fix the test, I please need a sponsor.
> > http://cr.openjdk.java.net/~goetz/wr17/8179953-ppc_flag/webrev.01/
> 
> I'm unclear on the test changes. It isn't obvious to me that
> TLABWasteIncrement is a ParallelGC only flag. By adding that as an
> additional flag you then had to exclude adding the GCType (if any GC
> selector is given) to avoid conflicting options - is that right?
> 
> Thanks,
> David
> 
> > On ppc, the mentioned flag is loaded as a 16 bit immediate, while it can
> have
> > bigger values.
> > I also adapt TestOptionWithRanges, which did not show the bug because
> > the flag has no effect with G1.
> >
> > Best regards,
> >   Goetz.
> >
> >


More information about the hotspot-runtime-dev mailing list