What is the mutator?

[Simon Marlow]

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