RFR 8225582: Shenandoah: Enable concurrent evacuation of JNIHandles and CLDG roots

Roman Kennke rkennke at redhat.com
Mon Jun 17 13:20:15 UTC 2019


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 --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/attachments/20190617/e6580ceb/attachment.htm>


More information about the hotspot-gc-dev mailing list