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

Roman Kennke rkennke at redhat.com
Wed Dec 4 16:45:26 UTC 2019


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