
Hi Stefan,
A real time incremental gc would be really cool. Some people claim they exist, but which languages have one?
james mccartney's supercollider [1] has a non-copying incremental collector based on [2], though not a parallel one.
btw, is an implementation of the incremental collector described in [3] available somewhere? are there any plans to incorporate it into future ghc versions?
<sk>
[1] http://supercollider.sourceforge.net [2] P. R. Wilson and M. S. Johnstone. Real-time non-copying garbage collection. In ACM OOPSLA Wsorkshop on Memory Management and Garbage Collection, 1993. [3] A. M. Cheadle, A. J. Field, S. Marlow, S. L. P. Jones, and R. L. While. Exploring the barrier to entry: incremental generational garbage collection for haskell. In ISMM ’04: Proceedings of the 4th international symposium on Memory management, pages 163–174, New York, NY, USA, 2004. ACM.
The collector in [3] isn't in a production version of GHC for several reasons, mainly because I finished it prior to significant reworking of GHC's backend (C-- target etc), and while finishing my PhD I couldn't devote the time to keeping it current - it is a massive engineering task! Furthermore, the scheduling of work-based increments are problematic and I only made a preliminary start with time-based collection. That said: Our current work here at Imperial has focussed on implementing exactly what we did for GHC in Java, targetting the Jikes RVM, and we've made alot of progress (*shameless plug*, check out our paper at VEE 2008: /A Method Specialisation and Virtualised Execution Environment for Java). /With this work nearing completion my attention is turning back to GHC but with particular focus on concurrency, and multi-core / parallel collection and the STM world... I haven't ruled out the collector being incremental too, so I wouldn't be surprised if I resurrect this code base... Of course, these things take time and I have other commitments... I know Simon has been working on parallel collection and I would expect this to be more generally useful than a single-threaded incremental collector, so I'll leave it to him to say how that's coming on... Cheers Andy // -- ********************************************************************* * Andrew Cheadle email: a.cheadle@doc.ic.ac.uk * * Department of Computing http://www.doc.ic.ac.uk/~amc4/ * * Imperial College London * *********************************************************************