OpenJDK操作数栈仅为被指令驱动的临时容器，无执行逻辑；真实执行由InterpreterRuntime和templateTable.cpp生成的平台相关汇编完成，如x86_64上iadd直接操作%rsp和寄存器。
OpenJDK 的操作数栈不“主动执行”字节码指令——它只是被指令驱动的临时容器，真正执行逻辑在 InterpreterRuntime 和各字节码处理器（如 IADD::execute()）中完成。
操作数栈本身没有执行逻辑，只提供 push/pop 接口
OpenJDK 源码里，每个栈帧（frame）持有一个 OperandStack 实例，本质是带类型检查的动态数组。它不解析字节码、不判断类型、不调度指令——所有行为都由上层解释器按顺序调用：
-
OperandStack::pop_int()仅做两件事：校验栈顶是否为int类型、移动栈顶指针、返回值 -
OperandStack::push_int(v)仅做两件事：校验当前深度未超max_stack、存值、移动栈顶指针 - 它不记录“谁压的”“为什么压”，也不保存局部变量索引或常量池引用——那些属于
frame的其他字段
真实执行发生在 InterpreterMacroAssembler 和 templateTable.cpp 中
以 iadd 为例，OpenJDK 的解释器不是用 C++ 函数逐条模拟，而是生成汇编模板（通过 templateTable.cpp 注册），最终落地为平台相关汇编指令：
- x86_64 上，
iadd模板会生成类似movl %r14, %eax; subq $8, %rsp; movl (%rsp), %edx; addl %edx, %eax这类指令，直接操作寄存器和栈内存 -
%r14固定指向当前栈帧的局部变量表起始地址，%rsp则对应操作数栈顶——JVM 把“栈抽象”映射成了真实 CPU 栈 + 寄存器协作 - 所谓“操作数栈操作”，其实是解释器把字节码语义翻译成对
%rsp偏移地址的读写，不是在堆上维护一个 Java 风格的Stack
容易踩的坑：max_stack 不匹配导致 VerifyError
编译期确定的 max_stack 值必须严格覆盖运行时所有可能路径的栈深度峰值。常见出错场景：
- 用 ASM 动态生成字节码时，忘记调用
mv.visitMaxs(0, 0)或传入错误值，导致 ClassVerifier 拒绝加载 - 插入 try-catch 后没重算栈深度：异常处理器入口处的操作数栈状态与主路径不同，需单独分析
- long/double 占两个 slot，但误当做一个处理——例如
lload_0后紧接iload_1，实际栈深增加 2 而非 1 - Java 7+ 的 StackMapTable 属性必须与操作数栈状态一致，否则抛
java.lang.VerifyError: Expecting a stackmap frame
真正难调试的从来不是“怎么压栈”，而是字节码序列与栈状态之间的隐式契约——它不报错在编译时，而爆在类加载验证阶段，且错误信息极度模糊。
