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