Add a port of mimalloc, a fast and scalable multithreaded allocator

[kripken]

The new allocator can be used with -sMALLOC=mimalloc.

Some numbers comparing native, wasm+dlmalloc, and wasm+mimalloc:

Lower is better there. dlmalloc does quite poorly here, getting actually slower with
each additional core, because the lock contention is much large than the actual work the
(very artificial) benchmark does. That's in log scale because of dlmalloc, here is a normal
scale of native vs wasm+mimalloc:

With mimalloc, wasm scales the same as natively: more cores keeps helping, up to 4
cores on this machine (which has 4 cores).

mimalloc is significantly larger than dlmalloc, however, so we definitely do not want it
on by default. It also uses more memory, both because of how mimalloc works and also
due to #20645 Likely many multithreaded applications won't need it. But it is is a
good option to have, for applications that have significant amounts of contention on
malloc/free across threads.

Design-wise, this layers mimalloc on top of emmalloc. emmalloc functions as the
"system allocator", which is more powerful than just using raw sbrk - sbrk can't free
holes in the middle, for example.

Code-wise, all of system/lib/mimalloc is unchanged from upstream (see README.emscripten)
except for an ifdef or two, and then the new backend which is in
system/lib/mimalloc/src/prim/emscripten/prim.c. That file has more comments explaining
the design of the port.

A new test is added which is also usable as a benchmark, test/other/test_mimalloc.cpp,
which is where the numbers above come from.

Fixes #18369

[sbc100]

This looks like it can all be on a single line

[sbc100]

You can remove this line I think

[kripken]

Unfortunately, not. Other libraries do this too. Without this it errors, as it uses this internally it seems. That might be worth working on, though, as it is surprising to me too.

[sbc100]

Elsewhere in this file we tend to put each + in its on statement. I think that will make it less messy:

e.g.:

    libc_files += files_in_path(                                                                     
        path='system/lib/libc/musl/src/legacy',                                                      
        filenames=['getpagesize.c', 'err.c'])                                                        
                                                                                                     
    libc_files += files_in_path(                                                                     
        path='system/lib/libc/musl/src/linux',                                                       
        filenames=['getdents.c', 'gettid.c', 'utimes.c'])                                            
                                                                                                     
    libc_files += files_in_path(                                                                     
        path='system/lib/libc/musl/src/sched',                                                       
        filenames=['sched_yield.c'])                                                                 
                                                                                                     
    libc_files += files_in_path(                                                                     
        path='system/lib/libc/musl/src/exit',                                                        
        filenames=['_Exit.c', 'atexit.c', 'at_quick_exit.c', 'quick_exit.c'])                        
                                                                                                     
    libc_files += files_in_path(                                                                     
        path='system/lib/libc/musl/src/ldso',                                                        
        filenames=['dladdr.c', 'dlerror.c', 'dlsym.c', 'dlclose.c'])       
    ```

[dschuff]

I think I may have asked this before, but is there a reason we can't just make the allocators regular static libs and select by using -lemmalloc or -lmimalloc?

For one thine the actually name of the underlying malloc isn't always that short name. For example it could be more like ``libemmalloc-mt-debug.a`. I think maybe we have some logic map the short name to the long name but its a bit too magical for my liking.

OK yeah, I'm not a big fan of magical -s flags that do nothing but link libraries, but had forgotten about all the named variants, so I guess we can't really avoid some magic for those libraries. And if there's going to be magic, I think it makes sense to make it obvious that this is emscripten-specific magic (as opposed to adding magic to a mechanism that is otherwise simple and transparent and would probably be surprising to users if there were magic).

We have run into issues before where folks specify -lc and then the system adds a default one too.

When users are specifying -lc is it because they are actually providing their own libc and want to avoid linking ours? or is it just carried over from some other system and doesn't really reflect a desire for non-default behavior? If the latter, then maybe we should just ignore -lc since we already have magical libc behavior. If the former... could that ever actually work?

[sbc100]

I think I may have asked this before, but is there a reason we can't just make the allocators regular static libs and select by using -lemmalloc or -lmimalloc?

For one thine the actually name of the underlying malloc isn't always that short name. For example it could be more like ``libemmalloc-mt-debug.a`. I think maybe we have some logic map the short name to the long name but its a bit too magical for my liking.

OK yeah, I'm not a big fan of magical -s flags that do nothing but link libraries, but had forgotten about all the named variants, so I guess we can't really avoid some magic for those libraries. And if there's going to be magic, I think it makes sense to make it obvious that this is emscripten-specific magic (as opposed to adding magic to a mechanism that is otherwise simple and transparent and would probably be surprising to users if there were magic).

We have run into issues before where folks specify -lc and then the system adds a default one too.

When users are specifying -lc is it because they are actually providing their own libc and want to avoid linking ours? or is it just carried over from some other system and doesn't really reflect a desire for non-default behavior? If the latter, then maybe we should just ignore -lc since we already have magical libc behavior. If the former... could that ever actually work?

It was that latter. And yes, I think we made it work my somehow ignore the -lc and/or replacing it with our magic libc lookup.

[kripken]

I forgot to say, I ran mimalloc on core2 and while there are failures, none seemed like blockers. For example sanitizers will require followup work (people can sanitize with dlmalloc for now), and things like mallinfo are not supported, and some tests fail because mimalloc needs more memory. I saw no logic errors, in other words.

[kripken]

Friendly ping @sbc100 @dschuff - any other comments or does this look good? (I may wait on landing it for #20704 which makes it more efficient, but I'd like to know it's ready to land).

[dschuff]

otherwise LGTM