The JVM is not that heavy • Hacker News Board

Re: The JVM is not that heavy

#131

Post by mickronome » Wed, Feb 01, 2017, 10:40 PM UTC

akvadrako wrote: post #126

eveningcoffee wrote: post #123

Earlier quoted context omitted.

Well, if you create a lot of additional objects on startup then it will take some time. JVM startup is still fast. http://blog.ndk.io/jvm-slow-startup.html

That links says 1.2 seconds for a hello world! 1.2 microseconds is what I would expect to be called fast.

1.2 seconds was hello world in clojure, the Java hello world presented the numbers below, so it's mostly clojure that is slow:

$ time java Hello Hello world 0.04user 0.01system 0:00.12elapsed 43%CPU (0avgtext+0avgdata 15436maxresident)k 29672inputs+64outputs (82major+3920minor

While 120ms elapsed is not stellar, it's rarely a problem with how the JVM ecosystem looks.

Re: The JVM is not that heavy

#132

Post by brianwawok » Wed, Feb 01, 2017, 10:41 PM UTC

martingxx wrote: post #110

brianwawok wrote: post #96

Earlier quoted context omitted.

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

A lot more to an app than MCV framework. I realize dropwizard tries to be the everything for the app, but at the core it is a MVC with some bundled libs.

Re: The JVM is not that heavy

#133

Post by dkersten » Wed, Feb 01, 2017, 10:41 PM UTC

akvadrako wrote: post #126

eveningcoffee wrote: post #123

Earlier quoted context omitted.

Well, if you create a lot of additional objects on startup then it will take some time. JVM startup is still fast. http://blog.ndk.io/jvm-slow-startup.html

That links says 1.2 seconds for a hello world! 1.2 microseconds is what I would expect to be called fast.

That's clojure, not java. JVM startup is much faster.

Re: The JVM is not that heavy

#134

Post by eveningcoffee » Wed, Feb 01, 2017, 10:42 PM UTC

akvadrako wrote: post #126

eveningcoffee wrote: post #123

Earlier quoted context omitted.

Well, if you create a lot of additional objects on startup then it will take some time. JVM startup is still fast. http://blog.ndk.io/jvm-slow-startup.html

That links says 1.2 seconds for a hello world! 1.2 microseconds is what I would expect to be called fast.

Please be kind to reread it.

Startup time of a simple Java application and therefore also whole JVM is 0.4s (in the linked article).

1.2s is for the implementation in Closure that includes its additional quite heavy runtime.

Re: The JVM is not that heavy

#135

Post by zigzigzag » Wed, Feb 01, 2017, 10:56 PM UTC

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 .

The actual HotSpot JVM itself is about 10mb, but that includes 4 GCs and 2 JIT compilers.

The Avian JVM can statically link an entire program and widget toolkit with itself and produce a 1mb binary.

It's not that big a deal. The space gets taken up by all the libraries. But then you'd want to compare a JVM against e.g. /usr/lib on a fresh Linux install ...

Re: The JVM is not that heavy

#136

Post by david-given » Wed, Feb 01, 2017, 10:56 PM UTC

david-given wrote: post #6

Way back when I ran a comment engine that was a custom Java servlet running on an embedded (i.e. mostly interpreted) JVM on a NSLU2: a 266MHz ARM with 32MB RAM. The servlet container was Winstone. Can't remember what the JVM was, sorry. Load wasn't exactly high, but it worked absolutely fine.

Ah, it was JamVM.

http://jamvm.sourceforge.net/

Alas, the last release looks like it was 2014, although it does claim to support Java 8. The actual interpreter core is under 100kB (class libraries extra, of course).

It plugs into the OpenJDK! Look for the openjdk-8-jre-jamvm package in Debian.

Re: The JVM is not that heavy

#137

Post by zigzigzag » Wed, Feb 01, 2017, 10:58 PM UTC

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

You aren't comparing the same program written in two languages. Seastar stuff is written by C++ performance experts who are fanatical about tuning, and does all kinds of unusual far-out things that Cassandra doesn't do to get high performance.

Re: The JVM is not that heavy

#138

Post by djsumdog » Wed, Feb 01, 2017, 10:59 PM UTC

What the hell is an HCMB? Nothing on DuckDuckGo, and nothing on Urban dictionary. I wish people would stop using acronyms before defining them.

Re: The JVM is not that heavy

#139

Post by zigzigzag » Wed, Feb 01, 2017, 11:00 PM UTC

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.

Avian can compile AOT to a single executable.

Re: The JVM is not that heavy

#140

Post by flavor8 » Wed, Feb 01, 2017, 11:03 PM UTC

eikenberry wrote: post #114

flavor8 wrote: post #37

Earlier quoted context omitted.

> The heavyness of the ecosystem in terms of the magnitude of concepts and tools being used and the enterprisy-ness of libraries. You don't have to use the enterprisey libraries though. Using Dropwizard, for example, gives you a tight and performant set of libraries that have a fairly minimal learning curve and require relatively little boilerplate.

While this is true in practice it can be hard. You don't always have control of what libs you are using and often finding lightweight alternatives to many libraries is hard to impossible. It is better once you get outside Java proper, but nearly all the alternative languages on the JVM tout access to the Java ecosystem as a plus which then brings back in all that pain.

> You don't always have control of what libs you are using

Well that's true regardless of the language. If you're not making the decisions on the codebase, there can be all kinds of gnarly dependencies and practices that you have to adhere to. I agree that big legacy corps tend to have over cumbersome setups, but hey, at least it's not cobol. My advice is not to work for big legacy corps.