RFR: 8200235: Generalize jniFastGetField jobject/jweak resolve

[Erik Österlund]

Hi David,

I like the way you think. I thought the same thing. My original wish was 
to get rid of this optimization, hoping that it is no longer necessary. 
So I ran a bunch of benchmarks, hoping that it would show it made no 
difference. To my dismay, I found that on x86 linux, SPECjvm2008 
regressed ~5% without jniFastGetField. I don't know why and did not look 
further into it. I thought that if there is one benchmark where this 
makes a large ish difference, there might be real applications that 
regress as well. And to dodge that debate, I decided to go down the 
route of making it possible for GCs to partially opt out of this madness 
when it is too problematic to maintain the interactions with 
jobject/jweak processing in safepoints. But the existing GCs can do the 
same thing and therefore not regress in performance.

Thanks,
/Erik

On 2018-04-18 14:30, David Holmes wrote:
> 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