Re: New malloc ready, take 42

On Fri, 23 Dec 2005, Scott Long wrote:

> Jason Evans wrote:
>
> > Here's a current version of all the changes that are necessary for
> > jemalloc to go in to the tree:
> >
> >     http://people.freebsd.org/~jasone/jemalloc/patches/
> > jemalloc_20051222c.diff
> >
> > This patch includes (roughly):
> >
> > 1) Fix gensnmptree bug (missing variable initialization).  I emailed
> > the maintainer, Hartmut Brandt, about this today, and am awaiting a  reply.
> >
> > 2) Fix kldxref bug (assumes allocation is adequately aligned).  This
> > needs to be committed along with (5), since the fix uses  posix_memalign().
> >
> > 3) Move calloc() from calloc.c to malloc.c (enables better statistics
> > gathering).
> >
> > 4) Add _malloc_{pre,post}fork(), for use by threading libraries.
> >
> > 5) Replace malloc(), calloc(), realloc(), and free().  Add
> > posix_memalign().
> >
> > I'd like to commit (3) and (4) first, so that we have a version of
> > phkmalloc in the cvs repository that is API-compatible with libc as  it
> > will be after jemalloc is committed.  This will make it easier to  swap
> > the phkmalloc code in, should we wish to do further benchmarking  or
> > regression testing at some point in the future.  Poul-Henning has
> > agreed with this in principle, though I haven't yet supplied him with
> > diffs for only (3) and (4).
> >
> > So, how about it?  Is jemalloc ready to go in now?
> >
> > Thanks,
> > Jason
>
> I think that this is overall a good plan.  Two things need to be
> stressed, since they will quickly become FAQs.  First is that phkmalloc
> and jemalloc won't be interchangable at runtime, like the threading
> libraries are.  Second is that amd64 will be stuck without working X
> until the 6.9/7.0 stuff gets in the tree, and people should be well
> aware of this.
>
> Another thing that I worry about is complex library scenarios where you
> might have different versions of libc getting pulled into the same
> process by different library dependencies.  This could turn into a big
> headache that is only solvable by telling people to wipe out their
> entire ports collection and rebuild from scratch.  Does this warrant a
> library version bump now (as much as I really don't want to advocate
> this)?

Please, no more library version bumps (ever, hopefully).  That's
what we have library versioning for.  Also, I don't see how
this changes external APIs (ABI) any more than we've done in
the past when adding interfaces.  We're adding posix_memalign()
and the __malloc_foofork() interfaces for our thread libraries.

-- 
DE