RFR : JDK-8067744 : XMM/SSE float register values corrupted by JNI_CreateVM call in JRE 8 (Windows)
Dmitry Chuyko
dmitry.chuyko at oracle.com
Fri Oct 28 17:40:36 UTC 2016
Agree, reduced the number of temporary set/clean of cpu features, re-tested.
Webrev: http://cr.openjdk.java.net/~vlivanov/dchuyko/8067744/webrev.02/
-Dmitry
On 10/27/2016 08:58 PM, Berg, Michael C wrote:
> Dmitry:
>
> The bottom two restore contexts can use the immediately prior values and set function:
>
> VM_Version::set_evex_cpuFeatures(); // 466..468 and 497..499
> UseAVX =
> UseSSE =
> // can be removed.
>
> Wrt the values set right before, they have not changed, so you will not need the additional code to change state its already done.
>
> 362..382 can be cleaned up to only require one set of avx/sse and cpuFeatures.
>
> Regards,
> Michael
>
> -----Original Message-----
> From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Vladimir Kozlov
> Sent: Thursday, October 27, 2016 7:19 AM
> To: Dmitry Chuyko <dmitry.chuyko at oracle.com>; hotspot-compiler-dev at openjdk.java.net
> Subject: Re: RFR : JDK-8067744 : XMM/SSE float register values corrupted by JNI_CreateVM call in JRE 8 (Windows)
>
> Looks good.
>
> thanks,
> Vladimir
>
> On 10/27/16 4:11 AM, Dmitry Chuyko wrote:
>> Now generate_get_cpu_info() preserves full xmm7,8,31 in AVX512 case and lower xmm7,8,15 in non-512 case (touched ones).
>>
>> Webrev:
>> http://cr.openjdk.java.net/~vlivanov/dchuyko/8067744/webrev.01/
>>
>> General testing done, and new test passes with the patch on the machine where the bug is reproducible.
>>
>> Also thanks to Vladimir Ivanov for initial test draft and help with webrev.
>>
>> -Dmitry
>>
>> On 10/20/2016 08:25 PM, Vladimir Kozlov wrote:
>>> Hi Dmitry,
>>>
>>> New code does not restore whole 64-bit of xmm7,8,15 in AVX512 case. I
>>> think you can totally separate save/restore for these cases.
>>>
>>> thanks,
>>> Vladimir
>>>
>>> On 10/19/16 4:49 AM, Dmitry Chuyko wrote:
>>>> Summary: Few xmm registers saved on stack and restored in
>>>> generate_get_cpu_info on Windows, a bit different on 2 detection paths.
>>>> New test calls native executable that loads jvm shared library and
>>>> checks if some double values are corrupted. The test reproduced the
>>>> problem on my machine with current devkit but not on Aurora.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8067744
>>>>
>>>> Webrev:
>>>> http://javaweb.us.oracle.com/~dchuyko/webrevs/8067744/webrev.00/
>>>>
>>>> ...............
>>>>
More information about the hotspot-compiler-dev
mailing list