RFR: JDK-8283674: Pad ObjectMonitor allocation size to cache line size

[Claes Redestad]

On Fri, 25 Mar 2022 09:02:28 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> See discussion under [1].
> 
> Since the libc malloc allocator may place ObjectMonitor instances adjacent to each other, we should pad the size of ObjectMonitor to fill a whole cache line to prevent false sharing between adjacent OMs.
> 
> [1] https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2022-March/054187.html

To add a little context to what Dan said above: the performance work I was involved in was done long before [JDK-8253064](https://bugs.openjdk.java.net/browse/JDK-8253064) when the number of extant object monitors were able to grow much larger than the number of monitors that are in use (each thread held a cache of up to 1024 unused OMs) and the memory allocated for them was effectively never returned. So there was a bigger worry that larger OMs would significantly and sneakily affect memory memory use (sneakily in that it won't show up early on in an application's life, but might see sudden expansion as applications go through load spikes and such..) 

Thanks to the work on JDK-8253064 there's way less reason to be worried about the size of individual OMs, and if you can somehow demonstrate that adding back some of the padding that was removed then I have no reservations.

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

PR: https://git.openjdk.java.net/jdk/pull/7955