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

41–50 of 373 posts

Re: The JVM is not that heavy

#41

Post by derefr »

gregschlom wrote: post #25

Also worth noting that the JVM itself only weighs a couple of megabytes. The bulk of the size comes from the Java runtime (ie: the "standard libraries"), and there are lots of things that your app may not need there (XML parsing, serialization, etc...) A couple of years ago I wrote a simple tool ( https://github.com/aerofs/openjdk-trim ) that allows you to filter out what you don't need. We were able to get the size…

> I wrote a simple tool that allows you to filter out what you don't need

It'd be a short hop from here to a tool that basically does for JDK-platform apps what Erlang's releases do for the ERTS platform: builds a new JRE (as a portable executable, not an installer) that actually contains the app and its deps in the JRE's stdlib, such that you just end up with a dir containing "a JRE", plus a runtime "boot config" file that tells the JRE what class it should run when you run the JRE executable.

With such a setup, your Java program could actually ship as an executable binary, rather than a jar and an instruction to install Java. Nobody would have to know Java's involved! :)

Re: The JVM is not that heavy

#42

Post by jeremiep »

akvadrako wrote: post #29
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…

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.

That's completely false in the context of a Lisp.

I boot the JVM once and iterate endlessly in the same process. Same for ClojureScript in the browser or node.js. Lisp is by far the most interactive language there is with the fastest iteration times (AFAIK).

1.5 seconds would be huge if you had to constantly restart your application like you do everywhere outside Lisp. Iterating in Clojure is literally instant.

I wrote applications in dozens of languages, and none come remotely close to Clojure's iteration speed or joy of use.

Re: The JVM is not that heavy

#45

Post by Matthias247 »

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…

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

Re: The JVM is not that heavy

#46

Post by martingxx »

I led our teams to switch from Java to Go because of the productivity of development, but then noticed deployment was simpler and faster, memory usage was slashed (for comparable applications), request/response times were much more consistent, startup was practically instant and as a result we started aggressively rewriting Java applications to Go and saw a notable difference in the number of machines we needed to run in AWS.

So in my situation, the JVM is heavier by every single measure listed, and for each by a considerable margin.

Re: The JVM is not that heavy

#47

Post by kasey_junk »

Matthias247 wrote: post #45
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…

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.

Re: The JVM is not that heavy

#48

Post by rev »

outworlder wrote: post #18

Interestingly, the author does not touch startup times. Frankly, for server-side loads, no-one cares how much your runtime weights, be it disk space, download size and even memory (heck, my last project required developer workstations with at least 96GB). There are all sorts of environments where that matters. And that's one of the reasons why Clojure didn't catch on on Android.

Wow, 96GB of RAM? I don't even... Would you care to elaborate?

Re: The JVM is not that heavy

#49

Post by sunkencity »

Sure it takes a while to load and there's bloat, but the bloat is everywhere now.

On the bad site of the JVM and assorted Java tools is that they are second class citizens of the unix world. The command arguments are all messed up, much like a windows tool ported to unix, and the interaction with the rest of the unix stack like sockets, files are all solipsistic and off, which leaves an ill stink on everything touched by it.

One of the things I find funny with java is the once upon a time much touted security model, fast forward a couple of years and the event of android - using the unix security model and none of the java stuff.

Re: The JVM is not that heavy

#50

Post by AnimalMuppet »

jackmott wrote: post #21
rb808 wrote: post #20

Not just heavy but I really don't like all our processes named "java" with stupid -D cmd line parameters. A Nice native binary app will let you can name it what you want with config as you like it.

there are ahead of time compilers for java! not free though.

IIRC, gcj compiles to an executable.
Post reply on HN