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

[David Holmes]

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