Date: Thu, 5 Apr 2012 11:55:48 -0700 From: Jason Evans <jasone@canonware.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: jasone@freebsd.org, current@freebsd.org Subject: Re: contrib/jemalloc Message-ID: <294B61A0-72E4-4014-8B13-ED5259112E61@canonware.com> In-Reply-To: <20120405175244.GZ2358@deviant.kiev.zoral.com.ua> References: <431CB493-836B-4DF4-AC42-A7C6ABF7DE3E@canonware.com> <20120405175244.GZ2358@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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: >>=20 >> = http://people.freebsd.org/~jasone/patches/jemalloc_20120404b.patch >=20 >> * 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? >> * 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. >>=20 > 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. Thanks, Jason=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?294B61A0-72E4-4014-8B13-ED5259112E61>