A typical way jvmti agents handle ResourceExhausted is to access the JVM  to obtain more information. That usually means running Java. For example, the CloudFoundry jvmkill ([1]) agent will use FollowReferences() to traverse the heap and to generate a class histogram.

That means ResourceExhausted events should only posted in threads which are able to call into java without problems.

Background: I am looking at a problem described in more detail here: [2]

CloudFoundry uses a tiny jvmti agent, jvmkill, which subscribes to ResourceExhausted and as a reaction to that event prints a class histogram. It crashes while doing so:

#  guarantee(!thread->is_Compiler_thread()) failed: cannot make java calls from the compiler

The reason is that we encounter a MetaspaceOOM in the compiler. Compiler allocates Metaspace for MethodData and MethodCounter objects. It would never actually leak those OOMs to the user but handle them internally. But since ResourceExhausted is posted, the CF jvmkill agent then runs its handler in the CompilerThread and triggers above assertion.

The solution would be to either not post ResourceExhausted in CompilerThreads or, alternatively, to not post ResourceExhausted when the current thread cannot call java.

--

[1] https://github.com/cloudfoundry/jvmkill
[2] https://github.com/cloudfoundry/java-buildpack/issues/500