3 ms·

Not core to the article's ultimate point and conclusion, but in the premise it has: > The performance is at the mercy of the native HashTable implementation, w

Not core to the article's ultimate point and conclusion, but in the premise it has: > 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. Does anyone have any idea what this is referring to, if anything? Java's HashMap performance is pretty mediocre and without value types seems un-improvable. Certainly no where close to the SIMD-accelerated cache-line optimized hash maps you can find in C++ like the one in abseil or F14. It's a good article otherwise, just this note comes across as wishful thinking than a premise with any truth behind it.

smarks 4y ago
The "native HashTable" referred to here is the string hash table that's inside the JVM. The JVM has to intern strings from class files' string literals here, so it's all implemented in native code. The comment about performance probably refers to Java constantly improving in performance because of improvements to the JIT compiler, whereas that native HashTable in the JVM is pretty static in performance unless somebody rewrites it or if the C++ optimization gets significantly better. Essentially Shipilëv is saying that Java code gets faster more quickly than the C++ code in the JVM.
- kllrnohj 4y ago
  JITs don't improve a hashtables performance as they are dominated by memory access patterns (eg, open vs closed addressing), load factor, and hash quality. Of those 3 factors, the first is borderline impossible to optimize in Java at all. Regardless, the runtime isn't helping with any of those 3, it requires changes to the algorithms used. Which doesn't seem to be happening in Java land broadly? It's possible that the JVM just ignores its c++ code, sure, but that's not commentary on Java or the Java ecosystem. Also offline compiler optimization has so far consistently outpaced (or at least kept up with) JIT optimizations. So it's incorrect to consider the native code as static anyway unless you're just never upgrading the compiler.

smarks 4y ago

The "native HashTable" referred to here is the string hash table that's inside the JVM. The JVM has to intern strings from class files' string literals here, so it's all implemented in native code. The comment about performance probably refers to Java constantly improving in performance because of improvements to the JIT compiler, whereas that native HashTable in the JVM is pretty static in performance unless somebody rewrites it or if the C++ optimization gets significantly better. Essentially Shipilëv is saying that Java code gets faster more quickly than the C++ code in the JVM.

kllrnohj 4y ago
JITs don't improve a hashtables performance as they are dominated by memory access patterns (eg, open vs closed addressing), load factor, and hash quality. Of those 3 factors, the first is borderline impossible to optimize in Java at all. Regardless, the runtime isn't helping with any of those 3, it requires changes to the algorithms used. Which doesn't seem to be happening in Java land broadly? It's possible that the JVM just ignores its c++ code, sure, but that's not commentary on Java or the Java ecosystem. Also offline compiler optimization has so far consistently outpaced (or at least kept up with) JIT optimizations. So it's incorrect to consider the native code as static anyway unless you're just never upgrading the compiler.