RFR: 8331572: Allow using OopMapCache outside of STW GC phases [v2]

[Aleksey Shipilev]

On Thu, 16 May 2024 17:47:16 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Well, tests pass with this change, but now I am thinking if we would eventually run into any lock ranking problem here. At very least `stackwatermark` is ranked above `service`, so we are safe for concurrent GCs. There are only a few locks that are ranked below `service`, so maybe I am overthinking this?
>
> It is a low level lock, I think it'll be ok, you could check out some call stacks but the tests should find these lock inversions if they exist (famous last words).

OK, the "problem" here is that OopMapCache is used from the generic interpreter frame walkers, so I cannot really trace the callers all that well. And it looks to me that capturing the failure in tests would be maddeningly hard: the notification happens very rarely. So we cannot even rely on current tests. 

So I am chickening out from notifying the service thread on this path. Instead, we would rely on service thread timed wait in current mainline. I amended the patch a bit, with the method that can trigger the cleanup. When/if we backport this change to previous releases, we can just hook the call to that method to safepoint cleanup sequence, like we used to have for String/SymbolTable; which would cover the case when service thread is not time-waited yet.

This also likely frees application threads from the cleanup, as cleanup is delegated solely to Service thread now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19229#discussion_r1604830095