Structs are currently always allocated "inline" in their container. So if the struct is the type of a struct property, the outer struct will include enough space for the inner struct; if the struct is the type of a class property, the class's instance size will include enough space for the struct; and if the struct is the type of a local variable, there will generally be that many bytes allocated in the stack frame.
There are two exceptions to that, both relating to situations where an arbitrarily-sized type needs to be fit into something fixed-size.
In generic code, we don't know how large an unconstrained type argument will take up, so if a function that's generic over some type T has a local variable of type T, we have to allocate space for that somehow. Today, that's done by allocating an inline buffer of 3 words and then using malloc if it spills over that. But we're exploring using dynamic stack allocations instead, like C's alloca() function; if that works out, we'll eliminate of the two cases.
The other case comes up with protocol types. A protocol type inherently has to have *some* fixed size, so it's an unavoidable limitation that *some* types will need to be allocated out-of-line when stored into a protocol value.
On Dec 20, 2016, at 9:14 AM, Sergo Bero via swift-dev <email@example.com> wrote:
I have a question about Swift Structs, regarding memory usage...
as WWDC talk ( Session 416 ) says, Swift uses heap memory to store large values ( contain more than 3 words as current inline buffer is 3 words ),
has something changed in this area since WWDC?
What are the advantages from copying it to heap?
is current behaviour final and will it be “baked” into Swift ABI?
is it possible to tell compiler ( or force ) to always use stack for value types ?