RFR: 8202978: Incorrect tmp register passed to MacroAssembler::load_mirror()

[coleen.phillimore at oracle.com]

Hi Per,

It's calling a static native function so might not be totally 
performance neutral.
It looks like rax is scratch there.  Can you try that?   Sorry I didn't 
figure out that r11 is rscratch2.

Thanks,
Coleen

On 5/11/18 8:48 AM, Per Liden wrote:
> On 05/11/2018 02:32 PM, Vladimir Kozlov wrote:
>> Looks good.
>
> Thanks Vladimir!
>
>> Is this new code? Should we backport it otherwise?
>
> Yes, this is new code, i.e. it's not in JDK 10 or older. Also, it just 
> so happens that this bug doesn't affect the existing GC, only GCs 
> which do load barriers (like ZGC), which is why it hasn't been caught 
> before.
>
> /Per
>
>>
>> Thanks,
>> Vladimir K
>>
>> On 5/11/18 1:31 AM, Per Liden wrote:
>>> On x86, MacroAssembler::load_mirror() defaults to using rscratch2 as 
>>> tmp register, unless something else is specified. In 
>>> TemplateInterpreterGenerator::generate_native_entry() we call 
>>> load_mirror(), but the rscratch2 register is already in use in this 
>>> context, which obviously leads to problems. This is not a 
>>> performance critical path, so we should just pass noreg as the tmp 
>>> register.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8202978
>>> Webrev: http://cr.openjdk.java.net/~pliden/8202978/webrev.0
>>>
>>> Testing: passes hs-tier{1,2}
>>>
>>> /Per