Hi Igor, Thanks a lot for looking into this. For us (around Moose), this is a critical issue because we play with our models in memory and regularly have images of several hundred megabytes. While most of us work on Mac without a problem, some other people work on Windows and this is a bottleneck.
Unfortunately, I do not have enough know-how to dive into the VM, but I would be gladly help in any way I can. Cheers, Doru On 16 May 2011, at 10:50, Igor Stasenko wrote: > On 10 May 2011 09:34, Tudor Girba <[email protected]> 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. -- www.tudorgirba.com "If you interrupt the barber while he is cutting your hair, you will end up with a messy haircut."
