Linus with some good observations on garbage collection

[Andrei Alexandrescu]

On 4/25/11 4:20 PM, Kim D wrote:
>> On 04/25/2011 10:06 AM, Iain Buclaw wrote:
>>> I was thinking of where one implements an alternative runtime that may
>>> not
>>> necessarily interface with a GC, or has different semantics on the use of
>>> the
>>> keyword (the compiler, after all, doesn't know/care what exactly 'delete'
>>> does, it
>>> just does it's job at emitting the correct action we expect from it).
>>> Though it
>>> was late night and I perhaps didn't quite put it right anyway.
>>>
>>> Having literally slept on it though, a runtime with a good GC is one that
>>> doesn't
>>> offer a choice to 'delete' memory - so I am on your side.  Though
>>> reflecting from
>>> my experience with the D2 GC (thinking from a compiler implementers POV),
>>> there
>>> isn't much I can really praise about it.
>>>
>>> Custom (de)allocators I can also see a very good point for removal too,
>>> however
>>> much a stab in the back for those who can use them in the - perhaps
>>> 'one-and-only'
>>> - case for a small amount of speed gain.
>>>
>>> Iain
>>
>> I understand. The right response to this is defining a good custom
>> allocator API and providing good implementations of it.
>>
>> Andrei
>
> Sounds like a good way forward. However, certain operations are currently
> not supported unless the GC is enabled, for instance 'Associative Arrays of
> Strings'... do you imagine the future allocator API beeing flexible enough
> to facilitate this use-case in a GC-less environment? Or at least allowing
> more of the functionality which is currently unsupported without GC?
>
> Kim

An entity relying on GC will by definition have more freedom and more 
safety than one relying on an alternative allocator. It is possible to 
make that transparent to some extent (e.g. define a type to be either 
refcounted or not depending on the allocator used). Total transparency 
would be difficult to achieve.

Andrei