Details
Backports
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8227215 | 11.0.6-oracle | Alex Menkov | P4 | Resolved | Fixed | b01 |
JDK-8214789 | 11.0.3 | Thomas Stuefe | P4 | Resolved | Fixed | master |
Description
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
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
Attachments
Issue Links
- backported by
-
JDK-8214789 JVMTI ResourceExhausted should not be posted in CompilerThread
-
- Resolved
-
-
JDK-8227215 JVMTI ResourceExhausted should not be posted in CompilerThread
-
- Resolved
-
- relates to
-
JDK-8260926 Trace resource exhausted events unconditionally
-
- Resolved
-
-
JDK-8260509 JNI-originated "guarantee(thread->can_call_java()) failed: cannot make java calls from the native compiler" crash
-
- In Progress
-
-
JDK-8214294 Control sending of JVMTI events with a new Thread::can_post_jvmti_events() property
-
- Open
-