RFR 8225582: Shenandoah: Enable concurrent evacuation of JNIHandles
Zhengyu Gu
zgu at redhat.com
Mon Jun 17 19:15:14 UTC 2019
Narrowed CR to only evacuating JNIHandles.
Updated Webrev: http://cr.openjdk.java.net/~zgu/JDK-8225582/webrev.02/
Reran hotspot_gc_shenandoah (fastdebug and release)
Okay now?
Thanks,
-Zhengyu
On 6/17/19 9:20 AM, Roman Kennke wrote:
> No worries, I am only thinking out loud ;-)
>
> I am thinking of broader features, which appear to be JNI handles, weak
> stuff (which overlaps with JNI handles via the weak handles), class
> unloading and reference processing.
>
> Is JNI handles needed for class unloading? If not, maybe split out one
> or the other? It appears to me that implementing JNI handles goes better
> with also implementing weak handles? Ultimately it's up to you.
>
> The other stuff I mentioned was only stuff that came up in my mind which
> would be needed for fully concurrent JNI handles, but not related to CLDG.
>
> Roman
>
>
> Roman
>
>
> Am 17. Juni 2019 14:44:31 MESZ schrieb Zhengyu Gu <zgu at redhat.com>:
>
> Hi Roman,
>
> On 6/17/19 4:55 AM, Roman Kennke wrote:
>
> Also, I wonder if we need to deal with CLDG roots here. It seems
> simpler
> to only do JNIHandles, which puts in a lot of required
> infrastructure
> into place. Then we'd also add concurrent marking of JNIHandles
> and call
> that part done. And then we shall probably add weak handles, and
> with
> this we have a basis on which to build CLDG processing. What do
> you think?
>
>
> I am not sure what's your argument here. The purpose of its main task
> (JDK-8225534) is to lay stepping stones for concurrent class unloading,
> and I break out this part for backport purpose, as stated in CR, for the
> releases that do not have nmethod barrier infrastructure (pre JDK13).
> Once we introduce nmethod barrier, the code starts to diverge, so I want
> to put nmethod barrier independent code under this main CR, probably a
> handful of followups. Make senses?
>
> Adding weak handles, is quite straight forward, but let's do it in
> followup CR. If you want to further break down this changeset into two,
> I am fine with that.
>
> This part of changes is stable. I ran specJVM and specJBB with
> -XX:+ClassUnloadingWithConcurrentMark
> -XX:ShenandoahUnloadClassesFrequency=1
>
> Thanks,
>
> -Zhengyu
>
>
> Roman
>
> Breaking out Suspendible workers changes to JDK-8225813 [1]
>
> Updated webrev:
> http://cr.openjdk.java.net/~zgu/JDK-8225582/webrev.01/
>
> Reran hotspot_gc_shenandoah tests (fastdebug and release)
>
> Thanks,
>
> -Zhengyu
>
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8225813
>
>
>
> On 6/14/19 3:00 PM, Roman Kennke wrote:
>
> Maybe makes sense to also break out the suspendible
> workers part?
>
> Roman
>
>
> Am 14. Juni 2019 20:22:52 MESZ schrieb Zhengyu Gu
> <zgu at redhat.com>:
>
> So, is this a review?
>
> Thanks,
>
> -Zhengyu
>
> On 6/14/19 10:25 AM, Roman Kennke wrote:
>
> In this case we're good.
> Roman
>
> Am 14. Juni 2019 15:27:37 MESZ schrieb Zhengyu Gu
> <zgu at redhat.com>:
>
> Hi Roman,
>
> Could you please take a look (Roland's
> comments) or if the CR is
> accurate?
>
> https://bugs.openjdk.java.net/browse/JDK-8225718
>
> Thanks,
>
> -Zhengyu
>
> On 6/12/19 3:11 PM, Roman Kennke wrote:
>
> IIRC (!) the IN_NATIVE barriers in C1 and C2
> are applied to
> getClass()
> intrinsic, which loads and unwraps the Class
> object from an obj
> via the
> Klass*. If the Klass* -> mirror reference is
> part of the CLDG
> roots (I
> don't know if that is the case), then you're
> gonna need the C1
> and C2
> barriers for concurrent evacuation of CLDG
> roots, otherwise you
> might
> leak from-space oops (the Class objects) in the
> getClass()
> intrinsics.
>
>
> Roman
>
> Hi Roman,
>
> This patch does not deal with class unloading,
> it is still
> done at final
> mark pause. What it does, is to move
> evacuate/update refs in
> CLDs from
> SH::evacuate_and_update_roots() to concurrent
> phase, and at
> this point,
> they are strongly reachable.
>
> I will put this through more tests.
>
> Thanks,
>
> -Zhengyu
>
>
>
> On 6/12/19 1:44 PM, Roman Kennke wrote:
>
> I suspect you're gonna need the C1 and C2 IN_NATIVE
> barriers, esp. for
> the CLDG roots. Should be relatively easy to
> wire up the
> LRB barriers
> there (probably ask shade or roland). It will
> be more
> complex to do the
> other parts and return NULL on unreachable
> objects, but
> this is not
> needed yet. When we do, we should probably just
> make it
> call out to
> runtime.
>
> Roman
>
> This is the last sub task of JDK-8225534 [1], that
> moves evacuation of
> JNIHandles and Class Loader Data into concurrent
> phase. This is the
> first step that moves some root processing into
> concurrent phase, and
> this step can be backported to the releases that
> don't support nmethod
> barrier.
>
> 1. Concurrent CLDG root evacuation can not run
> through safepoints, where
> there may also perform CLDG walk, e.g. heap
> iteration. So it requires
> suspendible workers always on, therefore,
> ShenandoahSuspendibleWorkers
> flag is removed, along with related test cases.
> There are many trivial
> changes just because of this flag.
>
> 2. A new concurrent phase "concurrent roots" is
> added to perform
> concurrent JNI and CLDG root evacuation. In Next
> step, it will also
> perform concurrent class unloading and nmethod
> cleanup.
>
> 3) This patch does not address Traversal GC.
>
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8225582
> Webrev:
> http://cr.openjdk.java.net/~zgu/JDK-8225582/webrev.00/
>
> Test:
> hotspot_gc_shenandoah (fastdebug and release)
>
>
> [1]
> https://bugs.openjdk.java.net/browse/JDK-8225582
>
> Thanks,
>
> -Zhengyu
>
>
>
>
> -- Diese Nachricht wurde von meinem
> Android-Gerät mit
> K-9 Mail
> gesendet.
>
>
> --
> Diese Nachricht wurde von meinem Android-Gerät mit K-9
> Mail gesendet.
>
>
>
> --
> Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
More information about the hotspot-gc-dev
mailing list