As it is now it sometimes gets very confusing because people are talking about VAS that's dropping while it is actually rising or people are saying there is no problem with VAS while there actually is!

FYI. I tried this on my system and the FSUIPC monitoring thing introduced stuttering in my system. Maybe just me and my system.

Edited February 18, 201412 yr by n4gix
Removed excessive quote. Please do not quote the entire message when replying!

FYI. I tried this on my system and the FSUIPC monitoring thing introduced stuttering in my system. Maybe just me and my system.

Happens with Microsoft's Process Explorer as well.

FYI. I tried this on my system and the FSUIPC monitoring thing introduced stuttering in my system. Maybe just me and my system.

 

The onscreen monitor also gives stutters on my PC. Even running Process Explorer in the background sometimes gives stutters. The FSUIPC monitor on the window title bar doesn't give me any problems. However, when I fly without testing something, I disable all those counters.

Light relief moment for all on VAS? we've entered genuine Gulliver's Travels Brobdingnag back slapping farce when we really truly and earnestly continue to debate at length about VAS being half full or half empty - really should one should break the egg from the narrow end, or the wide end up == invitation to laugh again as friends :- )

 

No disrespects lol to either view

 

And very much look forward to geolpilot's your final research - as long as it's good news I hope: something we can use please please until patched ! Because veg autogen to sparse may after all be inaccurate but it's got the single virtue of getting some of us back in the air for more than 20 minutes without oom :-)

 

Sunny side up,

Kab x

 

 

Sent from my iPhone using Tapatalk

The reason some people get an OOM error before hitting 4GB is because if P3D can't allocate a big enough chunk of contiguous memory , it's still an OOM. The VAS can get fragmented as a result of allocating and freeing memory eventually there will not be a big enough chunk left for the program then....crash.

 

http://technet.microsoft.com/en-us/sysinternals/dd535533.aspx

 

Get this tool then you can see it for yourself.

The reason some people get an OOM error before hitting 4GB is because if P3D can't allocate a big enough chunk of contiguous memory , it's still an OOM. The VAS can get fragmented as a result of allocating and freeing memory...

This point has been made several times before, but since you thankfully brought it up again, I will take the opportunity to point out that fragmentation of physical memory and fragmentation of virtual memory (simulated memory using disk storage) could produce very different results.

 

On my Win 8 system, with everything but P3d running, I am using 3.8 GB. If I pushed P3d to 4 GB (Which I have never seen happen), that would require almost 8Gb of RAM just to avoid using the swap file at all.

 

As you can see from my profile I have 40 GB of RAM, so the likelihood of fragmentation is about nil. Other users with large amounts of RAM (>16 GB) have reported less problems with p3d. It could be coincidental, but I expect that it is not.

What I'm talking about is VAS fragmentation has nothing absolutely to do with hard disk swap file or how much system memory you have unless you had less than about 6GB. You should go back and re read about virtual address space and 32 bit program limitations.

Time for another analogy in an attempt to clear confusion.

Virtual Address Space (table) does not equal Virtual Memory or physical Memory.

 

511 Hoffman Street does not equal "my physical house." It is nothing more than the address at which you will find "my physical house."

 

Similarly, an address in the VAS table is nothing more than the address at which the system will find "the application's data."

 

There are many ways in which a "Page Table" may be constructed, and it is up to the application's programmer to determine which of the various techniques is best suited for their application. Without knowing which technique FSX or Prepar3D uses, it's not possible to make any substantive evaluation of the relative efficiency of the process.

 

Nonetheless, all techniques essentially perform the identical task, which is simply to keep track of virtual addresses so that the system will know where stuff goes in physical memory whenever the system needs to move it in or out of virtual memory or the hard disk.

What I'm talking about is VAS fragmentation has nothing absolutely to do with hard disk swap file or how much system memory you have unless you had less than about 6GB. You should go back and re read about virtual address space and 32 bit program limitations.

My response was related to address space fragmentation and how that could lead to an OOM message without the app nearing the 4 GB limit.

 

Beyond that you have a lot of faith in MS's kludge of the swap file to emulate physical RAM.

 

 

511 Hoffman Street does not equal "my physical house." It is nothing more than the address at which you will find "my physical house."



Similarly, an address in the VAS table is nothing more than the address at which the system will find "the application's data."

 

Thanks for the clear explanation Fr. Bill. So what causes the address space to overfill? Are other processes/dlls/whatever giving FSX addresses that FSX or entities are not clearing out?

 

Ted

Bill Gates: "I never said '640K should be enough for anybody!'"

 

I guess its a hard lesson learned for LM. VAS management is priority number 1 under a 32bit framework.

 

I'm running windows 8.1 64bit and getting OOM's.... can't imagine P3D under 32bit O/S with even less VAS available.

 

Under a full 64bit setup (App and OS), VAS management would be priority 2000 and nostalgic types could still watch the address pool fill up with the Dowson FSUIPC while watching a sunset  :crazy:  ...  drinking a fine Tequila LOL

 

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

 

 

 

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;^[5][4] without that option they are limited to 2GB. By default, 64-bit processes have 8TB of user-mode virtual address space; Linking with /LARGEADDRESSAWARE:NO artificially limits the user-mode virtual address space to 2 GB.^[6][7]

 

 

Check this out, It explains it better than I can:

 

http://bugslasher.net/2011/01/15/memory-exhaustion-even-if-a-large-enough-free-memory-segment-is-available/

Very informative link Slayer. Thanks for posting that. Its going to take me awhile to absorb all of it. :biggrin:

Ted.

Thanks for the clear explanation Fr. Bill. So what causes the address space to overfill?

Ted, in simple terms... as time passes in the sim, more and more new scenery, AI, and autogen objects are added to the remaining empty pool of virtual address spaces.

 

The sim maintains previously loaded objects in the VAS table simply because you might turn around and pass over previously flown areas again, so there's no point in purging those addresses from VAS and remove those objects from the system's RAM (physical memory), so the amount of physical memory and virtual addresses used is going to gradually increase.

 

In a well-managed scenario, after some pre-determined point is reached, the program should release both the RAM and VAS gracefully, thus keeping things under control. It appears to me that this is not happening as well as it should, so we see the results when at some point there are no longer any 1MB contiguous blocks of VAS remaining, and we get the bOOM... :blush:

 

Nota bene: this is a very simplified explanation of what is truly a very complex subject.

Very clear explanation Bill. Thanks. From reading though the link that Slayer provided, finding the root cause of the runaway VAS does not appear to be an easy task.

 

Ted