Open mdempsky opened 3 years ago
There was a question about what the universal method value wrapper would look like. My idea was something like:
type methodValueWrapper {
entryPC uintptr
recv unsafe.Pointer
realEntryPC uintptr
}
and then have a wrapper function like:
TEXT universalWrapper(SB), NOSPLIT, $0
MOVQ 16(DX), AX // load realEntryPC
MOVQ 8(DX), DX // load recv into context register
JMP AX // jump to underlying method entrypoint
(AX can be replaced with any other register that better fits the regabi calling convention.)
Since we're in the 1.18 freeze and there hasn't been any movement here, I'm going to place this in the backlog. IIUC this is still something we'd like to do, but unless anyone explicitly plans on working on it for next release, I'm reluctant to put it in the 1.19 milestone.
@mdempsky @aclements Feel free to move it around as necessary.
TL;DR: We should look into passing pointer-shaped receivers using the context register.
Today, receiver parameters are effectively simply prepended to the parameter list. This was convenient when Go only had method expressions (i.e., expressions like
T.M
, whereT
is a type), because the same function code could be used for both method calls and method expressions.However, Go later added method values (i.e., expressions like
x.M
, wherex
is a value), which require generating wrapper functions and also requires rather complex trampoline code within package reflect. This complexity is needed to adapt between the function closure calling convention (which passes the closure pointer using a dedicated context register) and the method calling convention (which passes receivers using a regular parameter).If we change the internal calling convention so that receiver arguments are passed using the context register too, then we'd be able to avoid generating method value wrappers. We'd instead need just a single simple, universal wrapper, which could be used by both the compiler and package reflect. (For methods with non-pointer-shaped receivers, we would wrap the interface-calling-convention wrapper for the method, which always uses a pointer-shaped receiver parameter.)
Another benefit (pointed out by @dr2chase) is this would free up an extra register for passing arguments to pointer-receiver methods.
The only downside I see at the moment is that method expressions for pointer-shaped receiver types (e.g.,
(*T).M
) would now need compiler-generated wrappers instead. However, the mitigating factors here are: (1) method expressions can only appear in source so we can always statically generate them (unlike for method values); (2) method expressions seem much less commonly used than method values (caveat: based on my anecdotal experience); and (3) it would be easy to reuse wrappers for methods with the same GC shape./cc @aclements @dr2chase @mknyszek