Re: Cygwin malloc tune-up status

[Mark Geisert <mark@maxrnd.com>]

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