RFR: JDK-8199620: Support for JNI object pinning

[Roman Kennke]

Hi Erik,

thanks for reviewing!

I can do that, but a GC would get the opportunity to do both, or one or
the other in any case. As it stands, the JNI side of the GCLocker
protocol is always executed. If a GC decides to participate in GCLocker
protocol, by calling GCLocker::check_active_before_gc() and related API,
then will get JNI Critical function support, otherwise GCLocker is
basically counting up and down counters.

If it instead wishes to use pinning and ignore JNI critical functions,
then it only needs to override the pinning methods and not participate
in GCLocker, and everything would be fine.

However, I don't mind either way, so here's the alternative:
Diff:
http://cr.openjdk.java.net/~rkennke/8199620/webrev.02.diff/
Full:
http://cr.openjdk.java.net/~rkennke/8199620/webrev.02/

Better?

Thanks,
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
>>
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180319/52199d32/signature.asc>