Hacker News Reader

Comment by Androider | Hacker News Reader

1TB of RAM is cheap though, versus spending engineering hours.

Reminds me of the classic WTF "That would've been an option too" https://thedailywtf.com/articles/That-Wouldve-Been-an-Option...

View on HN

> 1TB of RAM is cheap though, versus spending engineering hours.

It's not about the amount of RAM, it's how fast and predictable the overall system is. Note in particular the remark about cache locality; that can be the difference between nanoseconds and microseconds.

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)

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.

This was a great read, thanks for that! Never heard of The Daily WTF before.

Congratulations!

https://xkcd.com/1053/

Of course there’s an XKCD for this! Ah, the wonders of the internet.

The article in question was written in 2008: I was 11 years old. I guess I now fall in to the category of “heard of it by the age of 30”.

> ...a new intern named Bob. Bob raised a finger and said "Yes, I have a question...

Damn those smart-ass interns!

agree. hardware is getting cheaper and cheaper

Except Memory / DRAM.

Reply on news.ycombinator.com