Make `Rc<T>::deref` and `Arc<T>::deref` zero-cost #132553

EFanZh · 2024-11-03T07:48:34Z

Currently, Rc<T> and Arc<T> store pointers to RcInner<T> and ArcInner<T>. This PR changes the pointers so that they point to T directly instead.

This is based on the assumption that we access the T value more frequently than accessing reference counts. With this change, accessing the data can be done without offsetting pointers from RcInner<T> and ArcInner<T> to their contained data. This change might also enables some possibly useful future optimizations, such as:

Convert &[Rc<T>] into &[&T] within O(1) time.
Convert &[Rc<T>] into Vec<&T> utilizing memcpy.
Convert &Option<Rc<T>> into Option<&T> without branching.
Make Rc<T> and Arc<T> FFI compatible types where T: Sized.

rustbot · 2024-11-03T07:48:42Z

r? @jhpratt

rustbot has assigned @jhpratt.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

marmeladema · 2024-11-03T09:22:09Z

Would it potentially enable those types to have an ffi compatible ABI? So that they could be returned and passed directly from /to ffi function, like Box?

EFanZh · 2024-11-03T10:36:08Z

Would it potentially enable those types to have an ffi compatible ABI? So that they could be returned and passed directly from /to ffi function, like Box?

I think in theory it is possible, at least for sized types, but I am not familiar with how to formally make it so.

jhpratt · 2024-11-03T23:07:24Z

r? libs

joboet · 2024-11-07T16:17:52Z

@EFanZh Is this ready for review? If so, please un-draft the PR.

EFanZh · 2024-11-07T17:12:22Z

@joboet: The source code part is mostly done, but I haven’t finished updating LLDB and CDB pretty printers. The CI doesn’t seem to run those tests.

joboet · 2024-11-08T12:56:42Z

No worries! I just didn't want to keep you waiting in case you had forgotten to change the state.
@rustbot author

thaliaarchi

I don't have any substantial feedback, because it's a lot of code and I haven't done comparisons between what was deleted in Rc<T> and Arc<T> and the new code. But I'm excited for this change and it looks generally good!

But the largest thing that stands out to me is that there's a lot of tiny functions. Although they have descriptive names and are documented, it made it somewhat harder to follow for me. For the ones used only once, it might make sense to inline them for readability.

library/alloc/src/raw_rc/mod.rs

library/alloc/src/raw_rc/raw_rc.rs

joboet

This will take some time to review, sorry. Some initial comments:

joboet · 2025-03-27T15:02:50Z

library/alloc/src/raw_rc/mod.rs

+
+/// Creates an allocator of type `A`, then tries to allocate a chunk of reference-counted memory
+/// that is described by `rc_layout`.
+fn try_allocate_uninit<A, const STRONG_COUNT: usize>(


Do you have a particular reason for making this a separate function instead of just passing Global into the generic function?

This is because passing a ZST is zero-cost, but passing a reference to a ZST is not. I assumed that most of the time, the allocator will be the ZST type Global, so if for some reason (maybe with opt-level=z) this function is not inlined into caller, caller does’t have to pay for passing an allocator.

Another reason is that if A::default is not a trivial function, code for constructing an allocator could be potentially shared by all callers, so that the binary sized could benefit from this.

joboet · 2025-03-27T15:04:24Z

library/alloc/src/raw_rc/rc_layout.rs

+impl Deref for RcLayout {
+    type Target = Layout;
+
+    fn deref(&self) -> &Self::Target {
+        &self.0
+    }
+}


This is never really a good idea, RcLayout isn't a smart pointer.

I have replaced dereference with a get function.

joboet · 2025-03-27T15:05:14Z

library/alloc/src/raw_rc/rc_layout.rs

+pub(crate) trait RcLayoutExt {
+    /// Computes `RcLayout` at compile time if `Self` is `Sized`.
+    const RC_LAYOUT: RcLayout;
+}
+
+impl<T> RcLayoutExt for T {
+    const RC_LAYOUT: RcLayout = match RcLayout::try_from_value_layout(T::LAYOUT) {
+        Ok(rc_layout) => rc_layout,
+        Err(_) => panic!("value is too big to store in a reference-counted allocation"),
+    };
+}


Inline const is stable, would that be an alternative here?

T::RC_LAYOUT is used in multiple places, I think making it an associated const could potentially avoid calculating it multiple times. This trait has a similar role as the core::mem::SizedTypeProperties trait.

library/alloc/src/raw_rc/rc_layout.rs

EFanZh · 2025-03-29T15:31:25Z

But the largest thing that stands out to me is that there's a lot of tiny functions. Although they have descriptive names and are documented, it made it somewhat harder to follow for me. For the ones used only once, it might make sense to inline them for readability.

@thaliaarchi: Do you mean the allocation functions? I have checked those functions, most functions are used more than once, and the function that are used once are used for unifying non-generic codes used in generic functions.

@rustbot ready

bors · 2025-03-29T23:36:36Z

☔ The latest upstream changes (presumably #133572) made this pull request unmergeable. Please resolve the merge conflicts.

bors · 2025-04-28T05:41:11Z

☔ The latest upstream changes (presumably #140378) made this pull request unmergeable. Please resolve the merge conflicts.

bors · 2025-05-07T04:43:54Z

☔ The latest upstream changes (presumably #140726) made this pull request unmergeable. Please resolve the merge conflicts.

joboet · 2025-05-15T10:38:24Z

This PR is way too large for me to review. Is there any way you could split this up? E.g. by moving the Arc changes to a different PR...

EFanZh · 2025-05-15T12:25:02Z

@joboet: The majority codes are in alloc::raw_rc module, which has to be submitted with at least one of alloc::rc and alloc::sync changes, otherwise they will be unused codes. Do you accept that I split this PR into these two PRs?

PR containing alloc::raw_rc + alloc::rc changes: this one will still contain a large chunk of code, which I don’t have a good way to further split.
PR containing alloc::sync changes.

thaliaarchi · 2025-05-15T23:23:28Z

Alternatively, an approach to consider, if splitting horizontally isn’t feasible, you could split it vertically: Split it into a commit history of discrete, atomic steps progressing towards the goal of the PR. Even if it needs to be merged all at once, this can aid reviewing.

I know the Rust project prefers smaller PRs, though, so that should be preferred if possible, but the approaches could be combined.

joboet · 2025-05-16T12:29:55Z

@joboet: The majority codes are in alloc::raw_rc module, which has to be submitted with at least one of alloc::rc and alloc::sync changes, otherwise they will be unused codes. Do you accept that I split this PR into these two PRs?
1. PR containing `alloc::raw_rc` + `alloc::rc` changes: this one will still contain a large chunk of code, which I don’t have a good way to further split.

2. PR containing `alloc::sync` changes.

That sounds very reasonable!

rustbot assigned jhpratt Nov 3, 2024

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Nov 3, 2024

EFanZh force-pushed the zero-cost-rc-arc-deref branch from b283c44 to ae36f44 Compare November 3, 2024 09:14

This comment has been minimized.

Sign in to view

EFanZh force-pushed the zero-cost-rc-arc-deref branch from ae36f44 to 0d6165f Compare November 3, 2024 11:21

This comment has been minimized.

Sign in to view

EFanZh force-pushed the zero-cost-rc-arc-deref branch from 0d6165f to 98edd5b Compare November 3, 2024 13:06

This comment has been minimized.

Sign in to view

rustbot assigned joboet and unassigned jhpratt Nov 3, 2024

EFanZh force-pushed the zero-cost-rc-arc-deref branch from 98edd5b to 8beb51d Compare November 4, 2024 16:29

This comment has been minimized.

Sign in to view

EFanZh force-pushed the zero-cost-rc-arc-deref branch from 8beb51d to d7879fa Compare November 4, 2024 17:26

This comment has been minimized.

Sign in to view

EFanZh force-pushed the zero-cost-rc-arc-deref branch from d7879fa to 317aa0e Compare November 4, 2024 18:40

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 8, 2024

EFanZh force-pushed the zero-cost-rc-arc-deref branch 3 times, most recently from f243654 to 1308bf6 Compare November 11, 2024 18:35

thaliaarchi reviewed Mar 28, 2025

View reviewed changes

library/alloc/src/raw_rc/mod.rs Show resolved Hide resolved

library/alloc/src/raw_rc/raw_rc.rs Show resolved Hide resolved

joboet requested changes Mar 28, 2025

View reviewed changes

rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 28, 2025

EFanZh force-pushed the zero-cost-rc-arc-deref branch 2 times, most recently from 376c802 to ac5a4e6 Compare March 29, 2025 12:16

This comment has been minimized.

Sign in to view

EFanZh force-pushed the zero-cost-rc-arc-deref branch from ac5a4e6 to 41d9c4c Compare March 29, 2025 13:01

This comment has been minimized.

Sign in to view

EFanZh force-pushed the zero-cost-rc-arc-deref branch from 41d9c4c to 9d4fbaf Compare March 29, 2025 13:40

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Mar 29, 2025

EFanZh force-pushed the zero-cost-rc-arc-deref branch 3 times, most recently from a72c6d5 to 2ae47dd Compare March 30, 2025 06:42

EFanZh force-pushed the zero-cost-rc-arc-deref branch from 2ae47dd to 7999ed8 Compare May 1, 2025 02:26

EFanZh requested review from joboet, scottmcm and thaliaarchi May 1, 2025 04:45

jplatte mentioned this pull request May 14, 2025

perf: fn Rav1dFrameData::{seq,frame}_hdr: Remove .unwrap() and Arc::deref overhead memorysafety/rav1d#751

Open

Make Rc<T>::deref and Arc<T>::deref zero-cost

369a658

EFanZh force-pushed the zero-cost-rc-arc-deref branch from 7999ed8 to 369a658 Compare May 17, 2025 02:28

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Make `Rc<T>::deref` and `Arc<T>::deref` zero-cost #132553

Make `Rc<T>::deref` and `Arc<T>::deref` zero-cost #132553

EFanZh commented Nov 3, 2024 •

edited

Loading

rustbot commented Nov 3, 2024

This comment has been minimized.

marmeladema commented Nov 3, 2024

This comment has been minimized.

EFanZh commented Nov 3, 2024

This comment has been minimized.

This comment has been minimized.

jhpratt commented Nov 3, 2024

This comment has been minimized.

This comment has been minimized.

joboet commented Nov 7, 2024

EFanZh commented Nov 7, 2024 •

edited

Loading

joboet commented Nov 8, 2024

thaliaarchi left a comment

joboet left a comment

joboet Mar 27, 2025

EFanZh Mar 29, 2025 •

edited

Loading

joboet Mar 27, 2025

EFanZh Mar 29, 2025

joboet Mar 27, 2025

EFanZh Mar 29, 2025

This comment has been minimized.

This comment has been minimized.

EFanZh commented Mar 29, 2025

bors commented Mar 29, 2025

bors commented Apr 28, 2025

bors commented May 7, 2025

joboet commented May 15, 2025

EFanZh commented May 15, 2025 •

edited

Loading

thaliaarchi commented May 15, 2025

joboet commented May 16, 2025

Make Rc<T>::deref and Arc<T>::deref zero-cost #132553

Are you sure you want to change the base?

Make Rc<T>::deref and Arc<T>::deref zero-cost #132553

Conversation

EFanZh commented Nov 3, 2024 • edited Loading

rustbot commented Nov 3, 2024

This comment has been minimized.

marmeladema commented Nov 3, 2024

This comment has been minimized.

EFanZh commented Nov 3, 2024

This comment has been minimized.

This comment has been minimized.

jhpratt commented Nov 3, 2024

This comment has been minimized.

This comment has been minimized.

joboet commented Nov 7, 2024

EFanZh commented Nov 7, 2024 • edited Loading

joboet commented Nov 8, 2024

thaliaarchi left a comment

Choose a reason for hiding this comment

joboet left a comment

Choose a reason for hiding this comment

joboet Mar 27, 2025

Choose a reason for hiding this comment

EFanZh Mar 29, 2025 • edited Loading

Choose a reason for hiding this comment

joboet Mar 27, 2025

Choose a reason for hiding this comment

EFanZh Mar 29, 2025

Choose a reason for hiding this comment

joboet Mar 27, 2025

Choose a reason for hiding this comment

EFanZh Mar 29, 2025

Choose a reason for hiding this comment

This comment has been minimized.

This comment has been minimized.

EFanZh commented Mar 29, 2025

bors commented Mar 29, 2025

bors commented Apr 28, 2025

bors commented May 7, 2025

joboet commented May 15, 2025

EFanZh commented May 15, 2025 • edited Loading

thaliaarchi commented May 15, 2025

joboet commented May 16, 2025

Make `Rc<T>::deref` and `Arc<T>::deref` zero-cost #132553

Make `Rc<T>::deref` and `Arc<T>::deref` zero-cost #132553

EFanZh commented Nov 3, 2024 •

edited

Loading

EFanZh commented Nov 7, 2024 •

edited

Loading

EFanZh Mar 29, 2025 •

edited

Loading

EFanZh commented May 15, 2025 •

edited

Loading