GC, the simple solution

Jeff Parsons jeffrparsons at optusnet.com.au
Wed Jun 7 01:41:38 PDT 2006


Sean Kelly wrote:
> For what it's worth, incremental GC is similar to refcounting in that 
> the cost is distributed across pointer use to avoid the need for a 
> costly mark/sweep phase.  I've even seen hard-realtime incremental GC 
> implementations, so it's a long-term solution worth considering.

My _only_ significant beef with D so far as been the unbound time for a 
garbage collection; therefore, if an incremental garbage collector built 
into D could guarantee me a set maximum time would be taken for each 
garbage collection (which I would manually induce as often as possible) 
then unless the efficiency hit is TERRIBLE I would be all over it.

What I'm really curious about, however, is how important this is to 
_other_ people - especially Walter. Would it be reasonable to say that 
it seems D has been designed largely without long-term real-time 
performance in mind? Sure, there are workarounds, but I haven't seen 
anything elegant yet that will let me use D for such applications 
without making my memory management more complicated than it would have 
been in C++. Is anything in the works?



More information about the Digitalmars-d mailing list