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

White, Derek Derek.White at cavium.com
Tue Mar 20 15:37:52 UTC 2018

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).

-----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::checkactivebeforegc() 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 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/ >>>> >>>> >>> Ping? Any takers for this? >>> >>> Roman >>> >> > >

More information about the hotspot-gc-dev mailing list