RFR: 8276205: Shenandoah: CodeCache_lock should always be held for initializing code cache iteration

Aleksey Shipilev shade at openjdk.java.net
Mon Nov 1 15:55:09 UTC 2021

On Mon, 1 Nov 2021 15:19:30 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> There are few bugs in current implementation:
> 1) No CodeCache_lock is held when initialize code cache iterator at safepoints. This is a problem for concurrent GC, since it can initialize a concurrent code cache iterator while holding CodeCache_lock without safepoint check.
> 2) Does not notify waiters upon completion of iteration at safepoints
> 3) Unnecessary held CodeCache_lock during concurrent code cache iteration.
> Test:
> - [x] hotspot_gc_shenandoah on Linux x86_64
> - [x] hotspot_gc_shenandoah on Linux aarch64

Looks okay. Do we miss `_codecache_snapshot = NULL;` in  `~ShenandoahConcurrentRootScanner`?


Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6192

More information about the hotspot-gc-dev mailing list