[10] RFR: 8182487: Add Unsafe.objectFieldOffset(Class, String)

[Mikael Gerdin]

Hi Claes,

On 2017-06-21 14:32, Claes Redestad wrote:
> Hi Mikael,
> 
> On 06/21/2017 09:49 AM, Mikael Gerdin wrote:
>> Hi Claes,
>>
>> This looks like a good change but I do have some comments on exception 
>> management details.
>>
>> On 2017-06-20 15:14, Claes Redestad wrote:
>>> Hi,
>>>
>>> as a startup optimization, we can avoid a number of reflective 
>>> operations on
>>> variouscore classes by adding a specialized objectFieldOffset method 
>>> taking
>>> Class and String rather than Field:
>>>
>>> Webrev: https://bugs.openjdk.java.net/browse/JDK-8182487
>>> Hotspot: http://cr.openjdk.java.net/~redestad/8182487/hotspot.00
>>
>> The UNSAFE_ENTRY macro expands to among other things a transition into 
>> _thread_in_vm (normal JNI code runs as _thread_in_native).
>> When running "in VM" we are (fairly) free to do things such as 
>> resolving JNI handles and looking at the fields of classes so that is 
>> clearly correct for find_field_offset.
>> For code running in VM we have to avoid invoking functions in the 
>> public JNI api since those entry points perform transitions from 
>> native to VM, causing assertions to fire and other potentially nasty 
>> stuff happening.
>>
>> Instead of reusing the throw_new helper function you should do 
>> something similar to the other find_field_offset function and do
>>
>> if (offset < 0) {
>>   THROW_0(vmSymbols::java_lang_InternalError());
>> }
>> return field_offset_from_byte_offset(offset);
> 
> makes sense.
> 
> I've also cleaned up and removed static blocks as suggested by
> Brent Christian, and even though I reverted the throw_new method
> back to its original place I think it's reasonable to clean it up as
> suggested by Christian Thalinger:
> 
> JDK: http://cr.openjdk.java.net/~redestad/8182487/jdk.01/
> Hotspot: http://cr.openjdk.java.net/~redestad/8182487/hotspot.01/

HotSpot change looks good to me.
/Mikael


> 
> Thanks!
> 
> /Claes