On Tue, 2 Feb 2021 11:02:18 GMT, Thomas Stuefe <[email protected]> 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
