Hi,
I'm looking at calling functions from a DLL on Windows. I found syscall.DLL
to do the job:
syscall.MustLoadDLL("foo.dll").MustFindProc("bar").Call(uintptr(unsafe.Pointer(&arg)))
Call() is annotated with //go:uintptrescapes
<https://github.com/golang/go/commit/bbe5da42600d5ab26cd58ffac3d6427994f08fb2#diff-c3301b166d7b20975be43f1c0accabc999ea4f2ccafef40f2d31217b8e2755c6>,
which causes arg to be heap allocated. Rewriting the snippet above seems to
avoid the escape to heap:
syscall.SyscallN(...MustFindProc("bar").Addr(),
uintptr(unsafe.Pointer(&arg)))
Here is a fully worked snippet: https://go.dev/play/p/vJySh0z22uI The
escape analysis shows that b doesn't escape:
go build -gcflags="-m=1" main.go
# command-line-arguments
./main.go:11:28: inlining call to syscall.MustLoadDLL
./main.go:12:26: inlining call to syscall.(*DLL).MustFindProc
./main.go:17:28: inlining call to syscall.(*Proc).Addr
./main.go:13:6: moved to heap: a
./main.go:14:11: ... argument escapes to heap
./main.go:17:18: ... argument escapes to heap
This is important for my use case because it would reduce allocations on a
common operation.
The uintptrescapes annotation was added due to
https://github.com/golang/go/issues/16035
A couple of questions:
- Is my analysis correct or am I missing something?
- Has anything changed in the last 8 years which means Proc.Call could be
made to not escape its arguments?
- Does it make sense to document this on Proc.Call?
Thanks!
Lorenz
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/10645e8b-9806-4a29-8c9a-3376a9d56263n%40googlegroups.com.
