Possibly crazy idea to deal with memory layout problems once and for all
I have been looking at a problem that has arisen in recent versions, particularly when using some D3D games, in which the virtual address space above TASK_UNMAPPED_BASE becomes fragmented to the extent that eventually you get an out of memory condition, even though you still have well over a gigabyte free (even in a contiguous block!). This has led to some people using the attached hack (first attachment) to get their D3D games to work. After considering a lot of approaches to this problem that did not seem to get anywhere productive, it seemed that the only way to resolve it would be to get in between the application and any libraries, and the kernel. The solution I came up with is somewhat rude, but if we assume that any libraries that Wine uses only call mmap() and associated calls via the C library, then it may well do the trick, plus make it possible to implement other virtual memory APIs more effectively (and in a couple of cases eliminate calls to wineserver). If wine_preloader were extended to have its own implementation of all the friends of mmap(), and to have its own implementation of the dynamic linker, then in principle it could make sure only its mmap (and not the C library's) is called. An even more aggressive approach might be to load the C library and stick jumps into its mmap that redirect to the preloader's versions. The preloader's mmap would keep track of mappings on its own and when it receives an mmap with a start address of "NULL", decides on its own what base address to use. Any thoughts?
Friday, February 17, 2006, 8:57:06 PM, Troy Rollo wrote:
I have been looking at a problem that has arisen in recent versions, particularly when using some D3D games, in which the virtual address space above TASK_UNMAPPED_BASE becomes fragmented to the extent that eventually you get an out of memory condition, even though you still have well over a gigabyte free (even in a contiguous block!). This has led to some people using the attached hack (first attachment) to get their D3D games to work.
After considering a lot of approaches to this problem that did not seem to get anywhere productive, it seemed that the only way to resolve it would be to get in between the application and any libraries, and the kernel. The solution I came up with is somewhat rude, but if we assume that any libraries that Wine uses only call mmap() and associated calls via the C library, then it may well do the trick, plus make it possible to implement other virtual memory APIs more effectively (and in a couple of cases eliminate calls to wineserver).
If wine_preloader were extended to have its own implementation of all the friends of mmap(), and to have its own implementation of the dynamic linker, then in principle it could make sure only its mmap (and not the C library's) is called. An even more aggressive approach might be to load the C library and stick jumps into its mmap that redirect to the preloader's versions. The preloader's mmap would keep track of mappings on its own and when it receives an mmap with a start address of "NULL", decides on its own what base address to use.
Any thoughts?
You sure this patch has anything to do with the problem that you describe? It looks to me that all it does is shrinks available amount of memory for only one particular class of VirtualAlloc calls. Can you me more specific about what is the real problem here? From what I know this patch is to fix WoW (Blizard's bad assumption about place where memory will be allocated). And possible few other games (that make the same exact assumption). So far I have not see a single explanation to exact reasoning behind this hack. Also I haven't seen any comparison to native - what does it do? When I tried to test this on windows - all my allocated blocks were starting from the stack and up. Vitaliy
On Saturday 18 February 2006 15:21, Vitaliy Margolen wrote:
more specific about what is the real problem here? From what I know this patch is to fix WoW (Blizard's bad assumption about place where memory will be allocated). And possible few other games (that make the same exact assumption).
Without the hack, Age of Mythology gets an out of memory error in the current git code even before it gets to the main menu. There is sufficient memory, it's just that everything above TASK_UNMAPPED_BASE is badly fragmented so that there is no unmapped virtual address space of sufficient size in the available range. I would be surprised to see an app care about what is in bit 30 of an address - bit 31 perhaps, but bit 30 should not make a difference except perhaps in the case of comparing unassociated pointers. Is this infererence about WoW based on discovering code that has such a sensitivity?
participants (2)
-
Troy Rollo -
Vitaliy Margolen