From owner-freebsd-current@FreeBSD.ORG Thu Apr 5 19:10:09 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43015106566B; Thu, 5 Apr 2012 19:10:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id C68D38FC18; Thu, 5 Apr 2012 19:10:07 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q35J9vvi048556; Thu, 5 Apr 2012 22:09:57 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q35J9uV8028586; Thu, 5 Apr 2012 22:09:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q35J9uRl028585; Thu, 5 Apr 2012 22:09:56 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 5 Apr 2012 22:09:56 +0300 From: Konstantin Belousov To: Jason Evans Message-ID: <20120405190956.GB2358@deviant.kiev.zoral.com.ua> References: <431CB493-836B-4DF4-AC42-A7C6ABF7DE3E@canonware.com> <20120405175244.GZ2358@deviant.kiev.zoral.com.ua> <294B61A0-72E4-4014-8B13-ED5259112E61@canonware.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VlzON83CwBK3K2mt" Content-Disposition: inline In-Reply-To: <294B61A0-72E4-4014-8B13-ED5259112E61@canonware.com> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: jasone@freebsd.org, current@freebsd.org Subject: Re: contrib/jemalloc X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Apr 2012 19:10:09 -0000 --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--