RFR: JDK-8199620: Support for JNI object pinning

[Roman Kennke]

FWIW, I also filed: https://bugs.openjdk.java.net/browse/JDK-8199868

I think it may be possible to also support JNI critical functions via
pinning. We'd have to pin/unpin all the arguments to such functions.
However, it takes a bit of wrangling to get those arguments to the GC.
I'll look at this at some point in the future.

Thanks, Roman


> Hi Roman,
> 
> Thanks for the new version. Having a centralized decision point in pin_object() should be clearer and open up other options (like only pinning huge arrays).
> 
> - Derek
> 
>> -----Original Message-----
>> From: hotspot-gc-dev [mailto:hotspot-gc-dev-bounces at openjdk.java.net]
>> On Behalf Of Per Liden
>> Sent: Tuesday, March 20, 2018 6:33 AM
>> To: Roman Kennke <rkennke at redhat.com>; Erik Österlund
>> <erik.osterlund at oracle.com>; hotspot-gc-dev at openjdk.java.net
>> Subject: Re: RFR: JDK-8199620: Support for JNI object pinning
>>
>> Hi Roman,
>>
>> This looks much better, thanks for fixing. Reviewed.
>>
>> Btw, as Erik mentioned, there are JavaCritical_ libraries out there on many
>> other platforms (I've seen performance critical stuff like OpenGL library
>> bindings using this... anyway, Shenandoah can opt-out from that)
>>
>> cheers,
>> /Per
>>
>> On 03/19/2018 06:07 PM, Roman Kennke wrote:
>>> 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/20180320/8c94be9c/signature.asc>