4 ms·
You are comparing very old Java if you had to touch anything else than heap size. Especially that Java's GCs are by far the very very best, everything else is
by gf000 2y ago
You are comparing very old Java if you had to touch anything else than heap size.
Especially that Java's GCs are by far the very very best, everything else is significantly behind (partially because other platforms may not be as reliant on object allocation, but it depends on your usecase)
- schmichael 2y agoThis is absolutely true! I haven’t stared at a JVM GC graph is over 8 years.
- naasking 2y agoI wonder how much of that is truly GC improvements vs. increased hardware speed dropping pause times.
- adgjlsfhk1 2y agoWith traditional low latency GC designs (e.g. Shenandoah/G1), faster hardware provides almost no benefit because the GC pause is based around the time for core to core communication which hasn't decreased much (since we keep adding extra cores so the fight has to be to keep it from getting slower)
- naasking 2y agoThe benchmarks don't necessarily use all of the cores though, and memory bandwidth has increased considerably since those original benchmarks, so you should expect pause times to decrease from that alone.
- neonsunset 2y ago.NET is not far behind at all. It is also better at heap size efficiency and plays nicely with interop. Plus the fact that the average allocation traffic is much lower in .NET applications on comparable code than in Java also helps.
- hiddew 2y agoYou can use GC defaults, but tuning can provide valuable throughput or latency improvements for the application if you tune the GC parameters according to the workload. Especially latency sensitive applications may benefit from generational ZGC in modern JVMs.