Why can a 10-character substring keep a 2 GB document alive in memory?

## Two implementations of one operation Extracting characters `[i, i+k)` from a parent string of length n can be done two ways. **View (buffer sharing).** The new string stores three things: a reference to the parent's character buffer, an offset `i`, and a length `k`. No characters are copied. - Time: O(1). Space: O(1) beyond the small header. - Legal **only because strings are immutable**. If either side could write to the shared buffer, the other would see its contents change — precisely the aliasing hazard immutability exists to remove. This is a nice illustration that immutability is not only a safety property; it *enables* optimisations that are impossible for mutable buffers. - Hidden cost: the child references the **whole** parent buffer. Reachability is all-or-nothing — memory reclamation frees a buffer only when nothing at all references it, and it has no notion of "only ten of these two billion characters are still wanted". **Copy.** The new string allocates its own buffer of exactly k characters and copies them in. - Time: O(k). Space: O(k). - The parent becomes unreachable the moment the last direct reference to it is dropped. ## The postmortem shape A document processor reads a 2 GB file, finds a marker, extracts a 10-character tag, drops the document, and stores the tag in a long-lived index. With copying substrings, live memory after the loop is 10 characters per document. With view substrings, it is 2 GB per document, and the process dies after a handful of files. What makes this expensive to diagnose is how *innocent* the code looks. There is no cycle, no forgotten listener, no unclosed resource — the classic leak checklist finds nothing. The tells are: - Live memory scales with the **size of the largest inputs ever processed**, not with the number or size of the retained results. - A heap breakdown shows a small number of enormous character buffers, each reachable from a tiny string object, with no other referents. - Retained size per stored object is orders of magnitude larger than its shallow size — the single most diagnostic number here. - The fix that "shouldn't matter" — copying the extracted value — makes the problem vanish, which is the confirmation. ## The fix, and why it is a real tradeoff The fix is to force a copy of any slice that will outlive its parent: rebuild the extracted value into its own buffer before storing it. Structurally, do it at the boundary where parsed values become retained values, so the rule is "anything that goes into the index is copied" rather than a judgement call at each call site. But do not conclude that copying substrings is simply correct. Consider a tokenizer that slices a large input into millions of tokens, examines each, and keeps almost none. With views, tokenization allocates essentially nothing and the parent dies with the parse. With copies, you allocate and copy every token's characters — a large, entirely wasted cost, and the classic reason high-performance parsers slice rather than copy. The rule that captures both cases: - **Slices transient, parent short-lived → view.** O(1) extraction, no retention hazard, big win. - **Slices retained, parent large → copy.** Pay O(k) once to release O(n). The direction to keep straight is that the view is not "faster", it is *cheaper to create and more expensive to keep*. It moves cost from extraction time to retention. The history here is instructive because mainstream ecosystems have made both calls and changed their minds: Java shipped buffer-sharing substrings for years and switched to copying after exactly this retention bug proved too common in the field, while Go's slice-of-bytes and Rust's string slices deliberately share and put the retention discipline on the programmer. Same operation, same tradeoff, opposite defaults — which is why an interviewer asking this wants your reasoning, not a memorised answer about one environment. ## Related shapes The pattern generalises past strings: any small object that holds a reference into a large backing store — a sub-array view, a slice over a memory-mapped region, a parsed field pointing into a network buffer — has the same retention behaviour. Recognising the shape once is what lets you find it quickly in whatever form it next appears.