Community
Participate
Working Groups
Created attachment 144812 [details] Multiple thread dumps while waiting to see the contents of the variables Using I20090811-0800. I'm debugging some code and it takes sometimes several minutes before the variables contents are refreshed in the Variables view. My machine is a Thinkpad T60p with 3Go of RAM and I've closed all other running applications on it except Eclipse (launched with -Xmx380Mo). The VM indicator shows that 73Mo of mem consumed with a max currently set to 173Mo (so far from any OOME)... I've taken multiple threads dump and it seems that the time is consumed to read and compile tons of unit (see attached file). Is it really necessary to read all these files to see the contents of the variables? I do not remember such a problem in 3.5, is there any recent change around this area?
Set as critical because, debug operation becomes unusable with this problem...
Nothing has really changed here since 3.5. It looks like you might have a watch expression (in the Expressions view) that is taking some time to evaluate. If that is the case, it could be the evaluations are serialized and the slow watch expression is getting in your way?
That's correct. I have watch expressions in the Expressions view and removing them fixes the problem, hence reduce the severity. However, I do have these expressions for a long time in my workspace and often debugging with them. I do not remember such a timing issue. Isn't there anything to do to speed-up the refresh? I like to have expression in this view to avoid to change the variable selection to see their contents...
Evaluations must be serialized on the suspended thread (we resume the thread to perform the evaluation on the VM...). So we must wait for each evaluation to complete before performing the next. What sort of evaluation is it? Is it expected to be long running?
(And we can't see variables while a thread is executing...). Ordering/prioritizing requests between the views is tricky (since each view is independent of the others).
(In reply to comment #4) > Evaluations must be serialized on the suspended thread (we resume the thread to > perform the evaluation on the VM...). So we must wait for each evaluation to > complete before performing the next. What sort of evaluation is it? Is it > expected to be long running? > I would say no. My workspace is about JDT/Core formatter and I had following expressions in my view: + this.column + this.scanner.source + this.scanner + this.scribe.scanner Depending on the breakpoints, one, three or all of these expression are invalid: 1) the last one when the hit breakpoint is in Scribe 2) the third first ones when the hit breakpoint is in CodeFormatterVisitor 3) all ones when the hit breakpoint is elsewhere As I'm usually debugging small test case, the source stored in the scanner is small, hence I would say that its serialization should not last too much...
I'm still really annoyed by this issue. Is there any more information I can provide to help you to reproduce it?
Created attachment 245910 [details] slow-breakpoint-cpu-sampling I've the same problem, attached a JVisualVM snapshot where it takes ~5 seconds to jump to the source line of the breakpoint. Looks like it reading a zip file in thread Worker-4: org.eclipse.debug.internal.ui.sourcelookup.SourceLookupFacility$SourceLookupJob.run() 5.199 ms which seems to send the most time in I think reading the JDK src.zip (I removed all other sources from the build path). I've about 10 jre/jdks installed (last of JDK 6/7/8 in 32 and 64 bit versions). The problem occurs running a simple unit test with Java 7/8 with a breakpoint in a large project. It occurs as mention the first time a breakpoint is hit after launch in debug mode. Using Eclipse IDE for Java Developers Version: Luna Release (4.4.0) Build id: 20140612-0600
Sorry, meant to add my previous comment/attachment to https://bugs.eclipse.org/bugs/show_bug.cgi?id=365394 (although this bug is similar)
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
I haven't seen the issue in the version I've used in the last year or so: Eclipse IDE for Java Developers Version: Photon Release (4.8.0) Build id: 20180619-1200 I'm fine with closing this issue.
Thanks for confirming.
