More (?) steps toward jemalloc within Cygwin DLL

[Corinna Vinschen]

Hi Mark,

On Jun 16 02:16, Mark Geisert wrote:
> I'm just putting a flag down on this new (to me) territory.  If somebody
> else has claimed this project already, let me know and I'll shove off.

No, please.  Just keep on working on that.  If you manage to get jemalloc
working and replacing dlmalloc, this would be really great.

> It wasn't much trouble to build a jemalloc.lib and statically link it into
> the Cygwin DLL when the latter is built.  I'm still learning which jemalloc
> configure options are required in order to get complete test coverage and to
> initialize properly within cygwin1.dll.
> 
> I'm currently using the "supply your own malloc" mechanism provided by
> Cygwin's malloc_wrapper.cc to overlay the usual dlmalloc-sourced functions
> with replacements from jemalloc.  I suspect there will be allocation
> collisions ahead...

The real problem here is this:

  __malloc_lock ();
  dl_foo_function ();
  __malloc_unlock ();

This locking is what makes our dlmalloc even slower in multi-threaded
scenarios because it disallows using malloc/free calls concurrently.

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.

> One question has popped up though.  I see from the docs that if one wants
> jemalloc to run thread-aware, it wraps pthread_create() to find out when the
> app has gone from single-threaded to multi-threaded.  But in Cygwin's case
> we'll additionally need to consider cygthreads, won't we?

Yes, and the pthread_create call should not be performed in jemalloc
if possible.  The best solution is probably letting jemalloc always
work under threading assumtion, right from the start.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer