4 ms·

the metrics have said otherwise. the golang team has implemented more sophisticated GC algorithms similar to the JVM's and the performance differences where neg

by 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.
    - jatone 5y ago
      regions have generations. its the same concept just partitioned to make the working sets smaller. there isn't anything fundamentally wrong with golangs GC. attempting to apply the solutions for the JVM to golang is fundamentally flawed and ignorant. the languages have fundamentally different approaches to memory allocations. and the reasons behind the JVM implementations simply do not exist in golang. the new pacer is in the works to attempt addressing many of the edge cases. https://github.com/golang/proposal/blob/master/design/44167-gc-pacer-redesign.md https://github.com/golang/proposal/blob/master/design/44167-... you seem to lack fundamental understanding of what the actual issues in the golang runtime are with relation to its GC.
      - pron 5y ago
        > attempting to apply the solutions for the JVM to golang is fundamentally flawed and ignorant. I'm not saying that Go should use GCs like Java's. I'm just saying that Go's GC does not work well enough for Go's needs, and that Java's GCs now deliver a better experience. Maybe Go needs something entirely different, but it does need something better than what it has now.

by jatone 5y ago

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.
  - jatone 5y ago
    regions have generations. its the same concept just partitioned to make the working sets smaller. there isn't anything fundamentally wrong with golangs GC. attempting to apply the solutions for the JVM to golang is fundamentally flawed and ignorant. the languages have fundamentally different approaches to memory allocations. and the reasons behind the JVM implementations simply do not exist in golang. the new pacer is in the works to attempt addressing many of the edge cases. https://github.com/golang/proposal/blob/master/design/44167-gc-pacer-redesign.md https://github.com/golang/proposal/blob/master/design/44167-... you seem to lack fundamental understanding of what the actual issues in the golang runtime are with relation to its GC.
    - pron 5y ago
      > attempting to apply the solutions for the JVM to golang is fundamentally flawed and ignorant. I'm not saying that Go should use GCs like Java's. I'm just saying that Go's GC does not work well enough for Go's needs, and that Java's GCs now deliver a better experience. Maybe Go needs something entirely different, but it does need something better than what it has now.