I worked on that switch before, and IIRC it's just a linker switch that
marks executables a certain way. So, if you have imagecfg.exe handy...
http://support.microsoft.com/kb/297812
On 7/17/14 19:25 , Oscar E. A. Callaú wrote:
Well. It seems that Pharo vms must be compiled with that option :/
Cheers
On Wed, Jul 16, 2014 at 8:44 PM, <b...@openinworld.com
<mailto:b...@openinworld.com>> wrote:
__
Eliot Miranda wrote:
On Wed, Jul 16, 2014 at 2:21 PM, Oscar E. A. Callaú
<oscar.apo...@gmail.com <mailto:oscar.apo...@gmail.com>> wrote:
Hi,
I'm using Windows 8.1 (update1) 64bits with 4GB of physical
RAM. I only need 1.5GB of RAM, so I think I don't need to
configure my OS to take /3GB of RAM.
Well my experience (and others) is that one can't grow the heap
much above 1.1 Gb without using the /3Gb switch on Windows XP. I
can't talk for 8.1. But if 8.x also limits memory to 2Gb/process
unless the /3Gb switch is in effect then yes, you'll need to use
the /3Gb switch.
HTH
Eliot
Cheers
On Wednesday, July 16, 2014, Eliot Miranda wrote:
Hi Oscar,
On Wed, Jul 16, 2014 at 9:11 AM, Oscar E. A. Callaú
<oscar.apo...@gmail.com> wrote:
Hi guys,
I'm running some experiments in Pharo. My data
is aprox. 1.3GB. When I load my image on Mac,
everything works perfectly. But, when I try to load
the same image on Windows, I get this error:
Unable to commit memory (1326649344 bytes requested)
I tried the Pharo VM, cogMT and NBcog with and
without the option
AddressSpaceLimit = 2048
in the ini file
Please help.
What OS are you using? Have you read e.g.
http://msdn.microsoft.com/en-us/library/windows/hardware/dn613959(v=vs.85).aspx
<http://msdn.microsoft.com/en-us/library/windows/hardware/dn613959%28v=vs.85%29.aspx>?
Here are some additional links...
/LARGEADDRESSAWARE (Handle Large Addresses)
http://msdn.microsoft.com/en-us/library/wz223b1z.aspx
Memory Limits for Windows and Windows Server Releases
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778(v=vs.85).aspx
I learnt something new reading this article. For Win 8.1 64-bit, the
/3GB switch is not applicable or required. However the
/LARGEADDRESSAWARE linker option is critical for both 32-bit and
64-bit VMs. Its only the default setting that changes between
compiling 32-bit or 64-bit applications. Some extracts...
Limits on memory and address space depend on whether the
IMAGE_FILE_LARGE_ADDRESS_AWARE value of the LOADED_IMAGE structure
and 4-gigabyte tuning (4GT) are in use.
IMAGE_FILE_LARGE_ADDRESS_AWARE is set or cleared by using the
/LARGEADDRESSAWARE linker option. 4-gigabyte tuning (4GT), also
known as application memory tuning, or the /3GB switch, is a
technology (**only applicable to 32 bit systems**) that alters the
amount of virtual address space available to user mode applications.
On x64-bit MS Windows, User-Mode virtual address space for each
32-bit process
4 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE set
2 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE cleared (default)
On x64-bit MS Windows, User-Mode virtual address space for each
64-bit process
8 TB With IMAGE_FILE_LARGE_ADDRESS_AWARE set (default):
2 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE cleared
cheers -ben
--
best,
Eliot
--
best,
Eliot
