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.org/pipermail/hotspot-gc-dev/attachments/20190617/ac36643c/signature.asc>
More information about the hotspot-gc-dev
mailing list