Reminiscence format of worth varieties in Swift
Reminiscence is only a bunch of 1s and 0s, merely known as bits (binary digits). If we group the stream of bits into teams of 8, we will name this new unit byte (eight bit is a byte, e.g. binary 10010110 is hex 96). We will additionally visualize these bytes in a hexadecimal kind (e.g. 96 A6 6D 74 B2 4C 4A 15 and so on). Now if we put these hexa representations into teams of 8, we’ll get a brand new unit known as phrase).
This 64bit reminiscence (a phrase represents 64bit) format is the fundamental basis of our fashionable x64 CPU structure. Every phrase is related to a digital reminiscence handle which can be represented by a (often 64bit) hexadecimal quantity. Earlier than the x86-64 period the x32 ABI used 32bit lengthy addresses, with a most reminiscence limitation of 4GiB. Thankfully we use x64 these days. 💪
So how can we retailer our knowledge varieties on this digital reminiscence handle area? Properly, lengthy story brief, we allocate simply the correct amount of area for every knowledge sort and write the hex illustration of our values into the reminiscence. It is magic, supplied by the working system and it simply works.
We might additionally begin speaking about reminiscence segmentation, paging, and different low stage stuff, however actually talking I actually do not understand how these issues work simply but. As I am digging deeper and deeper into low stage stuff like this I am studying so much about how computer systems work below the hood.
One vital factor is that I already know and I need to share with you. It’s all about reminiscence entry on varied architectures. For instance if a CPU’s bus width is 32bit meaning the CPU can solely learn 32bit phrases from the reminiscence below 1 learn cycle. Now if we merely write each object to the reminiscence with out correct knowledge separation that may trigger some hassle.
┌──────────────────────────┬──────┬───────────────────────────┐
│ ... │ 4b │ ... │
├──────────────────────────┴───┬──┴───────────────────────────┤
│ 32 bytes │ 32 bytes │
└──────────────────────────────┴──────────────────────────────┘
As you possibly can see if our reminiscence knowledge is misaligned, the primary 32bit learn cycle can solely learn the very first a part of our 4bit knowledge object. It will take 2 learn cycles to get again our knowledge from the given reminiscence area. That is very inefficient and likewise harmful, that is why many of the programs will not enable you unaligned entry and this system will merely crash. So how does our reminiscence format seems to be like in Swift? Let’s take a fast take a look at our knowledge varieties utilizing the built-in MemoryLayout enum sort.
print(MemoryLayout<Bool>.measurement)
print(MemoryLayout<Bool>.stride)
print(MemoryLayout<Bool>.alignment)
print(MemoryLayout<Int>.measurement)
print(MemoryLayout<Int>.stride)
print(MemoryLayout<Int>.alignment) As you possibly can see Swift shops a Bool worth utilizing 1 byte and (on 64bit programs) Int can be saved utilizing 8 bytes. So, what the heck is the distinction between measurement, stride and alignment?
The alignment will inform you how a lot reminiscence is required (a number of of the alignment worth) to avoid wasting issues completely aligned on a reminiscence buffer. Measurement is the variety of bytes required to truly retailer that sort. Stride will inform you in regards to the distance between two parts on the buffer. Don’t be concerned for those who do not perceive a phrase about these casual definitions, it’s going to all make sense simply in a second.
struct Instance {
let foo: Int
let bar: Bool
}
print(MemoryLayout<Instance>.measurement)
print(MemoryLayout<Instance>.stride)
print(MemoryLayout<Instance>.alignment) When developing new knowledge varieties, a struct in our case (lessons work totally different), we will calculate the reminiscence format properties, primarily based on the reminiscence format attributes of the collaborating variables.
┌─────────────────────────────────────┬─────────────────────────────────────┐
│ 16 bytes stride (8x2) │ 16 bytes stride (8x2) │
├──────────────────┬──────┬───────────┼──────────────────┬──────┬───────────┤
│ 8 bytes │ 1b │ 7 bytes │ 8 bytes │ 1b │ 7 bytes │
├──────────────────┴──────┼───────────┼──────────────────┴──────┼───────────┤
│ 9 bytes measurement (8+1) │ padding │ 9 bytes measurement (8+1) │ padding │
└─────────────────────────┴───────────┴─────────────────────────┴───────────┘
In Swift, easy varieties have the identical alignment worth measurement as their measurement. If you happen to retailer normal Swift knowledge varieties on a contiguous reminiscence buffer there isn’t any padding wanted, so each stride can be equal with the alignment for these varieties.
When working with compound varieties, such because the Instance struct is, the reminiscence alignment worth for that sort can be chosen utilizing the utmost worth (8) of the properties alignments. Measurement would be the sum of the properties (8 + 1) and stride will be calculated by rounding up the scale to the subsequent the subsequent a number of of the alignment. Is that this true in each case? Properly, not precisely…
struct Instance {
let bar: Bool
let foo: Int
}
print(MemoryLayout<Instance>.measurement)
print(MemoryLayout<Instance>.stride)
print(MemoryLayout<Instance>.alignment) What the heck occurred right here? Why did the scale improve? Measurement is difficult, as a result of if the padding is available in between the saved variables, then it’s going to improve the general measurement of our sort. You possibly can’t begin with 1 byte then put 8 extra bytes subsequent to it, since you’d misalign the integer sort, so that you want 1 byte, then 7 bytes of padding and eventually the 8 bypes to retailer the integer worth.
┌─────────────────────────────────────┬─────────────────────────────────────┐
│ 16 bytes stride (8x2) │ 16 bytes stride (8x2) │
├──────────────────┬───────────┬──────┼──────────────────┬───────────┬──────┤
│ 8 bytes │ 7 bytes │ 1b │ 8 bytes │ 7 bytes │ 1b │
└──────────────────┼───────────┼──────┴──────────────────┼───────────┼──────┘
│ padding │ │ padding │
┌──────────────────┴───────────┴──────┬──────────────────┴───────────┴──────┐
│ 16 bytes measurement (1+7+8) │ 16 bytes measurement (1+7+8) │
└─────────────────────────────────────┴─────────────────────────────────────┘
That is the primary motive why the second instance struct has a barely elevated measurement worth. Be at liberty to create different varieties and follow by drawing the reminiscence format for them, you possibly can at all times test for those who had been appropriate or not by printing the reminiscence format at runtime utilizing Swift. 💡
This entire downside is actual properly defined on the [swift unboxed] weblog. I might additionally prefer to advocate this text by Steven Curtis and there may be another nice put up about Unsafe Swift: A highway to reminiscence. These writings helped me so much to know reminiscence format in Swift. 🙏
Reference varieties and reminiscence format in Swift
I discussed earlier that lessons behave fairly totally different that is as a result of they’re reference varieties. Let me change the Instance sort to a category and see what occurs with the reminiscence format.
class Instance {
let bar: Bool = true
let foo: Int = 0
}
print(MemoryLayout<Instance>.measurement)
print(MemoryLayout<Instance>.stride)
print(MemoryLayout<Instance>.alignment) What, why? We had been speaking about reminiscence reserved within the stack, till now. The stack reminiscence is reserved for static reminiscence allocation and there is an different factor known as heap for dynamic reminiscence allocation. We might merely say, that worth varieties (struct, Int, Bool, Float, and so on.) dwell within the stack and reference varieties (lessons) are allotted within the heap, which isn’t 100% true. Swift is sensible sufficient to carry out further reminiscence optimizations, however for the sake of “simplicity” let’s simply cease right here.
You would possibly ask the query: why is there a stack and a heap? The reply is that they’re fairly totally different. The stack will be sooner, as a result of reminiscence allocation occurs utilizing push / pop operations, however you possibly can solely add or take away gadgets to / from it. The stack measurement can be restricted, have you ever ever seen a stack overflow error? The heap permits random reminiscence allocations and you must just remember to additionally deallocate what you have reserved. The opposite draw back is that the allocation course of has some overhead, however there isn’t any measurement limitation, besides the bodily quantity of RAM. The stack and the heap is kind of totally different, however they’re each extraordinarily helpful reminiscence storage. 👍
Again to the subject, how did we get 8 for each worth (measurement, stride, alignment) right here? We will calculate the true measurement (in bytes) of an object on the heap by utilizing the class_getInstanceSize methodology. A category at all times has a 16 bytes of metadata (simply print the scale of an empty class utilizing the get occasion measurement methodology) plus the calculated measurement for the occasion variables.
class Empty {}
print(class_getInstanceSize(Empty.self))
class Instance {
let bar: Bool = true
let foo: Int = 0
}
print(class_getInstanceSize(Instance.self)) The reminiscence format of a category is at all times 8 byte, however the precise measurement that it will take from the heap will depend on the occasion variable varieties. The opposite 16 byte comes from the “is a” pointer and the reference depend. If in regards to the Goal-C runtime a bit then this could sound acquainted, but when not, then don’t fret an excessive amount of about ISA pointers for now. We’ll speak about them subsequent time. 😅
Swift makes use of Computerized Reference Counting (ARC) to trace and handle your app’s reminiscence utilization. In many of the instances you do not have to fret about handbook reminiscence administration, due to ARC. You simply need to just remember to do not create sturdy reference cycles between class situations. Thankfully these instances will be resolved simply with weak or unowned references. 🔄
class Writer {
let identify: String
weak var put up: Put up?
init(identify: String) { self.identify = identify }
deinit { print("Writer deinit") }
}
class Put up {
let title: String
var writer: Writer?
init(title: String) { self.title = title }
deinit { print("Put up deinit") }
}
var writer: Writer? = Writer(identify: "John Doe")
var put up: Put up? = Put up(title: "Lorem ipsum dolor sit amet")
put up?.writer = writer
writer?.put up = put up
put up = nil
writer = nil
As you possibly can see within the instance above if we do not use a weak reference then objects will reference one another strongly, this creates a reference cycle they usually will not be deallocated (deinit will not be known as in any respect) even for those who set particular person tips that could nil. This can be a very fundamental instance, however the true query is when do I’ve to make use of weak, unowned or sturdy? 🤔
I do not prefer to say “it relies upon”, so as an alternative, I might prefer to level you into the fitting route. If you happen to take a better take a look at the official documentation about Closures, you will see what captures values:
- World features are closures which have a reputation and don’t seize any values.
- Nested features are closures which have a reputation and may seize values from their enclosing operate.
- Closure expressions are unnamed closures written in a light-weight syntax that may seize values from their surrounding context.
As you possibly can see world (static features) do not increment reference counters. Nested features however will seize values, identical factor applies to closure expressions and unnamed closures, however it is a bit extra difficult. I might prefer to advocate the next two articles to know extra about closures and capturing values:
Lengthy story brief, retain cycles suck, however in many of the instances you possibly can keep away from them simply by utilizing simply the fitting key phrase. Underneath the hood, ARC does an amazing job, besides just a few edge instances when you must break the cycle. Swift is a memory-safe programming language by design. The language ensures that each object can be initialized earlier than you possibly can use them, and objects residing within the reminiscence that are not referenced anymore can be deallocated routinely. Array indices are additionally checked for out-of-bounds errors. This offers us an additional layer of security, besides for those who write unsafe Swift code… 🤓
Anyway, in a nutshell, that is how the reminiscence format seems to be like within the Swift programming language.
