romix/java-concurrent-hash-trie-map

Java port of a concurrent trie hash map implementation from the Scala collections library

java-concurrent-hash-trie-map's Issues

Comparision with high-scale-lib

Was performance and memory footprint of this map implementation compared with NonBlockingHashMap from high-scale-lib? Seems like both of these projects aim to provide a non-blocking implementation of ConcurrentMap that could potentially replace ConcurrentHashMap in Java applications.

availability of the library on central

Hello,

have you thought about publishing this library to central, to make it available for builds with maven without own copy?

Is this supposed to work? new TrieMap<>().clear();

On my machine this results to an infinite loop:

/**
 *
 */
public void testClear() {
    new TrieMap<>().clear();
}

2013-08-06 19:41:05
Full thread dump Java HotSpot(TM) 64-Bit Server VM (23.25-b01 mixed mode):

"test-runner" prio=10 tid=0x00007f2d609d9800 nid=0x5cc7 runnable [0x00007f2d4f616000]
java.lang.Thread.State: RUNNABLE
at com.romix.scala.collection.concurrent.TrieMap.RDCSS_Complete(TrieMap.java:1115)
at com.romix.scala.collection.concurrent.TrieMap.RDCSS_ROOT(TrieMap.java:1143)
at com.romix.scala.collection.concurrent.TrieMap.clear(TrieMap.java:1285)

2013-08-06 19:41:05
Full thread dump Java HotSpot(TM) 64-Bit Server VM (23.25-b01 mixed mode):

"test-runner" prio=10 tid=0x00007f2d609d9800 nid=0x5cc7 runnable [0x00007f2d4f616000]
java.lang.Thread.State: RUNNABLE
at com.romix.scala.collection.concurrent.TrieMap.clear(TrieMap.java:1285)
at org.gridgain.grid.lang.utils.GridTrieMapSelfTest.testClear(GridTrieMapSelfTest.java:96)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)

java -version
java version "1.7.0_25"
Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)

OS: ubuntu 12.04

Yakov

V get (Object k) returns Some instead of V

We run into situations when subj. returns Some instance instead of V.

I'm now working on isolated test case, but quick look suggest that there could be an obvious bug. Method 'get' performs lookuphc and return result just casting it to V. In the same time method 'lookup' performs the same call and checks whether the value is an Option or not.

May be get should work the same as lookup?

Serializable

Any reason why the TrieMap port is not marked Serializable? The TrieMap from scala.concurrent is.