Why does the Rust compiler not reuse the memory on the stack after an object is moved?

Question

I thought that once an object is moved, the memory occupied by it on the stack can be reused for other purpose. However, the minimal example below shows the opposite.

#[inline(never)] fn consume_string(s: String) { drop(s); } fn main() { println!( "String occupies {} bytes on the stack.", std::mem::size_of::<String>() ); let s = String::from("hello"); println!("s at {:p}", &s); consume_string(s); let r = String::from("world"); println!("r at {:p}", &r); consume_string(r); }

After compiling the code with --release flag, it gives the following output on my computer.

String occupies 24 bytes on the stack. s at 0x7ffee3b011b0 r at 0x7ffee3b011c8

It is pretty clear that even if s is moved, r does not reuse the 24-byte chunk on the stack that originally belonged to s. I suppose that reusing the stack memory of a moved object is safe, but why does the Rust compiler not do it? Am I missing any corner case?

Update: If I enclose s by curly brackets, r can reuse the 24-byte chunk on the stack.

#[inline(never)] fn consume_string(s: String) { drop(s); } fn main() { println!( "String occupies {} bytes on the stack.", std::mem::size_of::<String>() ); { let s = String::from("hello"); println!("s at {:p}", &s); consume_string(s); } let r = String::from("world"); println!("r at {:p}", &r); consume_string(r); }

The code above gives the output below.

String occupies 24 bytes on the stack. s at 0x7ffee2ca31f8 r at 0x7ffee2ca31f8

I thought that the curly brackets should not make any difference, because the lifetime of s ends after calling comsume_string(s) and its drop handler is called within comsume_string(). Why does adding the curly brackets enable the optimization?

The version of the Rust compiler I am using is given below.

rustc 1.54.0-nightly (5c0292654 2021-05-11) binary: rustc commit-hash: 5c029265465301fe9cb3960ce2a5da6c99b8dcf2 commit-date: 2021-05-11 host: x86_64-apple-darwin release: 1.54.0-nightly LLVM version: 12.0.1

Update 2: I would like to clarify my focus of this question. I want to know the proposed "stack reuse optimization" lies in which category.

This is an invalid optimization. Under certain cases the compiled code may fail if we perform the "optimization".
This is a valid optimization, but the compiler (including both rustc frontend and llvm) is not capable of performing it.
This is a valid optimization, but is temporarily turned off, like this.
This is a valid optimization, but is missed. It will be added in the future.

As stated in the rest of the answer in the linked question, it is up to LLVM to choose whether to reuse the address space for different objects in memory, and observing addresses to values in a stack can influence the compilation output. The Rust compiler itself does not impose one behavior or the other. — E_net4
– E_net4, Commented May 12, 2021 at 10:29
@trentcl I'll push back again on the idea that printing should drop the optimisation: taking references is absolutely ubiquitous in rust, most method calls will do that. If that's sufficient to deopt then we have a problem (if not a big one). Though Emoun's investigation below seems to hint that the issue might be elsewhere. — Masklinn
– Masklinn, Commented May 12, 2021 at 12:04
@Masklinn You are mistaken. Taking a reference by itself does not inhibit optimizations because the address of the object does not have any observable effect on the behavior of the code. Printing or otherwise observing the address of an object directly does inhibit optimizations because the optimizer must use non-local reasoning to conclude that "any" value is allowed to be printed. — trent
– trent, Commented May 12, 2021 at 12:20
@trentcl I just created another example. godbolt.org/z/TEY76Wsjj In this example, (1) .push_str() forces the String instances to occupy space on the stack (2) no observable behavior is altered because nothing is observable (3) the space is not reused after s ends its lifetime — Zhiyao
– Zhiyao, Commented May 12, 2021 at 13:50

Emoun · Accepted Answer · 2021-05-12 11:08:08Z

My TLDR conclusion: A missed optimization opportunity.

So the first thing I did was look into whether your consume_string function actually makes a difference. To do this I created the following (a bit more) minimal example:

struct Obj([u8; 8]); fn main() { println!( "Obj occupies {} bytes on the stack.", std::mem::size_of::<Obj>() ); let s = Obj([1,2,3,4,5,6,7,8]); println!("{:p}", &s); std::mem::drop(s); let r = Obj([11,12,13,14,15,16,17,18]); println!("{:p}", &r); std::mem::drop(r); }

Instead of consume_string I use std::mem::drop which is dedicated to simply consuming an object. This code behaves just like yours:

Obj occupies 8 bytes on the stack. 0x7ffe81a43fa0 0x7ffe81a43fa8

Removing the drop doesn't affect the result.

So the question is then why rustc doesn't notice that s is dead before r goes live. As your second example shows, enclosing s in a scope will allow the optimization.

Why does this work? Because the Rust semantics dictate that an object is dropped at the end of its scope. Since s is in an inner scope, it is dropped before the scope exits. Without the scope, s is alive until the main function exits.

Why doesn't it work when moving s into a function, where it should be dropped on exit? Probably because rust doesn't correctly flag the memory location used by s as free after the function call. As has been mentioned in the comments, it is LLVM that actually handles this optimization (called 'Stack Coloring' as far as I can tell), which means rustc must correctly tell it when the memory is no longer in use. Clearly, from your last example, rustc does it on scope exit, but apparently not when an object is moved.

I wouldn't call it obvious optimization, it's more to you want to use as little stack as possible versus not. The code run the same speed anyway.
@Stargateur If you take cache into account, smaller memory footprint gives better locality and less cache miss, so the code will run faster. Also, on embedded systems, RAM is rare, the optimization can make a difference.
In this specific case it probably doesn't matter much, using more/less stack is likely affect performance in the real-world so larger functions could benefit from optimization as this. Also, this optimization is enabled in LLVM for -O0 and above, so they have clearly decided it is almost always worth it.
Evicting a cache line might cause other data reads/writes to miss. E.g. the function could evict a cache line used by its caller, which means the caller might later get a miss.

Peace · Accepted Answer · 2021-05-14 00:12:02Z

i think the fn drop do not free the memory of S, just call the fn drop. in first case the s still use the stack memory, rust can not be reused. in second case, because the {} scope, the memory is free. so the stack memory reused

Collectives™ on Stack Overflow

Why does the Rust compiler not reuse the memory on the stack after an object is moved?

2 Answers 2

6 Comments

Comments

Linked

Hot Network Questions

Collectives™ on Stack Overflow

2 Answers 2

6 Comments

Comments

Linked

Related