create CLHM classes for each primitve type for the keys of the map to eleminate autoboxing/unboxing

[GoogleCodeExporter]

Current Behavior:
autoboxing is used when primitive values are used as keys which reduces 
performance.

Desired Behavior:
create CLHM classes for each primitve type for the keys of the map to eleminate 
autoboxing/unboxing.  
eg.

byteConcurrentlinkedhashmap
shortConcurrentlinkedhashmap
intConcurrentlinkedhashmap
longConcurrentlinkedhashmap

Complexity / Amount of Change Required:
public V put(K key, V value) becomes public V put(long key, V value) 
for longConcurrentlinkedhashmap etc.

lots of methods would need to be updated but it should not take too long.

See the Trove collections to see how they do it.

Original issue reported on code.google.com by pariodeu...@googlemail.com on 20 Apr 2011 at 1:40

[GoogleCodeExporter]

Scala's specialized would be perfect here. I'm not sure if there is enough 
value for this effort in Java-land, though.

To improve concurrency often relies on increasing the memory footprint. I 
suspect that use cases that need the higher concurrency characteristics are 
less memory sensitive. If memory was a concern, then a different language (e.g. 
C) might be used.

Do you have a good example to justify this request or was this an observation?

Original comment by Ben.Manes@gmail.com on 20 Apr 2011 at 2:43

[GoogleCodeExporter]

It was just an observation, I use the trove collections for everything when I 
don't need concurrency. If you compare the performance of the trove hashmaps 
compared to the standard hashmap the performance and memory footprint are much 
better by a long shot. I am sure that eliminating autoboxing/unboxing 
contributed to the speedup and reduced memory footprint. 

I would not put it high on your todo list but it would be a nice thing to have 
at some point.

Original comment by pariodeu...@googlemail.com on 20 Apr 2011 at 9:44

[GoogleCodeExporter]

Due to being backed by ConcurrentHashMap, the effort required is considerable. 
Unfortunately Java is not friendly to these types of optimizations and its too 
much work for me to take on.

Original comment by Ben.Manes@gmail.com on 20 Apr 2011 at 10:07

• Changed state: WontFix