[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.

Patch looks good, but see one comment below, which addresses my own fault. ;-)

Also, I did a quick run with https://github.com/rkennke/fastlockbench and have not seen any regressions (I wouldn't have expected any) but also no significant wins. However, the benchmark is still very simple and doesn't present a workload that pressures caches at all. I would expect that it quickly pulls everything into L1 and go fast from there.

src/hotspot/share/runtime/lockStack.hpp line 38:

> 36:   friend class VMStructs;
> 37: private:
> 38:   static const size_t INITIAL_CAPACITY = 1;

Uh where did the '1' here come from? I certainly wanted to make this value at least 4. 4 seems to capture a majority of locking depths while not being excessively large. With just 1 or 2 I would expect to blow out the caching advantage with a significant number of workloads. This is probably a left-over from when I wanted to test the growing parts, which I haven't reverted. Please be generous and make that initial size 3 or 4, unless you have objections to that.

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

Changes requested by rkennke (Lead).

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