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