Quantifying the Performance of Garbage Collection vs. Explicit Memory Management

[Craig Black]

"Sean Kelly" <sean at invisibleduck.org> wrote in message 
news:frmhe4$20jp$1 at digitalmars.com...
> == Quote from renoX (renosky at free.fr)'s article
>> The same authors have made a VM friendly GC, it is linked at the end the
>> article..
>> http://lambda-the-ultimate.org/node/2391
>> The are two drawback of their GC:
>> 1) The OS needs to be modified so that the VM and the GC communicate.
>> 2) It is a moving GC, in the original paper they compares their GC with
>> moving and non-moving variant and the moving one win.
>> For Java this isn't an issue, but for D it is: working with C's library
>> wouldn't work if the GC is a moving one..
>> I don't know how to fix this one..
>
> There is published research regarding VM-aware garbage collectors, and 
> creating one for D wouldn't be
> terribly difficult.  Portability is more of an issue, as you've mentioned. 
> I believe plugging one into
> Windows isn't terribly difficult, but for *nix it can require a kernel 
> re-compile to get access to the
> proper hooks.  Because of this, I don't think that VM-aware GCs are the 
> best general purpose solution,
> even though their performance can be quite good.
>
>
> Sean

I don't think the *nix kernel recompile issue should be a show stopper.  I 
would be very happy with a prototype that was Windows only.  Once we have it 
working and can measure the benefits, then tackle the *nix issues.  A fast 
GC would really help D to be competitive.  It would be nice if the D 
community was leading GC innovation (like Tango just did with the XML 
parser).

-Craig