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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Shenandoah GC in production: experience report

173 点作者 truth_seeker大约 6 年前

9 条评论

ignoramous大约 6 年前
This is a super nice article with plenty of relevant talks and links. A HTTPS mirror: <a href="https:&#x2F;&#x2F;outline.com&#x2F;K96Geb" rel="nofollow">https:&#x2F;&#x2F;outline.com&#x2F;K96Geb</a><p>A presentation on Shenandoah by one of the principal developers (focuses on the how): <a href="https:&#x2F;&#x2F;youtube.com&#x2F;watch?v=4d9-FQZZoVA" rel="nofollow">https:&#x2F;&#x2F;youtube.com&#x2F;watch?v=4d9-FQZZoVA</a><p>Another presentation (focuses on the how, why, and when) at devoxx: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=VCeHkcwfF9Q" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=VCeHkcwfF9Q</a><p>Tangent: Go GC (generational, non-copying, concurrent mark and concurrent sweep) and the improvements it saw from 1.5 -&gt; 1.8 <a href="https:&#x2F;&#x2F;blog.golang.org&#x2F;ismmkeynote" rel="nofollow">https:&#x2F;&#x2F;blog.golang.org&#x2F;ismmkeynote</a><p>The mutator&#x2F;pacer scheme, the tri-color mark scheme, using rw-barriers during the sweep phase are interesting to contrast between the two GCs.
评论 #19886704 未加载
评论 #19887749 未加载
mcguire大约 6 年前
A quick note: Shenandoah is <i>not</i> generational, according to the article. Most bog-standard web apps (including REST thingys; not sure why the author calls out those) do strongly obey the generational hypothesis. For most web apps, in my experience, if you can tune your GC to serve the vast majority of your requests from a young generation, your latencies will be good, your performance will be good, your pauses will be infrequent and short, and plump unicorns and bunny rabbits will gather in your cubicle to share their rainbows.
评论 #19890680 未加载
评论 #19891568 未加载
评论 #19889361 未加载
评论 #19888379 未加载
grogers大约 6 年前
Does anyone have experiences with both ZGC and Shenandoah? It seems like they both have very similar goals (10 ms max pause) even though the implementation is quite different. So with both landing at about the same time, when would you prefer one or the other? Both seem like such a huge advance over G1 and so similar to each other that between them it doesn&#x27;t look like it matters much.<p>Our team is going to be targeting ZGC for the main reason that it&#x27;s included by default in JDK11. Yeah, builds of JDK11 with Shenandoah are available but it&#x27;s more work.
评论 #19887942 未加载
crawshaw大约 6 年前
Great to see the JVM experimenting with low-pause GC.<p>It looks like the maximum pauses of Shenandoah are still well over 1ms, which will still cause a lot of tail latency in services. (Go reached ~5ms max pauses a few releases ago, but there was still a significant improvement in the behavior of services when pauses were clamped at 100μms in more recent releases.)<p>Definitely the right direction. I hope future versions of Shenandoah will clamp GC pauses even lower.
评论 #19886130 未加载
评论 #19886284 未加载
评论 #19886483 未加载
评论 #19886499 未加载
评论 #19887252 未加载
foobarbazetc大约 6 年前
We use Shenandoah on every JVM we run and it’s amazing. Probably saves us 10k-20k a year on additional compute.<p>The devs are extremely responsive on the mailing list.
ajross大约 6 年前
Curmudgeon opinion, riffing off what I think is the most important takeaway from the linked article:<p>&gt; Garbage collection is by no means a solved problem.<p>I was reading articles like this one, about new ideas in JVM garbage collection, <i>literally two decades ago</i>. And it&#x27;s still &quot;not a solved problem&quot;.<p>I mean, it&#x27;s mostly solved. Managed heaps work great for lots of applications and have been very successful. But that last 5% has stretched out so long it seems almost like a joke. We&#x27;ll never get there, for the mythical &quot;there&quot; where GC overhead and latency isn&#x27;t an issue that needs to be tuned in deployment. And IMHO it&#x27;s time to start recognizing that fact instead of trying to make the JVM and .NET do what we get from explicit heaps in C and Rust. They just aren&#x27;t going to get there.
评论 #19886443 未加载
评论 #19888541 未加载
评论 #19886537 未加载
评论 #19886425 未加载
评论 #19886949 未加载
abalone大约 6 年前
<i>&gt; Throughput reduction is predictable, and it&#x27;s easy to plan for that — if your program runs 10% slower, bring up ~10% more servers; that&#x27;s about it. But long GC pauses are rapid and volatile; you can&#x27;t &quot;autoscale&quot; out of them, so in order to not fall over, you must allot extra resources to handle them.</i><p>Exactly. Long tail latency is often a more important server metric than throughput.<p>This is why I’m excited about Swift on the server. Unlike most other languages it uses automatic reference counting instead of pause the world garbage collection. That means consistent latency.
评论 #19889574 未加载
评论 #19887938 未加载
评论 #19890864 未加载
评论 #19887212 未加载
azhenley大约 6 年前
Here is a previous discussion about the Shenandoah GC from the Java 12 announcement: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=19435890" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=19435890</a>
nullwasamistake大约 6 年前
This article is great even for HN standards, thank you! Not much info on Shenandoah in prod yet