Malcolm Wallace wrote:
Say you are
implementing a network server, for example -- you don't want
to have big spikes in the request latency due to GC.
We think
concurrent GC is unlikely to be practical in the Haskell
setting, due to the extra synchronisation needed in the
mutator.
-- Simon Marlow
It is perfectly possible to do real-time concurrent garbage collection
for Haskell, in an incremental fashion that guarantees a small maximum
bound on each packet of GC work. The tradeoff is that the percentage of
time devoted to GC in total is much greater, and the mutator must do
more work to co-operate with the GC. In other words, the program runs
slower. This tradeoff is the same for all real-time garbage collection
schemes as far as I am aware, in any language - either you can have
responsiveness, or you can have better overall application speed, but
you cannot have both.
So I wonder, to what degree is GC latency controllable in
Haskell? It seems that, pending further research, we can not
hope for concurrent GC.
There have been several papers on real-time GC in Haskell (including one
of my own). There is no technical problem, only performance worries.
This is what I think Simon means by "unlikely to be practical".
You're quite right, I don't really mean "practical", more like "not
cheap enough to replace the existing GC as the default".
My current thoughts on reducing pause times are to adopt a region-style
GC, where the heap is divided into regions and any subset of the regions
can be collected in any GC cycle. This generalisation of generational
GC is becoming quite popular amongst the Java folks in particular.
Without going to proper incremental GC, this eliminates the need to do
full-heap collections (but introduces a slight danger due to cycles
between regions), and leads to shorter, or even bounded, pauses.
Cheers,
Simon
_______________________________________________
Glasgow-haskell-users mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
