From 8ef62820ffd6d0340a99bcee27552e08a0eb7034 Mon Sep 17 00:00:00 2001 From: simonmar Date: Tue, 12 Jul 2005 11:38:44 +0000 Subject: [PATCH] [project @ 2005-07-12 11:38:44 by simonmar] Add some comments on why we don't use posix_memalign() right now. --- ghc/rts/MBlock.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/ghc/rts/MBlock.c b/ghc/rts/MBlock.c index 0ce1e76..331982d 100644 --- a/ghc/rts/MBlock.c +++ b/ghc/rts/MBlock.c @@ -134,6 +134,16 @@ getMBlock(void) chunk, on the grounds that this is aligned and likely to be free. If it turns out that we were wrong, we have to munmap() and try again using the general method. + + Note on posix_memalign(): this interface is available on recent + systems and appears to provide exactly what we want. However, it + turns out not to be as good as our mmap() implementation, because + it wastes extra space (using double the address space, in a test on + x86_64/Linux). The problem seems to be that posix_memalign() + returns memory that can be free()'d, so the library must store + extra information along with the allocated block, thus messing up + the alignment. Hence, we don't use posix_memalign() for now. + -------------------------------------------------------------------------- */ #if !defined(mingw32_HOST_OS) && !defined(cygwin32_HOST_OS) -- 1.7.10.4