RFR: JDK-8260926: Trace resource exhausted events unconditionally

[Thomas Stuefe]

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

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

Commit messages:
 - Add trace

Changes: https://git.openjdk.java.net/jdk/pull/2350/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2350&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8260926
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2350.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2350/head:pull/2350

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