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

[Per Liden]

On 05/15/2018 10:25 PM, coleen.phillimore at oracle.com wrote:
> 
> Hi Per,

Hi Coleen,

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

I looks like you're right, rax seems to be used as scratch here. I'll 
run some tests with that and get back.

Thanks!

/Per

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