activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ARTEMIS-1702) ConcurrentLongHashMap and ConcurrentLongHashSet should avoid volatile set cost on put/remove
Date Mon, 26 Feb 2018 11:28:00 GMT

    [ https://issues.apache.org/jira/browse/ARTEMIS-1702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16376697#comment-16376697
] 

ASF GitHub Bot commented on ARTEMIS-1702:
-----------------------------------------

Github user wy96f commented on a diff in the pull request:

    https://github.com/apache/activemq-artemis/pull/1895#discussion_r170562278
  
    --- Diff: artemis-commons/src/main/java/org/apache/activemq/artemis/utils/collections/ConcurrentLongHashMap.java
---
    @@ -460,7 +468,7 @@ private void rehash() {
              keys = newKeys;
              values = newValues;
              usedBuckets = size;
    -         capacity = newCapacity;
    +         CAPACITY_UPDATER.lazySet(this, newCapacity);
              resizeThreshold = (int) (capacity * MapFillFactor);
    --- End diff --
    
    should be resizeThreshold = (int) (newCapacity * MapFillFactor)
      
                
      


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

Mime
View raw message