[
https://issues.apache.org/jira/browse/ARTEMIS-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16376838#comment-16376838
]
ASF GitHub Bot commented on ARTEMIS-1702:
-----------------------------------------
Github user michaelandrepearce commented on a diff in the pull request:
https://github.com/apache/activemq-artemis/pull/1895#discussion_r170587405
--- Diff:
artemis-commons/src/main/java/org/apache/activemq/artemis/utils/collections/ConcurrentLongHashMap.java
---
@@ -196,11 +202,13 @@ public ConcurrentLongHashSet keysLongHashSet() {
// A section is a portion of the hash map that is covered by a single
@SuppressWarnings("serial")
private static final class Section<V> extends StampedLock {
+
+ private static final AtomicIntegerFieldUpdater<Section>
CAPACITY_UPDATER = AtomicIntegerFieldUpdater.newUpdater(Section.class,
"capacity");
private long[] keys;
private V[] values;
private volatile int capacity;
- private volatile int size;
+ private int size;
--- End diff --
Got it, yeah missed that important point. Makes sense
> ConcurrentLongHashMap and ConcurrentLongHashSet should avoid volatile set
> cost on put/remove
> --------------------------------------------------------------------------------------------
>
> Key: ARTEMIS-1702
> URL: https://issues.apache.org/jira/browse/ARTEMIS-1702
> Project: ActiveMQ Artemis
> Issue Type: Improvement
> Components: Broker
> Affects Versions: 2.5.0
> Reporter: Francesco Nigro
> Assignee: Francesco Nigro
> Priority: Minor
> Fix For: 2.5.0
>
>
> ConcurrentLongHashSet/HashMap are making use of unecessary volatile store of
> size/capacity for modifier methods.
> The current JVM implementation of volatile store for multicore x86 is making
> use of a StoreLoad barrier for this operation: the most expensive one.
> These volatile stores could be replaced by plain stores/lazySet ones with no
> effects on the correctness of those methods.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
