www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - GC: Memory keeps growing

reply "Chris" <wendlec tcd.ie> writes:
My garbage collected app starts with ~10 MB in memory, however 
with every execution of code it grows by at least 0.2 MB (or more 
depending on the input). Although I can see memory being freed 
(say it goes up to 32 MB and drops to 14 MB), it keeps on growing 
slowly but surely.

I use structs for the most part [1] and reuse arrays at critical 
points, clearing them with destroy() after use. Maybe this is the 
problem? I dunno. I'd be grateful for any hints.

[1] The few classes I use are either singletons or instantiated 
only once and cached when the programs starts.
Apr 15 2015
parent reply Rikki Cattermole <alphaglosined gmail.com> writes:
On 15/04/2015 11:44 p.m., Chris wrote:
 My garbage collected app starts with ~10 MB in memory, however with
 every execution of code it grows by at least 0.2 MB (or more depending
 on the input). Although I can see memory being freed (say it goes up to
 32 MB and drops to 14 MB), it keeps on growing slowly but surely.

 I use structs for the most part [1] and reuse arrays at critical points,
 clearing them with destroy() after use. Maybe this is the problem? I
 dunno. I'd be grateful for any hints.

 [1] The few classes I use are either singletons or instantiated only
 once and cached when the programs starts.
Sounds like you are doing a LOT of allocations. Try with -vgc during compilation to find out where you are allocating.
Apr 15 2015
parent reply "Chris" <wendlec tcd.ie> writes:
On Wednesday, 15 April 2015 at 11:48:26 UTC, Rikki Cattermole 
wrote:
 On 15/04/2015 11:44 p.m., Chris wrote:
 My garbage collected app starts with ~10 MB in memory, however 
 with
 every execution of code it grows by at least 0.2 MB (or more 
 depending
 on the input). Although I can see memory being freed (say it 
 goes up to
 32 MB and drops to 14 MB), it keeps on growing slowly but 
 surely.

 I use structs for the most part [1] and reuse arrays at 
 critical points,
 clearing them with destroy() after use. Maybe this is the 
 problem? I
 dunno. I'd be grateful for any hints.

 [1] The few classes I use are either singletons or 
 instantiated only
 once and cached when the programs starts.
Sounds like you are doing a LOT of allocations. Try with -vgc during compilation to find out where you are allocating.
Just did that, for the most part it's: - indexing an associative array may cause GC allocation - operator ~= may cause GC allocation - operator ~ may cause GC allocation Whereas "'new' causes GC allocation" is rare and applies only to classes that are instantiated only once. I use appender a lot, too. There might be some low-hanging fruit there. However, before I change anything, maybe you guys have some suggestions.
Apr 15 2015
next sibling parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 16/04/2015 12:03 a.m., Chris wrote:
 On Wednesday, 15 April 2015 at 11:48:26 UTC, Rikki Cattermole wrote:
 On 15/04/2015 11:44 p.m., Chris wrote:
 My garbage collected app starts with ~10 MB in memory, however with
 every execution of code it grows by at least 0.2 MB (or more depending
 on the input). Although I can see memory being freed (say it goes up to
 32 MB and drops to 14 MB), it keeps on growing slowly but surely.

 I use structs for the most part [1] and reuse arrays at critical points,
 clearing them with destroy() after use. Maybe this is the problem? I
 dunno. I'd be grateful for any hints.

 [1] The few classes I use are either singletons or instantiated only
 once and cached when the programs starts.
Sounds like you are doing a LOT of allocations. Try with -vgc during compilation to find out where you are allocating.
Just did that, for the most part it's: - indexing an associative array may cause GC allocation - operator ~= may cause GC allocation - operator ~ may cause GC allocation Whereas "'new' causes GC allocation" is rare and applies only to classes that are instantiated only once. I use appender a lot, too. There might be some low-hanging fruit there. However, before I change anything, maybe you guys have some suggestions.
The only real suggestions here are -vgc and nogc. Something must, must be holding on to references.
Apr 15 2015
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Wednesday, 15 April 2015 at 12:03:49 UTC, Chris wrote:
 There might be some low-hanging fruit there. However, before I 
 change anything, maybe you guys have some suggestions.
See if switching to 64-bit mode changes anything.
Apr 16 2015
parent "Chris" <wendlec tcd.ie> writes:
On Thursday, 16 April 2015 at 18:51:25 UTC, Kagamin wrote:
 On Wednesday, 15 April 2015 at 12:03:49 UTC, Chris wrote:
 There might be some low-hanging fruit there. However, before I 
 change anything, maybe you guys have some suggestions.
See if switching to 64-bit mode changes anything.
64bit is the default. I've monitored the program for a while and it seems that it is not growing indefinitely. It might go up from 10 MB to 20 MB, but then it is happy with 20 MB for ages. It might even go down to 14 MB again, only to increase to 16 or 18 MB later. It's a bit weird. I analyzed it step by step but I couldn't find a culprit. Sometimes it stays constant for ages like 15.2 MB no matter what I put through it. Then I put one word through it and it goes up to 15.4 MB. It's a bit odd. However, I don't know the exact behavior of the GC, but it's a good time to start looking into it.
Apr 17 2015