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

Per Liden per.liden at oracle.com
Thu Mar 15 12:50:33 UTC 2018

Hi Roman,

On 03/14/2018 07:51 PM, 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/ And here is the correct patch: http://cr.openjdk.java.net/~rkennke/8199620/webrev.01/

It seems your patch both grabs the GCLocker and pins the object? I would have assumed that the default implementation of pin_objct() would be the one calling the GCLocker if pinning isn't supported by the GC.

Also, it seems that this patch doesn't take "critical native" functions into account, i.e. those special functions which grabs the GCLocker "lazily" when a safepoint happens. See SafepointSynchronize::check_for_lazy_critical_native().

cheers, Per

Roman

More information about the hotspot-gc-dev mailing list