Contradicting documentation on default allocator

[RalfJung]

Documentation states that

Currently the default global allocator is unspecified. Libraries, however, like cdylibs and staticlibs are guaranteed to use the System by default.

and it also states that

This type implements the GlobalAlloc trait and Rust programs by default work as if they had this definition:

use std::alloc::System;

#[global_allocator]
static A: System = System;

These two statements directly contradict each other -- one says that System is the default everywhere, one says that that is not specified. Which one should it be? :)

FWIW Miri currently considers it a bug to create an allocation with the default global allocator and then free it with System, matching the first bit of documentation, but contradicting the second.

[thomcc]

I think one solution here would be to decide that System is just always whatever we decide the default global allocator is (and perhaps it should be renamed to DefaultGlobal or something). The name System is already fairly misleading, given:

it is not valid to mix use of the backing system allocator with System, as this implementation may include extra work, such as to serve alignment requests greater than the alignment provided directly by the backing system allocator.

And also given that (IIUC) it's actually a vendored dlmalloc port on WebAssembly targets

[RalfJung]

So basically you are saying the second docs I quoted are right and the first one should be removed?

[thomcc]

That's my opinion, yes.

[bjorn3]

I think we shouldn't assume #[global_allocator] static A: System = System; being the default in miri. If you depend on System being the global allocator you should add #[global_allocator] static A: System = System; yourself and if you don't add it, someone else is allowed to use a different global allocator, which would then cause UB for you. In that case you are at fault, not the crate that specified a different global allocator.

[thomcc]

Yeah, that's a pretty compelling point. While I do feel like System should be guaranteed the default global allocator (and probably renamed), it's very hard to rely on that without UB.

[RalfJung]

Miri runs binary crates, not lib crates, so it's not possible for someone else to set anything.

If the documentation says that Rust works as if this exists by default

#[global_allocator]
static A: System = System;

then we have to allow such code, we have no grounds for calling it UB. So @bjorn3 are you saying we should remove the 2nd documentation and keep the first?

[bjorn3]

Miri runs binary crates, not lib crates, so it's not possible for someone else to set anything.

Miri is often used to test library crates.

So @bjorn3 are you saying we should remove the 2nd documentation and keep the first?

Yes.

[RalfJung]

Miri is often used to test library crates.

Yes -- by running a binary crate that exercises them (the test crate). What I said remains true.

[Diggsey]

@bjorn3 I disagree with this, because it means there's no way to "wrap" the default allocator.

I should be able to write something like this:

#[global_allocator]
static A: MyAllocationTracker = MyAllocationTracker::new(System);

And have it track my allocations without otherwise changing the behaviour of my program.

If you think System is not the right type for this (despite it being explicitly documented as the right way to do this) then we need a new DefaultGlobal type instead.

[bjorn3]

And have it track my allocations without otherwise changing the behaviour of my program.

It shouldn't change the behavior to switch from the default allocator to the system allocator. At most the performance profile. If we decided that the System allocator is always the default allocator, then MyAllocationTracker::new(System) would not cause any perf regression other than inherent to MyAllocationTracker. If we decided to use a different default allocator, we did likely do so to improve performance. In that case using MyAllocationTracker::new(System) would be a perf regression, but not beyond what we would have anyway by deciding to only use System as default allocator. If we decide to only use System as default, maybe should rename System itself to DefaultGlobal and remove any relation to the actual system allocator?

[chorman0773]

FTR, System is stable and cannot be renamed. If that path was taken, a new type entirely would have to be created.

[Diggsey]

It shouldn't change the behavior to switch from the default allocator to the system allocator.

In practice it can. We need a way to get precisely the default behaviour, not just "approximately". Whether we do that by upholding the guarantee that System is the default, or by introducing a new DefaultGlobal I don't really care,, but if we're going to do the latter, then the sooner the better.

[chorman0773]

I'm unsure you could rely upon that. Making it generally unspecified would allow, for example, delegating to C++ operator new (which I contemplated doing for proc-macros back when lccc was written in C++ - it switched to just pulling in xlang_allocate via custom allocator).

…

On Sat, Nov 19, 2022 at 10:59 bjorn3 ***@***.***> wrote: And have it track my allocations without otherwise changing the behaviour of my program. It shouldn't change the behavior to switch from the default allocator to the system allocator. At most the performance profile. If we decided that the System allocator is always the default allocator, then MyAllocationTracker::new(System) would not cause any perf regression other than inherent to MyAllocationTracker. If we decided to use a different default allocator, we did likely do so to improve performance. In that case using MyAllocationTracker::new(System) would be a perf regression, but not beyond what we would have anyway by deciding to only use System as default allocator. If we decide to only use System as default, maybe should rename System itself to DefaultGlobal and remove any relation to the actual system allocator? — Reply to this email directly, view it on GitHub <#108 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABGLD2YHNOJVPG7JYKGHOR3WJD2NJANCNFSM6AAAAAASFHO4YI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[RalfJung]

(despite it being explicitly documented as the right way to do this) t

It is also explicitly document as not being something you can rely on, so you really can't go off the docs here, unfortunately.