-
Bug
-
Resolution: Fixed
-
P4
-
12
-
b22
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 |
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
- 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-8308745 ObjArrayKlass::allocate_objArray_klass may call into java while holding a lock
-
- Resolved
-
-
JDK-8214294 Control sending of JVMTI events with a new Thread::can_post_jvmti_events() property
-
- Open
-