[Vm-dev] Re: Too many full GCs in Cog/Spur ... while just drawing GUI ...

[Bert Freudenberg]

On 08.04.2016, at 00:34, Levente Uzonyi <leves at caesar.elte.hu> wrote:
> 
> When the VM runs out of memory primitive 71 in #basicNew: will fail and it'll send
> #handleFailingBasicNew:. That method will retry primitive 71, which will fail again, and then it'll do a full gc to make room for the new object.

I couldn’t believe regular GC would go through primitive failure code and rely on the image to invoke a full GC.

And in fact, it doesn’t. I put a "BasicNewFailures := BasicNewFailures + 1.” in basicNew(:) and it never increased. So I think this is invoked only in severe conditions.

> Only when it's not possible to make room for the new object by collecting the garbage will the VM allocate more memory.

I see that code in Behavior (calling growMemoryByAtLeast:), yes, but in my tests it never got invoked.

> Forcing the VM to allocate more memory, by tweaking parameter 25, will decrease the number of GCs, though I wasn't able to get it down to 0, because the code became way too snappy and it quickly reached the new memory limit.

Yes, the number of full GCs goes down. But why not to zero? I cannot understand why we cannot find a large-enough “new space size” so that the working set is fully kept in there. Redrawing a couple windows should not produce any long-lived objects that trigger a full GC every second.

- Bert -



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4207 bytes
Desc: not available
Url : http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160408/388811ae/smime.bin