<story><title>ZGC – What&apos;s new in JDK 16</title><url>https://malloc.se/blog/zgc-jdk16</url></story><parent_chain><item><author>modeless</author><text>1 ms pause times are pretty good. That&amp;#x27;s finally getting close to the point where it may no longer be the biggest factor preventing adoption in applications like core game engine code. Although at 144 Hz it&amp;#x27;s still 14% of your frame time, so it&amp;#x27;s hardly negligible.&lt;p&gt;Even if the GC is running on an otherwise idle core there are still other costs like power consumption and memory bandwidth. So you still want to minimize allocation to keep the GC workload down.&lt;p&gt;For too long GC people were touting 10 ms pause times as &amp;quot;low&amp;quot; and not bothering to go further, but truly low pause times &lt;i&gt;are&lt;/i&gt; possible. I&amp;#x27;d love to see a new systems language that &lt;i&gt;starts&lt;/i&gt; by designing for extremely low-pause GC, not manual allocation or a borrow checker. I think it would be possible to make something that you could use for real time work without having to compromise on memory safety and without having to pay the complexity tax Rust takes on for the borrow checker.</text></item></parent_chain><comment><author>moonchild</author><text>&amp;gt; at 144 Hz it&amp;#x27;s still 14% of your frame time, so it&amp;#x27;s hardly negligible&lt;p&gt;A single skipped frame is not a big deal and will probably not be noticed.  It will probably happen anyway due to scheduling quirks, resource contention with other processes, existing variation in frametime...&lt;p&gt;True realtime work requires no dynamic allocations whatsoever (which, notably, is not covariant with gc!), so I think ‘low’ pause times are an acceptable compromise.  Where performance is a concern, you need to manually manage a lot of factors, among them GC&amp;#x2F;dynamic memory use.  There&amp;#x27;s no runtime that can obviate that.&lt;p&gt;Granted, 1ms pause times are probably still not low enough for realtime audio, and there may be room for some carelessness there (audio being soft realtime, not hard realtime).  But I think just being careful to avoid dynamic allocation on the audio thread is probably a worthwhile tradeoff.</text></comment>
<story><title>ZGC – What&apos;s new in JDK 16</title><url>https://malloc.se/blog/zgc-jdk16</url></story><parent_chain><item><author>modeless</author><text>1 ms pause times are pretty good. That&amp;#x27;s finally getting close to the point where it may no longer be the biggest factor preventing adoption in applications like core game engine code. Although at 144 Hz it&amp;#x27;s still 14% of your frame time, so it&amp;#x27;s hardly negligible.&lt;p&gt;Even if the GC is running on an otherwise idle core there are still other costs like power consumption and memory bandwidth. So you still want to minimize allocation to keep the GC workload down.&lt;p&gt;For too long GC people were touting 10 ms pause times as &amp;quot;low&amp;quot; and not bothering to go further, but truly low pause times &lt;i&gt;are&lt;/i&gt; possible. I&amp;#x27;d love to see a new systems language that &lt;i&gt;starts&lt;/i&gt; by designing for extremely low-pause GC, not manual allocation or a borrow checker. I think it would be possible to make something that you could use for real time work without having to compromise on memory safety and without having to pay the complexity tax Rust takes on for the borrow checker.</text></item></parent_chain><comment><author>The_rationalist</author><text>&lt;i&gt;Although at 144 Hz it&amp;#x27;s still 14% of your frame time&lt;/i&gt; well if we believe their numbers, the &lt;i&gt;worst case&lt;/i&gt; is 0.5ms so 6% of frame time for 144hz. Assuming their stated average pause time of 0.05ms then average pauses (and the GC isn&amp;#x27;t constantly pausing) take 0.6% of frametime, which &lt;i&gt;is&lt;/i&gt; negligible.
Though your concerns on throughput and resource usages stands.
Well newer programming languages could leverage ZGC (and improve upon it) by targeting graalVM + it enable cross-language interop.</text></comment>