RFR: JDK-8199620: Support for JNI object pinning

[Roman Kennke]

The calls into GCLocker in jni.cpp are only the JNI part of the protocol. The GC must still do its part to initiate the actual wait-and-retry when no threads are in critical region. It is conceivable with the proposed API that the GC sees a small object in a region of otherwise garbage and elects to participate in GCLocker instead of pinning the object / region, on a case-by-case basis.

What I'm not sure about is support for CriticalJNINatives... This does not seem easily possible without GCLocker. But I would consider that optional.

Thanks, Roman


Am 15. März 2018 16:38:56 MEZ schrieb "White, Derek" <Derek.White at cavium.com>:
>Hi Roman,
>
>Thanks for clearing that up. I didn't consider a GC opting out of the
>GCLocker protocol.
>
>[BTW, asking as a GC enthusiast, no longer a GC professional]
>
>Is there a danger that the API for these two options of freezing an
>object (pinning vs. gc lock-out) being too disjoint and asymmetrical?
>
>The GCLocker::lock_critical() API knows the thread requesting the lock,
>but nothing about the object (address, size, type, etc) while the
>pinning API knows all of that. 
>
>You could imagine schemes that would take object information into
>account when deciding to lock-out or to pin. For example, pinning an
>object that fully occupies a region has no drawbacks, while pinning
>tiny objects might end up protecting a lot of garbage (and these are
>cases that would have had short lock-out durations anyway).
>
>I don't see how the proposed API could support this case. But if you
>consider handling this case over-engineering for the problem at hand, I
>understand.
>
> - Derek
>
>> -----Original Message-----
>> From: Roman Kennke [mailto:rkennke at redhat.com]
>> Sent: Thursday, March 15, 2018 6:21 AM
>> To: White, Derek <Derek.White at cavium.com>; hotspot-gc-
>> dev at openjdk.java.net
>> Subject: Re: RFR: JDK-8199620: Support for JNI object pinning
>> 
>> 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
>> >
>> 

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.