Am 09.04.2013 14:00, schrieb Johannes Pfau:
Am Tue, 09 Apr 2013 11:29:09 +0100
schrieb "Regan Heath" <re...@netmail.co.nz>:
A good & simple start would be a -vgc switch, similar to -vtls which
prints out all hidden memory allocations. Custom allocators are
still important for the library (toString etc). Apart from that I
would just stay away from language features which allocate. For
example instead of using the concatenate operators I'd just use
something like appender (which should then support custom
allocators).
Did you see Manu's problem case? I can't recall the method name but
it was not one which suggested it would allocate, and it didn't in
the general case but in a very specific case it did. As it stands,
it's very hard to tell which language features allocate (without code
inspection of the compiler and standard library) so it's hard to
avoid.
R
toUpperInPlace IIRC? Yes, -vgc would not directly help here as
toUpperInPlace is a library function. But I think this is a library /
documentation bug:
1: We should explicitly document if a function is not supposed to
allocate
2: If a function is called "inPlace" but can still allocate, it needs a
huge red warning.
Those kind of things can be solved partially with correctly documented
functions. But hidden allocations caused by the language (closures,
array literals) are imho more dangerous and -vgc could help there.
Without -vgc it's very difficult to verify if some code could call into
the gc.
Btw: implementing -vgc shouldn't be too difficult: We have to check all
runtime hooks ( http://wiki.dlang.org/Runtime_Hooks ) for allocations,
then check all places in dmd where calls to those hooks are emitted.
It's actually very easy to find hidden allocations. If you remove the gc
entierly from the runtime hidden allocations will cause linker errors.
Kind Regards
Benjamin Thaut
--
Kind Regards
Benjamin Thaut
