VM Maker: VMMaker-dtl.241.mcz

 
Dave Lewis uploaded a new version of VMMaker to project VM Maker:
http://www.squeaksource.com/VMMaker/VMMaker-dtl.241.mcz

==================== Summary ====================

Name: VMMaker-dtl.241
Author: dtl
Time: 27 June 2011, 10:18:20 am
UUID: d8cf8a28-cb6e-4827-8765-d072c7e384df
Ancestors: VMMaker-dtl.240

VMMaker 4.5.5
 
Integrate Igor's fix from http://code.google.com/p/cog/issues/detail?id=46.

This change is adapted from NewObjectMemory>>sufficientSpaceAfterGC: in VMMaker.oscog-eem.86 and is intended to address object memory expansion problems noted on Windows.

Background from <http://code.google.com/p/cog/issues/detail?id=46

Reported by project member siguctua, Today (4 hours ago)

Hello, remember the problem Tudor has on Win32.
I tracked it down to the #sufficientSpaceAfterGC: method.
It looks like it miscalculating the amount of required space , because the check

        self oop: freeStart + minFree + 15000 isLessThan: reserveStart

fails after growing the memory.

So, instead of failing (and consequently raising a low-space condition), i placed the loop in allocation procedure to query even more memory from platform side , until condition will be fulfilled or no extra memory available , and then we naturally fail.

I modified source files to trace memory allocation requests, and here what they producing.
Before change:

max available memory space: 1073741824 , reserved now: 422965248
allocated extra memory: 4198400 , total: 427163648
allocated extra memory: 4198400 , total: 431362048
allocated extra memory: 4198400 , total: 435560448
allocated extra memory: 4198400 , total: 439758848

After change:

max available memory space: 1073741824 , reserved now: 422965248
allocated extra memory: 4214784 , total: 427180032
allocated extra memory: 4214784 , total: 431394816
allocated extra memory: 4214784 , total: 435609600
allocated extra memory: 4214784 , total: 439824384
sqMemoryExtraBytesLeft returns: 633917440
allocated extra memory: 5914624 , total: 445739008

As you can see, the VM without fix fails at 4th memory allocation request,
but as it shown below, there are plenty of memory space available, and problem is not in insufficient space but in calculating the requested memory size >> and comparing with wrong desired space after allocating it.
The loop just heals this issue.