RFR: 8214294: Post ResourceExhausted events generated by CompilerThread on the ServiceThread
David Holmes
dholmes at openjdk.org
Thu Jan 29 01:18:54 UTC 2026
On Sat, 24 Jan 2026 08:37:21 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:
> The
>
> [JDK-8213834](https://bugs.openjdk.org/browse/JDK-8213834) JVMTI ResourceExhausted should not be posted in CompilerThread
>
> disables posting ResourceExhausted events on CompilerThread because it can't post event.
> The ResourceExhausted is used by agents to identify VM issues (and usually kill instance). I think it makes sense to generate this event on the ServiceThread like other deferred events (methods loading/unloading).
> So tool like https://github.com/Netflix-Skunkworks/jvmquake can properly kill jvm if resource exhausting happens on any thread.
>
> Please note, that ResourceExhausted is NOT generated when CodeCache full. It might be makes sense to add it since performance degradation going to be critical and makes sense treat CodeCache as a resource.
>
> It is hard generate OOME in the CompilerThread to test this fix.
>
> The fix was tested by patch that generated event for codecache exchausting and new test.
> https://github.com/openjdk/jdk/compare/master...lmesnik:jdk:codecache-full?expand=1
@lmesnik exactly what kinds of "resource exhausted" events do you expect to encounter in a compiler thread? There are only 4 places I see them being posted.
- The `JVM_StartThread` case is not applicable to compiler threads.
- The main heap allocation site does:
JvmtiExport::post_resource_exhausted(
JVMTI_RESOURCE_EXHAUSTED_OOM_ERROR | JVMTI_RESOURCE_EXHAUSTED_JAVA_HEAP,
message);
but I don't believe you can post this from a compiler thread without needing to change the JVM TI specification. At the moment the spec states:
> JVMTI_RESOURCE_EXHAUSTED_OOM_ERROR | 0x0001 | After this event returns, the VM will throw a java.lang.OutOfMemoryError.
but if you change things so that a compiler thread now causes this to be posted on the service thread, then that is not true - there will not be an OOM in either thread. If the compiler thread itself hit this case it would not throw an OOM anyway.
- The metaspace OOM would have the same problem - but I don't think the compiler thread could ever trigger that.
- The post_array_size_exhausted is also I think, not applicable to the compiler thread
So I am unclear exactly what problem is intended to be solved here - or how you can generally solve it given the specification for ` JVMTI_RESOURCE_EXHAUSTED_OOM_ERROR`.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/29397#issuecomment-3814794675
More information about the serviceability-dev
mailing list