RFR: 8235337: Shenandoah: Fix evac OOM scoping for concurrent class unloading

Zhengyu Gu zgu at redhat.com
Wed Dec 4 19:00:48 UTC 2019

Fix is good.



On 12/4/19 11:45 AM, Roman Kennke wrote:
> CI threw up a bunch of asserts claiming that OOM scope hasn't been
> set-up correctly on an evacuating code path. I believe I have tracked
> this down to ShenandoahUnlinkTask calling into runtime and coming back
> with a native LRB call that is not procted with OOM scope. See more info
> in the bug report:
> https://bugs.openjdk.java.net/browse/JDK-8235337
> The fix would be to move the OOM scope all the way up to the worker
> entry in ShenandoahUnlinkTask::work(), and remove lower scopes (because
> they are not reentrant):
> http://cr.openjdk.java.net/~rkennke/JDK-8235337/webrev.01/
> Testing: hotspot_gc_shenandoah
> specjvm with +aggressive and +ShenandoahOOMDuringEvacALot (which
> triggered the original problem).
> Ok?
> Roman

More information about the hotspot-gc-dev mailing list