5 ms·

Depending on how it is done, one benefit could be you'd be able to use java/clojure/scala to build command line tools, something few people do now because of th

by i_s 12y ago

Depending on how it is done, one benefit could be you'd be able to use java/clojure/scala to build command line tools, something few people do now because of the slow JVM startup time.

sitkack 12y ago
The JVM isn't too slow for command line tools. What is too slow is the size of the executables and the amount of upfront work that secondary runtimes are doing. I can't say anything for Scala, but the startup time of Clojure has nothing to do with the JVM. Pure Java Hello World launches in 90ms on my machine. Jython Hello World takes 1.3 seconds. EDIT: to address all the comments. I am saying the JVM isn't _too_ slow for command line applications. Not ideal, but tolerable. I just tested the startup time of a robovm'ed Hello World: 23ms FWIW. And the resulting executable isn't exactly light weight. $ otool -L Main Main: /usr/lib/libSystem.B.dylib /usr/lib/libiconv.2.dylib /usr/lib/libsqlite3.dylib /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation /usr/lib/libstdc++.6.dylib $ du -sch Main 11M Main
- zorked 12y ago
  All C implementations of languages that exist on the JVM start fast. All JVM implementations are slow. How is this not a JVM problem?
  - pjmlp 12y ago
    Have you ever used Aonix, Websphere Real Time, JamaicaJVM, RoboVM, ExcelsiorJET, JikesRVM, OS/400 JVM, CodenameONE JVM,...? If not, then don't say "All JVM implementations are slow".
    - zorked 12y ago
      I meant "all JVM implementations of languages that also exist in C". Sorry I was unclear.
      - pjmlp 12y ago
        Ah ok.
- saurik 12y ago
  A pipeline of Java hello worlds then might take half a second just to spawn the multiple JVMs. It is also important to note that the work a JVM does scales in the number of classes you load: running "saxonb-xslt" with no arguments (so as to get the usage block) takes 215ms "hot" (1485ms "cold") on my relatively beefy server. In comparison, running "xsltproc" with no arguments takes 7ms "hot" (113ms "cold", though my cold numbers for this may be artificially low as maybe the JVM warmed up some C library xsltproc also happens to be using; the number doesn't feel wrong, though, given the hot times, which are perfectly reproducible, btw, as nothing else is happening on this computer). If I actually tried to use Saxon (so it had to load and link even more classes related to the transformations) the slowness would just become more and more painful.
  - sitkack 12y ago
    Those numbers seem totally plausible. I am not advocating for `ls` to implemented on the JVM. But for most usages, there is not a huge problem implementing CLI programs on the JVM, but some things like loading a huge AoP framework is out of the question.
- pron 12y ago
  Right. The "JVM's slow startup" (or, rather, HotSpot's slow startup) is a result of two things: the tendency of JVM code to use a lot of dependencies and, more importantly, the time it takes the HotSpot to warm up enough until it does all the optimizing compilation to native code. So, on my machine, Hello World takes about 80ms to launch (and terminate), but writing grep in Java isn't the best idea as it will take a while for the program to achieve "native" speed. HotSpot shines when running long-running processes, where the JIT is able to perform optimizations few (if any) static compilers can. Java 9, however, is expected to include JIT caching/AOT compilation to help programs that need to start at full speed. Of course, there are JVMs out there that do AOT compilation rather than JIT, and they don't have a "slow startup".
- i_s 12y ago
  If the JVM is slow at loading dependencies, that fact is very relevant when talking about the startup time. > startup time of Clojure has nothing to do with the JVM Startup time has everything to do with the VM. Check out this post, comparing perf and startup time for Clojure on the CLR vs JVM: http://stackoverflow.com/questions/10827093/clojure-performance-on-jvm-versus-clr http://stackoverflow.com/questions/10827093/clojure-performa...
- badlogic 12y ago
  We are working on the lightweightness. We currently throw away a bit of startup performance due to the way we load classes at runtime. That being said, 23ms is quite reasonable i guess.
  - sitkack 12y ago
    I don't think the size is horrible, though for mobile, smaller executables do reduce breakage. I haven't tried converting a large app, but I assume even a big jar is a small incremental increase in exe size. 23ms is is pretty good. To compare, Hello World in Python, converted to a native executable has a launch time of 6ms (284k executable size). So there might be some room for improvement. RoboVM is still amazing.

by i_s 12y ago

Depending on how it is done, one benefit could be you'd be able to use java/clojure/scala to build command line tools, something few people do now because of the slow JVM startup time.

sitkack 12y ago

The JVM isn't too slow for command line tools. What is too slow is the size of the executables and the amount of upfront work that secondary runtimes are doing. I can't say anything for Scala, but the startup time of Clojure has nothing to do with the JVM. Pure Java Hello World launches in 90ms on my machine. Jython Hello World takes 1.3 seconds. EDIT: to address all the comments. I am saying the JVM isn't _too_ slow for command line applications. Not ideal, but tolerable. I just tested the startup time of a robovm'ed Hello World: 23ms FWIW. And the resulting executable isn't exactly light weight. $ otool -L Main Main: /usr/lib/libSystem.B.dylib /usr/lib/libiconv.2.dylib /usr/lib/libsqlite3.dylib /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation /usr/lib/libstdc++.6.dylib $ du -sch Main 11M Main

zorked 12y ago
All C implementations of languages that exist on the JVM start fast. All JVM implementations are slow. How is this not a JVM problem?
- pjmlp 12y ago
  Have you ever used Aonix, Websphere Real Time, JamaicaJVM, RoboVM, ExcelsiorJET, JikesRVM, OS/400 JVM, CodenameONE JVM,...? If not, then don't say "All JVM implementations are slow".
  - zorked 12y ago
    I meant "all JVM implementations of languages that also exist in C". Sorry I was unclear.
    - pjmlp 12y ago
      Ah ok.
saurik 12y ago
A pipeline of Java hello worlds then might take half a second just to spawn the multiple JVMs. It is also important to note that the work a JVM does scales in the number of classes you load: running "saxonb-xslt" with no arguments (so as to get the usage block) takes 215ms "hot" (1485ms "cold") on my relatively beefy server. In comparison, running "xsltproc" with no arguments takes 7ms "hot" (113ms "cold", though my cold numbers for this may be artificially low as maybe the JVM warmed up some C library xsltproc also happens to be using; the number doesn't feel wrong, though, given the hot times, which are perfectly reproducible, btw, as nothing else is happening on this computer). If I actually tried to use Saxon (so it had to load and link even more classes related to the transformations) the slowness would just become more and more painful.
- sitkack 12y ago
  Those numbers seem totally plausible. I am not advocating for `ls` to implemented on the JVM. But for most usages, there is not a huge problem implementing CLI programs on the JVM, but some things like loading a huge AoP framework is out of the question.
pron 12y ago
Right. The "JVM's slow startup" (or, rather, HotSpot's slow startup) is a result of two things: the tendency of JVM code to use a lot of dependencies and, more importantly, the time it takes the HotSpot to warm up enough until it does all the optimizing compilation to native code. So, on my machine, Hello World takes about 80ms to launch (and terminate), but writing grep in Java isn't the best idea as it will take a while for the program to achieve "native" speed. HotSpot shines when running long-running processes, where the JIT is able to perform optimizations few (if any) static compilers can. Java 9, however, is expected to include JIT caching/AOT compilation to help programs that need to start at full speed. Of course, there are JVMs out there that do AOT compilation rather than JIT, and they don't have a "slow startup".
i_s 12y ago
If the JVM is slow at loading dependencies, that fact is very relevant when talking about the startup time. > startup time of Clojure has nothing to do with the JVM Startup time has everything to do with the VM. Check out this post, comparing perf and startup time for Clojure on the CLR vs JVM: http://stackoverflow.com/questions/10827093/clojure-performance-on-jvm-versus-clr http://stackoverflow.com/questions/10827093/clojure-performa...
badlogic 12y ago
We are working on the lightweightness. We currently throw away a bit of startup performance due to the way we load classes at runtime. That being said, 23ms is quite reasonable i guess.
- sitkack 12y ago
  I don't think the size is horrible, though for mobile, smaller executables do reduce breakage. I haven't tried converting a large app, but I assume even a big jar is a small incremental increase in exe size. 23ms is is pretty good. To compare, Hello World in Python, converted to a native executable has a launch time of 6ms (284k executable size). So there might be some room for improvement. RoboVM is still amazing.