-
Bug
-
Resolution: Fixed
-
P4
-
17, 21, 24
-
b07
Concurrent cleanup phase flips heap regions from Trash to Clean. In doing so, Shenandoah control thread acquires a lock per trash region:
https://github.com/openjdk/jdk/blob/45c4eaa5600016d3da5ca769b2519df53835e4f7/src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp#L909-L921
When there are lots of trash regions, this may block allocators significantly.
We need to see if this is a problem in practice, and if so, consider a more lenient locking strategy during the concurrent cleanup.
For example, can we batch the region cleanups, so that we do not acquire lock often? Can we yield more aggressively in concurrent cleanup, without prolonging the GC cycle all that much?
We might separately consider a different strategy for handling trashed regions altogether, i.e. eliminate the concurrent cleanup phase altogether. We can go there if none of the easy fixes for locking work out.
https://github.com/openjdk/jdk/blob/45c4eaa5600016d3da5ca769b2519df53835e4f7/src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp#L909-L921
When there are lots of trash regions, this may block allocators significantly.
We need to see if this is a problem in practice, and if so, consider a more lenient locking strategy during the concurrent cleanup.
For example, can we batch the region cleanups, so that we do not acquire lock often? Can we yield more aggressively in concurrent cleanup, without prolonging the GC cycle all that much?
We might separately consider a different strategy for handling trashed regions altogether, i.e. eliminate the concurrent cleanup phase altogether. We can go there if none of the easy fixes for locking work out.
- links to
-
Commit(master) openjdk/jdk/b32e4a68
-
Commit(master) openjdk/shenandoah-jdk21u/2c22b6a3
-
Review(master) openjdk/jdk/20086
-
Review(master) openjdk/shenandoah-jdk21u/106