Re: contrib/jemalloc

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).