New malloc ready, take 42
Daniel Eischen
deischen at freebsd.org
Fri Dec 23 05:24:49 PST 2005
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
More information about the freebsd-current
mailing list