30-40 second pauses in debugger, 'Collecting data...'

Hi, all.

I've been looking through this newsgroup, but haven't found anything
recently that looks to address this problem.

I've been using Irida for about 2 weeks (previously I was using 4.5). I'm
currently running build 3386 of Irida, and before that had build 3378. In
both builds, there are significant pauses when a breakpoint is reached, with
the display simply saying 'Collecting data...'. My timing (objective) is
that these take 30-40 seconds to complete. (Subjectively it takes much,
much longer :).

As an attempt to describe my environment, I'm on a Windows XP platform, SP 2
on a 3.2 Ghz Xeon processor, with 3GB memory. I have JDK 1.5.0_04. running
Remote Debugging using Socket transport, attaching to a 'client' and a
'server' process both running on my machine. The 'client' is running a unit
test, so not very heavy. The 'server' is running under JBoss. When the
debugger is waiting on the 'Collecting data...', my Cpu is basically idle,
and memory usage isn't high or climbing.

Debugging the same project under Idea 4.5 (except using JDK 1.4.2_08)
displayed no such delays.

Anyone got any ideas? Is there anything else in my setup that could help
diagnose what's wrong? I wanted to post here in case this is a known issue,
before logging it.

Thanks!

Bob.


34 comments
Comment actions Permalink

I am also having problems with debugger. I am debugging tomcat (as remote setup), however in my case delay is about 5 seconds. (4.5 debugger doesn't have any delay).
I also have this disconnecting issue: http://www.jetbrains.net/jira/browse/IDEA-2765


I am somewhat suprised that noone else is having those issues, so I am wondering if they don't debug web apps, or they don't have those problems.

0
Comment actions Permalink

Bob Sandiford wrote:

currently running build 3386 of Irida, and before that had build 3378. In
both builds, there are significant pauses when a breakpoint is reached, with


I've seen this on builds since 3378 ( havn't tried debugging on the
latest 3396 thou it happened on 3394 ).

Not sure whats up :( This is Ubuntu Linux under 1.5.0_04

0
Comment actions Permalink

Seen this on OSX as well, I don't think it's platform specific.

0
Comment actions Permalink

Robert S. Sfeir wrote:

Seen this on OSX as well, I don't think it's platform specific.


Yep, I saw this yesterday on Win2000. I was remotely connected to a
WebSphere 6 process started in debug mode. When it hit the first
breakpoint, it sat for about 20 seconds collecting data.

Ciao,
Gordon

--
Gordon Tyler (Software Developer)
Quest Software <http://www.quest.com/>
260 King Street East, Toronto, Ontario M5A 4L5, Canada
Voice: (416) 933-5046 | Fax: (416) 933-5001

0
Comment actions Permalink

I see this sometimes on Windows XP, Java 1.5, with a remote connection to Resin 2.1.x (running on localhost, also Java 1.5).

0
Comment actions Permalink

I see some delay on "Collecting data..." here, but it's no t that bad. What's really bad is reloading classes: this can take more than a minute, even for a single changed class.

0
Comment actions Permalink

WebSphere 6 process started in debug mode. When it hit the first breakpoint, it sat for about 20 seconds collecting data.


Does it happen only with the first breakpoint or all subsequent breaks are also rendered too slow?

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"


0
Comment actions Permalink

Please start IDEA you work with with the following VM option:

-Didea.debugger.trace="SENDS RECEIVES"
This will enable logging of communication events between IDEA and debuggee VM.
Then check data in idea-system-dir/log/idea.log

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

"Bob Sandiford" <bsandiford@dynix.com> wrote in message news:dae9gi$qp8$1@is.intellij.net...

Hi, all.

>

I've been looking through this newsgroup, but haven't found anything recently that looks to address this problem.

>

I've been using Irida for about 2 weeks (previously I was using 4.5). I'm currently running build 3386 of Irida, and before that
had build 3378. In both builds, there are significant pauses when a breakpoint is reached, with the display simply saying
'Collecting data...'. My timing (objective) is that these take 30-40 seconds to complete. (Subjectively it takes much, much
longer :).

>

As an attempt to describe my environment, I'm on a Windows XP platform, SP 2 on a 3.2 Ghz Xeon processor, with 3GB memory. I have
JDK 1.5.0_04. running Remote Debugging using Socket transport, attaching to a 'client' and a 'server' process both running on my
machine. The 'client' is running a unit test, so not very heavy. The 'server' is running under JBoss. When the debugger is
waiting on the 'Collecting data...', my Cpu is basically idle, and memory usage isn't high or climbing.

>

Debugging the same project under Idea 4.5 (except using JDK 1.4.2_08) displayed no such delays.

>

Anyone got any ideas? Is there anything else in my setup that could help diagnose what's wrong? I wanted to post here in case
this is a known issue, before logging it.

>

Thanks!

>

Bob.

>



0
Comment actions Permalink

I also encountered a delay in debugging, though much less than 30-40 seconds (more like 5-6 seconds)
Only on the first breakpoint though. I figured it has to do with some lazy initialization or
something of the sort...

Eugene Zhuravlev (JetBrains) wrote:
>>WebSphere 6 process started in debug mode. When it hit the first breakpoint, it sat for about 20 seconds collecting data.


Does it happen only with the first breakpoint or all subsequent breaks are also rendered too slow?

0
Comment actions Permalink

Every break point. No difference I've noticed between first and subsequent.

Bob.

"Eugene Zhuravlev (JetBrains)" <jeka@intellij.com> wrote in message
news:daqsvp$1an$1@is.intellij.net...
>> WebSphere 6 process started in debug mode. When it hit the first
>> breakpoint, it sat for about 20 seconds collecting data.
>

Does it happen only with the first breakpoint or all subsequent breaks are
also rendered too slow?

>

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"



0
Comment actions Permalink

OK, will do, first thing tomorrow (Monday) my time...

I assume this goes in the idea.exe.vmoptions?

Bob.

"Eugene Zhuravlev (JetBrains)" <jeka@intellij.com> wrote in message
news:daqtge$3cf$1@is.intellij.net...

Please start IDEA you work with with the following VM option:

>

-Didea.debugger.trace="SENDS RECEIVES"
This will enable logging of communication events between IDEA and debuggee
VM.
Then check data in idea-system-dir/log/idea.log

>

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

>

"Bob Sandiford" <bsandiford@dynix.com> wrote in message
news:dae9gi$qp8$1@is.intellij.net...

>> Hi, all.
>>
>> I've been looking through this newsgroup, but haven't found anything
>> recently that looks to address this problem.
>>
>> I've been using Irida for about 2 weeks (previously I was using 4.5).
>> I'm currently running build 3386 of Irida, and before that had build
>> 3378. In both builds, there are significant pauses when a breakpoint is
>> reached, with the display simply saying 'Collecting data...'. My timing
>> (objective) is that these take 30-40 seconds to complete. (Subjectively
>> it takes much, much longer :).
>>
>> As an attempt to describe my environment, I'm on a Windows XP platform,
>> SP 2 on a 3.2 Ghz Xeon processor, with 3GB memory. I have JDK 1.5.0_04.
>> running Remote Debugging using Socket transport, attaching to a 'client'
>> and a 'server' process both running on my machine. The 'client' is
>> running a unit test, so not very heavy. The 'server' is running under
>> JBoss. When the debugger is waiting on the 'Collecting data...', my Cpu
>> is basically idle, and memory usage isn't high or climbing.
>>
>> Debugging the same project under Idea 4.5 (except using JDK 1.4.2_08)
>> displayed no such delays.
>>
>> Anyone got any ideas? Is there anything else in my setup that could help
>> diagnose what's wrong? I wanted to post here in case this is a known
>> issue, before logging it.
>>
>> Thanks!
>>
>> Bob.
>>
>>
>



0
Comment actions Permalink

Only on the first break point. Subsequent breaks are quite snappy. The problem with reloading classes happen every time, however.

0
Comment actions Permalink

Yes, this should work. Also the tracing slows down debugging, so do not leave the option there after getting the profile.


"Bob Sandiford" <bsandiford@dynix.com> wrote in message news:daro6f$j0l$1@is.intellij.net...

OK, will do, first thing tomorrow (Monday) my time...

>

I assume this goes in the idea.exe.vmoptions?

>

Bob.

>

"Eugene Zhuravlev (JetBrains)" <jeka@intellij.com> wrote in message news:daqtge$3cf$1@is.intellij.net...

>> Please start IDEA you work with with the following VM option:
>>
>> -Didea.debugger.trace="SENDS RECEIVES"
>> This will enable logging of communication events between IDEA and debuggee VM.
>> Then check data in idea-system-dir/log/idea.log
>>
>> --
>> Best regards,
>> Eugene Zhuravlev
>> Software Developer
>> JetBrains Inc.
>> http://www.jetbrains.com
>> "Develop with pleasure!"
>>
>> "Bob Sandiford" <bsandiford@dynix.com> wrote in message news:dae9gi$qp8$1@is.intellij.net...
>>> Hi, all.
>>>
>>> I've been looking through this newsgroup, but haven't found anything recently that looks to address this problem.
>>>
>>> I've been using Irida for about 2 weeks (previously I was using 4.5). I'm currently running build 3386 of Irida, and before that
>>> had build 3378. In both builds, there are significant pauses when a breakpoint is reached, with the display simply saying
>>> 'Collecting data...'. My timing (objective) is that these take 30-40 seconds to complete. (Subjectively it takes much, much
>>> longer :).
>>>
>>> As an attempt to describe my environment, I'm on a Windows XP platform, SP 2 on a 3.2 Ghz Xeon processor, with 3GB memory. I
>>> have JDK 1.5.0_04. running Remote Debugging using Socket transport, attaching to a 'client' and a 'server' process both running
>>> on my machine. The 'client' is running a unit test, so not very heavy. The 'server' is running under JBoss. When the debugger
>>> is waiting on the 'Collecting data...', my Cpu is basically idle, and memory usage isn't high or climbing.
>>>
>>> Debugging the same project under Idea 4.5 (except using JDK 1.4.2_08) displayed no such delays.
>>>
>>> Anyone got any ideas? Is there anything else in my setup that could help diagnose what's wrong? I wanted to post here in case
>>> this is a known issue, before logging it.
>>>
>>> Thanks!
>>>
>>> Bob.
>>>
>>>
>>
>>
>



0
Comment actions Permalink

Eugene Zhuravlev (JetBrains) wrote:
>>WebSphere 6 process started in debug mode. When it hit the first breakpoint, it sat for about 20 seconds collecting data.


Does it happen only with the first breakpoint or all subsequent breaks are also rendered too slow?


I'm not 100% sure, but I recall that stepping through the code after the
breakpoint was reasonably quick.

Ciao,
Gordon

--
Gordon Tyler (Software Developer)
Quest Software <http://www.quest.com/>
260 King Street East, Toronto, Ontario M5A 4L5, Canada
Voice: (416) 933-5046 | Fax: (416) 933-5001

0
Comment actions Permalink

Hi, Eugene.

Can you please confirm the change required to the idea.exe.vmoptions? I
made the change, started IntelliJ, ran a debugging test, shut down IntelliJ,
and saved the log under a different name. Then I removed the change,
re-started IntelliJ and ran the same debugging test, and shut down IntelliJ
(i.e. as closely as I could, I did the same thing both with and without the
change to the idea.exe.vmoptions file). When I compare the two log files,
they appear substantially identical. (Different times, different addresses,
but 98% of the rest is identical). The differences that DO show don't
appear to have anything to do with the debugger.

(I did this in build 3401, by the way...)

Thanks!

Bob.

"Eugene Zhuravlev (JetBrains)" <jeka@intellij.com> wrote in message
news:datopv$j24$1@is.intellij.net...

Yes, this should work. Also the tracing slows down debugging, so do not
leave the option there after getting the profile.

>
>

"Bob Sandiford" <bsandiford@dynix.com> wrote in message
news:daro6f$j0l$1@is.intellij.net...

>> OK, will do, first thing tomorrow (Monday) my time...
>>
>> I assume this goes in the idea.exe.vmoptions?
>>
>> Bob.
>>
>> "Eugene Zhuravlev (JetBrains)" <jeka@intellij.com> wrote in message
>> news:daqtge$3cf$1@is.intellij.net...
>>> Please start IDEA you work with with the following VM option:
>>>
>>> -Didea.debugger.trace="SENDS RECEIVES"
>>> This will enable logging of communication events between IDEA and
>>> debuggee VM.
>>> Then check data in idea-system-dir/log/idea.log
>>>
>>> --
>>> Best regards,
>>> Eugene Zhuravlev
>>> Software Developer
>>> JetBrains Inc.
>>> http://www.jetbrains.com
>>> "Develop with pleasure!"



0
Comment actions Permalink

I have the same problem. Debugging is slow and IDEA sometimes even hangs
forever.
The messages are printed to the console, not the log file.
I attached the output and the stack trace.
Or should I file an JIRA report?

Sven.

Eugene Zhuravlev (JetBrains) schrieb:

Please start IDEA you work with with the following VM option:

-Didea.debugger.trace="SENDS RECEIVES"
This will enable logging of communication events between IDEA and debuggee VM.
Then check data in idea-system-dir/log/idea.log


Full thread dump Java HotSpot(TM) Client VM (1.5.0_04-b05 mixed mode):

"DebuggerManagerThreadImpl11" prio=7 tid=0x285d8f68 nid=0xbfc in Object.wait() [0x2f91f000..0x2f91f9
e8]
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:474)
at com.sun.tools.jdi.TargetVM.waitForReply(TargetVM.java:281)
- locked (a com.sun.tools.jdi.Packet) at com.sun.tools.jdi.VirtualMachineImpl.waitForTargetReply(VirtualMachineImpl.java:933) at com.sun.tools.jdi.PacketStream.waitForReply(PacketStream.java:51) at com.sun.tools.jdi.JDWP$EventRequest$Set.waitForReply(JDWP.java:6212) at com.sun.tools.jdi.JDWP$EventRequest$Set.process(JDWP.java:6177) at com.sun.tools.jdi.EventRequestManagerImpl$EventRequestImpl.set(EventRequestManagerImpl.ja va:178) - locked <0x03e300b8> (a com.sun.tools.jdi.EventRequestManagerImpl$ClassPrepareRequestImpl) at com.sun.tools.jdi.EventRequestManagerImpl$EventRequestImpl.setEnabled(EventRequestManager Impl.java:142) - locked <0x03e300b8>]]> (a com.sun.tools.jdi.EventRequestManagerImpl$ClassPrepareRequestImpl)
at com.sun.tools.jdi.EventRequestManagerImpl$EventRequestImpl.enable(EventRequestManagerImpl
.java:127)
at com.intellij.debugger.engine.requests.RequestManagerImpl.callbackOnPrepareClasses(Request
ManagerImpl.java:59)
at com.intellij.debugger.ui.breakpoints.Breakpoint$1.run(Breakpoint.java:5)
at com.intellij.openapi.application.impl.ApplicationImpl.runReadAction(ApplicationImpl.java:
252)
at com.intellij.debugger.ui.breakpoints.Breakpoint.createOrWaitPrepare(Breakpoint.java:61)
at com.intellij.debugger.ui.breakpoints.BreakpointWithHighlighter.createRequest(BreakpointWi
thHighlighter.java:194)
at com.intellij.debugger.engine.requests.RequestManagerImpl$3.action(RequestManagerImpl.java
)
at com.intellij.debugger.engine.requests.RequestManagerImpl$2.action(RequestManagerImpl.java
)
at com.intellij.debugger.engine.events.DebuggerCommandImpl.run(DebuggerCommandImpl.java)
at com.intellij.debugger.engine.DebuggerManagerThreadImpl.processEvent(DebuggerManagerThread
Impl.java:5)
at com.intellij.debugger.engine.DebuggerManagerThreadImpl.processEvent(DebuggerManagerThread
Impl.java:44)
at com.intellij.debugger.impl.InvokeThread.run(InvokeThread.java:31)
at com.intellij.debugger.impl.InvokeThread$1.run(InvokeThread.java)

"DebuggerEventThread" prio=7 tid=0x28510e78 nid=0x728 in Object.wait()
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:474)
at com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(EventQueueImpl.java:162)
- locked (a com.sun.tools.jdi.EventQueueImpl) at com.sun.tools.jdi.EventQueueImpl.remove(EventQueueImpl.java:78) at com.sun.tools.jdi.EventQueueImpl.remove(EventQueueImpl.java:64) at com.intellij.debugger.engine.DebugProcessEvents$DebuggerEventThread.run(DebugProcessEvent s.java:23) "JDI Target VM Interface" daemon prio=7 tid=0x2e41a250 nid=0xd7c waiting for monitor entry [0x2f85f0 00..0x2f85fc68] at com.sun.tools.jdi.VMState.notifyCommandComplete(VMState.java:78) - waiting to lock <0x1121e560> (a com.sun.tools.jdi.VMState) at com.sun.tools.jdi.TargetVM.run(TargetVM.java:128) at java.lang.Thread.run(Thread.java:595) "JDI Internal Event Handler" daemon prio=7 tid=0x285c5d10 nid=0xcf8 in Object.wait() [0x2f81f000..0x 2f81fce8] at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:474) at com.sun.tools.jdi.EventQueueImpl.removeUnfiltered(EventQueueImpl.java:162) - locked <0x1120b840>]]> (a com.sun.tools.jdi.EventQueueImpl)
at com.sun.tools.jdi.EventQueueImpl.removeInternal(EventQueueImpl.java:97)
at com.sun.tools.jdi.InternalEventHandler.run(InternalEventHandler.java:36)
at java.lang.Thread.run(Thread.java:595)

"Thread-162" prio=7 tid=0x284a2340 nid=0x5ac in Object.wait()
at java.lang.Object.wait(Native Method)
- waiting on (a com.intellij.util.concurrency.Semaphore) at java.lang.Object.wait(Object.java:474) at com.intellij.util.concurrency.Semaphore.waitFor(Semaphore.java:28) - locked <0x1120b8c8> (a com.intellij.util.concurrency.Semaphore) at com.intellij.execution.process.OSProcessHandler$ProcessWaitFor.waitFor(OSProcessHandler.j ava:55) at com.intellij.execution.process.OSProcessHandler$3$1.run(OSProcessHandler.java:90) "ReadProcessThread java.io.BufferedReader" prio=10 tid=0x282417b0 nid=0xa7c runnable [0x2992f000..0x 2992f9e8] at java.io.FileInputStream.readBytes(Native Method) at java.io.FileInputStream.read(FileInputStream.java:194) at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:411) at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) - locked <0x11211a00> (a java.io.InputStreamReader) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.fill(BufferedReader.java:136) at java.io.BufferedReader.read(BufferedReader.java:157) - locked <0x11211a00> (a java.io.InputStreamReader) at com.intellij.execution.process.OSProcessHandler$ReadProcessThread.readNextByte(OSProcessH andler.java:215) at com.intellij.execution.process.OSProcessHandler$ReadProcessThread.run(OSProcessHandler.ja va:193) "ReadProcessThread java.io.BufferedReader" prio=10 tid=0x284c7720 nid=0xf74 runnable [0x298ef000..0x 298efa68] at java.io.FileInputStream.readBytes(Native Method) at java.io.FileInputStream.read(FileInputStream.java:194) at java.io.BufferedInputStream.read1(BufferedInputStream.java:254) at java.io.BufferedInputStream.read(BufferedInputStream.java:313) - locked <0x11213af0> (a java.io.BufferedInputStream) at sun.nio.cs.StreamDecoder$CharsetSD.readBytes(StreamDecoder.java:411) at sun.nio.cs.StreamDecoder$CharsetSD.implRead(StreamDecoder.java:453) at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:183) - locked <0x11217b78> (a java.io.InputStreamReader) at java.io.InputStreamReader.read(InputStreamReader.java:167) at java.io.BufferedReader.fill(BufferedReader.java:136) at java.io.BufferedReader.read(BufferedReader.java:157) - locked <0x11217b78>]]> (a java.io.InputStreamReader)
at com.intellij.execution.process.OSProcessHandler$ReadProcessThread.readNextByte(OSProcessH
andler.java:215)
at com.intellij.execution.process.OSProcessHandler$ReadProcessThread.run(OSProcessHandler.ja
va:193)

"Thread-161" prio=7 tid=0x2848e040 nid=0xde8 runnable
at java.lang.ProcessImpl.waitFor(Native Method)
at com.intellij.execution.process.OSProcessHandler$ProcessWaitFor$1.run(OSProcessHandler.jav
a:44)

"DebuggerManagerThreadImpl6" prio=7 tid=0x284bc5e8 nid=0xff0 in Object.wait() [0x2875f000..0x2875fb6
8]
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:474)
at com.sun.tools.jdi.TargetVM.waitForReply(TargetVM.java:281)
- locked (a com.sun.tools.jdi.Packet) at com.sun.tools.jdi.VirtualMachineImpl.waitForTargetReply(VirtualMachineImpl.java:933) at com.sun.tools.jdi.PacketStream.waitForReply(PacketStream.java:51) at com.sun.tools.jdi.JDWP$StringReference$Value.waitForReply(JDWP.java:4542) at com.sun.tools.jdi.JDWP$StringReference$Value.process(JDWP.java:4523) at com.sun.tools.jdi.StringReferenceImpl.value(StringReferenceImpl.java:26) at com.sun.tools.jdi.StringReferenceImpl.toString(StringReferenceImpl.java:36) at java.lang.String.valueOf(String.java:2577) at java.lang.StringBuilder.append(StringBuilder.java:116) at com.sun.tools.jdi.JDWP$ClassType$InvokeMethod.enqueueCommand(JDWP.java:3088) at com.sun.tools.jdi.ClassTypeImpl$1.send(ClassTypeImpl.java:155) at com.sun.tools.jdi.VMState.thawCommand(VMState.java:94) - locked <0x1121e560>]]> (a com.sun.tools.jdi.VMState)
at com.sun.tools.jdi.VirtualMachineImpl.sendResumingCommand(VirtualMachineImpl.java:367)
at com.sun.tools.jdi.ClassTypeImpl.sendInvokeCommand(ClassTypeImpl.java:165)
at com.sun.tools.jdi.ClassTypeImpl.invokeMethod(ClassTypeImpl.java:212)
at com.intellij.debugger.engine.DebugProcessImpl$6.invokeMethod(DebugProcessImpl.java:2)
at com.intellij.debugger.engine.DebugProcessImpl$InvokeCommand$1.run(DebugProcessImpl.java:1
2)
at com.intellij.debugger.engine.DebuggerManagerThreadImpl.startLongProcessAndFork(DebuggerMa
nagerThreadImpl.java:29)
at com.intellij.debugger.engine.DebugProcessImpl$InvokeCommand.a(DebugProcessImpl.java:40)
at com.intellij.debugger.engine.DebugProcessImpl$InvokeCommand.start(DebugProcessImpl.java:3
1)
at com.intellij.debugger.engine.DebugProcessImpl.invokeMethod(DebugProcessImpl.java:443)
at com.intellij.debugger.engine.DebugProcessImpl.loadClass(DebugProcessImpl.java:604)
at com.intellij.debugger.engine.DebugProcessImpl.findClass(DebugProcessImpl.java:229)
at com.intellij.debugger.ui.tree.render.BatchEvaluator.hasBatchEvaluator(BatchEvaluator.java
:58)
at com.intellij.debugger.ui.tree.render.BatchEvaluator.invoke(BatchEvaluator.java:66)
at com.intellij.debugger.ui.tree.render.ToStringRenderer.calcLabel(ToStringRenderer.java:64)

at com.intellij.debugger.ui.impl.watch.ValueDescriptorImpl.a(ValueDescriptorImpl.java:16)
at com.intellij.debugger.ui.impl.watch.ValueDescriptorImpl.calcRepresentation(ValueDescripto
rImpl.java:127)
at com.intellij.debugger.ui.impl.watch.NodeDescriptorImpl.updateRepresentationNoNotify(NodeD
escriptorImpl.java:5)
at com.intellij.debugger.ui.impl.watch.DebuggerTreeNodeImpl.createNode(DebuggerTreeNodeImpl.
java:35)
at com.intellij.debugger.ui.impl.watch.NodeManagerImpl.createNode(NodeManagerImpl.java:4)
at com.intellij.debugger.ui.impl.watch.NodeManagerImpl.createNode(NodeManagerImpl.java:3)
at com.intellij.debugger.ui.tree.render.ClassRenderer.buildChildren(ClassRenderer.java:66)
at com.intellij.debugger.ui.impl.watch.DebuggerTree$BuildValueNodeCommand.threadAction(Debug
gerTree.java:10)
at com.intellij.debugger.engine.events.DebuggerContextCommandImpl.contextAction(DebuggerCont
extCommandImpl.java:0)
at com.intellij.debugger.engine.SuspendManagerUtil.runCommand(SuspendManagerUtil.java:14)
at com.intellij.debugger.engine.events.SuspendContextCommandImpl.action(SuspendContextComman
dImpl.java:11)
at com.intellij.debugger.engine.events.DebuggerCommandImpl.run(DebuggerCommandImpl.java)
at com.intellij.debugger.engine.DebuggerManagerThreadImpl.processEvent(DebuggerManagerThread
Impl.java:5)
at com.intellij.debugger.engine.DebuggerManagerThreadImpl.processEvent(DebuggerManagerThread
Impl.java:44)
at com.intellij.debugger.impl.InvokeThread.run(InvokeThread.java:31)
at com.intellij.debugger.impl.InvokeThread$1.run(InvokeThread.java)

"EditorCaretThread" prio=7 tid=0x28372920 nid=0x798 waiting on condition
at java.lang.Thread.sleep(Native Method)
at com.intellij.openapi.editor.impl.EditorImpl$RepaintCursorThread.run(EditorImpl.java:33)

"AlarmThread" prio=7 tid=0x27653048 nid=0xb28 in Object.wait()
at java.lang.Object.wait(Native Method)
- waiting on (a java.lang.Object) at java.lang.Object.wait(Object.java:474) at com.intellij.util.Alarm$MyThread.run(Alarm.java:194) - locked <0x06683238>]]> (a java.lang.Object)

"Thread-6" prio=7 tid=0x278c85f0 nid=0xf0 waiting on condition
at java.lang.Thread.sleep(Native Method)
at com.intellij.diagnostic.IdeMessagePanel$Blinker.run(IdeMessagePanel.java:12)

"Fatal Errors Grouper" prio=7 tid=0x28090d60 nid=0x81c waiting on condition

at java.lang.Thread.sleep(Native Method)
at com.intellij.diagnostic.MessagePool$MessageGrouper.run(MessagePool.java:22)

"StoreRefreshStatusThread" prio=2 tid=0x28065ce8 nid=0x418 waiting on condition [0x2894f000..0x2894f
ce8]
at java.lang.Thread.sleep(Native Method)
at com.intellij.openapi.vfs.impl.local.LocalFileSystemImpl$StoreRefreshStatusThread.run(Loca
lFileSystemImpl.java:1)

"WatchForChangesThread" prio=7 tid=0x280b0620 nid=0x43c runnable
at com.intellij.vfs.local.win32.FileWatcher.waitForChangeImpl(Native Method)
at com.intellij.vfs.local.win32.FileWatcher.waitForChange(FileWatcher.java:24)
at com.intellij.openapi.vfs.impl.local.LocalFileSystemImpl$WatchForChangesThread.run(LocalFi
leSystemImpl.java:1)

"Thread-2" prio=7 tid=0x280cf360 nid=0x654 waiting on condition
at java.lang.Thread.sleep(Native Method)
at com.intellij.openapi.progress.impl.ProgressManagerImpl$1.run(ProgressManagerImpl.java:5)

"AWT-EventQueue-1" prio=7 tid=0x27442db0 nid=0x138 in Object.wait()
at java.lang.Object.wait(Native Method)
- waiting on (a com.intellij.util.concurrency.WriterPreferenceReadWriteLock$Wri terLock) at java.lang.Object.wait(Object.java:474) at com.intellij.util.concurrency.WriterPreferenceReadWriteLock$WriterLock.acquire(WriterPref erenceReadWriteLock.java:240) - locked <0x057ab5b0> (a com.intellij.util.concurrency.WriterPreferenceReadWriteLock$WriterL ock) at com.intellij.openapi.application.impl.ApplicationImpl.runWriteAction(ApplicationImpl.java :51) at com.intellij.psi.impl.PsiDocumentManagerImpl.commitDocument(PsiDocumentManagerImpl.java:1 13) at com.intellij.openapi.fileEditor.impl.text.TextEditorImpl.getStateImpl(TextEditorImpl.java :2) at com.intellij.openapi.fileEditor.impl.text.TextEditorImpl.getState(TextEditorImpl.java:76) at com.intellij.openapi.fileEditor.impl.EditorsSplitters.writePanel(EditorsSplitters.java:21 0) at com.intellij.openapi.fileEditor.impl.EditorsSplitters.writeExternal(EditorsSplitters.java :262) at com.intellij.openapi.fileEditor.impl.FileEditorManagerImpl.writeExternal(FileEditorManage rImpl.java:98) at com.intellij.openapi.components.impl.ComponentManagerImpl.serializeComponent(ComponentMan agerImpl.java:55) at com.intellij.openapi.project.impl.BaseFileConfigurable.saveToXml(BaseFileConfigurable.jav a:39) at com.intellij.openapi.project.impl.ProjectImpl.saveToXml(ProjectImpl.java:86) at com.intellij.openapi.project.impl.BaseFileConfigurable._save(BaseFileConfigurable.java:20 2) at com.intellij.openapi.project.impl.ProjectImpl$2.run(ProjectImpl.java:8) at com.intellij.openapi.command.impl.CommandProcessorImpl.executeCommand(CommandProcessorImp l.java:28) at com.intellij.openapi.command.impl.CommandProcessorImpl.executeCommand(CommandProcessorImp l.java:68) at com.intellij.openapi.project.impl.ProjectImpl.save(ProjectImpl.java:174) at com.intellij.ide.SaveAndSyncHandler.c(SaveAndSyncHandler.java:21) at com.intellij.ide.SaveAndSyncHandler.access$300(SaveAndSyncHandler.java:88) at com.intellij.ide.SaveAndSyncHandler$4.run(SaveAndSyncHandler.java:2) at com.intellij.ide.SaveAndSyncHandler.b(SaveAndSyncHandler.java:75) at com.intellij.ide.SaveAndSyncHandler.access$500(SaveAndSyncHandler.java:94) at com.intellij.ide.SaveAndSyncHandler$5.run(SaveAndSyncHandler.java:3) at com.intellij.util.Alarm$1.run(Alarm.java:85) at com.intellij.util.Alarm$MyThread$1.run(Alarm.java:227) at com.intellij.openapi.application.impl.LaterInvocatorEx$FlushQueue.run(LaterInvocatorEx.ja va:20) - locked <0x05b20aa0>]]> (a java.lang.Object)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:461)
at com.intellij.ide.IdeEventQueue.defaultDispatchEvent(IdeEventQueue.java:114)
at com.intellij.ide.IdeEventQueue.a(IdeEventQueue.java:160)
at com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.java:44)
at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)

"AlarmThread" prio=7 tid=0x2743ad90 nid=0x234 in Object.wait()
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:474)
at com.intellij.util.Alarm$MyThread.run(Alarm.java:194)
- locked ]]> (a java.lang.Object)

"AlarmThread" prio=7 tid=0x276fc928 nid=0xcb0 in Object.wait()
at java.lang.Object.wait(Native Method)
at com.intellij.util.Alarm$MyThread.run(Alarm.java:254)
- locked ]]> (a java.lang.Object)

"TimerQueue" daemon prio=5 tid=0x2747fdd0 nid=0x938 in Object.wait()
at java.lang.Object.wait(Native Method)
at javax.swing.TimerQueue.postExpiredTimers(TimerQueue.java:215)
- locked (a javax.swing.TimerQueue) at javax.swing.TimerQueue.run(TimerQueue.java:231) - locked <0x0577a988>]]> (a javax.swing.TimerQueue)
at java.lang.Thread.run(Thread.java:595)

"AWT-Shutdown" prio=5 tid=0x274ddda8 nid=0x4d4 in Object.wait()
at java.lang.Object.wait(Native Method)
- waiting on (a java.lang.Object) at java.lang.Object.wait(Object.java:474) at sun.awt.AWTAutoShutdown.run(AWTAutoShutdown.java:259) - locked <0x056fe640>]]> (a java.lang.Object)
at java.lang.Thread.run(Thread.java:595)

"SocketListenerThread" prio=5 tid=0x276437c0 nid=0xd80 runnable
at java.net.PlainDatagramSocketImpl.receive0(Native Method)
- locked (a java.net.PlainDatagramSocketImpl) at java.net.PlainDatagramSocketImpl.receive(PlainDatagramSocketImpl.java:136) - locked <0x0571bc10> (a java.net.PlainDatagramSocketImpl) at java.net.DatagramSocket.receive(DatagramSocket.java:712) - locked <0x031d4b38> (a java.net.DatagramPacket) - locked <0x0571bc50>]]> (a java.net.MulticastSocket)
at com.intellij.licensecommon.net.impl.SocketImpl.receive(SocketImpl.java:16)
at com.intellij.licensecommon.net.impl.SocketListenerThread.run(SocketListenerThread.java:4)


"SocketListenerThread" prio=5 tid=0x27643240 nid=0xd60 runnable
at java.net.PlainDatagramSocketImpl.receive0(Native Method)
- locked (a java.net.PlainDatagramSocketImpl) at java.net.PlainDatagramSocketImpl.receive(PlainDatagramSocketImpl.java:136) - locked <0x0571e438> (a java.net.PlainDatagramSocketImpl) at java.net.DatagramSocket.receive(DatagramSocket.java:712) - locked <0x0571e478> (a java.net.DatagramPacket) - locked <0x0571e498>]]> (a java.net.DatagramSocket)
at com.intellij.licensecommon.net.impl.SocketImpl.receive(SocketImpl.java:16)
at com.intellij.licensecommon.net.impl.SocketListenerThread.run(SocketListenerThread.java:4)


"MessageDeliveryThread" prio=5 tid=0x2760a1d8 nid=0x894 in Object.wait()
at java.lang.Object.wait(Native Method)
- waiting on (a java.lang.Object) at java.lang.Object.wait(Object.java:474) at com.intellij.licensecommon.net.MessageDeliveryThread.run(MessageDeliveryThread.java:25) - locked <0x0571e538>]]> (a java.lang.Object)

"Java2D Disposer" daemon prio=10 tid=0x27608c30 nid=0xd4c in Object.wait()
at java.lang.Object.wait(Native Method)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)
- locked ]]> (a java.lang.ref.ReferenceQueue$Lock)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132)
at sun.java2d.Disposer.run(Disposer.java:107)
at java.lang.Thread.run(Thread.java:595)

"AWT-Windows" daemon prio=7 tid=0x274fc738 nid=0xd04 runnable
at sun.awt.windows.WToolkit.eventLoop(Native Method)
at sun.awt.windows.WToolkit.run(WToolkit.java:269)
at java.lang.Thread.run(Thread.java:595)

"Lock thread" prio=5 tid=0x2747b890 nid=0xd00 runnable
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
- locked ]]> (a java.net.SocksSocketImpl)
at java.net.ServerSocket.implAccept(ServerSocket.java:450)
at java.net.ServerSocket.accept(ServerSocket.java:421)
at com.intellij.idea.SocketLock$MyRunnable.run(SocketLock.java:4)
at java.lang.Thread.run(Thread.java:595)

"DestroyJavaVM" prio=5 tid=0x00036e00 nid=0x228 waiting on condition

"Low Memory Detector" daemon prio=5 tid=0x27411328 nid=0xcf0 runnable

"CompilerThread0" daemon prio=10 tid=0x00ef8c68 nid=0x250 waiting on condition [0x00000000..0x272cfa
4c]

"Signal Dispatcher" daemon prio=10 tid=0x2742ae60 nid=0xd8c waiting on condition [0x00000000..0x0000
0000]

"YJP CPU Sampler" daemon prio=5 tid=0x00f2fd60 nid=0xcc0 runnable

"YJP RequestServer" daemon prio=5 tid=0x00ef9dc8 nid=0x118 runnable
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
- locked ]]> (a java.net.SocksSocketImpl)
at java.net.ServerSocket.implAccept(ServerSocket.java:450)
at java.net.ServerSocket.accept(ServerSocket.java:421)
at com.yourkit.runtime.RequestServer.doIt(RequestServer.java:240)
at com.yourkit.runtime.RequestServer.access$000(RequestServer.java:12)
at com.yourkit.runtime.RequestServer$1.run(RequestServer.java:229)

"Finalizer" daemon prio=9 tid=0x00ee7e00 nid=0xcb8 in Object.wait()
at java.lang.Object.wait(Native Method)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)
- locked (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) "Reference Handler" daemon prio=10 tid=0x00ee69a8 nid=0xc98 in Object.wait() [0x00e2f000..0x00e2fae8 ] at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:474) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) - locked <0x056a9c30>]]> (a java.lang.ref.Reference$Lock)

"VM Thread" prio=10 tid=0x00ee4cc8 nid=0xc94 runnable

"VM Periodic Task Thread" prio=10 tid=0x274126c8 nid=0xcf4 waiting on condition








[JDI: Sending: modifiers(Modifier[]): ]


[JDI: Sending: classPattern(String): newtron.nmarkets.components.dbtree.DBTr
eeSearchComponent$*]

[JDI: Sending: signature(String): Lnewtron/nmarkets/components/dbtree/DBTreeSearchCo
mponent;]




















[JDI: Sending: modifiers(Modifier[]): ]


[JDI: Sending: loc(Location): newtron.nmarkets.components.dbtree.DBTreeSearc
hComponent$6:203]















[JDI: Sending: modifiers(Modifier[]): ]




















[JDI: Sending: modifiers(Modifier[]): ]






[JDI: Sending: modifiers(Modifier[]): ]


[JDI: Sending: classPattern(String): newtron.nmarkets.gui.HistoryComboBox$Mo
del]



[JDI: Sending: modifiers(Modifier[]): ]


[JDI: Sending: loc(Location): newtron.nmarkets.gui.HistoryComboBox$Model:103
]




[JDI: Sending: modifiers(Modifier[]): ]









[JDI: Sending: modifiers(Modifier[]): ]


[JDI: Sending: classPattern(String): newtron.nmarkets.gui.HistoryComboBox$Mo
del]




















[JDI: Sending: modifiers(Modifier[]): ]


[JDI: Sending: loc(Location): newtron.nmarkets.gui.HistoryComboBox$Model:103
]



















[JDI: Sending: modifiers(Modifier[]): ]




















[JDI

0
Comment actions Permalink

Uhh, sorry. Should have zipped it :(

0
Comment actions Permalink

Hello Bob,

Indeed, this does not work because this is JDI log, and it goes directly to the stderr. Sorry for incorrect instructions...
I've found much simplier way to get a log:

You will need to modify "idea.bat" file like this:
1) replace string
SET JVM_ARGS=%ACC% %REQUIRED_IDEA_JVM_ARGS%
with the string
SET JVM_ARGS=%ACC% %REQUIRED_IDEA_JVM_ARGS% -Didea.debugger.trace="SENDS RECEIVES"

2) set IDEA_JDK envioronmnt variable in the beginning of the file like this
SET IDEA_JDK=C:\java\jdk150_04

3) start IDEA from a command line using the following command:
idea.bat 2> debugTrace

In IDEA launch a debug session - after you quit IDEA the file "debugTrace" will contain all the output that came from the debuggee
VM.

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"


0
Comment actions Permalink

Hi, Eugene.

Thanks - I was able to get the debug trace to work.

Unfortunately, when it reached my first breakpoint, it just hung at the
'Collecting Data...' stage. I gave it 10 minutes before killing it.

I did figure out some other things that might have a bearing on the hangs.

1) When Stepping, if I have 'Suspend All Threads While Stepping' turned on,
then I see the long pause at the 'Collecting Data...' stage for each line I
step to. If I turn off the 'Suspend All Threads', then there is no
appreciable pause in seeing the variables.

2) I see that in version 5, the breakpoints have a new option, 'Suspend
Policy', with options 'All', 'Thread', and 'None'. When placing a
breakpoint with a left mouse click, this option is set to 'All' by default.
If I change the break point to be 'Thread', then when the debugger reaches
the break point, there is no appreciable lag in seeing the variables.

So - seems to be 'suspend all thread' related.

For our particular app, IntelliJ shows, when I do get to a break point, 39
threads running including "main".

(Note that when I tried the debug trace with the break point Suspend Policy
set to 'Thread', it hung also... For both tests, the 'Suspend All Threads
While Stepping' option was NOT selected.)

I've attached the two debug trace files just in case there is anything you
are able to glean from them. suspendall.zip is the trace when the
breakpoint suspend policy was set to 'All'. suspendthread.zip is (you
guessed it) the trace when the breakpoint was set to 'Thread'. Both are for
the same test, same breakpoint, the only difference being the suspend
policy.

Note that although the Break Points in 4.5.4 (build 2253) didn't have this
new option, the 'Suspend All Threads While Stepping' was available, and in
4.5.4, there is no pause while stepping, regardless of whether that option
is selected or not. (Same project, same test, same point in the code for
the breakpoint...)

I hope some of this will help track down just what's happening here...

Thanks!

Bob.

"Eugene Zhuravlev (JetBrains)" <jeka@intellij.com> wrote in message
news:db5k3c$9n2$1@is.intellij.net...

Hello Bob,

>

Indeed, this does not work because this is JDI log, and it goes directly
to the stderr. Sorry for incorrect instructions...
I've found much simplier way to get a log:

>

You will need to modify "idea.bat" file like this:
1) replace string
SET JVM_ARGS=%ACC% %REQUIRED_IDEA_JVM_ARGS%
with the string
SET JVM_ARGS=%ACC% %REQUIRED_IDEA_JVM_ARGS% -Didea.debugger.trace="SENDS
RECEIVES"

>

2) set IDEA_JDK envioronmnt variable in the beginning of the file like
this
SET IDEA_JDK=C:\java\jdk150_04

>

3) start IDEA from a command line using the following command:
idea.bat 2> debugTrace

>

In IDEA launch a debug session - after you quit IDEA the file "debugTrace"
will contain all the output that came from the debuggee
VM.

>

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

>







Attachment(s):
suspendthread.zip
suspendall.zip
0
Comment actions Permalink

Thanks for the traces Bob,

Looking at the traces and then at the source code of JDI... It seems like in JDK 1.5 they have changed the way, the classes are
requested: now when caching all classes loaded in VM it requests more data (due to generic signatures that appeared in 1.5).
One guess - please try to run IDEA itself on JDK 1.4.2_08 - seems like pauses won't last too long. Is it so?

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"


0
Comment actions Permalink

Hi, Eugene.

I THINK I got it started using 1.4.2_08 - when I do a 'Help' 'About', it
shows the JDK as 1.4.2_08 in that list of stuff on the left of the about
dialog. I did it by changing the idea.bat file to have the following
contentright at the top of the bat file, and then running idea.bat to start
up IDEA:

@echo off
::----


:: IntelliJ IDEA Startup Script
::----



:: -


:: Before you run IntelliJ IDEA specify the location of the
:: JDK 1.5 or higher installation directory which will be used for running
IDEA
:: -


SET IDEA_JDK=c:\j2sdk1.4.2_08
IF "%IDEA_JDK%" == "" goto error

Anyways - it makes no difference - the pause is the same on first and
subsequent break points, running the same test, using either 1.4.2_08 or 1.5
with break point suspend policy set to 'all'. When set to 'thread', there
is no pause when it hits the break point before showing the data...

Is there something else I should be doing to run IDEA itself on JDK
1.4.2_08?

Thanks,

Bob.

"Eugene Zhuravlev (JetBrains)" <jeka@intellij.com> wrote in message
news:db8paq$lg3$1@is.intellij.net...

Thanks for the traces Bob,

>

Looking at the traces and then at the source code of JDI... It seems like
in JDK 1.5 they have changed the way, the classes are requested: now when
caching all classes loaded in VM it requests more data (due to generic
signatures that appeared in 1.5).
One guess - please try to run IDEA itself on JDK 1.4.2_08 - seems like
pauses won't last too long. Is it so?

>

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"



0
Comment actions Permalink

Some more thoughts:

1) In IDEA 4.5.4, were there alternative collecttion views and 'show toString()' turned on or off?
What if turn these options off in IDEA 5.0 (see Settings | Debugger | "enable toString() object view" and "Alternate view for
collection classes")?

2) Is it possible to run the debugged application with jdk 1.4.2? Does it make difference?

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"



0
Comment actions Permalink

Hi, Eugene.

Comments below...

Bob.


"Eugene Zhuravlev (JetBrains)" <jeka@intellij.com> wrote in message
news:db956q$3jt$1@is.intellij.net...

Some more thoughts:

>

1) In IDEA 4.5.4, were there alternative collecttion views and 'show
toString()' turned on or off?


I don't see such an option anywhere in the 4.5.4 Debugger IDE Settings
dialog. I thought this was new in 5? If it's somewhere in 4.5.4, please
direct me to that setting, and I'll try it...

What if turn these options off in IDEA 5.0 (see Settings | Debugger |
"enable toString() object view" and "Alternate view for collection
classes")?


I have no 'Alternate View for collection classes' set up. I did a bunch of
things to the debugger settings, as well as trying running IDEA using
1.5.0_04 (as opposed to the bundled 1.5.0_03) and 1.4.2_08 - no appreciable
difference. For kicks, here's what I tried:

1) 'regular' debugger settings:
Hide debug window on process termination - no
Value tooltips delay - 700
Reload classes after compilation - ask
Force Classic VM for jdk 1.3.x and earlier - yes
Debugger transport: - Socket
Sort alphabetically - no
Show static fields - no
Array start index - 0
end index - 100
Autoscroll to new local variables - yes
Show static final fields - disabled.
Show maximum 100 array elements
Alternate view for collections classes - yes
show synthetic fields - yes
hide null array elements - yes
enable toString()' for object view - yes, with 'For all classes that
override 'toString()' method' selected.
Skip synthetic methods - yes
Skip constructors - no
Skip simple getters - no
Do not step into the classes - yes
class list: com.sun., java., javax., org.omg., sun., junit.
Type Renderers - none.

I ran my test the same way each time - just a unit test, but makes calls
into our server code. Everything running locally on my machine (unit test,
IDEA, Server (running JBoss), and MS SQL database). I had three breakpoints
set - one at the top of the unit test method, and two more scattered through
the body of the method. The breakpoints were set to Suspend: all

I then reran the test, disabling one option at a time for each test. I.E.
each test used the above config, with a single setting different. Each ran
substantially the same timings (within 3 seconds for each value):

enable toString()' for object view
Alternate view for collections classes
Force Classic VM for jdk 1.3.x and earlier
show synthetic fields
hide null array elements
Do not step into the classes
Array start - end index 0-20, show 21 elements

I also ran a test with both the 'toString()' and the 'alt view' disabled.
No change.

Timings (with a stop watch) were (with 'Collecting data...' showing):
first break point 28-33 seconds
second break point 23 seconds
third break point 22-25 seconds

>

2) Is it possible to run the debugged application with jdk 1.4.2? Does it
make difference?


I'm not sure what you are asking here. I have run IntelliJ 5 with jdk
1.4.2, and it makes no difference. Our app is now making use of 1.5
features, so I can't make the app with 1.4.2. Give me a bit more info here
for what you are asking me to do, and I'll try it...

>

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"



0
Comment actions Permalink

Hello Bob,

>> 1) In IDEA 4.5.4, were there alternative collecttion views and 'show toString()' turned on or off?
>

I don't see such an option anywhere in the 4.5.4 Debugger IDE Settings dialog. I thought this was new in 5? If it's somewhere in
4.5.4, please direct me to that setting, and I'll try it...

>

Right click inside a Frame View and choose "Customize view", there will be a setting whether to show objects as toString()

When I asked to run the debugged application on jdk 1.4, the intention was to check whether more data is transferred in theis case
over the network from the debuggee to IDEA. Examining the JDI internals makes me think that they transfer more data. Also I'm trying
to ensure that comparison between 2 IDEA versions was done with similar set of options turned on/off and within similar runtime
environments. If we notice the difference it may point us to the right direction in our investigation whether it is IDEA who makes a
lot of "expensive" calls to JDI, or some JDI calls have become "expensive" in jdk 1.5....


--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"


0
Comment actions Permalink

Hi, Eugene.

I didn't know about the customize view! That's cool. Maybe I should read
the documentation sometime :)

Anyways - I tried a number of different options in the Customize Frame View,
and none of them caused any delay in displaying the Frame window when a
break point was encountered, nor when stepping, with 'suspend all threads'
selected. I've tried with "Types to be shown as 'toString'" set to All, and
to Custom, with and without "Show object ID and type when in 'toString()'
mode", with and without "Alternate view for Collections classes", as well as
trying some others. About the only thing I DO notice is that although the
base variables show immediately, you can watch the 'toString' values sort of
ripple down the Frame view over about 1/2 a second or so depending on how
many variables are shown. But - that doesn't slow down the stepping that
can be done. (Each variable shows 'Collecting Data...' beside it until IDEA
displays the toString data.

I'll play with the 1.4 version of the JDK. I think I can check out from
about 4 weeks ago before we started with the 1.5 features, and test with
that. But that will take me a bit longer to set up. I'll send another post
when I have results from that.

Thanks!

Bob.

"Eugene Zhuravlev (JetBrains)" <jeka@intellij.com> wrote in message
news:dbilnc$8ek$1@is.intellij.net...

Hello Bob,

>
>>> 1) In IDEA 4.5.4, were there alternative collecttion views and 'show
>>> toString()' turned on or off?
>>
>> I don't see such an option anywhere in the 4.5.4 Debugger IDE Settings
>> dialog. I thought this was new in 5? If it's somewhere in 4.5.4, please
>> direct me to that setting, and I'll try it...
>>
>

Right click inside a Frame View and choose "Customize view", there will be
a setting whether to show objects as toString()

>

When I asked to run the debugged application on jdk 1.4, the intention was
to check whether more data is transferred in theis case over the network
from the debuggee to IDEA. Examining the JDI internals makes me think that
they transfer more data. Also I'm trying to ensure that comparison between
2 IDEA versions was done with similar set of options turned on/off and
within similar runtime environments. If we notice the difference it may
point us to the right direction in our investigation whether it is IDEA
who makes a lot of "expensive" calls to JDI, or some JDI calls have become
"expensive" in jdk 1.5....

>
>

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"



0
Comment actions Permalink

Hi, Eugene.

OK, I checked out a version of our code from a month or so ago. Reset my
environment variables to reference jdk 1.4.2_08 and jre 1.4.2_08, and
rebuilt the entire project. When starting JBoss, the output confirmed it
was using 1.4.2_08. Ran IDEA 4.5.4 build 2253 (which used JDK 1.4.2_04
according the help, about). No pauses when debugging.

Ran the same test with the same project and Java settings, with IDEA 5.0
build 3415 (using JDK 1.4.2_08 according to the help, about). Debugger
still pauses 30 seconds on first break point, about 23 seconds on each
subsequent.

I tried changing the idea.lax to reference jdk1.5.0_04, but it errors on
startup indicating "The JDK version is 1.5.0_04 IDEA requires JDK 1.4.2_04".
So I've been unable to test IDEA 4.5.4 using JDK 1.5.0.

So - to summarize what has been discovered so far:

1) The pausing in IDEA 5.0 seems to be independent of JDK and JRE version -
IDEA 5.0 displays pause behaviour for 1.4.2 and 1.5, IDEA 4.5.4 does not
display the pause behaviour. Pause is approx 30 seconds for first break
point, about 23 seconds for each subsequent break point.

2) Seems to be independent of Frame display options - IDEA 5.0 displays
pause behaviour no matter what options I've tried, including "Enable
'toString()' object view" and "Alternate view for Collections classes".
IDEA 4.5.4 does not display the pause behavious, no matter what options I've
tried in the Frame view.

3) Seems to be related to 'suspend threads' in 5.0. When I alter the break
point to just suspend the thread rather than suspend all, then hitting a
breakpoint doesn't pause. When I step with "Suspend all threads while
stepping", IDEA 5.0 pauses, when I don't have "Suspend all threads while
stepping", IDEA 5.0 doesn't pause. IDEA 4.5.4 doesn't pause in either case.

One other possible clue - I've heard from colleagues developing the same
project and using IDEA 5.0 on Linux that they do not have this problem.
But, since they are at other locations, I can't confirm their setups...
So - it MAY be a Windows only problem. I'm running Windows XP SP 2 on a
XEON processor. (Just for kicks, I disabled the hyperthreading on the Xeon,
but it didn't make any difference...)

If there's anything else I can supply for you on this, let me know and I'll
see what I can do...

Thanks!

Bob.

"Eugene Zhuravlev (JetBrains)" <jeka@intellij.com> wrote in message
news:dbilnc$8ek$1@is.intellij.net...

Hello Bob,



When I asked to run the debugged application on jdk 1.4, the intention was
to check whether more data is transferred in theis case over the network
from the debuggee to IDEA. Examining the JDI internals makes me think that
they transfer more data. Also I'm trying to ensure that comparison between
2 IDEA versions was done with similar set of options turned on/off and
within similar runtime environments. If we notice the difference it may
point us to the right direction in our investigation whether it is IDEA
who makes a lot of "expensive" calls to JDI, or some JDI calls have become
"expensive" in jdk 1.5....

>
>

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"

>



0
Comment actions Permalink

Hello Bob,

Seems like finally I have found the reason thanks to your very detailed descriptions. It is indeed a threading issue. More
specifically: the more threads are running in your application and the larger stacks they have, the more slow was debugger rendering
stack data - just because of one JDI call that turned out to be quite expensive. This is especially noticible when debugging
application servers with lots of threads running,. Now the debugger works much snappier.
I wish every our customer provided such detailed feedback like you did, thanks a lot for this and I hope you'll enjoy faster
debugger!

--
Best regards,
Eugene Zhuravlev
Software Developer
JetBrains Inc.
http://www.jetbrains.com
"Develop with pleasure!"


0
Comment actions Permalink

woohoo, Bob, thanks ;)
now lets wait for new build, this bug was major pita for me..
-m.j.m

0
Comment actions Permalink

Eugene Zhuravlev (JetBrains) wrote:

application servers with lots of threads running,. Now the debugger works much snappier.
I wish every our customer provided such detailed feedback like you did, thanks a lot for this and I hope you'll enjoy faster
debugger!


Excellent - did this fix make it into #3417 or the next build? Just
installing #3417 now and will look forward to debugging again...

0
Comment actions Permalink

running 3417 right now, and haven't seen "collecting data" yet ;)

0

Please sign in to leave a comment.