[xmlp] the recent garbage collector performance improvements
sandford at jhu.edu
Thu Feb 2 18:48:20 PST 2012
On Thu, 02 Feb 2012 19:31:50 -0600, H. S. Teoh <hsteoh at quickfur.ath.cx> wrote:
> Speaking of GC improvements, I googled around a bit and found this
> thread from 2 years ago:
> Especially interesting is this paper:
> Nonintrusive Cloning Garbage Collector with Stock Operating
> System Support.
> Has anything been done along these lines since that time? Seems like
> this particular GC algorithm is exactly the kind we need for D. It's a
> conservative mark-and-sweep algo with a very low overhead(*), mark phase
> concurrent with mutator thread(s), and lazy incremental sweeping at
> allocation time. Synchronization is automatically done by default OS
> kernel-space mechanisms (copy on write memory pages).
> More to the point, how easy/hard is it to switch between GCs in the
> current D implementation(s)? I think it would be helpful if these kinds
> of experimental GCs were available in addition to the current default
> GC, and people can play around with them and find out which one(s) are
> the cream of the crop. Otherwise we're just bottlenecked at a small
> number of people who can actually play with GC algos for D -- which
> means improvements will be slow.
> (*) True on *nix systems anyway, but judging from comments in
> that thread, Windoze also was acquiring equivalent functionality -- and
> this being 2 years ago, I'm assuming it's available now.
So to answer your question, yes, someone has made one of these types of GC for D called CDGC. No, it doesn't look like Windows will support this anytime soon. And cloning GCs, don't solve the problems of large heaps, soft/hard realtime issues like game render threads, and it actually makes the embarrassingly long pause (when they happen) longer. Now, CDGC, as I understand it, is better written than our current GC and would probably improve things, but I don't see it as the final end goal.
More information about the Digitalmars-d