RFR: 8200235: Generalize jniFastGetField jobject/jweak resolve

[Erik Österlund]

Hi,

The fantastic jniFastGetField optimization that we all know and love, 
resolves jobjects/jweaks in native, possibly concurrent with GC safepoints.
Currently it is assumed that it is "safe" to just unmask the potential 
jweak tag, and read the jobject/jweak oop and then speculatively read 
the integer value of that oop (resorting to the signal handler as plan B 
if the heap was concurrently unmapped in the safepoint).

This happens to be safe with existing collectors, but ties very strongly 
to how these oops are processed (as it is normally strictly forbidden by 
mutators to resolve jobject/jweak in safepoints, except of course when 
using it to quickly read integers via JNI).

My proposed solution is to add a try_resolve_jobject_in_native() 
function in the BarrierSetAssembler class, and allow it try to perform 
this resolution, but also give it an option to opt out should it find 
that this jobject/jweak really has to go through the proper VM 
transition. This allows a GC where this is not in general safe (but 
possibly mostly safe depending on GC-specific details such as pointer 
colouring) to override this special in-native jobject/jweak resolution. 
That should make everyone happy I hope.

I provided changes for x86_64, SPARC and AArch64. PPC and S390 do not 
use jniFastGetField, and there are no current plans that I am aware of 
to introduce support for any new GC any time soon to the non-AArch64 arm 
port.

Webrev:
http://cr.openjdk.java.net/~eosterlund/8200235/webrev.00/

Bug:
https://bugs.openjdk.java.net/browse/JDK-8200235

Thanks,
/Erik