编译时触发‘cannot make java calls from the compiler’错误的原因探究

首先先把你遇到的原始错误日志贴出来，方便对照：

A fatal error has been detected by the Java Runtime Environment:
Internal Error (javaCalls.cpp:64), pid=3560, tid=140207058839296
guarantee(!thread->is_Compiler_thread()) failed: cannot make java calls from the compiler

JRE version: Java(TM) SE Runtime Environment (7.0_65-b17) (build 1.7.0_65-b17)
Java VM: Java HotSpot(TM) 64-Bit Server VM (24.65-b04 mixed mode linux-amd64 compressed oops)

你已经定位到问题根源是抛出异常前遗漏了pop指令——checkcast执行成功后，它的结果还留在操作数栈上，但Java规范要求进入异常逻辑前必须清空这个栈帧的异常状态，不能留着checkcast的结果。接下来咱们拆解你问的两个问题：

一、为什么这个栈异常会触发"cannot make java calls from the compiler"错误？ #

这个错误的触发逻辑其实是个“间接连锁反应”：

1. 当JIT编译器在编译你的代码时，检测到了操作数栈的非法状态（checkcast结果没被pop就进入异常分支）；
2. 为了处理这个编译阶段的错误，HotSpot虚拟机内部会启动一个错误诊断流程——这个流程里会包含一些类似Java层面的调用逻辑（比如生成详细错误日志、收集编译上下文信息）；
3. 但HotSpot的编译器线程（Compiler_thread）从设计上就不允许发起Java方法调用：编译器线程的核心职责是编译字节码，它的执行上下文没有为Java方法调用准备好必要的栈帧管理、GC交互等环境；
4. 当VM的错误处理代码试图在编译器线程里执行这类Java调用时，就触发了guarantee(!thread->is_Compiler_thread())这个断言检查失败，最终抛出了你看到的这个致命错误。

二、编译器认为程序试图发起何种类型的“调用”？ #

这里要明确：不是你的业务代码在发起Java调用，而是编译器自身的错误处理逻辑触发了被禁止的Java层面调用。具体来说，这类调用属于VM内部的诊断/错误报告相关调用，比如：

• 生成错误栈轨迹时调用的内部日志输出方法；
• 收集编译阶段上下文信息时涉及的Java层面辅助方法。

简单讲，就是你的代码的栈异常导致编译器在处理错误时“踩了自己的规则红线”——它自己的错误处理流程不小心发起了编译器线程不允许的Java调用，才出现了这个提示。

内容的提问来源于stack exchange，提问作者User1291