RFR: Backport JDK-8221435 and JDK-8221629
Roman Kennke
rkennke at redhat.com
Thu May 16 09:04:57 UTC 2019
Hi Aleksey,
>> Webrev:
>> http://cr.openjdk.java.net/~rkennke/backport-jdk11-2019-05-15/webrev.00/
>
> Looks okay. Feels like a risky backport, are we good on testing?
Yeah, looks somewhat risky. I had Zhengyu help with backporting, runs
some tests and programs and eyeball that it does the right thing. I did
myself run the usual tests and some specjvm stuff, and it seems to look
good.
> Metadata does not follow our "[backport] ..." format:
> 8221435: Shenandoah should not mark through weak roots
> 8221629: Shenandoah: Cleanup class unloading logic
Oops:
http://cr.openjdk.java.net/~rkennke/backport-jdk11-2019-05-15/webrev.01/
> Also here:
>
> 460 // And finally finish class unloading
> 461 if (_heap->unload_classes()) {
> 462 _heap->unload_classes_and_cleanup_tables(full_gc);
> 463 } else if (ShenandoahStringDedup::is_enabled()) {
> 464 ShenandoahIsAliveSelector alive;
> 465 BoolObjectClosure* is_alive = alive.is_alive_closure();
> 466 ShenandoahStringDedup::unlink_or_oops_do(is_alive, NULL, false);
> 467 }
>
> Are we sure class unloading and strdedup are exclusive here?
I am not. We should raise this to Zhengyu, he should know. Also, this is
the same in sh/jdk and jdk/jdk, if it needs fixing, let's fix it there
first.
Ok?
Roman
More information about the shenandoah-dev
mailing list