RFR 8203466: intermittent crash at jdk.internal.misc.Unsafe::getObjectVolatile (native)
coleen.phillimore at oracle.com
coleen.phillimore at oracle.com
Mon Sep 17 23:47:43 UTC 2018
On 9/17/18 5:17 PM, dean.long at oracle.com wrote:
> Can you move the JavaThread _WIN64 changes to thread_windows_x86.hpp?
Thanks for looking at this. I moved it to the better place:
http://cr.openjdk.java.net/~coleenp/8203466.02/webrev/index.html
Retested with build and ran one test 100 times that failed once.
Thanks,
Coleen
>
> dl
>
> On 9/17/18 5:05 AM, coleen.phillimore at oracle.com wrote:
>>
>>
>> On 9/14/18 4:01 PM, dean.long at oracle.com wrote:
>>> Hi Coleen. In the bug you asked:
>>>
>>> > Why can't we just push rdi and rsi to the stack and restore them?
>>> This code appears to be leaf code so shouldn't care about stack format
>>>
>>> Did that ever get answered? If there is concern about the pushes
>>> and pops canceling out at the end, you could always reserve the
>>> stack space at the beginning, after
>>>
>>> __ enter();
>>>
>>> and then setup_arg_regs/restore_arg_regs would not need to adjust
>>> the stack pointer.
>>
>> The reason I didn't do this is that I couldn't get it to work for all
>> the various call sites. Also, the barrier code is going to need the
>> thread register sometimes which wasn't available. So I went with
>> this. I'm somewhat unclear with how this is called from the c2
>> code. If you want to try this solution, I should probably give up
>> and reassign it to compiler.
>>
>> thanks,
>> coleen
>>
>>>
>>> dl
>>>
>>> On 9/14/18 11:32 AM, coleen.phillimore at oracle.com wrote:
>>>> Summary: Save windows 64 callee saved registers rsi, rdi to Thread,
>>>> save r15, also callee saved to r9
>>>>
>>>> This is done for generated stubs that do arraycopy that need GC
>>>> barrier code because GC assumes that r10 is scratch, since it's
>>>> defined as rscratch1. See bug for more details. Thanks Erik for
>>>> your help and the diagnosis.
>>>>
>>>> Tested with mach5 hs-tier1-7. We don't have a reproduceable test
>>>> case.
>>>>
>>>> open webrev at http://cr.openjdk.java.net/~coleenp/8203466.01/webrev
>>>> bug link https://bugs.openjdk.java.net/browse/JDK-8203466
>>>>
>>>> Thanks,
>>>> Coleen
>>>>
>>>
>>
>
More information about the hotspot-dev
mailing list