Remove jemalloc from the runtime#9933
Merged
bors merged 1 commit intorust-lang:masterfrom Oct 18, 2013
Merged
Conversation
As discovered in rust-lang#9925, it turns out that we weren't using jemalloc on most platforms. Additionally, on some platforms we were using it incorrectly and mismatching the libc version of malloc with the jemalloc version of malloc. Additionally, it's not clear that using jemalloc is indeed a large performance win in particular situtations. This could be due to building jemalloc incorrectly, or possibly due to using jemalloc incorrectly, but it is unclear at this time. Until jemalloc can be confirmed to integrate correctly on all platforms and has verifiable large performance wins on platforms as well, it shouldn't be part of the default build process. It should still be available for use via the LD_PRELOAD trick on various architectures, but using it as the default allocator for everything would require guaranteeing that it works in all situtations, which it currently doesn't. Closes rust-lang#9925
Member
Author
|
This is the source of the odd errors that I was receiving in #9834, and I'll also close all the jemalloc-related issues on the issue tracker if we do decide to merge this. |
bors
added a commit
that referenced
this pull request
Oct 18, 2013
As discovered in #9925, it turns out that we weren't using jemalloc on most platforms. Additionally, on some platforms we were using it incorrectly and mismatching the libc version of malloc with the jemalloc version of malloc. Additionally, it's not clear that using jemalloc is indeed a large performance win in particular situtations. This could be due to building jemalloc incorrectly, or possibly due to using jemalloc incorrectly, but it is unclear at this time. Until jemalloc can be confirmed to integrate correctly on all platforms and has verifiable large performance wins on platforms as well, it shouldn't be part of the default build process. It should still be available for use via the LD_PRELOAD trick on various architectures, but using it as the default allocator for everything would require guaranteeing that it works in all situtations, which it currently doesn't. Closes #9925
This was referenced Oct 19, 2013
Closed
flip1995
pushed a commit
to flip1995/rust
that referenced
this pull request
Dec 17, 2022
improve `manual_is_ascii_check ` check Sorry, not familiar the api, i can only check the method name of expression `<expr-1>.contains(<expr-2>)` after read clippy book and hints from rust-lang#9933 . i dont know how to check 1. if <expr-1> is a specific range 2. <expr-2> is a character r? `@xFrednet` could you please provide some more hints? 😝️ --- changelog: Enhancement: [`manual_is_ascii_check`]: Now detects ranges with `.contains()` calls [rust-lang#10053](rust-lang/rust-clippy#10053) <!-- changelog_checked -->
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
As discovered in #9925, it turns out that we weren't using jemalloc on most
platforms. Additionally, on some platforms we were using it incorrectly and
mismatching the libc version of malloc with the jemalloc version of malloc.
Additionally, it's not clear that using jemalloc is indeed a large performance
win in particular situtations. This could be due to building jemalloc
incorrectly, or possibly due to using jemalloc incorrectly, but it is unclear at
this time.
Until jemalloc can be confirmed to integrate correctly on all platforms and has
verifiable large performance wins on platforms as well, it shouldn't be part of
the default build process. It should still be available for use via the
LD_PRELOAD trick on various architectures, but using it as the default allocator
for everything would require guaranteeing that it works in all situtations,
which it currently doesn't.
Closes #9925