RFR 8225582: Shenandoah: Enable concurrent evacuation of JNIHandles

Roman Kennke rkennke at redhat.com
Mon Jun 17 20:03:53 UTC 2019


Hi Zhengyu,

> Narrowed CR to only evacuating JNIHandles.

Great!

> Updated Webrev: http://cr.openjdk.java.net/~zgu/JDK-8225582/webrev.02/

Looks good to me. Let Aleksey please also take a look.

Thank you so much! This is cool stuff!

Roman

> 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20190617/ac36643c/signature.asc>


More information about the hotspot-gc-dev mailing list