Re: [Pharo-project] out of memory - cog on windows
Locked
Re: [Pharo-project] out of memory - cog on windows
 
|
On Thu, Apr 21, 2011 at 10:21 PM, Tudor Girba <[hidden email]> wrote: Hi, 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, -- Mariano http://marianopeck.wordpress.com |
Re: [Pharo-project] out of memory - cog on windows
|
|
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 ?
|
Re: [Pharo-project] out of memory - cog on windows
|
|
On Thu, Apr 21, 2011 at 10:44 PM, Alain_Rastoul <[hidden email]> wrote:
Cog
-- Mariano http://marianopeck.wordpress.com |
Re: [Pharo-project] out of memory - cog on windows
|
|
In reply to this post by Alain rastoul
FWIW, the reason for the 512MB limit has to do with Windows memory layout. When you're running applications that load dynamic libraries (directly or indirectly such as when using ODBC which loads further DLLs) Windows needs (sometimes a lot of) address space to map these DLLs in order to load them[*]. When the VM starts it grabs MAX_VIRTUAL_MEMORY from the OS which will consequently not be available to map DLLs into. We have found that depending on the libraries in use and depending on the overall system utilization, loading DLLs would fail seemingly "at random" which, after further investigation, we were able to track to reserving too much address space upfront. We were able to show experimentally, that changing the limit from 1GB to 512MB would on some machines make all the difference. [*] This is true in particular for libraries that create more threads as the default Windows policy is to create threads with the stack size of the application executable. Thus a 1MB default stack in the application will by default create all further threads to be allocated with a 1MB stack size. Of course all of this is subject to various other conditions. In the end we concluded that 512MB is a reasonable size for most apps and with 512MB we've never seen these random failures. You can increase the limit by recompiling the VM, but if you ship your app in diverse environments you should be aware of the potential issues. Cheers, - Andreas On 4/21/2011 22:44, Alain_Rastoul wrote:
|
Re: [Pharo-project] out of memory - cog on windows
|
|
On Fri, Apr 22, 2011 at 3:01 PM, Andreas Raab <[hidden email]> wrote:
Thanks Andreas for the explanation. And instead of having to recompile the VM, we cannot set that from the image side? or pass as an argument in the vm execution ? something like the -memory ? thanks Mariano
-- Mariano http://marianopeck.wordpress.com |
Re: Re: [Pharo-project] out of memory - cog on windows
|
|
In reply to this post by Andreas.Raab
Thank you Andreas.
That's really worth knowing, and as Andres
Valloud already mentionned (in the cross-posted paro-devel thread) memory
policies are not that simple.
As Mariano suggests it should be easy to
"reactivate" the old -memory: parameter to override the default value without
recompiling (if I'm correct the code for parsing arguments is still here), just
to address cases where memory seems to be a problem - my 2c
Regards,
Alain
|
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |