Memory: primitives vs objects

Where values live, and why copying an object shares it

In the Data types lesson, you met two kinds of values:

• Primitives: simple values such as numbers, strings, booleans, null, and undefined.
• Objects: everything else, such as arrays, functions, and plain objects.

In the Objects & references lesson, you saw that copying an object variable doesn't copy the object. Both variables then share one object. So a change made through one name shows up through the other name too. This lesson gives you a picture of memory that explains why that happens.

The picture has two places:

• The stack: each function that is running gets a small area here, called a frame. The frame holds that function's variables.
• The heap: a big storage area where objects live.

This stack-and-heap picture is a mental model: a simple way to think that helps you predict what code does. It is not an exact map of real memory. The engine is the program that runs your JavaScript, such as V8 in Chrome. An engine may store values however it likes, as long as your code gives the same results. So use the model to predict results. Don't use it to guess where things really sit in memory.

let score = 3;
let nextScore = score;
nextScore = 4;
console.log(score, nextScore);

Line 1 puts the number 3 in score. Line 2 copies that 3 into a new variable, nextScore. Line 3 puts 4 in nextScore only. So line 4 prints 3 4. The two variables never share anything.

Step through the program below. First, watch a number get copied. Then watch two variables point to the same object. Line 3 uses let user, not const, because line 6 gives user a new value, null. A const variable can't get a new value.

1let a = 1;Run2let b = a;3let user = { name: "Ada" };4const other = user;5other.name = "Lin";6user = null;7console.log(other.name);

Look closely at line 5. other.name = "Lin" doesn't change what other holds. JavaScript follows the reference in other to the object, and changes the object's name. The variable user holds the same reference, so user.name would also give "Lin".

Line 6 sets user to null. That changes only the variable user. The object is still in the heap, and other still points to it. So line 7 prints Lin.

People often say, "Primitives are copied by value, and objects are copied by reference." That is close. Here is a clearer rule:

Every variable holds a value, and for an object, that value is a reference.

When you copy a variable, you copy whatever it holds:

• For a number, you get a second number.
• For an object, you get a second reference to the same object.

The model is simpler than what engines really do. The table compares the two. Read each row as: "the model shows it like this, but an engine may really do this."

const cart = { item: { name: "tea", quantity: 1 } };
const copy = { ...cart };
copy.item.quantity = 2;
console.log(cart.item.quantity);

Line 1 makes a cart object. Its item property holds another object, called a nested object. Line 2 uses spread, ...cart, to make a new outer object called copy. Spread copies the value of each property. The value of item is a reference. So copy.item points to the same nested object as cart.item. Line 3 changes that shared nested object, so line 4 prints 2.

A copy like this is called a shallow copy: only the outer object is new. It works well when you change one top-level property. When the nested objects must be separate too, you need a deep copy, which copies every level.

A parameter is the variable a function gets for each value you pass in. Function calls follow the same rule as =. The parameter gets a copy of the value you pass. If that value is a reference, the copy points to the same object. Some people call this call by sharing.

function addTax(price) {
  price = price + 1;
  return price;
}
let price = 3;
console.log(addTax(price), price);

The function's parameter is called price, and so is the variable outside it. They are two separate variables. Line 5 stores 3 in the outside price. Line 6 calls addTax(price), so the parameter gets its own copy of 3. Line 2 changes that copy to 4, and line 3 returns it. The outside price is still 3. So line 6 prints 4 3.

1function rename(person) {2  person.name = "Lin";3  person = { name: "Grace" };4  return person.name;5}6 7const user = { name: "Ada" };Run8const result = rename(user);9console.log(user.name, result);

Line 2 changes object #1 through person. The caller's user points to the same object, so user.name becomes "Lin". Line 3 makes a new object, #2, and points only person at it. The caller's user still points to #1. So line 9 prints Lin Grace.

Line 2 is the pattern behind many "Why did this function change my object?" bugs.

When may the engine throw an object away? It checks whether the object is reachable:

1. It starts from roots. Roots are places the engine can always see, such as global variables and the variables of functions that are running right now.
2. It follows every reference from the roots, then every reference from those objects, and so on.
3. Any object it gets to is reachable, so it must stay.
4. Any object it can't get to is collectible: the garbage collector is allowed to clean it up.

function makeProfile(name) {
  return { name };
}
const profile = makeProfile("Asha");
console.log(profile.name);

Line 4 calls makeProfile("Asha"). The function makes an object and returns a reference to it. Line 4 stores that reference in profile. The function has finished, and its frame is gone. But the object is still reachable through profile, so it stays. Line 5 prints Asha.

1let globalUser = { profile: { city: "Kochi" } };2let modal = { owner: globalUser };3let a = { name: "A" };4a.friend = { name: "B", friend: a };5a = null;6modal = null;7globalUser = null;

Look at objects A and B. Line 4 makes them point to each other. Objects that point to each other in a loop form a cycle. Line 5 sets a to null, so after that no root points to A or B.

Modern garbage collectors use mark-and-sweep. First they mark every object they can reach from the roots. Then they sweep away, or clean up, every object that isn't marked. They never reach A or B, so both can be cleaned up together.

An older method, reference counting, counts how many references point to each object. It frees an object when its count reaches zero. In a cycle, A and B each keep the other's count at 1. So reference counting alone would never free them. The later Reference counting & cycles lesson covers this.

Garbage collection basics

Garbage collection means the engine frees memory for you. Your program makes objects as it runs. Every so often, the engine finds objects that are not reachable and reuses their memory. Your code can't see the exact moment an object is freed. So don't write code that depends on that moment.

Many engines also use generational collection. Most objects are needed only for a short time. So the engine checks new objects more often than old ones. Engines may also move the objects that are still in use closer together, to fill the gaps. The engine makes these choices. Your code can't ask for them for one object.

The table explains the main words. The last column shows how to talk about each one without saying something wrong.

Where you’ll use this

You'll use this model in everyday frontend work:

• Fixing an object that changed when you didn't expect it.
• Choosing between Map and WeakMap.
• Cleaning up timers and event listeners.
• Finding out why a web app gets slower after you move between many of its pages.

const seenUsers = new Map();

function rememberUser(user) {
  seenUsers.set(user.id, user);
}

function clearFinishedUsers() {
  seenUsers.clear();
}

A cache is a store of data you keep so you don't have to fetch or build it again. Line 1 makes the cache: a Map at the top level of a file. That Map stays reachable as long as the file is loaded. A Map keeps every value it stores reachable too. So a cache that only grows is a memory leak: memory that stays in use even though you no longer need the data. Line 8 fixes it: seenUsers.clear() removes every entry.

const recentUsers = new Map();
function remember(user) {
  recentUsers.set(user.id, user);
  if (recentUsers.size > 2) recentUsers.delete(recentUsers.keys().next().value);
}
remember({ id: "a" });
remember({ id: "b" });
remember({ id: "c" });
console.log(recentUsers.size);

This version keeps only the two newest users. Line 3 adds a user. On line 4, if there are more than 2 entries, it deletes the oldest key. A Map remembers the order its keys were added, so recentUsers.keys().next().value is the oldest key. The third call, on line 8, adds "c" and deletes "a". So line 9 prints 2. A size limit works well when data is useful for a while but shouldn't grow forever.

const metadata = new WeakMap();

function rememberElement(element, info) {
  metadata.set(element, info);
}

If the extra data belongs to an object, a WeakMap may be better. A WeakMap uses objects as keys, and it holds them weakly: the key alone doesn't keep the object reachable. When nothing else refers to element, the garbage collector may clean up both the element and its info.

More habits that prevent leaks:

• A timer or event listener you forget about keeps its function reachable, and everything that function uses. Clear it when you're done.
• Arrays, Maps, and caches that keep growing need a size limit, deletion, or clearing.
• A page element you removed from the page stays in memory if a JavaScript variable still points to it. Drop that reference too.
• A closure, a function that remembers outer variables, can keep large data alive. Keep what it remembers small, or let go of it when the work is done.
• A const object variable can't get a new value with =, but you can still change the object's properties.
• Clean up the same thing you set up: remove a listener with the same function you added, and clear a timer you started.

Common misconceptions

Key takeaways

• The stack-and-heap picture is a model for thinking, not an exact map of real memory.
• Copying a primitive makes a separate value. Copying an object variable copies a reference to the same object.
• Changing a property changes the object. Using = on a variable changes only that variable.
• An object stays while a root can reach it. A cycle that no root reaches can still be cleaned up.
• The engine cleans up memory on its own schedule. Your code shouldn't depend on when.

Up next: Scope & closures.