[commit: ghc] master: rts: Enable two-step allocator on FreeBSD (8736715)

git at git.haskell.org git at git.haskell.org
Fri Jul 6 18:10:44 UTC 2018


Repository : ssh://git@git.haskell.org/ghc

On branch  : master
Link       : http://ghc.haskell.org/trac/ghc/changeset/8736715857d08cc1f88d766c257b39c05df20639/ghc

>---------------------------------------------------------------

commit 8736715857d08cc1f88d766c257b39c05df20639
Author: Ben Gamari <bgamari.foss at gmail.com>
Date:   Fri Jul 6 11:11:20 2018 -0400

    rts: Enable two-step allocator on FreeBSD
    
    Previously we would prevent any operating system not providing the
    MEM_NORESERVE flag
    from using the two-step allocator. Afterall, Linux will reserve
    swap-space for
    a mapping unless this flag is given, which is most certainly not what
    we want.
    
    However, it seems that FreeBSD provides the reservation-only mapping
    behavior
    that we expect despite not providing the MEM_NORESERVE macro. In fact,
    it
    provided the macro until 2014, when it was removed on account of not
    being
    implemented in the kernel. However, empirical evidence suggests that
    just plain
    mmap does what we want.
    
    Reviewers: erikd, simonmar
    
    Subscribers: rwbarton, thomie, erikd, carter
    
    GHC Trac Issues: #15348
    
    Differential Revision: https://phabricator.haskell.org/D4939


>---------------------------------------------------------------

8736715857d08cc1f88d766c257b39c05df20639
 configure.ac      | 17 +++++++++--------
 rts/posix/OSMem.c | 11 ++++++++---
 2 files changed, 17 insertions(+), 11 deletions(-)

diff --git a/configure.ac b/configure.ac
index ac464b6..1976530 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1182,22 +1182,23 @@ if test "$ac_cv_sizeof_void_p" -eq 8 ; then
     if test "x$EnableLargeAddressSpace" = "xyes" ; then
         if test "$ghc_host_os" = "darwin" ; then
             use_large_address_space=yes
-	elif test "$ghc_host_os" = "openbsd" ; then
-	    # as of OpenBSD 5.8 (2015), OpenBSD does not support mmap with MAP_NORESERVE.
-	    # The flag MAP_NORESERVE is supported for source compatibility reasons,
-	    # but is completely ignored by OS mmap
+        elif test "$ghc_host_os" = "openbsd" ; then
+            # as of OpenBSD 5.8 (2015), OpenBSD does not support mmap with MAP_NORESERVE.
+            # The flag MAP_NORESERVE is supported for source compatibility reasons,
+            # but is completely ignored by OS mmap
             use_large_address_space=no
         else
-            AC_CHECK_DECLS([MAP_NORESERVE, MADV_FREE, MADV_DONTNEED],[],[],
+            AC_CHECK_DECLS([MAP_NORESERVE, MAP_GUARD, MADV_FREE, MADV_DONTNEED],[],[],
                 [
                 #include <unistd.h>
                 #include <sys/types.h>
                 #include <sys/mman.h>
                 #include <fcntl.h>
             ])
-            if test "$ac_cv_have_decl_MAP_NORESERVE" = "yes" &&
-                test "$ac_cv_have_decl_MADV_FREE" = "yes" ||
-                test "$ac_cv_have_decl_MADV_DONTNEED" = "yes" ; then
+            if ( test "$ac_cv_have_decl_MAP_NORESERVE" = "yes" ||
+                 test "$ac_cv_have_decl_MAP_GUARD" = "yes" ) &&
+                ( test "$ac_cv_have_decl_MADV_FREE" = "yes" ||
+                test "$ac_cv_have_decl_MADV_DONTNEED" = "yes" ) ; then
                     use_large_address_space=yes
             fi
         fi
diff --git a/rts/posix/OSMem.c b/rts/posix/OSMem.c
index e63e798..08f9635 100644
--- a/rts/posix/OSMem.c
+++ b/rts/posix/OSMem.c
@@ -102,8 +102,10 @@ void osMemInit(void)
  The naming is chosen from the Win32 API (VirtualAlloc) which does the
  same thing and has done so forever, while support for this in Unix systems
  has only been added recently and is hidden in the posix portability mess.
- It is confusing because to get the reserve behavior we need MAP_NORESERVE
- (which tells the kernel not to allocate backing space), but heh...
+ The Linux manpage suggests that mmap must be passed MAP_NORESERVE in order
+ to get reservation-only behavior. It is confusing because to get the reserve
+ behavior we need MAP_NORESERVE (which tells the kernel not to allocate backing
+ space), but heh...
 */
 enum
 {
@@ -161,7 +163,10 @@ my_mmap (void *addr, W_ size, int operation)
     else
         prot = PROT_NONE;
     if (operation == MEM_RESERVE)
-# if defined(MAP_NORESERVE)
+# if defined(MAP_GUARD)
+        // Provided by FreeBSD
+        flags = MAP_GUARD;
+# elif defined(MAP_NORESERVE)
         flags = MAP_NORESERVE;
 # else
 #  if defined(USE_LARGE_ADDRESS_SPACE)



More information about the ghc-commits mailing list