Does reflect.ValueOf still have to escape the argument?

[Lorenz Bauer]

reflect.ValueOf currently contains the following comment:

   // TODO: Maybe allow contents of a Value to live on the stack.
   // For now we make the contents always escape to the heap. It

   // makes life easier in a few places (see chanrecv/mapassign

   // comment below).

   escapes(i)

 Followed by this at the end of value.go:

   // Note: some of the noescape annotations below are technically a lie,

   // but safe in the context of this package. Functions like chansend

   // and mapassign don't escape the referent, but may escape anything

   // the referent points to (they do shallow copies of the referent).

The call to escapes(i) goes back to pre Go 1, 11 years ago, the comments were updated roughly 7 years ago. If I understand correctly, the reason that ValueOf escapes its argument is so that Value.send and Value.SetMapIndex work correctly.

The compiler and runtime have changed a lot since then, so I wonder what it would take to avoid the call to escapes(i) in ValueOf? It can't be as simple as adding escape() calls to Value.send and Value.SetMapIndex?

[cherry]

I have a working-in-progress CL https://golang.org/cl/408826 that makes ValueOf not alway escape. I hope to finish it and see if we can land it in Go 1.20. Thanks.

Cherry

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/ec410a68-c2b2-4f68-a6af-766a09947352n%40googlegroups.com.

[Lorenz]

Oh great! Thanks for linking the CL, that was very informative.

Lorenz

[Lorenz Bauer]

On Friday, 7 October 2022 at 21:29:16 UTC+1 cherry wrote:

I have a working-in-progress CL https://golang.org/cl/408826 that makes ValueOf not alway escape. I hope to finish it and see if we can land it in Go 1.20. Thanks.

Hi Cherry,

Do you think there is a chance to get this done for 1.21? I'd be happy to help / do some grunt work if possible, it's a problem that has been bugging me for a long time and I'd love to see it fixed.

Lorenz

[cherry]

Hi Lorenz,

Yes, I hope to get them in for 1.21. That CL and the subsequent ones up to CL https://golang.org/cl/441938 are pretty much ready for review. The only issue I'm having so far is that with the changes reflect.Value.Type won't be inlined.

You're welcome to try out the CLs and see if they work correctly and if they help your case. Thanks.

Cherry

 

Lorenz

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/9563e85d-a49c-4977-9a02-1b504c53752en%40googlegroups.com.

[Lorenz Bauer]

Hi Cherry,

Any chance to revive the CLs in time to get them into 1.21? I've rebased them on top of a recent master, and things seem to work fine.

I went ahead and ran the encoding/binary benchmarks: https://gist.github.com/lmb/4477812588a5ac23e0b58f5f780b383d Benchmarks that repeatedly call Write benefit from this change since the data argument doesn't escape anymore. This makes function which use a "temporary" struct to marshal into a wire format a bit cheaper. Not sure if I explained it properly, something like this:

func(w io.Writer, a ExportedType) error {

   tmp := wireFormat{a.Foo, a.Bar}

   return binary.Write(w, bo, tmp)

}

That still leaves the cost of the temporary buffer allocated by Write (which is much higher than the escaping interface), but with non-escaping reflect in place I want to experiment with an AppendByteOrder version of Write. Then we might be able to do zero-allocation binary marshaling while still using reflection behind the scenes.

Lorenz

[cherry]

Thanks for running the benchmarks! Glad to see it helps :)

I rebased the CLs and sent them again, with DO NOT SUBMIT removed. If they are reviewed we can get them in. Thanks.

Cherry

 

--
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/golang-dev/837465ce-0b3f-4d9e-8b6d-5656e96dbc68n%40googlegroups.com.