<story><title>Sub-10 ms Latency in Java: Concurrent GC with Green Threads</title><url>https://jet-start.sh/blog/2020/08/05/gc-tuning-for-jet</url></story><parent_chain><item><author>darksaints</author><text>Don&amp;#x27;t forget scanning. Yes, moving blocks of memory around is expensive, but it can also be done concurrently. Scanning, AFAIK, cannot be done concurrently, and thus remains the primary blocker to lower latency. And scanning is something that is entirely eliminated with static memory management.</text></item><item><author>dan-robertson</author><text>The part of GC which causes the most latency issues is compaction rather than merely collection. Using a language like rust won’t help if you have memory fragmentation and indeed allocation tends to be much faster with a GC than with malloc. I think the advantages of rust are more to do with often avoiding heap allocation entirely (and predictably) or value semantics leading to fewer small allocations or the language’s semantics not forcing you to choose between more reliable allocation-heavy immutable-everything code and faster harder-to-think-about mutation-heavy code.</text></item><item><author>jakewins</author><text>For years of my life, all I thought about was stuff like this. If you&amp;#x27;ve ever ran latency sensitive systems on the JVM.. man is it ever a pain.&lt;p&gt;Who was it that turned GC off entirely, minimized allocation and just restarted their VMs when they ran out of RAM every couple of hours, was that Netflix?&lt;p&gt;Either way. It makes me excited for Rust and the languages it&amp;#x27;ll inspire, all this labor gone away.</text></item></parent_chain><comment><author>pron</author><text>Scanning is most certainly done concurrently with ZGC. Even root scanning is on its way to become fully concurrent, which is why we&amp;#x27;re nearing the goal of &amp;lt;1ms latency.</text></comment>
<story><title>Sub-10 ms Latency in Java: Concurrent GC with Green Threads</title><url>https://jet-start.sh/blog/2020/08/05/gc-tuning-for-jet</url></story><parent_chain><item><author>darksaints</author><text>Don&amp;#x27;t forget scanning. Yes, moving blocks of memory around is expensive, but it can also be done concurrently. Scanning, AFAIK, cannot be done concurrently, and thus remains the primary blocker to lower latency. And scanning is something that is entirely eliminated with static memory management.</text></item><item><author>dan-robertson</author><text>The part of GC which causes the most latency issues is compaction rather than merely collection. Using a language like rust won’t help if you have memory fragmentation and indeed allocation tends to be much faster with a GC than with malloc. I think the advantages of rust are more to do with often avoiding heap allocation entirely (and predictably) or value semantics leading to fewer small allocations or the language’s semantics not forcing you to choose between more reliable allocation-heavy immutable-everything code and faster harder-to-think-about mutation-heavy code.</text></item><item><author>jakewins</author><text>For years of my life, all I thought about was stuff like this. If you&amp;#x27;ve ever ran latency sensitive systems on the JVM.. man is it ever a pain.&lt;p&gt;Who was it that turned GC off entirely, minimized allocation and just restarted their VMs when they ran out of RAM every couple of hours, was that Netflix?&lt;p&gt;Either way. It makes me excited for Rust and the languages it&amp;#x27;ll inspire, all this labor gone away.</text></item></parent_chain><comment><author>wokkel</author><text>Yes it can. Stop the world collection is a thing of the past. See for example: &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;developers.redhat.com&amp;#x2F;blog&amp;#x2F;2019&amp;#x2F;06&amp;#x2F;27&amp;#x2F;shenandoah-gc-in-jdk-13-part-1-load-reference-barriers&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;developers.redhat.com&amp;#x2F;blog&amp;#x2F;2019&amp;#x2F;06&amp;#x2F;27&amp;#x2F;shenandoah-gc-...&lt;/a&gt;</text></comment>