Mingw port, status update

[Mike Hommey]

On Thu, Apr 12, 2012 at 03:47:53PM +0200, Mike Hommey wrote:
> Hi,
> 
> Here's where I am standing with the mingw port: it passes the test
> suite, and repeated running of test/thread_arena (which, until mutexes
> were actually implemented, randomly failed :) )
> 
> The patches I'm currently using on top of current dev branch (5ff709c)
> are:
> - Replace %z in format strings with configure-time determined printf
>   length modifier.
> - Use a stub replacement and disable dss when sbrk is not supported.
> - Call base_boot before chunk_boot0.
> 
> On top of these, I have a patch adding win32 support:
>  configure.ac                                     |   25 ++++++-
>  include/jemalloc/internal/jemalloc_internal.h.in |   11 ++-
>  include/jemalloc/internal/mutex.h                |   16 +++-
>  include/jemalloc/internal/tsd.h                  |   44 +++++++++++
>  src/arena.c                                      |    2 +
>  src/chunk_dss.c                                  |    5 +-
>  src/chunk_mmap.c                                 |   87 +++++++++++++++++-----
>  src/jemalloc.c                                   |   30 +++++++-
>  src/mutex.c                                      |   10 ++-
>  src/util.c                                       |    5 +-
>  test/rallocm.c                                   |    9 +++
>  11 files changed, 210 insertions(+), 34 deletions(-)
> 
> The remaining things to do:
> - Build with the right extensions, the right flags, etc.
> - Replace the madvise calls instead of removing them.
> - Handle thread creation (equivalent to pthread_atfork)
> - Call cleanup functions for tsd.
> 
> As mentioned in another message, the latter is tricky, as it basically
> requires that all cleanup functions are called from a single point, so
> we need to decide how to group them.
> 
> Equivalent to pthread_atfork is not a given, because while it is "easy"
> to be notified of the creation of a thread through the dllmain entry
> point (which means jemalloc needs to be a shared library, btw, because
> executables don't have that), that only gives one half of the equation:
> in the child, after thread creation. I haven't found a way to run
> something in the parent before thread creation (at least yet).
> 
> For the madvise calls, I'm considering writing a "generic" function to
> be used from both places madvise is called, I just need to know where to
> put that (it would kind of make sense in chunk_mmap.h or chunk.h), and
> what to name it.
> 
> This will only bring mingw support. MSVC will probably require more
> tweaking, especially in the build system.

Something else I wanted to mention. The init_lock has to be initialized
with malloc_mutex_init. It doesn't seem safe to call it from
malloc_init_hard, so it would be  necessary to use a constructor
function. While this is easy to do with mingw
(__attribute__((constructor))), there is no equivalent in MSVC besides,
apparently, hacks with sections or C++ static initializers. Or, using
DllMain, which mandates that jemalloc is a shared library.

Mike