RFR: JDK-8199620: Support for JNI object pinning

[White, Derek]

Hi Roman,

Thanks for the new version. Having a centralized decision point in pin_object() should be clearer and open up other options (like only pinning huge arrays).

- Derek

> -----Original Message-----
> From: hotspot-gc-dev [mailto:hotspot-gc-dev-bounces at openjdk.java.net]
> On Behalf Of Per Liden
> Sent: Tuesday, March 20, 2018 6:33 AM
> To: Roman Kennke <rkennke at redhat.com>; Erik Österlund
> <erik.osterlund at oracle.com>; hotspot-gc-dev at openjdk.java.net
> Subject: Re: RFR: JDK-8199620: Support for JNI object pinning
> 
> 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::check_active_before_gc() 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 pin_object(oop) and void unpin_object(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
> >>>
> >>
> >
> >