- So we're gonna be talking about memory layout in Swift.

As I'm sure you know, Swift is Apple's brand new,

magical, fancy programming language

and I'm gonna go dive into it a little bit

and talk about the bits and bytes

and how it's all put together

and what stuff looks like in memory

when you actually run the code on a computer.

Real brief about me, I'm online at mikeash.com,

I have a blog where I do all sorts of crazy stuff

like this, I like to take things apart

and see how they tick and I've got a bunch

of crazy Github projects which you should

probably never use for anything,

but are lots of fun to play with.

I'm on Twitter if you feel like following me.

There's a picture of my cat because, you know,

the internet is all about cats

and we're fundamentally all about the internet these days.

I fly gliders, just point of information,

it's a lot of fun.

And the arrow is kinda pointing over here

so that's me, you know, I always put a photo

of myself on these slides and then afterwards I'm like,

people can just look at me.

So I decided I'd stop doing that.

So here's the plan; first I just wanna give

a quick overview of what memory is.

I'm sure you all know what memory is,

but it can help to get a little bit of perspective

and just tear it down, you know, go to the foundations,

revisit the fundamental stuff.

Then I wrote a program that basically

is where I generated all this information,

it actually goes through, crawls, the program

starting from a particular value

and dumps everything out that are in those values in memory.

And then finally I'm gonna actually dive into

how Swift lays out stuff in memory,

what that program actually produces

and some contrast with how C does it and how C++ does it.

So what is memory?

And fundamentally memory is what stops this from happening.

So you gotta keep track of where you are essentially.

You've got a computational process

and you are at some state within that process at all times.

And if you can't keep track of that

then you will just never get anywhere.

So we don't wanna just endlessly repeat,

we wanna actually make progress

and that's what this is all about.

So figuring out how to actually build hardware

which can remember things and store information

and dig it out later is kinda one of the fundamental

problems in computing and there's

lots of technologies along the way.

Started out with vacuum tubes.

You can imagine these things are like this big

and they're essentially like an incandescent light bulb

and each one holds one bit.

So if you wanna actually store some reasonable

amount of data you're talking about

a room full of incredibly hot equipment.

Later on there were mercury delay lines,

this is kind of a cool technology of a pipe,

you basically fill it with mercury,

you have a speaker or something like that on one end

and something like a microphone on the other end

and you pulse your data through it.

And it takes time to travel and because of that

you can fit stuff in and store your information that way.

And there was a fun little proposal,

somebody decided that gin would make a good medium for this,

had all the right chemical properties and whatever.

As far as I can tell nobody ever built that,

but fun little aside.

Magnetic core memory was an advancement of this stuff,

it was a very neat technology, you got little rings

of iron and you run wires through them

and depending on the electrical current

you send through them you can store data

or retrieve data by storing it

in the magnetic field in those rings.

And so that was one ring per bit.

And the state of the art of this in the 60s or 70s

was basically a cube about this big

could hold 32,000 bits of information

and then you can imagine this thing I've got

in my hand can hold many gigabytes memory,

billions of bits.

And so things have advanced a lot since then.

So DRAM, dynamic RAM, basically silicon chips

is the state of the art today.

Which we should all be incredibly thankful for

because it really makes our lives a lot easier.

That fact that we can have these,

this allows us to store billion and billions

of bits of information all at once.

And my phone is misbehaving, if you can

pardon me for just a moment here, there we go.

Alright, so that's the hardware view of things,

we don't really care too much about hardware

most of the time if we're programming

because that all just works, we ignore it.

So how does it look for a programmer?

So we've got the fundamental unit of information

is the bit, that's a one or a zero.

Traditionally we organize bits in groups of eight,

those are bytes, and memory is essentially

just a long sequence of bytes one after the other

just heading off into the mist.

And they're arranged in a certain order,

every byte gets a number, that's called it's address.

So we start at zero and then one and then two

and then three and then an 8,000,000,000 byte system

we've got billions off in the distance.

It can be, you can view these things

in different directions, often we view it

like this, organized by word instead of by byte.

So a word is a vague term of the art

in computer science, but usually it means

a unit that's the size of a pointer.

So on modern devices it's 64 bits or eight bytes.

And it just heads off into infinity.

So here I've got the bytes addressed by eight.

And we like hexadecimal.

Hexadecimal is where you've got base 16 addressing

instead of base eight.

So zero through nine then A through F,

that's a nice multiple of two so everything

fits together nicely, it's kind of

the native language of computing.

So it's the natural language to use here.

And so I've got the addresses done

in hexadecimal instead, zero, eight, 16 is 10,

24 and all that.

And this is just the big picture

of what this whole thing looks like.

If you zoomed out this is a Mac running on x86-64,

everything's a little bit different

and it's all very platform specific,

but essentially you've got a gap of stuff

that doesn't exist, the first four gigabytes of memory

is not mapped, this doesn't take up any physical space

it's just an addressing trick.

Then you've got the user, your program essentially,

your memory is the green stuff.

So you get a chunk that's for you

and then you've got a nice, big, empty space after that

and then finally the kernel is down at the bottom.

So you've got this two to the 64th power bytes

which get sliced up and organized like this.

And this is essentially how it looks

if you zoom in a little bit, so this is the same

picture as before except it's more realistic

because instead of starting at zero

we're starting at 4,000,000,000.

We've got pointers in memory, I'm sure you're all familiar

with the term pointer, references.

A pointer at this level is just a number.

And it's a number that just happens to correspond

to the address of something else in memory.

So here we've got this thing up there,

that stores the address of this bit down there

and I just indicate that with an arrow.

The arrow doesn't exist in reality,

it's just a number that we treat as if it were an arrow.

And one more detail on all of this,

whoops, went too far, we in the most modern systems

store things in little-endian order

which is essentially the least significant part

of the number comes first.

So it's as if you wrote 234 as 432,

everything's backwards, just one of those things

you just kinda have to learn to live with it

and read it that way, so.

Memory is organized into, as far as we see it,

is organized into three fundamental parts.

We've got at the hardware level

it's just a big list of stuff.

But the way we actually treat it,

parts of it have more specific purposes.

So we've got the stack which is where

all your local variables go when you write

variables that you're using in your computations

in a function, that goes on the stack

and it's called a stack because every time

you make a function call it adds that function's

local variables to it.

And when you make another call it goes up

and another call it goes up and then when you

return from a function it goes back down,

back down, back down.

So it's like a stack of things.

You've also got global data in your program.

Those are essentially things that came along

as part of the program when you loaded it.

So your global variables are part of that,

your string constants, your type metadata

in Swift, in other languages, just gets loaded

as part of that.

And then you've got the heap, and the heap is dynamically

allocated stuff, when you create a new object,

that allocates some memory that's on the heap.

And these are things where basically

they don't live permanently, they've got some lifetime

but they're not tied to a function, they're not

tied to your program, they come to life

and go away kind of arbitrarily.

And that's essentially everything else.

When you create a new object, when you allocate memory

manually, when you concatenate strings, whatever,

that's all on the heap.

So that's kinda the overview, remind you what memory is,

what the whole deal is that we're talking about here.

Let's get into dumping memory.

Actually diving in and inspecting the contents,

seeing what's actually in there.

So I'm gonna explore this program that I wrote,

how it works, that actually goes in

and traces all this stuff out.

If anyone wants to take a look at it

I've got it up on Github, the Github address

is there, or there's a tiny URL below,

or if anyone likes really huge URLs you can

use that one at the bottom, but I'm not

gonna wait for you to type it out.

Just real quick, this uses Xcode 8 and Swift 3.

If anyone's doing anything with Swift so far

you know that there have been a lot of versions

of it and they like to break compatibility.

So last year was Swift 2, starting a couple of weeks ago

we've got Swift 3 now and that's different.

So if you wanna use that code you need this.

So back to this.

The kind of fundamental unit of this program

is a function that looks like this.

And this is a function that works on an arbitrary type,

it takes a value and it's gonna return an array

of unsigned eight bit integers, or bytes.

And we'll just use it as in the demo above,

you create a variable containing something,

any arbitrary thing, and then you just call this