RFR: 8200235: Generalize jniFastGetField jobject/jweak resolve

[Erik Österlund]

Hi David,

On 2018-04-18 14:38, David Holmes wrote:
> I should have looked closer first ...
>
> On 18/04/2018 10:30 PM, David Holmes wrote:
>> Hi Erik,
>>
>> How does this affect performance? That's the only reason we have 
>> these 'fast' functions.
>
> Okay at the moment there's no affect as you've just added a potential 
> for change in a future GC that needs it.

Yes, exactly.

> For the ports not addressed they continue to use whatever "hard-wired" 
> approach they use.

Yes.

/Erik

> David
>
>> 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