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

[David Holmes]

On 9/11/2018 12:21 AM, Lindenmaier, Goetz wrote:
> 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.

UseCompressedOops is not the only flag that only exists in a certain 
kind of build.

But it is this distinction between present and not-present that I'm 
trying to clarify. You can imagine scenarios both for when you don't 
care if the flag exists, and you do.

> 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.

The point of the @requires and its use of VMProps is to test what flags 
have been passed through to the jtreg invocation. It is up to each test 
to understand if it has any dependencies/conflicts with the flags that 
might be passed and whether it impacts them via explicit use of othervm 
or by launching a separate VM directly in the test.

Cheers,
David

> 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