RFR: 8317466: Enable interpreter oopMapCache for concurrent GCs [v2]

[Zhengyu Gu]

On Mon, 23 Oct 2023 20:53:39 GMT, Leela Mohan Venati <duke at openjdk.org> wrote:

> Before of this change, VM_Operations which enabled "is_gc_active" and walks stack to collect roots had a call to OopMapCache::cleanup_old_entries() in its corresponding doit_epilogue(). This is to free the old entries which are collected during safepoint.
> 
> Now scope of the change isn't clear.
> 
> We seem to extend them to concurrent GCs during their concurrent phases (Not just safepoints of concurrent GCs). Calling OopMapCache::cleanup_old_entries() in doit_epilogue() would effectively cleanup old entries accumulated during concurrent phase of the GC and also during safepoint.
> 
> But change also allows java threads to accumulate old entries. When/Who calls cleanup_old_entries() in this case ? These needs to wait until future GC which does cleanup in doit_epilogue(). However, at least theoretically, we can have large time windows without GCs. Old entries accumulated by java threads can be seen as a leak (until next GC)
> 
Yes, it could accumulate a few. But from what I saw, there are not many. They are cleanup by:
- Serial, Parallel and G1: any `VM_GC_Operation`s
- ZGC: any `VM_ZOperation`s
- Shenandoah: I should have added `OopMapCache::cleanup_old_entries()` in `VM_ShenandoahOperation`, where should help jdk11u backport.

> A separate thought to make change simpler. Can cleanup_old_entries become a [list of Cleanup tasks](https://github.com/openjdk/jdk/blob/8d9a4b43f4fff30fd217dab2c224e641cb913c18/src/hotspot/share/runtime/safepoint.hpp#L72) VM thread does during cleanup phase.

No. There is no point to add safepoint latency when it can not done outside of safepoint.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16074#issuecomment-1776227534