7 ms·

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 ti

by jhh 10y ago

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 is quite heavy. See this article: http://www.ibm.com/developerworks/library/j-codetoheap/index.html http://www.ibm.com/developerworks/library/j-codetoheap/index... 3. The heavyness of the ecosystem in terms of the magnitude of concepts and tools being used and the enterprisy-ness of libraries.

meddlepal 10y ago
There's that word again "enterprisey".
akvadrako 10y ago
In my mind, 1½ seconds is huge; that essentially rules out any interactive usage. It's even annoying for rapid development cycles. Only low expectations or heavy orchestration can overcome such a startling disadvantage.
- kasey_junk 10y ago
  It rules out any interactive usage where you are starting and stopping the jvm, like in a command line context. There are work arounds for this (things that reuse jvms and such) but until that is overcome the jvm is largely not appropriate for cli tools that start/stop. But for other kinds of interactive programs, things with long running sessions and such, it is pretty easy to a) lower that startup time and b) do things that mitigate it to the user.
  - derefr 10y ago
    I've always thought it'd be nice to build a sort of hybrid between a "ClojureScript for bash", and a Java boot-script + RPC client. Picture a Clojure macro library just for writing CLI driver programs, where you could call all your Clojure code like normal, and where some of the subcommand-defining methods of the driver program could be annotated with something like "@inline". The un-annotated subcommands, as a simpler case, would translate into calls to spawn a JRE and feed your ARGV over to it once it gets running. These would be the slow-startup calls, so you'd just use them for the things that need the full "horsepower" of the JVM. The @inline subcommands, on the other hand, would grab your app, its deps, and the JRE, do a whole-program dead-code-elimination process over them to trim them down to just what that subcommand needs, and then would transpile that whole resulting blob to bash code and shove it into a bash function. (So, something like Emscripten with a different frontend + backend.)
- jeremiep 10y ago
  That's completely false in the context of a Lisp. I boot the JVM once and iterate endlessly in the same process. Same for ClojureScript in the browser or node.js. Lisp is by far the most interactive language there is with the fastest iteration times (AFAIK). 1.5 seconds would be huge if you had to constantly restart your application like you do everywhere outside Lisp. Iterating in Clojure is literally instant. I wrote applications in dozens of languages, and none come remotely close to Clojure's iteration speed or joy of use.
  - bandrami 10y ago
    Lisp is by far the most interactive language there is with the fastest iteration times (AFAIK). That's Forth. Lisp comes next.
  - icebraining 10y ago
    if you had to constantly restart your application like you do everywhere outside Lisp. This was probably true in the 80s, but hasn't been in a while. Many languages have this, either built-in or as a tool. In the case of the JVM, there's spring-loaded, which works in Java, Groovy, etc.
- maaaats 10y ago
  That 1.5 seconds is FUD anyway.
- eveningcoffee 10y ago
  1.5 is huge, except it is completely wrong. JVM startup time is within fraction of the second.
  - akvadrako 10y ago
    You are right, I was just going with what the grandparent said. But I think with normal amounts of class scanning and other overhead, 1.5 seconds becomes the practical normal. Certainly the JVM startup always feels slow, in my experience.
    - eveningcoffee 10y ago
      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 http://blog.ndk.io/jvm-slow-startup.html
      - akvadrako 10y ago
        That links says 1.2 seconds for a hello world! 1.2 microseconds is what I would expect to be called fast.
        mickronome 10y ago
        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.
        dkersten 10y ago
        That's clojure, not java. JVM startup is much faster.
        eveningcoffee 10y ago
        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.
jstimpfle 10y ago
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 primitive types)) for large data collections. Object overhead (memory usage) and GC overhead are the reason why only SOA will work (and it's a pain because the language doesn't make it convenient) if you have like >10^7 objects. (That's my personal experience from a 2-month project, and I normally don't use Java).
- pjmlp 10y ago
  > 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.
  - needusername 10y ago
    > Object Layouts on Azul. https://objectlayout.github.io/ObjectLayout/ 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 http://cr.openjdk.java.net/~jrose/values/shady-values.html
    - pjmlp 10y ago
      > 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.
flavor8 10y ago
> 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.
- eikenberry 10y ago
  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.
  - flavor8 10y ago
    > 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.
    - eikenberry 10y ago
      But some languages have better cultures/eco-systems than others. Java has one of the worst.
      - flavor8 10y ago
        Far from it IMO. It depends on which subculture you immerse yourself in. If you subscribe to the IBM/Oracle/Red Hat thought leaders, then yes - you'll encounter enterprisey stuff, because they're all targeting legacy corps. Believe me that I know where you're coming from -- I have a real aversion the big enterprise side of the Java world. There's a lot of interesting development in Java open source though, and it'd be a shame to throw the baby out with the bathwater.
Scarbutt 10y ago
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).
needusername 10y ago
> 1. The startup times, not so much of the JVM itself, that just takes 1,5 secs Where do you get these numbers from? On my five year old MacBook Pro with default JVM options parsing a 20 MB file: real 0m0.248s user 0m0.325s sys 0m0.043s > 2. Memory usage of Java objects is quite heavy. That's IBMs enterprise VM that uses three word headers. HotSpot is actually better. If you compare that with other "lightweight" programming languages it is really, really light.
- ekidd 10y ago
  > 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.
  - Orangeair 10y ago
    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
    - fnord123 10y ago
      Here you go: https://bitbucket.org/ewanhiggs/csv-game https://bitbucket.org/ewanhiggs/csv-game
  - asmosoinio 10y ago
    The parent did write "parsing a 20 MB file". So not a hello world.
    - pvdebbe 10y ago
      <insert joke about Java being overly verbose>
d_burfoot 10y ago
Did you test that 1.5 second claim yourself? I literally just wrote a HelloWorld and ran it on my MacBook, the total time for the whole program was <0.2 seconds.
- jhh 10y ago
  I agree that my claim is false. I kind of wrote that from the top of my head. In any case, the point that I wanted to make in the parent comment was that the JVM startup time itself was basically fine. I just checked on my Macbook and a HelloWorld class gives me .13 secs real.
- monodeldiablo 10y ago
  To be fair, 0.2 seconds is still ludicrously long. I can literally say the output of the program in less time than the runtime can.
LaSombra 10y ago
On my old ThinkPad X201 with HDD and 8GB of RAM, running Fedora 25 and Gnome 3 I can start vanilla WildFly 10.1 in less than 10 seconds, http://imgur.com/a/BCDNP http://imgur.com/a/BCDNP: 20:43:44,578 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 10.1.0.Final (WildFly Core 2.2.0.Final) started in 6551ms - Started 331 of 577 services (393 services are lazy, passive or on-demand) Not too shabby IMHO.
javajosh 10y ago
Startup time on my late 2014 MPBr for Clojure Hello World is indeed 1.29s, which is what the OP was measuring. $ time java -jar target/uberjar/clojure.jar Hello, World! 1.29s user 0.08s system 181% cpu 0.755 total $ /usr/sbin/system_profiler -detailLevel full Model Name: MacBook Pro Model Identifier: MacBookPro11,3 Processor Name: Intel Core i7 Processor Speed: 2.3 GHz Number of Processors: 1 Total Number of Cores: 4 L2 Cache (per Core): 256 KB L3 Cache: 6 MB Memory: 16 GB
- eveningcoffee 10y ago
  It is Clojure. It loads an additional runtime by itself. It is unfortunately not usable for CLI applications. Pure Java does the same thing in fraction of time. http://blog.ndk.io/jvm-slow-startup.html http://blog.ndk.io/jvm-slow-startup.html
richdougherty 10y ago
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 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 http://openjdk.java.net/jeps/169.
developer2 10y ago
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.
- matt2000 10y ago
  I'm sorry to call out this comment specifically, but almost everything you said here is not true. Out-Of-Memory crashes are not the status quo. The JVM garbage collector is (generally) a very high performance system that has improved incredibly over the past decade, it's not as simple as saying it's missing reference counting so it's "horrid". These are the kind of lazy generalization that causes people to make poor technology decisions.

by jhh 10y ago

meddlepal 10y ago

There's that word again "enterprisey".

akvadrako 10y ago

In my mind, 1½ seconds is huge; that essentially rules out any interactive usage. It's even annoying for rapid development cycles. Only low expectations or heavy orchestration can overcome such a startling disadvantage.

kasey_junk 10y ago
It rules out any interactive usage where you are starting and stopping the jvm, like in a command line context. There are work arounds for this (things that reuse jvms and such) but until that is overcome the jvm is largely not appropriate for cli tools that start/stop. But for other kinds of interactive programs, things with long running sessions and such, it is pretty easy to a) lower that startup time and b) do things that mitigate it to the user.
- derefr 10y ago
  I've always thought it'd be nice to build a sort of hybrid between a "ClojureScript for bash", and a Java boot-script + RPC client. Picture a Clojure macro library just for writing CLI driver programs, where you could call all your Clojure code like normal, and where some of the subcommand-defining methods of the driver program could be annotated with something like "@inline". The un-annotated subcommands, as a simpler case, would translate into calls to spawn a JRE and feed your ARGV over to it once it gets running. These would be the slow-startup calls, so you'd just use them for the things that need the full "horsepower" of the JVM. The @inline subcommands, on the other hand, would grab your app, its deps, and the JRE, do a whole-program dead-code-elimination process over them to trim them down to just what that subcommand needs, and then would transpile that whole resulting blob to bash code and shove it into a bash function. (So, something like Emscripten with a different frontend + backend.)
jeremiep 10y ago
That's completely false in the context of a Lisp. I boot the JVM once and iterate endlessly in the same process. Same for ClojureScript in the browser or node.js. Lisp is by far the most interactive language there is with the fastest iteration times (AFAIK). 1.5 seconds would be huge if you had to constantly restart your application like you do everywhere outside Lisp. Iterating in Clojure is literally instant. I wrote applications in dozens of languages, and none come remotely close to Clojure's iteration speed or joy of use.
- bandrami 10y ago
  Lisp is by far the most interactive language there is with the fastest iteration times (AFAIK). That's Forth. Lisp comes next.
- icebraining 10y ago
  if you had to constantly restart your application like you do everywhere outside Lisp. This was probably true in the 80s, but hasn't been in a while. Many languages have this, either built-in or as a tool. In the case of the JVM, there's spring-loaded, which works in Java, Groovy, etc.
maaaats 10y ago
That 1.5 seconds is FUD anyway.
eveningcoffee 10y ago
1.5 is huge, except it is completely wrong. JVM startup time is within fraction of the second.
- akvadrako 10y ago
  You are right, I was just going with what the grandparent said. But I think with normal amounts of class scanning and other overhead, 1.5 seconds becomes the practical normal. Certainly the JVM startup always feels slow, in my experience.
  - eveningcoffee 10y ago
    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 http://blog.ndk.io/jvm-slow-startup.html
    - akvadrako 10y ago
      That links says 1.2 seconds for a hello world! 1.2 microseconds is what I would expect to be called fast.
      - mickronome 10y ago
        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.
      - dkersten 10y ago
        That's clojure, not java. JVM startup is much faster.
      - eveningcoffee 10y ago
        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.

jstimpfle 10y ago

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 primitive types)) for large data collections. Object overhead (memory usage) and GC overhead are the reason why only SOA will work (and it's a pain because the language doesn't make it convenient) if you have like >10^7 objects. (That's my personal experience from a 2-month project, and I normally don't use Java).

pjmlp 10y ago
> 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.
- needusername 10y ago
  > Object Layouts on Azul. https://objectlayout.github.io/ObjectLayout/ 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 http://cr.openjdk.java.net/~jrose/values/shady-values.html
  - pjmlp 10y ago
    > 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.

flavor8 10y ago

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

eikenberry 10y ago
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.
- flavor8 10y ago
  > 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.
  - eikenberry 10y ago
    But some languages have better cultures/eco-systems than others. Java has one of the worst.
    - flavor8 10y ago
      Far from it IMO. It depends on which subculture you immerse yourself in. If you subscribe to the IBM/Oracle/Red Hat thought leaders, then yes - you'll encounter enterprisey stuff, because they're all targeting legacy corps. Believe me that I know where you're coming from -- I have a real aversion the big enterprise side of the Java world. There's a lot of interesting development in Java open source though, and it'd be a shame to throw the baby out with the bathwater.

Scarbutt 10y ago

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

needusername 10y ago

> 1. The startup times, not so much of the JVM itself, that just takes 1,5 secs Where do you get these numbers from? On my five year old MacBook Pro with default JVM options parsing a 20 MB file: real 0m0.248s user 0m0.325s sys 0m0.043s > 2. Memory usage of Java objects is quite heavy. That's IBMs enterprise VM that uses three word headers. HotSpot is actually better. If you compare that with other "lightweight" programming languages it is really, really light.

ekidd 10y ago
> 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.
- Orangeair 10y ago
  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
  - fnord123 10y ago
    Here you go: https://bitbucket.org/ewanhiggs/csv-game https://bitbucket.org/ewanhiggs/csv-game
- asmosoinio 10y ago
  The parent did write "parsing a 20 MB file". So not a hello world.
  - pvdebbe 10y ago
    <insert joke about Java being overly verbose>

d_burfoot 10y ago

Did you test that 1.5 second claim yourself? I literally just wrote a HelloWorld and ran it on my MacBook, the total time for the whole program was <0.2 seconds.

jhh 10y ago
I agree that my claim is false. I kind of wrote that from the top of my head. In any case, the point that I wanted to make in the parent comment was that the JVM startup time itself was basically fine. I just checked on my Macbook and a HelloWorld class gives me .13 secs real.
monodeldiablo 10y ago
To be fair, 0.2 seconds is still ludicrously long. I can literally say the output of the program in less time than the runtime can.

LaSombra 10y ago

On my old ThinkPad X201 with HDD and 8GB of RAM, running Fedora 25 and Gnome 3 I can start vanilla WildFly 10.1 in less than 10 seconds, http://imgur.com/a/BCDNP http://imgur.com/a/BCDNP: 20:43:44,578 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 10.1.0.Final (WildFly Core 2.2.0.Final) started in 6551ms - Started 331 of 577 services (393 services are lazy, passive or on-demand) Not too shabby IMHO.

javajosh 10y ago

Startup time on my late 2014 MPBr for Clojure Hello World is indeed 1.29s, which is what the OP was measuring. $ time java -jar target/uberjar/clojure.jar Hello, World! 1.29s user 0.08s system 181% cpu 0.755 total $ /usr/sbin/system_profiler -detailLevel full Model Name: MacBook Pro Model Identifier: MacBookPro11,3 Processor Name: Intel Core i7 Processor Speed: 2.3 GHz Number of Processors: 1 Total Number of Cores: 4 L2 Cache (per Core): 256 KB L3 Cache: 6 MB Memory: 16 GB

eveningcoffee 10y ago
It is Clojure. It loads an additional runtime by itself. It is unfortunately not usable for CLI applications. Pure Java does the same thing in fraction of time. http://blog.ndk.io/jvm-slow-startup.html http://blog.ndk.io/jvm-slow-startup.html

richdougherty 10y ago

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 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 http://openjdk.java.net/jeps/169.

developer2 10y ago

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.

matt2000 10y ago
I'm sorry to call out this comment specifically, but almost everything you said here is not true. Out-Of-Memory crashes are not the status quo. The JVM garbage collector is (generally) a very high performance system that has improved incredibly over the past decade, it's not as simple as saying it's missing reference counting so it's "horrid". These are the kind of lazy generalization that causes people to make poor technology decisions.