New malloc for glibc-2.3

[Wolfram Gloger <wg at malloc dot de>]

Hi,

I've just placed at

http://www.malloc.de/libc/libc.malloc.tar.gz

the port of ptmalloc2, or rather Doug Lea's malloc-2.7.0 for multiple
threads and glibc's special features.  It is meant to be unpacked in
libc/malloc, and Makefile.glibc.diff should be applied to
libc/malloc/Makefile.  Patches for the source files would be larger
than the archive.  A diff from Doug Lea's original sources to malloc.c
is still somewhat readable, however, which is also why I would favour
to keep the non-standard formatting.

I've added a new testcase for malloc_{get,set}_state, but it really
can only test for the most obvious errors.  Porting malloc_set_state
for the new malloc version was... well, interesting.  I've tested
several old versions of GNU Emacs, and they seem to work fine (one
can't test it with "ld-linux.so.2 --library-path ... /usr/bin/emacs"
though, a chroot or real installation is required).  Someone should
test XEmacs because it is also a user of malloc_set_state AFAIK.

The major new feature is "fastbins" for chunks at most 80bytes long.
Long sequences of free(small);...malloc(small); should go much faster
now.  There are also reports from Mozilla that fragmentation is
better, sometimes much better, than with the previous versions.  I've
found that for random allocation sequences (not very realistic), the
new version is a bit slower than the old one.

With regards to multiple threads, nothing much should have changed.
Multiple arenas are generated as needed, so lock contention shouldn't
be an issue.

Due to popular demand (e.g. from Hurd people), I've exposed the
internal interface to arenas (similar to mmalloc), you can allocate a
new arena with

  m = _int_new_arena(initial_size);

(m is an opaque pointer, initial_size is just a hint as to how large
an allocation will follow) and then use it like

  ptr = _int_malloc(m, size);
  _int_free(m, ptr);
  ...

(Don't like the minimalistic interface or the _int_ prefix?  I'm open
to suggestions.)  However, in the presence of threads, you have to or
rather can do your own locking when you use your own arena(s).  You
could also use this in a signal handler, for example.

Some things will have to change.  I am definitely planning for the use
of fast inline spinlocks rather than pthread mutexes, see my next
mail.  Comments very welcome.  I'll be away from the net next Tuesday
through Friday.

Regards,
Wolfram.