Problem: the binary must be fast now and faster later, and both wishes spend the same CPU. Preconditions: a measurable warm-up budget and a hot-code fraction small enough that profiling pays. Guarantee: AOT gives flat startup; tiering gives peak throughput that beats AOT on speculative wins it can withdraw. Cost: warm-up time and the metadata a profiler keeps. Failure case: a short-lived process whose lifetime ends inside the interpreter's discount window — the JIT never recovers its scouting fee.

Problem: optimising everything is slow to start; interpreting everything is slow forever. Preconditions: a dispatch fast enough to observe hotness, and code that actually repeats. Guarantee: each tier raises the threshold, so compile cost tracks measured heat. Cost: per-tier transition machinery and the profiling data that feeds it. Failure case: the plateau where tier two compiles code the tier-one thresholds misjudged — hot while observed, cold forever after.

Problem: method boundaries hide the loop that matters behind calls that do not. Preconditions: hot paths are stable across iterations; type feedback agrees. Guarantee: the trace inlines the hot path across call edges, giving one straight-line region to optimise. Cost: every side exit is a deopt, and path explosion compiles the same basic blocks many ways. Failure case: a polymorphic loop whose "hot path" changes per iteration — the tracer spends everything guarding against yesterday's path.

Problem: safe code must handle cases the profile has never shown, and handling them costs the common path. Preconditions: a deopt path that reconstructs interpreter state correctly. Guarantee: the optimised code is correct in every reachable state because the guard either holds or exits to a frame that does. Cost: guard instructions everywhere, and frame-reconstruction machinery in reserve. Failure case: a rare-but-real input shape that deopts in a loop — the runtime pays interpretation plus bailout plus recompilation each time.

Problem: a property access or call site sees a small set of shapes, but "small" is per-site and data-dependent. Preconditions: receiver shapes cluster below the cache's polymorphism cap. Guarantee: a hit is a compare and a jump — around an order of magnitude cheaper than a generic lookup on the course's cost model. Cost: megamorphic sites thrash and must fall back, which is why they exist as a first-class mode. Failure case: treating a megamorphic site as cacheable — the chain grows, the compares dominate, and a hash lookup would have won.

Problem: reclamation must be timely, complete, and cheap — pick two. Preconditions: the heap shape (cycles? sharing? mutation rate?) is stated. Guarantee: RC reclaims at the last pointer; tracing reclaims exactly the unreachable; ownership makes reclamation a compile-time fact. Cost: RC pays per-pointer write; tracing pays throughput and latency in collection; ownership pays in program structure, and in counting wherever sharing is opted back in. Failure case: cyclic structures under pure RC, or a latency budget under a stop-the-world mark — each strategy has a heap it cannot serve.

Problem: reference counts cannot see a disconnected cycle, and decrement-every-write is a tax paid on every store. Preconditions: enough allocation churn that RC's per-write cost exceeds periodic tracing, or real cycles that leak otherwise. Guarantee: reachability, not counting — cycles die with their last root edge. Cost: pause or barrier overhead, and floating garbage until the next collection. Failure case: a heap that is mostly long-lived and acyclic — tracing buys completeness it never uses.

Problem: most objects die young, so scanning the whole heap wastes work on the old. Preconditions: the workload actually follows the generational hypothesis — measure survival, do not assume it. Guarantee: a nursery-sized scavenge bounds pause time while a rare full pass reclaims the rest. Cost: remembered-set bookkeeping on every old-to-young write, plus promotion policy. Failure case: middle-aged objects dying past the nursery — they promote, then die in the expensive tier, paying for both ends of the ride.

Problem: a non-moving heap fragments until a large allocation fails with free space everywhere. Preconditions: the runtime controls all references — handles, read barriers, or a pause where fix-up is safe. Guarantee: live objects pack into one region; free space is a pointer increment. Cost: every read may pay a forwarding check, and pinned objects carve holes in compaction. Failure case: a C API that stores raw pointers — the contract forbids movement, and compaction is simply unavailable, as JNI-critical sections show.

Problem: the collector question arrives as a flag, but it is a workload question. Preconditions: live-set size, allocation rate, and a pause-time percentile stated. Guarantee: each design point dominates only on the axis it spends on — Parallel on throughput, G1 on bounded-stall balance, ZGC/Shenandoah on pauses at heap scale. Cost: concurrent marks spend CPU while the app runs; regional sets spend metadata per region. Failure case: tuning a concurrent collector on a throughput workload — GC thread time is billed as mutator slowdown.

Problem: concurrent work must coordinate, and the model chosen decides where races can even exist. Preconditions: the sharing pattern — mutable state touched by all, or owned state passed as messages. Guarantee: shared memory gives the cheapest communication the memory model still permits; the event loop serialises races out of existence; actors make every boundary a copy. Cost: threads spend correctness discipline; the loop spends latency on any blocking call; actors spend bandwidth on data movement. Failure case: a blocking call on the event loop, or an actor forced to serve state every other actor reads — its mailbox becomes the bottleneck the shared memory would have avoided.

Problem: an OS thread per task costs memory per idle task and a kernel transition per switch. Preconditions: tasks outnumber cores and block rarely, or the runtime detects blocking. Guarantee: work-stealing keeps every worker busy while runnable tasks exist — idle workers pull from busy queues. Cost: queue operations on the hot path, plus the preemption needed to stop a runaway task from starving its queue. Failure case: a task that blocks without telling the runtime — it holds a worker hostage, and the whole queue behind it stalls.

Problem: concurrent I/O wants cheap tasks, but a shared-colour language makes every callee a viral commitment. Preconditions: an ecosystem that already speaks the colour — an async library stack, an executor to drive it. Guarantee: thousands of in-flight operations fit in memory because each costs a state machine, not a stack. Cost: colouring propagates through callers, cancellation is cooperative, and blocking code poisons the executor. Failure case: the sync call inside async — one blocking function holds its worker thread for the call's duration, invisibly to the type system; on a single-threaded loop that is the whole executor, and no cooperative budget can interrupt it.

Problem: two concurrent pieces must exchange data; the question is whether they synchronise or buffer. Preconditions: whether backpressure must reach the sender (channel) or absorb it (mailbox/queue). Guarantee: a channel's rendezvous is itself a synchronisation edge — Go's memory model makes the send happens-before the receive. Cost: an unbuffered channel stalls the sender; a mailbox can grow without bound. Failure case: an unbounded mailbox under a slow consumer — memory, not deadlock, is the failure the BEAM teaches you to watch.

Problem: defensive code for every failure is impossible, and some failures are transient enough that restart beats recovery. Preconditions: failures that a clean state fixes — a wedged connection, corrupted scratch state — and an error kernel small enough to hold the parts that must not crash. Guarantee: a supervisor restarts a child to a known state with bounded restart intensity; escalation stops runaway restarts. Cost: state lost on restart, and restart storms absorbed by intensity caps. Failure case: a deterministic bug or poisoned input — restart recurs the crash, and intensity just delays it.

Problem: non-atomic reference counts plus C extensions assuming single-threaded access make fine-grained locking a rewrite of the ecosystem. Preconditions: an extension ABI that exposes object layout and counts, as `native-extension-contract` derives. Guarantee: interpreter internals and counts stay correct under threads without touching a single extension. Cost: CPU-bound threads cap at one core, and I/O threads convoy behind the bound one. Failure case: a CPU-bound workload on threads — the folklore says it parallelises; the lock says it serialises.

Problem: one lock per process wastes the cores under it; the exit is either more interpreters or no lock. Preconditions: isolation needs shareable data or copy costs bounded; free-threading needs the PEP-703 machinery (biased counts, immortal objects, per-object locks) and extension compatibility. Guarantee: subinterpreters give parallelism with process-like isolation; free-threading gives true shared-memory parallelism inside one interpreter. Cost: subinterpreters pay memory per interpreter and copying across; free-threading pays a single-thread slowdown and per-object-lock complexity. Failure case: extensions that assumed the GIL — under free-threading they must lock per object or race, and under isolation they must reinitialise per interpreter.

Problem: reasoning about interleavings is only possible if the language promises something; reorderings make raw interleaving intuition wrong. Preconditions: the program synchronises every shared access — locks, acquire/release, channels — so no data race exists on SC executions. Guarantee: compilers may reorder freely between synchronisation, but no thread can observe it — the model reduces to interleavings. Cost: the language must say which reorderings are legal, and the programmer must use the synchronisation vocabulary. Failure case: assuming DRF-SC holds on a racy program — now the answer depends on the model: Java bounds the read, C++ calls it undefined, Go admits bounded race values.

Problem: sequential consistency costs fences the hardware must execute; weaker orderings ask the programmer to carry the order. Preconditions: a data race on non-atomics is UB, so shared accesses must be atomic; then pick the ordering the pattern needs — release/acquire for message passing, relaxed for statistics, seq_cst for the store-buffer patterns that need it. Guarantee: each ordering is a contract with stated allowed outcomes, and standard mappings to x86 and AArch64 instructions exist for each. Cost: weaker orderings move reasoning from the model to the programmer. Failure case: a relaxed flag used for publication — the write to the payload is invisible to the reader that "saw" the flag, and no fence was paid for.