Componentizing D's garbage collector

Frustrated c1514843 at drdrb.com
Tue Jan 14 16:24:47 PST 2014


On Tuesday, 14 January 2014 at 22:36:12 UTC, Benjamin Thaut wrote:
> Am 14.01.2014 23:10, schrieb Walter Bright:
>>
>> I already agreed that there are better ways.
>>
>
> Then this was a big misunderstanding.

So, the issue seems to be that everyone is treating the GC as the 
Thors hammer and seeing everything as a nails?

The GC does and can not solve all problems. Why force people to 
use it when it doesn't work well?

I would think having a multi-layered approach would be best. 
Allow the GC to do everything it can but also allow it to be 
configured from 0 to 60. For noobs, non-realtime apps, etc the GC 
can be set to do it all. One can trade speed for memory(less 
memory, more scanning etc...). One can disable to in specific 
cases(such as on unions), have separate heaps for GC memory and 
non-GC allocated memory, etc.

It seems that a more robust GC with many features(with the 
feature of not using it and either manually allocating or using 
ARC).

The the only real issue becomes how to keep the GC in sync with 
the non-GC allocated memory... and this only happens if one 
chooses to use non-GC features(which must be intentional so 
hopefully the programming knows what he's doing if he got that 
far).

I doubt this will ever be possible to solve efficiently so why 
bother? Leave it up to the programmer to deal with it. Make some 
resources available to solve these problems but don't try to 
dictate what must be done. If the programmer is going to bypass 
the GC he already must have good reasons so why put up 
roadblocks? Cause *you* think you know better than him what he 
needs to do?


For example, suppose we have a non-GC based pointer. Allow the 
programmer to mark it as a pointer with certain contextual 
parameters so that either the GC ca n "deal with it" better or at 
least for debugging purposes help find memory leaks.

I'm way more interested in having a GC that doesn't stop the 
world and a compiler that doesn't require the GC for simple stuff 
as slices(could it not use a buffer and/or ARC 
instead/alternatively?).


More information about the Digitalmars-d mailing list