5 ms·

"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

"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?

QuercusMax 9y ago
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.
- electrum 9y ago
  Yes, although Hashtable is legacy from JDK 1.0. New code should use HashMap or ConcurrentHashMap.
  - deleted 9y ago
    [deleted]
  - Tharkun 9y ago
    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 :-(
    - josefx 9y ago
      > 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.
jakewins 9y ago
It's using a custom c++ hashtable: https://github.com/JetBrains/jdk8u_hotspot/blob/master/src/share/vm/classfile/symbolTable.hpp#L255 https://github.com/JetBrains/jdk8u_hotspot/blob/master/src/s... 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: https://github.com/JetBrains/jdk8u_hotspot/blob/master/src/share/vm/utilities/hashtable.hpp#L277 https://github.com/JetBrains/jdk8u_hotspot/blob/master/src/s...
- pjmlp 9y ago
  That is an implementation detail, there are many JVMs to choose from.
  - jakewins 9y ago
    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.
    - pjmlp 9y ago
      I missed that.
pjmlp 9y ago
That is an implementation detail, there are many JVMs implementations to choose from.

QuercusMax 9y ago

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.

electrum 9y ago
Yes, although Hashtable is legacy from JDK 1.0. New code should use HashMap or ConcurrentHashMap.
- deleted 9y ago
  [deleted]
- Tharkun 9y ago
  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 :-(
  - josefx 9y ago
    > 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.

jakewins 9y ago

It's using a custom c++ hashtable: https://github.com/JetBrains/jdk8u_hotspot/blob/master/src/share/vm/classfile/symbolTable.hpp#L255 https://github.com/JetBrains/jdk8u_hotspot/blob/master/src/s... 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: https://github.com/JetBrains/jdk8u_hotspot/blob/master/src/share/vm/utilities/hashtable.hpp#L277 https://github.com/JetBrains/jdk8u_hotspot/blob/master/src/s...

pjmlp 9y ago
That is an implementation detail, there are many JVMs to choose from.
- jakewins 9y ago
  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.
  - pjmlp 9y ago
    I missed that.

pjmlp 9y ago

That is an implementation detail, there are many JVMs implementations to choose from.