<story><title>Memory leak proof every C program</title><url>https://flak.tedunangst.com/post/memory-leak-proof-every-C-program</url></story><parent_chain><item><author>rco8786</author><text>Reminds me of the HFT shop that built in Java and simply turned the garbage collector off. Then when the market closed they would restart the process for the next day.</text></item><item><author>enriquto</author><text>This is the core idea:&lt;p&gt;&amp;gt; It is [...] entirely optional to call free. If you don’t call free, memory usage will increase over time, but technically, it’s not a leak. As an optimization, you may choose to call free to reduce memory, but again, strictly optional.&lt;p&gt;This is beautiful!  Unless your program is long-running, there&amp;#x27;s no point of ever calling free in your C programs.  The system will free the memory for you when the program ends.  Free-less C programming is an exhilarating experience that I recommend to anybody.&lt;p&gt;In the rare cases where your program needs to be long-running, leaks may become a real problem.  In that case, it&amp;#x27;s better to write a long-running shell script that calls a pipeline of elegant free-less C programs.</text></item></parent_chain><comment><author>JB_Dev</author><text>I’ve done something similar in one of our production services. There was a problem with extremely long GC pauses during Gen2 garbage collection (.NET uses a multigenerational GC design). Pauses could be many seconds long or more than a minute in extreme cases.&lt;p&gt;We found the underlying issue that caused memory pressure in the Gen2 region but the fix was to change some very fundamental aspects of the service and would need to have some significant refactoring. Since this was a legacy service (.net framework) that we were refactoring anyway to run in new .NET (5+), we decided to ignore the issue.&lt;p&gt;Instead we adjusted the GC to just never do the expensive Gen2 collections (GCLatencyMode) and moved the service to run on higher memory VMs. It would hit OOM every 3 days or so, so we just set instances to auto-restart once a day.&lt;p&gt;Then 1 year later we deployed the replacement for the legacy service and the problem was solved.</text></comment>
<story><title>Memory leak proof every C program</title><url>https://flak.tedunangst.com/post/memory-leak-proof-every-C-program</url></story><parent_chain><item><author>rco8786</author><text>Reminds me of the HFT shop that built in Java and simply turned the garbage collector off. Then when the market closed they would restart the process for the next day.</text></item><item><author>enriquto</author><text>This is the core idea:&lt;p&gt;&amp;gt; It is [...] entirely optional to call free. If you don’t call free, memory usage will increase over time, but technically, it’s not a leak. As an optimization, you may choose to call free to reduce memory, but again, strictly optional.&lt;p&gt;This is beautiful!  Unless your program is long-running, there&amp;#x27;s no point of ever calling free in your C programs.  The system will free the memory for you when the program ends.  Free-less C programming is an exhilarating experience that I recommend to anybody.&lt;p&gt;In the rare cases where your program needs to be long-running, leaks may become a real problem.  In that case, it&amp;#x27;s better to write a long-running shell script that calls a pipeline of elegant free-less C programs.</text></item></parent_chain><comment><author>tombert</author><text>I had a friend who worked for one of the big Market Makers, and he told me that they would indeed turn the GC off, but what they&amp;#x27;d do is just pre-allocate everything into bigass arrays before-hand, and have incrementers to simulate the &amp;quot;new&amp;quot; keyword. They might do this in something more or less like a threadlocal to avoid having to deal with locks or race conditions or anything like that.</text></comment>