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

101–110 of 373 posts

Re: The JVM is not that heavy

#101

Post by andor »

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…

Avian [0] is an embeddable VM in the way you suggest, I haven't used it though.

In the future, we'll hopefully have the Substrate VM [1] for Java and other Truffle-supported languages. It's embeddable and also does reachability analysis to exclude unused library code. For now, it seems to be closed source.

[0] http://readytalk.github.io/avian/

[1] http://lafo.ssw.uni-linz.ac.at/papers/2015_CGO_Graal.pdf

Re: The JVM is not that heavy

#103

Post by lisivka »

AnimalMuppet wrote: post #50
jackmott wrote: post #21

Earlier quoted context omitted.

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

IIRC, gcj compiles to an executable.

Gcj was deleted from GCC in October 2016[1]. So only free option left, AFAIK, is to use mono AOT[2].

[1]: http://tromey.com/blog/?p=911 [2]: http://www.mono-project.com/docs/about-mono/languages/java/

Re: The JVM is not that heavy

#104

Post by andor »

yoden wrote: post #99
derefr wrote: post #41

Earlier quoted context omitted.

> 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…

https://docs.oracle.com/javase/8/docs/technotes/guides/deplo... Not only is it a short hop, it already exists :P

Nice. Here's the manual page, the relevant flag is "-native":

http://docs.oracle.com/javase/8/docs/technotes/tools/unix/ja...

Re: The JVM is not that heavy

#105

Post by PeCaN »

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…

You're measuring the size of a program that calls GCC, not GCC itself at all. gcc-5 isn't the compiler, it dispatches to cpp/cc1/ld/etc.

cc1 is 20MB over here. gold is 5MB. Dynamic libraries it depends on (gmp & family, isl) weigh about 4MB. All-in-all the programs required to compile even a simple C program come out around ~32MB.

Clang is much bigger. Clang 3.8 is 59MB (I think that includes the preprocessor though, but GNU's CPP is only around 1MB (which still seems huge for a preprocessor)).

Re: The JVM is not that heavy

#107

Post by pron »

sandGorgon wrote: post #56
echlebek wrote: post #14

Earlier quoted context omitted.

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

Explicit use of vector intrinsics are not the source of any 10x performance boost, nor anything to do with C++ in particular. Again, only a small (but probably not minuscule) portion of the difference has to do with Java vs. C++. The bulk of the difference is due to all sorts of optimizations, most of them could have been done in Java as well. But the ScyllaDB people are more experienced in C++ than in Java, and as they use sequential code anyway, there isn't a big downside for using C++ -- certainly not for them -- so it was the better choice. From what little I know, the reasons why such optimizations weren't done in Cassandra are because 1. the people working on it aren't low-level optimization experts, but more importantly, 2. because the performance was good enough.

Re: The JVM is not that heavy

#108

Post by richdougherty »

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…

I'm not arguing with you, those are genuine problems, but there are a few projects in a pipeline to address a few of these things.

1. Startup time being addressed by precompiling the standard library (or your own library). See "JEP 295: Ahead-of-Time Compilation": http://openjdk.java.net/jeps/295. Also addressed by modularisation of the standard library, "JEP 220: Modular Run-Time Images".

2. Memory usage (and less garbage collection overhead) using value types. See "JEP 169: Value Objects": http://openjdk.java.net/jeps/169.

Re: The JVM is not that heavy

#109

Post by dajohnson89 »

hannob wrote: post #100

I must admit my experience is a few years old, but one thing that the whole text doesn't mention and that has contributed a lot to the negativity I feel towards the java ecosystem: It seemed not well integrated in the Linux ecosystem. What do I mean? I often experienced that Java dependencies were not readily available in Linux distros. Packaging Java stuff was - weird and complicated, not sure how to better phrase i…

I think that's a fair point. I bet part of it is due to licensing. The choice on whether or not to use OpenJDK is not trivial, and I surmise that distro managers just avoid the issue completely (I would).

Re: The JVM is not that heavy

#110

Post by martingxx »

brianwawok wrote: post #96
martingxx wrote: post #46

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 ru…

> aggressively rewriting Java applications to Go and saw a notable difference in the number of machines we needed to run in AWS. This is the easy trap to fall into though. What if you aggressively rewrote the Java apps from crappy legacy frameworks to well developed Java apps? A rewrite ALMOST always is faster. So the new language seems faster. Except if you would then rewrite the rewrite back in the original languag…

These apps are mostly microservices and the Java ones are mostly only a year or two old. None of them use things like spring. Some use Dropwizard. Would you consider dropwizard modern? If not, what would you use instead?
Post reply on HN