Make Rc<T>::deref zero-cost

[EFanZh]

View all comments

This PR makes Rc::deref zero-cost by changing the internal pointer to point directly to the value instead of to the allocation.

This PR is split from #132553, which will also make Arc::deref zero-cost.

Review status:

• 8d8878a Add RefCounts and RcLayout types
• abe9c27 Add allocation functions
• cfa6ea8 Add RefCounter trait
• 77755f0 Add RawWeak type
• 7fce1c4 Add RawWeak methods for sized values
• adddf22 Add RawWeak methods for slice values
• 99522fc Implement necessary traits for RawWeak
• 393e377 Add RawRc type
• 6cb537c Add RawRc methods for sized values
• 6b47771 Add RawRc methods for MaybeUninit<T> values
• 9184466 Add RawRc methods for slice values
• 33881a5 Add RawRc methods for dyn Any type
• 17e84c6 Implement necessary traits for RawRc
• 20e0aba Add RawUniqueRc type
• 82525d0 Add RawUniqueRc methods for sized values
• 8bc9dea Implement necessary traits for RawUniqueRc
• cee99e8 Implement alloc::rc::{Rc,Weak,UniqueRc} with alloc::raw_rc types
• 2676c63 (HEAD -> zero-cost-rc-deref) Add LLVM codegen tests for new Rc implementation

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

[oli-obk]

@bors try @rust-timer queue

[bors]

⌛ Trying commit f5245ba with merge 8ef4a25...

[bors]

☀️ Try build successful - checks-actions
Build commit: 8ef4a25 (8ef4a25b05973cfbd577205c507a891d07f0ae5f)

[rust-timer]

Finished benchmarking commit (8ef4a25): comparison URL.

Overall result: ❌✅ regressions and improvements - please read the text below

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR may lead to changes in compiler perf.

Next Steps: If you can justify the regressions found in this try perf run, please indicate this with @rustbot label: +perf-regression-triaged along with sufficient written justification. If you cannot justify the regressions please fix the regressions and do another perf run. If the next run shows neutral or positive results, the label will be automatically removed.

@bors rollup=never
@rustbot label: -S-waiting-on-perf +perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	0.5%	[0.2%, 0.7%]	4
Regressions ❌ (secondary)	1.1%	[0.2%, 2.5%]	9
Improvements ✅ (primary)	-1.0%	[-2.0%, -0.5%]	7
Improvements ✅ (secondary)	-1.3%	[-2.0%, -0.1%]	4
All ❌✅ (primary)	-0.5%	[-2.0%, 0.7%]	11

Max RSS (memory usage)

Results (primary -0.3%, secondary -0.0%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	8.4%	[8.4%, 8.4%]	1
Regressions ❌ (secondary)	3.1%	[2.0%, 4.8%]	6
Improvements ✅ (primary)	-4.6%	[-7.1%, -2.1%]	2
Improvements ✅ (secondary)	-4.7%	[-6.4%, -2.9%]	4
All ❌✅ (primary)	-0.3%	[-7.1%, 8.4%]	3

Cycles

Results (primary -0.5%, secondary -1.9%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.9%	[0.9%, 0.9%]	1
Regressions ❌ (secondary)	2.1%	[2.1%, 2.1%]	2
Improvements ✅ (primary)	-1.9%	[-1.9%, -1.9%]	1
Improvements ✅ (secondary)	-3.9%	[-9.3%, -1.5%]	4
All ❌✅ (primary)	-0.5%	[-1.9%, 0.9%]	2

Binary size

Results (primary 0.2%, secondary 1.6%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	0.3%	[0.0%, 1.8%]	29
Regressions ❌ (secondary)	1.8%	[0.0%, 6.4%]	9
Improvements ✅ (primary)	-0.3%	[-0.6%, -0.1%]	5
Improvements ✅ (secondary)	-0.4%	[-0.4%, -0.4%]	1
All ❌✅ (primary)	0.2%	[-0.6%, 1.8%]	34

Bootstrap: 775.728s -> 776.531s (0.10%)
Artifact size: 366.25 MiB -> 366.33 MiB (0.02%)

[apiraino]

Would anyone comment the perf. run? cc @EFanZh thanks!

@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[rust-bors]

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

[clarfonthey]

@tgross35 what is the status of reviewing this? Mostly because I think that we want this and it's blocking work for custom allocators on these types, and I keep seeing it rebased without any review progress. Would be willing to help take over review after RustConf if you don't have the bandwidth.

[tgross35]

? I don't think I clicked comment, sorry that reply wasn't complete

Yeah this is something that I haven't been able to completely review, and the others I've talked to also haven't been able to pick it up—just massive surface area rewriting some critical API. More recently we talked about doing a group review to make it more feasible, I'll loop you in for that