Wow! I will certainly try this patch.

Doru


On Fri, Jul 18, 2014 at 5:15 PM, Oscar E. A. Callaú <[email protected]>
wrote:

> Well,
>
>   I fixed the problem by modifying the Pharo.exe file with the 4GB patch
> program (http://ntcore.com/4gb_patch.php).
>
> As mentioned before, I think the best solution is that Pharo vms must be
> compiled with the flag LARGEADDRESSAWARE, so more memory space is
> enabled for 64bits Windows OSs.
>
> Thanks guys
>
> Oscar
>
>
>
> On Thu, Jul 17, 2014 at 11:03 PM, Andres Valloud <
> [email protected]> wrote:
>
>> 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, <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>>     __
>>>     Eliot Miranda wrote:
>>>
>>>>
>>>>
>>>>
>>>>     On Wed, Jul 16, 2014 at 2:21 PM, Oscar E. A. Callaú
>>>>     <[email protected] <mailto:[email protected]>> 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ú
>>>>             <[email protected]> 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
>>>>
>>>
>>>
>>>
>>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Reply via email to