Integrated: JDK-8260926: Trace resource exhausted events unconditionally

Thomas Stuefe stuefe at openjdk.java.net
Fri Feb 5 07:34:00 UTC 2021


On Tue, 2 Feb 2021 11:02:18 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Analyzing out-of-resource situations in cloud scenarios is no fun. With CloudFoundry, a JVMTI agent (jvmkill) is hooked up intercepting the jvmti "resource exhausted" event, then attempts to write up a heap report. That may fail, e.g. due to bugs in the agent [1], but also because that report runs java code and may suffer from the same resource exhaustion. Successful or not, it unceremoniously kills the VM when done, often leaving us with no information about the actual resource.
> 
> It would be very helpful if we had unconditional tracing here. We do have tracing, but it requires a non-product build and is triggered with TraceJVMTI. Also, it traces at trace level which is way to fine granular.
> 
> I'd like to introduce another, unconditional trace line here. Arguably, resource exhausted is fatal enough that it justifies unconditional tracing.
> 
> This is a bit of a coin toss. Tracing unconditionally would help in most scenarios, where it would be either difficult or even impossible to specify a trace command line switch. OTOH it may trip up scripts parsing the VM output, or some of our tests (which can be fixed).
> 
> Thoughts?
> 
> ..Thomas
> 
> [1] https://github.com/cloudfoundry/jvmkill/issues/18

This pull request has now been integrated.

Changeset: ee2f2055
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ee2f2055
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

8260926: Trace resource exhausted events unconditionally

Reviewed-by: dholmes, coleenp

-------------

PR: https://git.openjdk.java.net/jdk/pull/2350


More information about the serviceability-dev mailing list