From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from m0.truegem.net (m0.truegem.net [69.55.228.47]) by sourceware.org (Postfix) with ESMTPS id CC11A3858D34 for ; Fri, 3 Jul 2020 06:57:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org CC11A3858D34 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=maxrnd.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=mark@maxrnd.com Received: (from daemon@localhost) by m0.truegem.net (8.12.11/8.12.11) id 0636vsBj090369 for ; Thu, 2 Jul 2020 23:57:54 -0700 (PDT) (envelope-from mark@maxrnd.com) Received: from 162-235-43-67.lightspeed.irvnca.sbcglobal.net(162.235.43.67), claiming to be "[192.168.1.100]" via SMTP by m0.truegem.net, id smtpdibR2a8; Thu Jul 2 23:57:51 2020 Subject: Re: More (?) steps toward jemalloc within Cygwin DLL To: cygwin-developers@cygwin.com References: <20200630092412.GA3499@calimero.vinschen.de> From: Mark Geisert Message-ID: <064ac876-bb84-6e05-1e46-ba594e03f057@maxrnd.com> Date: Thu, 2 Jul 2020 23:57:52 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.4 MIME-Version: 1.0 In-Reply-To: <20200630092412.GA3499@calimero.vinschen.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: cygwin-developers@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin core component developers mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2020 06:57:56 -0000 Hi Corinna, Corinna Vinschen wrote: > On Jun 16 02:16, Mark Geisert wrote: >> I'm just putting a flag down on this new (to me) territory. If somebody >> else has claimed this project already, let me know and I'll shove off. > > No, please. Just keep on working on that. If you manage to get jemalloc > working and replacing dlmalloc, this would be really great. Super. >> It wasn't much trouble to build a jemalloc.lib and statically link it into >> the Cygwin DLL when the latter is built. I'm still learning which jemalloc >> configure options are required in order to get complete test coverage and to >> initialize properly within cygwin1.dll. >> >> I'm currently using the "supply your own malloc" mechanism provided by >> Cygwin's malloc_wrapper.cc to overlay the usual dlmalloc-sourced functions >> with replacements from jemalloc. I suspect there will be allocation >> collisions ahead... I've had to rethink the above a bit. > The real problem here is this: > > __malloc_lock (); > dl_foo_function (); > __malloc_unlock (); > > This locking is what makes our dlmalloc even slower in multi-threaded > scenarios because it disallows using malloc/free calls concurrently. > > If you get jemalloc working, it would be nice in itself, but the main > improvement would be the ability to get rid of these __malloc_lock/ > __malloc_unlock brackets. Thanks for reminding me of that aspect of Cygwin's current malloc. The malloc implementation has seemed to be bulletproof for many years so I guess the function-level locking is the only drawback of note? I've found that jemalloc would add 500kB to cygwin1.dll and it also seems difficult to get working, at first blush at least. I've switched to a plug-in sort of implementation that allows one to choose among several malloc packages: "original", dlmalloc (w/ internal locking), ptmalloc[23], nedalloc, jemalloc, and a Windows Heap wrapper. Perhaps tcmalloc in the future. One sets an environment variable CYGMALLOC= before launching a program and that malloc implementation is used. This should make testing and benchmarking the various choices possible. I don't expect big improvements in individual programs (unless they are stress testing), but something like a large configure or build should give more useful data. ..mark