RFR: 8200235: Generalize jniFastGetField jobject/jweak resolve (original) (raw)

David Holmes david.holmes at oracle.com
Wed Apr 18 12:30:13 UTC 2018

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 tryresolvejobjectinnative() 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 x8664, 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

More information about the hotspot-dev mailing list