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

Roman Kennke rkennke at redhat.com
Tue Mar 20 16🔞57 UTC 2018

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 pinobject() 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::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

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

More information about the hotspot-gc-dev mailing list