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

[Vladimir Kozlov]

On 4/14/20 1:44 PM, Tom Rodriguez wrote:
> 
> 
> Vladimir Kozlov wrote on 4/3/20 5:41 PM:
>> 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.
> 
> Currently there are 3 places in deoptimization.cpp that handle sparc 32 bit, like 
> http://hg.openjdk.java.net/jdk/jdk/file/tip/src/hotspot/share/runtime/deoptimization.cpp#l1084.  Should remove those and 
> the logic in my new code?  output.cpp appears to have a case as well.

No, we will remove them soon for JEP: 381: Remove the Solaris and SPARC Ports.

I don't want you to add new case.

> 
>>
>> 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.
> 
> I'll add the requested ifdefs.

Good.

Thanks,
Vladimir

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