cmd/compile, runtime: a design for low-cost defers via inline code

[danscales]

We are working on an implementation of defer statements that makes most defers no more expensive than open-coding the deferred call, hence eliminating the incentives to avoid using this language to its fullest extent. We wanted to document the design in the proposal/design repo.
See issue #14939 for discussion of defer performance issues.

The design document is posted here. The current, mostly complete implementation is here

Comments are welcome on either the design or the implementation.

[gopherbot]

Change https://golang.org/cl/196964 mentions this issue: design: add 34481-opencoded-defers.md

[gopherbot]

Change https://golang.org/cl/197017 mentions this issue: misc, runtime, test: extra tests and benchmarks for defer

[bcmills]

@danscales, should this be milestoned to 1.14, or is it a longer-term effort?

[danscales]

Yes, Go1.14 milestone is correct -- that's what we're aiming for.

[tsatke]

This proposal only allows up do 64 defers per function, is that correct?
I imagine this is enough for most hand written code, but I can imagine some frameworks generating a lot more than that...

Or imagine test code opening every file in a directory and deferring the file close. This won’t work for large directories and may break backwards compatibility in some cases. Also, what would be the error?

[danscales]

This proposal only allows up do 64 defers per function, is that correct?

Yes, there is some limit to the number of defers per function (the size of the deferBits bitmask). In the current implementation, it is 8, but easily changed to 64.

But to clarify, if open-coded (inlined) defers cannot be used in a function, we just revert back to the current way of doing defers (create a "defer object" and add to the defer chain, process the appropriate objects on the defer chain at all function exits).

Our goal is to reduce the defer overhead in the common cases where it occurs, which is typically smallish functions with a few defers. In unusual cases (functions with defers in loops or lots of defer statements), we just revert to the current method.

I will add some text to the design document to make this clearer.

[rasky]

Is there a way to avoid checking deferBits for defers that are always executed? I don’t mind that the respective bits get set, but there is no compiler optimization that’s able to remove checks for those bits (unless they are all always set and thus the variable is constant). It looks like it should be sufficient to check whether the defer is called in a block that dominates all exits (or something like that) and not emit the bitcheck in that case.

[CAFxX]

@rasky dominating all exits is not enough; consider:

func foo() {
  bar()
  defer baz()
  // ...
}

If bar() panics, baz() should not be executed (even though the defer dominates all exits).

[rasky]

The special panic handler can still check the bits if it needs to. My comment is about not generating bit checks in open-coded defers within the function body.

[danscales]

Is there a way to avoid checking deferBits for defers that are always executed? I don’t mind that the respective bits get set, but there is no compiler optimization that’s able to remove checks for those bits (unless they are all always set and thus the variable is constant). It looks like it should be sufficient to check whether the defer is called in a block that dominates all exits (or something like that) and not emit the bitcheck in that case.

Yes, the deferBits conditionals (in the inline code) are eliminated completely in the simple cases where all defers are unconditional. If all defers are unconditional, then the stream of operations on deferBits are all unconditional and just involve constants, so the value is known everywhere through constant propagation. The 'opt' phase of the compiler does the constant propagation and then eliminates the if-check on deferBits which is always true.

As you point out (good point!), if one defer is always executed (dominates the exit) but others are not, we could potentially remove the deferBits check for that specific defer on any exits after that defer. I will put that on the TODO list (and add that as an idea for the next rev of the design doc). I may not do that optimization for the initial checkin.