Switch to direct HeapAlloc on Windows when not using jemalloc

[retep998]

This removes our dependency on the CRT for memory allocation.

[rust-highfive]

r? @pcwalton

(rust_highfive has picked a reviewer for you, use r? to override)

[retep998]

I would provide a really neat implementation using HeapSummary, but I don't know of an easy way to print things from inside this crate.

[eddyb]

Is there no easy way to write to stdout on windows without the CRT?

[retep998]

Well I could directly WriteConsole to GetStdHandle(STD_OUTPUT_HANDLE) but then I'd have to format numbers into strings without std.

[alexcrichton]

I think it's fine to leave this as-is, I don't think it's really worth adding an implementation unless it's easy (this is very rarely called)

[petrochenkov]

Did you consulted with the implementations of malloc/free/realloc in crt\src\{malloc, free, realloc}.c?
They seem to perform some additional checks and actions (besides calling hooks) comparing to this implementation, especially realloc.

[nagisa]

They seem to perform some additional checks and actions

Looks mostly like optimisations, backward compatibility, crt specifics, and locking (in case NO_SERIALIZE heap is misused?) code. Since this code currently can only be used by the standard library, I feel its fine to go for the simple approach.

[alexcrichton]

Thanks @retep998! It's my impression that the CRT malloc functions and friends just call these underlying functions, right? I looked around and didn't really find a definitive answer on why we'd want to favor these over malloc, and having to deal with alignment ourselves is always a pain.

Also, could you elaborate a little more on why we want to eliminate the dependency on the CRT? It sounds like issues like #26258 mean that it'd be nice to not have to deal with it altogether, but I just want to make sure we've got a good picture of what's going on here.

[retep998]

malloc and friends do simply call HeapAlloc. _aligned_malloc does the exact same trick as I do here with overallocating and embedding a pointer to the original directly before the aligned address. The CRT versions do handle errors through _errno though, and having it in Rust also means the function can be inlined to give a slight performance advantage.

I want to eliminate the dependency on the CRT so that Rust can be independent of it. Such a Rust library could be used anywhere without concerns over the ABI of the C runtime. A binary built without the CRT and having its own entry point wouldn't depend on the CRT redistributables and would have a quicker startup time.

[alexcrichton]

Could you add some parens to the align - 1 just to make the binding explicit? (I can never remember the precedence of - vs &

[alexcrichton]

Sounds good to me! r=me with just a few nits

[retep998]

Nits addressed and an implementation of stats_print added.

[klutzy]

cc #20861

[alexcrichton]

@bors: r+ ebbd90d

[bors]

⌛ Testing commit ebbd90d with merge 8937ec1...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt