Re: FreeBSD malloc.c, -lmalloc, and squid.

> 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.