Memory: primitives vs objects

Where values live, and why references matter

You already met Data types: primitives such as numbers, strings, booleans, null, and undefined, plus objects such as arrays, functions, and object literals. You also met Objects & references: copying an object variable copies a reference, so aliases can see the same mutation. This lesson goes one level deeper: it gives you a memory model for predicting why that happens.

The curriculum summary says it plainly: where values live, and why copying an object copies a reference. We will use the common stack-and-heap model because it is useful, but we will label it honestly. JavaScript engines may store small integers inline, box numbers on the heap, keep closure variables on the heap, compress pointers, or remove allocations entirely. You are learning a reasoning model, not peeking into V8 or SpiderMonkey memory.

Step through the program. Watch primitive copies stay independent, then watch two bindings point at the same object. Line 6 deliberately uses let user so we can set it to null; a const binding could not be reassigned.

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

The important surprise is line 5. other.name = "Lin" does not change the reference stored in other. It follows that reference and changes the object. Since user had the same reference, user.name would see the change too until line 6 removes that one path.

JavaScript is often described as “primitives are passed by value, objects are passed by reference.” That phrase is close, but a sharper version is: every variable stores a value; for objects, that value is a reference. Copying the variable copies whatever value is in the binding.

Function calls use the same rule. A parameter receives a copy of the argument value. If the argument value is a reference, the copy points at the same object. This is sometimes called call by sharing.

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 mutates object #1, so the caller sees user.name become "Lin". Line 3 only reassigns the local parameter to a new object #2, so it does not replace the caller’s user. This is the pattern behind many “why did this function change my object?” bugs.

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

Notice the cycle. Objects A and B point at each other, but no root points at A or B. Modern mark-and-sweep collectors handle that: they mark from roots, never reach A or B, and can collect the whole island. A pure reference-counting collector would struggle because each object keeps the other’s count above zero; that is the classic “Reference counting & cycles” problem.

Garbage collection basics

Garbage collection is automatic memory management. JavaScript creates objects as your program runs. The engine periodically finds objects that are not reachable and makes their memory available for reuse. Normal code cannot observe the exact moment an ordinary object is freed, and it should not depend on that timing.

Where you’ll use this

This model shows up in everyday frontend work: fixing accidental mutation, choosing Map or WeakMap, clearing subscriptions, and understanding why a page gets slower after many route changes.

const seenUsers = new Map();

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

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

A module-level Map is reachable as long as the module is reachable. Its entries strongly hold their values, so a cache that only grows is a leak pattern. If the cache is for temporary metadata attached to objects, a WeakMap may be better because weakly held keys do not keep objects alive by themselves.

const metadata = new WeakMap();

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

• Forgotten timers or listeners can keep callbacks and captured data reachable. Clear them.
• Growing arrays, Maps, and caches need size limits, deletion, or clearing.
• Detached page nodes can be kept alive by ordinary JavaScript references. Drop those references.
• Closures can capture large data. Keep captured state small or release it when the work is done.

Common misconceptions

Key takeaways

• The stack/heap story is a mental model, not a literal map of engine storage.
• Primitive copies are independent values; object copies share references.
• Mutation changes an object; reassignment changes one binding.
• Reachability decides whether objects are still needed. Unreachable cycles can be collectible.
• Garbage collection timing is automatic and not something normal code should observe.

Up next: Scope & closures.