RFR: 8202479: Add missing try_resolve_jobject_in_native calls

[Erik Osterlund]

Hi Coleen,

Thanks for the review.

/Erik

> On 7 May 2018, at 16:58, coleen.phillimore at oracle.com wrote:
> 
> 
> 
>> On 5/7/18 10:39 AM, Erik Österlund wrote:
>> Hi Coleen,
>> 
>> Thank you for having a look at this!
>> 
>>> On 2018-05-07 15:51, coleen.phillimore at oracle.com wrote:
>>> 
>>> http://cr.openjdk.java.net/~eosterlund/8202479/webrev.00/src/hotspot/cpu/sparc/jniFastGetField_sparc.cpp.udiff.html 
>>> 
>>> Generally G3 is seen as G3_scratch in sparc code.
>> 
>> Yes, but I noticed that this is not the case in this file, and tried to follow the conventions for this file.
>> 
>>> Why don't both paths have G3 as tmp?
>> 
>> Because one of them retains the old safepoint counter in G3. So if I scratch G3, then a subsequent check that the safepoint counter has not changed from before the access was made, will fail. So in that peculiar case, I had to find a different register. I chose G1, because it is caller saved in both the Java and C ABIs - like G3.
> 
> Ok, looks good then.  I like that you've trashed the register if the branch isn't taken for checking that it's free.
> thanks,
> Coleen
> 
>> 
>> Thanks,
>> /Erik
>> 
>>> thanks,
>>> Coleen
>>> 
>>>> On 5/7/18 4:53 AM, Erik Österlund wrote:
>>>> Ping!
>>>> 
>>>>> On 2018-05-01 17:00, Erik Österlund wrote:
>>>>> Hi,
>>>>> 
>>>>> There are some missing calls to try_resolve_jobject_in_native for the jni fast get field optimization.
>>>>> 
>>>>> On x86_64, it is used for T_BOOLEAN, T_BYTE, T_CHAR, T_SHORT, T_INT and T_LONG, but is missing for T_FLOAT and T_DOUBLE.
>>>>> On SPARC, it is used for T_BOOLEAN, T_BYTE, T_CHAR, T_SHORT, T_INT, but is missing for T_LONG, T_FLOAT and T_DOUBLE.
>>>>> On AArch64, it is used for all types.
>>>>> 
>>>>> Here is a patch to add the missing calls to try_resolve_jobject_in_native.
>>>>> 
>>>>> Webrev:
>>>>> http://cr.openjdk.java.net/~eosterlund/8202479/webrev.00/
>>>>> 
>>>>> Bug:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8202479
>>>>> 
>>>>> Thanks,
>>>>> /Erik
>>>> 
>>> 
>> 
>