cmd/compile: allocate some defers in stack frames

[randall77]

When we can statically determine that a defer is called (at most) once, we should
allocate the Defer structure in the stack frame instead of from the DeferChunk mechanism.

We suspect most defers fit into this category.

[rsc]

Comment 1:

Labels changed: added release-go1.4, removed release-go1.3maybe.

[rsc]

Comment 2:

I sketched this during gophercon. The 6g-only CL is in
https://golang.org/cl/100300043 although it also has an unrelated ... fix for
escape analysis mixed in.
It made basically no difference for things that hit Dmitriy's latest defer cache. For
strangely-sized defers it might help and be worth doing.

[dgryski]

Comment 3:

Some simple benchmarks from expvar-like locked values:
BenchmarkDeferAddInt    20000000            91.4 ns/op
BenchmarkAddInt 100000000           21.6 ns/op
BenchmarkDeferAddFloat  20000000            89.3 ns/op
BenchmarkAddFloat   100000000           21.7 ns/op
So, the overhead is pretty big.

[dgryski]

Comment 4:

Some simple benchmarks from expvar-like locked values:
BenchmarkDeferAddInt    20000000            91.4 ns/op
BenchmarkAddInt 100000000           21.6 ns/op
BenchmarkDeferAddFloat  20000000            89.3 ns/op
BenchmarkAddFloat   100000000           21.7 ns/op
So, the overhead is pretty big.

[rsc]

Comment 5:

Stack copying now depends on Defers NEVER being on the stack.

Labels changed: added release-none, removed release-go1.4.

Status changed to Retracted.

[dvyukov]

Comment 6:

The code in stack.c suggests the opposite:
    for(dp = &gp->defer, d = *dp; d != nil; dp = &d->link, d = *dp) {
        if(adjinfo->old.lo <= (uintptr)d && (uintptr)d < adjinfo->old.hi) {
            // The Defer record is on the stack.  Its fields will
            // get adjusted appropriately.
            // This only happens for runtime.main and runtime.gopanic now,
            // but a compiler optimization could do more of this.
            // If such an optimization were introduced, Defer.argp should
            // change to have pointer type so that it will be updated by
            // the stack copying. Today both of those on-stack defers
            // set argp = NoArgs, so no adjustment is necessary.
            *dp = (Defer*)((byte*)d + adjinfo->delta);
            continue;
        }

Labels changed: added release-go1.5, removed release-none.

Status changed to Accepted.

[randall77]

Comment 7:

Russ is a bit ahead of himself - this will be the case when
https://golang.org/cl/141490043/ is in.

[dvyukov]

Comment 8:

Why defers on stack won't work? Are there any principal problems? Don't we just need to
do proper adjustments to support defers on stack?

[dvyukov]

Comment 9:

Defers are still super slow. To the point where one can prefer to not use defer at all
just because of the performance.

[randall77]

Comment 10:

I don't think there is anything in principle that wouldn't work.  You just have to be
careful about avoiding tracebacks while copying the stack.

[rsc]

Comment 11:

It is probably possible to make work. However, I benchmarked it (patch in the CL above)
and it just doesn't matter. The defer cache takes care of nearly all the win. It is not
worth it.
I will leave this open but it is not targeted to a release.

Labels changed: added release-none, removed release-go1.5.

[dvyukov]

Comment 12:

The compiler also needs to *fill* in the struct and link it into g->defer, and on
successful return unlink from g->defer inline. That would provide the speedup.
Today the single defer in net.Conn.Read/Write consumes 2.5% of time in the end-to-end
HTTP benchmark:
http://build.golang.org/log/33d55778f33682e4e1d45e7c825a73d2ea500de7
Defer is not something that must be visible in a profile of such program. We don't want
to wipe defers from std lib due to performance, right? I guess there are Go users who
already do this with their libraries.

[rsc]

Comment 13:

Okay, well that might work. Defers will need more care in the stack copier if they get
stack-allocated, because the Defer chain will weave between allocated memory and the
stack, but I think it is possible to make it work. (In contrast it was fundamentally not
possible to make stack-allocated Panics work when they were also used during traceback,
because a Panic near the bottom of the stack wasn't actually needed until later up the
stack, and by then it had been rewritten. The CL 141490043 fixed this by not using
Panics during traceback anymore.)

[griesemer]

Comment 14:

Labels changed: added repo-main.