In case someone else is wondering: What is being called "mid-stack inlining" here is what is generally understood by the term "inlining".
This is absolutely fantastic work.<p>Since I've learned about continuation passing style (which Go channels could <i>probably</i> be formally transformed into), I've been convinced that there's a better way to do codegen. Better calling convention, better stack representation, better instruction architecture; I'm not yet sure - it's a nag continuously at the back of my mind, almost as though it's at the tip of my tongue. In this specific case, it must <i>surely</i> be possible to inline a continuation with some foreign architecture. I'd <i>love</i> to see some literature on the more experimental end of this stuff, if anyone has it.
Jvm/java had that for a while in its JIT - it's nice to see it to coming to Golang.<p>Byproduct of that could be little hacky things like this below that make code faster by restructuring code a little<p><a href="https://techblug.wordpress.com/2013/08/19/java-jit-compiler-inlining/" rel="nofollow">https://techblug.wordpress.com/2013/08/19/java-jit-compiler-...</a>
What impact would that have on build times? I know a lot of work has gone into getting back to 1.4 build times, but would the added work of inlining prolong builds?
The presentation redacted the stats about how this affects Google performance. I bet it saves enough CPU hours to pay the author's salary many many many times over. Good job!
This is interesting work!<p>That said, it's a little disappointing when runtimes require custom algorithms or metadata to walk the stack and construct a stack trace. It makes it harder to build debuggers that grok the state of multiple runtimes (e.g., the Go code and the C code in the same program). This also affects runtime tracing tools like DTrace, which by construction can't rely on runtime support for help.