4 ms·

1. Sure, but JVM has a pretty state-of-the art GC tech developed for decades, so it is fair to draw comparisons to it. And it is still not even close to non-GCe

1. Sure, but JVM has a pretty state-of-the art GC tech developed for decades, so it is fair to draw comparisons to it. And it is still not even close to non-GCed languages, in particular when we also take memory use and pauses into account, not just throughput. Throughput, low latency, low memory use - there are inherent tradeoffs between them and usually you can pick only one to tune for. 2 - Not really. The fact they allow to allocate/deallocate manually is not enough. Dealing with non-GCed memory in Java or C# is much more error-prone and less ergonomic than even in C++. E.g. no automatic reference counting nor RAII. 3 - It is 5 years in development now and as far as the specs goes value types will be limited to immutable objects only, so it is inefficient by design and it solves only half of the problem. Similarly high hopes were associated with escape analysis which turned out to be totally ineffective.

pjmlp 6y ago
1 - Java is not the only game in town. 2 - automatic reference counting is slower than tracing GC. Strange to prefer something with less performance. RAII is possible in C# via IDispose (alongside Roslyn compiler errors for not using it properly) and FP patterns similar to -with in Common Lisp. 3 - It is a major engineering feat to design a feature that will work out of the box with 25 years old compiled jars without playing a Python 2 in the Java world. Naturally it takes its time to get right. Just like it took 10 years to get modules and concepts and they are still not available across all major C++ compilers. Good engineering takes time.
- pkolaczk 6y ago
  1 - The tradeoff between latency, throughput and memory-use of tracing GCs is universal and language-independent. Some implementations may be better than the others, but I haven't seen an implementation that is good in all three aspects. 2 - I've seen this repeated on the Internet many times, but there is little scientific evidence, and the one available is quite contradictory. I recall a paper where authors argued that replacing the old-gen collector with reference counting actually improved performance. So this is definitely not universally true, and depends on many factors such as imposed constraints on memory overhead and usage patterns. It is easy to make GC good when you only create short-lived objects and allow it to use 10x more memory than needed. But things get pretty hairy when you also want low-pauses and low memory overhead and objects live longer (e.g. cache-like use cases). Also the number of reference counted objects in C++/Rust programs is typically orders of magnitude lower than the number of GCed objects in GCed languages, so even if ref-counting was less efficient per-object lifetime, it is not globally less efficient. 3 - Agree, but "value types" have been present in C/C++/Rust/Swift/D/C# and dozens of other languages for ages, so, unless you're forced to work on a legacy Java project, why wait? You can become productive in Rust in less time than they will be able to ship Valhalla.
  - pjmlp 6y ago
    1 - Just like manual memory management isn't good in all aspects and before the FOSS wave there were companies whose only business was selling specialized versions of malloc()/free(). 2 - Really? Here is one to start with, https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages. Enjoy the RC high performance from Swift. Additional SIGPLAN and ACM papers can be provided. The fact is that when RC gets fine tuned for performance, it is a tracing GC in disguise, with its background threads for deferred releases, like C++/WinRT is currently doing with COM/UWP. 3 - It takes some time to catch up with 25 years of libraries, OS and IDE support
    - pkolaczk 6y ago
      2 - and your link only shows that Go, Java and C# have substantially lower performance than C and Rust on this task. So that doesn't refute my point. As I said, the whole trick relies on the fact that these languages don't need so much GC in the first place. Reference counting in Rust or C is something you do as the last resort. It doesnt matter it is slower per-single-object, when you have 1000x fewer objects. 3 - Mature doesn't mean all of it is always better. Take Cargo vs Maven/Gradle. Or libraries for async programming. Also not everything needs to be written from scratch.
      - pjmlp 6y ago
        Micro-benchmarks are meaningless if the project hard deadlines have been met and customer is happy with the result. The point of my link was about Swift RC performance, Rust and C aren't using it.
  - majewsky 6y ago
    > You can become productive in Rust in less time than they will be able to ship Valhalla. Yeah, but they'll ship Valhalla before you rewrite your existing 4M LOC Java application.
    - pkolaczk 6y ago
      Sure, but then when they finally ship Valhalla you'll still need to rewrite your 4M LOC Java app to use value types ;)

pjmlp 6y ago

1 - Java is not the only game in town. 2 - automatic reference counting is slower than tracing GC. Strange to prefer something with less performance. RAII is possible in C# via IDispose (alongside Roslyn compiler errors for not using it properly) and FP patterns similar to -with in Common Lisp. 3 - It is a major engineering feat to design a feature that will work out of the box with 25 years old compiled jars without playing a Python 2 in the Java world. Naturally it takes its time to get right. Just like it took 10 years to get modules and concepts and they are still not available across all major C++ compilers. Good engineering takes time.

pkolaczk 6y ago
1 - The tradeoff between latency, throughput and memory-use of tracing GCs is universal and language-independent. Some implementations may be better than the others, but I haven't seen an implementation that is good in all three aspects. 2 - I've seen this repeated on the Internet many times, but there is little scientific evidence, and the one available is quite contradictory. I recall a paper where authors argued that replacing the old-gen collector with reference counting actually improved performance. So this is definitely not universally true, and depends on many factors such as imposed constraints on memory overhead and usage patterns. It is easy to make GC good when you only create short-lived objects and allow it to use 10x more memory than needed. But things get pretty hairy when you also want low-pauses and low memory overhead and objects live longer (e.g. cache-like use cases). Also the number of reference counted objects in C++/Rust programs is typically orders of magnitude lower than the number of GCed objects in GCed languages, so even if ref-counting was less efficient per-object lifetime, it is not globally less efficient. 3 - Agree, but "value types" have been present in C/C++/Rust/Swift/D/C# and dozens of other languages for ages, so, unless you're forced to work on a legacy Java project, why wait? You can become productive in Rust in less time than they will be able to ship Valhalla.
- pjmlp 6y ago
  1 - Just like manual memory management isn't good in all aspects and before the FOSS wave there were companies whose only business was selling specialized versions of malloc()/free(). 2 - Really? Here is one to start with, https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages. Enjoy the RC high performance from Swift. Additional SIGPLAN and ACM papers can be provided. The fact is that when RC gets fine tuned for performance, it is a tracing GC in disguise, with its background threads for deferred releases, like C++/WinRT is currently doing with COM/UWP. 3 - It takes some time to catch up with 25 years of libraries, OS and IDE support
  - pkolaczk 6y ago
    2 - and your link only shows that Go, Java and C# have substantially lower performance than C and Rust on this task. So that doesn't refute my point. As I said, the whole trick relies on the fact that these languages don't need so much GC in the first place. Reference counting in Rust or C is something you do as the last resort. It doesnt matter it is slower per-single-object, when you have 1000x fewer objects. 3 - Mature doesn't mean all of it is always better. Take Cargo vs Maven/Gradle. Or libraries for async programming. Also not everything needs to be written from scratch.
    - pjmlp 6y ago
      Micro-benchmarks are meaningless if the project hard deadlines have been met and customer is happy with the result. The point of my link was about Swift RC performance, Rust and C aren't using it.
- majewsky 6y ago
  > You can become productive in Rust in less time than they will be able to ship Valhalla. Yeah, but they'll ship Valhalla before you rewrite your existing 4M LOC Java application.
  - pkolaczk 6y ago
    Sure, but then when they finally ship Valhalla you'll still need to rewrite your 4M LOC Java app to use value types ;)