Hacker News Reader

Comment by axaxs | Hacker News Reader

Java can be performant, but still typically has a huge footprint and memory profile. Others will point out that there are multiple implementations of Java, which is true, but to what adoption? IMO, the only thing propping up Java is legacy enterprise and Android. The adoption of Go, Rust, et al show that people just aren't that into VMs anymore. They had a place in the self hosted world, but in the microservice/cloud world, it's a -lot- of overhead. The same is true in smartphones...we have a huge memory use problem in Android. It may be 'performant', but it's still a resource dog.

View on HN

A key difference between an ELF binary and a Java .jar is that ELF contains a process image. The loader literally mmaps portions of the executable file into memory, and control is immediately translated to this image (dynamic linking and runtime relocations complicate this a bit, but mainly involve patching the image).

Java on the other builds its process image on the heap, using the executable file as input. Nothing is executed out of the binary file directly afaik. I believe classloading (defined in the Java spec) actually prohibits doing too much of this work ahead of time. The JVM has to defer work until startup in case the user wants to define a custom classloader.

My knowledge of the JVM is very basic compared to my knowledge of ELF, but I believe the basic gist of this is correct. I'm interested in diggging into this difference more deeply and writing a well-researched blog entry about it.

I have good news for you! Android (which never had a JVM) Lollipop replaced its old runtime Dalvik with ART, which is on around 1.5B devices. ART actually compiles Android's bytecode to ELF, though Android calls their variant OAT.

OAT, in turn, is a playful anagram of AOT, because what Android now does is even more powerful than the JVM or ELF. Android includes a JIT but it also does nightly profile guided optimizations. So not only does Android perform the preloading optimization you mention for ELF but as the user continues to use their apps Android will continue to optimize the compiled binaries.

Good to know. Does that mean Java classloaders are not supported on Android? And does this approach require breaking compatibility with that aspect of the Java spec?

> The adoption of Go, Rust, et al show that people just aren't that into VMs anymore.

Did you actually look at the numbers?

Go is certainly gaining some popularity, and Rust too (although an order of magnitude below Go) but both of these still have a fraction of the mind share that Java has.

You're being dazzled by the hype and forgetting to look at hard data.

> people just aren't that into VMs anymore

Bytecode can be translated quite well to native code. So I'm wondering if this isn't about "VMs versus native" as much as it is about "garbage collected versus unmanaged memory".

Possibly. The default strategy, at least in the server side world, simply uses too much memory. Compare Go RES memory to an equally implemented Java version. It's typically orders of magnitude smaller.

What's an example of an ahead-of-time compiler that takes bytecode and spits out native code? Can you do inline assembly for the target architecture? I heard a million time how JIT and JVM "could be" just as fast (or some claim faster) than AOT but in practice it hasn't happened. High performance code is written in AOT/native languages.

>What's an example of an ahead-of-time compiler that takes bytecode and spits out native code?

I believe that is how .NET works (the byte code gets distributed, and the user compiles it to native immidietly before execution).

Also, Android's ART is the replacement for Dalvik that compiles Dalvik bytecode into native code at installation.

Actually, ART is now "JIT guided AOT." The JIT will (re)compile code as needed but the JIT code is stored to disk, thus creating an AOT binary on future runs.

You can definitely do ahead of time compilation with .net bytecode. That's why you can write iOS apps in c# with xamarin's SDK.

I think the performance differences between JIT compiled code and native code mainly come from the 'convenience' features offered by languages such as Java or C#. I am thinking of garbage collection, (default) virtual functions or reflection.

In let's say c++ you can do all of these things too, but the cost is not hidden from the developer.

>I heard a million time how JIT and JVM "could be" just as fast (or some claim faster) than AOT but in practice it hasn't happened.

Why do you say this? There's lots of examples out there and Android is one of them.

How is an Android an example? What AOT are we comparing to here?

> The adoption of Go, Rust, et al show that people just aren't that into VMs anymore.

Or, you can also say that the adoption of LLVM compilers, Javascript/Node, Python, and Ruby, show that people are more into VMs than ever.

LLVM is not a vm, despite its name. Node is popular mainly because frontend people want to do backend work. Python is python, it's been around forever and is available. It's also unmatched in scientific realms. Ruby seems falling out of favor.

between github, metasploit, and rails, ruby is falling out of favor the way that java has fallen out of favor.

Well, I don't mean 'dead' by falling out of favor, just trying to gauge the pulse of new projects. Of course Ruby still exists, heck even Fortran has new development jobs, but I wouldn't call it a 'hot' language. Sure that comparison isn't fair or accurate, but an observation. Rails props up Ruby in a similar fashion existing codebases and Android do Java.

>Ruby seems falling out of favor.

Please elaborate, i'm interested.

Well, I typically look at a few metrics as PL fascinate me a lot. However, I'll be the first to admit I'm not an expert, so take everything below with a grain of salt.

First I judge by new projects/tools that interest me. I don't see much ruby there, but a fair amount of python admittedly. This could be biased to what interests me, obviously.

The second is people I know. Some are ex ruby devs, none still use it in their line of work.

The third is job trends. Ruby, specifically Rails, is just down by any metric. A quick google search sent me to http://www.indeed.com/jobtrends/q-Ruby-on-rails.html

Again, I said 'seems' because it seems that way to me, not because it is fact.

JavaScript is moving away from VMs in a sense, since WASM has basically unmanaged memory (no garbage collector). That's a good thing, because in theory you could build your own GC on top of it. (I say in theory because the technology is not there yet, in particular on the concurrency front).

Wasm code is bytecode; it targets a VM.

True, but it's a very simple VM, as it doesn't have a GC.

Reply on news.ycombinator.com