Instead of the view rbtree.
Testing shows a 20% FPS increase in We Happy Few, from 80-100fps to
100-120fps right after starting a new game.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This is an ordered range sequence used to keep track of free address
ranges.
The sequence contains an entry for every free address range, with base
pointing to the first free address and end pointing to the next first
used address. It is initialized to [0, ~0] for convenience, so that
there's always a range before or after a view.
In the worst case scenario, where memory is entirely fragmented, there's
going to be one more range than allocated views, but in general there's
much less. In any case, because of cache locality, iterating in the
contiguous sequence is much faster than traversing the view rbtree.
In theory there can be a performance hit when allocating or deleting a
view, as we may have to move the end of the sequence when a range is
split or merged. But in practice and given the usually low number of
ranges, this is not an issue.
The default and maximum sequence size can hold up to 65536 ranges, which
is much more than enough in general, and performance is probably going
to be bad before reaching the limit anyway. The code currently asserts
when reaching the limit, although we could possibly grow the sequence.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The search was initiated with base == 0, which returns NULL immediately
if MEM_TOP_DOWN is not used. Use address_space_start instead.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=47974
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This introduces map_free_area function which tries mapping the expected
free areas until it finds one that succeeds. It now also works for
memory regions outside of the reserved region, but could probably be
improved.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
We used this function to find free areas outside of the reserved range,
and it's obviously incorrect as there can be some system or external
memory mapping we don't know about.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Use alloc_area.limit field to limit the search in reserved areas to the
desired memory range, or call find_free_area to get a pointer to a free
memory region which matches the zero_bits constraint, then mmap it with
MAP_FIXED flag.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The zero_bits parameter can be a pointer mask on Win64 and WoW64 and it
was incorrectly truncated to 16bits in APCs. Testing shows that only the
leading zeroes are used in the mask, so we can safely use the 64 based
number of leading zeroes everywhere instead.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
It can be a pointer mask, eventually 64bit, and ULONG_PTR is what can be
found in several documentation of these functions.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
NtMapViewOfSection also accepts the MEM_TOP_DOWN parameter that can
be used in combination with zero_bits to map memory on the highest
possible address.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This parameter was misinterpreted as an alignment parameter for the
lower bits of the allocated memory region, although it is a constraint
on the higher bits.
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Alexandre Julliard