On 10 April 2013 23:45, Benjamin Thaut <[email protected]> wrote:
> Am 09.04.2013 14:00, schrieb Johannes Pfau: > > 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<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. > Not a particularly user-friendly approach. I'd rather think of some proper tools/mechanisms to help in this area :)
