RFR(S) 8231756: [JVMCI] need support for deoptimizing virtual byte arrays encoding non-byte primitives
Vladimir Kozlov
vladimir.kozlov at oracle.com
Wed Apr 15 18:12:53 UTC 2020
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