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

Per Liden per.liden at oracle.com
Tue Mar 20 10:32:43 UTC 2018

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