• Dan Olson (9/9) Jan 04 2016 I haven't played with any of the new GC configuration options introduced
• Rainer Schuetze (9/16) Jan 04 2016 There is a "leak detector" in the GC compiled into it the with
• Dan Olson (2/21) Jan 05 2016 Thanks Raniner!

Dan Olson <gorox comcast.net> writes:

I haven't played with any of the new GC configuration options introduced
in 2.067, but now need to.  An application on watchOS currently has
about 30 MB of RAM.  Is there any more documentation than the web page
https://dlang.org/spec/garbage.html or should I just browse druntime
code?

Also pointers (pun maybe) on finding who has the references keeping memory from
being collected.
-- 
Dan

Rainer Schuetze <r.sagitario gmx.de> writes:

On 05.01.2016 01:39, Dan Olson wrote:
 I haven't played with any of the new GC configuration options introduced
 in 2.067, but now need to.  An application on watchOS currently has
 about 30 MB of RAM.  Is there any more documentation than the web page
 https://dlang.org/spec/garbage.html or should I just browse druntime
 code?

I don't think there is more than that.

 Also pointers (pun maybe) on finding who has the references keeping memory from
 being collected.

There is a "leak detector" in the GC compiled into it the with 
-debug=LOGGING, but I guess noone has been using it the last couple of 
years (and it seems to me it doesn't really do anything more than 
printing allocations).

I used -debug=PRINTF, -debug=PRINTF_COLLECT and -debug=PRINTF_TO_FILE in 
the past and grepped the resulting gcx.log. You might want to uncomment 
some printf in the mark function, too.

Dan Olson <gorox comcast.net> writes:

Rainer Schuetze <r.sagitario gmx.de> writes:

 On 05.01.2016 01:39, Dan Olson wrote:
 I haven't played with any of the new GC configuration options introduced
 in 2.067, but now need to.  An application on watchOS currently has
 about 30 MB of RAM.  Is there any more documentation than the web page
 https://dlang.org/spec/garbage.html or should I just browse druntime
 code?

 I don't think there is more than that.

 Also pointers (pun maybe) on finding who has the references keeping
 memory from
 being collected.

 There is a "leak detector" in the GC compiled into it the with
 -debug=LOGGING, but I guess noone has been using it the last couple of
 years (and it seems to me it doesn't really do anything more than
 printing allocations).

 I used -debug=PRINTF, -debug=PRINTF_COLLECT and -debug=PRINTF_TO_FILE
 in the past and grepped the resulting gcx.log. You might want to
 uncomment some printf in the mark function, too.

Thanks Raniner!