Update: the next major version will introduce a new set of startup options to control exception telemetry: exceptions=disable (the same as current _disable_exception_events), exceptions=on, exceptions=off.

disablestacktelemetry: JVM exception events enabled, exception telemetry not started (can be started later)disablestacktelemetry,_disable_exception_events: JVM exception events disabled, exception telemetry is not started and cannot be started later

In future version:

exceptions=disable: JVM exception events disabled, exception telemetry is not started and cannot be started later (the same as the current combination disablestacktelemetry,_disable_exception_events)

exceptions=off: JVM exception events enabled, exception telemetry is not started but can be started later (the same as current disablestacktelemetry)

exceptions=on: JVM exception events enabled, exception telemetry starts immediately, and of course can be turned off and on in runtime

A profiling agent that uses the JVMTI API can ask the JVM to notify it about occurring exceptions by enabling the exception event. The event can only be enabled on the JVM start, as the existing JVMs do not allow to enable it at a later stage. In other words, you cannot ask the JVM to turn it on or off on demand.

When the event is enabled, there is no noticeable overhead in most cases.

The profiler's exception telemetry feature processes (records) the exception events. The event processing adds overhead, but it is also small in most cases. When the exception telemetry is not running, the event processing code is a no-op and the only overhead is the JVM's activity for issuing the event which, as said above, is usually negligible.

Your example is very special and unusual as it throws a huge number of exceptions in a loop. This is not a normal application's pattern, and in this particular case the usually small overhead becomes big. That's why your example benefited from disabling (i.e. not enabling) the event.