Quantifying the Performance of Garbage Collection vs. Explicit Memory Management

[renoX]

Craig Black Wrote:
> "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. 

Uh? Does Windows VM provides enough information as needed by the GC in the paper or are you thinking about a totally different GC?

For the records, the authors of the GC in the paper submitted their VM patch for inclusion in the standard Linux kernel, but they didn't manage to convince kernel maintainers to include it.. At the time, the JVM was proprietary, if their GC goes into the JVM now that it is GPL maybe it would be a stronger argument.

Regards,
renoX