Share via

Be Aware: 4GB of VAS under WOW, does it really worth it?

  • Article

By now you have heard a lot about the fact that under WOW a 32 bit process can get 4GB of VAS. I agree this is great, but I would like you to be aware of something that might hit you really hard. As it turns out enabling 4GB VAS can be problematic due to either 32 bit app you are using or dlls 32 bit application might end up loading.  

 

In the past, past times, developers thought that 32 bit pointer can never exceed 2GB boundary and the max pointer is 0x7fffffff. This assumption was based on Windows architecture of splitting VAS into two major regions user and kernel each 2GB in size. Due to the assumption some developers have ended up using high bits of a pointer to store extra information. Knowing that those bits are not used anyway they, for example, play some tricks and implement blocking free data structures without support for cmpxchng8b...  and then Windows added 3GB support https://msdn.microsoft.com/library/default.asp?url=/library/en-us/DevTest_g/hh/DevTest_g/BootIni_de16d3ec-c437-4628-805f-8945ea598a92.xml.asp.  All the applications and dlls that made an assumption of half and half split between user and kernel broke down https://blogs.msdn.com/oldnewthing/archive/2004/08/12/213468.aspx.

It has taken a while to shake most of the problems off. The only problem is that nobody has ever expected that suddenly 32 bit application will be given not only 3GB but all 4GB so that many developers has continued relying on the fact that last 1GB can never be given to the app. Well, they have been wrong. Now 32 bit large address aware applications can get all 4GB of VAS to work with. And the problems have started crippling in as more and more of older 32 applications are moved on 64 bit machines to be run in WOW mode.

In the last several month we have seen several cases when user written dlls loaded into server process space bring it down due to incorrect handling of pointers in WOW. In this case server can't do much, for example, incorrectly written dll might corrupt process heap and will force server restart.

 

So here is my suggestions. If you are a system administrator you need to make sure  that before moving critical large address aware application into WOW

 

A. You get sign off from your developers and developers of external dlls your application loads on correct pointer usage under WOW

B. You test and stress test the application on WOW as thoroughly as possible before making the move

 

If you a developer, you need to make sure  that before running critical large address aware application into WOW, you remove all incorrect pointer manipulation including high bit usage, and possible pointer overflowing such as (a+b)/2

 

The bottom line of this post is if you can run an application natively in 64bit mode you probably should do that instead of trying continue running it as 32 bit in WOW.

 

So the question to you then: should you buy native x64 bit version of SQL 2005 instead of running SQL Server in WOW :-)? (Keep in mind SQL 2000 itself doesn't exhibit large address aware problem though dlls that developer/DBA can force SQL Server to load through extended procs or COM might hit the issue)

 

Have a nice week!

Comments

  • Anonymous
    March 12, 2006
    The comment has been removed

  • Anonymous
    March 12, 2006
    it seems really a bug farm for legacy applications in WOW

    once hit an issue (assuming the user mode pointer always < 0x7fffffff) in delay load library even under /3GB

  • Anonymous
    March 14, 2006
    Q. Can you do the "top down memory allocation" trick in WOW that you used to be able to in regular 32-bit Windows to force the memory manager to allocate memory from the top of the address space first?
    A. You could. Though decreasing the time for catching the problem does really depend on the server application. For example, for SQL Server we always allocate VAS for BP then under VAS memory pressure we might start freeing BP's regions. Since VAS pressure can happen after weeks of server running we might not see the problem for weeks.

  • Anonymous
    November 06, 2006
    So does this mean I can see 4 GB of RAM with SQL 2000 Standard Edition SP4 on an x64 system? Or is only the enterprise edition compiled correctly to support this?

  • Anonymous
    November 13, 2006
    Nope, for SQL Server 2000 SE you will still be limitted to 2GB

  • Anonymous
    November 26, 2007
    One colleague asked me that question in order to answer one of his customer's multiple questions. The

  • Anonymous
    November 26, 2007
    One colleague asked me that question in order to answer one of his customer&#39;s multiple questions