is d-runtime non-gc safe?

[Johannes Pfau]

Steven Schveighoffer wrote:
>On Sat, 03 Dec 2011 12:43:08 -0500, Marco Leise <Marco.Leise at gmx.de>
>wrote:
>
>> Am 03.12.2011, 10:01 Uhr, schrieb Benjamin Thaut  
>> <code at benjamin-thaut.de>:
>>
>>> Thanks, That doesn't sound to bad. If I manage to get a non leaking
>>> non gc version of d-runtime working would there be any interest in
>>> that?
>>>
>>> Kind Regards
>>> Benjamin Thaut
>>
>> That would be most interesting! How do you imagine this could work  
>> though? As an example D array slices work on GC memory and you can
>> have dozens of slices on the same memory block. Would these memory
>> blocks be reference counted then?
>
>D array appending operations require a GC.  You'd have to avoid
>them. This should be possible with some changes to druntime (just find
>all the cases and remove them).
>
>But what's difficult is finding leaks which don't have any anchor to  
>search for.  For example, how do you search for code that allocates
>an array and *doesn't* deallocate it?

I'd say don't replace the GC with a simple malloc/free stub, remove it
completely. Add a switch to dmd (-nogc) which disables all features
which need the gc (especially 'new', array appending, ...). This will
break a lot of code, but you won't have silent memory leaks this way.

Code which should be usable with and without GC could use the new
allocators API once that's finished, or a special "version(NOGC)"
code path.

-- 
Johannes Pfau