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

51–60 of 373 posts

Re: The JVM is not that heavy

#51

Post by saosebastiao »

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…

I agree with most of what you say...AOT is far more of a competitive advantage for phones and other devices.

But I'd argue that there are very few benefits of JIT that can't be achieved by AOT + PGO. A sound static type system nullifies the need for most of those benefits (like speculative type optimizations and deoptimizations). But it might have the upper hand in cases where profiling can't capture all of the possible optimizable workloads that the binary would see. Databases or other large programs that continuously specialize over the lifecycle of the process. But that is far more niche than most people realize.

Re: The JVM is not that heavy

#54

Post by Scarbutt »

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.5 secs for the jvm only seems excessive.

$time java HelloWorld

Hello, World

real 0m0.071s

user 0m0.053s

sys 0m0.020s

That is a linux vm running in a mba (first run).

Re: The JVM is not that heavy

#55

Post by snuxoll »

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…

Later versions of .Net don't do dynamic profiling, the .Net CLR is much less sophisticated than the JVM, the first time you invoke an IL method it is compiled to machine code, and that same code will execute for the rest of the lifetime of that image.

Re: The JVM is not that heavy

#56

Post by sandGorgon »

echlebek wrote: post #14
sandGorgon wrote: post #7

I used to think this too, until I came across http://www.scylladb.com/ It is a fork of cassandra written in the Seastar c++ framework and is drop-in compatible with cassandra. Claims 10x increase in performance. I always thought there was a few percentage points difference - never a 10x performance difference between java and c++. And that too for a project with as many man hours and facebook-scale tuning as cassandr…

If you investigate what they actually do to achieve those numbers, it's much less simple than just rewriting Cassandra in C++. For example, they use their own TCP stack and make use of vector intrinsics.

Hey.. "vector intrinsics" looks very cool. Thanks for mentioning that!

so what you mean is that, even after throwing facebook scale resources at java.. it is possible for a That's a huge loss of face for java IMHO

Re: The JVM is not that heavy

#57

Post by smacktoward »

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…

> As if anybody ever cared about a few hundred megabytes of overhead on a server

Kids today! Sit down over here, and Grandpa will tell you about the days when a few hundred megabytes was more than your average server's entire storage capacity. Now, in those days you tied an onion to your servers, which was the style at the time...

Re: The JVM is not that heavy

#58

Post by gozur88 »

cperciva wrote: post #44

The notion that the JVM is not heavy because it needs less than a GB of disk space seems crazy to me. I consider OpenSSL to be wildly bloated because it is over 1 MB .

A megabyte of disk space is now worth about $0.0000290, according to this site:

http://www.jcmit.com/diskprice.htm

The numbers we're talking about here just aren't a practical consideration any more.

Re: The JVM is not that heavy

#59

Post by makapuf »

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 IDE is nice but I wouldn't take that as part of the language. Or also include eclipse + plugins.

Re: The JVM is not that heavy

#60

Post by gregschlom »

derefr wrote: post #41
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" fi…

Funny you mention that, that's exactly why we wrote this tool. We were having a ton of support issues with our Windows users having to install Java, incompatible Java versions, needing admin privileges to install the JRE, etc...

We fixed this whole class of issues by doing exactly what you suggest: bundling the JRE and writing our own launcher binary.

Post reply on HN