为什么Go可以将GC暂停降低到1ms以下，而JVM却没有呢? [英] Why Go can lower GC pauses to sub 1ms and JVM has not?

问题描述

是这样的: https://groups.google.com/forum/? fromgroups#！topic/golang-dev/Ab1sFeoZg_8 :

今天，我向垃圾收集器提交了一些更改，这些更改使典型的最坏情况下的世界停止时间少于100微秒.对于具有许多活动goroutine的应用程序，这应该特别改善暂停，而以前可能会大大增加暂停时间.

Today I submitted changes to the garbage collector that make typical worst-case stop-the-world times less than 100 microseconds. This should particularly improve pauses for applications with many active goroutines, which could previously inflate pause times significantly.

如果JVM用户长期苦苦挣扎，GC暂停次数就会很高.

High GC pauses are one if the things JVM users struggle with for a long time.

什么是(体系结构上的)约束?这些约束阻止JVM将GC暂停降低到Go级别，但不影响Go?

What are the (architectural?) constraints which prevent JVM from lowering GC pauses to Go levels, but are not affecting Go?

推荐答案

什么是(体系结构上的)约束?这些约束阻止JVM将GC暂停降低到golang级别

What are the (architectural?) constraints which prevent JVM from lowering GC pauses to golang levels

没有.

如果JVM用户长期苦苦挣扎，GC暂停次数就会很高.

High GC pauses are one if the things JVM users struggle with for a long time.

稍作搜索就可以发现类似的解决方案也适用于Java

A little googling shows that similar solutions are available for java too

• Azul提供了可扩展的无暂停收集器甚至达到100GB +
• Redhat正在为openjdk和oracle shenandoah .openjdk.java.net/display/zgc/Main"rel =" noreferrer> zgc .
• IBM提供了节拍器，其目标还在于微秒的暂停时间
• 其他各种实时JVM

• Azul offers a pauseless collector that scales even to 100GB+
• Redhat is contributing shenandoah to openjdk and oracle zgc.
• IBM offers metronome, also aiming for microsecond pause times
• various other realtime JVMs

与Go的不同，openjdk中的其他收集器是压缩世代收集器.这是为了避免碎片问题，并通过启用凹凸指针分配并减少在GC中花费的CPU时间，在具有大堆的服务器级计算机上提供更高的吞吐量.至少在良好的条件下，尽管CMS与移动的年轻代收集器配对，也可以实现单位毫秒的暂停.

The other collectors in openjdk are, unlike Go's, compacting generational collectors. That is to avoid fragmentation problems and to provide higher throughput on server-class machines with large heaps by enabling bump pointer allocation and reducing the CPU time spent in GC. And at least under good conditions CMS can achieve single-digit millisecond pauses, despite being paired with a moving young-generation collector.

Go的收集器是非世代的，非紧凑的，并且需要写障碍(请参阅此

Go's collector is non-generational, non-compacting and requires write barriers (see this other SO question), which results in lower throughput/more CPU overhead for collections, higher memory footprint (fragmentation) and less cache-efficient placement of objects on the heap (non-compact memory layout).

这篇关于为什么Go可以将GC暂停降低到1ms以下，而JVM却没有呢?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！