Disabling jemalloc

[sanxiyn]

I follow Fedora's bug to package Rust, and I noticed they plan to build with ./configure --disable-jemalloc.

I think this is okay, since that is the current default on Windows, but I want to make sure upstream is okay with this. Do you see any problem?

[retep998]

With windows-msvc it is less of being a default and more of jemalloc won't build with msvc at all so let's not even bother and have the system allocator be the only option.

I certainly don't see any issues with using the system allocator. Especially on some systems the system allocator is competitive with jemalloc in which case disabling jemalloc is beneficial by reducing binary sizes.

[cuviper]

FWIW, that was not some deep decision, just me making that proposal and nobody disputing it. I'm open to being convinced otherwise, but I generally feel it's better to rally around a single system allocator. And it was a little lazy too, as I don't have to fix the build system to use shared libraries for unbundling jemalloc.

[PeteVine]

@cuviper We're talking about Linux (on x86, even with 64kb/512kb L1/L2, jemalloc provides about 3% speedup) so you could do the best thing possible, that I'd suggested to @alexcrichton recently, by switching to alloc_system by default but also building the jemalloc crate. (--disable-jemalloc is a little blunt but fulfills the promise as you can even delete the source tree before bootstrap)

IOW, jemalloc is very tunable, therefore having this option would be great for experienced jemalloc users (and with some reading, for the rest of us too.)

[cuviper]

@PeteVine It depends very much on the workload. Glibc works very well in general, but some cases will be better in jemalloc, and sure, a performance architect may want to control that. I hope people actually measure it though, instead of cargo-culting the idea that one is always better. (No Cargo pun intended.)

AIUI, making your own allocator choice still requires unstable feature flags, right?

Anyway, whatever we do now isn't set in stone. If Rust gets more knobs for controlling defaults, and preferably learns to link jemalloc dynamically, then I won't mind including it.

[PeteVine]

instead of cargo-culting the idea that one is always better. (No Cargo pun intended.)

That's why I find it strange jemalloc is either obligatory or completely eradicated. I'd like to be able to boostrap any number of sysalloc targets (leaving jemalloc on the table) without editing their definitions.

AIUI, making your own allocator choice still requires unstable feature flags, right?

I believe so.

[brson]

Do you see any problem?

At the moment I don't see any problem because there's not a stable way to ask for jemalloc explicitly, but this does seem to be a reason to take pause at further stabilization. If we were in a place where all Rust users were expected to have access to the alloc_jemalloc crate in the sysroot, then Fedora not building it would be bad for us.

Personally, I'm in favor of moving in a direction where Rust uses the system allocator by default, there is some stable way to ask for a different allocator, and jemalloc is just a crate on crates.io.

[cuviper]

I like the idea that it's eventually just another crate. Then the dependency is also spelled out explicitly, instead of some implicit default or a buried choice in the source.

[sfackler]

I would also love to jettison jemalloc to a third party crate. I believe the only real blocker there is finding someone motivated enough to own the allocator crate API and get it on the road to stabilization.

[sorear]

Do the situational performance advantages of jemalloc persist if you dynamically link it, though?

[cuviper]

I would not expect the advantages to be mere call locality, but please feel free to measure it and see.

[Ericson2314]

I would!

The allocator API is not enough for stable usage on its own, however. We also need the needs-provides mechanism to anoint one instance the default allocator. Alternatively, I've proposed moving the notion of a default allocator out of liballoc, in which case that crate could be stabilized before needs-provides mechanism, but this wouldn't help users that do rely on a default allocator via std---i.e. most of them.

[sfackler]

I think that's roughly what RFC 1183 does, right?

[Ericson2314]

Not quite.

Firstly, this uses some ad-hoc attributes instead of the generalized needs-provides infrastructure there is no some consensus about wanting. I think it would be a shame to stabilize the add-hoc stuff.

Secondly,

#![needs_allocator] indicates that a library requires the "allocation symbols" to link successfully. This attribute will be attached to liballoc and no other library should need to be tagged as such.

My alternative of giving liballoc no notion of a default allocator to stabilize liballoc quicklier would entail moving this attribute to a downstream crate.

[sfackler]

Why is it a shame to stabilize ad-hoc stuff if there's no consensus that we want something more complex?

[Ericson2314]

I would say more regular, not necessarily more complex. Last I checked there was growing consensus for wanting needs-provides, after it came up with at least allocation, logging, and panic strategies.

[sfackler]

Could you point me to some place that discussion about a needs-provides system has taken place? I'm not familiar with it coming up at all, not to mention consensus about it.

[brson]

@sfackler This is the only thread I'm aware of.

[Ericson2314]

See also the panic strategy PR https://github.com/rust-lang/rfcs/pull/1513#issuecomment-190774907 (not sure if the comment I linked is the first to discus this in that thread)