www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - GC-less tutorial?

reply "Tove" <tove fransson.se> writes:
Hi,

are there any good tutorials for using D totally without GC, 
detailing some common pitfalls?

One thing on my wishlist would be a way to detect accidental GC 
allocations resulting from side-effects of every-day 
operations... generating linking errors would be sufficient for 
detecting this...
Apr 07 2012
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-04-07 17:25, Tove wrote:
 Hi,

 are there any good tutorials for using D totally without GC, detailing
 some common pitfalls?

 One thing on my wishlist would be a way to detect accidental GC
 allocations resulting from side-effects of every-day operations...
 generating linking errors would be sufficient for detecting this...

The GC is plugable at link time, just remove it and you'll get linker errors when it's used. -- /Jacob Carlborg
Apr 07 2012
prev sibling next sibling parent Artur Skawina <art.08.09 gmail.com> writes:
On 04/07/12 17:25, Tove wrote:
 Hi,
 
 are there any good tutorials for using D totally without GC, detailing some
common pitfalls?
 
 One thing on my wishlist would be a way to detect accidental GC allocations
resulting from side-effects of every-day operations... generating linking
errors would be sufficient for detecting this...

One problem with this is that the runtime wants to alloc some things before your code gets to run - so you can't just remove the functions from the build. You're left with either modifying the runtime or somehow ignoring the initial allocations (which usually won't cause any problems). If using a custom RT would have been an option you wouldn't be asking these questions (as you could just omit the symbols), so... If your platform supports gdb, try creating a text file "trapallocs" containing: b gc_malloc b gc_qalloc b gc_calloc b gc_realloc b gc_extend then run "gdb -x ./trapallocs -ex run --args ./your_app" The debugger will stop at the first allocation and you can then use "bt" to check what's going on, then "c" to skip to the next alloc. The first few will come from the runtime and various module ctors, but anything after that will be caused by your code, directly or indirectly. You can also trap just the array ops with eg: b _d_arraycatT b _d_arraycatnT b _d_arrayappendT b _d_arrayappendcTp b _d_newarrayT etc Once the runtime becomes a shared library simpler solutions will be possible, but, until then, it doesn't get much better than this. You need some way to determine which allocations are "legal" and which are not; doing this w/o a custom runtime is probably not worth the effort... And, yes, the initial runtime allocations could (and should) me made to use a different path; some of them shouldn't happen at all. For example std.datetime alone causes two allocs via _d_newclass, in every D app that imports std.stdio... artur
Apr 07 2012
prev sibling parent "Tove" <tove fransson.se> writes:
On Saturday, 7 April 2012 at 17:31:02 UTC, Artur Skawina wrote:
 On 04/07/12 17:25, Tove wrote:
 Hi,
 
 are there any good tutorials for using D totally without GC, 
 detailing some common pitfalls?
 
 One thing on my wishlist would be a way to detect accidental 
 GC allocations resulting from side-effects of every-day 
 operations... generating linking errors would be sufficient 
 for detecting this...

One problem with this is that the runtime wants to alloc some things before your code gets to run - so you can't just remove the functions from the build. You're left with either modifying the runtime or somehow ignoring the initial allocations (which usually won't cause any problems). If using a custom RT would have been an option you wouldn't be asking these questions (as you could just omit the symbols), so... If your platform supports gdb, try creating a text file "trapallocs" containing: b gc_malloc b gc_qalloc b gc_calloc b gc_realloc b gc_extend then run "gdb -x ./trapallocs -ex run --args ./your_app" The debugger will stop at the first allocation and you can then use "bt" to check what's going on, then "c" to skip to the next alloc. The first few will come from the runtime and various module ctors, but anything after that will be caused by your code, directly or indirectly. You can also trap just the array ops with eg: b _d_arraycatT b _d_arraycatnT b _d_arrayappendT b _d_arrayappendcTp b _d_newarrayT etc Once the runtime becomes a shared library simpler solutions will be possible, but, until then, it doesn't get much better than this. You need some way to determine which allocations are "legal" and which are not; doing this w/o a custom runtime is probably not worth the effort... And, yes, the initial runtime allocations could (and should) me made to use a different path; some of them shouldn't happen at all. For example std.datetime alone causes two allocs via _d_newclass, in every D app that imports std.stdio... artur

great, thanks for the hint, I didn't think of using breakpoints at first... but you are right, given good enough unit tests, the coverage would be sufficient!
Apr 08 2012