OSNews thread here degenerates into GC vs not

[Sean Kelly]

Mike Capp wrote:
> Georg Wrede wrote:
>> Who's had a GC problem /for real/?
> 
> Resharper refactoring plugin for Visual Studio; we use it heavily for our C#
> development. It regularly freezes up for a minute or so at a time. That's the
> dotNet runtime's GC, granted, but I have a hard time believing that D's would do
> better.

That sounds like bad program design rather than bad GC design.  Were the 
app written using conventional allocation it would either be visibly 
slow or leak like a sieve.

> This isn't as simple as a "GC vs not" debate; I don't think anyone (here, at
> least) would argue that GC is worthless. Rather there are at least three open
> questions:
> 
> 1) When and where is GC appropriate?

When the memory overhead is affordable (GCs can consume 40% more system 
memory for the same amount of user memory as traditional allocators). 
For very large applications, I think a combination approach would be 
most likely.  GCed memory for most of the throw-away data used during 
processing and malloc/free or mmap for the rest.  This is one area where 
D has an advantage over Java, as it has built-in support for mixed-mode 
allocation.  For comparison, try allocating an array larger than 1 
million elements in Java--the implementation I've tried have been unable 
to do so (though this woulc obviously be addressed by a specialized GC).

> 2) When it is appropriate, how good is D's implementation of it?

 From an implementation standpoint, I really have few complaints.  The 
code is fairly clean, succinct, and extensible.  As far as 
application-level use is concerned, that's a difficult question to 
answer for two reasons.  First, I think any well-written app simply 
won't stress a GC in ways that it wasn't meant to be stressed, so some 
testing almost necessarily has to create unrealistic conditions to test 
with.  Second, I haven't yet ported or written an app in D that has such 
refined allocator requirements that the nuances of a GCs performance 
would matter.  Perhaps someone who's written a game in D could comment 
on the obstacles they encountered related to garbage collector performance?

> 3) When it's not appropriate, how well does D support GC-less (and possibly
> allocation-less) programming?

Stack allocation of classes could be better, though 'scope' is a decent 
enough substitute if heap allocation isn't a problem.  Other than that, 
placement new and delete work so long as classes have new/delete 
statements defined, but it might be nice if these weren't required.  I'm 
half tempted to add these functions to Object simply to avoid this, 
assuming it's even possible to have virtual new/delete routines.

         new( size_t size, void* pos )
         {
             return pos;
         }

         delete( void* pos )
         {

         }


Sean