From owner-freebsd-current@FreeBSD.ORG Mon Dec 26 18:26:58 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 39AEE16A41F for ; Mon, 26 Dec 2005 18:26:58 +0000 (GMT) (envelope-from jasone@freebsd.org) Received: from lh.synack.net (lh.synack.net [204.152.188.37]) by mx1.FreeBSD.org (Postfix) with ESMTP id CE7CE43D49 for ; Mon, 26 Dec 2005 18:26:57 +0000 (GMT) (envelope-from jasone@freebsd.org) Received: by lh.synack.net (Postfix, from userid 100) id 997EE5E48E4; Mon, 26 Dec 2005 10:26:57 -0800 (PST) Received: from [192.168.168.203] (moscow-cuda-gen2-68-64-60-20.losaca.adelphia.net [68.64.60.20]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by lh.synack.net (Postfix) with ESMTP id 8EBFA5E48C4; Mon, 26 Dec 2005 10:26:48 -0800 (PST) In-Reply-To: <20051226101825.GA92082@samodelkin.net> References: <20051226101825.GA92082@samodelkin.net> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Jason Evans Date: Mon, 26 Dec 2005 10:26:45 -0800 To: Max Khon X-Mailer: Apple Mail (2.746.2) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on lh.synack.net X-Spam-Level: * X-Spam-Status: No, score=1.8 required=5.0 tests=RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: freebsd-current@freebsd.org Subject: Re: New malloc ready, take 42 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: Mon, 26 Dec 2005 18:26:58 -0000 On Dec 26, 2005, at 2:18 AM, Max Khon wrote: > > Do you plan to provide public API for malloc arenas > similar to SGI amalloc(3)? > > http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi? > coll=0650&db=man&fname=/usr/share/catman/p_man/cat3p/amallinfo.z I hadn't planned to do so. It's not too hard to think of scenarios in which manual management of arenas might be useful, but adding non- standard public APIs to libc is something that I'm reluctant to do unless there is a compelling reason to do so. Arena-specific APIs would work well with jemalloc, but they may not make sense for whatever comes after jemalloc, yet we'd be stuck with supporting the APIs. In fact, if I were making API changes to non-standard libc interfaces, the first thing I'd do would be to remove reallocf(3), or at least rename it to reallocf_np(). Are there compelling use cases you can think of that might sway us toward providing malloc arena APIs? Thanks, Jason