JVM垃圾回收(GC)如何识别栈上对象是否为引用？

Hey there! Great question—your approach of using the lowest bit as a reference marker is a clever quick fix for simpler VMs, but as you’ve noticed, it comes with the frustrating downside of clipping the full range for 64-bit primitives. Let’s break down how the JVM handles this cleanly, no bit-marking required:

• Leverage Strongly-Typed Bytecode & Frame Metadata
  The JVM doesn’t rely on embedding markers in raw stack values at all. Instead, it leans into the inherent type information baked into Java bytecode and stack frame structure. Every bytecode operation is explicitly type-specific: aload loads a reference onto the operand stack, iload loads an int, lload loads a long, and so on. When the GC needs to scan the stack for root references, it checks the stack frame’s local variable table and operand stack, then uses the bytecode’s type annotations to instantly tell which slots hold references vs. primitive values.

• Typed Stack Slots as the Foundation
  JVM stack frames use "slots" as their basic storage unit. Primitive types like int, float, and references each take up one slot; 64-bit primitives like long and double occupy two consecutive slots. The JVM tracks the type of each slot either via precomputed metadata for the method’s bytecode, or by analyzing the bytecode execution flow to determine the type of each stack position at GC time. The type information lives separately from the raw data, so there’s no need to "tag" values themselves.

• No Tradeoffs for Primitive Value Range
  Since the JVM never modifies primitive values to add reference markers, 64-bit types like long and double can store their full, untruncated range of values. The GC’s ability to identify references is completely decoupled from the raw data in the stack, avoiding the limitation you ran into with your current design.

To sum it up: the JVM’s statically typed bytecode and frame metadata eliminate the need for in-data reference markers. Instead of guessing from the data itself, it knows exactly what each stack element is supposed to be—making GC root detection both accurate and efficient, without sacrificing primitive type functionality.

内容的提问来源于stack exchange，提问作者Stephen.W