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

[Leela Mohan Venati]

On Wed, 11 Oct 2023 18:50:14 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Interpreter oop maps are computed lazily during GC root scan and they are expensive to compute.
>> 
>> GCs uses a small hash table per instance class to cache computed oop maps during STW root scan, but not for concurrent root scan.
>> 
>> This patch is intended to enable `OopMapCache` for concurrent GCs.
>> 
>> Test:
>>   tier1 and tier2 fastdebug and release on MacOSX, Linux 86_84 and Linux 86_32.
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup old oop map cache entry after class redefinition

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)


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.

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

PR Review: https://git.openjdk.org/jdk/pull/16074#pullrequestreview-1693431578