runtime: don't allocate for non-escaping conversions to interface{}

[randall77]

fmt.Fprintf("%d", 8)

Since all interface data fields are now pointers, an int must be allocated and
initialized to 8 so that it can be put in an interface{} to pass to Fprintf.

Since we know the 8 doesn't escape, we could instead allocate that 8 on the stack and
have the interface data word point to that stack slot.  To be safe, we can only do this
when the resulting interface{} doesn't escape.  We probably also need to be sure the
conversion happens at most once so the stack slot is not reused.

We could have a special convT2Enoescape call for the compiler to use when it knows the
result doesn't escape.  Maybe also convT2I, assertT2E, ...

[robpike]

Comment 1:

Status changed to Accepted.

[griesemer]

Comment 2:

Labels changed: added repo-main.

[jeffallen]

This thread explains how this issue causes 2 allocs on every call to os.(*File).Write.
https://groups.google.com/forum/#!topic/golang-nuts/0hfeLJP1LSk

[josharian]

Dmitry started this in CL 3503. Note that this requires improved escape analysis.

[gopherbot]

CL https://golang.org/cl/35554 mentions this issue.

[navytux]

For the reference until this is fixed some of us use ad-hoc printf-style mini language to do text formatting in hot codepaths without allocations. For example if in fmt speak you have

s := fmt.Sprintf("hello %d %s %x", 1, "world", []byte("data"))

the analog would be

buf := xfmt.Buffer{}
buf .S("hello ") .D(1) .C(' ') .S("world") .C(' ') .Xb([]byte("data"))
s := buf.Bytes()

It is a bit uglier but runs faster and without allocations:

pkg: lab.nexedi.com/kirr/go123/xfmt
BenchmarkFmt-4       5000000           246 ns/op          72 B/op      3 allocs/op
BenchmarkXFmt-4     20000000            57.9 ns/op         0 B/op      0 allocs/op

Details:

https://lab.nexedi.com/kirr/go123/commit/1aa677c8
https://lab.nexedi.com/kirr/go123/blob/c0bbd06e/xfmt/fmt.go

[josharian]

Note that when the arguments are constants, they no longer allocate on tip, so this is a bit better than it was.

[navytux]

@josharian thanks for feedback. For the reference the above benchmark was for tip (go version devel +d728be70f4 Thu Apr 20 01:37:08 2017 +0000 linux/amd64).

[bnjjj]

What are the status about this issue ? Is anyone working on ?

[ianlancetaylor]

@bnjjj I'm not aware of anybody actively working on this.

[thepudds]

FWIW, I was curious what the current gap is for avoiding allocations with the fmt print function arguments.

As far as I could see, it looks like as of Go 1.21, there are ~6 reasons val escapes here:

 val := 1000
 fmt.Sprintf("%d", val)

I did an exploratory pass on some possible solutions a couple of months ago, which I recently sent as stack of CLs.

Some of the CLs are likely wrong, but part of my hope is that sometimes if someone helps sketch the contours of a problem, then frequently other people are better able to jump in with solutions or their own explorations (whether those "other people" are experts, or just other people who are curious).

Brief summary of the ~6 reasons:

1. The fmt print methods store the user interface arguments on a pp struct. The pp struct escapes, and the heap can't point to the stack, so the user arguments escape as well. (Sent CL 524938).

2. reflect.Value.Pointer also causes escapes. (Sent CL 524939).

3. reflect.Value.Slice also causes escapes. (Sent CL 524940).

4. Interface conversions and interface methods call like arg.String() in handleMethods also cause the user arguments to escape. This might be the most fundamental reason. (Sent CL 524945 and some related CLs. Matthew Dempsky then said he liked the core idea and he sent an alternative implementation in CL 526520. I also opened #62653 to help discussion on this specific piece).

5. Within reflect, packEface causes reflect.Value.Interface to escape, which causes the fmt args to escape. (Sent CL 528535).

6. Also within reflect, method values cause conditional allocation of a methodValue struct, which also causes the fmt args to escape. (Sent CLs 528536, 528537, and 528538. These CLs might be the ugliest).

   • UPDATE: creating a new type of pragma was indeed too ugly, so I abandoned those three CLs and instead sent a hopefully better approach spread across CLs 530095 (runtime), 530096 (compiler), and 530097 (reflect).

By the end of my first-cut stack (as of CL 528538), arguments to Sprintf like the Point struct here no longer get heap allocated:

  type Point struct {x, y int}
  p := Point{1, 2}
  fmt.Sprintf("%v", p)

Some of those CLs are more-or-less shots in the dark, but I tried to put some context in the CL descriptions and elsewhere in the hopes of other gophers jumping in with alternative solutions (or suggestions for corner cases to test, or questions, or ideas for improvement and so on...).

The CLs all pass all.bash and pass the older TryBots (but hit some LUCI-specific issues with the new TryBots).

If you are new to the escape analysis code:

• The best place to start is probably Matthew Dempsky's nice introduction in escape.go.
• I tried to add some additional general explanation of how escape analysis currently works, including via some examples here and at the start of here.
• For the interface method challenges, I tried to give some narrative examples here with the results reflecting the new behavior. Also, the CL 524945 commit message attempts to explain how escape analysis arrives at its result for interface method calls in Go 1.21 and earlier. (Definitely room for improvement in those explanations 😅).

[gopherbot]

Change https://go.dev/cl/524938 mentions this issue: fmt: avoid storing input arguments on pp to help escape analysis

[gopherbot]

Change https://go.dev/cl/528535 mentions this issue: reflect: leak packEface input to result rather than heap

[gopherbot]

Change https://go.dev/cl/530095 mentions this issue: runtime: manually represent reflect.methodValue in stack map for methodValueCall assembly

[gopherbot]

Change https://go.dev/cl/530096 mentions this issue: cmd/compile/internal/escape: recognize more self-assignment patterns

[gopherbot]

Change https://go.dev/cl/530097 mentions this issue: reflect: avoid always escaping in Value.Interface

[gopherbot]

Change https://go.dev/cl/524944 mentions this issue: cmd/compile/internal/escape: reserve space in leaks encoding for interface receiver data

[gopherbot]

Change https://go.dev/cl/524945 mentions this issue: cmd/compile/internal/escape: analyze receivers in interface method calls

[gopherbot]

Change https://go.dev/cl/528539 mentions this issue: cmd/compile/internal/escape: propagate method usage for analyzing receivers in interface method calls

[gopherbot]

Change https://go.dev/cl/524937 mentions this issue: cmd/compile/internal/escape: make escape analysis -m=2 logs more accessible

[gopherbot]

Change https://go.dev/cl/529575 mentions this issue: fmt: add more function and allocation tests

[jeffallen]

@thepudds I noticed this problem 10 years ago, and I really appreciate your work on it now today!

[pav-kv]

Are there any interim brute-force solutions to this? I see one here. As another option, could we use generics? For example, instead of a variadic fmt.Sprintf, generate a family of functions:

func SprintfN1[T1 any](format string, x1 T1) string { ... }
func SprintfN2[T1, T2 any](format string, x1 T1, x2 T2) string { ... }
...
func SprintfN10 // or any practical limit on the number of parameters

Which does everything doPrint does, except it has a concrete list of arguments taken by value, so no escaping would be incurred.

This function is at the core of so many logging/tracing invocations in production systems (and responsible for a good chunk of allocations) that having a brute-force but working solution could be acceptable, until this problem is solved fundamentally.