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!
