[Pharo-project] out of memory - cog on windows

Andres Valloud avalloud at smalltalk.comcastbiz.net
Fri Apr 22 21:48:19 CEST 2011


It's nice to see how to set up one's environment.  The specific compiler 
versions, as well as versions of the relevant SDKs, should be well 
documented so that anyone can reproduce an "official" build.

IMHO, it seems a bit weird that a command line switch was superceded 
with a #define.

On 4/22/11 8:17 , Alain_Rastoul wrote:
> Hi Andres,
>
> Of course you are right , in that particular case  it's just to help Tudor
> recovering an image.
> Having an argument -memory would be helpful for such cases, but I think it
> has been superseeded with a#define.
>
> You can build a vm very easily once you have your build environment set.
> This is described in
> http://book.pharo-project.org/book/Virtual-Machine/Building/BuildVMOnWindows/BuildCogVMOnWindows/
> and (didn't try it but seems very well done and perhaps more up to date -
> thanks Mariano!):
> http://marianopeck.wordpress.com/tag/build/
> See also the HowToBuild note in the vm sources.
> On Unix, the build tools are here you just need to download the vm sources
> (see the url in previous documents)
> and run make.
> For Mac, I don't have a Mac I don't know
>
> Regards,
> Alain
>
>
>
> "Andres Valloud"
> <avalloud at smalltalk.comcastbiz.net>  a écrit dans le
> message de news: 4DB0C591.3080903 at smalltalk.comcastbiz.net...
>> Yeah, not all operating systems and application environments are the same.
>> What happens when you let a 512mb image loose in an environment where you
>> have 10 images running on a 4gb machine?  Ouch.  What happens when you let
>> a 2gb image loose in a 1gb machine and you get an infinite recursion bug?
>> Ouch.
>>
>> But, at the same time, a 512mb limit can be useful precisely to prevent an
>> infinite recursion from killing your machine.  I hate to brag, but I have
>> been working on memory policies and memory management for quite a while on
>> VisualWorks, and the edge cases do matter a lot.  It's not so simple as to
>> "let's just increase the max memory to 4gb".
>>
>> Also, you can recompile your VMs with different settings and what not, but
>> how do you know they will work?  Is the compilation environment
>> standardized somewhere so that I can reproduce an "official" VM build if I
>> want?
>>
>> On 4/21/11 13:44 , Alain_Rastoul wrote:
>>> Apparently, the vm allocates MAX_VIRTUAL_MEMORY and reduces by steps of
>>> 128M until it
>>> succeeds.
>>> so I suppose it could be possible to allocate 2Gb and see how it runs on
>>> a 1Gb system and if this is not too much stress for
>>> the system (thinking of the pagefile) ?
>>> Tudor is your vm a cog or non cog vm ?
>>>
>>>      "Mariano Martinez Peck"
>>> <marianopeck at gmail.com
>>>      <mailto:marianopeck at gmail.com>>  a écrit
>>> dans le message de news:
>>>
>>> BANLkTi=Tved13_KL7quOzemOXPnCcfWw+g at mail.gmail.com
>>>
>>> <mailto:BANLkTi=Tved13_KL7quOzemOXPnCcfWw+g at mail.gmail.com>...
>>>
>>>      ------------------------------------------------------------------------
>>>
>>>
>>>
>>>      On Thu, Apr 21, 2011 at 10:21 PM, Tudor Girba
>>> <tudor.girba at gmail.com
>>>      <mailto:tudor.girba at gmail.com>>  wrote:
>>>
>>>          Hi,
>>>
>>>          Should I to understand that the only way to enable more memory
>>>          is to recompile the VM? Does that mean that there is no way to
>>>          pass this information as a parameter like we can on Mac?
>>>
>>>
>>>      As far as I know you can pass a parameter, but even so, it won't be
>>>      able to allocate more than 512MB.
>>>      I can compile the VM for you with this change in 5 minutes. But I am
>>>      not sure that such simple code would make it work. I think such
>>>      limit is there because of something. Otherwise, it sounds stupid
>>>      imposing a limit just because.
>>>
>>>          The problem is that I cannot recompile the VM because I have no
>>>          access to a Windows machine. Is there one available that
>>>          provides more memory?
>>>
>>>
>>>      I don't think so, but start cc'ing the VM mailing list. You'd
>>>      probably receive more help.
>>>
>>>      Cheers
>>>
>>>      Mariano
>>>
>>>          Cheers,
>>>          Doru
>>>
>>>
>>>          On 21 Apr 2011, at 22:09, Alain_Rastoul wrote:
>>>
>>>           >  Hi Tudor,
>>>           >
>>>           >  There is a constant in sqWin32Alloc.h (platforms\win32\vm) :
>>>           >  #define MAX_VIRTUAL_MEMORY 512*1024*1024
>>>           >  you can change it to whatever you want and rebuild the vm,
>>>           >  for exzmple give all the available memory less 256 M .
>>>           >
>>>           >  HTH
>>>           >
>>>           >  Regards
>>>           >  Alain
>>>           >
>>>           >  "Tudor Girba"
>>> <tudor.girba at gmail.com
>>>          <mailto:tudor.girba at gmail.com>>  a
>>> écrit
>>>           >  dans le message de news:
>>>
>>> 03B9389F-C719-44D0-B106-2AC78B120F56 at gmail.com...
>>>           >  Hi,
>>>           >
>>>           >  We have no specific startUp: methods in Moose. In any case,
>>>          the issue with
>>>           >  opening the image does not seem to be related to startUp:.
>>>           >
>>>           >  Is it really true that the Cog VM is limited to 512MB of
>>> memory?
>>>           >
>>>           >  Cheers,
>>>           >  Doru
>>>           >
>>>           >
>>>           >  On 21 Apr 2011, at 14:27, Luc Fabresse wrote:
>>>           >
>>>           >>  Hi Doru,
>>>           >>
>>>           >>  2011/4/21 Tudor Girba
>>>           >>  <tudor.girba at gmail.com
>>> <mailto:tudor.girba at gmail.com>>
>>>           >>  Hi,
>>>           >>
>>>           >>
>>>           >>
>>>           >>  On Apr 21, 2011, at 14:06, Mariano Martinez Peck
>>>           >>  <marianopeck at gmail.com
>>> <mailto:marianopeck at gmail.com>>  wrote:
>>>           >>
>>>           >>>
>>>           >>>
>>>           >>>  On Thu, Apr 21, 2011 at 1:58 PM, Tudor Girba
>>>           >>>  <tudor.girba at gmail.com
>>> <mailto:tudor.girba at gmail.com>>  wrote:
>>>           >>>>  Hi again,
>>>           >>>>
>>>           >>>>  I did not say what the problem was :). The problem was
>>>          that when
>>>           >>>>  opening the image on Windows, he got a Space is low
>>>          message and the
>>>           >>>>  image was not usable (see attachment).
>>>           >>>
>>>           >>>  That's weird. Does moose have something on the startup
>>>          list? something
>>>           >>>  that can be bothering there?
>>>           >>
>>>           >>  Not that I know of. Is there a way to check this?
>>>           >>
>>>           >>  Classes should be registered using Smalltlak
>>>          addToStartUpList: aClass
>>>           >>  Then aClass class>>#startUp: is executed at startup.
>>>           >>  So implementors of #startUp: on Moose classes should give
>>>          you the answer.
>>>           >>
>>>           >>  #Luc
>>>           >>
>>>           >>
>>>           >>  Actually, using exactly the same process some days ago he
>>>          produced an
>>>           >>  image of 190MB. This one works just fine on Windows. The
>>>          only difference
>>>           >>  between the two is the size of the loaded data.
>>>           >>
>>>           >>  It would be really bad news if the Windows vm would be so
>>>          severely limited
>>>           >>  in terms of memory.
>>>           >>
>>>           >>  Cheers,
>>>           >>  Doru
>>>           >>
>>>           >>
>>>           >>>
>>>           >>>  On Mac it worked just fine.
>>>           >>>>
>>>           >>>>  Cheers,
>>>           >>>>  Doru
>>>           >>>>
>>>           >>>>
>>>           >>>
>>>           >>>>
>>>           >>>>
>>>           >>>>
>>>           >>>>  On 21 Apr 2011, at 12:52, Tudor Girba wrote:
>>>           >>>>
>>>           >>>>>  Hi,
>>>           >>>>>
>>>           >>>>>  I received a question from someone running a 200MB image
>>>          on Windows
>>>           >>>>>  using Cog 2361.
>>>           >>>>>
>>>           >>>>>  If I open the image on Mac, it works just fine.
>>>          Unfortunately, I do
>>>           >>>>>  not have a Windows machine around, and I cannot test but
>>>          I believe it
>>>           >>>>>  should be solvable by increasing the allocated memory.
>>>           >>>>>
>>>           >>>>>  On Mac, I would run it with: ./Croquet -memory 1500m
>>>           >>>>>
>>>           >>>>>  Can anyone help me with the right incantation for Windows?
>>>           >>>>>
>>>           >>>>>  Cheers,
>>>           >>>>>  Doru
>>>           >>>>>
>>>           >>>>>
>>>           >>>>>  --
>>>           >>>>>  www.tudorgirba.com<http://www.tudorgirba.com>
>>>           >>>>>
>>>           >>>>>  "What we can governs what we wish."
>>>           >>>>>
>>>           >>>>>
>>>           >>>>>
>>>           >>>>>  <Space is low.png>
>>>           >>>>
>>>           >>>>  --
>>>           >>>>  www.tudorgirba.com<http://www.tudorgirba.com>
>>>           >>>>
>>>           >>>>  "Yesterday is a fact.
>>>           >>>>  Tomorrow is a possibility.
>>>           >>>>  Today is a challenge."
>>>           >>>>
>>>           >>>>
>>>           >>>>
>>>           >>>
>>>           >>>
>>>           >>>
>>>           >>>
>>>           >>>  --
>>>           >>>  Mariano
>>>           >>>  http://marianopeck.wordpress.com
>>>           >>>
>>>           >>
>>>           >
>>>           >  --
>>>           >  www.tudorgirba.com<http://www.tudorgirba.com>
>>>           >
>>>           >  "Beauty is where we see it."
>>>           >
>>>           >
>>>           >
>>>           >
>>>           >
>>>           >
>>>           >
>>>           >
>>>
>>>          --
>>>          www.tudorgirba.com<http://www.tudorgirba.com>
>>>
>>>          "If you interrupt the barber while he is cutting your hair,
>>>          you will end up with a messy haircut."
>>>
>>>
>>>
>>>
>>>
>>>      --
>>>      Mariano
>>>      http://marianopeck.wordpress.com
>>>
>>
>>
>
>
>
>
> .
>



More information about the Pharo-project mailing list