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