RFR: JDK-8199620: Support for JNI object pinning (original) (raw)

Roman Kennke rkennke at redhat.com
Thu Mar 15 16:57:43 UTC 2018

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::lockcritical() 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::lockcritical() and >unlockcritical(). 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::lockcritical() 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 pinobject(oop) and void unpinobject(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.

More information about the hotspot-gc-dev mailing list