RFR: JDK-8260926: Trace resource exhausted events unconditionally

[David Holmes]

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

Hi Thomas,

Approval in principle, but changes suggested.

Thanks,
David

src/hotspot/share/prims/jvmtiExport.cpp line 1509:

> 1507:   JavaThread *thread  = JavaThread::current();
> 1508: 
> 1509:   log_error(os)("Resource Exhausted (%s)", description != nullptr ? description : "no info");

Shouldn't that be `log_error(jvmti)`?
I'd also suggest the text "Posting Resource Exhausted event: %s" with "unknown" for a null description.

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

Changes requested by dholmes (Reviewer).

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