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

231–240 of 373 posts

Re: The JVM is not that heavy

#231

Post by fetbaffe »

jpgvm wrote: post #218
hyperpallium wrote: post #168

Earlier quoted context omitted.

"Plan to throw one away; you will, anyhow." First version to understand the problem, second version to solve it. But deployment, gc pauses and startup time (jvm vs go) are orthogonal to program quality. I would also expect go to have less memory usage. > deployment was simpler and faster, memory usage was slashed..., request/response times were much more consistent, startup was practically instant

Orthogonal to quality but imperative to velocity. At the end of the day despite Go's failings it's a good (maybe the best?) language for large projects and teams because it compiles fast, is easy to anyone to run anywhere, tests run quickly, programs execute quickly and there is already good tooling/editor support. Nothing beats efficient workflow for improving velocity.

I could use the exact same arguments but for PHP.

Re: The JVM is not that heavy

#232

Post by the8472 »

kodablah wrote: post #119
necubi wrote: post #28

Earlier quoted context omitted.

This is officially supported in JDK 9. It's part of an ongoing project called "jigsaw" which is introducing modules to the JVM. The first step, shipping in 9, is to modularize the JDK [0]. Already today you can build a custom JDK in the early access release. [0] http://openjdk.java.net/jeps/200

Not that well. The java.base module is still huge. Also, Zulu has nice pre-packaged JDK9 downloads[0] so you don't have to build. 0 - http://zulu.org/zulu-9-pre-release-downloads/

I think jlink can strip at the class level, not just the module level.

Re: The JVM is not that heavy

#233

Post by needusername »

pjmlp wrote: post #117
jstimpfle wrote: post #33

Earlier quoted context omitted.

These points are true in my experience (EDIT: 1.5 startup time sounds like too much) and they are enough to debunk the claim "The JVM is not that heavy". I hadn't ever heard anybody considering disk consumption or installation time before, when making that claim. To add, 4. Garbage collection and lack of value typed records. As far as I know there is currently no way around going full SOA (structures of arrays (of pr…

> As far as I know there is currently no way around going full SOA There are if you use language extensions like Packed Objects on the IBM JVM or Object Layouts on Azul. So just like C, you have C and then GCC C, clang C, .... Eventually Java 10 will fix this, but for those that like to live on the edge there are already snapshots available.

> Object Layouts on Azul.

https://objectlayout.github.io/ObjectLayout/ does not save you any headers. It just allows you to control where your objects are in memory and compiler optimizations based on this. It does not help you with memory footprint.

Also I'm not sure if it's really implemented on Zing considering that from the outside the project seems dead.

> Eventually Java 10 will fix this

I would not be so sure. The challenges especially regarding primitive generics are not to be underestimated. See

http://cr.openjdk.java.net/~jrose/values/shady-values.html

Re: The JVM is not that heavy

#234

Post by developer2 »

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…

4. Garbage collection. The fact that Java does not have a refcount collector, that can release memory back to the process's pool as soon as something goes out of scope and is no longer referenced, is horrid. Nearly every major software written in Java goes through the worst kind of struggle wherein users have to assign a 4 GB heap size to run a service that only really needs 500 MB. When fatal Out-Of-Memory crashes are the status quo, something is very very wrong.

Re: The JVM is not that heavy

#235

Post by vgy7ujm »

alsadi wrote: post #69

Ruby is perl-minded folks reinventing python without understanding it. The result was: ruby is python-done wrong. Now comparing python flask uwsgi and jvm jetty apps are in favor of python in all metric. Starting a django elephant takes no time compare that to starting less capable framework of choice in java world. To be fair, java can be much much faster than python. But usually you don't care because python is not…

Perl > Ruby > any other language > Python

Re: The JVM is not that heavy

#236

Post by marklgr »

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…

> what Erlang's releases do for the ERTS platform

That's the difference between an industrial-strength platform like Erlang, and a dev-centric deployment nightmare like Python. Java is normally on the enterprise side of the spectrum, but unfortunately it didn't get deployment right for quite a long time, even though it appears it's getting there lately.

Re: The JVM is not that heavy

#237

Post by stevedonovan »

Jach wrote: post #183

Work on an enterprise-sized "app", the JVM starts seeming "heavy". It feels super slow (and memory greedy, and you have to make sure it has enough of the right 'type' of memory) in executing on a whole (when it gets going it can do limited, specific things quite fast) and for productivity, as does all the tooling around it. Unless perhaps you're Google and you have server farms constantly compiling crap and so on so…

Yes, it's not my preferred platform at all but we all inherit projects. By leaning too heavily on the _dynamic_ aspects of Java (like reflection) it is possible to get Python-like speeds and constantly running the risk of OOM. But with better tooling than Python, at least. (For small languages that interop with the JVM, I must say I had a lot of fun with LuaJava - Swing was actually pleasant)

Re: The JVM is not that heavy

#238

Post by flaie »

cutler wrote: post #203
bjoernw wrote: post #172

Earlier quoted context omitted.

How is Spring Boot "enterprisey"? It makes modern java programming simpler and more accessible by hiding some of the unnecessary complexity. It enables things like https://jhipster.github.io/ which to me is the Rails equivalent in the java world.

JHipster equivalent to Rails? You have to be joking, surely. I just setup a JHipster site and when I opened it up in IntelliJ it was the same labyrinthine mess I've come to expect from Java frameworks, ie. knee-deep in endless subdirectories and everything abstracted away to the point of incomprehension. Contrast that with the simplicity of Ruby and Rails. Java by its very nature makes it impossible to build simple,…

This is non-sense, something like Spring boot is easy to comprehend, there's no labyrinthine mess whatsoever. You've got the choice to use other simple frameworks like Spark, or plain libs like Jersey + Jackson. All in all it's still the same, you write your Controller, your services and that's it. Where is that complicated?

And I'm a big fan of Clojure, but it's not because Clojure is cool that Java becomes de-facto a big pile of poo. People have been drilled by so much FUD about Javaland that they simply can't stand to try it correctly without preconceptions.

Re: The JVM is not that heavy

#239

Post by pjmlp »

needusername wrote: post #233
pjmlp wrote: post #117

Earlier quoted context omitted.

> As far as I know there is currently no way around going full SOA There are if you use language extensions like Packed Objects on the IBM JVM or Object Layouts on Azul. So just like C, you have C and then GCC C, clang C, .... Eventually Java 10 will fix this, but for those that like to live on the edge there are already snapshots available.

> Object Layouts on Azul. https://objectlayout.github.io/ObjectLayout/ does not save you any headers. It just allows you to control where your objects are in memory and compiler optimizations based on this. It does not help you with memory footprint. Also I'm not sure if it's really implemented on Zing considering that from the outside the project seems dead. > Eventually Java 10 will fix this I would not be so sure.…

> It just allows you to control where your objects are in memory and compiler optimizations based on this. It does not help you with memory footprint.

It is already better than what you get on Hotspot.

> The challenges especially regarding primitive generics are not to be underestimated. See

The challenge here is due to how Java designers to build them in first place.

Modula-3 and Eiffel are two examples of languages with proper generics, value types and toolchains that do AOT compilation to native code.

So I am still hopeful.

However, like everything, some challenges are technical and some are political.

Re: The JVM is not that heavy

#240

Post by froh42 »

quanticle wrote: post #206
froh42 wrote: post #35

Earlier quoted context omitted.

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…

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. That's not necessarily true. JIT compilation is severely constrained in the amount of analysis that it can do for the simple reason that JIT has to be fast . Fast enough to not noticeably slow down the app.…

Not all JIT compilation needs to be fast. I think it was hotspot that first does interpretation, then - when interpretation proves too expensive - switches over to a quick jit. And when code gets executed lots of times it runs jit again, this time with deep optimization settings.

What I personally don't understand: Why don't we cache JIT results between runs? That might be a worthwile optimization and even possible in the face of class loading.

It probably would be like running ngen on .net, just WITH performance statistics of a program. (Enabling specialization of calls for types commonly passed or eliminating constant expressions while keeping the generic version of a function around - that's hard in AOT as you need profiling information. I think sun's C/C++ compiler was able to do that for AOT, resulting in large speedups. But maybe it only used it for branch prediction).

Edit: What I forgot to add - I like the way you could always AOT things in .NET with ngen but also use a JIT where possible. Now that Java turned out to be owned by the evil empire and .NET the one by the company committed to open source - imagine reading that 10 years ago - I'm really curious in which way things will develop. And with all the new contenders as well. JVM (and .net) is not dead, but a lot of interesting alternatives are getting traction now.

Post reply on HN