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

[Bert Freudenberg]

On 08.04.2016, at 18:29, Levente Uzonyi <leves at caesar.elte.hu> wrote:
> 
> On Fri, 8 Apr 2016, Bert Freudenberg wrote:
>> 
>> 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.
> 
> It does. [...] Make sure you have only a few windows open, otherwise drawing will take way too long and there won't be enough allocations to trigger the failure.

You’re right, it does get triggered with just one window.

>> > 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.
>> 
> 
> If you replace #bench with #benchFor: 1 seconds, then the number of full GCs will stay zero (using the #garbageCollectMost change I suggested above).


Well we should be able to run for 5 seconds ;)

But it’s even worse: After loading Kernel-ul.1014 and running your snippet, I get an OutOfMemory error immediately. So we are somehow pushing the VM to its limit.

If I open more windows, it works, but I verified that there were no more basicNew failures. It apparently has to do with big allocations. E.g. this triggers OOM with your change :

	10 timesRepeat: [Bitmap new: 10000000]

... but works fine (albeit slowly) without.

- 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/74fedadd/smime-0001.bin