"The performance is at the mercy of the native HashTable implementation, which may lag behind what is available in high-performance Java world, especially under concurrent access."
What native HashTable is used? Shouldn't the JVM be using an optimized one?
I think by "native" they mean "implemented-in-c++-by-the-JVM", which potentially vary; not java.util.HashTable, which should be pretty standard across JVM implementations.
Please be careful with blanket statements like this. HashMap, Hashtable and ConcurrentHashMap behave differently in certain (subtle?) ways. ConcurrentHashMap doesn't like NULL but is thread-safe. Hashtable is synchronized, slow and thread-safe, but doesn't mind NULL. HashMap is not thread safe and doesn't mind NULL.
Edit: pardon the dupes, on unreliable mobile link :-(
> Hashtable is synchronized, slow and thread-safe, but doesn't mind NULL.
The issue with Hashtable or rather all legacy collection classes is that the API is rarely useful without additional synchronization. So you might as well use a HashMap wrapped by Collections.synchronizedMap or use a ConcurrentHashMap with a placeholder object instead of null.
Interestingly, the hash table implementation it's subclassing has changed from `HashTable` to `RehashableHashtable` between JDK7 and JDK8, so I guess there's at least been work to try and improve the performance there.
The hashmap header is here, code lives in the matching cpp file in the same directory:
Absolutely - that's what the blog post is about, how OpenJDK's particular implementation behaves. When Aleksey is talking about the hashtables not being resizeable, he's talking about the project he works on, which is the code above.
What native HashTable is used? Shouldn't the JVM be using an optimized one?