RFR: JDK-8199620: Support for JNI object pinning

[Erik Österlund]

Hi Roman,

Looks good.

Thanks,
/Erik

On 2018-03-19 18:07, 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
>>>
>