cmd/compile: reflected methods have extra wrapping

[seebs]

What version of Go are you using (go version)?

1.12.7

Does this issue reproduce with the latest release?

Probably.

What operating system and processor architecture are you using (go env)?

amd64, or amd64p32. Reproduces on playground, probably not specific to it.

What did you do?

https://play.golang.org/p/tEu9qKfYdEB

Obtain a method using (reflect.Value).MethodByName(), convert it to a function type, and call it.

The method has a stack trace.

What did you expect to see?

A function pointer identical to one I could call directly.

What did you see instead?

A fancy wrapped function pointer which is doing some kind of marshalling and then unmarshalling of its parameters.

goroutine 1 [running]:
main.(*Updater).Update(0x414020, 0x7d0, 0x13, 0x0)
	/tmp/sandbox371765888/prog.go:15 +0x80
main.callFn(...)
	/tmp/sandbox371765888/prog.go:22
main.main()
	/tmp/sandbox371765888/prog.go:29 +0x160

trace:
goroutine 1 [running]:
main.(*Updater).Update(0x414020, 0x7d0, 0x0, 0x446494)
	/tmp/sandbox371765888/prog.go:15 +0x80
reflect.callMethod(0x43e320, 0x454f70, 0x454f64, 0x0)
	/usr/local/go/src/reflect/value.go:690 +0x180
reflect.methodValueCall(0x7d0, 0x414020, 0x201, 0x138901, 0x121ac0, 0x43e320, 0x125060, 0x414020, 0x213, 0x1d, ...)
	/usr/local/go/src/reflect/asm_amd64p32.s:35 +0x40
main.callFn(...)
	/tmp/sandbox371765888/prog.go:22
main.main()
	/tmp/sandbox371765888/prog.go:30 +0x180

(The stray "callFn" is an attempt to ensure that the compiler isn't just outsmarting me here by taking short-cuts when it can easily see that the method it's calling is a method of a local object...)

It seems to me like it would be really nice if there were a way for the methods reflect.MethodByName yields to be the same functions that you get from method values.

[andybons]

@randall77 @griesemer @josharian @mdempsky @martisch

[mdempsky]

Method values always require wrapping. The static call case has a wrapper call frame too, but the runtime skips it when generating the stack trace.

For consistency we should probably skip the reflection call frames here too, but that seems possibly a little tricky.

[seebs]

Oh, interesting. Hmm. That implies that method values are more expensive than I realized -- I'm not actually sure I want those stack frames skipped always, or at least, not when I'm trying to figure out where all my CPU went. But it makes sense that they'd always require wrapping.

[randall77]

I think the difference in wrapping is that the standard method wrapping is all generated by the compiler. It's not code the user can see (there's no line number to report for it, you couldn't see it in a debugger, etc.) The wrapping generated by reflect is actual code (assembly or Go) that is source with line numbers, etc.