Disable GC entirely

[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.