-
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
Fix a layout possible miscalculation in alloc::RawVec
#83706
Conversation
(rust-highfive has picked a reviewer for you, use r? to override) |
I don't think so.
Makes sense.
I found at least one other place that used |
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 seems reasonable and I agree that we should also take a look at shrink
:
rust/library/alloc/src/raw_vec.rs
Lines 470 to 479 in 451e98e
let (ptr, layout) = if let Some(mem) = self.current_memory() { mem } else { return Ok(()) }; | |
let new_size = amount * mem::size_of::<T>(); | |
let ptr = unsafe { | |
let new_layout = Layout::from_size_align_unchecked(new_size, layout.align()); | |
self.alloc.shrink(ptr, layout, new_layout).map_err(|_| TryReserveError::AllocError { | |
layout: new_layout, | |
non_exhaustive: (), | |
})? | |
}; |
r=me once it's addressed.
Ping from triage:
Can you please address this |
117b686
to
fe942c2
Compare
Done, also fixed |
☔ The latest upstream changes (presumably #87408) made this pull request unmergeable. Please resolve the merge conflicts. |
fe942c2
to
e7f1c8e
Compare
Rebased |
Sorry for the delay! |
📌 Commit 03498aa has been approved by |
⌛ Testing commit 5376317 with merge ed9196e48a1c25c95588058b775e6c71cd47eb83... |
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
Uhm, another spurious failure came up... @bors retry |
☀️ Test successful - checks-actions |
Finished benchmarking commit (5bd1ec3): comparison url. Summary: This benchmark run shows 54 relevant regressions 😿 to instruction counts.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression |
@JohnTitor @a1phyr the perf regressions are somewhat small but still there are enough of them to warrant a check in on what's going on. I assume a small perf regression would be expected since we're now strictly doing more (e.g., checked multiplication), but is the magnitude of the regression here expected? |
simplify layout calculations in rawvec The use of `Layout::array` was introduced in rust-lang#83706 which lead to a [perf regression](rust-lang#83706 (comment)). This PR basically reverts that change since rust currently only supports stride == size types, but to be on the safe side it leaves a const-assert there to make sure this gets caught if those assumptions ever change.
simplify layout calculations in rawvec The use of `Layout::array` was introduced in #83706 which lead to a [perf regression](rust-lang/rust#83706 (comment)). This PR basically reverts that change since rust currently only supports stride == size types, but to be on the safe side it leaves a const-assert there to make sure this gets caught if those assumptions ever change.
simplify layout calculations in rawvec The use of `Layout::array` was introduced in #83706 which lead to a [perf regression](rust-lang/rust#83706 (comment)). This PR basically reverts that change since rust currently only supports stride == size types, but to be on the safe side it leaves a const-assert there to make sure this gets caught if those assumptions ever change.
A layout miscalculation could happen in
RawVec
when used with a type whose size isn't a multiple of its alignment. I don't know if such type can exist in Rust, but the Layout API provides ways to manipulate such types. Anyway, it is better to calculate memory size in a consistent way.