RFR: JDK-8199620: Support for JNI object pinning

[Per Liden]

On 03/29/2018 03:54 PM, Roman Kennke wrote:
> Am 29.03.2018 um 11:29 schrieb Per Liden:
>> Hi Roman,
>>
>> On 03/29/2018 12:31 AM, Roman Kennke wrote:
>>> BTW, we do have a working prototype of 'JNI lazy critical functions' or
>>> whatever it is called in Shenandoah now, using pinning:
>>>
>>> http://hg.openjdk.java.net/shenandoah/jdk/rev/232d819bc452
>>>
>>> It looks like it could use the same API that I proposed (pin_object() /
>>> unpin_object()), plus an extra method to indicate if the GC would like
>>> to use it, and generate the corresponding stub code.
>>>
>>> I came to think that it was an unfortunate decision to put the GCLocker
>>> stuff in pin_object() / unpin_object(). I think I outlined the reasons
>>> elsewhere in this thread, it basically boils down to what I consider
>>> unnecessary coupling of the two possible ways to implement JNI critical
>>> fluff.
>>
>> The main objection people had with your original patch was that it both
>> grabbed the GCLocker _and_ potentially pinned the object. I think that
>> was perceived as both unnecessary and confusing. However, the design we
>> have now isn't set in stone by any means. How about changing it to this:
>>
>> http://cr.openjdk.java.net/~pliden/supports_object_pinning/webrev.0
>>
>> This gives you the ability to ask the collector if pinning is supported,
>> and then choose what to do. I think this should cover the need you have,
>> right?
>>
> 
> yes, that looks good. Thank you!

Good! I'll file an RFE and send it out for review on hotspot-dev.

/Per

> 
> Roman
> 
>