RFR: JDK-8199620: Support for JNI object pinning
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 (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.
>
> 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/supports_object_pinning/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