What does it mean that a non-escaping value is scalar-replaced rather than allocated anywhere at all?

## From object to variables A proof that no reference to a value escapes its frame permits two different rewards, and they are not the same thing. - **Frame placement.** The object still exists, with its fields laid out contiguously; it simply lives in the frame and dies with the pop. - **Scalar replacement.** The object stops existing. Each field becomes an independent local value that the compiler assigns to a register or a stack slot exactly as it would any other local. The second is stronger on every axis that costs time: nothing to find, nothing to initialise as a block, no header, no release step, and no pointer to chase when a field is read. ## Why the fields are better off separate Once the fields are ordinary locals, every later transformation that applies to locals applies to them: - A field written once with a known value can be **propagated as a constant** into the expressions that read it. - A field nobody reads is **dead** and disappears entirely, along with the work that computed it. - A field read in a loop can stay in a **register** for the whole loop rather than being reloaded through a reference. - Arithmetic on two fields of the same value becomes arithmetic on two locals, with no ordering constraint imposed by a shared block. This is why the transformation is worth more than its allocation saving alone: it converts a memory-shaped problem into a register-shaped one. ## What defeats it | use of the value | why it blocks the transformation | |---|---| | comparing it by reference identity | identity needs a distinct location, and separated fields have none | | using it as an identity-based key | the same requirement: something must stand for the value itself | | taking or storing its address | there is no address for a set of registers | | letting a reference escape at all | the value must then outlive the frame | | passing it to a call the compiler cannot examine | the callee might do any of the above | There is also a weaker, more interesting blocker: a variable that receives **different values on different paths** which then merge. Some compilers can keep the fields separated across such a merge by tracking each incoming shape; others give up and materialise an object. Ecosystems genuinely differ here, and in how aggressively they attempt the transformation at all, so the honest statement is that the transformation is permitted by the proof rather than guaranteed by it. ## Why you can rarely see it happen The transformation is close to unobservable from outside the compiled code: - Allocation counters register nothing, because no allocation occurred. - A heap snapshot cannot contain the value, because it was never a heap object. - Stepping through code may show the fields as ordinary locals rather than as one value, which is exactly what they now are. - The computed result is identical, so tests pass either way. That invisibility is the practical trap. The absence of an allocation in a profile is evidence about this compilation of this code shape, not a property the source guarantees, and the next edit re-derives the answer from scratch. ## What to take from it Two things are worth remembering. First, 'the value was stack-allocated' is often the wrong description of what actually happened: in many cases no value was laid out anywhere, and the fields simply became locals. Second, the transformation is bought by giving up identity — which is why a design that leans on reference identity for small short-lived values is quietly paying for something it may not need, and why value-like data that is only ever read by its fields is the shape that benefits most.