Rainer Stropek - Memory Management in Rust
Вставка
- Опубліковано 25 січ 2024
- This session is for people who are rather new to Rust or who are curious about why so many developers are passionate about the programming language. It aims to unravel the unique facets of Rust's memory management, including Ownership/Borrowing, Stack/Heap allocation, Reference Counting, and Lifetimes. Rainer will present a similar session at the upcoming OOP conference, so this is kind of his rehearsal.
Source: github.com/rstropek/rust-samp... - Наука та технологія
I appreciate you defining who the expected audience is and the general expectations at the beginning.
Wow, this was a great presentation! I just started learning rust this month learned a lot by this look behind the scenes. Well done!
When you're talking about Rc and multiple ownership, I don't like "you need synchronization" as an explanation for why mutable borrows are forbidden. That's not an issue in a single-threaded context. The real reason as I understand it is that Rust wants to guarantee that while you hold a read-only reference, the data it points to won't change. This is a useful property both for humans trying to reason about the program and for the compiler to make optimizations (if you can alias a mutable reference, the compiler has to assume writes might've changed data pointed to by read-only references.)
It is more than that: even in single-threaded applications there is the problem of "spooky action at a distance" in C and C++, where some part of a program alters things through a totally different path to the data than another part - and, as there is this "cast const away" on function parameters in C and C++, surprisingly within a function or method taking a const reference. Then there is async - absent in C and IIRC only planned for C++ - where a single thread acts on a list of tasks in turn, suspending a task if it is awaiting another async task to complete and turn to the next. Concurrency and parallelism is where Rust runs circles around C and C++.
this is the best explained, especially using assembly
I think the last part of multiple &mut not showing an error is because RefCell does borrow checking at runtime and not compile time
Yes, exactly
Loved this! I really enjoyed the enthusiasm.
Am just starting up with Rust, thank you was a great talk.
Amazing video
It was amazing :)
yess!
Me favourite type of teaching
At 5:36 you said it was allocating on the heap when you meant the stack (rsp adjustment).
@rstropek, can you please explain what went wrong with the last demo, now you’ve had some time to reflect upon it?
Edit: ah, you explained at 53:30, although I don’t think you should have borrowed from the samwise *copy* since I think you wanted to demonstrate multiple mutable borrows from the *same* RefCell, which would have been Frodo’s.
You are inconsistent with respect to c# guys - their struct objects are stack allocated.
Also destructors in c++ work pretty much same as in rust, except for the move semantics. Would be nice to make distinction clear there.
Yeah, you can also stack allocate an array with stackalloc keyword
I'm just before the "multiple owners" section, so I'm pretty sure you don't cover it:
When you transfer ownership into a function argument, does it copy the data into there? I assume there's no version of referencing at that point.
Unless it's a Copy type, no. Ownership is a zero-cost abstration. It only exists at compile time, and the compiler is smart enough to only copy data when it has to.
Unless the passed type implements the Copy trait, the data is passed into the function by reference (as in C++), and the caller has no longer access to the data (as not in C++) - this means it was "moved" and ownership was transferred. So the rule of thumb here is: ownership changes if a type does not have the Copy trait (this is true for assignments of one variable to another as well). If it has (like for all scalar basic types in Rust like integers or floats), then the called function receives a copy of the argument (it is still possible to pass a reference of such a type into a function, and if the function takes it as a mutable reference, the function can even alter the data with the caller seeing it). The Copy trait has the semantics that if you do a memcpy of that type to a different memory area you obtain an independent copy of all data contained. Types that contain references to other data cannot implement Copy. They may be able to implement Clone, if all their parts implement Clone. Clone is expensive, it is a deep copy of a data structure. Clone is never invoked without the programmer explicitly calling for it. Whereas Copy is.