www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Any way to track memory allocations?

reply wade Shen <swadenator gmail.com> writes:
I'm writing some performance sensitive code (real time processing) for which
I've tried to minimize the number of memory allocations by using preallocated
objects pools.  Unfortunately, during the course of running, it seems that lots
of memory is still getting allocated even though all explicit "new" and array
slicing operations have been moved out of the main processing loops.  As a
result the program is quite slow when garbage collection is enabled (but very
fast otherwise).

Is there a way to track down where memory is being allocated if I'm using
phobos? Any recommendations would be appreciated.

thanks,
wade
Feb 24 2009
parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, Feb 24, 2009 at 12:00 PM, wade Shen <swadenator gmail.com> wrote:

 I'm writing some performance sensitive code (real time processing) for wh=


ich I've tried to minimize the number of memory allocations by using preall=
ocated objects pools. =A0Unfortunately, during the course of running, it se=
ems that lots of memory is still getting allocated even though all explicit=
 "new" and array slicing operations have been moved out of the main process=
ing loops. =A0As a result the program is quite slow when garbage collection=
 is enabled (but very fast otherwise).

Array slicing does not cause the GC to run.  It is essentially free,
which is a wonderful thing.


 Is there a way to track down where memory is being allocated if I'm using=


 phobos? Any recommendations would be appreciated.

This is something I have *always* wanted.  Unfortunately I don't think
it's possible to add such instrumentation without modifying and
recompiling Phobos.  Even if you're using D2, which uses druntime,
there's no such thing.

Hm, actually..

If you *are* using D2, you might be able to replace the GC interface
with a "debug" interface that just forwards calls to the normal GC.
This is a capability druntime inherited from the Tango runtime - the
GC is separated from the rest of the standard library and can actually
be replaced at link-time.  I don't know if D2 links all three parts of
druntime into a single library or not, though.

Here are some other things that could be causing allocation:

- Array appending (~=3D) can cause it; array concatenation (~) is
guaranteed to cause it.
- Array .dup.
- Adding items to associative arrays.
- In D2, nested functions/anonymous delegates can allocate memory
secretly, unless you're careful and only pass them to "scope" delegate
parameters.
Feb 24 2009
next sibling parent reply BCS <ao pathlink.com> writes:
Reply to Jarrett,



 Hm, actually..
 
 If you *are* using D2, you might be able to replace the GC interface
 with a "debug" interface that just forwards calls to the normal GC.
 This is a capability druntime inherited from the Tango runtime - the
 GC is separated from the rest of the standard library and can actually
 be replaced at link-time.  I don't know if D2 links all three parts of
 druntime into a single library or not, though.
 


Someone should make such a GC shell. You could add a BanAlloc(bool) option 
that would turn on an assert on any allocation. This could be set and cleared 
around the RT parts of the code.
Feb 24 2009
parent reply "Denis Koroskin" <2korden gmail.com> writes:
On Tue, 24 Feb 2009 20:40:13 +0300, BCS <ao pathlink.com> wrote:


 Reply to Jarrett,



 Hm, actually..
  If you *are* using D2, you might be able to replace the GC interface
 with a "debug" interface that just forwards calls to the normal GC.
 This is a capability druntime inherited from the Tango runtime - the
 GC is separated from the rest of the standard library and can actually
 be replaced at link-time.  I don't know if D2 links all three parts of
 druntime into a single library or not, though.


 Someone should make such a GC shell. You could add a BanAlloc(bool)  
 option that would turn on an assert on any allocation. This could be set  
 and cleared around the RT parts of the code.


Good idea!
Feb 24 2009
parent reply wade <swadenator gmail.com> writes:
Yes,
this would be a great idea, especially for RT production software.

wade

Denis Koroskin Wrote:


 On Tue, 24 Feb 2009 20:40:13 +0300, BCS <ao pathlink.com> wrote:
 

 Reply to Jarrett,



 Hm, actually..
  If you *are* using D2, you might be able to replace the GC interface
 with a "debug" interface that just forwards calls to the normal GC.
 This is a capability druntime inherited from the Tango runtime - the
 GC is separated from the rest of the standard library and can actually
 be replaced at link-time.  I don't know if D2 links all three parts of
 druntime into a single library or not, though.


 Someone should make such a GC shell. You could add a BanAlloc(bool)  
 option that would turn on an assert on any allocation. This could be set  
 and cleared around the RT parts of the code.


 
 Good idea!
Feb 24 2009
parent BCS <ao pathlink.com> writes:
Reply to wade,


 Yes,
 this would be a great idea, especially for RT production software.
 wade
 
 Denis Koroskin Wrote:
 


For production software it would get tricky. Are you better of doing the 
alloc or just failing?
Feb 24 2009
prev sibling next sibling parent wade <swadenator gmail.com> writes:
Thanks,

That's helpful.  I'm using D 1.0.  I've eliminated all array concats, dups,
etc. but there's still a significant amount of memory being allocated that I
can't seem to detect.

Perhaps, I can recompile an instrumented version of phobos...

wade

Jarrett Billingsley Wrote:


 On Tue, Feb 24, 2009 at 12:00 PM, wade Shen <swadenator gmail.com> wrote:

 I'm writing some performance sensitive code (real time processing) for which
I've tried to minimize the number of memory allocations by using preallocated
objects pools.  Unfortunately, during the course of running, it seems that lots
of memory is still getting allocated even though all explicit "new" and array
slicing operations have been moved out of the main processing loops.  As a
result the program is quite slow when garbage collection is enabled (but very
fast otherwise).


 
 Array slicing does not cause the GC to run.  It is essentially free,
 which is a wonderful thing.
 

 Is there a way to track down where memory is being allocated if I'm using
phobos? Any recommendations would be appreciated.


 
 This is something I have *always* wanted.  Unfortunately I don't think
 it's possible to add such instrumentation without modifying and
 recompiling Phobos.  Even if you're using D2, which uses druntime,
 there's no such thing.
 
 Hm, actually..
 
 If you *are* using D2, you might be able to replace the GC interface
 with a "debug" interface that just forwards calls to the normal GC.
 This is a capability druntime inherited from the Tango runtime - the
 GC is separated from the rest of the standard library and can actually
 be replaced at link-time.  I don't know if D2 links all three parts of
 druntime into a single library or not, though.
 
 Here are some other things that could be causing allocation:
 
 - Array appending (~=) can cause it; array concatenation (~) is
 guaranteed to cause it.
 - Array .dup.
 - Adding items to associative arrays.
 - In D2, nested functions/anonymous delegates can allocate memory
 secretly, unless you're careful and only pass them to "scope" delegate
 parameters.
Feb 24 2009
prev sibling next sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Jarrett Billingsley wrote:


 On Tue, Feb 24, 2009 at 12:00 PM, wade Shen <swadenator gmail.com> wrote:

 I'm writing some performance sensitive code (real time processing) for 




which I've tried to minimize the number of memory allocations by using 
preallocated objects pools.  Unfortunately, during the course of running, it 
seems that lots of memory is still getting allocated even though all 
explicit "new" and array slicing operations have been moved out of the main 
processing loops.  As a result the program is quite slow when garbage 
collection is enabled (but very fast otherwise).

 
 Array slicing does not cause the GC to run.  It is essentially free,
 which is a wonderful thing.
 

 Is there a way to track down where memory is being allocated if I'm using 




phobos? Any recommendations would be appreciated.

 
 This is something I have *always* wanted.  Unfortunately I don't think
 it's possible to add such instrumentation without modifying and
 recompiling Phobos.  Even if you're using D2, which uses druntime,
 there's no such thing.


Might it be possible to use tangobos for this purpose and just add asserts 
in the GC code? Last time I looked it was pretty straightforward to 
recompile Tango.
Feb 24 2009
parent reply wade <swadenator gmail.com> writes:
Thanks again for all the help.  I found what the problem was and it wasn't
obvious (at least to me):

float[uint] arr;

foreach (uint k; arr.keys)
{
 ...
}

Changing this to:

foreach (uint k, float v; arr)
{
...
}

fixes the leak.  I guess the keys array is constructed on the fly?

wade

Lutger Wrote:


 Jarrett Billingsley wrote:
 

 On Tue, Feb 24, 2009 at 12:00 PM, wade Shen <swadenator gmail.com> wrote:

 I'm writing some performance sensitive code (real time processing) for 




 which I've tried to minimize the number of memory allocations by using 
 preallocated objects pools.  Unfortunately, during the course of running, it 
 seems that lots of memory is still getting allocated even though all 
 explicit "new" and array slicing operations have been moved out of the main 
 processing loops.  As a result the program is quite slow when garbage 
 collection is enabled (but very fast otherwise).

 
 Array slicing does not cause the GC to run.  It is essentially free,
 which is a wonderful thing.
 

 Is there a way to track down where memory is being allocated if I'm using 




 phobos? Any recommendations would be appreciated.

 
 This is something I have *always* wanted.  Unfortunately I don't think
 it's possible to add such instrumentation without modifying and
 recompiling Phobos.  Even if you're using D2, which uses druntime,
 there's no such thing.


 
 Might it be possible to use tangobos for this purpose and just add asserts 
 in the GC code? Last time I looked it was pretty straightforward to 
 recompile Tango.
Feb 24 2009
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
wade wrote:

 Thanks again for all the help.  I found what the problem was and it wasn't
obvious (at least to me):
 
 float[uint] arr;
 
 foreach (uint k; arr.keys)
 {
  ...
 }
 
 Changing this to:
 
 foreach (uint k, float v; arr)
 {
 ....
 }
 
 fixes the leak.  I guess the keys array is constructed on the fly?
 
 wade


Yup.

It's a pity that we don't have, oh I don't know, some sort of efficient
iterable interface that doesn't cause a heap allocation that the runtime
could use instead *cough*hint*cough*andrei*cough*ranges*cough*.

  -- Daniel
Feb 24 2009
parent reply Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, Feb 24, 2009 at 8:23 PM, Daniel Keep
<daniel.keep.lists gmail.com> wrote:


 Yup.

 It's a pity that we don't have, oh I don't know, some sort of efficient
 iterable interface that doesn't cause a heap allocation that the runtime
 could use instead *cough*hint*cough*andrei*cough*ranges*cough*.


You can use "foreach(k; aa)" and "foreach(_, v; aa)".

The thing is they're not always substitutes for .keys and .values.
For example, if you want to modify the AA during the foreach loop, you
have to use something like "foreach(k; aa.keys)" since you need a
"snapshot" of the keys as they were before you started modifying it.
Feb 24 2009
parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Jarrett Billingsley wrote:

 On Tue, Feb 24, 2009 at 8:23 PM, Daniel Keep
 <daniel.keep.lists gmail.com> wrote:
 

 Yup.

 It's a pity that we don't have, oh I don't know, some sort of efficient
 iterable interface that doesn't cause a heap allocation that the runtime
 could use instead *cough*hint*cough*andrei*cough*ranges*cough*.


 
 You can use "foreach(k; aa)" and "foreach(_, v; aa)".
 
 The thing is they're not always substitutes for .keys and .values.
 For example, if you want to modify the AA during the foreach loop, you
 have to use something like "foreach(k; aa.keys)" since you need a
 "snapshot" of the keys as they were before you started modifying it.


True; although I'm one of those people who stays up at night, plotting
the gruesome demise of invisible allocations, so I tend to do manually
create and destroy the storage for the keys.

In a perfect world, we'd have extension methods, and then we could just
do this:

RangeType!(T)[] toArray(T)(ref T this) if isRange!(T)
{
  ...
}

foreach( k ; aa.keys.toArray ) ...

My own policy is that if you have to choose between two designs, one
where you always allocate and the other where you can optionally
allocate, go for the second.

  -- Daniel
Feb 24 2009
prev sibling parent Jarrett Billingsley <jarrett.billingsley gmail.com> writes:
On Tue, Feb 24, 2009 at 8:04 PM, wade <swadenator gmail.com> wrote:


 fixes the leak. =A0I guess the keys array is constructed on the fly?


Oh, yes X|  .keys and .values of AAs are constructed whenever you use them.
Feb 24 2009
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
Jarrett Billingsley wrote:

 On Tue, Feb 24, 2009 at 12:00 PM, wade Shen <swadenator gmail.com> wrote:
 

 Is there a way to track down where memory is being allocated if I'm using
phobos? Any recommendations would be appreciated.


 
 This is something I have *always* wanted.  Unfortunately I don't think
 it's possible to add such instrumentation without modifying and
 recompiling Phobos.  Even if you're using D2, which uses druntime,
 there's no such thing.


This has been on my "to do" list forever.  One of these days I'll 
actually get to it :-)


 Hm, actually..
 
 If you *are* using D2, you might be able to replace the GC interface
 with a "debug" interface that just forwards calls to the normal GC.
 This is a capability druntime inherited from the Tango runtime - the
 GC is separated from the rest of the standard library and can actually
 be replaced at link-time.  I don't know if D2 links all three parts of
 druntime into a single library or not, though.


It does.  Partially because the three-library approach seems to have 
problems on Linux (there are link errors even though everything needed 
is actually present).  But the GC is still easily replaceable.  In fact, 
D2 provides an undocumented way to redirect GC calls, but I don't think 
it will currently work for this form of interception--you'd end up with 
an endless loop.



Sean
Feb 25 2009