Hacker News Reader

Comment by whizzter | Hacker News Reader

What the GP is referring to (Misc.Unsafe) is basically going back to manual pointer reads/writes (IE writing more or less C code in Java), the benefit is you get C speed/memory layout/cache-locality but with the downside of writing it in a less suited language (Java).

HOWEVER If you DO _allocate_ much then 1TB seems like a great choice since GC pauses are killers w.r.t. latency in comparison to cache issues. A cache line (often 64 bytes) would probably only hold at most a couple of Java objects (minimum is probably like 16 or more bytes for each small object) so cache locality won't be improved much by a GC (Yes, the G1 GC in newer JDK's does neighbour compacting iirc so you get a little cache locality but only if the patterns were bad from the start, but avoiding GC entirely is better)

View on HN

Can you explain why you would code java this way instead of dropping down to C?

Probably because they started out in Java and don't want a full rewrite once they've gotten this far (might be that they don't have many C++ devs anyhow). I remember working on similar codebases 10 years back when J2ME games were still a thing (J2ME runtimes usually had horrible GC's and some people really went overboard in trying to avoid them) and it wasn't that fun at all (Even if the questDB codebase that is linked elsewhere in this thread seems to be saner).

Also JNI for calling C/C++ code is fairly bad and error prone (if you want to combine code), JNA is better but i think this is one of the bigger reasons that Oracle is funding GraalVM is that it promises "seamless" interoperability and breaking up things into Java and C/C++ parts might be a good option in the future.

JNI replacement is called Panama it doesn't have anything to do with GraalVM.

GraalVM is the new name of MaximeVM one of the JVM meta-circular JVMs. Other well known ones being JikesRVM and SquawkVM.

What Oracle and others in the Java community are doing is reducing the need to drop down to C with support for value types and more fine grained control over native memory.

Java 16 will have the first preview release of the new low level memory APIs.

The meta-circularity is part of the impl details, cross-language calling (Java/JS/LLVM) seems to be the main selling point of it, so if you want GC-less logic then Clang->LLVM then running on the JVM is an option, no idea if it also simplifies native bindings though (that is more of a Panama issue and improving that is a good idea aswell).

Productivity and safety of Java.

Those unsafe bits are a tiny portion of the overall code.

Reply on news.ycombinator.com