Quantifying the Performance of Garbage Collection vs. Explicit Memory Management

[Robert Fraser]

Sean Kelly wrote:
> == 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

What's wrong with having different collectors for different OSes? In 
fact, with Tango's pluggable GC, I can see it being very easy to get 
collectors tailor-made to the abuse a particular piece of software plans 
to put on them. For example, it would be possible to create a moving 
collector or metronomic collector and compile that in. That would impose 
a number of restrictions/requirements on the programmer which a general 
mark-and-sweep would not, but if the user was explicitly compiling that 
in, he would be aware of that.