4

While debugging a java process that is normally ready in 90 seconds, my server application kept timing out after 10 minutes because I had a method entry breakpoint set before the breakpoint ever even had a chance to trip.

According to the accepted answer to this SO question, this is at least partly due to the Hotspot JIT compiler being disabled when an entry breakpoint is set. Why does the debugged program slow down so much when using method entry debugging?

However, my JVM seemed to be running orders of magnitude slower. The process I was debugging is multi-threaded and I was debugging remotely via eclipse. Looking at the task manager when the entry breakpoint was set showed one core performing significantly more work than the other cores. With the breakpoint removed, the load across the cores was more even.

While at least some of the slowness can be explained by JIT compilation being disabled, I am wondering if method entry breakpoints check with the debugger process for every method invocation, in effect causing the threads to synchronize on the remote debugger process for every method invocation. To me, it seems this could cause more significant slowdown than the loss of JIT.

Community
  • 1
  • 1
Kylos
  • 1,888
  • 14
  • 24

1 Answers1

0

I don't think method entry breakpoints should cause all invocations checked and I haven't read anything specifically confirming this behavior.

The Java Debug Interface provides event thread suspension policies when any breakpoint is hit and I think you've probably already known these policies. I'd expect the number of overall working thread would drop, maybe even more threads than you expected were suspended, and as a result the overall throughput dropped significantly.

Plus, since you were debugging remotely, is there any chance the network was experiencing delays, etc.?

IUSR
  • 81
  • 4