Maybe consider rpmalloc

[Mark Geisert]

Teemu Nätkinniemi wrote:
> Thanks a lot for looking into this issue! I wonder if there are any
> other applications affected by this?

We have several examples by now.  All are (relatively) long-lasting apps, with 
high to very high memory allocation churn, often multi-threaded.  I believe some 
specific rsync operations hit this.  Achim reported a zstd operation that 
exhibited the symptoms.  And I've been attempting to get a working replacement for 
Cygwin's malloc for some time but every malloc I've tested, several of them, 
exhibits similar symptoms: excessive time being spent in ntdll.dll presumably 
supporting the memory operations.

Your rpmalloc "hack" is interesting in that you aren't using Cygwin's mmap() 
underneath the malloc routines; you're calling Windows VM ops directly.  Not sure 
yet what all the implications are.

I need to identify what's being hit within ntdll.dll.  Is it one or two routines, 
or just hot locks.  So that means getting the correct PDB file from the MS Symbol 
Server and working with Windows tools I'm unfamiliar with.  Sigh, in an earlier 
life I had a gdb that we'd taught how to work with PDB files; dunno if I could 
resurrect that.  Profiling the Cygwin DLL itself, call profiling I mean, might 
lead somewhere as well.

Lots of plausible directions to go...
Cheers,

..mark