Hi Bernd,

On Sat, Oct 06, 2007 at 09:14:54AM +0200, Bernd Ernesti wrote:

> > I have tested this on and off for a couple of months on i386 and amd64. Some
> > 3rd party programs could fail due to bad behaviour that they got away with
> > under the old allocator (phkmalloc). I found 1 instance of this within the
> > NetBSD tree - in lint, which is a bit ironic. It's possible that there might
> > be some glitches on non-x86 platforms, since they have not been tested.
> 
> I saw the benchmarks with it, but can't remember if I saw one where it was
> a comparision between the two malloc implementaions. Was there one and how
> much did it help?

There are some details here:

	http://people.freebsd.org/~jasone/jemalloc/

The one downside to jemalloc that I saw (some months back) was that it used
more virtual address space than phkmalloc. However, the resident set was
similar so it is not a big deal. It seems to have improved in that respect.
As for single threaded performance, from what I have seen it it usually very
close to or faster than phkmalloc (although YMMV, terms and conditions
apply, etc).
 
> Hmmm, do we need to bump the libc minor version or is it not needed?
> It would help to easily find out if one is using the new malloc and as
> you said there are maybe some behaviour changes which may varent that
> we bump the version.

I think you are right; the posix_memalign() call has been added but it is
not exported via the header files yet. But the interface is there.
 
> Do you have an example of such a bad behaviour?

Just typical use-after-free problems. Sometimes you get lucky and things
work; jemalloc might return the memory to the system or allocate it to
something else, and in that case you are unlucky..

Thanks,
Andrew