JIT循环展开不依赖大数组容量，而取决于编译期能否建立确定性内存访问视图；堆分配导致地址不可预测、GC干扰布局收敛、引用语义增加解引用开销，均破坏展开前提。
堆内存中的大数组对象在 JIT 循环展开中不是“越大越好”，而是面临明确的内存模型约束——关键不在容量本身，而在于 JIT 编译器能否在编译期建立确定性的内存访问视图。
堆分配导致地址不可预测，破坏展开前提
JIT 的循环展开依赖对数组内存布局的静态可推理性。Java 或 Python 3.14（Torchlight）的 JIT 在编译时无法假设堆上 new int[1000000] 或 np.array(shape=(1e6,)) 的基地址、对齐方式或页边界位置。这类信息只有运行时 GC 分配后才确定，而 JIT 编译发生在方法首次热点触发阶段，此时对象可能尚未分配，或刚被移动（如 G1 的 Evacuation）。一旦地址不可知，就无法做指针算术折叠、无法消除边界检查、更无法生成固定偏移的展开指令块（如 mov eax, [rdi + 0], mov ebx, [rdi + 4] 连续序列）。
GC 活动干扰类型与布局收敛性
JIT 的类型特化和循环展开决策基于最近 256 次调用的统计稳定性。但堆大数组常伴随以下 GC 干扰：
- 年轻代频繁晋升：若数组在 Eden 区创建后很快进入 Old Gen，其内存位置突变，导致 JIT 缓存的地址相关优化失效
- 压缩式 GC（如 ZGC、Shenandoah）：运行中重映射对象地址，使已编译的展开代码中硬编码的偏移量过期
- 数组 reshape / resize：如
arr.resize(new_size)或list.append()后转为 ndarray，会触发内存重分配，彻底打破 JIT 对 layout 的假设
引用语义 vs 值语义：堆对象引入间接层级
对比栈分配的局部数组（如 Java 中的 int[] local = new int[256] 在逃逸分析后可能栈化），堆大数组始终通过引用访问：array[i] 实际是 load ref → load array header → compute offset → load element 多步解引用。JIT 只有在确认该引用不逃逸、header 不被修改、且元素访问无副作用时，才可能将其中部分步骤（如 header 读取）提升出循环，进而支持展开。但大数组常作为参数跨方法传递，极易逃逸，迫使 JIT 保留全部安全检查，放弃展开。
缓存行与预取友好性不等于 JIT 展开可行性
有人误以为“大数组连续存储利于 CPU 预取，所以 JIT 更愿展开”。这是混淆了硬件层与编译层逻辑。JIT 不看 L1d 缓存命中率，它只看 IR 构建阶段能否证明：每次迭代的内存地址表达式可静态简化为常量偏移。例如 for (int i = 0; i 中，a[i] 能被降为 &a[0] + i * 4，再结合 i 的已知范围，展开成 1024 个独立地址；但若写成 for (int i = 0; i ，a.length 是堆对象字段读取，属于运行时值，整个循环体就失去静态可推断性，JIT 直接跳过展开路径。
