RFR: JDK-8199620: Support for JNI object pinning

[White, Derek]

Hi Roman,

Thanks for clearing that up. I didn't consider a GC opting out of the GCLocker protocol.

[BTW, asking as a GC enthusiast, no longer a GC professional]

Is there a danger that the API for these two options of freezing an object (pinning vs. gc lock-out) being too disjoint and asymmetrical?

The GCLocker::lock_critical() API knows the thread requesting the lock, but nothing about the object (address, size, type, etc) while the pinning API knows all of that. 

You could imagine schemes that would take object information into account when deciding to lock-out or to pin. For example, pinning an object that fully occupies a region has no drawbacks, while pinning tiny objects might end up protecting a lot of garbage (and these are cases that would have had short lock-out durations anyway).

I don't see how the proposed API could support this case. But if you consider handling this case over-engineering for the problem at hand, I understand.

 - Derek

> -----Original Message-----
> From: Roman Kennke [mailto:rkennke at redhat.com]
> Sent: Thursday, March 15, 2018 6:21 AM
> To: White, Derek <Derek.White at cavium.com>; hotspot-gc-
> dev at openjdk.java.net
> Subject: Re: RFR: JDK-8199620: Support for JNI object pinning
> 
> Hi Derek,
> 
> I did not provide an implementation for G1 because I am not in the position
> to decide for G1 to use pinning or GCLocker. Nor do I know well
> G1 enough that I could be confident to get it right.
> 
> The implementation should be fairly simple though: in Shenandoah we
> simply set a flag in the heap region containing the object, and when we get
> to build the collection set, skip the regions with the pinned flag set.
> 
> The JNI code should still call GCLocker::lock_critical() and unlock_critical(). As
> long as the GC does not participate in the protocol, this amounts to counting
> up and down.
> 
> It *is* possible to use both mechanisms in one GC even. For a while, in
> Shenandoah, we considered to use pinning for concurrent phases, but use
> the GCLocker protocol in full-GC, but we opted against it, because the
> coordination between GCLocker, control thread, GC workers and mutators
> seemed to error/deadlock-prone, and, TBH, critical arrays are not very
> common and don't seem worth the hassle.
> 
> I hope that clarifies the idea a bit?
> 
> Roman
> 
> 
> 
> > Interesting idea.
> >
> > Is the intention to NOT call GCLocker::lock_critical() in the case when the
> object can be pinned?
> >
> > I can see how this allows pinning a region, but I don't see in this webrev
> where we’re getting any benefit.
> >
> > Thanks!
> >
> >  - Derek
> >
> >> -----Original Message-----
> >> From: hotspot-gc-dev [mailto:hotspot-gc-dev-bounces at openjdk.java.net]
> >> On Behalf Of Roman Kennke
> >> Sent: Wednesday, March 14, 2018 2:51 PM
> >> To: hotspot-gc-dev at openjdk.java.net
> >> Subject: Re: RFR: JDK-8199620: Support for JNI object pinning
> >>
> >> 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/
> >>
> >> And here is the correct patch:
> >>
> >> http://cr.openjdk.java.net/~rkennke/8199620/webrev.01/
> >>
> >> Roman
> >
>