`std::thread::Thread` grew from one to two pointer sizes

[ginnyTheCat]

Caused by the changes in #123550 the size of std::thread::Thread grew from one to two pointer sizes.

The docs don't promise Thread to have a certain size so I'm not quite sure whether this would be considered a breaking change. It doesn't seem however like this was noticed/acknowledged in the PR, as having a larger thread handle might negate the benefits that PR brought with it.

Code

I tried this code:

let pointer_size = size_of::<*const ()>();
let thread_size = size_of::<std::thread::Thread>();
assert_eq!(pointer_size, thread_size);

I expected to see this happen: it to run successfully

Instead, this happened: the assert is unfulfilled and it panics

Version it worked on

It most recently worked on: Rust 1.82

Version with regression

rustc --version --verbose:

rustc 1.84.0-nightly (b8c8287a2 2024-11-03)
binary: rustc
commit-hash: b8c8287a229cd79604aa84c25e1235fc78cd5f2e
commit-date: 2024-11-03
host: x86_64-unknown-linux-gnu
release: 1.84.0-nightly
LLVM version: 19.1.3

[GnomedDev]

This performance regression (Thread inline size increasing) only affects code which handles std::thread::Thread, which is going to be much less than programs that hit the rt startup code which previously allocated for this, however this regression isn't impossible to claw back.

Alignment tagging could possibly allow fitting the two pointers into a single one, via even more unsafe code, although that's more unsafe as a maintenance burden.

[workingjubilee]

Yes, unspecified layouts are unspecified and std::thread::Thread can be 1 pointer or 1 kilobyte.

A benchmark that reflects an excerpt from an even vaguely practical program would be useful information, here, to measure any supposed regressions against. Or improvements, for that matter. When you start packing more data into the same eight bytes, it is very easy for packing more data in a smaller space to cost more instructions to actually act on that data.