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

Tom Rodriguez tom.rodriguez at oracle.com
Thu Apr 16 00:34:35 UTC 2020


I've updated the webrev in place with the new ifdefs in 
deoptimization.cpp.  The mach5 run was clean apart from known failures.

tom

Vladimir Kozlov wrote on 4/15/20 11:12 AM:
> After discussion with Tom offline I agree to keep his SPARC code because 
> we would need to backport this later into 11u.
> 
> Thanks,
> Vladimir
> 
> On 4/14/20 2:07 PM, Vladimir Kozlov wrote:
>> 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


More information about the hotspot-compiler-dev mailing list