fixing the config flags for openbsd and bitrig #13
Conversation
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @nikomatsakis (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. The way Github handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see CONTRIBUTING.md for more information. |
|
Ah we don't actually use our |
|
@alexcrichton so should I patch the master branch to make sure it gets included in any future jemalloc snapshots? |
|
So long as it's in upstream jemalloc we should pick it up from now on |
|
@alexcrichton but the upstream jemalloc change doesn't work in our fork. Our fork has broken config scripts that don't correctly set the force_tls flag AFAICT. |
|
Sorry but I don't really understand, we don't really maintain a fork, it's just a point in jemalloc's history where we checked in the |
|
@alexcrichton Let me double check the jemalloc patch again. I think I don't need the force_tls = 0 in the main jemalloc patch. The sbrk_deprecated=1 seems to do the trick. |
|
@alexcrichton at some point (near january 25 2015 I think), the configure script of jemalloc/jemalloc didn't needed Now, as @dhuseby has/will do I think, if I recheck the current status (running ./configure and check how @dhuseby sorry if I have induced you in error : I don't have rechecked before now. |
|
@semarie thanks, I'm trying to sort this out. It seems like when I build rust with force_tls=0, I still get sbrk issues. I tried to disable jemalloc by adding this: https://github.com/rust-lang/rust/blob/master/configure#L778 But that doesn't seem to be the right way to disable jemalloc. I'm currently in the process of doing a bunch a builds to find what makes the sbrk errors go away. But IIRC, if I configure rust with --disable-jemalloc, the sbrk errors go away. But since I have to do full builds from source, it will take me a couple of days to work out the details. I'll report on progress here. |
|
@semarie I figured out how to correctly disable the use of jemalloc on Bitrig. I built the latest master with it disabled and ran a bunch of tests on it. It seems to be stable (e.g. make check passes) as do all of my test programs. I'm going to just disable jemalloc for now. Here's the PR for disabling it: rust-lang/rust#23990 |
|
@dhuseby I have an explaination about the confusion if TLS is correctly autodetected or not: with the base gcc (4.2.1), the autodetection found TLS=0, whereas with gcc from ports (4.8.4) the autodetection found TLS=1, and it failed at some points... for reference: jemalloc#223 |
|
@semarie interesting. well, I just landed a patch in rust to disable jemalloc on Bitrig until I can sort things out. Right now I'm focusing on getting the unit tests to pass so that my buildbot can produce the snapshots automagically instead of me doing it by hand. |
Extract szad size quantization into {extent,run}_quantize(), and .
quantize szad run sizes to the union of valid small region run sizes and
large run sizes.
Refactor iteration in arena_run_first_fit() to use
run_quantize{,_first,_next(), and add support for padded large runs.
For large allocations that have no specified alignment constraints,
compute a pseudo-random offset from the beginning of the first backing
page that is a multiple of the cache line size. Under typical
configurations with 4-KiB pages and 64-byte cache lines this results in
a uniform distribution among 64 page boundary offsets.
Add the --disable-cache-oblivious option, primarily intended for
performance testing.
This resolves #13.
This fixes the configure flags for OpenBSD and Bitrig. This PR puts the change into the dev branch.