From owner-freebsd-current@FreeBSD.ORG Tue Jan 8 01:37:33 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC09016A418 for ; Tue, 8 Jan 2008 01:37:33 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from smtp.infidyne.com (ds9.infidyne.com [88.80.6.206]) by mx1.freebsd.org (Postfix) with ESMTP id 81DD513C455 for ; Tue, 8 Jan 2008 01:37:33 +0000 (UTC) (envelope-from peter.schuller@infidyne.com) Received: from c-8216e555.03-51-73746f3.cust.bredbandsbolaget.se (c-8216e555.03-51-73746f3.cust.bredbandsbolaget.se [85.229.22.130]) by smtp.infidyne.com (Postfix) with ESMTP id 5E12996FD; Tue, 8 Jan 2008 02:37:31 +0100 (CET) From: Peter Schuller To: freebsd-current@freebsd.org Date: Tue, 8 Jan 2008 02:37:31 +0100 User-Agent: KMail/1.9.7 References: <15094.1199751424@critter.freebsd.dk> In-Reply-To: <15094.1199751424@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3582823.OzzedFMMDR"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200801080237.40379.peter.schuller@infidyne.com> Cc: Kostik Belousov , Andrew Reilly , Poul-Henning Kamp , Igor Mozolevsky , Peter Jeremy Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2008 01:37:34 -0000 --nextPart3582823.OzzedFMMDR Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > For performance reasons, malloc(3) will hold on to a number of pages > that theoretically could be given back to the kernel, simply because > it expects to need them shortly. Although the primary concern is malloc(), I would like to point out that=20 various programs implementing copying garbage collection could more=20 efficiently give memory back to the system than malloc(), and could therefo= r=20 benefit more than malloc() from some kind of feedback from the kernel. There was concern over the complexity involved with intelligently doing=20 something about the memory pressure hints in userspace, but this does not=20 apply here since the allocator/garbage collection would be the equivalent o= f=20 malloc() and complexity there would not affect application code. The problem with malloc() being that, unless I am missing something, malloc= =20 will never be able to give back memory to the kernel except insofar as the= =20 memory mapped is continuously unused between some location and the break (i= n=20 the case of sbrk()) or over the entire range (mmap()). malloc() cannot forc= e=20 this to be the case, since pointers must remain valid. The possibility of=20 reclamation is then often going to be limited to completely unused space=20 being held by malloc() for future use, rather than also applying to areas=20 already used for allocation. Programs implementing copying GC, or able to for some other reason to move= =20 allocated memory around, could compact the heap and give back left-over=20 memory. In some cases this would only entail a temporary improvement due to= =20 defragmentation, but in others (such as a long-running program spiking in=20 memory use, only then to drop a lot of that memory) it could have a pretty= =20 massive effect on memory use. Where a malloc() using program might be unable to sbrk() or munmap() becaus= e=20 there happens to be some left-over non-free piece of memory at the top of t= he=20 mapped range, a GC could use indications from the system to ensure this is= =20 not the case (depending on details of the implementation; for example,=20 compactation of tenured generations could be forced early, etc). (This is not to say I am aware of any implementation that actually supports= =20 this, but on the other hand perhaps that is due to the lack of operating=20 systems that provide the required feedback.) =2D-=20 / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller ' Key retrieval: Send an E-Mail to getpgpkey@scode.org E-Mail: peter.schuller@infidyne.com Web: http://www.scode.org --nextPart3582823.OzzedFMMDR Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQBHgtPkDNor2+l1i30RArqwAJ9CbTrjN7XwhdAXzszTjCbnfBGjEACfT50H /oBJrHvuIDdDPJpxLC8RSog= =0sNw -----END PGP SIGNATURE----- --nextPart3582823.OzzedFMMDR--