4 ms·

The irony is that Java removed its old Go-like collector (CMS = Concurrent Mark & Sweep) a couple of years ago, and its next-gen (G1) and next-next-gen (ZGC) co

by pron 5y ago

The irony is that Java removed its old Go-like collector (CMS = Concurrent Mark & Sweep) a couple of years ago, and its next-gen (G1) and next-next-gen (ZGC) collectors have improved so much in recent JDK versions (15 and up) that they require little if any tuning at all anymore.

kaba0 5y ago
I don’t think that ZGC is next-gen over G1, they just choose different tradeoffs. G1 is very good at throughput, and is very good at upholding its target pause times even under loads. But it doesn’t promise that low latencies as ZGC does, but latency is fundamentally one end of the spectrum, where the other end is throughput. But otherwise agree with you.
pjmlp 5y ago
jhgb 5y ago
To run adequately, Java most likely needs a better collector than Go in the first place because Go has sparser object graphs. A triangle with three XYZ points would be four contiguous objects in Java (if implemented as a class with three fields of another class) but only one in Go. On the other hand, Go needs to handle interior pointers. So the requirements for the collectors may not necessarily be the same.
- pron 5y ago
  That's true, but Go's GC, while possibly not needing to be quite as sophisticated as Java's, is still not sophisticated enough, even for Go's needs, to match Java's collectors' performance or convenience. Whether or not Go could actually come up with a collector to get Java-like behaviour for Go programs while being significantly simpler is still an open question.
  - deleted 5y ago
    [deleted]
  - jatone 5y ago
    the metrics have said otherwise. the golang team has implemented more sophisticated GC algorithms similar to the JVM's and the performance differences where negligible and had significant downsides. uber was able to solve there issue so the GC in golang seems perfectly fine.
    - pron 5y ago
      They did not experiment with anything remotely resembling Java's new GCs, but rather aspects of very old ones (they just tried a relatively simple generational GC). Go's poor performance relative to Java's on memory intensive applications is largely due to its primitive GC, which does not work perfectly fine for any challenging workload.
      - jatone 5y ago
        fundamentally they did, they implemented a generational GC. The optimizations the JVM does in the newer ones are well understood optimizations but don't address the root issues with implementing generational GC in golang. the issues was with the write barriers and requirements around moving data which can't be avoided in generational GC implementations because you have to move data and update pointers. most of the benefits of generational GC doesn't exist in golang because of escape analysis allocating data on the stack.
        pron 5y ago
        ZGC isn't currently generational and still outperforms Go's GC, and the benefits of Java's advanced collectors don't (just) come from their being generational. I agree Go has some difficulty with compaction among other things, but that only means that it will take some time to fix. Important Go workloads perform poorly because of its GC. I don't know what Go has to do to fix its GC, but it's not perfectly fine.

by pron 5y ago

kaba0 5y ago

I don’t think that ZGC is next-gen over G1, they just choose different tradeoffs. G1 is very good at throughput, and is very good at upholding its target pause times even under loads. But it doesn’t promise that low latencies as ZGC does, but latency is fundamentally one end of the spectrum, where the other end is throughput. But otherwise agree with you.

pjmlp 5y ago

jhgb 5y ago

To run adequately, Java most likely needs a better collector than Go in the first place because Go has sparser object graphs. A triangle with three XYZ points would be four contiguous objects in Java (if implemented as a class with three fields of another class) but only one in Go. On the other hand, Go needs to handle interior pointers. So the requirements for the collectors may not necessarily be the same.

pron 5y ago
That's true, but Go's GC, while possibly not needing to be quite as sophisticated as Java's, is still not sophisticated enough, even for Go's needs, to match Java's collectors' performance or convenience. Whether or not Go could actually come up with a collector to get Java-like behaviour for Go programs while being significantly simpler is still an open question.
- deleted 5y ago
  [deleted]
- jatone 5y ago
  the metrics have said otherwise. the golang team has implemented more sophisticated GC algorithms similar to the JVM's and the performance differences where negligible and had significant downsides. uber was able to solve there issue so the GC in golang seems perfectly fine.
  - pron 5y ago
    They did not experiment with anything remotely resembling Java's new GCs, but rather aspects of very old ones (they just tried a relatively simple generational GC). Go's poor performance relative to Java's on memory intensive applications is largely due to its primitive GC, which does not work perfectly fine for any challenging workload.
    - jatone 5y ago
      fundamentally they did, they implemented a generational GC. The optimizations the JVM does in the newer ones are well understood optimizations but don't address the root issues with implementing generational GC in golang. the issues was with the write barriers and requirements around moving data which can't be avoided in generational GC implementations because you have to move data and update pointers. most of the benefits of generational GC doesn't exist in golang because of escape analysis allocating data on the stack.
      - pron 5y ago
        ZGC isn't currently generational and still outperforms Go's GC, and the benefits of Java's advanced collectors don't (just) come from their being generational. I agree Go has some difficulty with compaction among other things, but that only means that it will take some time to fix. Important Go workloads perform poorly because of its GC. I don't know what Go has to do to fix its GC, but it's not perfectly fine.