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

241–250 of 373 posts

Re: The JVM is not that heavy

#241

Post by pjmlp »

marklgr wrote: post #236
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…

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

It started on Java 8 with adoption of having a packing story as part of the JDK tooling, but I don't know how good it is.

Re: The JVM is not that heavy

#242

Post by pjmlp »

radicalbyte wrote: post #223
yoden wrote: post #99

Earlier quoted context omitted.

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

The problem with visiting that site is that Oracle have started litigating against users of their JVMs. In that way the JVM can be "heavy".

With users that use commercial features without paying for them.

It is quite easy to know which features those are when they require a flag named -XX:+UnlockCommercialFeatures, you just don't use them by mistake.

Re: The JVM is not that heavy

#244

Post by pjmlp »

gregschlom wrote: post #174
geocar wrote: post #144

Earlier quoted context omitted.

I don't know. 10MB still sounds really too big. Why is it so big? What do we gain? I don't have a system with 10MB of cache, so I imagine Java can't run faster than memory...

10MB for a platform that allows you to run code on all three major operating systems without too much trouble and in a performant way is a huge win, in my opinion. Not many alternatives come close to that.

Actually all languages with a rich runtime and standard library that isn't just a thin POSIX layer like C or C++ (although C++ has been improving their library story).

Still your point holds.

Re: The JVM is not that heavy

#245

Post by pjmlp »

froh42 wrote: post #240
quanticle wrote: post #206

Earlier quoted context omitted.

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

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

This is configurable, Hotspot can JIT right away when application starts, but then be prepared to wait a bit.

> What I personally don't understand: Why don't we cache JIT results between runs?

They do, just not the OpenJDK that many only care about.

All commercial JDKs support code caches between executions and AOT compilation.

Re: The JVM is not that heavy

#246

Post by pjmlp »

sunkencity wrote: post #49

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

Well, except for the type safety of Java, only allow native code to be compiled to shared objects for implementing Java native methods and exposing all OS APIs outside what is required for graphics and real time audio via JNI.

If it wasn't for the pressure of game developers, the NDK wouldn't even exist.

Remember Brillo? It was supposed to be like Android, but using C++ frameworks instead, as presented at Linux Embedded 2015 conference.

Guess what, when it got recently re-branded as Android Things, it switched to the Java Frameworks instead and it doesn't even allow for the NDK, with the user space device drivers being written in Java.

Re: The JVM is not that heavy

#247

Post by fnord123 »

Orangeair wrote: post #85
ekidd wrote: post #71

Earlier quoted context omitted.

> real 0m0.248s A quarter of a second to start up the VM, run some code, and exit again is actually pretty steep compared to typical interpreted and compiled languages. Among other things, this means that you can't really call Java executables from a loop in a shell script. For comparison purposes, both Ruby and Rust will show between "0.00 elapsed" and "0.02 elapsed" for a simple "Hello, world" program on my laptop.

That's just Hello World, though. He said his app was parsing a 20 MB file. To do a fair comparison, with your example, I just compiled and ran Hello World in Java on my machine and got this: real 0.06 user 0.06 sys 0.01

Here you go:

https://bitbucket.org/ewanhiggs/csv-game

Re: The JVM is not that heavy

#248

Post by pjmlp »

cutler wrote: post #196
eikenberry wrote: post #114

Earlier quoted context omitted.

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.

This is one thing I've never understood about Clojure - the Java interop. I actually love Clojure but I close my eyes to the fact that it requires an object-oriented VM to work its magic. Clojure is a functional Lisp based on immutable data structures which is about as far from Java OOP as it gets yet we're encouraged to mix Java objects and classes into our Clojure apps as if nothing matters.

Funny, when I code in Clojure there are these things called multi-methods, protocols and multiple dispatch.

I think it was originally designed in a Lisp library called CLOS, which incidentally stands for Common Lisp Object System.

Very nice explained on how to implement OOP in Lisp, in a book called "The Art of the Metaobject Protocol".

Users of Lisp based languages should think twice before criticizing OOP.

Re: The JVM is not that heavy

#249

Post by beagle3 »

CountHackulus wrote: post #210
Jeaye wrote: post #157

Earlier quoted context omitted.

In production, what matters is the ridiculous memory usage. Both Java and App Engine are to blame about this, but the Python and Go folks aren't running into the same issue.

If memory usage matters to you, have you tried telling the JVM not to use all the memory? Have you tried any of the tuning options? Can't say I've ever used app engine, but the pure java applications I've worked on did in fact use a fair bit of memory, much like windows and OSX will aggressively use spare memory for caching. Then I use -Xmx to tell it not to use all the memory and now it's much better. For a server,…

I have, and gave up after a month of touching every couple of days trying to find the sweet spot. Someone more familiar with JVM internals would have probably succeeded - but somehow C Python Go and even OCaml runtimes don't need this level of tuning in my experience.

JVM deployments tend to assume nothing else happens on the same machine, in my experience.

Re: The JVM is not that heavy

#250

Post by pjmlp »

akvadrako wrote: post #145
eveningcoffee wrote: post #134

Earlier quoted context omitted.

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.

I read it fine, but Clojure is an application of the JVM. The fact that a popular interpreted language of the JVM takes 1.2 seconds for hello world is a problem of the JVM itself, or at least it's ecosystem. An interpreted language in C wouldn't take nearly that long.

The way an interpreter is implemented and the language it runs on don't have anything to do with each other.

A Clojure interpreter written in C, if written the same way as for Java, it would run just as slow, given the way it is building Clojure every time the application starts.

Post reply on HN