[Vm-dev] GC

[Eliot Miranda]

Hi Ben,

> On Apr 27, 2018, at 12:26 AM, Ben Coman <btc at openinworld.com> wrote:
> 
> 
> 
>> On 26 April 2018 at 23:09, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>>  
>> Hi Clément, Hi All,
>> 
>>    I answered a question on Quora on GC recently and that same question was answered by Jon Harrop, who has taken a good look at GC performance.  If you're not on Quora yet, let me encourage you.  This blog post is a good read:
>> 
>> https://flyingfrogblog.blogspot.co.uk/2017/12/does-reference-counting-really-use-less.html
>> 
>> And in Jon's answer to the Quora question he mentions Staccato, A Parallel and Concurrent Real-time Compacting Garbage Collector for Multiprocessors https://pdfs.semanticscholar.org/9770/fc9baf0f2b6c7521f00958973657bf03337d.pdf
>> 
>> That's my reading for today.
>> 
>> _,,,^..^,,,_ (phone)
>> 
> 
> 
> What is the significance of Minimum Mutator Utilisation
> and is a comparative value known for our compactors?

It's an important metric, especially in real-time GC (I got this yesterday from reading the Metronome paper (POPL 03) and Staccato tech report (2008).

Up until Cheng's work, Baker had introduced the notion that real time GCs were those that had bounded maximum pause times.  But Chang pointed out that if you have many small pauses within some interval then the mutator may not be because my delayed for very long, but its overall share of the processor could fall to insufficient levels.  So Cheng introduced the Minimum Mutator Utilization (MMU) metric as the percentage processor utilization by the mutator during some interval.  So for example, achieving 85% utilization over a 20ms period implies both a maximum pause time of 3ms and at least 17ms of runtime, whereas one could imagine (and indeed people have measured in such gcs) a pause of 1ms happening ten times in the same interval which would mean 50% processor utilization.  So MMU is a much better metric that maximum pause time.

So the metric doesn't apply to compaction per se. It applies to GC overhead and latency.

> 
> 
> I thought this was interesting about the mark phase...
> > each thread maintains its own thread-local fragment of the [mark-stack].
> 
> Do I understand correctly that the mark-stack is equivalent to the grey-marked collection?

During incremental collection, yes.  In our case the store check will be extended so that if one stores into a black object, it will be set to grey and pushed on the mark stack.

> btw...
> What support does Slang have for concurrent programming?

Nothing.  But in the VMMaker package, as Clément mentioned, there's a multi-process simulation of the support for the threaded FFI which is built upon some atomic instruction support the JIT makes available when it generates its run-time at startup. So we can use CAS to switch ownership of the VM between threads.

> cheers -ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20180427/36b6b301/attachment.html>