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

科技回声

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

GitHubTwitter

首页

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

资源链接

HackerNews API原版 HackerNewsNext.js

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

Techniques for investigating untypical Go memory leaks

27 点作者 pavfarb大约 8 年前

5 条评论

leovonl大约 8 年前
&quot;When we&#x27;ve initially started [..], dominant was Go 1.3, which had mechanisms to detect memory blocks allocated inside used libraries and all such blocks were to be freed by GC. Go 1.6 significantly improved its memory management, however as part of those improvements memory allocated by external libraries was no longer garbage collected by the runtime.&quot;<p>This looks like a serious API break.<p>To be fair, the whole idea of the runtime automagically managing external memory gives me shivers, and this looks like moving in the right direction - I just think it was not very wise to go with that initial decision in the first place.
评论 #13772764 未加载
评论 #13772153 未加载
ankurdhama大约 8 年前
&quot;var output = (*byte)(unsafe.Pointer(m))&quot; This will give you the pointer to the byte slice object which may have its own structure which is opaque to you and this is not same as &quot;getting the pointer to C byte array&quot;. It is weird that it was producing correct results at all :)
giantahead大约 8 年前
Techniques for noticing you&#x27;re almost shooting yourself in the leg, then suddenly saving the situation very last moment, mi amigo :)
yandrypozo大约 8 年前
This remember me one of the Go Proverbs, Cgo is not Go <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=PAAkCSZUG1c&amp;t=12m37s" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=PAAkCSZUG1c&amp;t=12m37s</a>
评论 #13772165 未加载
bkeroack大约 8 年前
Don&#x27;t use cgo (or any dependencies that use it) if you can at all avoid doing so.
评论 #13772173 未加载