JOHN MCCUTCHAN: Hey, everyone.

I'm John McCutchan, and welcome to the Break Point.

And I'm here with Loreena Lee.

LOREENA LEE: Hi, I'm Loreena Lee.

JOHN MCCUTCHAN: So what do you do at Google?

LOREENA LEE: I actually work on Gmail, and I'm focused

primarily on performance, so making it faster as well as

making sure we're using the right amount of memory.

JOHN MCCUTCHAN: Nice, well that's good.

Good thing you're here, because we're here today to

talk about understanding the way memory works inside

JavaScript and how to profile your usage of memory inside

Chrome dev tools.

So I'm going to spend a little bit of time talking about the

conceptual material for how JavaScript manages memory.

And then Loreena is going to show us a really cool demo of

using Chrome dev tools.

So JavaScript variables can be of four primary types--

the boolean type, which just true or false canonical

values, the number type, which is any double precision

floating point number, the string, which is a UTF-16

encoded character array, or an object, which

is a key value map.

For those of you familiar with JavaScript, this

is very basic stuff.

But we're just going to start from scratch and build up.

So objects are built around key value mapping.

So the key goes in the square brackets.

And this is always a string.

No matter what you put in it, it's going to be

coerced into a string.

And then use that as the look up into the table.

And then for value, you can store any JavaScript object

inside of the value.

So a key fundamental concept of memory and JavaScript is

the object graph.

So we're looking at a whole bunch of circles and lines on

this slide.

But let's start from the left at the blue circle.

This is the root object inside the memory management system.

This is not something that you can explicitly manipulate or

do anything with, but this is just where every object that

you create descends from.

And so this is called the root.

And from the root, it references global variables

and other global state that's available to the browser.

The red objects are object variables.

So these can reference other variables.

And the green circles are scalar variables, like a

boolean or a number that can't reference anything else.

And you can see the green note at the end there, on the upper

right part of the screen with the yellow arrow, this is the

terminating node in this part of the object graph.

So objects have a concept of a retaining tree.

And this is the paths along the graph that are keeping the

object from being classified as memory.

So on the slide right now, you can see a green node.

And let's look at the retaining tree

for this green node.

So the retaining tree is this yellow node here--

the root node--

as well as this other path from the root to the other

yellow node as well.

So the object actually has two paths that are keeping it

pinned into memory.

If both of these paths are terminated, then the object

becomes garbage and eventually is collected.

Objects have two sizes.

They have a shallow size, which is just the size of the

actual object.

And this is usually a very small constant value.

I think on my system, an object is 36 bytes.

All of the variables that the object references are

accumulated together.

The sizes of those objects are accumulated, and this is the

retained size of an object.

This is the amount of memory that could be freed if this

object was turned into garbage.

LOREENA LEE: If you go back to the previous slide, we can see

the retained side of the root node would be basically the

whole graph except for those two disconnected

nodes in the middle.

JOHN MCCUTCHAN: Yes, which are garbage.

So from the root node, the retain sizes is the size of

everything that's still reachable.

So what exactly is garbage?

Well, the definition of garbage is any variable and

all variables which cannot be reached from the root node.

So in this diagram here, I've highlighted the two nodes

which are garbage.

The red node is referencing in the green node, but there is

no path from the blue root node to that red node, making

both the red and the green node into garbage.

So garbage collection happens in two phases.

First, the graph is scanned, and all garbage is found.

So we already know the garbage in this graph was the red and

the green node.

And then this memory is returned to the system during

the collection phase.

So it's important when optimizing for performance and

memory usage to understand the cost model

for allocating memory.

So every time that your JavaScript application calls

new, it reserves memory from something called the young

memory pool.

So memory is split into young objects and old objects.

The v8 internally decides when to promote an object from the

young memory pool to the old memory pool.

You don't have any control over that, but when you call

new, you're going to be scooping up memory from the

young memory pool, which is very cheap.

It's actually incredibly fast until the on memory pool runs

out of memory.

And at that point, the young memory pool is scanned, and

all of the garbage is collected, freeing memory,

making it possible to allocate new objects.

And this could take milliseconds.

So for interactive applications, you really want

to be careful about how you allocate objects and what the

patterns are, and how long you hold onto them, particularly

for a game.

You pretty much need to be able to do a frame with zero

allocations, because inside of a frame, you have 16

milliseconds to compute the state of the world, render it,

and take input handling, play sound.

If half of that time is taken up by garbage collection, the

game's not going to be very much fun.

So in summary, all variables that you have in JavaScript

are part of the object graph.

And the only inner nodes in an object graph

are JavaScript objects.

They're the only type of variable that can reference

other variables.

And objects have two sizes--

the shallow size, which is just the size of this the

object itself and then the retained size, which is the

size of the object itself plus all of its

descendants shallow sizes.

So all variables that cannot be reached from the root are

classified as garbage.

And when v8 decides it's an appropriate time, it will do a

garbage collection phase, freeing up memory and

collecting all the garbage and giving it back to the system.

So allocations are really cheap until the young memory

pool runs out of memory.

At that point, a garbage collection is forced, it's not

just done at an opportune time.

So you have to watch out for that in interactive

applications.

So Loreena, do you want to give us your demo?

LOREENA LEE: Sure, so just a little bit of basics about the

Chrome dev tools.

So we'll talk about how you can use the dev tools to

profile what's in your heap at any given time, and then also

to find situations where you may be leaving around memory

allocated that you don't need anymore.

So in general, the garbage collector should be cleaning

up after you.

But there are certain situations, which we'll see in

a little bit, where things may not get

cleaned up as expected.

So a little bit of his background on the dev tools.

We can use these now.

There are multiple tabs, and we're going to go through this

in an example.

But first, you want to if you have a suspicious action, so

you see that your memory is growing, or you think that

your application is slowing down for some reason or

another, and you think that memory might be the situation,

you can use the Timeline tab to perform the action and see

what's happening to memory.

So we can see if it's growing over time.

And if so, then we can say, OK, now we need to dig a

little bit deeper and see what's happening in the heap.

So we can use that to capture a heap snapshot, which will

show you all the objects that are in the graph that John

just talked about.

It does not capture scalar values, which were the green

nodes-- green nodes?

JOHN MCCUTCHAN: Yes.

LOREENA LEE: Green nodes in the graph that we saw.

But it does show you all the JavaScript

objects that are allocated.

There are four views of a snapshot.

And you'll see these in the demo as well.

There's the summary view, which shows you everything in

the heap, and you can apply a filter on the entire graph to

show only certain things.

And I'll talk about that in a little bit

in the demo as well.

And then there's a comparison view, where you can view the

differences between two heap snapshots.

So you take one snapshot and then take another one and see

what happens to memories.

Did more things get allocated?

Did a bunch of stuff get collected?

What's going on there?

There's a containment view, which is a bird's eye view of

the app's overall object structure.

So John mentioned a little bit about memory

versus retained memory.

And so in the containment view, you can see more easily

what the retained memory is.

And the DOMinator's also has a different

view of the same summary.

JOHN MCCUTCHAN: Yeah, so the summary and the comparison

view are sorted and organized around the objects

constructor, whereas the containment view is organized

starting at the root.

So it captures the structure of the object graph.

LOREENA LEE: OK, so we're not going to cover the container

and DOMinator's view too much in this demo.

But there's some really great documentation online at

developers.google.com, where you can see some nice demos

that show you exactly what you can see by

these two other views.

So we talked about comparison view and how sometimes you can

take two snapshots to find leaks.

But we're going to talk about a case where two

is not quite enough.

Some other good tips to know, though, are, you should always

do these experiments in an incognito window.

You want to make sure that you're in a clean room

environment.

You don't have your extensions that may be interacting with

your app in a way that you don't understand or

you don't even know.

So something these third party extensions do all sorts of

crazy things to memory, and you want to make sure that

those aren't influencing your results at all.

JOHN MCCUTCHAN: Yeah, just to repeat that, any browser

extension that is loaded will be part of the heap snapshot.

So you're not just looking at your code.

You're also looking at any extension that happens to be

loaded at the same time.

So an incognito windows is a quick way to avoid loading

your extensions.

LOREENA LEE: And then you want to get your bearings.

So on the heap profile page, you'll see that when we show