RFR(XS): 8213410: UseCompressedOops @requirement check fails fails on 32-bit system
Lindenmaier, Goetz
goetz.lindenmaier at sap.com
Thu Nov 8 14:21:29 UTC 2018
Hi David,
> > must remember about the special case of this flag.
>
> Any developer writing any test that uses VM flags has to know whether
> the flag is valid for all configurations/platforms etc.
I'm not referring to the special case in the VM, but to the
special case in VMProps.
The developer here needs to know that for vm.opt.final.UseCompressedOops
he obtains three values 'true', 'false' or 'null', while
for other flags it is only two values.
Overall, the whole VMProp vm.opt.final.* seems inconsistent to me.
As I understand it returns how the value is set in the VM parsing the
test script, not how it is set in the vm running the test, which is
started for main/othervm.
E.g., if I add -Xmx40g to the main/othervm command, UseCompressedOops
will be off in that VM, although vm.opt.final.UseCompressedOops was true in
first place.
Best regards,
Goetz.
> -----Original Message-----
> From: David Holmes <david.holmes at oracle.com>
> Sent: Donnerstag, 8. November 2018 13:50
> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>; Boris Ulasevich
> <boris.ulasevich at bell-sw.com>; hotspot-dev at openjdk.java.net
> Subject: Re: RFR(XS): 8213410: UseCompressedOops @requirement check fails
> fails on 32-bit system
>
> On 8/11/2018 9:35 PM, Lindenmaier, Goetz wrote:
> > Hi,
> >
> > I also ran into this issue and designed this as fix for it:
> > http://cr.openjdk.java.net/~goetz/wr18/8213527-32bit_tests/01/
> > I withdraw this part of my change :)
> >
> > I think handling this in VMProps is the better solution.
> > Else every developer that implements a test with UseCompressedOops
> > must remember about the special case of this flag.
>
> Any developer writing any test that uses VM flags has to know whether
> the flag is valid for all configurations/platforms etc.
>
> > But I also think a generic solution as you propose, Boris, does not
> > makes sense. You can not handle this generically.
> > Imagine the flag was DontUseCompressedOops. By just setting
> > it to false would be the wrong thing to do.
> > Therefore I think we must special case on the very flag that causes
> > the issue.
>
> Based on what you are testing you have to understand the role of the
> flag. I agree that a test that requires a flag to be disabled probably
> does not do as intended if the flag is not present at all. But the test
> writer has to understand that. Just think of GC specific flags, or C2
> versus C1 flags.
>
> David
>
> > Maybe we should add other lp64_* flags right in this change?
> > At least UseCompressedClassPointers?
> >
> > Best regards,
> > Goetz
> >
> >
> >
> >> -----Original Message-----
> >> From: hotspot-dev <hotspot-dev-bounces at openjdk.java.net> On Behalf Of
> >> Boris Ulasevich
> >> Sent: Mittwoch, 7. November 2018 09:07
> >> To: David Holmes <david.holmes at oracle.com>; hotspot-
> dev at openjdk.java.net
> >> Subject: Re: RFR(XS): 8213410: UseCompressedOops @requirement check
> fails
> >> fails on 32-bit system
> >>
> >> Hi David,
> >>
> >> Yes, at first glance it is weird. We have actually three states for
> >> vm.opt.final.UseCompressedOops: true, false and null. Null means "not
> >> applicable" - when current VM does not support the option with the given
> >> name. Here is another approach for the issue (I am not sure it is a good
> >> one):
> >> http://cr.openjdk.java.net/~bulasevich/8213410/webrev.01/
> >>
> >> thank you,
> >> Boris
> >>
> >> On 07.11.2018 1:36, David Holmes wrote:
> >>> Hi Boris,
> >>>
> >>> I'm somewhat perplexed as to what the difference is between:
> >>>
> >>> @requires vm.opt.final.UseCompressedOops
> >>>
> >>> and
> >>>
> >>> @requires vm.opt.final.UseCompressedOops == true
> >>>
> >>> if they are indeed different then that seems to be a bug in the
> >>> requirement handling in the jtreg support code.
> >>>
> >>> I'm also wondering whether any such requirement should always be
> >>> proceeded by a check for 64-bits?
> >>>
> >>> Otherwise I would expect
> >>>
> >>> @requires vm.opt.final.UseCompressedOops
> >>>
> >>> to be false in 32-bit, so again a problem with the jtreg support code.
> >>>
> >>> Thanks,
> >>> David
> >>>
> >>> On 7/11/2018 12:43 AM, Boris Ulasevich wrote:
> >>>> Hi all,
> >>>>
> >>>> Please review this patch to fix jtreg @requires
> >>>> vm.opt.final.UseCompressedOops flag evaluation fail reproduced on
> >>>> ARM32: "invalid boolean value: null for expression
> >>>> vm.opt.final.UseCompressedOops".
> >>>>
> >>>> http://cr.openjdk.java.net/~bulasevich/8213410/webrev.00/
> >>>> https://bugs.openjdk.java.net/browse/JDK-8213410
> >>>>
> >>>> The fix was checked on ARM32 (tests disabled) and AARCH64 (works Ok by
> >>>> default, and becomes disabled with
> >>>> -javaoptions:"-XX:-UseCompressedOops" jtreg option).
> >>>>
> >>>> Thanks,
> >>>> Boris Ulasevich
More information about the hotspot-dev
mailing list