[Vm-dev] Re: [Pharo-project] out of memory - cog on windows

[Igor Stasenko]

On 10 May 2011 09:34, Tudor Girba <tudor.girba at gmail.com> wrote:
> Hi,
>
> I am back with some more input on the matter. We played with it, and found that basically any image that goes beyond something like 200MB limit (or maybe it's the number of objects), will not open on Windows.
>
> I would need some help on this. Has nobody else hit this wall, or is it that I am doing something wrong?
>
> One scenario that we used to reproduce the problem looks like this:
> 1. Take a Moose image:
> http://hudson.moosetechnology.org/job/moose-latest-dev/lastSuccessfulBuild/artifact/moose/*zip*/moose.zip
> 2. Run:
> 1 to: 3 do: [ :i | MooseScripts createModelForConfigurationOfMoose ]
> This will basically create some 850000 objects and will get the image to some 400+MB
> 3. Save and quit the image
> 4. Reopen it
>
> A ready-made image with the result of this can be found here:
> http://dl.dropbox.com/u/18323746/Tmp/moose-case-study-windows-problem.zip
>
> This works well on Mac, but on Windows when you reopen the image, you get the out of memory message.
>
> Cheers,
> Doru
>
>

I using latest VMs built by cmake on windows, and everytime i run this image,
it opens a 'Space is low' dialog and then image not reacting on anything.
VM not crashing however and responds to windows events.. But because
UI process is broken
an image simply not reacts to anything.


I think that the problem is that this dialog are shown at early image
startup time,
before everything is properly initialized, and because of that UI
stalls somewhere.


Next things which i tried is to increase a virtual memory limit in
sqWin32Alloc.h

#ifndef MAX_VIRTUAL_MEMORY
#define MAX_VIRTUAL_MEMORY 512*1024*1024
#endif

first i raised it to 768 Mbytes.. same behavior.
then i raised it to 1Gb and again same behavior..

So, either this constant is overridden somewhere or it actually
doesn't affecting the low-space detection mechanism as i would expect.
Any suggestions?


I will continue looking , what happens on VM side,
but in addition to that, i think we should do something on image side as well:
 - a low space watcher should not pop up before passing image startup,
because if preempted process is UI process (and in 99.99% cases it is),
then it means that low space watcher blocks UI process and as a consequence,
your image stops handling events.


Also, i thinking about different approach for signaling a low space condition.
Instead of signaling a low space semaphore, what VM could do is to
fail an allocation primitive
and set the error code to "low memory warning"
then a primitive failure code could actually throw an exception, which
then could be handled as usual...
so you could write a code, like:

[ self allocateSomethingReallyHuge ] on: LowMemoryWarning do: [:err |
  self shouldWeReallyCare ifFalse: [ self tellVMThatItsOk. err resume ]
  ifTrue: [ err pass ]
]

Because by preempting a currently active process, which "possibly"
causing a memory problems is not a solution,
as you can see, if it happens during startup phase, then you it just
stucks and image hangs.
But if we could use exceptions, we could just ignore this warning (or
do something else) during image startup,
instead of blocking UI process , showing a useless popup message and
letting image hang like that.

-- 
Best regards,
Igor Stasenko AKA sig.