8 ms·

JVM has two new open source garbage collector implementations that are designed for TERABYTES of heap space with 10 ms GC pause times. (yes you read that corre

JVM has two new open source garbage collector implementations that are designed for TERABYTES of heap space with 10 ms GC pause times. (yes you read that correctly) ZGC from Oracle -- but open source Shenandoah from Red Hat -- also open source I know of no other managed runtime platform with the GC options and tunability as JVM. Also JVM has not one, but TWO JIT compilers, C1 and C2. Your JVM byte code starts out interpreted. It is constantly dynamically performance profiled. If it is getting above average CPU use then it is quickly compiled by C1 into native code, and scheduled to be recompiled soon later by C2. When C2 comes along, it takes its time recompiling your code into highly optimized native code. Suppose that YOUR function A calls MY function B. And C2 aggressively inlined my B function into your A function. Now suppose my code is dynamically reloaded within the running environment. Now your function has a stale version of my code inlined within. JVM will instantly de-optimize your code back to JVM byte code interpretation so that soon, if it is still a cpu hot spot, it will get recompiled again by C1 and C2. Let me know of any other runtime platform that even comes close to the things JVM does.

User23 7y ago
> Let me know of any other runtime platform that even comes > close to the things JVM does. Some of the more advanced Lisps would qualify.
- pron 7y ago
  No Lisp runtime currently has this quality of JIT compilers, GCs, and observability.
  - madmax96 7y ago
    You should check out SBCL, it's competitive.
    - pron 7y ago
      It isn't. Perhaps you haven't seen what the JVM can do lately. It's got JIT compilers that do this[1], GCs that are getting close to 1ms max pause times on terabytes of heap [2], and low-overhead, in-production deep profiling [3]. Not to mention all of the classic capabilities of the JVM like hot code redefinition and exceptional monitoring. Lots of applications can certainly manage well without some or even all those things, and some want other tradeoffs (like no warmup or lower RAM footprint), but these days it's hard to compete with the JVM where it's strong. The technological gap between it and other runtimes is only growing. [1]: https://twitter.com/ChrisGSeaton/status/619885182104043520 https://twitter.com/ChrisGSeaton/status/619885182104043520 [2]: http://cr.openjdk.java.net/~pliden/slides/ZGC-Jfokus-2019.pdf http://cr.openjdk.java.net/~pliden/slides/ZGC-Jfokus-2019.pd... [3]: https://craftingjava.com/using-java-flight-recorder-with-openjdk-11/ https://craftingjava.com/using-java-flight-recorder-with-ope...
      - User23 7y ago
        And yet it still can't even do TCO
        pron 7y ago
        Right. Different platforms have different priorities. But tail calls will be coming to the JVM eventually.
        preordained 7y ago
        This is the dumbest thing in the universe (in context of a Clojure discussion) that I keep seeing parroted over and over. So you have to type "recur <args>" instead of the actual function name + <args> for the exact same effect. If you can get over that aesthetic "sin" then you have your TCO in effect. I don't even find it mildly inconvenient...and even prefer the "shortcut" syntax vs explicitly repeating my function name.
    - pepper_sauce 7y ago
      Do you have appropriate benchmarks? I would appreciate seeing the comparison.
      - DannyB2 7y ago
        Yes, benchmarks. But it's not just benchmarks. It's capabilities. He should please provide references that compare other runtime platforms' capabilities side by side with JVM's capabilities.
        igouy 7y ago
        > provide references that compare other runtime platforms' capabilities side by side with JVM's capabilities How many weeks work do you imagine that would be?
        DannyB2 7y ago
        My point: if someone is going to assert that another platform is competitive with JVM, then not only is performance important, but capabilities as well. While no language / platform / os / etc is perfect, JVM as a managed runtime platform is hard to beat. More than two decades of research in its JIT compilers, and multiple GC implementations with various knobs and dials for tuning and monitoring. Battle tested. Someone mentioned SBCL. While I am a fan of Common Lisp, and generally all Lisps, I would cringe to see SBCL with terabytes of heap and hundreds of CPU cores running a serious workload -- and see how well it holds up. Just an example: You can Google for this, but in 2012 Twitter switched from Ruby on Rails to Java. They have YouTube videos explaining their change over. Basic reasons: performance and scalability. They have to handle BILLIONS of tweets per day and route each one to multiple places with notifications in near real time.
        lispm 7y ago
        > I would cringe to see SBCL with terabytes of heap and hundreds of CPU cores running a serious workload That's nothing SBCL can do, but one can save an executable and start that in a subsecond without the need for a terabyte of RAM. Generally there is a lot of stuff in the JVM which makes it less attractive as runtime for Lisp: more complex code loading via 'class loaders', lack of support for memory representation of Lisp's data types (like CLOS objects, which are more dynamic than Java classes), lack of TCO, lack of easy AOT compilation, lack of easy image dumps, lack of resumeable exceptions, ... And in 2019 something like Eclipse still is a bit clunky to run on my 8 core Xeon - part of the reason could be a less than great GUI implementation. In IntelliJ I need to restart my IDE for every simple plugin... probably features like live-updating haven't made it yet into popular apps.
    - User23 7y ago
      http://www.chiark.greenend.org.uk/doc/cmucl-docs/compiler-hint.html http://www.chiark.greenend.org.uk/doc/cmucl-docs/compiler-hi... is mostly applicable to SBCL last I checked. It gives an idea of what kind of cleverness the compiler can undertake.
- DannyB2 7y ago
  Then why is Clojure implemented on the JVM? As Rich Hickey says: because it has _reach_ The JVM is widely used. ClojureScript on JS is because JS also has reach.
pron 7y ago
ZGC is targeting 1ms max pause time now.

User23 7y ago

> Let me know of any other runtime platform that even comes > close to the things JVM does. Some of the more advanced Lisps would qualify.

pron 7y ago
No Lisp runtime currently has this quality of JIT compilers, GCs, and observability.
- madmax96 7y ago
  You should check out SBCL, it's competitive.
  - pron 7y ago
    It isn't. Perhaps you haven't seen what the JVM can do lately. It's got JIT compilers that do this[1], GCs that are getting close to 1ms max pause times on terabytes of heap [2], and low-overhead, in-production deep profiling [3]. Not to mention all of the classic capabilities of the JVM like hot code redefinition and exceptional monitoring. Lots of applications can certainly manage well without some or even all those things, and some want other tradeoffs (like no warmup or lower RAM footprint), but these days it's hard to compete with the JVM where it's strong. The technological gap between it and other runtimes is only growing. [1]: https://twitter.com/ChrisGSeaton/status/619885182104043520 https://twitter.com/ChrisGSeaton/status/619885182104043520 [2]: http://cr.openjdk.java.net/~pliden/slides/ZGC-Jfokus-2019.pdf http://cr.openjdk.java.net/~pliden/slides/ZGC-Jfokus-2019.pd... [3]: https://craftingjava.com/using-java-flight-recorder-with-openjdk-11/ https://craftingjava.com/using-java-flight-recorder-with-ope...
    - User23 7y ago
      And yet it still can't even do TCO
      - pron 7y ago
        Right. Different platforms have different priorities. But tail calls will be coming to the JVM eventually.
      - preordained 7y ago
        This is the dumbest thing in the universe (in context of a Clojure discussion) that I keep seeing parroted over and over. So you have to type "recur <args>" instead of the actual function name + <args> for the exact same effect. If you can get over that aesthetic "sin" then you have your TCO in effect. I don't even find it mildly inconvenient...and even prefer the "shortcut" syntax vs explicitly repeating my function name.
  - pepper_sauce 7y ago
    Do you have appropriate benchmarks? I would appreciate seeing the comparison.
    - DannyB2 7y ago
      Yes, benchmarks. But it's not just benchmarks. It's capabilities. He should please provide references that compare other runtime platforms' capabilities side by side with JVM's capabilities.
      - igouy 7y ago
        > provide references that compare other runtime platforms' capabilities side by side with JVM's capabilities How many weeks work do you imagine that would be?
        DannyB2 7y ago
        My point: if someone is going to assert that another platform is competitive with JVM, then not only is performance important, but capabilities as well. While no language / platform / os / etc is perfect, JVM as a managed runtime platform is hard to beat. More than two decades of research in its JIT compilers, and multiple GC implementations with various knobs and dials for tuning and monitoring. Battle tested. Someone mentioned SBCL. While I am a fan of Common Lisp, and generally all Lisps, I would cringe to see SBCL with terabytes of heap and hundreds of CPU cores running a serious workload -- and see how well it holds up. Just an example: You can Google for this, but in 2012 Twitter switched from Ruby on Rails to Java. They have YouTube videos explaining their change over. Basic reasons: performance and scalability. They have to handle BILLIONS of tweets per day and route each one to multiple places with notifications in near real time.
        lispm 7y ago
        > I would cringe to see SBCL with terabytes of heap and hundreds of CPU cores running a serious workload That's nothing SBCL can do, but one can save an executable and start that in a subsecond without the need for a terabyte of RAM. Generally there is a lot of stuff in the JVM which makes it less attractive as runtime for Lisp: more complex code loading via 'class loaders', lack of support for memory representation of Lisp's data types (like CLOS objects, which are more dynamic than Java classes), lack of TCO, lack of easy AOT compilation, lack of easy image dumps, lack of resumeable exceptions, ... And in 2019 something like Eclipse still is a bit clunky to run on my 8 core Xeon - part of the reason could be a less than great GUI implementation. In IntelliJ I need to restart my IDE for every simple plugin... probably features like live-updating haven't made it yet into popular apps.
  - User23 7y ago
    http://www.chiark.greenend.org.uk/doc/cmucl-docs/compiler-hint.html http://www.chiark.greenend.org.uk/doc/cmucl-docs/compiler-hi... is mostly applicable to SBCL last I checked. It gives an idea of what kind of cleverness the compiler can undertake.
DannyB2 7y ago
Then why is Clojure implemented on the JVM? As Rich Hickey says: because it has _reach_ The JVM is widely used. ClojureScript on JS is because JS also has reach.

pron 7y ago

ZGC is targeting 1ms max pause time now.