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".
Regards,
Malcolm
_______________________________________________
Glasgow-haskell-users mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
