Date: Thu, 5 Apr 2012 22:09:56 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Jason Evans <jasone@canonware.com> Cc: jasone@freebsd.org, current@freebsd.org Subject: Re: contrib/jemalloc Message-ID: <20120405190956.GB2358@deviant.kiev.zoral.com.ua> In-Reply-To: <294B61A0-72E4-4014-8B13-ED5259112E61@canonware.com> References: <431CB493-836B-4DF4-AC42-A7C6ABF7DE3E@canonware.com> <20120405175244.GZ2358@deviant.kiev.zoral.com.ua> <294B61A0-72E4-4014-8B13-ED5259112E61@canonware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--VlzON83CwBK3K2mt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: > >>=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. >=20 > 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@FBSD_1.0 without default version, and malloc_options@FBSD_1.3 which is default. >=20 > >> * 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) ? >=20 > 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). --VlzON83CwBK3K2mt Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk997gQACgkQC3+MBN1Mb4imxwCfT0xdAT6UBsy1oGOLao47UX/K GIQAoISDKU/WKMBWMB85woWKmPQ396T5 =1F4J -----END PGP SIGNATURE----- --VlzON83CwBK3K2mt--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120405190956.GB2358>