Date: Fri, 23 Dec 2005 08:24:45 -0500 (EST) From: Daniel Eischen <deischen@freebsd.org> To: Scott Long <scottl@samsco.org> Cc: freebsd-current@freebsd.org, Jason Evans <jasone@freebsd.org> Subject: Re: New malloc ready, take 42 Message-ID: <Pine.GSO.4.43.0512230815590.28572-100000@sea.ntplx.net> In-Reply-To: <43ABC3E2.1030108@samsco.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.43.0512230815590.28572-100000>