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 90B423857C45 for ; Tue, 29 Sep 2020 02:22:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 90B423857C45 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 08T2MW7f034485 for ; Mon, 28 Sep 2020 19:22:32 -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 smtpdWX2DKG; Mon Sep 28 19:22:32 2020 Subject: Re: Cygwin malloc tune-up status To: cygwin-developers@cygwin.com References: <067987e2-e958-b56c-efea-25d827568453@maxrnd.com> From: Mark Geisert Message-ID: Date: Mon, 28 Sep 2020 19:22:33 -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: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, 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, 29 Sep 2020 02:22:36 -0000 Johannes Schindelin wrote: > Hi Mark, > On Thu, 24 Sep 2020, Mark Geisert wrote: >> I've been looking into two potential enhancements of Cygwin's malloc operation >> for Cygwin 3.2. The first is to replace the existing function-level locking >> with something more fine-grained to help threaded processes; the second is to >> implement thread-specific memory pools with the aim of lessening lock activity >> even further. >> >> Although I've investigated several alternative malloc packages, including >> ptmalloc[23], nedalloc, and Windows Heaps, only the latter seems to improve on >> the performance of Cygwin's malloc. Unfortunately using Windows Heaps would >> require fiddling with undocumented heap structures to enable use with fork(). >> I also looked at BSD's jemalloc and Google's tcmalloc. Those two require much >> more work to port to Cygwin so I've back-burnered them for the time being. > > I am just a lurker when it comes to your project, but I wonder whether you > had any chance to look into mimalloc > (https://github.com/microsoft/mimalloc)? I had investigated it in Git for > Windows' context for a while (because nedmalloc, which is used by Git for > Windows, is no longer actively maintained). Hi Johannes, Great minds think alike! Yours is the 3rd pointer I've received on- and off-list towards mimalloc. I had not heard of it before. I've looked into it and have now added it to my back-burnered list. mimalloc looks promising. It's fairly small. It has at least one issue it shares with jemalloc and tcmalloc: initialization code that needs to run before the Cygwin DLL has completely set up a new process' environment. A chicken-and-egg problem, if you will. A solution to that (which I'm pondering) will allow me to test all three malloc alternatives in the future. Thank you to all our users for sharing helpful pointers! ..mark