svn commit: r286866 - in head: contrib/jemalloc contrib/jemalloc/doc contrib/jemalloc/include/jemalloc contrib/jemalloc/include/jemalloc/internal contrib/jemalloc/src include lib/libc/gen lib/libc/...

[Jilles Tjoelker]

On Tue, Aug 18, 2015 at 02:28:25PM -0700, Jason Evans wrote:
> On Aug 18, 2015, at 2:17 PM, Jilles Tjoelker <jilles at stack.nl> wrote:
> > On Tue, Aug 18, 2015 at 09:49:44PM +0200, Jan Beich wrote:
> >> Jason Evans <jasone at freebsd.org> writes:
> >>>>> +  - Remove the *allocm() API, which is superseded by the *allocx() API.
> >>>> Symbol.map and manpages haven't been updated.

> > You can't really remove anything from Symbol.map files, since that
> > breaks binary compatibility for applications that used the removed
> > symbols. Such breakage usually crashes the application if and when it
> > attempts to use a removed symbol. To avoid the breakage, wrappers
> > invoking the new APIs should be provided; using some special symver
> > directives, it is possible to prevent linking new applications against
> > the obsolete symbols.

> *allocm() compatibility functions are in place, so I think this is
> correctly sorted out.  Jan also pointed out missing entries for
> sdallocx() in a previous email, which I've already committed the fix
> for (r286872).

Sorry, I didn't read the code sufficiently thoroughly. The compatibility
code looks good, now I see it.

> > A corollary is that experimental APIs should not be added to Symbol.map.
> > It may be better for developers that want to use experimental APIs to
> > build jemalloc themselves, or to use jemalloc from ports (although such
> > a port doesn't seem to exist, currently).

> Yes, exposing *allocm() was a big mistake. :(

Does that mean that mallocx() and friends will stay for a long time?

-- 
Jilles Tjoelker