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

Erik Österlund erik.osterlund at oracle.com
Mon Mar 19 16:04:26 UTC 2018

Hi 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