www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - GC configuration docs

reply 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
Jan 04
parent reply 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.
Jan 04
parent 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!
Jan 05