Cygwin malloc tune-up status

Mark Geisert
Tue Sep 29 02:22:33 GMT 2020

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
> ( 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!


More information about the Cygwin-developers mailing list