cmd/compile: reflected methods have extra wrapping #33641
Comments
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. |
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. |
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 |
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.
(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.
The text was updated successfully, but these errors were encountered: