Mingw port, status update
mh+jemalloc at glandium.org
Thu Apr 12 07:15:42 PDT 2012
On Thu, Apr 12, 2012 at 03:47:53PM +0200, Mike Hommey wrote:
> 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)
> - 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.
More information about the jemalloc-discuss