RFR (jdk8): Backport weakroots stuff to sh/jdk8

Roman Kennke rkennke at redhat.com
Tue May 21 10:01:02 UTC 2019


Hi Zhengyu,

> 1) Should StringTable also belong to WeakProcessor?

It should, but then it would go under a single claimed task together
with the other weak roots there, and we'd loose possible parallel
procesing. I don't know if we want to do this. The other option would be
to extend ShWeakProcessor to handle parallel processing like >=JDK12
WeakProcessor, but I don't think we want to go that way either.

> 2) Why SRP::processor_vm_roots() still contains JNIHandles' weak oops

That is because of the bug that is described in the comment. I don't
dare to touch that ;-)

> 3) SRP::process_all_roots(), should we call WeakProcessor::oops_do()
> instead? when we need to mark through all roots?

We could, but the way I did mirrored jdk11 and up changes. Plus, it is
changed right in the subsequent changeset again to accept a templated
BoolClosure, so doesn't seem worth to change anything.

Roman


> Thanks,
> 
> -Zhengyu
> 
> 
> On 5/17/19 8:29 AM, Roman Kennke wrote:
>> This backports the following two changes from sh/jdk11 -> sh/jdk8:
>>
>> 49: JDK-8221435: Shenandoah should not mark through weak roots
>> 49: JDK-8221629: Shenandoah: Cleanup class unloading logic
>>
>>
>> This is a bit risky and complicated. I added a compat class in
>> shenandoahWeakProcessor.hpp/cpp which is basically the same (with minor
>> removals) as jdk11's weakProcessor.hpp/cpp.
>>
>> Other than that, the weakroots-handling in systemDictionary is a bit
>> different and more messy than in jdk11, which is why I moved those bits
>> into process_strong_roots() (only scans strong sys-dict roots) and
>> process_weak_roots (scans both strong+weak sys-dict roots). This keeps
>> the interfaces the same as in jdk11 and 13 and does the right thing.
>> Unfortunately, we can't drive the strong and weak sys-dict roots
>> separately as it's done in jdk11 and upwards.
>>
>> The stringdedup stuff is also different. I believe I got it right, as
>> much as it is possible.
>>
>> Testing: hotspot_gc_shenandoah looks good. Some point testing in specjvm
>> did not show up any problems. We want to test this thouroughly in our CI
>> before shipping it anywhere.
>>
>> http://cr.openjdk.java.net/~rkennke/backport-jdk8-2019-05-17-1/webrev.00/
>>
>> Ok to go?
>>
>> Roman
>>



More information about the shenandoah-dev mailing list