RFR: 8322630: Remove ICStubs and related safepoints

[Thomas Schatzl]

On Thu, 25 Jan 2024 06:43:59 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> On linux, the time for "Purge Unlinked NMethods" goes down when I comment out delete ic->data(); and ignore the memory leak. (MacOS seems to be ok with it.)
>Adding trace code to purge_ic_callsites shows that we often have 0 or 2 ICData instances, sometimes up to 30 ones.
>It would be good to think a bit about the allocation scheme. Some ideas would be

>    Allocate ICData in an array per nmethod instead of individually. That should help to some degree and also improve data locality (and hence cache efficiency). Would also save iterating over the relocations when purging unlinked NMethods. It's not very complex.
>    Instead of freeing ICData instances, we could enqueue them and either reuse or free them during a concurrent phase. This may be a bit complicated. Not sure if it's worth it.
>    Allocate in Metaspace?

Sorry for being unresponsive for a bit.

Yes, the issue is the new `delete ic->data()`; but also the iteration over the relocinfo here is almost as expensive in my tests.

So the idea to allocate ICData in a per nmethod basis (and actually some other existing C heap allocations that are also `delete`d in this phase) seems the most promising to me.

Also came up with the other suggestions, but I think that first one seems best to me at first glance. I did not really like the second because enqueuing adds another indirection for first gathering all of them and then separately free them.

Metaspace is something I do not know that well to comment on that option.

I am open to moving this improvement, if it is not easy to do, into a separate CR.

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

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