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 29BA43858D38 for ; Tue, 21 Jul 2020 08:51:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 29BA43858D38 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 06L8owMI087395 for ; Tue, 21 Jul 2020 01:50:58 -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 smtpdsSrKmM; Tue Jul 21 01:50:54 2020 Subject: Re: More (?) steps toward jemalloc within Cygwin DLL To: cygwin-developers@cygwin.com References: <20200630092412.GA3499@calimero.vinschen.de> <064ac876-bb84-6e05-1e46-ba594e03f057@maxrnd.com> <20200703101115.GA3499@calimero.vinschen.de> From: Mark Geisert Message-ID: <75b43adc-ebcd-1d98-bd3e-33b8337f0475@maxrnd.com> Date: Tue, 21 Jul 2020 01:50:55 -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: <20200703101115.GA3499@calimero.vinschen.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.3 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: Tue, 21 Jul 2020 08:51:04 -0000 Corinna Vinschen wrote: >>> 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? > > Not quite. It's bad enough, given how much this slows down multi-threaded > executables, but... > > ...the big problem are dependencies on malloc during Cygwin startup, > especially in fork/exec, so the real challenge is to get the new malloc > still let Cygwin processes start up correctly first time and especially > in fork/exec situations, and to make sure the malloc bookkeeping > survives fork/exec. O.K., understood. > These malloc dependencies sometimes crop up in the weirdest situations, > so that's something to look out for. For instance, using pthread > functions may call malloc as well. If a problem can be solved by > changing another part of Cygwin, don't hesitate to discuss this! Yes, a couple of the malloc packages I'm testing want to allocate locks and TLS slots right off the bat so there's nasty recursion possible. >> 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. > > In the end, we should settle for a single malloc implementation, though. > It doesn't really matter if it's jemalloc, ptmalloc, xymalloc. Almost > all other modern mallocs are faster and better suited for multi-threading > than dlmalloc, *especially* if the above locks can go away. For sure; I didn't make it clear this CYGMALLOC setup is just for testing the different malloc packages. When I stumble across some failing in one of them it's nice to be able to quickly re-run using a different malloc. Here's a question I didn't expect to come up: If it turns out a home-grown wrapper on the Win32 HeapXXX functions performs better (hint: it does, 2.5 to 3 times better) than any malloc package derived from dlmalloc, is there any reason why we ought not use it? Assuming it can be made to work for all those cases you mentioned above, of course. > The only danger here is this: If you manage to get dlmalloc replaced > reliably, you *will* get a pink plush hippo! Oh, gee, that sounds like a really nice reward... Wow, I'm gonna have to do this project now for sure! ..mark