Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The JVM is not that heavy

opensourcery.co.za

Post reply on HN
Print view View original

71–80 of 373 posts

Re: The JVM is not that heavy

#71

Post by ekidd »

needusername wrote: post #62
jhh wrote: post #13

I agree with many points in this article. That being said, there are dimensions of heaviness not captured in the article as far as I can see: 1. The startup times, not so much of the JVM itself, that just takes 1,5 secs, but the startup time of your application gets higher if you have a lot of classes on the classpath. I guess it's the classpath scanning that takes a lot of time (?). 2. Memory usage of Java objects i…

> 1. The startup times, not so much of the JVM itself, that just takes 1,5 secs Where do you get these numbers from? On my five year old MacBook Pro with default JVM options parsing a 20 MB file: real 0m0.248s user 0m0.325s sys 0m0.043s > 2. Memory usage of Java objects is quite heavy. That's IBMs enterprise VM that uses three word headers. HotSpot is actually better. If you compare that with other "lightweight" prog…

> real 0m0.248s

A quarter of a second to start up the VM, run some code, and exit again is actually pretty steep compared to typical interpreted and compiled languages. Among other things, this means that you can't really call Java executables from a loop in a shell script.

For comparison purposes, both Ruby and Rust will show between "0.00 elapsed" and "0.02 elapsed" for a simple "Hello, world" program on my laptop.

Re: The JVM is not that heavy

#72

Post by derefr »

kasey_junk wrote: post #39
akvadrako wrote: post #29

Earlier quoted context omitted.

In my mind, 1½ seconds is huge; that essentially rules out any interactive usage. It's even annoying for rapid development cycles. Only low expectations or heavy orchestration can overcome such a startling disadvantage.

It rules out any interactive usage where you are starting and stopping the jvm, like in a command line context. There are work arounds for this (things that reuse jvms and such) but until that is overcome the jvm is largely not appropriate for cli tools that start/stop. But for other kinds of interactive programs, things with long running sessions and such, it is pretty easy to a) lower that startup time and b) do th…

I've always thought it'd be nice to build a sort of hybrid between a "ClojureScript for bash", and a Java boot-script + RPC client.

Picture a Clojure macro library just for writing CLI driver programs, where you could call all your Clojure code like normal, and where some of the subcommand-defining methods of the driver program could be annotated with something like "@inline".

The un-annotated subcommands, as a simpler case, would translate into calls to spawn a JRE and feed your ARGV over to it once it gets running. These would be the slow-startup calls, so you'd just use them for the things that need the full "horsepower" of the JVM.

The @inline subcommands, on the other hand, would grab your app, its deps, and the JRE, do a whole-program dead-code-elimination process over them to trim them down to just what that subcommand needs, and then would transpile that whole resulting blob to bash code and shove it into a bash function. (So, something like Emscripten with a different frontend + backend.)

Re: The JVM is not that heavy

#73

Post by LaSombra »

jhh wrote: post #13

I agree with many points in this article. That being said, there are dimensions of heaviness not captured in the article as far as I can see: 1. The startup times, not so much of the JVM itself, that just takes 1,5 secs, but the startup time of your application gets higher if you have a lot of classes on the classpath. I guess it's the classpath scanning that takes a lot of time (?). 2. Memory usage of Java objects i…

On my old ThinkPad X201 with HDD and 8GB of RAM, running Fedora 25 and Gnome 3 I can start vanilla WildFly 10.1 in less than 10 seconds, http://imgur.com/a/BCDNP:

    20:43:44,578 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 10.1.0.Final (WildFly Core 2.2.0.Final) started in 6551ms - Started 331 of 577 services (393 services are lazy, passive or on-demand)
Not too shabby IMHO.

Re: The JVM is not that heavy

#76

Post by noselasd »

makapuf wrote: post #59
vmarovic wrote: post #53

"For both Node and Ruby you need a C compiler on the system which is hundreds of megabytes alone." Wait what? What c compiler is hundreds of megabytes?

$ ls -sh /usr/bin/gcc-5 896K /usr/bin/gcc-5 $ ldd /usr/bin/gcc-5 linux-vdso.so.1 => (0x00007ffc64bf5000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fda3da4f000) /lib64/ld-linux-x86-64.so.2 (0x000055f2460a1000) (so no specific .so dependencies) And why would you need that in production ? (hint: use fpm) This article seems strange : why do you include xcode in npm ? why use a mac if it's that heavy ? sure an…

I certainly agree that you don't need that for production machines.

However /usr/bin/gcc is just a frontend, and calls a slew of other binaries(such as cpp, collect2, cc1, normally found somewhere in /usr/libexec/gcc/). You also need binutils, and to be useful, likely headers for at least the standard C library.

The gcc + binutils package comes up at around 75MB on my machine.

Re: The JVM is not that heavy

#77

Post by derefr »

kasey_junk wrote: post #47
Matthias247 wrote: post #45

Earlier quoted context omitted.

The really interesting part of this: Java was actually designed for smaller embedded devices and not for servers.

And there are alternative JVMs that are specifically designed for that use case that don't behave the same way.

For examples:

• the JVM on smart cards, e.g. EMV (chip) credit cards, or GSM cellular SIM cards

• the JVM embedded into the Intel Management Engine coprocessor

Re: The JVM is not that heavy

#78

Post by azinman2 »

froh42 wrote: post #35
saosebastiao wrote: post #12

Interesting that all the comparisons were with server frameworks. As if anybody ever cared about a few hundred megabytes of overhead on a server. Hell, even a bloated JVM implementation fits in most server L3 caches. On the desktop, laptop, phone, or embedded environment, the JVM is heavy. It starts up slow, jars carry around ridiculous amounts of dead dependencies, garbage collectors require immense amounts of tunin…

Haha, AOT native compilation. This comes back time and time again. AOT native results in slower runtimes for applications with one simple exception: startup time. In every other case a modern JIT compiler like the JVM will win due to gathering information and layered compilation. Where AOT really makes sense is for an interactive app on a mobile device where you don't care about the last millisecond of performance bu…

Don't forget that AOT also means less memory -- no hotspot running and dynamically compiling code.

Re: The JVM is not that heavy

#79

Post by javajosh »

ohstopitu wrote: post #74

Just out of curiosity: If you decide to use Java (or any other languages that run on JVM), are their 3rd party libraries as "nice" (read: as many) as npm?

Java has an incredible range of libraries, often of very high quality. You have to manually install the dependency piece in the form of Maven (http://maven.apache.org/), or if you're doing Clojure, Leiningen (https://leiningen.org/). The total number of artifacts in the main archive, Maven Central (http://search.maven.org/#stats) is ~1.8M.

Re: The JVM is not that heavy

#80

Post by PaulHoule »

Clojure is heavy, or at least it has high start times. Some of that is the JVM start, but parsing and compiling a large amount of Clojure code system-wide is more of a burden than, say, CPython.
Post reply on HN