Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 27 Nov 2009 17:30:17 -0800
From:      Jason Evans <jasone@FreeBSD.org>
To:        Maxim Sobolev <sobomax@sippysoft.com>
Cc:        FreeBSD Hackers <freebsd-hackers@FreeBSD.org>
Subject:   Re: heap limits: mmap(2) vs. break(2) on i386
Message-ID:  <4B107D29.5030307@FreeBSD.org>
In-Reply-To: <4B10687D.3050209@sippysoft.com>
References:  <4B1041EB.9020109@sippysoft.com> <4B1059CA.6040605@FreeBSD.org> <4B10687D.3050209@sippysoft.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Maxim Sobolev wrote:
> Jason Evans wrote:
>> Maxim Sobolev wrote:
>>> I am trying to figure out why java fails to start with 1024MB of heap 
>>> on i386 with 4GB of RAM and 4GB of swap. Both MAXDSIZ and DFLDSIZ are 
>>> set to 2GB.
>>
>> Some memory (1GiB?) is reserved for kernel address space, and you 
>> reserved 2GiB for DSS.  That leaves less than 1GiB available after 
>> shared libraries and whatnot are mapped.  If there is more than 1GiB 
>> available, mmap can still fail due to the memory being non-contiguous.
> 
> So, are you saying that by allocating 2GB to MAXDSIZ, I limit myself 
> less than 1GB left to be allocated via mmap()?

Yes, my recollection is that MAXDSIZ controls the amount of virtual 
address space dedicated to DSS, and this address space will not be 
mapped via anonymous mmap.  I wanted to move completely away from using 
sbrk in malloc, but we can't completely remove DSS for backward 
compatibility reasons, which means less heap address space than would be 
ideal.

> What is the 
> best strategy if I want to maximize amount of memory available to 
> applications? Most of modern applications use mmap(), isn't it? Then 
> where MAXDSIZ can bite me if I set it to say 512MB?

I would set MAXDSIZ to 0, so that the maximum amount of memory is 
available for mapping shared libraries and files, and allocating via 
malloc.  This may cause problems with a couple of ports that implement 
their own memory allocators based on sbrk, but otherwise it should be 
all good.  You might also set /etc/malloc.conf  to 'd' in order to 
disable the sbrk calls.

Jason



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4B107D29.5030307>