Disable GC entirely

[Regan Heath]

On Mon, 08 Apr 2013 19:02:19 +0100, Johannes Pfau <nospam at example.com>  
wrote:

> Am Mon, 08 Apr 2013 11:57:08 +0100
> schrieb "Regan Heath" <regan at netmail.co.nz>:
>
>> On Mon, 08 Apr 2013 09:58:15 +0100, Manu <turkeyman at gmail.com> wrote:
>> > I suspect Andrei for one knows this, and that's why the D
>> > containers are so... barely existing. The language is not yet ready
>> > to say with confidence
>> > how they should look.
>>
>> That, and before you can design the containers you need a concrete
>> allocator interface design.  Actually, this is likely the same
>> blocker for GC-free D as well.
>>
>> D should have a set of global allocator hooks.  If it did, you could
>> easily catch unexpected allocations in tight loops and realtime
>> code.  If it did, GC-free D would be trivial - just replace the
>> default GC based allocator with a malloc/free one, or any other
>> scheme you like.
>>
>
> IIRC stuff like closures and dynamic array appending rely on a gc and
> it wouldn't be trivial to change that to a normal alloc/free allocator.

True, my comment actually contained 2 ideas, neither of which I explained  
properly :p

Idea #1.  Have alloc/realloc/free hooks for use /with/ the GC.  Allowing  
Manu to catch unexpected allocations, or provide the GC with memory from a  
pre-allocated block etc.  In this case we'd probably want the allocator to  
control when the GC performed collection - to avoid it in realtime code.

I think this rather simple idea would give a lot more control and  
flexibility to applications with realtime requirements.  As Manu himself  
said (IIRC) he doesn't mind the GC, what he minds is the hidden  
allocations which themselves cause a delay, and I would imagine he would  
mind even more if a collection was triggered by one :p


Idea #2.  Replace the GC with allocators.  In this case, as you say,  
without a GC we would have problems catching the 'free' for objects like  
closures and arrays (as we'd have no reference to them in user code upon  
which to call 'destroy' or similar.

So, we'd either have to replace the GC with reference counting /and/ have  
some compiler support for triggers on references leaving scope, for  
example.  Or, we could require code to call 'destroy' on everything to be  
freed and force users to keep references to closures and arrays and  
'destroy' them.

There are likely cases where the user code never sees the closure  
reference, in this case the allocator itself could perform some object  
tracking.  We could aid this by having an allocation 'type' allowing the  
allocator to track only closure or array allocations - for example, and  
ignore user allocations where it assumes the user code will call 'destroy'  
on the reference (as delete/free would be called in C/C++).

> 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

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/