RFR: JDK-8199620: Support for JNI object pinning

[Erik Österlund]

Hi Roman,

Would there be a problem for you to move the GCLocker stuff into the 
default implementation of object pinning?
I have seen code in the wild (not just Solaris) outside of hotspot that 
exploits critical native. I would feel less worried if a given GC is not 
forced to choose between completely ignoring the GC locking protocol 
(and hence breaking such applications), or only locking.

Thanks,
/Erik

On 2018-03-19 15:23, Roman Kennke wrote:
> Am 14.03.2018 um 19:13 schrieb Roman Kennke:
>> Currently, the Get/Release*Critical() family of functions use the
>> GCLocker protocol to ensure that no JNI critical arrays are in use when
>> a GC pause is entered.
>>
>> Some GCs may instead want to use object pinning and guarantee that the
>> object does not move. For example, this is easy to do with region-based
>> GCs (G1, Shenandoah, ZGC) by simply not including regions with pinned
>> objects in the collection set.
>>
>> The implementation/API that I'm proposing is fairly simple: add two
>> methods oop pin_object(oop) and void unpin_object(oop) to CollectedHeap,
>> and call them from JNI's Get/Release*Critical methods.
>>
>> This approach has been working perfectly fine since a long time in
>> Shenandoah.
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8199620
>> Webrev:
>> http://cr.openjdk.java.net/~rkennke/8199620/webrev.00/
>>
>>
> Ping? Any takers for this?
>
> Roman
>