Skip to content

jemalloc still pulled in with extern crate alloc_system on nightlies >= 2017-07-07 #43277

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
chenxiaolong opened this issue Jul 17, 2017 · 6 comments
Labels
A-allocators Area: Custom and system allocators regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@chenxiaolong
Copy link

chenxiaolong commented Jul 17, 2017

It seems that ever since the 2017-07-07 nightly, using the alloc_system crate causes jemalloc to be linked in. For example, if I change the default hello world sample crate to the following:

#![feature(alloc_system)]
extern crate alloc_system;

fn main() {
    println!("Hello, world!");
}

then the binary built by the 2017-07-07 toolchain contains jemalloc symbols, while the binary built by the 2017-07-06 toolchain does not.

[hello] rm -rf target/release; cargo +nightly-2017-07-06 build --release; strings target/release/hello | grep -c jemalloc
   Compiling hello v0.1.0 (file:///tmp/rust/hello)
    Finished release [optimized] target(s) in 0.32 secs
0
[hello] rm -rf target/release; cargo +nightly-2017-07-07 build --release; strings target/release/hello | grep -c jemalloc
   Compiling hello v0.1.0 (file:///tmp/rust/hello)
    Finished release [optimized] target(s) in 0.42 secs
269

Could this be related to the allocator PRs that have been merged recently? Or perhaps the code above is no longer the way to select the system allocator?


Versions:

  • nightly-2017-07-06-x86_64-unknown-linux-gnu (rustc 1.20.0-nightly (3610a70ce 2017-07-05))
  • nightly-2017-07-07-x86_64-unknown-linux-gnu (rustc 1.20.0-nightly (696412de7 2017-07-06))
@Mark-Simulacrum
Copy link
Member

cc @alexcrichton

@Mark-Simulacrum Mark-Simulacrum added regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. A-allocators Area: Custom and system allocators labels Jul 17, 2017
@alexcrichton
Copy link
Member

Ah yeah this is intended behavior as the implementation of global allocators changed in #42727, and you should be able to see the current state of affairs at the top of #27389

@chenxiaolong
Copy link
Author

@alexcrichton Thanks for the info!

Forgive my ignorance, but with the new global allocators implementation, is there an easy way to specify that the system allocator should be used? What would I need to specify in the code?

@alexcrichton
Copy link
Member

Oh sure yeah, to specify the system allocator as the global allocator:

use std::heap::System;

#[global_allocator]
static ALLOCATOR: System = System;

@chenxiaolong
Copy link
Author

Thanks! That worked perfectly. For reference, I tested with:

#![feature(global_allocator)]
#![feature(allocator_api)]

use std::heap::System;

#[global_allocator]
static ALLOCATOR: System = System;

fn main() {
    println!("Hello, world!");
}

@alexchandel
Copy link

For future seekers, this has moved to std::alloc::System as of ≤1.31. Try:

use std::alloc::System;

#[global_allocator]
static ALLOCATOR: System = System;

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-allocators Area: Custom and system allocators regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

4 participants