TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Visualising the Go garbage collector

148 点作者 davecheney将近 11 年前

4 条评论

userbinator将近 11 年前
The vaguely sawtooth-looking waves are pretty characteristic of all GC operation. If you look at typical GC graphs of the JVM or CLR, they look very similar - but this one has a difference I&#x27;ll try to explain below:<p>In this case the workload doesn&#x27;t look particularly suited to GC - notice the scvg.inuse line (light blue) spends more time at its lowest value than climbing or at the top, meaning that more time is spent holding onto memory that is not in use than actually using it... the difference between scvg.consumed and scvg.inuse essentially represents wasted memory. Estimating roughly, the process appears to be using 100% more memory than it needs to for 66% of the time, and 20% more for the other 33% for an average of ~70% (you can use an integral to get the exact average.)<p>Most of the JVM GC graphs I&#x27;ve seen are much &quot;pointier&quot; at the bottom, indicating that immediately after a GC cycle the allocations resume again so there is far less time where memory is allocated but not in use. The average between used and allocated memory is closer to 50% in that case.
评论 #8019866 未加载
twotwotwo将近 11 年前
An interesting GC-related find earlier this week: it can help a lot to allocate in large chunks when you can:<p><a href="https://plus.google.com/+ChandraSekarS0/posts/MNMWAXr63qz" rel="nofollow">https:&#x2F;&#x2F;plus.google.com&#x2F;+ChandraSekarS0&#x2F;posts&#x2F;MNMWAXr63qz</a><p>Note that the entire chunk stays &quot;alive&quot; while any element in it is reachable, so this only works when arena allocation would in a non-GC&#x27;d language, i.e., when you&#x27;re going to free the entire chunk at once (or in those rare cases you never need it reclaimed, e.g., &#x27;cause it&#x27;s a big fixed-size pool that you&#x27;ll recycle forever).<p>To my surprise, allocating big chunks performed better than a Pool or manual recycling in this case. My best guess, and the author&#x27;s, is that fewer allocations meant less space on memory-allocator bookkeeping (so fewer GCs) and less time spent sweeping in each GC.<p>If anyone&#x27;s more aware of the guts of the runtime than I am and can confirm or disconfirm or elaborate, I&#x27;m curious.
Intermernet将近 11 年前
Nice! and in 325 LOC :-)<p>This tool (or something like it) has been asked for a few times on Stack Overflow. I can see that many people will find this useful.
评论 #8021215 未加载
zameericle将近 11 年前
great tool and and excellent code read. Thanks for sharing.