RFR: 8322630: Remove ICStubs and related safepoints

[Thomas Schatzl]

On Fri, 19 Jan 2024 06:25:20 GMT, Erik Österlund <eosterlund at openjdk.org> wrote:

> ICStubs solve an atomicity problem when setting both the destination and data of an inline cache. Unfortunately, it also leads to occasional safepoint carpets when multiple threads need to ICRefill the stubs at the same time, and spurious GuaranteedSafepointInterval "Cleanup" safepoints every second. This patch changes inline caches to not change the data part at all during the nmethod life cycle, hence removing the need for ICStubs.
> 
> The new scheme is less stateful. Instead of adding and removing callsite metadata back and forth when transitioning inline cache states, it installs all state any shape of call will ever need at resolution time in a struct that I call CompiledICData. This reduces inline cache state changes to simply changing the destination of the call, and it doesn't really matter what state transitions to what other state.
> 
> With this patch, we get rid of ICStub and ICBuffer classes and the related ICRefill and almost all Cleanup safepoints in practice. It also makes the inline cache code much simpler.
> 
> I have tested the changes from tier1-7, and run through full aurora performance tests.

I think the `ccstress` application attached to https://bugs.openjdk.org/browse/JDK-8315503 should show the issue (not tested - today I've been busy completing a JDK 22 bugfix).

The actual application I'm using is specjbb2015 that basically executes that ccstress application as a java agent in parallel to jbb2015 just for extra load. I can certainly give you that.

Tomorrow I will also spend some time investigating this change a bit more (also on aarch64 - I think other factors may easily outweigh this difference), but I think that @TheRealMDoerr is correct about the C heap allocator just being very slow.
Glibc being slow is a "known" issue, other `delete` calls in class unloading already take a significant chunk of that phase, so there is already some interest (from me) to do something about them.

There are ideas how to handle this, one of them being moving this (and other) `delete` calls into some concurrent phase somehow (in addition to making metaspace purging concurrent). That would obviously only help G1 though, so maybe there is some better option.

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

PR Comment: https://git.openjdk.org/jdk/pull/17495#issuecomment-1908684867