-
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
cmd/cgo: unexpected allocations when passing void pointers #15048
Comments
The difference is that in the void* case, cgo doesn't figre out that the value does not point to a value that contains a Go pointer, and therefore inserts a check call. In the char* case, cgo can see that the type C.char can not contain a pointer, and therefore there is no need to use a check call. The check call causes the pointer to appear to escape, forcing buf to be allocated on the heap. |
That mostly makes sense. But you are saying it is allocating space on the heap for the 24-byte slice header (pointer + 2 ints)? It seems strange that a slice header can "escape". |
The slice header is being passed to a function via |
go version
)? go1.6go env
)? linux/amd64I was helping to debug several unaccounted for allocations and we came across what we thought was very peculiar behavior. Consider the following two implementations of the same package
http://play.golang.org/p/hC-b5VSG58
http://play.golang.org/p/soCMGF1WjG
And the following benchmark
http://play.golang.org/p/e37ObBxwJP
Neither implementation appears to allocate anything in the Foo function. So I expect
go test -bench
to report zero allocations for both implementations of the package.For the first example (hC-b5VSG58) the command
go test -bench=. -benchmem
reports two allocations (48 bytes total) when the C function is passed a non-nil argument.The second example avoids any allocation.
The first example does see a performance impact, I assume because of the allocations.
The text was updated successfully, but these errors were encountered: