New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/compile: better escape analysis documentation #23109

Open
mdempsky opened this Issue Dec 12, 2017 · 9 comments

Comments

Projects
None yet
5 participants
@mdempsky
Member

mdempsky commented Dec 12, 2017

Despite repeated efforts, I'm still confused by our escape analysis code. Also, based on discussion with other compiler devs, apparently this difficulty understanding is not unique to me. It would be good to better document this code so we can hopefully simplify and improve it.

Some specific questions I've had trying to understand the code:

  • The "Escape analysis" documentation has a very high-level explanation, but leaves me with more questions than answers:

    • It mixes discussion of "nodes" and "variables," which makes it unclear to me whether expressions other than ONAME Nodes are present in the flow graph. (I think they are, otherwise I can't make sense of how we know if new(T) can be stack allocated or not.) It also talks about "values" having addresses, when only variables do. Using terminology consistent with the Go spec would help, IMO.

    • It mentions storing edges between "pointer-containing nodes". It would be nice to understand how this is expected to work in the presence of unsafe.Pointer <-> uintptr conversions.

    • Pseudo-code like flow(closure, &var) is confusing too: what's the & here supposed to signify?

    • I can't make sense of the phrase "tags all variables of it can reach an & node as escaping".

  • The Level godocs are super opaque to me:

    • I kind of understand the meaning of value, but I don't completely understand why adding the +1 and -1 values is sound.

    • I have no idea what a "maximum-copy-started-suffix-level" is, and the x.left.left, &Node{x}, etc. examples don't really help. I'm particularly confused because a Node can represent so many different operations depending on the Op, and I'm lost on what semantic meaning we're divining from syntactic tree depth.

  • escAnalyze has a reflooding loop that keeps looping until fixed point. It's not obvious to me why this is necessary. (At least experimentally, I do see that "Reflooding foo" shows up when building the standard library with -m=3.)

/cc @dr2chase @cherrymui @paranoiacblack

@cherrymui

This comment has been minimized.

Contributor

cherrymui commented Dec 13, 2017

I have no idea what a "maximum-copy-started-suffix-level" is, and the x.left.left, &Node{x}, etc. examples don't really help. I'm particularly confused because a Node can represent so many different operations depending on the Op, and I'm lost on what semantic meaning we're divining from syntactic tree depth.

If I understand correctly, the example assumes there is a type Node with a field left which is of type *Node, in the source code, instead of the Node representation of the AST in the compiler. This is particularly confusing because I think this refers to source code but uses a data type that is the same as the compiler's AST data type.

@cherrymui

This comment has been minimized.

Contributor

cherrymui commented Dec 13, 2017

escAnalyze has a reflooding loop that keeps looping until fixed point. It's not obvious to me why this is necessary. (At least experimentally, I do see that "Reflooding foo" shows up when building the standard library with -m=3.)

The reflooding is added in CL https://go-review.googlesource.com/c/go/+/30693. Its CL description explains it. Probably we should add this as a comment.

@ianlancetaylor ianlancetaylor added this to the Go1.11 milestone Mar 29, 2018

@gopherbot

This comment has been minimized.

gopherbot commented Jun 26, 2018

Change https://golang.org/cl/121001 mentions this issue: cmd/compile: improve escape analysis explanation

gopherbot pushed a commit that referenced this issue Jun 26, 2018

cmd/compile: improve escape analysis explanation
No code changes, only revised comments in an attempt to make
escape analysis slightly less confusing.

Updates #23109.

Change-Id: I5ee6cea0946ced63f6210ac4484a088bcdd862fb
Reviewed-on: https://go-review.googlesource.com/121001
Run-TryBot: David Chase <drchase@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Cherry Zhang <cherryyz@google.com>

@ianlancetaylor ianlancetaylor modified the milestones: Go1.11, Unplanned Jun 30, 2018

@mdempsky

This comment has been minimized.

Member

mdempsky commented Dec 10, 2018

Over the weekend, I reimplemented a basic variant of esc.go's escape analysis logic, and now I better understand how it works in practice and what the documentation is explaining.

One thing I still don't understand though is the handling of recursive functions. In particular, this bit:

// in a mutually recursive group we lose track of the return values
if e.recursive {
	for _, ln := range Curfn.Func.Dcl {
		if ln.Op == ONAME && ln.Class() == PPARAMOUT {
			e.escflows(&e.theSink, ln, e.stepAssign(nil, ln, ln, "returned from recursive function"))
		}
	}
}

It looks like in esccall that we handle recursive calls, including wiring their return values into the flow graph correctly (look for "function in same mutually recursive group. Incorporate into flow graph").

I tried disabling this code by adding recursive = false at the top of escAnalyze, and it somewhat changes the -m output (which does cause test/escape_because.go's f8 and f9 to fail), but it doesn't seem to change which variables actually need to be heap allocated.

This code comes from CL 6741044 (507fcf3). It's true that before that CL we lost track of the return values in mutually recursive function calls, but the CL appears to have added both. So maybe the "if e.recursive" logic was written first, then lvd@ decided to fix the return value tracking, but forgot to remove the original (now unnecessary) fix?

@dr2chase

This comment has been minimized.

Contributor

dr2chase commented Dec 11, 2018

When I was working on this and thought I understood it, the recursive punt seemed necessary.
A test case demonstrating this would be tricky, however.

I also don't know that this is that worthwhile; I took a stab at handling recursion and even had a CL for it that I somewhat trusted, and it avoided practically no heap allocations, so I didn't pursue it. The problem is that if anything escapes, the this-field-versus-that-field precision is lacking, and so everything escapes.

I am however very interested in any writeup you can put together, because the algorithm is a real pain to understand.

@mdempsky

This comment has been minimized.

Member

mdempsky commented Dec 11, 2018

So here's the basic idea I understand:

Escape analysis treats the control flow graph as a bunch of locations, and assignments between them. Individual assignments can involve addressing or an arbitrary number of dereferences. For example:

p = &q    // -1
p = q     //  0
p = *q    //  1
p = **q   //  2
...

Note that p = &&q is nonsensical as values can't be addressed, so the length of an edge can never be less than -1.

Assignments can also be to the "sink" (basically, the Go heap).

All Go language constructs can be lowered into this assignment graph. For example,

var x struct { f, g *int }
var u []*int

x.f = u[0]

can be represented as

x = *u

Assignments to global variables, through pointers, passing arguments to unknown functions, etc. are recorded as assignments to the sink. Also, if q has a greater loop depth than p, then p = &q needs to be treated as sink = &q.

This is an imprecise but conservative representation of data flow.

As an optimization, the Go source might lower into multiple edges between the same two locations; it's only necessary to track the shortest edge.

Once we have a graph representing one or more functions, we can walk the graph to compute each node's "distance" from the sink and from any return parameters. This is basically just a bunch of shortest-path computations, except that distance is bounded as non-negative. For example, if p has distance 0 from some location, and there's an edge p = &q, then q has distance 0 from that location too, not distance -1.

Finally, we can observe two things from the resulting distance computations:

  1. If there's an edge p = &q where p has distance 0 from either the sink or any return parameter, then q escapes (i.e., must be heap allocated).

  2. For each function func f(p1, p2, ..., pN) (r1, r2, ..., rM) we can record the (M+1)*N distances from (sink, r1, r2, ...) to (p1, p2, ...) for subsequent escape analysis passes that involve calls to f. (The parameter tags that esc.go generates are basically a quantized encoding of this information.)

--

Notably, esc.go doesn't exactly follow this approach. Instead of simply constructing a graph and walking it as I describe above, escassign/escflow construct a partial graph (synthesizing OADDR/ODEREF nodes in lieu of tracking edge lengths directly) and escflood/escwalk walk the remaining edges. The subsequent computations based on the distance calculations are also intermingled into the walking logic, and tracking/recording distances is much more complicated.

@dr2chase

This comment has been minimized.

Contributor

dr2chase commented Dec 11, 2018

That's a nicer description than mine, I think. I am still trying to figure out an intuitive explanation of "suffixValue".

@mdempsky

This comment has been minimized.

Member

mdempsky commented Dec 11, 2018

As best I can tell, the suffixValue logic is captured in my simplified description by having distances bottom out at 0.

Basically, it's to ensure that given

sink = &p
p = q

then p needs to be heap allocated, but q doesn't.

@mdempsky

This comment has been minimized.

Member

mdempsky commented Dec 15, 2018

As an update, I have a WIP branch where I've written a new escape analysis pass. You can see the new code here: https://github.com/mdempsky/go/blob/esc5/src/cmd/compile/internal/gc/esc2.go

It's still a little rough and I need to add documentation and better debugging facilities. (The latter being mostly ad hocly developed while I bring it up to feature parity with esc.go.)

However, I believe it's about on par with esc.go in terms of correctness, and it's less than half the number of lines of code (1117 vs 2425).

It roughly follows the description I made above: the stmts/stmt/value/assign/call methods all trudge through the AST tracking pointer flows and constructing a graph of EscLocations, and then flood+walk do a simple walk over the graph identifying locations that escape and value flows from pointers to result parameters.

The graphs it builds also tend to be much smaller than esc.go's. For example:

# net/http      total   high watermark
locations:    5172646    10126    // esc2.go's nodes
edges:        4784956     9577    // esc2.go's edges
state:       12479460    25101    // esc.go's nodes
flow:         5826852    11793    // esc.go's edges

esc2.go only needed about 40% as many graph nodes as esc.go, and about 80% as many edges. There's room for further improvement here too.

My next immediate goal is continuing to dig through the differences in behavior between esc.go and esc2.go, and then polishing it up for review for the next dev cycle.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment