RFR: 8200235: Generalize jniFastGetField jobject/jweak resolve

[Erik Osterlund]

Hi Kim,

Thanks for the review.

/Erik

On 19 Apr 2018, at 01:55, Kim Barrett <kim.barrett at oracle.com> wrote:

>> On Apr 18, 2018, at 7:14 AM, Erik Österlund <erik.osterlund at oracle.com> 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
> 
> Looks good.
>