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

[Thomas Stuefe]

On Wed, 8 Mar 2023 14:14:49 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> 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?
> 

I thought so too, but you would have to put this into Thread, not JavaThread. And then you'd have to measure performance, since some other data gets pushed into the next cache line. And also, of course, there's false sharing to consider. Lockstack is only used from the current thread, right? So placing it together with other such data may be fine.

Note that using three pointers for this structure is a bit wasteful. You could save one 64-bit slot using ints for stack top and stack limit. But I did not feel like rewriting the using code :-)

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

Yes, probably. I did not run benchmarks though.

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

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