Thanks for the hints, I could finally have a look at it and found that a
uint64 value was escaping regardless of the actual function code path. I
can reproduce it with this dummy function example:
func foo(cond bool, v int) *int {
if cond {
return
}
return nil
}
The
That looks like something escaped to the heap.
If you pass the -S option to the compiler, the assembly output will have
the symbolic name of the type being allocated (at the LEAQ 2 instructions
before the call to newobject).
If you pass the -m option to the compiler, it will tell you what
On Wed, Sep 23, 2020 at 3:36 PM 'ju...@sqreen.com' via golang-nuts
wrote:
> I was surprised to find a heap allocation in the following function prolog:
> https://gist.github.com/Julio-Guerra/a3a2088832cd927669c08e1127e4c25a
I think the function prolog consists of the first three assembler
Hello,
I was surprised to find a heap allocation in the following function prolog:
https://gist.github.com/Julio-Guerra/a3a2088832cd927669c08e1127e4c25a
Under what circumstances is this happening and it is possible to avoid it?
Thanks,
Julio
--
You received this message because you are
