summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorCorinna Vinschen <corinna@vinschen.de>2020-04-07 14:17:04 +0200
committerCorinna Vinschen <corinna@vinschen.de>2020-04-07 18:23:11 +0200
commit3fe9b02ccd6aeb684e39ca3fb9a6fd3ee5ede852 (patch)
tree4383a9b2ac66f3106981e70c8720bb4817f7c558
parentb8ecbaaac0f9ff9682a310cc78616d421470335e (diff)
downloadcygnal-3fe9b02ccd6aeb684e39ca3fb9a6fd3ee5ede852.tar.gz
cygnal-3fe9b02ccd6aeb684e39ca3fb9a6fd3ee5ede852.tar.bz2
cygnal-3fe9b02ccd6aeb684e39ca3fb9a6fd3ee5ede852.zip
Cygwin: mmap_alloc: fix comment to document using the extended memory API
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
-rw-r--r--winsup/cygwin/mmap_alloc.cc23
1 files changed, 13 insertions, 10 deletions
diff --git a/winsup/cygwin/mmap_alloc.cc b/winsup/cygwin/mmap_alloc.cc
index b42bc16e1..cd4d49bc9 100644
--- a/winsup/cygwin/mmap_alloc.cc
+++ b/winsup/cygwin/mmap_alloc.cc
@@ -4,17 +4,20 @@
#include "mmap_alloc.h"
#include <sys/param.h>
-/* FIXME? Unfortunately the OS doesn't support a top down allocation with
- a ceiling value. The ZeroBits mechanism only works for
- NtMapViewOfSection and it only evaluates the high bit of ZeroBits
- on 64 bit, so it's pretty much useless for our purposes.
+/* Starting with Windows 10 1803 we use VirtualAlloc2 and MapViewOfFile3
+ (or rather NtMapViewOfSectionEx), rather than the below class.
+
+ Up to Windows 10 1709, the OS doesn't support a top down allocation with
+ a ceiling value. The ZeroBits mechanism only works for NtMapViewOfSection
+ and it only evaluates the high bit of ZeroBits on 64 bit, so it's pretty
+ much useless for our purposes.
+
+ If the below simple mechanism to perform top-down allocations turns out to
+ be too dumb, we need something else. One idea is to divide the space in
+ (3835) 4 Gig chunks and just store the available free space per slot. Then
+ we can go top down from slot to slot and only try slots which are supposed
+ to have enough space. Bookkeeping would be very simple and fast. */
- If the below simple mechanism to perform top-down allocations
- turns out to be too dumb, we need something else. One idea is to
- dived the space in (3835) 4 Gig chunks and simply store the
- available free space per slot. Then we can go top down from slot
- to slot and only try slots which are supposed to have enough space.
- Bookkeeping would be very simple and fast. */
PVOID
mmap_allocator::alloc (PVOID in_addr, SIZE_T in_size, bool fixed)
{