Github user franz1981 commented on the issue: https://github.com/apache/activemq-artemis/pull/1851 @wy96f > Adding unsafe is not trivial and lazySet is enough Probably we have already access to it thanks to `io.netty.util.internal.shaded.org.jctools.util.UnsafeAccess` but it could be tricky to win the karaf validation if used, so I agree :+1: > size() is seldomly called, isn't it? The load yes, but the store is on hot paths (eg put): dropping the cost of a volatile store/full fence could be very welcome on writer side (ig less latencies spikes while writing on the journal). > We can add @sun.misc.Contended in Section class, right It could be tricky like using `sun.misc.Unsafe` directly in the code, due to the proprietary `sun.misc.*`, there are unglier but nonetheless effective ways to do it with plain Java too. For example this is padding the lock fields from the one of the section using the same padding size of `@Contended` ie 128 bytes: ``` abstract static class SectionL0Pad extends StampedLock { long p01, p02, p03, p04, p05, p06, p07; long p10, p11, p12, p13; } // A section is a portion of the hash map that is covered by a single @SuppressWarnings("serial") private static final class Section<V> extends SectionL0Pad { ``` Using [jol](http://openjdk.java.net/projects/code-tools/jol/) it shows: ``` org.apache.activemq.artemis.utils.collections.ConcurrentLongHashMap$Section object internals: OFFSET SIZE TYPE DESCRIPTION VALUE 0 12 (object header) N/A 12 4 int StampedLock.readerOverflow N/A 16 8 long StampedLock.state N/A 24 4 java.util.concurrent.locks.StampedLock.WNode StampedLock.whead N/A 28 4 java.util.concurrent.locks.StampedLock.WNode StampedLock.wtail N/A 32 4 java.util.concurrent.locks.StampedLock.ReadLockView StampedLock.readLockView N/A 36 4 java.util.concurrent.locks.StampedLock.WriteLockView StampedLock.writeLockView N/A 40 4 java.util.concurrent.locks.StampedLock.ReadWriteLockView StampedLock.readWriteLockView N/A 44 4 (alignment/padding gap) 48 8 long SectionL0Pad.p01 N/A 56 8 long SectionL0Pad.p02 N/A 64 8 long SectionL0Pad.p03 N/A 72 8 long SectionL0Pad.p04 N/A 80 8 long SectionL0Pad.p05 N/A 88 8 long SectionL0Pad.p06 N/A 96 8 long SectionL0Pad.p07 N/A 104 8 long SectionL0Pad.p10 N/A 112 8 long SectionL0Pad.p11 N/A 120 8 long SectionL0Pad.p12 N/A 128 8 long SectionL0Pad.p13 N/A 136 4 int Section.capacity N/A 140 4 int Section.size N/A 144 4 int Section.usedBuckets N/A 148 4 int Section.resizeThreshold N/A 152 4 long[] Section.keys N/A 156 4 java.lang.Object[] Section.values N/A Instance size: 160 bytes ``` While the original version layout were: ``` org.apache.activemq.artemis.utils.collections.ConcurrentLongHashMap$Section object internals: OFFSET SIZE TYPE DESCRIPTION VALUE 0 12 (object header) N/A 12 4 int StampedLock.readerOverflow N/A 16 8 long StampedLock.state N/A 24 4 java.util.concurrent.locks.StampedLock.WNode StampedLock.whead N/A 28 4 java.util.concurrent.locks.StampedLock.WNode StampedLock.wtail N/A 32 4 java.util.concurrent.locks.StampedLock.ReadLockView StampedLock.readLockView N/A 36 4 java.util.concurrent.locks.StampedLock.WriteLockView StampedLock.writeLockView N/A 40 4 java.util.concurrent.locks.StampedLock.ReadWriteLockView StampedLock.readWriteLockView N/A 44 4 int Section.capacity N/A 48 4 int Section.size N/A 52 4 int Section.usedBuckets N/A 56 4 int Section.resizeThreshold N/A 60 4 long[] Section.keys N/A 64 4 java.lang.Object[] Section.values N/A 68 4 (loss due to the next object alignment) Instance size: 72 bytes ``` Anyway before doing anything would be necessary to measure any benefits by adding something like that. Our current use case for this collection is on the journal ie "mostly" single writer: the original collection was meant to be used on multiple writers scenarios and probably it could benefit from this technique.
---