public inbox for cygwin-cvs@sourceware.org
help / color / mirror / Atom feed
From: Corinna Vinschen <corinna@sourceware.org>
To: cygwin-cvs@sourceware.org
Subject: [newlib-cygwin] Cygwin: mmap_alloc: fix comment to document using the extended memory API
Date: Tue,  7 Apr 2020 16:24:53 +0000 (GMT)	[thread overview]
Message-ID: <20200407162453.7A41A385DC1A@sourceware.org> (raw)

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=3fe9b02ccd6aeb684e39ca3fb9a6fd3ee5ede852

commit 3fe9b02ccd6aeb684e39ca3fb9a6fd3ee5ede852
Author: Corinna Vinschen <corinna@vinschen.de>
Date:   Tue Apr 7 14:17:04 2020 +0200

    Cygwin: mmap_alloc: fix comment to document using the extended memory API
    
    Signed-off-by: Corinna Vinschen <corinna@vinschen.de>

Diff:
---
 winsup/cygwin/mmap_alloc.cc | 23 +++++++++++++----------
 1 file 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)
 {


                 reply	other threads:[~2020-04-07 16:24 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200407162453.7A41A385DC1A@sourceware.org \
    --to=corinna@sourceware.org \
    --cc=cygwin-cvs@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).