Disable GC entirely

[Manu]

On 10 April 2013 23:45, Benjamin Thaut <code at benjamin-thaut.de> wrote:

> 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<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 :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130411/f4902326/attachment.html>