[7ca0fdf] Disable munmap() if it causes VM map holes

Jason Evans jasone at canonware.com
Mon Apr 16 12:07:58 PDT 2012

On Apr 16, 2012, at 8:08 AM, Mike Hommey wrote:
> I noticed something "interesting" with the test for VM map holes:
> If I compile it manually, it fails:
>  Hoped for 0x7f835133d000, got 0x7f8350b3d000
>  0x7f835173d000..0x7f835133d000..0x7f8350f3d000..0x7f835073d000..0x7f8350b3d000
> Apparently, this happens when *not* linking libm to the testcase. It
> also does happen when linking libm and some other library (tried
> pthread and stdc++).

What OS is this on?  The test should fail on Linux, but not OS X or FreeBSD.  Linux has a VM map management quirk (on at least x86) that causes accumulation of VM map holes under normal operation.

> Moreover, the test being run on the build machine, which can have a very
> different setup from the machine the binary runs on, it is most probably
> not reliable to decide whether to disable munmap or not.

The AC_CACHE_CHECK() wrapper makes it possible to cross-compile, so although getting this right may be subtle, it should be possible.  I initially added a --disable-munmap configure option, but was reluctant to expose yet another option that has the sole purpose of working around a Linux VM shortcoming.


More information about the jemalloc-discuss mailing list