0

I have asked a couple of questions here relating to the heap and with all the answers I get I am not sure what is the importance of making a distinction of heap in Rust.

To explain where I am coming from. I have mostly developed in Java, and there is a clear case for what goes on the stack and what goes on the heap. For example if there is a primitive version of a type, it is advisable to use that (since this will be on the stack) instead of using one that will create an object (which will go on the heap and be work for the garbage collector)

So there is a clear distinction of what goes to the heap and what goes to the stack in everyday programming.

But in Rust this does not seem to be the case.

In Is Clone for copying on the heap, while Copy for copying on the stack in Rust? I was made to understand that Copy/Clone is not dependent on Stack/Heap. My initial wrong impression was, cloning occurs only with value on the heap (I think this also comes from my Java background, where cloning applies to objects and those are values that live on the heap)

Then in Are Dynamically Sized Typed always on the heap? I was also made to know that DSTs can exist both on the heap and also on the stack.

So right now I am not sure of the importance of having this distinction between memory regions in Rust. Because it seems things that can be done on one can be done on the other. And values that can be place on one can also be placed on the other.

What am I missing? And what is the practical repercussion of these two memory regions in Rust. By practical repercussion, I am thinking of distinct properties that is only possible with one region and not with the other.

Federico klez Culloca
  • 26,308
  • 17
  • 56
  • 95
Finlay Weber
  • 2,989
  • 3
  • 17
  • 37
  • "I have mostly developed in Java, and there is a clear case for what goes on the stack and what goes on the heap" – Actually, Java has neither a stack nor a heap. You will not find anything about a stack or a heap in the Java Language Specification. (The *word* "heap" appears a couple of times, but only as the compound term "heap pollution" which is simply the name for a specific kind of type-unsafety and has nothing to do with a heap as you are using the term.) – Jörg W Mittag Oct 15 '22 at 10:00
  • Also, even for implementations that *do* use a heap and a stack (which, again, is simply a private internal implementation choice of the author of that implementation and in no way mandated by the JLS), they will move allocations from the heap to the stack (e.g. using Escape Analysis in Oracle HotSpot) or from the stack to the heap (e.g. using Escape Analysis in Azul Zing). – Jörg W Mittag Oct 15 '22 at 10:02
  • The heap incurs an overhead. So in any language one prefers the stack by default, and only uses the heap when required. You can indeed `clone` values whether they're on the stack or the heap in Rust. Precisely what `clone` involves depends. At times it's just the *reference* to heap memory being cloned (and a counter incremented), as is the case with a `Rc`. If you clone a struct on the stack it would be all the data, no matter how large. Re: when we _need_ the heap, consider `Box`, `String`, `Rc` and `Vec` individually. – jsstuball Oct 15 '22 at 10:40
  • The conclusion I am making is the following (please correct me If am wrong). Stack and Heap are just memory regions. They mainly differ in the way they are managed and house cleaning is performed. If you want to use a memory location where you do not have to clean up after yourself and let the stack frame being destroyed also destroy your values, then go with Stack...if you want values held in a place that is not tied to the lifecycle of the stackframe, then put the value on the heap - only that you need to take care of house cleaning yourself – Finlay Weber Oct 15 '22 at 14:54

0 Answers0