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