[
https://issues.apache.org/jira/browse/BOOKKEEPER-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15652371#comment-15652371
]
ASF GitHub Bot commented on BOOKKEEPER-964:
-------------------------------------------
Github user merlimat commented on the issue:
https://github.com/apache/bookkeeper/pull/72
My primary concern here was about the number of allocations, especially of
allocation that could be slightly long-lived (eg: item stays in the map for few
seconds), that are more likely to be pushed to old-gen whenever a young GC
cycle is performed.
For example in the `Map<Long, Long>` case you would have 3 allocations
per-insertion (long boxing + linked list node to hold key and value).
Also, every `get()`, `containsKey()` operation would need 1 allocation to
box the long key.
In general Objects in 64bits JVM will have a minimum size of 16 bytes.
http://stackoverflow.com/questions/258120/what-is-the-memory-consumption-of-an-object-in-java
> Add concurrent maps and sets for primitive types
> ------------------------------------------------
>
> Key: BOOKKEEPER-964
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-964
> Project: Bookkeeper
> Issue Type: Improvement
> Reporter: Matteo Merli
> Assignee: Matteo Merli
> Fix For: 4.5.0
>
>
> In BookKeeper there are many instances of maps and sets that use ledger id
> and entry ids as keys or values. JDK concurrent collections have the overhead
> of boxing all the primitive values into objects (eg: long --> Long) that would
> need to be allocated from the heap. In addition to that, JDK map
> implementations
> are closed hash tables and they will require at least one more allocation to
> hold
> the linked-list/tree node.
> There are already available libraries that offer primitive collections with
> zero-allocation, but none of these support concurrent maps/sets.
> We have added a handful of specializations, all based on the same
> implementation
> idea. We have a hash table which is broken down into multiple sections. Each
> sections, on its own, is an open hash table with linear probing, protected by
> a stamped lock.
> All insertions, lookups and iterations on these collections are allocation
> free.
> {noformat}
> ConcurrentLongHashMap: Map<long, Object>
> ConcurrentLongHashSet: Set<long>
> ConcurrentLongLongHashMap: Map<long, long>
> ConcurrentLongLongPairHashMap: Map< Pair<long, long>, Pair<long, long> >
> ConcurrentOpenHashMap: Map<Object, Object>
> ConcurrentOpenHashSet: Set<Object>
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
