Garbage collection is automatic memory management: an application allocates memory without explicitly freeing it, while a managed runtime scans the heap, identifies unused blocks, and reuses their memory. It prevents leaks, dangling pointers, double frees, and use-after-free bugs, but can introduce unpredictable pauses and tail-latency increases. section 7.4.2
A typical generational collector allocates short-lived objects in a region with a bump-the-pointer allocator. When the region fills, collection scans it, discards unreachable objects, and moves live objects into another region using more traditional allocation. Incremental scanning, parallel collection, and pauseless designs reduce—but do not eliminate—the latency impact. section 7.4.2
Latency-sensitive applications should treat garbage collection as an operational constraint:
- Avoid unnecessary allocations on fast paths because allocation can eventually trigger heap scanning and collection. section 2.3.5 section 7.4.2
- Understand the selected collector and tune its parameters for acceptable latency rather than assuming every algorithm behaves identically. section 2.3.5 section 7.4.2
- Measure tail latency in the actual runtime and deployment environment, because collection pauses can range from milliseconds to seconds. section 7.4.2 section 2.3
A full allocation region
An allocator advances a pointer through a region instead of maintaining a freelist. When the region fills, the runtime collects it: short-lived objects are discarded, while live objects move to a separately managed region. This makes allocation cheap but defers work into collection events. section 7.4.2
