about summary refs log tree commit diff
path: root/src/liballoc_jemalloc
AgeCommit message (Collapse)AuthorLines
2018-11-02Remove all jemalloc-related contentAlex Crichton-318/+0
This commit removes all jemalloc related submodules, configuration, etc, from the bootstrap, from the standard library, and from the compiler. This will be followed up with a change to use jemalloc specifically as part of rustc on blessed platforms.
2018-09-27Bump to 1.31.0 and bootstrap from 1.30 betaJosh Stone-5/+1
2018-09-11stabalize infer outlives requirements (RFC 2093).toidiu-1/+0
Co-authored-by: nikomatsakis
2018-08-27Auto merge of #53441 - toidiu:ak-fix53419, r=nikomatsakisbors-0/+1
fix for late-bound regions Fix for https://github.com/rust-lang/rust/issues/53419 r? @nikomatsakis
2018-08-26rustc: Continue to tweak "std internal symbols"Alex Crichton-4/+4
In investigating [an issue][1] with `panic_implementation` defined in an executable that's optimized I once again got to rethinking a bit about the `rustc_std_internal_symbol` attribute as well as weak lang items. We've sort of been non-stop tweaking these items ever since their inception, and this continues to the trend. The crux of the bug was that in the reachability we have a [different branch][2] for non-library builds which meant that weak lang items (and std internal symbols) weren't considered reachable, causing them to get eliminiated by ThinLTO passes. The fix was to basically tweak that branch to consider these symbols to ensure that they're propagated all the way to the linker. Along the way I've attempted to erode the distinction between std internal symbols and weak lang items by having weak lang items automatically configure fields of `CodegenFnAttrs`. That way most code no longer even considers weak lang items and they're simply considered normal functions with attributes about the ABI. In the end this fixes the final comment of #51342 [1]: https://github.com/rust-lang/rust/issues/51342#issuecomment-414368019 [2]: https://github.com/rust-lang/rust/blob/35bf1ae25799a4e62131159f052e0a3cbd27c960/src/librustc/middle/reachable.rs#L225-L238
2018-08-24check that adding infer-outlives requirement to all crates worksNiko Matsakis-0/+1
2018-08-09liballoc_jemalloc: enable feature(nll) for bootstrapmemoryruins-0/+1
2018-07-31enable jemalloc assertions when configured to do soRalf Jung-5/+4
2018-07-25Deny bare_trait_objects globallyTatsuyuki Ishi-1/+0
2018-07-12Deny bare trait objects in the rest of rustljedrz-0/+1
2018-06-11Mark alloc_jemalloc as perma-unstableSimon Sapin-3/+2
2018-05-17Switch to 1.26 bootstrap compilerMark Simulacrum-7/+0
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!
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-01-12 05:11:48 +0000