cc me

I think this is going to require further discussion before merging since there's some disagreement about how we should treat allocations that require special alignment.

My preference is:

• Our internal allocator API takes alignment paramenters
• By default it is backed by jemalloc, which aligns as requested
• The malloc implementation can be replaced at compile time for those that don't want or can't use jemalloc
• malloc is not required to obey alignment requests, and therefore the default exchange heap allocator provides no alignment guarantees beyond what is specced for malloc
• Code that must guarantee alignment is welcome to override the allocator parameter on the boxes it creates with an allocator that gives them the alignment they need

It's possible to build an allocator respecting alignment around malloc, realloc and free by adding padding. Rust isn't going to be able to provide portable SIMD types or an alignment attribute if type alignment requirements aren't respected, so I think it's important.

It shouldn't be necessary to rewrite all of the standard collections in order to use types with alignment requirements higher than the platform's choice. The malloc family of functions is supposed to support the alignment necessary for any built-in C type, but it's a legacy claim - no one wants to raise it above 16 bytes because it would add a lot of overhead. The highest alignment required for a built-in C type seems like a bad thing to leak as a user-facing detail into Rust's semantics, especially when platforms ignore the requirement.

The exchange allocator itself has no realloc function, so it can be implemented in terms of posix_memalign and free. On Windows, _aligned_malloc, _aligned_realloc and _aligned_free are all available in the C runtime.

The missing piece on *nix operating systems is an aligned realloc function, but calling posix_memalign and using memcpy is a viable workaround. It loses the in-place realloc optimization, but C++ std::vector implementations are plagued by this issue so it's nothing new (pardon the pun).

The malloc implementation can be replaced at compile time for those that don't want or can't use jemalloc

I don't really think this is a pressing need. I don't think there's a use case for using libc malloc instead of jemalloc, because it's portable to the same platforms as Rust. Debian and Fedora want us to provide an --external-jemalloc switch making use of a libjemalloc.so / libjemalloc.a provided by the system. They'll want the same thing for LLVM, libuv and any other third party dependency including libbacktrace and compiler-rt.

Statically linking jemalloc with mingw-w64 is broken. It could be dynamically linked there for now or left out... https://sourceforge.net/p/mingw-w64/bugs/395/

I discovered a workaround for the Windows issue, which is passing --enable-lazy-lock to avoid the global initialization. There's no harm in passing this flag so it's not even a hack. I've reported this as a mingw-w64 issue (since that appears to be the source) along with a jemalloc issue for good measure.