[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