Date: Tue, 8 Jan 2008 02:37:31 +0100 From: Peter Schuller <peter.schuller@infidyne.com> To: freebsd-current@freebsd.org Cc: Kostik Belousov <kostikbel@gmail.com>, Andrew Reilly <andrew-freebsd@areilly.bpc-users.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Igor Mozolevsky <igor@hybrid-lab.co.uk>, Peter Jeremy <peterjeremy@optushome.com.au> Subject: Re: sbrk(2) broken Message-ID: <200801080237.40379.peter.schuller@infidyne.com> In-Reply-To: <15094.1199751424@critter.freebsd.dk> References: <15094.1199751424@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <peter.schuller@infidyne.com>' 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200801080237.40379.peter.schuller>