RFR 8203466: intermittent crash at jdk.internal.misc.Unsafe::getObjectVolatile (native)

[dean.long at oracle.com]

Can you move the JavaThread _WIN64 changes to thread_windows_x86.hpp?

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