[master] RFR: JDK-8303823: [Lilliput] Inline initial LockStack stack

[Roman Kennke]

On Wed, 8 Mar 2023 13:10:35 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Inlines the initial lock stack. This gives us:
> - Much higher chance of cache hits when accessing lockstack slots via lockstack header.
> - postponed malloc call
> - we use actually less memory (not that it matters much) per thread since malloc overhead is at least 48 bytes per allocation, probably more.
> 
> Also increases size of initial stack to two slots, and uses realloc instead of malloc+free when growing stack.

Oh this is nice! I've just done #79 but have closed that now in favour of this PR.

I wonder if it would help even more if we move the LockStack structure somewhere near the beginning of the Thread stucture (similar to the GC state, which we also moved close to the top), which would increase the likelyhood of (L1) cache hit even more?

Ideally, the improvement should show up here: https://github.com/rkennke/fastlockbench (maybe add new benchmark(s) to show that it does?)

Also, consider linking this to a bug entry. I've recently switched to that model (seems like I may not yet have updated jcheck to reflect this), IME this makes it easier to find and track changes.

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

PR: https://git.openjdk.org/lilliput/pull/80