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