From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 28 00:02:18 2009 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F6021065670 for ; Sat, 28 Nov 2009 00:02:18 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from sippysoft.com (gk1.360sip.com [72.236.70.240]) by mx1.freebsd.org (Postfix) with ESMTP id 21A9C8FC0A for ; Sat, 28 Nov 2009 00:02:17 +0000 (UTC) Received: from [192.168.1.38] (S0106005004e13421.vs.shawcable.net [70.71.167.197]) (authenticated bits=0) by sippysoft.com (8.14.3/8.14.3) with ESMTP id nAS025Q4063941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 27 Nov 2009 16:02:11 -0800 (PST) (envelope-from sobomax@sippysoft.com) Message-ID: <4B10687D.3050209@sippysoft.com> Date: Fri, 27 Nov 2009 16:02:05 -0800 From: Maxim Sobolev Organization: Sippy Software User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Jason Evans References: <4B1041EB.9020109@sippysoft.com> <4B1059CA.6040605@FreeBSD.org> In-Reply-To: <4B1059CA.6040605@FreeBSD.org> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 28 Nov 2009 01:11:08 +0000 Cc: FreeBSD Hackers Subject: Re: heap limits: mmap(2) vs. break(2) on i386 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2009 00:02:18 -0000 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. Jason, So, are you saying that by allocating 2GB to MAXDSIZ, I limit myself less than 1GB left to be allocated via mmap()? Perhaps the cause of the problem is my interpretation of MAXDSIZ as an overall limit of VM that the process will be able to allocate regardless of the memory management interface is wrong, and in fact the process can allocate up to MAXDSIZ using sbrk(2) and then some extra using mmap(2) up to 3GB? I tried lowering DFLDSIZ to 1.5GB, and it helped with Java. 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? -Maxim