-
Notifications
You must be signed in to change notification settings - Fork 17.6k
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
reflect: NamedOf #16522
Comments
This turns out to require more invasive changes than I originally realized. To be useful, it needs to be possible to add methods to types created at run time. That means taking some equivalent to But methods are called directly from pointers to the text segment (stored in the itab). The unboxed receiver value is on the stack for the method body to use, but no type is available. So there's no way for the reflect package to take the receiver value and box it up into a reflect.Value when the method is called. Assuming we want to avoid code generation, some change to dynamic method calling would have to be made. The smallest is probably dropping the underlying type and method number onto the stack. A more significant change would be making the function pointers in the itab indirect like func() pointers (https://golang.org/s/go11func). A third option would be a note on the itab saying these are func()-style pointers. Any of these actions incurs some cost on dynamic method calls. Still pondering. |
I thought the precise GC work back in Go1.4 meant all types on the stack are known to the runtime. Is that no longer true? |
We only have pointer/nonpointer bits for each word on the stack. We do not have full type information. |
A discussion in the original thread starting at #4146 (comment) eventually honed in on really wanting something like described in this issue. Referencing here because there is some discussion about how |
Since NamedOf() knows the new type T that it is creating, couldn't it build a closure for each method, and store a pointer to the runtime._type for T in each closure? I'm assuming we can build a reflect.Value given an unboxed value and runtime._type. Since there is no subtyping, we don't have to worry about the receiver's actual type being different from T (or *T), right? |
@nerdatmath The language doesn't permit methods to be closures. So, for simplicity, the same mechanism is used to pass the receiver value as is used to pass the pointer to the closure. For a method, we pass the receiver, and for a closure, we pass the closure pointer. We don't have a way to pass both. |
OK another shot. Suppose T is a concrete type, s is of type T, x is of type A, and m is a method of T accepting a single parameter of type A. From the programmer's perspective, calling s.m(x) is essentially the same as calling T.m(s, x). Does that correspondence extend down to the calling convention? When calling T.m the compiler knows the concrete type of s (and knows that T.m knows it too), so it doesn't need to pass the type info. If so, we already have a way to create functions of type func(T, A): runtime.FuncOf. Could this or a similar function create method pointers that could be put in itabs? Please forgive me if I'm being hopelessly naive. |
@nerdatmath, I think the issue that you'll run into that @ianlancetaylor is referring to is that once you do create the struct/type of I believe the long standing calling conventions would need to modified or extended in order to support this. There's probably a safe way to extend the compiler to support a new calling convention. I went down a very deep rabbit hole trying to implement |
I thought the concrete type was pointed at by the other half of the interface value (https://research.swtch.com/interfaces). If one is calling through the interface value, would the type not be available? What am I missing? |
I dropped the idea of creating a closure. What does reflect.MakeFunc create? Not a closure but an actual function like TopLevel in https://golang.org/s/go11func, right? From that document:
So essentially, creating a method should be the same as creating a top-level function, which is done by reflect.MakeFunc. My apologies for referring to it as runtime.FuncOf earlier. |
OK so I guess reflect.MakeFunc actually creates something like a func literal / closure. So I think I see the difficulty. |
@glycerine The interface value has the type, yes, but in the current calling convention we don't pass the entire interface value in a method call. We only pass the value pointer inside the interface value. We don't need to pass the type, since by definition a method knows which type it has been compiled for. |
Thanks Ian. Related discussion (for others catching up) from Carl Chatfield's proposal a couple years back, calling convention adaptation to provide the entire interface value. https://groups.google.com/d/msg/golang-dev/coyYwxU3dfM/dZzOleaeFu4J |
In my opinion, reflect.NamedOf would be useful even without support for adding methods to the newly created type - just like reflect.StructOf is useful even without (full) support for wrapper methods of embedded fields. In any case, I think that reflect.NamedOf() should have, as proposed, a function parameter to pass the list of methods and, until support for adding methods is implemented, it could simply panic if the methods list is non-empty. I also have an idea on how to support adding methods to types created with reflect.NamedOf without changing the calling convention for methods, but it's quite tricky - better if I write a prototype first. P.S. it is worth noting that the signature
|
Yes you are right, and it will introduce to the idea of Proxy Object. |
…or contexts In many cases IO needs to be able to be canceled. For example in WCFS filesystem I need to cancel handling sysread(/head/watch) when FUSE INTERRUPT request comes in [1,2,3]. The READ handler for /head/watch inside WCFS is interally implemented via io.Pipe which does not provide read/write cancellattion besides "destructive" close. Standard Go answer for cancellations is via contexts. So as a first step let's add corresponding interfaces - xio.Reader, xio.Writer etc - that are io analogs that add support for contexts. For compatibility with legacy code that work with only io.X (e.g. only with io.Reader), in spirit of [4], add BindCtx which binds xio.X instance with context and converts it into io.X. Add WithCtx - corresponding inverse operation that converts io.X back into xio.X and for general io.X adds cancellation handling on a best-effort basis. [1] https://lab.nexedi.com/kirr/wendelin.core/commit/b17aeb8c [2] https://lab.nexedi.com/kirr/wendelin.core/commit/f05271b1 [3] https://lab.nexedi.com/kirr/wendelin.core/commit/5ba816da [4] golang/go#20280 [5] golang/go#16522
I have a vague idea which I wanted to run past you before I spend time digging deeper. So methods have no access to a closure pointer (assuming we don't want to change calling conventions), we don't want to incur extra costs for dynamic method calls unrelated to The idea is that the method code of a TEXT Forwarder
CALL DispatchMethod
Obviously, this requires multiple copies of What happens if we run out of free slots? We create a new virtual memory mapping to the same physical memory (or possibly pre-seed the binary with "enough" of such mappings at compile time). So the same physical code gets new virtual addresses and can serve more methods. No generation of new code necessary. In total, the cost would be:
|
@ianlancetaylor is this the kind of issue the team would entertain a community member working on/proposing or is it so deep in probable compiler changes that it'd be easier for it to be done internally? |
@edaniels It's fine for a community member to work on this, but it's really hard to get right. |
Consider adding a function to the reflect package for creating a new named type with a method set:
(Broken out from #4146.)
The text was updated successfully, but these errors were encountered: