3
# 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)

The error eventually turned out to be that I had forgotten one pop instruction before throwing an exception. (Last instruction before throwing the Exception was a checkcast that had succeeded, and Java didn't like its result still being on the stack.)

[Also (should be obvious, but I realise my words can be confusing): no exception was thrown during execution of the faulty code (because the code was still being compiled and not executed), but the next instructions after the checkcast would amount to throwing an Exception.]

I'm curious, though, how that results in this error message,

cannot make java calls from the compiler

What kind of "call" would the compiler think it's trying to make?

User1291
  • 7,664
  • 8
  • 51
  • 108
  • This message is produce here: https://github.com/JetBrains/jdk8u_hotspot/blob/master/src/share/vm/runtime/javaCalls.cpp. This may helps you. – Jean-Baptiste Yunès Jan 26 '18 at 12:42
  • I don’t get it. The result of a `checkcast` instruction is the same object reference as before, just with a different, usually more specific, type. If it’s not the throwable you’re going to throw, why cast it, or if it is the throwable, why `pop` it, and anyway, if the type doesn’t match, shouldn’t the verifier reject it? If invalid code passes the verifier, be it a bug or explicit turning off, there is no point in discussing subsequent JVM crashes. – Holger Jan 26 '18 at 16:08
  • @Holger it's part of a series of typechecks. For some types, I want to throw a dedicated exception (that will be caught and handled further up), for others, I want to do something type-specific with the object I just cast, instead. – User1291 Jan 26 '18 at 16:39
  • That still doesn’t explain it. All that `checkcast` followed by `pop` would to, is to throw a `ClassCastException` if the type doesn’t match. If you place that directly before throwing an exception, you are throwing an exception in either case, not “do something type-specific with the object”. And well, `athrow` requires a throwable on the stack. Pushing the throwable before the `checkcast` makes no sense, but when you’re pushing it after the `checkcast`, it is entirely irrelevant whether there are additional items on the stack. – Holger Jan 26 '18 at 16:49

0 Answers0