Why does the debugged program slow down so much when using method entry debugging?

Question

I'm using jdi interfaces to create a debugger and when I use MethodEntryRequests to enable method entry tracing the debugged program slows down by factor of tens. I have set filter for main thread and suspend policy to SUSPEND_EVENT_THREAD. Classfilter is limited and if I print any received events it doesn't show more than couple of dozen of those so it shouldn't receive too much of them. I'm debugging locally and having followind kind of command-line with the debugged java program:

-Xdebug -Xrunjdwp:transport=dt_socket,suspend=y,server=y,address=1337

Demodulate

Good question. I noticed method entry breakpoints slow things down considerably when I'm debugging Java programs with Eclipse. I hope someone has the answer! – Recommend

Has the situation improved in recent java versions or is it the same ? – Demonolater

Answer 1

The short answer is that execution runs through the interpreter when method entries are set. I don't think there is anyway around this...

This used to be the case for all code running in debug mode but it was enhanced in 1.4... now HotSpot works for 'full-speed' debugging except in the case of method entries and exits, watchpoints and when single stepping or in methods that contain breakpoints.

Mourant

It really only makes sense...HotSpot does all sorts of nice things in compiling code to speed it up (including in-lining methods which blurs the boundaries between the methods involved). On top of that, it is adaptive so between runs how a method runs can change. Definitely not something you want to have happen when you are in the middle of debugging. – Mourant

Answer 2

2 reasons:

1. it has to add checks on every method entry (there is no option to tweak just some methods)
2. method inlining becomes impossible (so small methods runs 10-100x times slower)

same goes to profilers and .net apps

Pick

Why does method inlining become impossible? – Grassquit

Because method inlining means that you don't have that method any more - whole it's content will be INLINED in all places from which it's calling and no method invocation will occure. But debugger needs that method because it's the place where it's taking the place. – Pick

It sound valid but not sound strong enough to me. INLINED method can still be traced by debugger? Technically it should know the enclosing method it is being inline to? – Rabbitfish

Has the situation improved in recent java versions or is it the same ? – Demonolater

Answer 3

I would assume that the debugger needs to wake up for every method call to see if it matches the one(s) that were selected to break. Because it has to check every method call for a potential match before it can execute it is considerably slower than if it does not have to do all these checks.

Lelialelith