Skip to main content

JDI problems

5 replies [Last post]
lbarowski
Offline
Joined: 2005-08-03

I reported a JDI problem using the bug report page but had it rejected because of not providing a test case. This is annoying - a test case is not always practical, and in this case it should be obvious that it is not, and that the problem is serious enough to at least notify an appropriate developer. The bug report reviewers should be allowed to user their common sense.

Anyway, with build 1.6.0-ea-b47, ThreadReference.isAtBreakpoint() and ThreadReference.ownedMonitors() are sometimes very slow, taking as much as half a second to complete. This is not always the case, but seems to happen immediately after a breakpoint event, for example. We always call these while the vm is suspended. The problem did not happen in Java 1.5 or any previous versions. Our debugger continuously displays the status and monitors for each thread, and because of this it is basically unusable under Java 1.6 (for now, we have disabled those features when running under 1.6 ea, and there don't seem to be any other problems).

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
batemana
Offline
Joined: 2003-06-17

Thanks Larry. This is now in the bug database as 6311508 - it should be visible on bugs.sun.com in a day or two. It is good to catch issues like this early. There have been a few changes in the VM recently which might have caused the JVMTI GetOwnedMonitorInfo implementation to have to do extra work. This should become clear once the issue is duplicated. One useful piece of information would be to know if b47 is the first build where you observed the slowdown.

lbarowski
Offline
Joined: 2005-08-03

I just tried b44 and it happens there also. Both shared memory and socket connections show the problem. In all cases we attach to an already running (suspended) process. There don't seem to be any significant CPU usage spikes in the debugger or target, but it's hard to tell.

I suppose you could instrument jdb so it calls isAtBreakpoint() and ownedMonitors() on every thread each time an event is processed, and hopefully the problem will show itself.

batemana
Offline
Joined: 2003-06-17

I suspect the issue is a change in b43 that makes the stack walk to get the owned monitors more expensive in some cases. This means the interesting builds to compare are b42 and b43. If you have these builds then that would be a good test. I just checked http://download.java.net/jdk6/archive and unfortunately the oldest build online is b44. If you don't have these older builds let us know as there maybe be a few -XX options that we can use to narrow this down.

lbarowski
Offline
Joined: 2005-08-03

I don't have them.

lbarowski
Offline
Joined: 2005-08-03

This is an update for anyone reading this. I just provided a test case using jdb. Debug any program using jdb, set a breakpoint, and run to it. Then invoke the "threads" command. Under Java 1.6 there is a long delay (~1.5 sec. on my system) before the info for the stopped thread is displayed. Under Java 1.5 the results are essentially instant. I assume this is due to the slowness of isAtBreakpoint() for threads that are at breakpoints.