Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/compile: reflected methods have extra wrapping #33641

Open
seebs opened this issue Aug 14, 2019 · 4 comments

Comments

@seebs
Copy link
Contributor

commented Aug 14, 2019

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 andybons changed the title compiler: reflected methods have extra wrapping cmd/gc: reflected methods have extra wrapping Aug 15, 2019

@andybons andybons added this to the Unplanned milestone Aug 15, 2019

@andybons andybons changed the title cmd/gc: reflected methods have extra wrapping cmd/compile: reflected methods have extra wrapping Aug 15, 2019

@andybons

This comment has been minimized.

Copy link
Member

commented Aug 15, 2019

@mdempsky

This comment has been minimized.

Copy link
Member

commented Aug 15, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented Aug 15, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Aug 16, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.