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

Roman Kennke rkennke at redhat.com
Thu Mar 29 13:54:13 UTC 2018

Am 29.03.2018 um 11:29 schrieb Per Liden:

Hi Roman,

On 03/29/2018 12:31 AM, Roman Kennke wrote: 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 (pinobject() / unpinobject()), 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 pinobject() / unpinobject(). 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. The main objection people had with your original patch was that it both grabbed the GCLocker and potentially pinned the object. I think that was perceived as both unnecessary and confusing. However, the design we have now isn't set in stone by any means. How about changing it to this: http://cr.openjdk.java.net/~pliden/supportsobjectpinning/webrev.0 This gives you the ability to ask the collector if pinning is supported, and then choose what to do. I think this should cover the need you have, right?

yes, that looks good. Thank you!

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/5870432a/signature.asc>

More information about the hotspot-gc-dev mailing list