Re: contrib/jemalloc

From: Konstantin Belousov <kostikbel_at_gmail.com>
Date: Thu, 5 Apr 2012 22:09:56 +0300
On Thu, Apr 05, 2012 at 11:55:48AM -0700, Jason Evans wrote:
> On Apr 5, 2012, at 10:52 AM, Konstantin Belousov wrote:
> > On Wed, Apr 04, 2012 at 09:56:45PM -0700, Jason Evans wrote:
> >> I have the current version of jemalloc integrated into libc as contrib/jemalloc:
> >> 
> >> 	http://people.freebsd.org/~jasone/patches/jemalloc_20120404b.patch
> > 
> >> * Are the symbol versioning specifications right, and are the
> >> compatibility symbols for _malloc_options and _malloc_message workable?
> > Why do you manually added __sys_compat() for the symbols ?
> > My reading of the patch shows that you do not change the ABI,
> > and symbols are still at FBSD_1.0 and even in Symbol.map.
> > The 1.3 symbols have different names, without prepended '_' ?
> > Please correct me if I am wrong, but it seems that the __sym_compat()
> > magic is not needed.
> 
> The malloc_conf and malloc_message symbols are new to this
> version of jemalloc, though they are similar in spirit to
> _malloc_options/_malloc_message.
>
> _malloc_options/_malloc_message aren't actually supported by
> this version of jemalloc, but the symbols still need to exist so
> that old applications that were linked with previous releases
> can run. My intention with the __sys_compat() macros was to make
> _malloc_options/_malloc_message available to those applications,
> but to keep from exporting the symbols for use when linking new
> applications. Is this the wrong thing to do, and/or do I misunderstand
> how compat symbols work?

Ah, ok. It is fine then.
So you will have e.g. _malloc_options_at_FBSD_1.0 without default version,
and malloc_options_at_FBSD_1.3 which is default.

> 
> >> * Is the light editing of the jemalloc manual page sufficient? Keeping
> >> the changes minimal will make regular imports less work, but the
> >> result is less tailored to FreeBSD.
> >> 
> > Might be, keep existing but somewhat trimmed malloc(3) page as is, but
> > add the unedited man from contrib as jemalloc(3), xreferencing it from
> > malloc(3) ?
> 
> Hmm, that's an interesting idea. My main concerns with it are the
> amount of redundancy (everything in malloc(3) would be redundant),
> and the decreased visibility of additional functionality in the
> documentation. The TUNING, IMPLEMENTATION NOTES, DEBUGGING MALLOC
> PROBLEMS, and DIAGNOSTIC MESSAGES sections would all be absent from
> malloc(3), thus requiring users to notice the jemalloc(3) cross
> reference to find full documentation.

You may add full sentence pointing out jemalloc(3) and saying
which sections are there. The sentence is naturally fit into
IMPLEMENTATION NOTES in malloc(3).

Received on Thu Apr 05 2012 - 17:10:09 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:25 UTC