RFR(S) 8231756: [JVMCI] need support for deoptimizing virtual byte arrays encoding non-byte primitives

Vladimir Kozlov vladimir.kozlov at oracle.com
Sat Apr 4 00:41:46 UTC 2020


I think new code in deoptimize.cpp should be JVMCI specific.

I filed 8242150 for serviceability tests failures in testing. It seems caused by recent changes.

It is weird to see SPARC_32 checks in deoptimization.cpp which we should not have in new code:

#ifdef _LP64
         jlong res = (jlong) *((jlong *) &val);
#else
#ifdef SPARC
       // For SPARC we have to swap high and low words.

We don't support such configuration for eons.

I don't see  where _support_large_access_byte_array_virtualization  is checked. If it is only in Graal then it should be 
guarded by #if.

Thanks,
Vladimir

On 4/3/20 12:37 PM, Tom Rodriguez wrote:
> 
> 
> Vladimir Kozlov wrote on 4/3/20 10:31 AM:
>> Hi Tom,
>>
>> I looked on testing results and one test fails consistently:
>>
>> compiler/jvmci/jdk.vm.ci.hotspot.test/src/jdk/vm/ci/hotspot/test/VirtualObjectLayoutTest.java 
> 
> Sorry that was an old mach5 run and I forgot to update with the new one.  There are some failures but they seem 
> unrelated to me.
> 
> tom
> 
>>
>>
>> Vladimir K
>>
>> On 4/2/20 12:12 PM, Tom Rodriguez wrote:
>>> http://cr.openjdk.java.net/~never/8231756/webrev
>>> https://bugs.openjdk.java.net/browse/JDK-8231756
>>>
>>> This adds support for deoptimizing with non-byte primitive values stored on top of a byte array, similarly to the way 
>>> that a double or long can be stored on top of 2 int fields.  More detail is provided in the bug report and new unit 
>>> tests exercise the deoptimization.  mach5 testing is in progress.
>>>
>>> tom


More information about the hotspot-compiler-dev mailing list