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

[Mikael Gerdin]

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

/Mikael

> JDK: http://cr.openjdk.java.net/~redestad/8182487/jdk.00
> 
> On startup tests this reduces executed instructions by ~1-2M, depending on
> how many of the touched classes are loaded.
> 
> Since all uses of this would throw an Error, InternalError or
> ExceptionInInitializerError if the field was missing - effectively
> aborting VM execution - it felt reasonable to simplify the code to
> consistently throw InternalError and remove a number of distracting
> try-catch blocks.
> 
> Thanks!
> 
> /Claes