Valgrind for Go?
James Nurmi
seem to be leaking memory, they seem to be consuming more than I'd
expect.
The basic question is, does go have anything similar to valgrind
(which doesn't seem to work on go binaries, not that I'd expect it to
really), or even a traced malloc/free available in go? Strace only
catches brk() calls, and these don't seem to line up with the numbers
reported in /proc at all.
More specifically, neither of these applications use a large volume of
data, but their VmData tend be 6-8 megs/goroutine larger than I'd
expect. The simplest one uses reflection but no outside (cgo)
libraries; Utilizing a "dump-my-data" routine, the dataset seems to
be be only about 2 megs (JSON encoded), but the resident data size is
closer to 75 megs. The more complex one stores less data, but uses a
number of threads and alexh's GoLUA bindings -- this one is almost
completely bound by the number of goroutines I create -- at about 25MB
(VmSize) per thread.
Tangential but (i think) unrelated: Any but the most trival binaries
tend to be > 1MB [amd64] -- while disk is cheap, I'd like to not be a
pig as a software distributor -- does anyone know of a "Crunch" like
functionality for Go command line tools? My prototype certainly would
indicate this works at reducing binary size, but there's enough edge
cases that I'd rather steal someone elses if it's available :-).
Thanks & Cheers,
James
Paulo Pinto
similar to what JVM and CLR do offer,
so that you can see in real time what the GC is doing.
I suspect that the memory is not being reclaimed, because the GC sees
no need for it, hence you
are seeing an increase in memory usage, even if you don't use all of
it.
Jessta
> I'm debugging a few long-running applications and while they don't
> seem to be leaking memory, they seem to be consuming more than I'd
> expect.
The GC doesn't return memory to the operating system. So long-running
applications won't ever shrink.
The GC is also conservative, so it hold on to memory longer than you'd
expect and therefore may
allocate more memory than you'd expect.
> The basic question is, does go have anything similar to valgrind
> (which doesn't seem to work on go binaries, not that I'd expect it to
> really), or even a traced malloc/free available in go? Strace only
> catches brk() calls, and these don't seem to line up with the numbers
> reported in /proc at all.
http://golang.org/pkg/runtime/#MemProfile might be helpful.
> More specifically, neither of these applications use a large volume of
> data, but their VmData tend be 6-8 megs/goroutine larger than I'd
> expect. The simplest one uses reflection but no outside (cgo)
> libraries; Utilizing a "dump-my-data" routine, the dataset seems to
> be be only about 2 megs (JSON encoded), but the resident data size is
> closer to 75 megs. The more complex one stores less data, but uses a
> number of threads and alexh's GoLUA bindings -- this one is almost
> completely bound by the number of goroutines I create -- at about 25MB
> (VmSize) per thread.
>
> Tangential but (i think) unrelated: Any but the most trival binaries
> tend to be > 1MB [amd64] -- while disk is cheap, I'd like to not be a
> pig as a software distributor -- does anyone know of a "Crunch" like
> functionality for Go command line tools? My prototype certainly would
> indicate this works at reducing binary size, but there's enough edge
> cases that I'd rather steal someone elses if it's available :-).
Go binaries tend to be similar in size to statically linked C binaries.
- jessta
--
=====================
http://jessta.id.au