BatchEventProcessor.processEvents performance

While profiling a simple D-Bus-based application, I noticed the following:

     1764406    2.74%        1  OptoRuntime::handle_exception_C_helper(JavaThread*, nmethod*&)

The application is not in any failure scenario, so I would have expected that all messages could be processed without throwing exceptions. The exception handling is inside processEvents:

https://github.com/LMAX-Exchange/disruptor/blob/305d7371765b0cf0f670a059cbfaf9e0691da27c/src/main/java/com/lmax/disruptor/BatchEventProcessor.java#L156

The profile output shows:

--- 2116394 ns (3.28%), 1 sample
  [ 0] exit_to_usermode_loop_[k]
  [ 1] prepare_exit_to_usermode_[k]
  [ 2] swapgs_restore_regs_and_return_to_usermode_[k]
  [ 3] OptoRuntime::handle_exception_C_helper(JavaThread*, nmethod*&)
  [ 4] OptoRuntime::handle_exception_C(JavaThread*)
  [ 5] com.lmax.disruptor.BatchEventProcessor.processEvents
  [ 6] com.lmax.disruptor.BatchEventProcessor.run
  [ 7] java.lang.Thread.run

I don’t know what particular exception is causing the exception catch clause to be invoked, if any, or if there’s anything that can be changed to improve the performance. Feel free to close if nothing practical can be done.

The full async-profile log is attached.

dbus-2.log

[grumpyjames]

Also, in case I haven’t made it clear: that timeout exception is thrown when a ringbuffer consumer sees no events for a configured amount of time. We could probably rename all the timeout parts as “onTemporarilyIdle” or similar.

That rather suggests that the thread in question is probably not of that much interest to your profile anyway.

[DaveJarvis]

Closing as not applicable.