Inspecting GC memory/stats

[Rainer Schuetze via Digitalmars-d]

On 11.11.2014 08:36, Iain Buclaw wrote:
> Hi,
>
> I find myself wondering what do people use to inspect the GC on a
> running process?
>
> Last night, I had a look at a couple of vibe.d servers that had been
> running for a little over 100 days.  But the same code, but one used
> less (or not at all).
>
> Given that the main app logic is rather simple, and things that may be
> otherwise held in memory (files) are offloaded onto a Redis server.
> I've have thought that it's consumption would have stayed pretty much
> stable.  But to my surprise, I found that the server that is under more
> (but not heavy) use is consuming a whooping 200MB.
>
> Initially I had tried to see if this could be shrunk in some way or
> form.  Attached gdb to the process, called gc_minimize(), gc_collect() -
> but it didn't have any effect.

The GC allocates pools of memory in increasing size. It starts with 1 
MB, then adds 3MB for every new pool. (Numbers might be slightly 
different depending on the druntime version). These pools are then used 
to service any allocation request.

gc_minimize can only return memory to the system if all the allocation 
in a pool are collected, which is very unlikely.

>
> When I noticed gc_stats with an informative *experimental* warning, I
> thought "lets just run it anyway and see what happens"... SEGV.  Wonderful.

I suspect calling gc_stats from the debugger is "experimental" because 
it returns a struct. With a bit of casting, you might by able to call 
"_gc.getStats( *cast(GCStats*)some_mem_adr );" instead.

>
> As I'm probably going to have to wait 100 days for the apparent leak
> (I'm sure it is a leak though) to show itself again, does anyone have
> any nice suggestions whether or not to confirm this memory is just being
> held and never freed by the GC?
>
> Iain.