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

Roman Kennke rkennke at redhat.com
Wed Mar 28 22:31:15 UTC 2018

BTW, we do have a working prototype of 'JNI lazy critical functions' or whatever it is called in Shenandoah now, using pinning:

http://hg.openjdk.java.net/shenandoah/jdk/rev/232d819bc452

It looks like it could use the same API that I proposed (pin_object() / unpin_object()), plus an extra method to indicate if the GC would like to use it, and generate the corresponding stub code.

I came to think that it was an unfortunate decision to put the GCLocker stuff in pin_object() / unpin_object(). I think I outlined the reasons elsewhere in this thread, it basically boils down to what I consider unnecessary coupling of the two possible ways to implement JNI critical fluff.

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/20180329/4c687433/signature.asc>

More information about the hotspot-gc-dev mailing list