RFR(XS): 8213410: UseCompressedOops @requirement check fails fails on 32-bit system

[Lindenmaier, Goetz]

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.  

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.

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