RFR: JDK-8199620: Support for JNI object pinning

[Roman Kennke]

Hi Derek,

I did not provide an implementation for G1 because I am not in the
position to decide for G1 to use pinning or GCLocker. Nor do I know well
G1 enough that I could be confident to get it right.

The implementation should be fairly simple though: in Shenandoah we
simply set a flag in the heap region containing the object, and when we
get to build the collection set, skip the regions with the pinned flag set.

The JNI code should still call GCLocker::lock_critical() and
unlock_critical(). As long as the GC does not participate in the
protocol, this amounts to counting up and down.

It *is* possible to use both mechanisms in one GC even. For a while, in
Shenandoah, we considered to use pinning for concurrent phases, but use
the GCLocker protocol in full-GC, but we opted against it, because the
coordination between GCLocker, control thread, GC workers and mutators
seemed to error/deadlock-prone, and, TBH, critical arrays are not very
common and don't seem worth the hassle.

I hope that clarifies the idea a bit?

Roman



> Interesting idea.
> 
> Is the intention to NOT call GCLocker::lock_critical() in the case when the object can be pinned?
> 
> I can see how this allows pinning a region, but I don't see in this webrev where we’re getting any benefit.
> 
> Thanks!
> 
>  - Derek
> 
>> -----Original Message-----
>> From: hotspot-gc-dev [mailto:hotspot-gc-dev-bounces at openjdk.java.net]
>> On Behalf Of Roman Kennke
>> Sent: Wednesday, March 14, 2018 2:51 PM
>> To: hotspot-gc-dev at openjdk.java.net
>> Subject: Re: RFR: JDK-8199620: Support for JNI object pinning
>>
>> 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/
>>
>> And here is the correct patch:
>>
>> http://cr.openjdk.java.net/~rkennke/8199620/webrev.01/
>>
>> 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/20180315/1508087e/signature.asc>