Swift stack and heap understanding

Question

I want to understand what is stored in the stack and heap in swift. I have a rough estimation: Everything that you print and the memory address appears not the values, those are stored in the stack, and what is printed out as values, those are on the heap, basically according to value and reference types. Am I completely wrong? And optionally, could you provide a visual representation of the stack/heap?

Kayleigh

This presentation explains some of Swift's use of heap and stack: realm.io/news/andy-matuschak-controlling-complexity. In short, you can't make assumptions whether a value or reference will end up on the heap or stack, like you can in C. – Catastrophism

Answer 1

As @Juul stated Reference types are stored in the Heap and values in the stack.

Here is the explanation:

Stack and Heap

Stack is used for static memory allocation and Heap for dynamic memory allocation, both stored in the computer's RAM .

Variables allocated on the stack are stored directly to the memory, and access to this memory is very fast, and its allocation is determined when the program is compiled. When a function or a method calls another function which in turns calls another function, etc., the execution of all those functions remains suspended until the very last function returns its value. The stack is always reserved in a LIFO order, the most recently reserved block is always the next block to be freed. This makes it really simple to keep track of the stack. Freeing a block from the stack is nothing more than adjusting one pointer.

Variables allocated on the heap have their memory allocated at run time, and accessing this memory is a bit slower, but the heap size is only limited by the size of virtual memory. Elements of the heap have no dependencies with each other and can always be accessed randomly at any time. You can allocate a block at any time and free it at any time. This makes it more complex to keep track of which parts of the heap are allocated or free at any given time.

For Escaping Closure:
An important note to keep in mind is that in cases where a value stored on a stack is captured in a closure, that value will be copied to the heap so that it's still available by the time the closure is executed.

For more reference: http://net-informations.com/faq/net/stack-heap.htm

Biotype

An important note to keep in mind is that in case a value stored on a stack is captured in a closure, that value will be moved to the heap so that it's still available by the time the closure is executed. – Chigger

@OleksandrKruk that's true only for escaping closures, as only those can be executed later. – Overpay

@Overpay that's true :), from my experience most of them are escaping though, as a big number of closures are used for delegates/async requests, that's why I mentioned it as something to keep in mind. – Chigger

@Overpay thanks for your comment i updated my answer – Biotype

Because a large part of your answer is copied from here net-informations.com/faq/net/stack-heap.htm it would be good to link it as a reference. – Ist

Answer 2

Classes (reference types) are allocated in the heap, value types (like Struct, String, Int, Bool, etc) live in the stack. See this topic for more detailed answers: Why Choose Struct Over Class?

Solnit

This is no longer true. Swift can optimize some allocations to make them stack allocations when it can prove values don't escape. Value vs reference type is a conceptual difference, it doesn't hinge on where the value is allocated. – Guttural

This optimisation is called "Stack Promotion". I could not find any articles outlining its behaviour online, but you may consult the Swift source code if you're curious. – Enzymolysis

Adding to @Guttural point: there are several more cases when value types go to the heap (it's called Boxing), and reference stay on stack (it's called Stack Promotion). I found this nice article about it – Laynelayney

Answer 3

Stack vs Heap

Stack is a part of thread. It consists of method(function) frames in LIFO order. Method frame contains only local variables. Actually it is method stack trace which you see during debugging or analysing error^[About].

Heap another part of memory where ARC^[About] come in play. It takes more time to allocate memory here(find appropriate place and allocate it in synchronous way).

Theses concepts are the same as [JVM illustration]

Xcode propose you next variant using Debug Memory Graph

*To see Backtrace use:

Edit Scheme... -> <Action> -> Diagnostics -> Malloc Stack Logging

[Value vs Reference type]
[Class vs Struct]

Boccie

Answer 4

Usually when we ask question like this (is it stack or is it heap) we care about performance and are motivated by the desire to avoid the excessive cost of heap allocation. Following the general rule saying that "reference types are heap-allocated and the value types are stack-allocated" may lead to suboptimal design decisions and needs further discussion.

One may falsely conclude that passing around structs (value types) is universally faster than passing classes (reference types) because it never requires heap allocation. Turns out this is not always true.

The important counter-example are protocol types where concrete polymorphic types with value-semantics (structs) implement a protocol, like in this toy example:

protocol Vehicle {
    var mileage: Double { get }
}

struct CombustionCar: Vehicle {
    let mpg: Double
    let isDiesel: Bool
    let isManual: Bool
    var fuelLevel: Double    // gallons
    var mileage: Double { fuelLevel * mpg }
}

struct ElectricCar: Vehicle {
    let mpge: Double
    var batteryLevel: Double // kWh
    var mileage: Double { batteryLevel * mpge / 33.7 }
}

func printMileage(vehicle: Vehicle) {
    print("\(vehicle.mileage)")
}

let datsun: Vehicle = CombustionCar(mpg: 18.19,
                                        isDiesel: false,
                                        isManual: false,
                                        fuelLevel: 12)
let tesla: Vehicle = ElectricCar(mpge: 132,
                                 batteryLevel: 50)
let vehicles: [Vehicle] = [datsun, tesla]
for vehicle in vehicles {
    printMileage(vehicle: vehicle)
}

Note that CombustionCar and ElectricCar objects have different sizes, yet we are able to mix them in an array of Vehicle protocol types. This raises the question: don't the array container elements need to be of the same size? How can the compiler compute the offset of the array element if it doesn't always know the element size at the compile time?

It turns out there's quite a lot of logic under the hood. Swift compiler will create what is called an Existential Container. It's a fixed-sized data structure acting as a wrapper around an object. It this container that gets passed to a function call (is pushed onto the stack) instead of the actual struct.

Existential Container is five words long:

|           |
|valueBuffer|
|           |
|    vwt    |
|    pwt    |

The first three words are called the valueBuffer and this is where actual structure gets stored. Well, that's unless the struct size is greater than three words - in such case the compiler will allocate the struct on the heap and store the reference to it in the valueBuffer:

    STACK                  STACK              HEAP

|   mpge     |         |  reference |-->|     mpg     |
|batteryLevel|         |            |   |   isDiesel  |
|            |         |            |   |   isManual  |
|    vwt     |         |     vwt    |   |   fuelLevel |
|    pwt     |         |     pwt    |

So passing a protocol type object like this to a function may actually require a heap allocation. The compiler will do the allocation and copy the values so you still get the value semantics but the cost will vary depending on whether your struct is 3 words long or more. This renders the "value-types on stack, reference-types on heap" not always correct.

Arv

@joliejuly Here is a great explanation of the topic: developer.apple.com/videos/play/wwdc2016/416 – Backhanded