3 ms·

No runtime has a better GC than Java's, certainly in the current version (14) which is worlds better than Java 8. The reason you don't think about it in other l

by pron 6y ago

No runtime has a better GC than Java's, certainly in the current version (14) which is worlds better than Java 8. The reason you don't think about it in other languages is because if you use other languages, you probably don't care too much about performance in the first place.

cogman10 6y ago
* better GCs (plural) Probably the best thing about the JVM that, AFAIK, no other platform does is it gives you an option for which GC you use. Not only is that an option, but you are spoiled with options. ZGC, G1GC, Shenandoah, The parallel collector, the serial collector. Pick the right one for the job! But beyond that, they are infinitely tuneable (Not that you should usually). Again, not something that almost any other platform offers.
nvarsj 6y ago
So if I care about performance, I would use the JVM? I spent years as a performance engineer on HFT trading systems tuning JVMs. It’s possible to get very good performance on the JVM, but it is also hard and for the layman almost impossible. Yes, it has great throughput, but only because it has to. The design of hotspot / JVM and the languages that run on it encourages massive heap allocations of gigabytes a second. I can’t think of any other language or runtime that is comparable in terms of its memory bloat. Even if you control allocations, and have happy path GCs, hotspot GC still causes occasional pauses of 10-100s milliseconds. And this is considered good. I know that lots of people have built careers on the JVM and defend it vigorously. Whenever I make a comment that is negative on the JVM, I always get downvoted without fail on HN. I used to be one of these people, after all, so I can relate. If I truly cared about performance these days, I’d use C++ or Rust. Otherwise, I’d use a language like golang with reasonable default GC behavior and allocation patterns - where I know the daemon I write won’t use more than 100-200Mb, and probably even less, and will typically have sub-ms pauses. I think even most scripting languages, like Ruby/Python, have reasonable memory usage and GC patterns for web development, but I’m not as familiar with them. I probably care more about energy consumption these days though. And again, the JVM is the worst offender. The average developer building a Java web app will create something which consumes gigabytes of memory usually. These apps tend to spend the majority of their CPU time allocating and GCing memory. I can only guess how much server time has been consumed to satiate the memory hungry needs of the JVM.
- pron 6y ago
  > So if I care about performance, I would use the JVM? No. If you use the JVM you might well care about performance. If you care about performance, you should consider the JVM. > I spent years as a performance engineer on HFT trading systems tuning JVMs. The JVM is not designed to give you 100% performance (of the ideal offered by the hardware). It's designed to give you the easiest means of achieving ~95%, provided you're OK with some nondeterminism. > I’d use a language like golang with reasonable default GC behavior and allocation patterns - where I know the daemon I write won’t use more than 100-200Mb, and probably even less, and will typically have sub-ms pauses. You'd be wrong, because JDK 14 will most likely give you substantially better performance than Go out of the box; JDK 15 and 16 even more so. BTW, the footprint and performance profile of JDK 14 is worlds apart from JDK 8. The JVM has been undergoing some very big changes in the last couple of years. > And again, the JVM is the worst offender Nope. https://greenlab.di.uminho.pt/wp-content/uploads/2017/09/paperSLE.pdf https://greenlab.di.uminho.pt/wp-content/uploads/2017/09/pap...
  - nvarsj 6y ago
    Thanks for the paper. The data tables for it just proves my point. For example, in the binary-trees test, Java used 1120 Mb. Go used 228, Rust used 180, Lisp used 373, Haskell used 494 Mb. Only Jruby and Erlang seem to require more memory usage. If a webapp performs similar to this experiment, I could rewrite it in almost any other language and I’d cut the required number of servers in half or more.
    - pron 6y ago
      Java absolutely requires more memory; less so in 14, but still. That does not, however, make your point about either performance or energy, both of which are wrong. > If a webapp performs similar to this experiment, I could rewrite it in almost any other language and I’d cut the required number of servers in half or more. Nope. Because you gain in performance where you lose on memory. If you add more RAM, you'd pay for less hardware and consume less energy. Anyway, if you last experienced Java in version 8, try 14. It's not what you might remember. You'd likely see a 10-40% reduction in cost-per-transaction, plus very low pauses with the new GCs. OpenJDK's VM in 14 is just significantly different from what it was in 8.
saberience 6y ago
Dotnet's GC is way better than Java, Java has been trying to catch up in recent years but it's still miles off.
- pjmlp 6y ago
  I do both since they exist, in no way is .NET GC able to handle multi-TB heaps with ms pauses. What helps .NET is the design since the early days to support value types and the introduction of Midori learnings into C# 7 and later for low level programming.

by pron 6y ago

cogman10 6y ago

* better GCs (plural) Probably the best thing about the JVM that, AFAIK, no other platform does is it gives you an option for which GC you use. Not only is that an option, but you are spoiled with options. ZGC, G1GC, Shenandoah, The parallel collector, the serial collector. Pick the right one for the job! But beyond that, they are infinitely tuneable (Not that you should usually). Again, not something that almost any other platform offers.

nvarsj 6y ago

So if I care about performance, I would use the JVM? I spent years as a performance engineer on HFT trading systems tuning JVMs. It’s possible to get very good performance on the JVM, but it is also hard and for the layman almost impossible. Yes, it has great throughput, but only because it has to. The design of hotspot / JVM and the languages that run on it encourages massive heap allocations of gigabytes a second. I can’t think of any other language or runtime that is comparable in terms of its memory bloat. Even if you control allocations, and have happy path GCs, hotspot GC still causes occasional pauses of 10-100s milliseconds. And this is considered good. I know that lots of people have built careers on the JVM and defend it vigorously. Whenever I make a comment that is negative on the JVM, I always get downvoted without fail on HN. I used to be one of these people, after all, so I can relate. If I truly cared about performance these days, I’d use C++ or Rust. Otherwise, I’d use a language like golang with reasonable default GC behavior and allocation patterns - where I know the daemon I write won’t use more than 100-200Mb, and probably even less, and will typically have sub-ms pauses. I think even most scripting languages, like Ruby/Python, have reasonable memory usage and GC patterns for web development, but I’m not as familiar with them. I probably care more about energy consumption these days though. And again, the JVM is the worst offender. The average developer building a Java web app will create something which consumes gigabytes of memory usually. These apps tend to spend the majority of their CPU time allocating and GCing memory. I can only guess how much server time has been consumed to satiate the memory hungry needs of the JVM.

pron 6y ago
> So if I care about performance, I would use the JVM? No. If you use the JVM you might well care about performance. If you care about performance, you should consider the JVM. > I spent years as a performance engineer on HFT trading systems tuning JVMs. The JVM is not designed to give you 100% performance (of the ideal offered by the hardware). It's designed to give you the easiest means of achieving ~95%, provided you're OK with some nondeterminism. > I’d use a language like golang with reasonable default GC behavior and allocation patterns - where I know the daemon I write won’t use more than 100-200Mb, and probably even less, and will typically have sub-ms pauses. You'd be wrong, because JDK 14 will most likely give you substantially better performance than Go out of the box; JDK 15 and 16 even more so. BTW, the footprint and performance profile of JDK 14 is worlds apart from JDK 8. The JVM has been undergoing some very big changes in the last couple of years. > And again, the JVM is the worst offender Nope. https://greenlab.di.uminho.pt/wp-content/uploads/2017/09/paperSLE.pdf https://greenlab.di.uminho.pt/wp-content/uploads/2017/09/pap...
- nvarsj 6y ago
  Thanks for the paper. The data tables for it just proves my point. For example, in the binary-trees test, Java used 1120 Mb. Go used 228, Rust used 180, Lisp used 373, Haskell used 494 Mb. Only Jruby and Erlang seem to require more memory usage. If a webapp performs similar to this experiment, I could rewrite it in almost any other language and I’d cut the required number of servers in half or more.
  - pron 6y ago
    Java absolutely requires more memory; less so in 14, but still. That does not, however, make your point about either performance or energy, both of which are wrong. > If a webapp performs similar to this experiment, I could rewrite it in almost any other language and I’d cut the required number of servers in half or more. Nope. Because you gain in performance where you lose on memory. If you add more RAM, you'd pay for less hardware and consume less energy. Anyway, if you last experienced Java in version 8, try 14. It's not what you might remember. You'd likely see a 10-40% reduction in cost-per-transaction, plus very low pauses with the new GCs. OpenJDK's VM in 14 is just significantly different from what it was in 8.

saberience 6y ago

Dotnet's GC is way better than Java, Java has been trying to catch up in recent years but it's still miles off.

pjmlp 6y ago
I do both since they exist, in no way is .NET GC able to handle multi-TB heaps with ms pauses. What helps .NET is the design since the early days to support value types and the introduction of Midori learnings into C# 7 and later for low level programming.