JDK-8256303 : revisit ObjectMonitor padding between fields
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 16
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2020-11-12
  • Updated: 2025-01-09
  • Resolved: 2025-01-09
Related Reports
Relates :  
JDK-8253064 - monitor list simplifications and getting rid of TSM
Relates :  
JDK-8257975 - Regression ~ 2.5% in SwingMark.Table after JDK-8253064
Description
[~rehn] mentioned this RFE during the JDK-8253064 review: 

 src/hotspot/share/runtime/objectMonitor.hpp
  DEFINE_PAD_MINUS_SIZE(0, OM_CACHE_LINE_SIZE, sizeof(volatile markWord) +
                        sizeof(WeakHandle) + sizeof(AllocationState));
                        sizeof(WeakHandle));
  // Used by async deflation as a marker in the _owner field:


I have test with and without padding, I saw no difference.
Comments
I did some perf runs with compressing the fields (removing the padding) so that the type goes from /* size: 192, cachelines: 3, members: 17, static members: 11 */ to /* size: 104, cachelines: 2, members: 16, static members: 14 */ Which is a little bit smaller. The performance runs were jittery but some were worse (volano linux-x64 10%) some were a little worse, a couple were a tiny bit better but nothing great. From these results, there seems no benefit of a smaller ObjectMonitor, which would be the main motivation of removing the padding. The ObjectMonitor class has extensive comments about avoiding false sharing, particularly with the _owner field. In the class the _owner field is on its own cache line. Combining with other fields that are written along with _owner in TrySpin, like _succ and _SpinDuration shows no benefit for DaCapo xalan and a slight regression. So rejiggering fields to reduce the size of ObjectMonitor to two cache lines seems not worth doing. We don't have any use cases supporting this and don't know of any use cases that would regress if we change this. The only comments in objectMonitor.hpp that seem definitely false are these. They are holdovers from when ObjectMonitors were in type stable memory. -// - Adjacent ObjectMonitors should be separated by enough space to avoid -// false sharing. This is handled by the ObjectMonitor allocation code -// in synchronizer.cpp. Also see TEST_VM(SynchronizerTest, sanity) gtest. Closing this as WNF.
09-01-2025
$ pahole -M -C ObjectMonitor build/linux-x64/images/jdk/lib/server/libjvm.so class ObjectMonitor : public CHeapObj<(MemTag)26> { public: /* class CHeapObj<(MemTag)26> <ancestor>; */ /* 0 0 */ /* XXX last struct has 1 byte of padding */ static class OopStorage * _oop_storage; /* 0 0 */ volatile uintptr_t _metadata; /* 0 8 */ class WeakHandle _object; /* 8 8 */ char _pad_buf0[48]; /* 16 48 */ /* Bitfield combined with previous fields */ static const uintptr_t DEFLATER_MARKER_VALUE = 2; /* 0 0 */ static const uintptr_t ANONYMOUS_OWNER = 1; /* 0 0 */ /* --- cacheline 1 boundary (64 bytes) --- */ volatile void * _owner; /* 64 8 */ volatile uint64_t _previous_owner_tid; /* 72 8 */ char _pad_buf1[48]; /* 80 48 */ /* --- cacheline 2 boundary (128 bytes) --- */ class ObjectMonitor * _next_om; /* 128 8 */ volatile intx _recursions; /* 136 8 */ volatile class ObjectWaiter * _EntryList; /* 144 8 */ volatile class ObjectWaiter * _cxq; /* 152 8 */ volatile class JavaThread * _succ; /* 160 8 */ volatile int _SpinDuration; /* 168 4 */ int _contentions; /* 172 4 */ volatile class ObjectWaiter * _WaitSet; /* 176 8 */ volatile int _waiters; /* 184 4 */ volatile int _WaitSetLock; /* 188 4 */ /* Bitfield combined with previous fields */ static PerfCounter * _sync_ContendedLockAttempts; /* 0 0 */ static PerfCounter * _sync_FutileWakeups; /* 0 0 */ static PerfCounter * _sync_Parks; /* 0 0 */ static PerfCounter * _sync_Notifications; /* 0 0 */ static PerfCounter * _sync_Inflations; /* 0 0 */ static PerfCounter * _sync_Deflations; /* 0 0 */ static class PerfLongVariable * _sync_MonExtant; /* 0 0 */ static int Knob_SpinLimit; /* 0 0 */ /* size: 192, cachelines: 3, members: 17, static members: 11 */ /* paddings: 1, sum paddings: 1 */ };
30-09-2024
I won't have time to investigate this issue for JDK19.
04-05-2022
The dust has not settled on the performance bugs that were logged against JDK-8253064 so making more changes that might make performance worse would not be a good idea. Changing to 'tbd'.
20-05-2021
[~rehn] - Feel free to edit the bug to make things more clear since all I did was copy stuff from the PR.
12-11-2020