On Tue, 1 Sep 2026 19:04:39 GMT, Daniel D. Daugherty <[email protected]> wrote:
>> src/hotspot/share/runtime/objectMonitor.hpp line 157: >> >>> 155: // put it on a different cache line than the _object field. The >>> 156: // _object does not change, but it's frequently read during >>> 157: // ObjectMonitorTable lookups. >> >> Again this seems not be be actually known. If _object and _owner were an >> issue then the existing padding would not have worked. > > `_metadata`, formerly known as `_header`, was a hot field and > `_owner` was a hot field. More than a decade ago we added padding > between `_header` and `_owner` and we had targeted microbenchmarks > that proved the padding prevented false sharing on X64 (and SPARC64). > I don't remember testing aarch64 back then. For the more general > benchmarks, I think there were minor improvements at most. > > `_object` was not a hot field and we put it adjacent to `_header` as a lightly > used field. I believe `_object` is still lightly used. With the removal of > `_header` > AKA `_metadata`, we no longer need this padding: > > > DEFINE_PAD_MINUS_SIZE(0, OM_CACHE_LINE_SIZE, sizeof(_object)); Yes `_metadata` contained the old (displaced) header for all locking modes except lightweight for which it contained the hash code. The header was hot, the hash was not. Anyhow now since I removed `_metadata`, `_object` kind of floated up and though it's not really hot, it's not totally cold either. It's read in the `ObjectMonitorTable` lookup code, both from C2 and from the slow path. So you can theorize and claim that if you need to do linear probing to find your monitor in the OMT (because of hash-collisions), you should (theoretically) benefit from having the `_object` and the `_owner` in separate cashe lines. Because you might read the `_object` pointer from a monitor which is not the monitor you're looking for at the same time as the `_owner` is changed by someone else using CAS. Hence the comment about __object does not change, but it's frequently read during ObjectMonitorTable lookups_. But after David's comment I ran some performance tests with, and without the padding, and even though having padding was overall slightly better, it was really nothing to write home about. However removing the padding did improve the performance of the Xalan test on linux-aarch64 by 16%. We (runtime team) had a meeting and decided that `_object` is not hot enough to justify the need for padding, so I will remove it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32573#discussion_r3915081892
