-
Notifications
You must be signed in to change notification settings - Fork 13.8k
reuse RHS allocation for vec.extend(vec.into_iter()) when they do not fit into the LHS #77496
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
Changes from 10 commits
c5af975
2409653
8a0a13a
0c443cf
153a916
cb477d4
5e6abf1
567cd52
1dbab48
aa4a4ac
1885f38
d460c85
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
@@ -2199,19 +2199,12 @@ impl<T> SpecFromIter<T, IntoIter<T>> for Vec<T> { | |||||||||||||||||||||||||||||||
// But it is a conservative choice. | ||||||||||||||||||||||||||||||||
let has_advanced = iterator.buf.as_ptr() as *const _ != iterator.ptr; | ||||||||||||||||||||||||||||||||
if !has_advanced || iterator.len() >= iterator.cap / 2 { | ||||||||||||||||||||||||||||||||
unsafe { | ||||||||||||||||||||||||||||||||
let it = ManuallyDrop::new(iterator); | ||||||||||||||||||||||||||||||||
if has_advanced { | ||||||||||||||||||||||||||||||||
ptr::copy(it.ptr, it.buf.as_ptr(), it.len()); | ||||||||||||||||||||||||||||||||
} | ||||||||||||||||||||||||||||||||
return Vec::from_raw_parts(it.buf.as_ptr(), it.len(), it.cap); | ||||||||||||||||||||||||||||||||
} | ||||||||||||||||||||||||||||||||
// Safety: passing 0 is always valid | ||||||||||||||||||||||||||||||||
return unsafe { iterator.into_vec_with_uninit_prefix(0) }; | ||||||||||||||||||||||||||||||||
} | ||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||
let mut vec = Vec::new(); | ||||||||||||||||||||||||||||||||
// must delegate to spec_extend() since extend() itself delegates | ||||||||||||||||||||||||||||||||
// to spec_from for empty Vecs | ||||||||||||||||||||||||||||||||
vec.spec_extend(iterator); | ||||||||||||||||||||||||||||||||
iterator.move_into(&mut vec); | ||||||||||||||||||||||||||||||||
vec | ||||||||||||||||||||||||||||||||
} | ||||||||||||||||||||||||||||||||
} | ||||||||||||||||||||||||||||||||
|
@@ -2391,11 +2384,62 @@ where | |||||||||||||||||||||||||||||||
} | ||||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||||
impl<T> SpecExtend<T, IntoIter<T>> for Vec<T> { | ||||||||||||||||||||||||||||||||
fn spec_extend(&mut self, mut iterator: IntoIter<T>) { | ||||||||||||||||||||||||||||||||
unsafe { | ||||||||||||||||||||||||||||||||
self.append_elements(iterator.as_slice() as _); | ||||||||||||||||||||||||||||||||
fn spec_extend(&mut self, iterator: IntoIter<T>) { | ||||||||||||||||||||||||||||||||
// Avoid reallocation if we can use iterator's storage instead. This requires 1 memcpy and 0-1 memmove | ||||||||||||||||||||||||||||||||
the8472 marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||||||||||||||||||||||||||
// while reallocation would require 1 alloc, 1-2 memcpy, 1-2 free. | ||||||||||||||||||||||||||||||||
// | ||||||||||||||||||||||||||||||||
// # illustration of some extend scenarios (not exhaustive) | ||||||||||||||||||||||||||||||||
// | ||||||||||||||||||||||||||||||||
// == step == == memory == == self == == iter / v == | ||||||||||||||||||||||||||||||||
// 0123456789abcdef0123456789abcdef | ||||||||||||||||||||||||||||||||
// 0---------------1--------------- | ||||||||||||||||||||||||||||||||
// | ||||||||||||||||||||||||||||||||
// ## non-empty self, partially consumed iterator | ||||||||||||||||||||||||||||||||
the8472 marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||||||||||||||||||||||||||||
// | ||||||||||||||||||||||||||||||||
// [initial] AAAA_-----__BBB___-------------- Vec(0x00, 4, 5) IntoIter(0x0a, 0x0c, 0x0f, 8) | ||||||||||||||||||||||||||||||||
// ³ into_vec AAAA_-----____BBB_-------------- Vec(0x00, 4, 5) Vec(0x0a, 7, 8) | ||||||||||||||||||||||||||||||||
// ² prepend _____-----AAAABBB_-------------- Vec(0x00, 0, 5) Vec(0x0a, 7, 8) | ||||||||||||||||||||||||||||||||
// ⁴ *self = v ----------AAAABBB_-------------- Vec(0x0a, 7, 8) | ||||||||||||||||||||||||||||||||
// | ||||||||||||||||||||||||||||||||
// ## empty self, partially consumed iterator | ||||||||||||||||||||||||||||||||
// | ||||||||||||||||||||||||||||||||
// [initial] ____------__BBBB__-------------- Vec(0x00, 0, 4) IntoIter(0x0a, 0x0c, 0x10, 8) | ||||||||||||||||||||||||||||||||
// ³ into_vec ____------BBBB____-------------- Vec(0x00, 0, 4) Vec(0x0a, 4, 8) | ||||||||||||||||||||||||||||||||
// ⁴ *self = v ----------BBBB____-------------- Vec(0x0a, 4, 8) | ||||||||||||||||||||||||||||||||
// | ||||||||||||||||||||||||||||||||
// ## empty self, pristine iterator | ||||||||||||||||||||||||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do we even check for this case below? By the way, nice diagram. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
|
||||||||||||||||||||||||||||||||
// | ||||||||||||||||||||||||||||||||
// [initial] ----------BBBB____-------------- Vec(0x00, 0, 0) IntoIter(0x0a, 0x0a, 0x0e, 8) | ||||||||||||||||||||||||||||||||
// *self = v ----------BBBB____-------------- Vec(0x0a, 4, 8) | ||||||||||||||||||||||||||||||||
// | ||||||||||||||||||||||||||||||||
// ## insufficient capacity | ||||||||||||||||||||||||||||||||
// | ||||||||||||||||||||||||||||||||
// [initial] AAAAA-----BBBBBB__-------------- Vec(0x00, 5, 5) IntoIter(0x0a, 0x0a, 0x0f, 8) | ||||||||||||||||||||||||||||||||
// ¹² reserve(6) ----------BBBBBB__--AAAAA______- Vec(0x14, 5, 11) IntoIter(0x0a, 0x0a, 0x0f, 8) | ||||||||||||||||||||||||||||||||
|
// SAFETY: `new_size` is non-zero as `old_size` is greater than or equal to `new_size` | |
// as required by safety conditions. Other conditions must be upheld by the caller | |
old_size if old_layout.align() == new_layout.align() => unsafe { | |
let new_size = new_layout.size(); | |
// `realloc` probably checks for `new_size >= old_layout.size()` or something similar. | |
intrinsics::assume(new_size >= old_layout.size()); | |
let raw_ptr = GlobalAlloc::realloc(self, ptr.as_ptr(), old_layout, new_size); | |
let ptr = NonNull::new(raw_ptr).ok_or(AllocError)?; | |
if zeroed { | |
raw_ptr.add(old_size).write_bytes(0, new_size - old_size); | |
} | |
Ok(NonNull::slice_from_raw_parts(ptr, new_size)) | |
}, |
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 many cases realloc is just malloc+memcpy+free. Only in some cases it can extend the allocation in place.
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.
// |
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.
That line was intentionally left blank.
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 think following the rest of the codebase convention here would have this blank line not have the comment //
, and just be empty.
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.
Can this be simplified as?
&& self.capacity() - self.len() < iterator.len() | |
&& iterator.cap - iterator.len() >= self.len() | |
&& iterator.len() - self.len() < iterator.cap - self.capacity() |
I wonder if this will always grow the vec if the iterator is larger.
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.
The proposed change would underflow if self is larger than iterator
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.
Underflow?
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.
This is technically still an overflow, but that iterator.len() - self.len()
would panic or wrap if, say, self.capacity() == 20_000
and self.len() == 19_950
, and iterator.len() == 100
.
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 meant the case where self.capacity() > iterator.cap
. The subtraction would underflow the usize
result and thus lead to the inequality unexpectedly evaluating to true
which would then violate the safety constraints of into_vec_with_uninit_prefix
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.
Then how about?
&& self.capacity() - self.len() < iterator.len() | |
&& iterator.cap - iterator.len() >= self.len() | |
&& iterator.len().saturating_sub(self.len()) < iterator.cap.saturating_sub(self.capacity()) |
I
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.
For a self with len == 2 && cap == 2
and an iterator len == 2 && cap == 3
that would evaluate to true and attempt to store 4 elements into an allocation of 3. 💣💥
the8472 marked this conversation as resolved.
Show resolved
Hide resolved
the8472 marked this conversation as resolved.
Show resolved
Hide resolved
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.
Can we turn this into an else
block instead of early returning?
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.
We can, but I prefer early returns since the later part indicates the default approach in contrast to the special case above.
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 mentioned the same thing above #77496 (comment)
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 find splitting the branches here a bit easier to follow so you can tell that there's two paths we can take and don't have any way to fall through this one.
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.
It would be cooler if the code are linked to the cool diagram.
iterator.move_into(self); | |
// Insufficient capacity | |
iterator.move_into(self); |
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.
Well, yes and no.
With the optimization present that is indeed all it covers. But it is the general codepath that also works without the optimization. So I don't want to give the impression that it can only handle that case.
the8472 marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
the8472 marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
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.
We could probably use add
instead of offset
for usize
, but I don't know if the compiler will optimize out the offset
if it is 0
? Does it or should we have two functions, one with offset and one without?
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.
0 is a constant in the other callsite, so it should be easy to optimize for llvm.
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.
cc @lzutao to see if he's interested to check this out
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 think it might be clearer to add another helper method that just converts the iterator into a
Vec
without talking about an uninitialized prefix here.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.
Looking at the implementation of
into_vec_with_uninit_prefix
I think it would be better if we disallowed a prefix of0
and added a separateinto_vec
method.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.
As commented below, shifting is still needed even if the prefix is 0 so the methods would be identical except for their safety and one less addition.
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 personally think that's enough reason to make the change.