RFR: 8200235: Generalize jniFastGetField jobject/jweak resolve

[David Holmes]

Hi Erik,

How does this affect performance? That's the only reason we have these 
'fast' functions.

Thanks,
David

On 18/04/2018 9:14 PM, Erik Österlund wrote:
> 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