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