RFR: 8343056: C2: Micro-optimize Node lists grow

[Claes Redestad]

On Fri, 25 Oct 2024 09:44:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Seen this in Leyden profiles, but it is a generic issue. The profiles show `Node::grow` and `VectorSet::grow` as hot methods. The methods are small, and since they are implementing doubling-the-array scheme, we often exit early without actually growing. Outlining the actual growing part from the capacity check would allow inlining the common case.
> 
> I'll put some performance data in the comments.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `tier1`

The split between `_size` and `_data_size` is there to allow keeping the same storage when we reset a vectset; when we grow the `_data` array they are grown to the same value, `x`, which is `new_word_capacity` aligned up to the nearest power of two. When not growing `_data` but just reclaiming previously used space in that array we only update `_size` (and zero out any pre-existing data). 

The "clever" thing then happens when `_size` has been reset to 0: `_data` and `_data_size` remain untouched. If later we need to grow back up to some `new_word_capacity`, then if `new_word_capacity` is below `_data_size` we don't need a `REALLOC_ARENA_ARRAY` but just bump `_size` and do some zeroing. Otherwise we do the realloc, then zero. IIRC this was a pretty decent win over the status quo, especially for footprint given how freed memory wasn't actually freed up.

So I don't think there's any pre-existing issue and it looks like this PR does the right thing in the context.

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

PR Comment: https://git.openjdk.org/jdk/pull/21707#issuecomment-2438906443