summary refs log tree commit diff
path: root/src/liballoc_jemalloc
AgeCommit message (Collapse)AuthorLines
2018-04-22Remove Alloc::oomSteven Fackler-4/+2
2018-04-22Replace GlobalAlloc::oom with a lang itemSteven Fackler-3/+2
2018-04-12Restore Global.oom() functionalitySimon Sapin-0/+11
… now that #[global_allocator] does not define a symbol for it
2018-04-12Use the GlobalAlloc trait for #[global_allocator]Simon Sapin-106/+5
2018-04-12Make AllocErr a zero-size unit structSimon Sapin-22/+3
2018-04-12Separate alloc::heap::Alloc trait for stage0 #[global_allocator]Simon Sapin-2/+1
2018-04-08Move deny(warnings) into rustbuildMark Simulacrum-1/+0
This permits easier iteration without having to worry about warnings being denied. Fixes #49517
2018-04-07Inject the `compiler_builtins` crate whenever the `core` crate is injectedOliver Schneider-0/+1
2018-04-02Use Alloc and Layout from core::heap.Mike Hommey-3/+1
94d1970bba87f2d2893f6e934e4c3f02ed50604d moved the alloc::allocator module to core::heap, moving e.g. Alloc and Layout out of the alloc crate. While alloc::heap reexports them, it's better to use them from where they really come from.
2018-01-18Make liballoc_jemalloc work on CloudABI.Ed Schouten-3/+10
The automated builds for CloudABI in dist-various-2 don't use --disable-jemalloc, even though my original container image did. Instead of setting that flag, let's go the extra mile of making jemalloc work. CloudABI's C library already uses jemalloc and now exposes the API extensions used by us.
2017-12-30Add CloudABI to the list of systems on which we stub out alloc_jemalloc.Ed Schouten-3/+3
The official jemalloc sources don't build cleanly on CloudABI yet, for the reason that some of its tracing frameworks try to access the global filesystem namespace, which CloudABI doesn't provide. Always make use of the malloc implementation used by the C library, which already happens to be jemalloc with some tiny build fixes.
2017-12-27Revert "Add a file to trivially disable tool building or testing"kennytm-3/+3
This reverts commit ab018c76e14b87f3c9e0b7384cc9b02d94779cd5. This also adds the `ToolBuild::is_ext_tool` field to replace the previous `ToolBuild::expectation` field, to indicate whether a build-failure of certain tool is essential.
2017-11-28*: strip calls to cc::Build::compileTamir Duberstein-1/+1
The documentation states: "The name output should be the name of the library." and this is already done in more recently-added callers.
2017-11-20Remove comment about a branch being optimized out, fix #45831Simon Sapin-2/+1
Most often, this code is used through the `std::heap::Heap` and `#[gloabal_allocator]` indirection, so this branch is not optimized out anymore.
2017-11-20alloc_jemalloc: don’t assume MIN_ALIGN for small sizesSimon Sapin-11/+11
See previous commit’s message for what is expected of allocators in general, and https://github.com/jemalloc/jemalloc/issues/1072 for discussion of what jemalloc does specifically.
2017-11-19std: Add a new wasm32-unknown-unknown targetAlex Crichton-1/+1
This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a "custom linker" for now which will hopefully one day be direct calls to lld. Notable features of this target include: * There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set. * There is zero toolchain footprint beyond adding the target. No custom linker is needed, rustc contains everything. * Very small wasm modules can be generated directly from Rust code using this target. * Most of the standard library is stubbed out to return an error, but anything related to allocation works (aka `HashMap`, `Vec`, etc). * Naturally, any `#[no_std]` crate should be 100% compatible with this new target. This target is currently somewhat janky due to how linking works. The "linking" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker. This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target, so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's "production ready". --- Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored, but many passing as well). The `core` test suite is still getting LLVM bugs fixed to get that working and will take some time. Relatively simple programs all seem to work though! --- It's worth nothing that you may not immediately see the "smallest possible wasm module" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final "bloat" in vanilla rustc (again, a real linker should fix all this). For now what you'll have to do is: cargo install --git https://github.com/alexcrichton/wasm-gc wasm-gc foo.wasm bar.wasm And then `bar.wasm` should be the smallest we can get it! --- In any case for now I'd love feedback on this, particularly on the various integration points if you've got better ideas of how to approach them!
2017-11-04rustc: Handle some libstd symbole exports betterAlex Crichton-10/+10
Right now symbol exports, particularly in a cdylib, are handled by assuming that `pub extern` combined with `#[no_mangle]` means "export this". This isn't actually what we want for some symbols that the standard library uses to implement itself, for example symbols related to allocation. Additionally other special symbols like `rust_eh_personallity` have no need to be exported from cdylib crate types (only needed in dylib crate types). This commit updates how rustc handles these special symbols by adding to the hardcoded logic of symbols like `rust_eh_personallity` but also adding a new attribute, `#[rustc_std_internal_symbol]`, which forces the export level to be considered the same as all other Rust functions instead of looking like a C function. The eventual goal here is to prevent functions like `__rdl_alloc` from showing up as part of a Rust cdylib as it's just an internal implementation detail. This then further allows such symbols to get gc'd by the linker when creating a cdylib.
2017-11-04Auto merge of #45514 - gnzlbg:jemalloc_realloc2, r=sfacklerbors-3/+5
[jemalloc] set correct excess in realloc_excess
2017-11-03[jemalloc] set correct excess in alloc_excessgnzlbg-1/+2
2017-10-25use nallocx instead of sallocxgnzlbg-21/+6
2017-10-25move sallocx and excess into not null branchgnzlbg-2/+3
2017-10-25[jemalloc] set correct excess in realloc_excessgnzlbg-1/+1
2017-10-25[jemalloc] set correct excess in realloc_excessgnzlbg-5/+20
2017-10-15rustbuild: Support specifying archiver and linker explicitlyVadim Petrochenkov-14/+1
2017-10-11Bump cc to 1.01 to include x86_64-unknown-linux-gnux32 supportMarco A L Barbosa-1/+1
2017-09-28Update to the `cc` crateAlex Crichton-4/+4
This is the name the `gcc` crate has moved to
2017-09-17Add a file to trivially disable tool building or testingOliver Schneider-3/+3
2017-09-10Autodetect the type of allocator crate usedMichal 'vorner' Vaner-0/+3
Annotate the allocator crates (allocator_system, allocator_jemalloc) by the type of allocator they are. If one is requested as an exe allocator, detect its type by the flags. This has the effect that using this (de jure wrong) configuration in the target spec works instead of producing a really unhelpful and arcane linker error: "exe-allocation-crate": "alloc_system" Fixes #43524.
2017-09-02update gcc crateRalf Jung-2/+2
Use gcc::Build rather than deprecated gcc::Config. Fixes #43973
2017-08-29Auto merge of #43648 - RalfJung:jemalloc-debug, r=alexcrichtonbors-3/+5
Fix alloc_jemalloc debug feature At least, I think that's how it should be. 'debug' is how the feature is called in liballoc_jemalloc/Cargo.toml and libstd/Cargo.toml. I verified this by making the build script panic rather than adding `--enable-debug`, and without this PR, the panic does not occur even when I set `debug-jemalloc = true` in config.toml. With the PR, the panic occurs as expected. However, I actually have no idea what I am doing here.
2017-08-29give up on trying to fix the assertion failureRalf Jung-3/+5
2017-08-29Fix alloc_jemalloc debug featureRalf Jung-1/+1
At least, I think that's how it should be. 'debug' is how the feature is called in Cargo.toml.
2017-08-27Whitelist for dummy_jemallocTatsuyuki Ishi-1/+1
2017-08-25*: remove crate_{name,type} attributesTamir Duberstein-2/+0
Fixes #41701.
2017-08-16Update jemalloc to 4.5.0arthurprs-23/+1
2017-07-25Bump master to 1.21.0Alex Crichton-15/+8
This commit bumps the master branch's version to 1.21.0 and also updates the bootstrap compiler from the freshly minted beta release.
2017-07-05rustc: Implement the #[global_allocator] attributeAlex Crichton-66/+139
This PR is an implementation of [RFC 1974] which specifies a new method of defining a global allocator for a program. This obsoletes the old `#![allocator]` attribute and also removes support for it. [RFC 1974]: https://github.com/rust-lang/rfcs/pull/197 The new `#[global_allocator]` attribute solves many issues encountered with the `#![allocator]` attribute such as composition and restrictions on the crate graph itself. The compiler now has much more control over the ABI of the allocator and how it's implemented, allowing much more freedom in terms of how this feature is implemented. cc #27389
2017-06-25Stop disabling fill in jemallocSteven Fackler-2/+0
The underlying bug has been fixed for over 2 years!
2017-06-19Bump version and stage0 compilerAlex Crichton-0/+5
2017-06-09Revert "Update jemalloc to 4.5.0"arthurprs-1/+23
This reverts commit 65d0be3b7b540145c22409b1a79f7d263422e19b.
2017-06-01Support VS 2017Brian Anderson-1/+1
Fixes #38584
2017-05-10Update jemalloc to 4.5.0arthurprs-23/+1
2017-04-15Specialize Vec::from_elem<u8> to use calloc or memsetMatt Brubeck-0/+21
Fixes #38723.
2017-04-08Fix jemalloc support for muslShiz-6/+6
Just like DragonFlyBSD, using the same symbols as the system allocator will result in a segmentation fault at runtime due to allocator mismatches. As such, prefix the jemalloc symbols instead.
2017-03-12Update usages of 'OSX' (and other old names) to 'macOS'.Corey Farwell-1/+1
As of last year with version 'Sierra', the Mac operating system is now called 'macOS'.
2017-03-04Automate timestamp creation and build skipping for native librariesVadim Petrochenkov-9/+4
Add comments
2017-03-04Build compiler-rt and sanitizers only onceVadim Petrochenkov-25/+15
2017-03-04Add/remove `rerun-if-changed` when necessaryVadim Petrochenkov-2/+0
2017-02-21test: Verify all sysroot crates are unstableAlex Crichton-12/+0
As we continue to add more crates to the compiler and use them to implement various features we want to be sure we're not accidentally expanding the API surface area of the compiler! To that end this commit adds a new `run-make` test which will attempt to `extern crate foo` all crates in the sysroot, verifying that they're all unstable. This commit discovered that the `std_shim` and `test_shim` crates were accidentally stable and fixes the situation by deleting those shims. The shims are no longer necessary due to changes in Cargo that have happened since they were originally incepted.
2017-02-06std: Remove cfg(cargobuild) annotationsAlex Crichton-17/+0
These are all now no longer needed that we've only got rustbuild in tree.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-01-15 19:45:57 +0000