RFR(XS): 8213410: UseCompressedOops @requirement check fails fails on 32-bit system
Boris Ulasevich
boris.ulasevich at bell-sw.com
Wed Nov 7 08:06:43 UTC 2018
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