From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 145E2198005 for ; Tue, 26 Feb 2013 16:40:39 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 75839E06C0; Tue, 26 Feb 2013 16:40:36 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 81CB3E064C for ; Tue, 26 Feb 2013 16:40:35 +0000 (UTC) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: floppym) by smtp.gentoo.org (Postfix) with ESMTPSA id A212833DD10 for ; Tue, 26 Feb 2013 16:40:34 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id c10so4643736ieb.17 for ; Tue, 26 Feb 2013 08:40:32 -0800 (PST) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.50.219.234 with SMTP id pr10mr5710407igc.26.1361896832679; Tue, 26 Feb 2013 08:40:32 -0800 (PST) Received: by 10.64.102.66 with HTTP; Tue, 26 Feb 2013 08:40:32 -0800 (PST) In-Reply-To: <512CB9B8.9060308@gentoo.org> References: <512CB9B8.9060308@gentoo.org> Date: Tue, 26 Feb 2013 11:40:32 -0500 Message-ID: Subject: Re: [gentoo-dev] Evaluating a new malloc() From: Mike Gilbert To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 212ce734-451a-4484-80ed-f7c906f3aa4b X-Archives-Hash: abe3d70cfe578c82e280e99b5cb08778 On Tue, Feb 26, 2013 at 8:33 AM, Richard Yao wrote: > Unless a significant issue is found in jemalloc itself, I do not see any > reason to continue using glibc's ptmalloc over jemalloc. As far as I > know, FreeBSD, NetBSD, Facebook and others are using jemalloc, so I > expect that no significant issues will be found. jemalloc will still > needs testing before we can consider it. Doing good tests is hard, so I > would like to crowd source ideas on the appropriate way to test a malloc > implementation from the list. My expectation is that people on the list > will collectively think of better ideas than I could on my own. > > With that said, what do people think? > Just want to point out a problem I have personally encountered with another alternate malloc (tcmalloc). Essentially, when you combine libGL.so from nvidia-drivers with tcmalloc, the Google Chrome web browser fails to properly close its worker processes. https://bugs.gentoo.org/show_bug.cgi?id=413637 This thread on the Chromium developer list goes into more detail: https://groups.google.com/a/chromium.org/forum/#!msg/chromium-dev/uLf5l669dCk/MXXfJfIvDF0J The main concern I would have is that upstream developers (like nvidia) are unlikely to test their software with an alternate malloc implementation, so we could end up running into some very subtle bugs. Are the saved cycles really worth it?