RFR: JDK-8260926: Trace resource exhausted events unconditionally [v3]

[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

Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision:

  Reformulate message

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2350/files
  - new: https://git.openjdk.java.net/jdk/pull/2350/files/40e3af87..b3d331ff

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2350&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2350&range=01-02

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 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