Should we continue to use ConcurrentLongHashMap in source code?

[berg223]

I have write a benchmark for ConcurrentLongHashMap and ConcurrentHashMap. And the result shows ConcurrentHashMap has at least 1.6x throughput than ConcurrentLongHashMap. However, ConcurrentHashMap do have more gc count. Do you think it's a tradeoff between throughput and gc count?

I have upload the benchmark result in attachment file benchmark-concurrent-hashmap.json. You can visialize the result in JMH Visualizer. And summary the result of throughput benchmark in the following table:

method	ConcurrentHashMap	ConcurrentLongHashMap
getAbsent	about 500,000,000 ops/s	about 300,000,000 ops/s
getPresent	about 500,000,000 ops/s	about 300,000,000 ops/s
putAbsent	about 14,000,000 ops/s	about 5,000,000 ops/s
putPresent	about 80,000,000 ops/s	about 30,000,000 ops/s
removeAbsent	about 220,000,000 ops/s	about 33,000,000 ops/s
removePresent	about 200,000,000 ops/s	about 30,000,000 ops/s

Question: Should we optimize ConcurrentLongHashMap or stop use it?

Pros:

1. Avoid boxing and unboxing
2. Cache friendly due to linear probing and compact memory
3. Auto shrink is a great feature

Cons:

1. Lower throughput
2. Concurrent level is static
3. We have met multiple concurrent issues about ConcurrentLongHashMap:
   ConcurrentLongHashMap may throw an ArrayIndexOutOfBoundsException bookkeeper#4684
   [fix][broker] fix bug caused by optimistic locking #18390
   [fix] Fix ConcurrentLongHashMap concurrency issue bookkeeper#4317
   [fix] Fix concurrent containers concurrency issue #22604
4. We have to sync ConcurrentLongHashMap between bookkeeper and pulsar repo. And there is other classes has the same cons like ConcurrentLongLongPairHashMap.

IMO, we should replace ConcurrentLongHashMap with ConcurrentHashMap before we have a better implemention.