2

I have very strange behavior of the Windows OS regarding 32-bit processes regarding memory allocation. The problem is - it seems that 32-bit process can't allocate more than something around 1.2GB, the limit floats between 1.1GB and 1.3GB depending on conditions I have no idea about.

My environment is:

  • Windows Server 2008 R2
  • Total physical RAM - 16GB
  • RAM in use at the moment of experiment - 6GB (i.e. around 9+GB is free)

I have self-written c++ tool, which bounces memory allocation via malloc() in blocks of 32MB until it gets denial from OS (the upper limit right now is 1070MB, but as I mentioned already - limit floats, the max number I remember was around 1.3GB) and than releases all these blocks in reverse order. This is done in cycle.

So the questions I have are:

  • Why I can't get close to real limit of 2GB for 32bit process? 1.3GB is only 60% of theoretical limit. Inability to get at least 0.5 GB more seems to be very strange to me. I have 9GB of unused RAM.

  • What (at runtime) can influence on the top limit? It does change over time - I have no idea why. I'd like to control it somehow - probably there is some magic command to optimize OS address space :)

In reply to comments:

  • show the loop where you allocate the memory:

    here it is https://code.google.com/p/membounce/source/browse/

    Note: after looking deeper into the code I've noticed the bug which incorrectly calculated the upper limit (when allocation page size is changed dynamically while tool is running :() - the actual limit I'm getting right now is around 1.6 GB - this is better than 1.2 but yet not close to 2GB.

  • Build to x64 instead:

    in that case I'm interested particularly in 32bit. The original cause of this topic is sometime I'm not able to run java (specifically Netbeans x32) with Xmx900M (says JVM creation failed), and sometime it DOES run with Xmx1200M (Xmx is JVM parameter of max RAM that can be used by JVM). The reason I want to use non-x64 netbeans is because java (at least Oracle's JVM) effectively consumes twice more memory when switching to x64, i.e I have to allocate 2GB of RAM to JVM to get same efficiency as with 1GB on 32bit JVM. I have number of java processes and want to fit more of them into my 16GB address space :) (this is some kind of offtopic background)

Xtra Coder
  • 3,389
  • 4
  • 40
  • 59
  • show the loop where you allocate the memory – bolov Jun 27 '14 at 10:58
  • http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778(v=vs.85).aspx#physical_memory_limits_windows_server_2008_r2 here you can see the memory limits. You can see that `Windows Server 2008 R2 Foundation` has a limit of `8 GB`. The other versions have significantly higher limits. So are you using the `Foundation` version? – bolov Jun 27 '14 at 11:03
  • also see this http://stackoverflow.com/questions/570589/can-a-32bit-process-access-more-memory-on-a-64bit-windows-os – bolov Jun 27 '14 at 11:06
  • 1
    You've got nice hardware, there's no point in not using it. Build to x64 instead. Use [this blog post](http://blogs.technet.com/b/markrussinovich/archive/2008/11/17/3155406.aspx) and its test program to get insight. – Hans Passant Jun 27 '14 at 12:03
  • I've added replies to some comments in the original question – Xtra Coder Jun 27 '14 at 13:40
  • 3
    There is more stuff that lives in the 2GB address space than just the memory you allocated. (For example, your *code* needs to live in that address space, too.) Use VMMap to see what it all is. – Raymond Chen Jun 27 '14 at 13:50
  • I don't think you will ever get to 2GB by allocating. e.g. the first 64kb are reserved anyway. Some of the virtual code resides also in memory. You should also check your .exe Sections to see how much is mapped. – Ben Jun 27 '14 at 13:53
  • possible duplicate of [allocate more than 1 GB memory on 32 bit XP](http://stackoverflow.com/questions/9785174/allocate-more-than-1-gb-memory-on-32-bit-xp) – nobody Jun 27 '14 at 15:21

0 Answers0