Manual solution of OOM

[3-2-1-Now 126]

VAS is just a fancy name for flat memory addressing. It doesn't change the 2^32 address space limit of 32-bit processes.

 

Best regards,

Robin.

[mgh 89]

Flat memory addressing  has nothing to do it's a 32 or 64 bit process - both are flat memory addressing.

 

 It's the Virtual Address Space (VAS)  that determines whether it's 32 or 64 bit .

[Don t moderate me this way 882]

(...)

 It's the Virtual Address Space (VAS)  that determines whether it's 32 or 64 bit .

 

 

It's actually the other way round.  

[mgh 89]

What is?

[Don t moderate me this way 882]

"On 64-bit Microsoft Windows, processes running 32-bit executables that were linked with the /LARGEADDRESSAWARE:YES option have access to 4 GiB of virtual address space; without that option they are limited to 2GB. By default, 64-bit processes have 8TB of user-mode virtual address space; (...)"

 

from: http://en.wikipedia.org/wiki/Virtual_address_space

[mgh 89]

User-mode virtual address space for each 32-bit process is

• Limit in on X86 determines if it's 2GB or up to 3GB with IMAGE_FILE_LARGE_ADDRESS_AWARE (set) and 4GT
• Limit in 64-bit Windows and determines if it's 2 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE cleared (default) or 4 GB with  set

So with 64 bit you can't set 3GB user-mode virtual address space.

 

Also, you can't set 8TB user-mode virtual address space with an 32 bit.

Edited February 24, 2014 by mgh

[kevinh 409]

You've still got it backwards. The number of bits determines the maximum addressable space. Not the other way around.

 

A 32 bit application running on a 64 bit OS is of course still limited to 32 bit addressing.

 

 

Sent from my iPhone using Tapatalk

Edited February 24, 2014 by kevinh

[MorsAbAlto 19]

VAS size is determined by the the supported word length of the operating system.

 

a. A 32-bit process in a 32-bit Windows environment will be allocated a maximum of 2 GB of VAS, the rest being used by Windows. This can be increased to a maximum of 3 GB with the LAA flag. Not more.

 

b. A 32 bit-process in a 64-bit Windows environment will be allocated a maximum of 4 GB of VAS, minus the memory footprint of the operating system, unless there are more than 4 GB of physical memory installed.

 

c. Now a 64-bit process in a 64 bit Windows environment will be allocated up to 8 TB of VAS.

 

FSX falls into category b. and there is no way around this 4 GB limit.

Edited February 24, 2014 by MorsAbAlto

[mgh 89]

That is what already posted but for completion for user-mode virtual address space for each 64-bit process

• Limit on 64-windows determines if it's x64 8TB (Intel Itanium-based systems 7TB, or Windows 8.1 and Windows Server 2012 R2 128TB) with IMAGE_FILE_LARGE_ADDRESS_AWARE set (default), or 2 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE cleared

 

64 bit may still have only 2GB

[aentwis 61]

Lots of really interesting stuff here everyone. Mgh, thanks for the summary. I think your posts should be highlighted as best answers here, so that people stopping by finally understand. No 32-bit application is ever going to see more than 4 GiB of VAS, regardless of it running on 64, 128, or even a 256-bit OS... Period.

 

 

 

 

Andrew Entwistle

[Fabo 213]

 

 

They are strictly speaking correct but if you expect to get 1 TB (in the computing sense of 10244 bytes) you will feel cheated. You'll get around 1012 bytes, about 9% less. Windows keeps up the confusion by not following the same naming standard. For example my laptop HDD is 750 GB according to the manufacturer. Windows "My Computer" reports that as 698 GB (750,145,503,232 bytes). It's not surprising people feel cheated.

 

Just be glad they don't use bit notation, as internet connection companies (almost) always do.

 

Fun game: try and find a C/S rep that does not understand the bit/byte difference and get them totally confused. Depending on your provider, this might be either next to impossible, or impossibly easy.

[pracines 823]

Maybe someday we will have a 128 bit simulator (may as well skip 64 bit now since its getting kind of old). Its more likely that our sun will go nova first :-)

 

Paul Racines

[Noel 4,483]

 

 

there is no way around this 4 GB limit.

 

This sounds absolutely locked in stone as you explain it, but...because I don't really understand the WHY part of this, it seems intuitive that a hack could be created to fool the OS into giving more VAS to an application.   I'm sure by now this would have been done, presumably.  So why is a hack not possible? 

[LHookins 3,102]

 

 

So why is a hack not possible?

 

I tried to work through this one a while back.  Unfortunately, a program will have pointers 32 bits long, no more, and there's no way to map more than 32 bits into this pointer.  For example, if you try to use one bit to specify which of two 32 bit address spaces you want to use, that leaves you with two 31 bit address spaces, the same total amount.  For various reasons, you have to be able to address every byte in an address space.

 

Sorry 'bout that.

 

Hook

[jabloomf1230 2,445]

There are ways around the 4 GB limit for 32 bit apps running under Win x64. They have been used in commercial software, but they also have drawbacks that make the approach viable only as short term solutions. I've mentioned this before as an example, but before Adobe went 64 bit with its entire suite of apps (Photoshop, Illustrator, Premiere Pro, etc.), its video special effects app,  After Effects CS4 would spawn multiple specialized copies of itself to do tasks in parallel and the main instance of the app would keep track of all the instances. For example, one instance would do all the work for one frame and then a second instance would do all the work for the next frame. Each instance and the main instance would each get 4 GB of VAS.

 

Of course, this approach was abandoned as Adobe went full 64 bit. I should add here for those who use Google Chrome as their browser, it still utilizes this approach, although the reason is not to stay under 4 GB of VAS. And if you think about it further, since most of the weather add-ons for FSX and P3d are self contained apps, they also get their own 4 GB of VAS. TrackIR is also a separate app. The approach is possible, but it isn't the best course of action. The best course of action is to offload as much computational load to the GPU.