From owner-freebsd-hackers Sun Dec 17 15: 3:21 2000 From owner-freebsd-hackers@FreeBSD.ORG Sun Dec 17 15:03:18 2000 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from gw.nectar.com (gw.nectar.com [208.42.49.153]) by hub.freebsd.org (Postfix) with ESMTP id 1199137B400 for ; Sun, 17 Dec 2000 15:03:18 -0800 (PST) Received: from hamlet.nectar.com (hamlet.nectar.com [10.0.1.102]) by gw.nectar.com (Postfix) with ESMTP id 09244193E1; Sun, 17 Dec 2000 17:03:17 -0600 (CST) Received: (from nectar@localhost) by hamlet.nectar.com (8.11.1/8.9.3) id eBHN3GG63271; Sun, 17 Dec 2000 17:03:16 -0600 (CST) (envelope-from nectar@spawn.nectar.com) Date: Sun, 17 Dec 2000 17:03:16 -0600 From: "Jacques A. Vidrine" To: Chris Costello Cc: hackers@FreeBSD.ORG Subject: Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c) Message-ID: <20001217170316.A63227@hamlet.nectar.com> References: <200012172110.eBHLAfU46563@freefall.freebsd.org> <20001217151509.A63051@hamlet.nectar.com> <20001217151735.D54486@holly.calldei.com> <20001217153129.B63080@hamlet.nectar.com> <20001217153656.F54486@holly.calldei.com> <20001217155648.C63080@hamlet.nectar.com> <20001217160442.H54486@holly.calldei.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20001217160442.H54486@holly.calldei.com>; from chris@calldei.com on Sun, Dec 17, 2000 at 04:04:42PM -0600 X-Url: http://www.nectar.com/ Sender: nectar@nectar.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Dec 17, 2000 at 04:04:42PM -0600, Chris Costello wrote: > On Sunday, December 17, 2000, Jacques A. Vidrine wrote: > > I may have missed your point ... or maybe you are just agreeing with > > what I wrote. For this particular implementation of free, you get the > > following for `free(foo)' when foo == NULL: > > > > function call and stack overhead for free() > > lock something if we are threaded > > pointer assignment > > increment > > compare and branch > > function call and stack overhead for ifree() > > compare and branch > > unwind ifree() > > More stuff if HAVE_UTRACE > > decrement > > unlock something > > unwind free() > > > FreeBSD's free() is not optimized for freeing NULL pointers. Not > > that I think it should be -- as I said, that would be silly. > > The code I pasted _was_ FreeBSD's code, Yes, I know. > and it does optimize for freeing NULL pointers. How so? Many instructions that are unnecessary are executed when you call free with a NULL pointer (read what I wrote above). To optimize for this case would be to check whether or not the pointer was NULL before doing anything else. This is kinda silly, who the hell started this thread? :-) > You can still check for the pointer if you wish, before you call > free(). Of course. And it seems a prudent thing to do if NULL pointers are not uncommon in the code path. I hate to give up a line for if (data) free(data); but neither do I care for ``if (data) free(data);''. I guess if I were writing several statements like that in a single file, I would consider the macro route (e.g. xfree). -- Jacques Vidrine / n@nectar.com / jvidrine@verio.net / nectar@FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message