RFR(L) 8228665: Shenandoah: Implementation of Concurrent nmethod evacuation
Roman Kennke
rkennke at redhat.com
Tue Jul 30 16:43:47 UTC 2019
Ok, looks good to me now. Thanks!
Roman
> On 7/29/19 12:25 PM, Roman Kennke wrote:
>> Hi Zhengyu,
>>
>> First glance (will need to do another review pass later):
>>
>> - Does it not also need an aarch64 port?
>> - Does it also work on x86_32?
>
> Yes, but I guess we have to deal with them later. Let's get Linux x86_64
> and Windows 64 in and stabilize them first.
>
>
>> - src/hotspot/share/gc/shenandoah/shenandoahArguments.cpp:
>>
>> Why is that change there?
>>
>> - if (!ClassUnloading ||
>> !FLAG_IS_CMDLINE(ClassUnloadingWithConcurrentMark)) {
>> + if (!ClassUnloading) {
>> log_info(gc)("Consider -XX:+ClassUnloadingWithConcurrentMark if
>> large pause times "
>> "are observed on class-unloading sensitive
>> workloads");
>
> We do want to honor ClassUnloadingWithConcurrentMark's default value, if
> we can do concurrent class unloading.
>
> However, I misplaced this change here, should belong to concurrent class
> unloading changeset.
>
>>
>> - src/hotspot/share/gc/shenandoah/shenandoahClosures.hpp:
>>
>> + BarrierSetNMethod* _bs;
>>
>> Make this BarrierSetNMethod* const _bs. Not sure if it makes a
>> difference perf-wise, but it doesn't hurt and might give the compiler a
>> hint.
>>
> Okay.
>
>> - I guess this partly answers the questions above:
>>
>> +bool ShenandoahConcurrentRoots::can_do_concurrent_nmethods() {
>> +#if defined(_LP64) && defined(X86) && (defined(LINUX) ||
>> defined(_WINDOWS))
>>
>> But why do we deal with LINUX and WINDOWS there? Is there anything OS
>> specific in this codes?
>
> I guess MacOS X and Solaris X86?
>
>>
>> - This change will enable class-unloading on every cycle, is that right?
>>
>
> Right. Again, It should belong to next changeset.
>
> Updated: http://cr.openjdk.java.net/~zgu/JDK-8228665/webrev.01/
>
> Reran hotspot_gc_shenandoah tests
>
> Thanks,
>
> -Zhengyu
>
>
>
>>
>> Thanks a lot for doing this! This is huge!
>> Roman
>>
>>
>>> This patch moves nmethod evacuation and disarming into concurrent phase.
>>> However, nmethod's liveness is still checked at a pause.
>>>
>>> This is the last step before we complete concurrent class unloading,
>>> where we move class loader and nmethod's liveness check into concurrent
>>> evacuation phase.
>>>
>>> Given the scope of this changes, let's bake it in shenandoah/jdk first,
>>> before upstream to jdk/jdk.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8228665
>>> Webrev: http://cr.openjdk.java.net/~zgu/JDK-8228665/webrev.00/
>>>
>>> Test:
>>> hotspot_gc_shenandoah (fastdebug and release)
>>> specjvm (fastdebug and release)
>>>
>>> Thanks,
>>>
>>> -Zhengyu
>>
More information about the shenandoah-dev
mailing list