Hi, On 18 May 2011, at 16:30, Levente Uzonyi wrote:
> On Wed, 18 May 2011, Tudor Girba wrote: > >> >> Hi, >> >> Is there a possibility to have any sort of answer on this topic? >> >> It looks to me like this bug is critical given that it prevents us to work >> with images larger than some 200M. > > IMHO it's a problem on the image side. Change the behavior of > #lowSpaceWatcher to fix the problem. How would you do it? :) And if it is an image problem, why does it only appear on Windows? Cheers, Doru > > Levente > >> >> Cheers, >> Tudor >> >> >> >> On 16 May 2011, at 11:06, Tudor Girba wrote: >> >>> 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 <tudor.gi...@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. >>> >>> -- >>> www.tudorgirba.com >>> >>> "If you interrupt the barber while he is cutting your hair, >>> you will end up with a messy haircut." >>> >> >> -- >> www.tudorgirba.com >> >> "Obvious things are difficult to teach." >> >> >> >> -- www.tudorgirba.com "Next time you see your life passing by, say 'hi' and get to know her."
