Date: Tue, 27 Aug 1996 09:53:42 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: stesin@gu.kiev.ua Cc: angio@aros.net, squid-users@nlanr.net, current@FreeBSD.org Subject: Re: FreeBSD malloc.c, -lmalloc, and squid. Message-ID: <199608271653.JAA24972@phaeton.artisoft.com> In-Reply-To: <199608270744.KAA20433@creator.gu.kiev.ua> from "Andrew Stesin" at Aug 27, 96 10:44:12 am
next in thread | previous in thread | raw e-mail | index | archive | help
> As a result of a pre-2.1.5-release discussion, > I was under impression that libmalloc in FreeBSD-2.1.5 was going > to be a "libPHKmalloc" really, with old libmalloc going elsewhere. > From your message I got an impression that I was wrong. :( > > As for me, I strongly suggest using phkmalloc with Squid > on any platform. Or gnumalloc at least. Default (standard?) > BSD malloc isn't usable. More on this topic... I would like to see the use of an mmap() of /dev/zero replace the use of sbrk() in malloc. For one thing, it would allow us to seperate allocation by thread by establishing sparse allocation zones in the overall process address space. Secondly, the sbrk()-based system recovery of memory assumes too much allocation locality: the recovery of memory (via sbrk() back to the system) can only occur at the end of the allocation region. I would like to see an extention to the mmap() semantics for sparse reclaimation on a per-page basis: When a full page is no longer on use, it would be returned individually to the system. This would resolve the internal heap fragmentation issues of the X server, and of other programs, which do not use a persistance-based locality of allocation model (despite my squawking on the subject, I have only ever seen one persistance-based model implemented without using x86 segment identifiers, and since it was a commercial product, it's unlikely that the code will ever come into common use). Extending the mmap() semantics for page reclaimation also suggests that a "back fill" mechanism will be needed to avoid internal fragmentation (probably not a real problem unless the process normally uses a significant fraction of its available virtual address space). Finally, in the "as long as you're in there" category, it seems that it would be a good idea to support the extension of a mapping region without first unmapping -- a "remmap" in the "realloc" style, if you will. Combining this last with "file size extension" as an FS event to internally cause the mapping to change, at least up to the next page boundry (which has to be mapped anyway because of the VM system's page granularity), should resolve the INN mmap/extension problem. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608271653.JAA24972>