<p>TIL from Rustaceans that stack frames are part of most-to-all machine architectures and by extension caches and OS's.</p>
<p>Is there anything besides the current state of research that would prevent the compiler from gathering escape analysis data at compile time for the future garbage collector(s) and allocator(s) if, for example, runtime reflection were restricted?</p>
<hr/>**评论：**<br/><br/>jeffrallen: <pre><p>The Go compiler already does significant escape analysis, resulting in many allocations not creating GC load. See <a href="http://blog.rocana.com/golang-escape-analysis" rel="nofollow">http://blog.rocana.com/golang-escape-analysis</a>.</p></pre>dchapes: <pre><blockquote>
<p>The Go compiler already does significant escape analysis</p>
</blockquote>
<p>FYI, you can see the results of this if you do <code>go build -gcflags="-m"</code>.</p>
<p>The output will include lines of the form</p>
<pre><code>filename.go:90: leaking param: foo
filename.go:98: bar does not escape
filename.go:99: blah escapes to heap
</code></pre>
<p>where foo/bar/blah is the name of some parameter, variable, function call, etc.</p></pre>barosl: <pre><p>Just in case anyone's interested, the last case mentioned in the link above, which is:</p>
<pre><code>package main
type S struct {
M *int
}
func main() {
var x S
var i int
ref(&i, &x)
}
func ref(y *int, z *S) {
z.M = y
}
</code></pre>
<p>can be translated into Rust like:</p>
<pre><code>struct S<'a> {
m: &'a i32,
}
fn main() {
let i = 0;
let mut x: S = unsafe { std::mem::uninitialized() };
ref_(&i, &mut x); // I could not use `ref` because it is a keyward in Rust!
}
fn ref_<'a>(y: &'a i32, z: &mut S<'a>) {
z.m = y;
}
</code></pre>
<p>which only uses stack allocation. The magic is in here:</p>
<pre><code>fn ref_<'a>(y: &'a i32, z: &mut S<'a>)
</code></pre>
<p>which means "for a random lifetime named <code>'a</code>, the reference <code>y</code> must live as long as the references inside the struct <code>z</code>. In this way you can tell the compiler what your intent is, and the compiler verifies this.</p></pre>jeffrallen: <pre><p>Interesting feature, thanks for sharing.</p>
<p>However, I call EBADMAGIC on that magic. It does not pass the "my colleagues would be smart enough to understand and modify it" test. Every line of systems which are written and maintained in teams need to pass that test. Languages like Go manage, just barely, depending on how stupid you think your colleagues are. (Careful... they are applying the test to every line THEY write, and they think you're awfully stupid too.)</p>
<p>-jeff</p></pre>barosl: <pre><p>I think I can understand your sentiment, but I see the opposite thing: my colleagues and I are <em>helped</em> by the lifetime annotations, exactly because we are not smart enough. Yes, there are inherent difficulties in those additional type system features, but (1) I'm not the smartest person in my team, but still can use them; so I believe my colleagues can do better than me. And (2) if something goes wrong, it will simply not compile; so even though some (probably most!) people may struggle when they start learning how to manipulate lifetime annotations, they can't screw up the system. The compiler is a very solid learning material. So I guess, my version of the test is, "my colleagues and I <em>don't have to be</em> smart to use them." And lifetime annotations fit that criterion, in my opinion.</p></pre>
