Available Memory to 32-Bit Applications

[Guest Mike Sharpe]

We are running Windows XP64 and we are using 4 CPU machines that have 8GB

total. We have a program that was written in 32-Bit code that runs on these

computers. It does some complex mathematics and data crunching. Since we

have 4 CPUs on this computer, we create 4 separate processes. Our assumption

was that each process can have 2 GB worth of addressable space. Since the

code is written in 32-Bit, do these 4 CPUs each share the same 4GB of lower

memory?

 

What we are seeing is that our code is running out of memory when the total

system memory usage is around 1.8GB. This leads me to believe that the

64-Bit version of Windows cannot remap memory in the 4GB+ range and make that

exposed to these processes.

 

What I believe is happening is that:

CPU 1 -> CPU 4 all share the same lower 4GB of memory

Instead of

CPU 1 -> gets to use 2GB (say 0GB -> 2GB)

CPU 2 -> gets to use 2GB (say 2GB -> 4GB)

CPU 3 -> gets to use 2GB (say 4GB -> 6GB)

CPU 4 -> gets to use 2GB (say 6GB -> 8GB)

 

Can someone definitively answer how multiple 32-Bit processes use memory in

the 64-Bit OS? What I am seeing sort of goes against everything that people

have been telling me.

[Guest Bobby Johnson]

Re: Available Memory to 32-Bit Applications

 

The 32-bit system environment is the limiting factor, it can only deal

with a maximum of 4GB while the actual limit is usually in the 3.2GB -

3.5GB range.

 

See the info on _*Large Memory Support*_ at:

http://msdn.microsoft.com/en-us/library/aa366718(VS.85).aspx

 

 

Mike Sharpe wrote:

> We are running Windows XP64 and we are using 4 CPU machines that have 8GB

> total. We have a program that was written in 32-Bit code that runs on these

> computers. It does some complex mathematics and data crunching. Since we

> have 4 CPUs on this computer, we create 4 separate processes. Our assumption

> was that each process can have 2 GB worth of addressable space. Since the

> code is written in 32-Bit, do these 4 CPUs each share the same 4GB of lower

> memory?

>

> What we are seeing is that our code is running out of memory when the total

> system memory usage is around 1.8GB. This leads me to believe that the

> 64-Bit version of Windows cannot remap memory in the 4GB+ range and make that

> exposed to these processes.

>

> What I believe is happening is that:

> CPU 1 -> CPU 4 all share the same lower 4GB of memory

> Instead of

> CPU 1 -> gets to use 2GB (say 0GB -> 2GB)

> CPU 2 -> gets to use 2GB (say 2GB -> 4GB)

> CPU 3 -> gets to use 2GB (say 4GB -> 6GB)

> CPU 4 -> gets to use 2GB (say 6GB -> 8GB)

>

> Can someone definitively answer how multiple 32-Bit processes use memory in

> the 64-Bit OS? What I am seeing sort of goes against everything that people

> have been telling me.

>

[Guest Mike Sharpe]

Re: Available Memory to 32-Bit Applications

 

Thank you for the reply but that seems to only make sense on a 32-Bit OS. I

am running a 64-Bit OS so I would expect that the OS should handle where the

2GB of RAM comes from and remap it to the 32-Bit process. For example:

 

32-Bit Process A requests 8 bytes of memory from the 64 Bit OS. The 64-Bit

OS gets that memory from lets say the 6GB block in its own memory space. It

should then provide this to 32-Bit process in a way that the 32-Bit process

thinks it is coming from a 32-Bit space.

 

I would think that the 64-bit OS would handle memory in this fashion.

Otherwise, moving to 64-Bit doesn't gain you anything if you want to run

multiple 32-Bit process. I could have 16GB of RAM and it wouldn't make a

difference. Let's say I have a dual quad core machine for a total of 8

CPUs/Cores. Are you suggesting that all 8 of these will use the exact same

32-Bit address space? So ~3GB will be used and the remaining 13GB would not

be used by these?

[Guest Doug Forster]

Re: Available Memory to 32-Bit Applications

 

Hi Mike,

 

You are quite correct, each app has its own virtual memory space and the OS

will duly map this to real RAM or page file as necessary. In fact the amount

of physical RAM is totally irrelevent - you are most likely running out of

virtual memory (assuming its not something obvious like disk space for the

page file). However it is not sufficient just to tot up the amount of memory

(virtual) you are using. The most likely barrier you are running into is

virtual memory fragmentation whereby the memory allocator cannot find

sufficient *contiguous* memory. This type of issue needs to be dealt with at

a programming level and you are not clear whether you have control over

this? If you do then a programming group might be a more appropriate place

to continue the discussion, but commonly memory fragmentation can be caused

by using auto expanding data structures that are repeatedly resized.

 

Cheers

Doug Forster

 

"Mike Sharpe" <MikeSharpe@discussions.microsoft.com> wrote in message

news:07654363-8AF1-43FB-ABB3-F9AC565544D6@microsoft.com...

> Thank you for the reply but that seems to only make sense on a 32-Bit OS.

> I

> am running a 64-Bit OS so I would expect that the OS should handle where

> the

> 2GB of RAM comes from and remap it to the 32-Bit process. For example:

>

> 32-Bit Process A requests 8 bytes of memory from the 64 Bit OS. The

> 64-Bit

> OS gets that memory from lets say the 6GB block in its own memory space.

> It

> should then provide this to 32-Bit process in a way that the 32-Bit

> process

> thinks it is coming from a 32-Bit space.

>

> I would think that the 64-bit OS would handle memory in this fashion.

> Otherwise, moving to 64-Bit doesn't gain you anything if you want to run

> multiple 32-Bit process. I could have 16GB of RAM and it wouldn't make a

> difference. Let's say I have a dual quad core machine for a total of 8

> CPUs/Cores. Are you suggesting that all 8 of these will use the exact

> same

> 32-Bit address space? So ~3GB will be used and the remaining 13GB would

> not

> be used by these?

[Guest Bobby Johnson]

Re: Available Memory to 32-Bit Applications

 

But, the 32-bit processes are running in a 32-bit environment within the

64-bit OS - the 32-bit environment is in its own little 32-bit world,

not in the OS's 64-bit world.

 

See info on _*WOW64 Implementation Details*_ at:

http://msdn.microsoft.com/en-us/library/aa384274.aspx

 

Your 32-bit processes are running in *WOW64* which is the x86 emulator

that allows 32-bit Windows-based applications to run seamlessly on

64-bit Windows.

 

Se info at: http://msdn.microsoft.com/en-us/library/aa384249(VS.85).aspx

 

 

Mike Sharpe wrote:

> Thank you for the reply but that seems to only make sense on a 32-Bit OS. I

> am running a 64-Bit OS so I would expect that the OS should handle where the

> 2GB of RAM comes from and remap it to the 32-Bit process. For example:

>

> 32-Bit Process A requests 8 bytes of memory from the 64 Bit OS. The 64-Bit

> OS gets that memory from lets say the 6GB block in its own memory space. It

> should then provide this to 32-Bit process in a way that the 32-Bit process

> thinks it is coming from a 32-Bit space.

>

> I would think that the 64-bit OS would handle memory in this fashion.

> Otherwise, moving to 64-Bit doesn't gain you anything if you want to run

> multiple 32-Bit process. I could have 16GB of RAM and it wouldn't make a

> difference. Let's say I have a dual quad core machine for a total of 8

> CPUs/Cores. Are you suggesting that all 8 of these will use the exact same

> 32-Bit address space? So ~3GB will be used and the remaining 13GB would not

> be used by these?

>

[Guest Doug Forster]

Re: Available Memory to 32-Bit Applications

 

Just noticed your original post said you are running out at 1.8GB. This is

actually about par for the course for a 32 bit app that does not have the

LARGEADDRESSAWARE flag set. If you want the full 4GB to be available then

you can set this flag with the EditBin utility (or your dev tool if you are

in control of this) in which case you would run out of virtual memory

somwhere between 3 and 4 GB

[Guest Bobby Johnson]

Re: Available Memory to 32-Bit Applications

 

http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx has

more information about _*Memory Support and Windows Operating Systems*_

 

Mike Sharpe wrote:

> Thank you for the reply but that seems to only make sense on a 32-Bit OS. I

> am running a 64-Bit OS so I would expect that the OS should handle where the

> 2GB of RAM comes from and remap it to the 32-Bit process. For example:

>

> 32-Bit Process A requests 8 bytes of memory from the 64 Bit OS. The 64-Bit

> OS gets that memory from lets say the 6GB block in its own memory space. It

> should then provide this to 32-Bit process in a way that the 32-Bit process

> thinks it is coming from a 32-Bit space.

>

> I would think that the 64-bit OS would handle memory in this fashion.

> Otherwise, moving to 64-Bit doesn't gain you anything if you want to run

> multiple 32-Bit process. I could have 16GB of RAM and it wouldn't make a

> difference. Let's say I have a dual quad core machine for a total of 8

> CPUs/Cores. Are you suggesting that all 8 of these will use the exact same

> 32-Bit address space? So ~3GB will be used and the remaining 13GB would not

> be used by these?

>

[Guest Mike Sharpe]

Re: Available Memory to 32-Bit Applications

 

The documents were helpful but did not answer my question. I understand

64-Bit addresses. I understand 32-Bit addresses. What I am not

understanding is whether or not the 64-Bit Windows Virtual Memory Manager can

provide unique blocks of 2GB (or 3GB with the switch) for each 32-bit

process or if they all share the same. I have an 8 core computer with 16GB

of RAM running 64-Bit OS. I have 8 32-Bit processes running. My page file

is setup for 10GB which should leave me with a total of approximately 26GB of

Virtual Memory.

 

I start up an application 8 times. Each one runs in its own process and

assigned to its own CPU. This application is 32-Bit and let's say each one

uses about 1GB of RAM. What I am seeing is that when the Physical Memory of

the box (not per process, the whole box) reaches about 1.8GB, my processes

start experiencing problems and I get Out of Memory errors. If I do some

quick math, 8 CPU x 1GB = 8GB of memory total. Since my system has 16GB

total, I should be consuming only about half. And each 32-Bit process is

under the 2 GB limit.

 

What I suspect is happening is that each process is sharing the SAME 32-Bit

space instead of being granted their own space in the Virtual memory and the

64-Bit memory manager controlling where each process recognizes its space.

Even if some data is in the 64-Bit range for a single process, it should be

able to map that down to the process specific 32-Bit range.

[Guest Bobby Johnson]

Re: Available Memory to 32-Bit Applications

 

Each 32-bit program has it own block of memory which will be shared by

the processes running within that program just as if it were actually

running that program on a Windows XP Pro (32-bit) system. I thought

that was pointed out in the info on WOW64.

 

 

Mike Sharpe wrote:

> The documents were helpful but did not answer my question. I understand

> 64-Bit addresses. I understand 32-Bit addresses. What I am not

> understanding is whether or not the 64-Bit Windows Virtual Memory Manager can

> provide unique blocks of 2GB (or 3GB with the switch) for each 32-bit

> process or if they all share the same. I have an 8 core computer with 16GB

> of RAM running 64-Bit OS. I have 8 32-Bit processes running. My page file

> is setup for 10GB which should leave me with a total of approximately 26GB of

> Virtual Memory.

>

> I start up an application 8 times. Each one runs in its own process and

> assigned to its own CPU. This application is 32-Bit and let's say each one

> uses about 1GB of RAM. What I am seeing is that when the Physical Memory of

> the box (not per process, the whole box) reaches about 1.8GB, my processes

> start experiencing problems and I get Out of Memory errors. If I do some

> quick math, 8 CPU x 1GB = 8GB of memory total. Since my system has 16GB

> total, I should be consuming only about half. And each 32-Bit process is

> under the 2 GB limit.

>

> What I suspect is happening is that each process is sharing the SAME 32-Bit

> space instead of being granted their own space in the Virtual memory and the

> 64-Bit memory manager controlling where each process recognizes its space.

> Even if some data is in the 64-Bit range for a single process, it should be

> able to map that down to the process specific 32-Bit range.

>

>

>

[Guest Chuck Walbourn [MSFT]]

Re: Available Memory to 32-Bit Applications

 

A 32-bit process can only adddress up to 2 GB of virtual address space. A

32-bit Large Address Aware process can get up to 4 GB of virtual address

space when run on Windows x64.

 

Each process has it's own unique address space. Every THREAD in that process

shares the same virtual address space.

 

Physical memory is managed by the operating system and will be mapped to

each process on demand. The mapping is completely up to the OS and is

dynamic, so there's no hard and firm rule here. If you are runnning a x64 OS

with 8 GB of physical RAM available, then the system will allocate it based

on the runtime demand. Multiple 32-bit processes running at the same time

can utilize more than 2 GB of physical memory.

 

To determine what is really happening you should look at your runtime

environment and determine how much viritual address space is allocated by

each process, and how large each working set is at runtime.

 

--

-Chuck Walbourn

SDE, XNA Developer Connection

 

This posting is provided "AS IS" with no warrenties, and confers no rights.

[Guest Doug Forster]

Re: Available Memory to 32-Bit Applications

 

And just one last thought: Are you sure your apps are actually completely

independent. I have come across bugs in such a situation where apps were

inadvertently sharing temporary files and crashing as a consequence of

processing unexpected data.

 

Cheers

Doug Forster

 

"Mike Sharpe" <MikeSharpe@discussions.microsoft.com> wrote in message

news:1E61C353-56A5-435F-841A-59B702CC5434@microsoft.com...

> The documents were helpful but did not answer my question. I understand

> 64-Bit addresses. I understand 32-Bit addresses. What I am not

> understanding is whether or not the 64-Bit Windows Virtual Memory Manager

> can

> provide unique blocks of 2GB (or 3GB with the switch) for each 32-bit

> process or if they all share the same. I have an 8 core computer with

> 16GB

> of RAM running 64-Bit OS. I have 8 32-Bit processes running. My page

> file

> is setup for 10GB which should leave me with a total of approximately 26GB

> of

> Virtual Memory.

>

> I start up an application 8 times. Each one runs in its own process and

> assigned to its own CPU. This application is 32-Bit and let's say each

> one

> uses about 1GB of RAM. What I am seeing is that when the Physical Memory

> of

> the box (not per process, the whole box) reaches about 1.8GB, my processes

> start experiencing problems and I get Out of Memory errors. If I do some

> quick math, 8 CPU x 1GB = 8GB of memory total. Since my system has 16GB

> total, I should be consuming only about half. And each 32-Bit process is

> under the 2 GB limit.

>

> What I suspect is happening is that each process is sharing the SAME

> 32-Bit

> space instead of being granted their own space in the Virtual memory and

> the

> 64-Bit memory manager controlling where each process recognizes its space.

> Even if some data is in the 64-Bit range for a single process, it should

> be

> able to map that down to the process specific 32-Bit range.

>

>

[Guest Mark H]

Re: Available Memory to 32-Bit Applications

 

An architectural limit has been reached. Some commonly reported

architectural limits in Windows include:

 

1. 2 GB of shared virtual address space for the system

2. 2 GB of private virtual address space per process

3. 660 MB System PTE storage

4. 470 MB paged pool storage

5. 256 MB nonpaged pool storage

6. 1 GB System cache

7. 16,000 GB pagefile size

 

Your current set of applications are using 18GB of virtual address space. (8

application processes, 1 OS)

So answering you're original question, Yes. Each process has it's own 2GB of

virtual memory.

 

But, here's the rub:

Your're running 32-bit applications in a 64-bit OS. For this to occur, the

32-bit application must be converted, on-the-fly, to a 64-bit application.

It now uses twice as much memory to do the same thing while being limited to

the 32-bit rules. The executable stays the same size (only converted as

used), but the data produced is retained in 64-bit. Example: Your routine is

1KB, but it calculates Pi to 1GB places. To store the number, you need 2GB

for this emulated x64 application. Since these are data intensive

applications, you may be running out of memory, not addresses. Run less

processes, or set the page file bigger.

 

You have 16 GB of RAM, paging will occur as you are currently setup

significantly reducing the performance of your applications. But, more

importantly, the Paged Pool Entry Table is trying to handle a huge amount of

information. You may be running out of Shared Virtual Memory (the OS) which

is reported as Out of Memory, and not Private Virtual Memory for your

processes. Because you hit the limit at 1.8GB, I suspect your problem is

Shared Virtual Memory (the OS) running out of memory as it sets up tables

for paging all the data produced.

 

A kernel debugger is needed to find out which limit you are violating.

 

"Bobby Johnson" <rjohnson@aol.NOSPAM.com> wrote in message

news:OMXFqSVNJHA.5232@TK2MSFTNGP05.phx.gbl...

> Each 32-bit program has it own block of memory which will be shared by

> the processes running within that program just as if it were actually

> running that program on a Windows XP Pro (32-bit) system. I thought

> that was pointed out in the info on WOW64.

>

>

> Mike Sharpe wrote:

> > The documents were helpful but did not answer my question. I understand

> > 64-Bit addresses. I understand 32-Bit addresses. What I am not

> > understanding is whether or not the 64-Bit Windows Virtual Memory

Manager can

> > provide unique blocks of 2GB (or 3GB with the switch) for each 32-bit

> > process or if they all share the same. I have an 8 core computer with

16GB

> > of RAM running 64-Bit OS. I have 8 32-Bit processes running. My page

file

> > is setup for 10GB which should leave me with a total of approximately

26GB of

> > Virtual Memory.

> >

> > I start up an application 8 times. Each one runs in its own process and

> > assigned to its own CPU. This application is 32-Bit and let's say each

one

> > uses about 1GB of RAM. What I am seeing is that when the Physical

Memory of

> > the box (not per process, the whole box) reaches about 1.8GB, my

processes

> > start experiencing problems and I get Out of Memory errors. If I do

some

> > quick math, 8 CPU x 1GB = 8GB of memory total. Since my system has 16GB

> > total, I should be consuming only about half. And each 32-Bit process

is

> > under the 2 GB limit.

> >

> > What I suspect is happening is that each process is sharing the SAME

32-Bit

> > space instead of being granted their own space in the Virtual memory and

the

> > 64-Bit memory manager controlling where each process recognizes its

space.

> > Even if some data is in the 64-Bit range for a single process, it should

be

> > able to map that down to the process specific 32-Bit range.

> >

> >

> >

[Guest Bobby Johnson]

Re: Available Memory to 32-Bit Applications

 

I don't know where you obtained your information, but it is seriously

flawed. 32-bit application are NOT converted "on-the fly" in Windows

x64! The are run in a virtual 32-bit environment space under WOW64.

You need to do some more research before you make such erroneous

statements! And each APPLICATION gets 2GB for ALL its processes to share!

 

 

Mark H wrote:

> An architectural limit has been reached. Some commonly reported

> architectural limits in Windows include:

>

> 1. 2 GB of shared virtual address space for the system

> 2. 2 GB of private virtual address space per process

> 3. 660 MB System PTE storage

> 4. 470 MB paged pool storage

> 5. 256 MB nonpaged pool storage

> 6. 1 GB System cache

> 7. 16,000 GB pagefile size

>

> Your current set of applications are using 18GB of virtual address space. (8

> application processes, 1 OS)

> So answering you're original question, Yes. Each process has it's own 2GB of

> virtual memory.

>

> But, here's the rub:

> Your're running 32-bit applications in a 64-bit OS. For this to occur, the

> 32-bit application must be converted, on-the-fly, to a 64-bit application.

> It now uses twice as much memory to do the same thing while being limited to

> the 32-bit rules. The executable stays the same size (only converted as

> used), but the data produced is retained in 64-bit. Example: Your routine is

> 1KB, but it calculates Pi to 1GB places. To store the number, you need 2GB

> for this emulated x64 application. Since these are data intensive

> applications, you may be running out of memory, not addresses. Run less

> processes, or set the page file bigger.

>

> You have 16 GB of RAM, paging will occur as you are currently setup

> significantly reducing the performance of your applications. But, more

> importantly, the Paged Pool Entry Table is trying to handle a huge amount of

> information. You may be running out of Shared Virtual Memory (the OS) which

> is reported as Out of Memory, and not Private Virtual Memory for your

> processes. Because you hit the limit at 1.8GB, I suspect your problem is

> Shared Virtual Memory (the OS) running out of memory as it sets up tables

> for paging all the data produced.

>

> A kernel debugger is needed to find out which limit you are violating.

>

> "Bobby Johnson" <rjohnson@aol.NOSPAM.com> wrote in message

> news:OMXFqSVNJHA.5232@TK2MSFTNGP05.phx.gbl...

>

>> Each 32-bit program has it own block of memory which will be shared by

>> the processes running within that program just as if it were actually

>> running that program on a Windows XP Pro (32-bit) system. I thought

>> that was pointed out in the info on WOW64.

>>

>>

>> Mike Sharpe wrote:

>>

>>> The documents were helpful but did not answer my question. I understand

>>> 64-Bit addresses. I understand 32-Bit addresses. What I am not

>>> understanding is whether or not the 64-Bit Windows Virtual Memory

>>>

> Manager can

>

>>> provide unique blocks of 2GB (or 3GB with the switch) for each 32-bit

>>> process or if they all share the same. I have an 8 core computer with

>>>

> 16GB

>

>>> of RAM running 64-Bit OS. I have 8 32-Bit processes running. My page

>>>

> file

>

>>> is setup for 10GB which should leave me with a total of approximately

>>>

> 26GB of

>

>>> Virtual Memory.

>>>

>>> I start up an application 8 times. Each one runs in its own process and

>>> assigned to its own CPU. This application is 32-Bit and let's say each

>>>

> one

>

>>> uses about 1GB of RAM. What I am seeing is that when the Physical

>>>

> Memory of

>

>>> the box (not per process, the whole box) reaches about 1.8GB, my

>>>

> processes

>

>>> start experiencing problems and I get Out of Memory errors. If I do

>>>

> some

>

>>> quick math, 8 CPU x 1GB = 8GB of memory total. Since my system has 16GB

>>> total, I should be consuming only about half. And each 32-Bit process

>>>

> is

>

>>> under the 2 GB limit.

>>>

>>> What I suspect is happening is that each process is sharing the SAME

>>>

> 32-Bit

>

>>> space instead of being granted their own space in the Virtual memory and

>>>

> the

>

>>> 64-Bit memory manager controlling where each process recognizes its

>>>

> space.

>

>>> Even if some data is in the 64-Bit range for a single process, it should

>>>

> be

>

>>> able to map that down to the process specific 32-Bit range.

>>>

>>>

>>>

>>>

>

>

>

[Guest Mark H]

Re: Available Memory to 32-Bit Applications

 

Thank you for the correction on the use of the word application where I

stated process. Reading the below, you may understand while I crossed my

words. But, "converting" on the fly is the process for x86 on x64.

 

 

Regarding WOW64: (from MS)

http://msdn.microsoft.com/en-us/library/aa384249(VS.85).aspx

(in case you want to read up on WOW64)

"Many 32-bit applications will not be updated for Windows Vista x64 Edition;

however, most 32-bit software will still function because of a Microsoft

emulation layer. This emulation layer, known as Windows on Windows 64 or

WoW64, enables 32-bit programs to run as though on a 32-bit version of

Windows by translating instructions passing in and out of 32-bit

applications into 64-bit instructions. Emulated programs act as though they

are running on an x86 computer and operate within the 2 GB of virtual memory

that a 32-bit version of Windows allocates to every process. However,

despite Wow64, 32-bit programs on Windows Vista x64 Edition cannot take

advantage of the larger 64-bit address spaces or wider 64-bit registers on

64-bit processors."

 

The phrase "by translating instructions passing in and out of 32-bit

applications into 64-bit instructions" would be "on-the-fly."

The phrase "operate within the 2 GB of virtual memory that a 32-bit version

of Windows allocates to every process" would be the "being limited to 32-bit

rules."

 

In most cases, 32-bit instructions are converted "on-the-chip"... (a 32-bit

instruction is put into a 64-bit register.) Most kernel routines require

conversion to a 64-bit equivalent call. In this case, WOW64 adds overhead as

it must maintain both 32-bit and 64-bit stacks to allow communication within

the executable and externally to any kernel connections (kernel32.dll,

ntdll.dll, user32.dll, imm32.dll ,gdi32.dll, rpcrt4.dll).

 

"WOW64 adds significant virtual memory overhead if two or more instances of

the same 32-bit application are run concurrently. read-only memory pages are

not shared between 32-bit processes as they are on x86 NT/Win9x."

 

"WOW64 does not support access to more than 2gb of memory - there is no

support for 3gb usermode processes via /LARGEADDRESSAWARE:YES

All kernelmode drivers must be ported to 64-bit native code."

 

Beyond that, well, have a good day.

 

 

 

"Bobby Johnson" <rjohnson@aol.NOSPAM.com> wrote in message

news:%23Hi3gFdNJHA.1960@TK2MSFTNGP04.phx.gbl...

> I don't know where you obtained your information, but it is seriously

> flawed. 32-bit application are NOT converted "on-the fly" in Windows

> x64! The are run in a virtual 32-bit environment space under WOW64.

> You need to do some more research before you make such erroneous

> statements! And each APPLICATION gets 2GB for ALL its processes to share!

>

>

> Mark H wrote:

> > An architectural limit has been reached. Some commonly reported

> > architectural limits in Windows include:

> >

> > 1. 2 GB of shared virtual address space for the system

> > 2. 2 GB of private virtual address space per process

> > 3. 660 MB System PTE storage

> > 4. 470 MB paged pool storage

> > 5. 256 MB nonpaged pool storage

> > 6. 1 GB System cache

> > 7. 16,000 GB pagefile size

> >

> > Your current set of applications are using 18GB of virtual address

space. (8

> > application processes, 1 OS)

> > So answering you're original question, Yes. Each process has it's own

2GB of

> > virtual memory.

> >

> > But, here's the rub:

> > Your're running 32-bit applications in a 64-bit OS. For this to occur,

the

> > 32-bit application must be converted, on-the-fly, to a 64-bit

application.

> > It now uses twice as much memory to do the same thing while being

limited to

> > the 32-bit rules. The executable stays the same size (only converted as

> > used), but the data produced is retained in 64-bit. Example: Your

routine is

> > 1KB, but it calculates Pi to 1GB places. To store the number, you need

2GB

> > for this emulated x64 application. Since these are data intensive

> > applications, you may be running out of memory, not addresses. Run less

> > processes, or set the page file bigger.

> >

> > You have 16 GB of RAM, paging will occur as you are currently setup

> > significantly reducing the performance of your applications. But, more

> > importantly, the Paged Pool Entry Table is trying to handle a huge

amount of

> > information. You may be running out of Shared Virtual Memory (the OS)

which

> > is reported as Out of Memory, and not Private Virtual Memory for your

> > processes. Because you hit the limit at 1.8GB, I suspect your problem is

> > Shared Virtual Memory (the OS) running out of memory as it sets up

tables

> > for paging all the data produced.

> >

> > A kernel debugger is needed to find out which limit you are violating.

> >

> > "Bobby Johnson" <rjohnson@aol.NOSPAM.com> wrote in message

> > news:OMXFqSVNJHA.5232@TK2MSFTNGP05.phx.gbl...

> >

> >> Each 32-bit program has it own block of memory which will be shared by

> >> the processes running within that program just as if it were actually

> >> running that program on a Windows XP Pro (32-bit) system. I thought

> >> that was pointed out in the info on WOW64.

> >>

> >>

> >> Mike Sharpe wrote:

> >>

> >>> The documents were helpful but did not answer my question. I

understand

> >>> 64-Bit addresses. I understand 32-Bit addresses. What I am not

> >>> understanding is whether or not the 64-Bit Windows Virtual Memory

> >>>

> > Manager can

> >

> >>> provide unique blocks of 2GB (or 3GB with the switch) for each 32-bit

> >>> process or if they all share the same. I have an 8 core computer with

> >>>

> > 16GB

> >

> >>> of RAM running 64-Bit OS. I have 8 32-Bit processes running. My page

> >>>

> > file

> >

> >>> is setup for 10GB which should leave me with a total of approximately

> >>>

> > 26GB of

> >

> >>> Virtual Memory.

> >>>

> >>> I start up an application 8 times. Each one runs in its own process

and

> >>> assigned to its own CPU. This application is 32-Bit and let's say

each

> >>>

> > one

> >

> >>> uses about 1GB of RAM. What I am seeing is that when the Physical

> >>>

> > Memory of

> >

> >>> the box (not per process, the whole box) reaches about 1.8GB, my

> >>>

> > processes

> >

> >>> start experiencing problems and I get Out of Memory errors. If I do

> >>>

> > some

> >

> >>> quick math, 8 CPU x 1GB = 8GB of memory total. Since my system has

16GB

> >>> total, I should be consuming only about half. And each 32-Bit process

> >>>

> > is

> >

> >>> under the 2 GB limit.

> >>>

> >>> What I suspect is happening is that each process is sharing the SAME

> >>>

> > 32-Bit

> >

> >>> space instead of being granted their own space in the Virtual memory

and

> >>>

> > the

> >

> >>> 64-Bit memory manager controlling where each process recognizes its

> >>>

> > space.

> >

> >>> Even if some data is in the 64-Bit range for a single process, it

should

> >>>

> > be

> >

> >>> able to map that down to the process specific 32-Bit range.

> >>>

> >>>

> >>>

> >>>

> >

> >

> >