Bug ID: JDK-8153413 Exceptions::_throw always logs exceptions, penalizing performance

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 13
13 b10Fixed

See:

void Exceptions::_throw(Thread* thread, const char* file, int line, Handle h_exception, const char* message) {
  ...
  // vm log
  if (LogEvents){
    Events::log_exception(thread, "Exception <%s%s%s> (" INTPTR_FORMAT ") thrown at [%s, line %d]",
                          h_exception->print_value_string(), message ? ": " : "", message ? message : "",
                          p2i(h_exception()), file, line);
  }

Note that LogEvents is "true"! Therefore, the patch for JDK-8076161 is actually incomplete. This logging does backfire at least when exception is coming from implicit null check, like in JDK-8076161, or from the native code, like in the benchmark below. Turning LogEvents off improves performance by a lot.

Benchmark:
 http://cr.openjdk.java.net/~shade/8153413/StatBench.java

Runnable JAR:
 http://cr.openjdk.java.net/~shade/8153413/benchmarks.jar

Events::log_exception seems to record the exception into VM's ring buffer to provide diagnostics during the crash. There are other log messages there, but exceptions logging is special in two regards: a) exceptions may be much more frequent than other events, e.g. redefinitions or deopts; b) we are not capturing most exceptions that are coming from the generated code anyway!

Therefore, I would suggest we drop Events::log_exception facility, or at least remove its usage at Exceptions::_throw.

I made a small change to Exceptions::_throw to check for logging before calling oopDesc::print_value_string and constructing the string message directly in the exceptions logging string. This has no effect on the benchmark submitted but does show a positive effect >1% on the JMH Throw benchmarks and startup. So will fix now.
14-02-2019
I noticed we do some extra work for Exceptions::_throw for logging and have some looking at the performance of adding class unloading events. ��[~shade] How do I run this benchmark?
11-02-2019
This is not on our list of current priorities. If there are additional specific customer requirements, we will consider reopening this issue. Closing as WNF.
05-01-2018
I don't think we should drop log_exceptions functionality because it has helped with crash diagnosis. It seems that this performance difference is for a specific case, where the real problem is that it's throwing too many exceptions. This isn't a performance regression. I'm moving this to JDK 10.
06-06-2016

Relates :	JDK-8153229 - JavacFiler.checkFileReopening drowns in exceptions after Modular Runtime Images change
Relates :	JDK-8212988 - add recent class unloading events to the hs_err log
Relates :	JDK-8076161 - Runtime stub for throw_null_pointer_exception always constructs log messages