[PATCH resend v3 1/2] ntdll: Try mapping free memory region outside of reserved regions.

Paul Gofman gofmanp at gmail.com
Tue Dec 24 08:23:14 CST 2019

On 12/24/19 16:17, Rémi Bernon wrote:
> On 12/24/19 1:27 PM, Alexandre Julliard wrote:
> The original patches this whole zero bits thing is based upon were
> trying semi-random addresses to try to find free system areas, with a
> timeout [1], but I'm not completely convinced that it's better
> especially with the top_down flag to implement.
> It could also read /proc/self/maps, making it not portable, I guess.
> Or maybe there's a way to enumerate mapped memory, including non-Wine,
> that I'm missing?

Just to mention, there is also an mincore() system call which I suppose
should be portable which can provide a preliminary guess if the range of
pages is free. It should be much less expensive than an attempt to map a
memory at least because the attempt always succeeds allocating the
memory outside of the region which is then freed in case memory is busy.
This is still not transactional of course (native code in separate
threads can get the memory right after checking it availability either way).

> Or you just mean the search within an expected free area could do a
> bisection instead of iterating linearly?

There are some applications which depend on (virtual) memory allocations
not returning high addresses while the lower memory is available.
Windows allocates virtual memory bottom up unless top down is explicitly
requested. I made a patch [1] some time ago which does that the same way
zero_bits allocation works (that depends on this fix or equivalent).
Unless such sort of change is not desirable for some reason it would be
great if the modified fix for zero_bits support would keep the ability
to follow bottom up / top down allocation order.



More information about the wine-devel mailing list