Subject: Re: Heads up: malloc() changed
To: None <current-users@NetBSD.org>
From: Andrew Doran <ad@NetBSD.org>
List: current-users
Date: 10/09/2007 02:14:45
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