-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
BTreeMap: remove shared root #70111
BTreeMap: remove shared root #70111
Conversation
I was unable to run miri as it's currently unavailable in nightly, but we can hold off landing this until miri returns (or fix potential fallout once it returns). Tests do pass locally, including under valgrind. |
This comment has been minimized.
This comment has been minimized.
Looks like the gdb pretty printing broke as a result of this; I am completely unfamiliar with that side of things but will try to investigate and fix. |
This comment has been minimized.
This comment has been minimized.
Hm, tests did pass locally so I'm guessing this is a gdb-version specific issue? It looks like perhaps the way enums are decoded differs though. Or, as another alternative I guess, we have some layout optimization applying in stage 2 which is absent in stage 1 (where I tested). Part of me wants to just comment out the Btree debug pretty printing entirely... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder how you came up with that gdb code, but I sure don't know how to unwrap an option there. You are aware it's being changed in #60826?
front: Option<Handle<NodeRef<marker::Mut<'a>, K, V, marker::Leaf>, marker::Edge>>, | ||
back: Option<Handle<NodeRef<marker::Mut<'a>, K, V, marker::Leaf>, marker::Edge>>, | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just an idea that popped up: did you consider making some static handle that could be used here, to avoid the Option(s) and the code around them? Since in that case front==back
so the handles would never be dereferenced.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I did consider this. I suspect we'd run into many of the same problems as we did with the shared root (or end up having to write a bunch of boilerplate code) -- I would prefer to avoid that. There is at least once niche in the NodeRef (and Handle doesn't use it up) so I think this is essentially zero-cost anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In node.rs
, it looks like a really nice cleanup! In map.rs
, the extra unwraps and such are a little annoying, but not too bad. Overall, it looks like an improvement in safety though.
5175860
to
0b599bf
Compare
I was aware of #60826, but had forgotten about it :) It looks like that doesn't actually change the BTree printing at all pretty much so this PR would need to fix it up if we want it to work. I'm not actually personally sure how useful it is for it to work :) Maybe @ortem has some advice on how best to work around the introduction of the Option here -- clearly my haphazard "this seems to get us what we want" is not passing CI, at least. I've pushed up a commit to attempt to debug the Some trouble now. |
This comment has been minimized.
This comment has been minimized.
0b599bf
to
4624456
Compare
If it's any comfort, your latest commit tests fine on my linux box (with gdb 8.2.1 as opposed to 8.1.0 on rust-highfive). |
Yeah, every commit since I tried to fix it has tested fine with my local GDB (8.3.1) too. If this doesn't work I'll try to get a 8.1 gdb copy locally I guess... |
This comment has been minimized.
This comment has been minimized.
4624456
to
db7a697
Compare
@cuviper -- looks like gdb pretty printing is working now, I believe this is ready for another review pass. |
LGTM! @bors r+ |
📌 Commit db7a697 has been approved by |
You could also remove test case |
…cuviper BTreeMap: remove shared root This replaces the shared root with `Option`s in the BTreeMap code, and then slightly cleans up the node manipulation code taking advantage of the removal of the shared root. I expect that further simplification is possible, but wanted to get this posted for initial review. Note that `BTreeMap::new()` continues to not allocate. Benchmarks seem within the margin of error/unaffected, as expected for an entirely predictable branch. ``` name alloc-bench-a ns/iter alloc-bench-b ns/iter diff ns/iter diff % speedup btree::map::iter_mut_20 20 21 1 5.00% x 0.95 btree::set::clone_100 1,360 1,439 79 5.81% x 0.95 btree::set::clone_100_and_into_iter 1,319 1,434 115 8.72% x 0.92 btree::set::clone_10k 143,515 150,991 7,476 5.21% x 0.95 btree::set::clone_10k_and_clear 142,792 152,916 10,124 7.09% x 0.93 btree::set::clone_10k_and_into_iter 146,019 154,561 8,542 5.85% x 0.94 ```
Failed in #70169 (comment) |
This simplifies the node manipulation, as we can (in later commits) always know when traversing nodes that we are not in a shared root.
We no longer have a separate header because the shared root is gone; all code can work solely with leafs now.
This makes ensure_root_is_owned return a reference to the (now guaranteed to exist) root, allowing callers to operate on it without going through another unwrap. Unfortunately this is only rarely useful as it's frequently the case that both the length and the root need to be accessed and field-level borrows in methods don't yet exist.
db7a697
to
bce7f6f
Compare
@bors r=cuviper Fixed up the pretty printing code (at least the test-various builder is passing locally now, and gdb 8.3 with the debugger script in this PR also does the right thing). |
📌 Commit bce7f6f has been approved by |
…cuviper BTreeMap: remove shared root This replaces the shared root with `Option`s in the BTreeMap code, and then slightly cleans up the node manipulation code taking advantage of the removal of the shared root. I expect that further simplification is possible, but wanted to get this posted for initial review. Note that `BTreeMap::new()` continues to not allocate. Benchmarks seem within the margin of error/unaffected, as expected for an entirely predictable branch. ``` name alloc-bench-a ns/iter alloc-bench-b ns/iter diff ns/iter diff % speedup btree::map::iter_mut_20 20 21 1 5.00% x 0.95 btree::set::clone_100 1,360 1,439 79 5.81% x 0.95 btree::set::clone_100_and_into_iter 1,319 1,434 115 8.72% x 0.92 btree::set::clone_10k 143,515 150,991 7,476 5.21% x 0.95 btree::set::clone_10k_and_clear 142,792 152,916 10,124 7.09% x 0.93 btree::set::clone_10k_and_into_iter 146,019 154,561 8,542 5.85% x 0.94 ```
…cuviper BTreeMap: remove shared root This replaces the shared root with `Option`s in the BTreeMap code, and then slightly cleans up the node manipulation code taking advantage of the removal of the shared root. I expect that further simplification is possible, but wanted to get this posted for initial review. Note that `BTreeMap::new()` continues to not allocate. Benchmarks seem within the margin of error/unaffected, as expected for an entirely predictable branch. ``` name alloc-bench-a ns/iter alloc-bench-b ns/iter diff ns/iter diff % speedup btree::map::iter_mut_20 20 21 1 5.00% x 0.95 btree::set::clone_100 1,360 1,439 79 5.81% x 0.95 btree::set::clone_100_and_into_iter 1,319 1,434 115 8.72% x 0.92 btree::set::clone_10k 143,515 150,991 7,476 5.21% x 0.95 btree::set::clone_10k_and_clear 142,792 152,916 10,124 7.09% x 0.93 btree::set::clone_10k_and_into_iter 146,019 154,561 8,542 5.85% x 0.94 ```
Rollup of 16 pull requests Successful merges: - rust-lang#65097 (Make std::sync::Arc compatible with ThreadSanitizer) - rust-lang#69033 (Use generator resume arguments in the async/await lowering) - rust-lang#69997 (add `Option::{zip,zip_with}` methods under "option_zip" gate) - rust-lang#70038 (Remove the call that makes miri fail) - rust-lang#70058 (can_begin_literal_maybe_minus: `true` on `"-"? lit` NTs.) - rust-lang#70111 (BTreeMap: remove shared root) - rust-lang#70139 (add delay_span_bug to TransmuteSizeDiff, just to be sure) - rust-lang#70165 (Remove the erase regions MIR transform) - rust-lang#70166 (Derive PartialEq, Eq and Hash for RangeInclusive) - rust-lang#70176 (Add tests for rust-lang#58319 and rust-lang#65131) - rust-lang#70177 (Fix oudated comment for NamedRegionMap) - rust-lang#70184 (expand_include: set `.directory` to dir of included file.) - rust-lang#70187 (more clippy fixes) - rust-lang#70188 (Clean up E0439 explanation) - rust-lang#70189 (Abi::is_signed: assert that we are a Scalar) - rust-lang#70194 (#[must_use] on split_off()) Failed merges: r? @ghost
…r=Mark-Simulacrum Test and fix gdb pretty printing more Over time I had oversimplified the test case for rust-lang#68098: it does not have an internal node to print so it does not test what it pretend to test. And then I also realized not spotting the same mistake reviewing rust-lang#70111, and more likely to occur in the wild. Now, both test cases fail if you put back the flawed python code. r? @Mark-Simulacrum
…Mark-Simulacrum Test and fix gdb pretty printing more Over time I had oversimplified the test case for rust-lang#68098: it does not have an internal node to print so it did not test what it pretended to test. And then I also realized not spotting the same mistake reviewing rust-lang#70111, and more likely to occur in the wild. Now, both test cases fail if you put back the flawed python code. r? @Mark-Simulacrum
This replaces the shared root with
Option
s in the BTreeMap code, and then slightly cleans up the node manipulation code taking advantage of the removal of the shared root. I expect that further simplification is possible, but wanted to get this posted for initial review.Note that
BTreeMap::new()
continues to not allocate.Benchmarks seem within the margin of error/unaffected, as expected for an entirely predictable branch.