Am Tue, 09 Apr 2013 11:29:09 +0100 schrieb "Regan Heath" <[email protected]>: > > 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.
