Available Memory to 32-Bit Applications

Discussion in 'Windows 64bit' started by Mike Sharpe, Oct 23, 2008.

  1. Mike Sharpe

    Mike Sharpe Guest

    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.
     
    Mike Sharpe, Oct 23, 2008
    #1
    1. Advertising

  2. 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.
    >
     
    Bobby Johnson, Oct 23, 2008
    #2
    1. Advertising

  3. Mike Sharpe

    Mike Sharpe Guest

    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?
     
    Mike Sharpe, Oct 23, 2008
    #3
  4. Mike Sharpe

    Doug Forster Guest

    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" <> wrote in message
    news:...
    > 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?
     
    Doug Forster, Oct 23, 2008
    #4
  5. 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?
    >
     
    Bobby Johnson, Oct 23, 2008
    #5
  6. Mike Sharpe

    Doug Forster Guest

    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
     
    Doug Forster, Oct 23, 2008
    #6
  7. 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?
    >
     
    Bobby Johnson, Oct 23, 2008
    #7
  8. Mike Sharpe

    Mike Sharpe Guest

    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.
     
    Mike Sharpe, Oct 23, 2008
    #8
  9. 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.
    >
    >
    >
     
    Bobby Johnson, Oct 23, 2008
    #9
  10. 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.
     
    Chuck Walbourn [MSFT], Oct 24, 2008
    #10
  11. Mike Sharpe

    Doug Forster Guest

    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" <> wrote in message
    news:...
    > 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.
    >
    >
     
    Doug Forster, Oct 24, 2008
    #11
  12. Mike Sharpe

    Mark H Guest

    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" <> wrote in message
    news:...
    > 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.
    > >
    > >
    > >
     
    Mark H, Oct 24, 2008
    #12
  13. 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" <> wrote in message
    > news:...
    >
    >> 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.
    >>>
    >>>
    >>>
    >>>

    >
    >
    >
     
    Bobby Johnson, Oct 24, 2008
    #13
  14. Mike Sharpe

    Mark H Guest

    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" <> wrote in message
    news:%...
    > 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" <> wrote in message
    > > news:...
    > >
    > >> 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.
    > >>>
    > >>>
    > >>>
    > >>>

    > >
    > >
    > >
     
    Mark H, Oct 24, 2008
    #14
  15. Mike Sharpe

    Dennis Guest

    "Mark H" <> wrote in message
    news:...
    > 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.
    >

    http://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx#memory_limits
    Take a look at the "limit on 64-bit wndows" column.

    And from your link,
    Performance and memory consumption

    "WOW64 enables 32-bit applications to take advantage of the 64-bit kernel.
    Therefore, 32-bit applications can use a larger number of kernel handles and
    window handles. However, 32-bit applications may not be able to create as
    many threads under WOW64 as they can on x86. On some processors, there is
    less virtual address space available, and each thread contains a 64-bit
    stack (usually 512K). On the x64 processor, each 32-bit application receives
    4 GB virtual address space in the WOW64 environment, if the application has
    the IMAGE_FILE_LARGE_ADDRESS_AWARE flag set in the image header. If this
    flag is not set, the 32-bit application receives 2 GB virtual address
    space."

    Dennis
     
    Dennis, Nov 12, 2008
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. abcd
    Replies:
    2
    Views:
    358
  2. =?Utf-8?B?cm9oaXQ=?=

    Porting VB 6 Applications from 32 Bit to 64 Bit

    =?Utf-8?B?cm9oaXQ=?=, Nov 10, 2005, in forum: Windows 64bit
    Replies:
    2
    Views:
    2,285
    Andre Da Costa [Extended64]
    Nov 10, 2005
  3. Will
    Replies:
    2
    Views:
    670
    Charlie Russel - MVP
    Nov 7, 2006
  4. Replies:
    19
    Views:
    3,833
    Bobby Johnson
    Jan 12, 2010
  5. Replies:
    6
    Views:
    2,395
    Carlos
    May 18, 2010
Loading...

Share This Page