4 ms·

The OpenJDK JVM (aka Hotspot) addresses both issues: control [1] and monitoring [2] (there are built-in compilation and deoptimization events emitted to the eve

by pron 7y ago

The OpenJDK JVM (aka Hotspot) addresses both issues: control [1] and monitoring [2] (there are built-in compilation and deoptimization events emitted to the event stream). You can also compile methods in advance [3], and inspect the generated machine code when benchmarking [4]. You can even compile an entire application ahead-of-time [5] to produce a native binary. [1]: https://docs.oracle.com/en/java/javase/14/vm/compiler-control1.html https://docs.oracle.com/en/java/javase/14/vm/compiler-contro... [2]: https://docs.oracle.com/en/java/javase/14/jfapi/why-use-jfr-api.html https://docs.oracle.com/en/java/javase/14/jfapi/why-use-jfr-... [3]: https://docs.oracle.com/en/java/javase/14/docs/specs/man/jaotc.html https://docs.oracle.com/en/java/javase/14/docs/specs/man/jao... [4]: http://psy-lob-saw.blogspot.com/2015/07/jmh-perfasm.html http://psy-lob-saw.blogspot.com/2015/07/jmh-perfasm.html [5]: https://www.graalvm.org/docs/reference-manual/native-image/ https://www.graalvm.org/docs/reference-manual/native-image/

amelius 7y ago
The GC is still nondeterministic though.
- tomp 7y ago
  So is malloc
  - amelius 7y ago
    True, but the bounds are much better.
  - pkolaczk 7y ago
    It is much easier to avoid malloc writing C than to avoid new in Java.
    - tomp 7y ago
      Nothing to do with GC though. It's also fairly easy to avoid `new` in Go and C#.
      - pkolaczk 7y ago
        To some degree, probably. Structs have many limitations though and two different argument passing semantics in the same language mean more complexity. Also you may be lucky to eliminate allocations in your own code, but what about libraries? Existence of GC shepherds programmers and library creators into heap allocation. You don't need to write new explicitly to allocate on the heap. Also high level languages with no GC make manual memory management much more usable and provide way better ergonomics in this area, just because they have to. E.g. automated reference counting, ownership/lifetime control, move semantics etc.
        pjmlp 7y ago
        Automated reference counting is a garbage collection algorithm, and it is possible to have ownership/lifetime control without giving up on GC, Chapel, ParaSail, Haskell, OCaml, Swift, D are following up exactly this path.
        pkolaczk 7y ago
        How do you avoid heap allocations in Haskell? Automated reference counting is technically a GC, but a kind of GC that can be enabled only for a subset of objects. In languages which force GC on everything (even reference counted GC) the incentive to provide abstractions that work without GC are much weaker. It is just hard to opt-out from GC once you have it and once all your stdlib relies on it. I thing D learned it the hard way.
        pjmlp 7y ago
        Stack and register allocation in Haskell is under compiler control via escape analysis, however you can allocate native heap outside GC via mallocBytes/allocaBytes/free, and if they get integrated into mainstream GHC, linear types. Besides, plenty of GC enabled languages offer the option to stack allocate, static global allocations, or native heap. Some examples, including languages that for whatever reason failed on the mainstream market. D, C#, Swift, Oberon, Oberon-2, Active Oberon, Component Pascal, Mesa/Cedar, Sing#, System C#, Nim, Modula-2+, Modula-3, VB, Xojo, C++ (via C++/CLI, C++/CX and Unreal C++), Common Lisp.
- pron 7y ago
  True, but few people care with ZGC [1] well on its way to having worst-case latencies of under 1ms (as soon as this year) on heaps up to 16TB in size. We're getting to the point where jitter due to GC is no larger than jitter introduced by the OS, so the only real cost is footprint. [1]: https://wiki.openjdk.java.net/display/zgc/Main https://wiki.openjdk.java.net/display/zgc/Main
  - amelius 7y ago
    This is great. Some practical downsides though: it's not available for all architectures (e.g. WebAssembly); the license is GPL, which makes this unsuitable for some applications; and finally the project is run by Oracle, which is reason for some to avoid this project.
    - pron 7y ago
      The architectures, license (GPL + classpath exception; i.e. it is not viral), and Oracle's leadership of OpenJDK has worked well for many companies for years, like Amazon, Google, Netflix and Apple, that base much or most of their infrastructure on it.
      - amelius 7y ago
        > GPL + classpath exception This seems only useful if you want to use the VM, not if you want to embed it into your own application. But the whole classpath exception clause is confusing to me (and from what I see I'm not the only one). I just want to write code, as opposed to interpreting licenses ... I.e., exactly why I would avoid this project, regardless of any good intentions from the side of the project team.
        deleted 7y ago
        [deleted]
        pron 7y ago
        It's OK, some things are not for everyone; some people avoid Linux, that has a similar license -- perhaps even more complex when you consider gcc and glibc -- for similar reasons. The GPLv2+CPE license has been around for over a decade and is used by one of the largest and most successful open-source projects that, in turn, is used by millions of developers and the world's largest companies.
- zamalek 7y ago
  The GC amortizes the cost of allocation. Allocation is expensive even in manually allocated languages. The real problem with the GC is that it leads people to believe that they don't need to be considerate about how they are using memory.
zamalek 7y ago
The article [incorrectly] equates all JITs with the author's experience with V8. The article even states "faster than python, but slower than Java" which makes no sense because Java is a JITted language.

by pron 7y ago

amelius 7y ago

The GC is still nondeterministic though.

tomp 7y ago
So is malloc
- amelius 7y ago
  True, but the bounds are much better.
- pkolaczk 7y ago
  It is much easier to avoid malloc writing C than to avoid new in Java.
  - tomp 7y ago
    Nothing to do with GC though. It's also fairly easy to avoid `new` in Go and C#.
    - pkolaczk 7y ago
      To some degree, probably. Structs have many limitations though and two different argument passing semantics in the same language mean more complexity. Also you may be lucky to eliminate allocations in your own code, but what about libraries? Existence of GC shepherds programmers and library creators into heap allocation. You don't need to write new explicitly to allocate on the heap. Also high level languages with no GC make manual memory management much more usable and provide way better ergonomics in this area, just because they have to. E.g. automated reference counting, ownership/lifetime control, move semantics etc.
      - pjmlp 7y ago
        Automated reference counting is a garbage collection algorithm, and it is possible to have ownership/lifetime control without giving up on GC, Chapel, ParaSail, Haskell, OCaml, Swift, D are following up exactly this path.
        pkolaczk 7y ago
        How do you avoid heap allocations in Haskell? Automated reference counting is technically a GC, but a kind of GC that can be enabled only for a subset of objects. In languages which force GC on everything (even reference counted GC) the incentive to provide abstractions that work without GC are much weaker. It is just hard to opt-out from GC once you have it and once all your stdlib relies on it. I thing D learned it the hard way.
        pjmlp 7y ago
        Stack and register allocation in Haskell is under compiler control via escape analysis, however you can allocate native heap outside GC via mallocBytes/allocaBytes/free, and if they get integrated into mainstream GHC, linear types. Besides, plenty of GC enabled languages offer the option to stack allocate, static global allocations, or native heap. Some examples, including languages that for whatever reason failed on the mainstream market. D, C#, Swift, Oberon, Oberon-2, Active Oberon, Component Pascal, Mesa/Cedar, Sing#, System C#, Nim, Modula-2+, Modula-3, VB, Xojo, C++ (via C++/CLI, C++/CX and Unreal C++), Common Lisp.
pron 7y ago
True, but few people care with ZGC [1] well on its way to having worst-case latencies of under 1ms (as soon as this year) on heaps up to 16TB in size. We're getting to the point where jitter due to GC is no larger than jitter introduced by the OS, so the only real cost is footprint. [1]: https://wiki.openjdk.java.net/display/zgc/Main https://wiki.openjdk.java.net/display/zgc/Main
- amelius 7y ago
  This is great. Some practical downsides though: it's not available for all architectures (e.g. WebAssembly); the license is GPL, which makes this unsuitable for some applications; and finally the project is run by Oracle, which is reason for some to avoid this project.
  - pron 7y ago
    The architectures, license (GPL + classpath exception; i.e. it is not viral), and Oracle's leadership of OpenJDK has worked well for many companies for years, like Amazon, Google, Netflix and Apple, that base much or most of their infrastructure on it.
    - amelius 7y ago
      > GPL + classpath exception This seems only useful if you want to use the VM, not if you want to embed it into your own application. But the whole classpath exception clause is confusing to me (and from what I see I'm not the only one). I just want to write code, as opposed to interpreting licenses ... I.e., exactly why I would avoid this project, regardless of any good intentions from the side of the project team.
      - deleted 7y ago
        [deleted]
      - pron 7y ago
        It's OK, some things are not for everyone; some people avoid Linux, that has a similar license -- perhaps even more complex when you consider gcc and glibc -- for similar reasons. The GPLv2+CPE license has been around for over a decade and is used by one of the largest and most successful open-source projects that, in turn, is used by millions of developers and the world's largest companies.
zamalek 7y ago
The GC amortizes the cost of allocation. Allocation is expensive even in manually allocated languages. The real problem with the GC is that it leads people to believe that they don't need to be considerate about how they are using memory.

zamalek 7y ago

The article [incorrectly] equates all JITs with the author's experience with V8. The article even states "faster than python, but slower than Java" which makes no sense because Java is a JITted language.