Hacker News Reader

Comment by kibwen | Hacker News Reader

Now that users can switch out the global allocator, the next step may be to change the default allocator for Rust programs from jemalloc (which, note, is only the default on some platforms) to the system allocator. This has been blocked on stable global allocator support in order to make sure that users who find that jemalloc is superior for their program have a recourse to avoid performance regressions; ideally switching to jemalloc (or tcmalloc, etc.) should be well-facilitated by Crates.io.

As for the rationale behind moving away from jemalloc as a default, the tracking issue is here: https://github.com/rust-lang/rust/issues/36963 (TL;DR: lower maintenance burden, easier cross-compilation, smaller binaries, better system integration (including packaging), and the ability to use Valgrind).

View on HN

In case of FFI, if C & Rust are using the same allocator (say the system allocator), does it mean that memory allocated by C can be freed by Rust and vice-versa?

Yes.

Many types in the standard library do not consider it sound behavior to have their allocations freed by functions other than their own destructors:

https://doc.rust-lang.org/std/boxed/struct.Box.html#method.i...

    After calling this function, the caller is responsible for the memory 
    previously managed by the Box. In particular, the caller should properly 
    destroy T and release the memory. The proper way to do so is to convert 
    the NonNull<T> pointer into a raw pointer and back into a Box with the 
    Box::from_raw function.

I would guess that this might become a fun latent footgun in crates.io code -- everyone writes their unsafe code in a way that Just Works under the default allocator, but then things break down in confusing ways when enabling alternative allocators, which should be safe to do even when using external crates.

That's already true in cases; for example, I've seen FFI code that has a use-after-free bug in it, but because of the different way that the allocator works on different platforms, on OS X it "worked", but on Linux, it segfaulted.

This is not safe in general, even within a single language. For instance, on Windows, it is essentially required that a pointer is freed by code from the dynamic library (even if they're both written in, say, C) that allocated it, because (IIRC) they could be using different versions of the platform allocator.

Will it also shave off fifty-odd KB from executable size?

It depends; for example, on Windows, we already do not use jemalloc, so you won't see any change there. I don't have a Linux box handy to find the exact size of the binary there, but it will be smaller, yes.

Reply on news.ycombinator.com