# Why mutable structs are allocated on the heap?
**URL:** https://discourse.julialang.org/t/why-mutable-structs-are-allocated-on-the-heap/12992
**Category:** General Usage
**Tags:** question
**Created:** [August 7, 2018, 2:02pm UTC](https://discourse.julialang.org/t/why-mutable-structs-are-allocated-on-the-heap/12992 "2018-08-07T14:02:04Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@e3c6](https://discourse.julialang.org/u/e3c6)
#### Post date: [August 7, 2018, 2:02pm UTC](https://discourse.julialang.org/t/why-mutable-structs-are-allocated-on-the-heap/12992/1 "2018-08-07T14:02:04Z")
From [https://docs.julialang.org/en/latest/manual/types/#Mutable-Composite-Types-1:](https://docs.julialang.org/en/latest/manual/types/#Mutable-Composite-Types-1:)
> In order to support mutation, such objects are generally allocated on the heap, and have stable memory addresses.
If I define:
```julia
mutable struct MyT
x::Int
end
```
and then use `MyT` inside a function, such as:
```julia
function f(x::Int)
q = MyT(x);
q.x += 1
return q.x
end
```
I would expect `q` to be allocated on the stack, because it is a local variable that does not change type and `MyT` is `isbits`. But it is not:
`@btime f(1) # 3.781 ns (1 allocation: 16 bytes)`
Why?
---
### Author:  [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)
#### Post date: [August 7, 2018, 2:06pm UTC](https://discourse.julialang.org/t/why-mutable-structs-are-allocated-on-the-heap/12992/2 "2018-08-07T14:06:18Z")
Julia has many optimisations, eliminating unnecessary allocations is one of them.
---
### Author:  [@e3c6](https://discourse.julialang.org/u/e3c6)
#### Post date: [August 7, 2018, 2:12pm UTC](https://discourse.julialang.org/t/why-mutable-structs-are-allocated-on-the-heap/12992/3 "2018-08-07T14:12:16Z")
But in this case the allocation seems unnecessary, yet it occurs. Or am I missing something?
---
### Author:  [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)
#### Post date: [August 7, 2018, 2:13pm UTC](https://discourse.julialang.org/t/why-mutable-structs-are-allocated-on-the-heap/12992/4 "2018-08-07T14:13:57Z")
Sorry, on 0.7 this optimization is much more effective:
```julia
julia> @btime f(1)
1.503 ns (0 allocations: 0 bytes)
2
julia> VERSION
v"0.7.0-rc3.3"
```
---
### Author:  [@e3c6](https://discourse.julialang.org/u/e3c6)
#### Post date: [August 7, 2018, 2:15pm UTC](https://discourse.julialang.org/t/why-mutable-structs-are-allocated-on-the-heap/12992/5 "2018-08-07T14:15:11Z")
Is there an easy to state rule to know when something will be allocated on the heap vs. the stack? If not, is there a macro (something like `@code_warntype`) that alerts me when a variable is heap allocated?
---
### Author:  [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)
#### Post date: [August 7, 2018, 2:16pm UTC](https://discourse.julialang.org/t/why-mutable-structs-are-allocated-on-the-heap/12992/6 "2018-08-07T14:16:50Z")
0.6:
```julia
julia> @code_typed f(1)
CodeInfo(:(begin
q = $(Expr(:new, :(Main.MyT), :(x))) # line 3:
SSAValue(0) = (Base.add_int)((Core.getfield)(q, :x)::Int64, 1)::Int64
(Core.setfield!)(q, :x, SSAValue(0))::Int64 # line 4:
return (Core.getfield)(q, :x)::Int64
end))=>Int64
```
0.7
```julia
julia> @code_typed f(1)
CodeInfo(
3 1 ─ %1 = (Base.add_int)(x, 1)::Int64 │╻ +
└── goto #3 if not false │
2 ─ nothing::Nothing │
4 3 ─ return %1 │
) => Int64
```
Can see that the `new` call creating the mutable type is elided.
---
### Author:  [@e3c6](https://discourse.julialang.org/u/e3c6)
#### Post date: [August 7, 2018, 2:19pm UTC](https://discourse.julialang.org/t/why-mutable-structs-are-allocated-on-the-heap/12992/7 "2018-08-07T14:19:17Z")
Thanks.
---
### Author:  [@e3c6](https://discourse.julialang.org/u/e3c6)
#### Post date: [August 7, 2018, 3:30pm UTC](https://discourse.julialang.org/t/why-mutable-structs-are-allocated-on-the-heap/12992/8 "2018-08-07T15:30:46Z")
One more question. If I have a vector of `mutable structs` such as this one (which only contain isbits fields), the vector will be a pointer to a list of pointers to the structs, or a single pointer to a single chunk of memory with all the structs?
---
### Author:  [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)
#### Post date: [August 7, 2018, 3:33pm UTC](https://discourse.julialang.org/t/why-mutable-structs-are-allocated-on-the-heap/12992/9 "2018-08-07T15:33:25Z")
They will not lie contiguously in memory.
---
### Author:  [@e3c6](https://discourse.julialang.org/u/e3c6)
#### Post date: [August 7, 2018, 3:36pm UTC](https://discourse.julialang.org/t/why-mutable-structs-are-allocated-on-the-heap/12992/10 "2018-08-07T15:36:46Z")
Is there a way to force a contiguous block? Like for instance perhaps casting the Vector to a Tuple might be a good idea in this case?
---
### Author:  [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)
#### Post date: [August 7, 2018, 3:58pm UTC](https://discourse.julialang.org/t/why-mutable-structs-are-allocated-on-the-heap/12992/11 "2018-08-07T15:58:12Z")
> [@e3c6](#):
>
> Is there a way to force a contiguous block?
Don’t use `mutable`
---
### Author:  [@Stephen\_Vavasis](https://discourse.julialang.org/u/Stephen_Vavasis)
#### Post date: [August 8, 2018, 2:19pm UTC](https://discourse.julialang.org/t/why-mutable-structs-are-allocated-on-the-heap/12992/12 "2018-08-08T14:19:29Z")
Just to elaborate on this a bit: if you want a contiguous array of structs, then they need to be immutable. But suppose you want to change a field in one of those structs? The Julian way to do it is to copy the whole struct over and then count on compiler optimizations to elide needless work. For example, here is a function (not tested) that changes one field of a struct that lives inside of an array:
```julia
struct A
a::Int
b::Bool
end
function changeb!(v::Vector{A}, ind, newb::Bool)
v[ind] = A(v[ind].a, newb)
nothing
end
```
For a struct that has many fields, this can get awkward. I wrote a macro a long time ago to automatically generate the above kind of code, but I haven’t used it recently, and I’m not sure it works any more. I suspect someone else may have a package for this purpose.
---
### Author:  [@tk3369](https://discourse.julialang.org/u/tk3369)
#### Post date: [August 8, 2018, 2:57pm UTC](https://discourse.julialang.org/t/why-mutable-structs-are-allocated-on-the-heap/12992/13 "2018-08-08T14:57:49Z")
Can they lie contiguously in memory when all attributes of the mutable struct are fixed length eg bits type?
---
### Author:  [@Gnimuc](https://discourse.julialang.org/u/Gnimuc)
#### Post date: [August 8, 2018, 3:27pm UTC](https://discourse.julialang.org/t/why-mutable-structs-are-allocated-on-the-heap/12992/14 "2018-08-08T15:27:30Z")
[https://github.com/simonster/StructsOfArrays.jl](https://github.com/simonster/StructsOfArrays.jl)
A little bit off-topic: this might be useful if you want every field in the immutable struct stored contiguously in memory.
---
### Author:  [@Stephen\_Vavasis](https://discourse.julialang.org/u/Stephen_Vavasis)
#### Post date: [August 8, 2018, 3:32pm UTC](https://discourse.julialang.org/t/why-mutable-structs-are-allocated-on-the-heap/12992/15 "2018-08-08T15:32:14Z")
The issue of mutable/immutable structs is orthogonal to the issue of whether its fields are bits/nonbits. In other words, a particular mutable struct may have only bits objects, but it is still mutable (one can change the fields individually). Similarly, an immutable struct may have nonbits entries, but it is still immutable (one cannot change the fields individually). In terms of the memory layout, for both mutable and immutable, a nonbits field is stored via a pointer inside the struct, whereas a bits field is stored directly. (Note: the compiler is allowed to emit code that implements these properties differently for the purpose of improving performance as long as the results are indistinguishable from this description.)
For an array of structs, as Kristoffer Carlsson said, there is contiguous memory layout only for immutable structs. And if those immutable structs contain nonbits fields, then each struct object in the array internally will have pointers, so the data in the array may still be scattered.
---
### Author:  [@e3c6](https://discourse.julialang.org/u/e3c6)
#### Post date: [August 9, 2018, 4:21pm UTC](https://discourse.julialang.org/t/why-mutable-structs-are-allocated-on-the-heap/12992/16 "2018-08-09T16:21:49Z")
Note that Julia `isbits` returns false for a mutable struct, even if all the fields are `isbits`. I agree with the distinction of mutable/immutable vs. bits/nonbits… but then why `isbits` behaves like this?
---
### Author:  [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)
#### Post date: [August 9, 2018, 4:25pm UTC](https://discourse.julialang.org/t/why-mutable-structs-are-allocated-on-the-heap/12992/17 "2018-08-09T16:25:46Z")
> [@e3c6](#):
>
> but then why `isbits` behaves like this
This explains it quite well I think:
```julia
help?> isbits
search: isbits isbitstype disable_sigint
isbits(x)
Return true if x is an instance of an isbitstype type.
help?> isbitstype
search: isbitstype
isbitstype(T)
Return true if type T is a "plain data" type, meaning it is immutable and contains no references to other values,
only primitive types and other isbitstype types. Typical examples are numeric types such as UInt8, Float64, and
Complex{Float64}. This category of types is significant since they are valid as type parameters, may not track
isdefined / isassigned status, and have a defined layout that is compatible with C.
Examples
≡≡≡≡≡≡≡≡≡≡
julia> isbitstype(Complex{Float64})
true
julia> isbitstype(Complex)
false
```
---
### Author:  [@Raf](https://discourse.julialang.org/u/Raf)
#### Post date: [August 9, 2018, 4:32pm UTC](https://discourse.julialang.org/t/why-mutable-structs-are-allocated-on-the-heap/12992/18 "2018-08-09T16:32:26Z")
[Setfeild.jl](https://github.com/jw3126/Setfield.jl) does this.
---
### Author:  [@e3c6](https://discourse.julialang.org/u/e3c6)
#### Post date: [August 22, 2018, 12:39pm UTC](https://discourse.julialang.org/t/why-mutable-structs-are-allocated-on-the-heap/12992/19 "2018-08-22T12:39:35Z")
I’m still a bit confused about why mutable structs, even if all its fields are `isbits`, might require heap allocation. If a variable is defined in a function scope, and not returned, it can be safely deleted after the function scope exits. Then what’s wrong with stack allocating it (whether it is of mutable or immutable type, but with all fields of `isbits` type so it has a compile-time defined size), as long as its inside a function? Is there a simple example where this does not work?
---
### Author:  [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)
#### Post date: [August 22, 2018, 12:43pm UTC](https://discourse.julialang.org/t/why-mutable-structs-are-allocated-on-the-heap/12992/20 "2018-08-22T12:43:03Z")
> [@e3c6](#):
>
> If a variable is defined in a function scope, and not returned, it can be safely deleted after the function scope exits.
Eliding allocations when a non isbits struct is created and known not to escape is an optimization that is already happening.
But the discussion above was about how they will be stored in an Array?
[Next page](https://discourse.julialang.org/t/why-mutable-structs-are-allocated-on-the-heap/12992.md?page=2)