Values, variables and memory

01 · BITS AND BYTES

Bits and bytes

A bit is the smallest piece of information there is: one switch, off or on, written 0 or 1. In the memory chips of your computer each bit is a tiny capacitor that either holds a charge or doesn't, guarded by one transistor. Robert Dennard patented that one-transistor cell at IBM in 1968, and DRAM still works that way. The transistor and Memory show the hardware.

Memory hands bits out eight at a time. Eight bits make a byte, and every byte in memory has its own number, its address, like houses on a very long street. With 8 switches there are 2 × 2 × 2 × 2 × 2 × 2 × 2 × 2 = 256 patterns.

To read a pattern as a number, give each bit a place value, doubling from right to left: 1, 2, 4, 8, 16, 32, 64, 128. Add up the places that are on. 01000001 is 64 + 1 = 65. That is all binary is: counting where each column is worth twice the one to its right, instead of ten times. In the 3D the enlarged byte counts through some values; watch the place values light up.

// count in binary: each column is worth twice the one to its right
for (let n = 0; n <= 8; n++) {
  const pattern = n.toString(2).padStart(4, "0");
  console.log(pattern, "=", n);
}

Binary is long to write, so programmers use hexadecimal (base 16, digits 0–9 then a–f). One hex digit is exactly four bits, so a byte is always exactly two hex digits: 01000001 is 41. That is why memory dumps, addresses and colours like #ff9d4d are written in hex.

const n = 65;
​
// the same byte, written four ways
console.log(n.toString(2).padStart(8, "0")); // binary
console.log(n.toString(16));                 // hexadecimal
console.log(0b01000001);                     // a binary literal
console.log(String.fromCharCode(n));         // read as a letter

02 · INTEGERS

Integers: fixed width, and the wrap-around

Whole numbers are stored in a fixed number of bits: 8, 16, 32 or 64. Fixed width means a fixed range. An unsigned byte holds 0 to 255; add 1 to 255 and the carry falls off the left end, leaving 0. That is called overflow, and the number wraps round like a car's odometer.

Negative numbers use two's complement. The top bit keeps its place but counts as negative: in a byte it is worth −128, so 10000000 is −128 and 11111111 is −128 + 127 = −1. The wheel in the 3D does the same with 4 bits, where the top bit is worth −8: count up from 0 and after +7 comes −8.

Why this odd scheme? Because the same adding circuit then works for positive and negative numbers alike, there is only one zero, and negating is simple: flip every bit, then add 1.

const u = new Uint8Array(1);   // one byte, unsigned: 0 to 255
u[0] = 255;
u[0] = u[0] + 1;
console.log("255 + 1 =", u[0]);
​
const s = new Int8Array(1);    // one byte, signed: -128 to 127
s[0] = 127;
s[0] = s[0] + 1;
console.log("127 + 1 =", s[0]);
​
// look at the raw bits of -1 in a signed byte
s[0] = -1;
const raw = new Uint8Array(s.buffer)[0];
console.log("-1 is stored as", raw.toString(2));

// two's complement by hand, in 8 bits:
// to negate a number, flip every bit, then add 1
function negate8(x) {
  return (~x + 1) & 0xff;      // ~ flips bits; & 0xff keeps 8 of them
}
const show = (b) => b.toString(2).padStart(8, "0");
​
console.log(" 5 =", show(5));
console.log("-5 =", show(negate8(5)));
console.log(" 5 + -5 =", show((5 + negate8(5)) & 0xff), "(the carry falls off the end)");

Overflow is not a quirk of toy examples. Many systems store time as seconds since 1 January 1970 in a signed 32-bit integer, and that counter runs out in 2038:

// Many systems count time as seconds since 1 Jan 1970,
// in a signed 32-bit integer. The biggest it can hold:
const max32 = 2 ** 31 - 1;
console.log(max32);
console.log(new Date(max32 * 1000).toISOString());
​
// one second later the counter wraps to the most negative number
const wrapped = (max32 + 1) | 0;   // | 0 forces 32-bit integer maths
console.log(wrapped);
console.log(new Date(wrapped * 1000).toISOString());

JavaScript is unusual here: its Number is not an integer type at all but a 64-bit float (the next act). Whole numbers are exact only up to 2⁵³ − 1, called Number.MAX_SAFE_INTEGER. For bigger integers there is BigInt, which grows as needed and never overflows.

// JavaScript's Number is a 64-bit float: whole numbers are exact
// only up to 2^53
console.log(Number.MAX_SAFE_INTEGER);
console.log(2 ** 53 + 1);             // can't be stored: rounds
console.log(2 ** 53 === 2 ** 53 + 1);
​
// BigInt: integers of any size (note the n)
console.log(2n ** 53n + 1n);
console.log(2n ** 100n);

03 · FLOATING POINT

Floating point: why 0.1 + 0.2 ≠ 0.3

For fractions, computers use floating point: scientific notation, in base 2. A double (IEEE 754 binary64) spends its 64 bits on three fields, the three colours in the 3D: 1 sign bit, 11 exponent bits that say how far to slide the point, and 52 fraction bits for the digits. The value is ± 1.fraction × 2^exponent. Every number in JavaScript is one of these.

The catch is that most decimal fractions have no exact binary form. You can't write 1/3 in decimal with a finite number of digits (0.3333…); in binary you can't write 1/10 either. It comes out as 0.000110011001100… repeating forever. The 52 fraction bits hold the nearest value they can. You can see the repeating 1001 1001 in the 3D.

function bits(x) {
  const view = new DataView(new ArrayBuffer(8));
  view.setFloat64(0, x);                 // the 8 bytes of a double
  let s = "";
  for (let i = 0; i < 8; i++) {
    s += view.getUint8(i).toString(2).padStart(8, "0");
  }
  return s[0] + " " + s.slice(1, 12) + " " + s.slice(12);
}
​
console.log(bits(0.1));
console.log(bits(0.2));
console.log(bits(0.1 + 0.2));
console.log(bits(0.3));
0.1 + 0.2 === 0.3

0.1 and 0.2 are each stored a hair too big. Their sum rounds to the double just above the one nearest 0.3. Near 0.3, neighbouring doubles are 2⁻⁵⁴ apart, about 0.000000000000000056, and the number line in the 3D shows four of them: 0.1 + 0.2 lands exactly one step too high.

// what is really stored when you write 0.1
console.log((0.1).toFixed(55));
console.log((0.3).toPrecision(21));
console.log((0.1 + 0.2).toPrecision(21));
​
console.log(0.1 + 0.2);
console.log(0.7 + 0.2 + 0.1);   // order matters too
console.log(0.1 + 0.2 + 0.7);

This is not a JavaScript bug. Python, Java, C and nearly every language use the same IEEE 754 doubles and print the same 0.30000000000000004. The rules that follow:

• Never compare floats with ===. Check that they are close, with a tolerance that suits the size of your numbers.
• Count money in whole units (cents), or use a decimal type. Never in fractional dollars.
• Know the special values: Infinity, NaN ("not a number", which isn't even equal to itself), and a separate -0.

const a = 0.1 + 0.2;
​
// 1. compare with a tolerance
console.log(Math.abs(a - 0.3) < Number.EPSILON);
​
// 2. count money in whole cents, never in fractions of a dollar
const cents = 10 + 20;
console.log(cents === 30, (cents / 100).toFixed(2));
​
// the strange corners of IEEE 754
console.log(1 / 0, -1 / 0, 0 / 0);
console.log(NaN === NaN, Number.isNaN(0 / 0));
console.log(Object.is(-0, 0), -0 === 0);

Graphics cards and AI models often go the other way and use smaller floats, 32 or even 16 bits, trading precision for speed: see The GPU.

04 · TEXT AND UTF-8

Text: code points and UTF-8

Text is numbers too. Unicode gives every character in every writing system a number called its code point, written U+ and hex: A is U+0041 (65), é is U+00E9, 🙂 is U+1F642.

An encoding turns code points into bytes. The one that won is UTF-8: plain English letters take 1 byte (so old ASCII text is already valid UTF-8), accented letters 2, most other scripts 3, and emoji 4. The first bits of every byte say what it is, yellow in the 3D:

• 0xxxxxxx: a whole character in one byte.
• 110xxxxx, 1110xxxx, 11110xxx: the first byte of a 2-, 3- or 4-byte character.
• 10xxxxxx: a continuation byte. Never the start of a character, so a program dropped into the middle of text can always find the next one.

const word = "Hé🙂";
​
const bytes = new TextEncoder().encode(word);   // text → UTF-8 bytes
console.log(bytes.length, "bytes:", [...bytes].map((b) => b.toString(16)).join(" "));
​
for (const ch of word) {                         // one character at a time
  const cp = ch.codePointAt(0);
  const n = new TextEncoder().encode(ch).length;
  console.log(ch, "U+" + cp.toString(16).toUpperCase().padStart(4, "0"), n, "byte(s)");
}
​
console.log(word.length);        // UTF-16 code units, not characters!
console.log([...word].length);   // real characters (code points)

That last surprise: JavaScript strings are UTF-16 inside. Each element is a 16-bit unit, and anything beyond U+FFFF, like most emoji, takes two of them. So "🙂".length is 2. Use for…of or [...str] to walk real characters. Even those aren't always what a person calls one character: 👍🏽 is two code points, a thumb and a skin tone.

Bytes on their own don't say which encoding made them. Read UTF-8 with the wrong one and you get mojibake:

// bytes only mean something with an encoding
const bytes = new Uint8Array([0xc3, 0xa9]);
​
console.log(new TextDecoder("utf-8").decode(bytes));        // é
console.log(new TextDecoder("windows-1252").decode(bytes)); // é  (mojibake)

05 · TRUE, FALSE, NOTHING

True, false, and two kinds of nothing

A boolean is true or false: the answer to every comparison, and what every if decides on. It is one bit of information, though it is usually stored in a whole byte or more, because a byte is the smallest piece of memory with an address.

JavaScript has two ways to say "no value", the middle and right boxes in the 3D:

• undefined: nothing was ever put here. A variable declared without a value, a missing property, a function that returns nothing.
• null: deliberately empty. A programmer wrote it to say "there is no value, on purpose".

Most languages manage with one: None in Python, NULL in C (a pointer to address 0), null in Java.

console.log(typeof true, typeof 42, typeof 42n, typeof "hi");
console.log(typeof undefined, typeof null, typeof {}, typeof []);
​
let notYet;
console.log(notYet);             // declared, never given a value
​
const user = { name: "Ada", phone: null };
console.log(user.phone);         // deliberately empty
console.log(user.email);         // never set at all
​
console.log(null == undefined, null === undefined);

typeof null says "object", and that is a bug. In the first JavaScript engine every value carried a small type tag; objects had tag 0, and null was the null pointer, all zero bits, so it read as an object. Fixing it would break existing websites, so it stays.

if accepts any value, not just booleans. It treats exactly these as false, the falsy values: false, 0, -0, 0n, "", null, undefined and NaN. Everything else is truthy, including "0", "false", [] and {}. The gate in the 3D lets them through one at a time.

const things = [0, "0", "", " ", [], {}, null, undefined, NaN, "false", -1];
​
for (const x of things) {
  const shown = typeof x === "string" ? '"' + x + '"' : x;
  console.log(shown, "→", x ? "truthy" : "falsy");
}
​
// || falls back on ANY falsy value; ?? only on null and undefined
const volume = 0;
console.log(volume || 50, volume ?? 50);

06 · VARIABLES

Variables: names for values

A variable is a name for a value. let score = 10; puts 10 in memory and ties the name score to it. In the 3D, each name gets a slot in the program's global frame.

The = sign is not "equals" as in maths. It is an instruction: work out the right-hand side, then make the name on the left hold the result. That is why score = score + 5 makes sense: read the old value, add 5, store the new one.

let score = 10;
let best = score;      // copies the value 10
score = score + 5;     // score now names a new value
console.log(score, best);
​
const player = "Ada";
console.log(player);

Three keywords make names in JavaScript. const: the name can never be pointed at another value. let: it can. var: the old way, with looser rules you don't need; avoid it. Use const by default and let when you must reassign.

const answer = 42;
answer = 43;           // a const name can't be pointed elsewhere

Names are for people. A C compiler turns every local name into a fixed offset in the function's frame, and a JavaScript engine turns them into register or slot numbers; the names themselves are gone by the time the machine runs.

Look at the last line in the 3D: player doesn't hold the text "Ada". It holds an address, @1f40, and an arrow to where the string really lives. Where that is, and why, is the next act.

07 · STACK AND HEAP

The stack and the heap

A running program splits its memory by purpose. Two regions matter most.

The stack holds function calls. Each call gets a frame, a block holding its parameters and local variables. Calling pushes a frame on top; returning pops it off. Freeing a whole frame is just moving one pointer, so the stack is very fast, but everything in it dies when its function returns, and it is small. In the 3D, area(4, 3) pushes a frame, computes 12, and the frame vanishes when it returns.

The heap is for everything that is big, that grows, or that must outlive the function that made it: objects, arrays, strings, closures. It can be allocated anywhere, so it is found by address, and someone has to give it back when it is no longer needed: you, in C, or a garbage collector. The user object in the 3D lives on the heap, and so do the string and the array inside it.

function area(w, h) {
  const result = w * h;    // w, h and result live in area's frame
  return result;           // the frame is thrown away here
}
​
const size = area(4, 3);
const user = { name: "Ada", tags: ["admin"] };  // objects go on the heap
console.log(size, user.name);

The stack has a fixed size: on Windows, 1 MB per thread by default. A function that calls itself forever keeps pushing frames until there is no room left: a stack overflow.

let depth = 0;
​
function dive() {
  depth++;
  dive();              // every call pushes another frame, forever
}
​
try {
  dive();
} catch (e) {
  console.log(e.name + ":", e.message);
  console.log("frames pushed before it broke:", depth);
}

JavaScript hides where things go, and engines are free to choose. A good mental model: primitives (numbers, booleans, and so on) behave as if they sit in the slot; objects always live on the heap, and the slot holds a reference. On real x86 and ARM processors the stack grows downwards, towards lower addresses; chapter 4 follows it call by call.

08 · REFERENCES

References vs copies

This is the idea in this chapter that causes the most bugs. Copying a primitive copies the value. Copying an object variable copies the reference, the arrow, so both names now point at the same object. Change it through one name and the other sees the change. That is called aliasing.

// primitives: the value is copied
let a = 5;
let b = a;
b = 6;
console.log(a, b);
​
// objects: the reference is copied, not the object
const p = { score: 1 };
const q = p;
q.score = 2;
console.log(p.score, p === q);
​
// a real copy is a new object
const r = { ...p };
r.score = 3;
console.log(p.score, r.score, p === r);

So === on objects asks "is this the same object?", not "do they look the same?". {} === {} is false: two objects, two addresses.

Spread ({ ...p }) makes a shallow copy: a new outer object, but anything nested inside is still shared. structuredClone makes a deep copy, all the way down.

const original = { name: "Ada", langs: ["JS"] };
​
const shallow = { ...original };          // copies one level
shallow.name = "Grace";
shallow.langs.push("COBOL");              // the array is still shared!
​
const deep = structuredClone(original);   // copies all the way down
deep.langs.push("Python");
​
console.log(original.name, original.langs);
console.log(deep.langs);
console.log({} === {}, original.langs === shallow.langs);

Passing an object to a function passes a copy of the reference. The function can change the object, and the caller will see it; but re-pointing its parameter at a new object changes nothing outside. This is sometimes called call by sharing.

function rename(person) {
  person.name = "Grace";      // changes the object the caller sees
  person = { name: "Linus" }; // only re-points the local name
}
​
const ada = { name: "Ada" };
rename(ada);
console.log(ada.name);

09 · MUTABILITY

Mutability: change in place, or make a new one

A mutable value can be changed in place. An immutable one can't: to "change" it you make a new value. In JavaScript, all primitives are immutable, strings included, while objects and arrays are mutable.

const list = [1, 2];
list.push(3);                 // const stops re-pointing, not changing
console.log(list);
​
let word = "cat";
const loud = word.toUpperCase();   // strings never change: a new one is made
console.log(word, loud);
word[0] = "b";                     // silently ignored
console.log(word);
​
const settings = Object.freeze({ theme: "dark" });
settings.theme = "light";          // also ignored (an error in strict mode)
console.log(settings.theme, Object.isFrozen(settings));

Notice that const doesn't make anything immutable. It only stops the name being pointed elsewhere. Object.freeze makes an object immutable, but only one level deep.

Why care? Shared mutable state is one of the classic sources of bugs: two parts of a program hold the same object, one changes it, and the other is surprised. Much modern code prefers to make new values instead of changing old ones. In 2023 JavaScript added copying versions of the array methods that change things in place: toSorted, toReversed, toSpliced and with.

const scores = [30, 4, 100];
​
const copy = scores.toSorted((a, b) => a - b); // new array (ES2023)
console.log(scores, copy);
​
scores.sort((a, b) => a - b);                  // changes scores itself
console.log(scores);

10 · GARBAGE COLLECTION

Garbage collection: who cleans up the heap?

Heap memory has to be given back, or a long-running program eventually runs out. In C you do it yourself, with free(). Forget, and memory leaks. Free too early and later code reads memory that now belongs to something else (use after free). Free twice and the allocator's own records get corrupted. These memory-safety bugs are not rare.

JavaScript, Python, Java, Go and C# use a garbage collector (GC) instead. Its rule: an object is alive if it can be reached from a root (a global variable, or a variable in a frame on the stack) by following references. Everything else is garbage, because no code can ever get to it again.

The classic algorithm is mark and sweep, invented by John McCarthy for Lisp in 1960. Mark: start at the roots and follow every arrow, marking what you reach. Sweep: free everything unmarked. In the 3D, d = null cuts the only path to D and E. They still point at each other, but nothing can reach them, so the sweep takes both.

// a heap as a graph: each object lists what it points to
const heap = {
  A: ["B"],
  B: ["C"],
  C: [],
  D: ["E"],     // D and E point at each other...
  E: ["D"],     // ...but nothing else points at them
  F: [],
};
const roots = ["A", "F"];   // what the stack and globals still hold
​
// MARK: everything reachable from a root
const marked = new Set();
function mark(id) {
  if (marked.has(id)) return;
  marked.add(id);
  for (const next of heap[id]) mark(next);
}
roots.forEach(mark);
​
// SWEEP: everything else is garbage
const freed = Object.keys(heap).filter((id) => !marked.has(id));
console.log("reachable:", [...marked].join(" "));
console.log("freed:", freed.join(" "));

Real collectors are cleverer. V8, the engine in Chrome and Node.js, relies on the observation that most objects die young: new objects go in a small young generation that is collected often and cheaply, and the survivors move to an old generation that is collected rarely, much of the work running on helper threads. CPython counts references instead, freeing an object the moment its count reaches zero, and runs a separate cycle collector for loops like D and E.

A garbage collector frees what you can't reach, not what you don't need. Keep a reference by accident, in a cache or a list of event listeners, and the memory stays alive forever:

// a garbage-collected program can still leak:
// anything you keep a reference to stays alive
const cache = [];
​
function handle(request) {
  const big = new Array(1000).fill(request);
  cache.push(big);       // oops: every request is kept forever
  return big.length;
}
​
for (let i = 0; i < 500; i++) handle(i);
console.log("arrays still reachable:", cache.length);
console.log("numbers kept alive:", cache.length * 1000);

11 · JS, PYTHON, C

The same ideas in C, Python and JavaScript

Every language makes the same choices this chapter has covered, but picks different defaults. The 3D shows x = 42 in all three.

C: you get the bytes

In C a variable is a box: a fixed number of bytes at a fixed place. An int is 4 bytes on today's mainstream platforms, and x86 and ARM store the lowest byte first (little-endian), so 42 sits in memory as 2a 00 00 00. Unsigned integers wrap; signed overflow is undefined behaviour, meaning the compiler may assume it never happens. Heap memory is yours to malloc and free.

#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>
 
int main(void) {
    int x = 42;                          /* 4 bytes, in main's stack frame */
    unsigned char *b = (unsigned char *)&x;
    printf("%zu bytes: %02x %02x %02x %02x\n", sizeof x, b[0], b[1], b[2], b[3]);
 
    uint8_t small = 255;
    small = small + 1;                   /* unsigned types wrap: 0 */
    printf("%u\n", small);
 
    int *p = malloc(sizeof *p);          /* 4 bytes on the heap */
    *p = 7;
    printf("%d\n", *p);
    free(p);                             /* you give it back, exactly once */
    return 0;
}

4 bytes: 2a 00 00 00
0
7

Python: everything is an object

In Python, even 42 is an object on the heap, with a reference count and a type, which is why it takes 28 bytes rather than 4. Names point at objects exactly as in JavaScript. Integers grow as big as they need and never overflow, floats are the same IEEE 754 doubles, and len counts code points, so an emoji is 1.

import sys
 
x = 42
print(sys.getsizeof(x))     # 28: a whole object, not 4 bytes
print(2 ** 100)             # ints grow; they never overflow
print(0.1 + 0.2)            # the same IEEE 754 doubles as JavaScript
print(len("🙂"), len("🙂".encode("utf-8")))
 
a = [1, 2]
b = a                       # names point at objects here too
b.append(3)
print(a, a is b)
print(sys.getrefcount(a))   # a, b, and the call's own argument

28
1267650600228229401496703205376
0.30000000000000004
1 4
[1, 2, 3] True
3

JavaScript: in between

JavaScript gives you one Number type (a double) plus BigInt, UTF-16 strings, objects by reference, and a garbage collector. Underneath, V8 cheats for speed: small integers, called Smis, are stored inside the slot itself, shifted one bit left with a 0 tag bit at the end (the pink bit in the 3D), while a number like 4.2 is boxed as a HeapNumber on the heap. You never see the difference: the language only promises the behaviour.

const x = 42;
console.log(typeof x, Number.isInteger(x), x / 5);  // just a "number"
​
const a = [1, 2];
const b = a;
b.push(3);
console.log(a, a === b);

• Integers: C has fixed widths that wrap; Python's grow without limit; JavaScript's are doubles, exact to 2⁵³, plus BigInt.
• Text: C has arrays of bytes ending in a zero byte; Python has immutable code points; JavaScript has immutable UTF-16.
• Memory: C is manual; Python counts references and collects cycles; JavaScript traces from the roots.