Disable GC entirely

[Benjamin Thaut]

Am 09.04.2013 14:00, schrieb Johannes Pfau:
> Am Tue, 09 Apr 2013 11:29:09 +0100
> schrieb "Regan Heath" <regan at 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