Community
Participate
Working Groups
Created attachment 232637 [details] Thread dump of frozen Eclipse instance (created via JVisualVM) ======== Overview ======== When hovering in a local class its JavaDoc comment (several times) over a JavaDoc link tag that references an enumeration constant (of an enum class in same project but different package) then Eclipse starts to gain more and more CPU resources. Eventually (after running a minute) Eclipse its UI will freeze (hourglass mouse cursor displayed; input not processed / no GUI feedback). ================== Steps to reproduce ================== 0. Start your favorite tool to observe CPU load / utilization. 1. Create a Java project in Eclipse. 2. Enter the following packages and classes: + package edu.hover.enumeration; /** * This is {@link Enumeration}. * @author a1 */ public enum Enumeration { /** * Enum constant #1. */ EC1, /** * Enum constant #2. */ EC2, } + package edu.hover.ref; public abstract class Base extends JPanel { abstract void f(Object a, Object b); } + package edu.hover.ref; import java.util.Collection; import java.util.Set; import edu.hover.enumeration.Enumeration; public class Reference extends Base { private boolean other(Object c) { return false; } @Override void f(Object a, Object b) { /** * Utilizes {@link Enumeration}s. May call {@link Reference#other()}. * @author a2 * @see JPanel#getBounds() */ class Local { private final Set<Enumeration> c; /** * Construction. * @param c * @throws NullPointerException */ Local(Collection<Enumeration> c) { this.c = c.isEmpty() ? EnumSet.noneOf(Enumeration.class) : EnumSet.copyOf(c); } /** * Uses {@link Enumeration#EC1}. */ Local() { this(EnumSet.of(Enumeration.EC1); } } } } 3. Hover over a JavaDoc comment in package edu.hover.ref.Reference.f.Local (probably several times). See how eclipse demands more and more CPU resources. 4. Observe that Eclipse freezes. ============== Actual results ============== Excessive CPU load (50% of the cores for almost 100%), freeze. ================ Expected results ================ Reasonable CPU load, terminating hover processing, eventually showing a hover. ===================== Build date & platform ===================== Eclipse SDK, Version: 4.2.2, Build id: M20130204-1200 ====================== Additional Information ====================== Created a thread dump of Eclipse instance via JVisualVM (see attachement).
> 4. Observe that Eclipse freezes. For how long? The hover computation runs in the background, so this has no effect on any UI freeze. The main thread indicates that the hyperlink manager was active. Did you hit the 'Ctrl' key why moving the mouse, or change the preference to show the hyperlinks even without pressing the 'Ctrl' key?
(In reply to comment #1) > > 4. Observe that Eclipse freezes. > > For how long? As long as I was patient, say 5 minutes. Then I killed Eclipse for restart. > The hover computation runs in the background, so this has no > effect on any UI freeze. The main thread indicates that the hyperlink > manager was active. Did you hit the 'Ctrl' key why moving the mouse, or > change the preference to show the hyperlinks even without pressing the > 'Ctrl' key? The JavaDoc hover with my configuration appears (normally) by just moving the mouse cursor over an element without additional keyboard input required (as tool-tips usually (should) do ;-))
(In reply to comment #2) > > The hover computation runs in the background, so this has no > > effect on any UI freeze. The main thread indicates that the hyperlink > > manager was active. Did you hit the 'Ctrl' key why moving the mouse, or > > change the preference to show the hyperlinks even without pressing the > > 'Ctrl' key? > The JavaDoc hover with my configuration appears (normally) by just moving > the mouse cursor over an element without additional keyboard input required > (as tool-tips usually (should) do ;-)) I talked about *hyperlinks*. The main thread is working on that and not on hovers/tool tips as you can see in the stack trace. So, can you please try to answer my question? Moving to JDT Core as it seems to "hang" in #codeSelect.
(In reply to comment #3) > (In reply to comment #2) > > > The hover computation runs in the background, so this has no > > > effect on any UI freeze. The main thread indicates that the hyperlink > > > manager was active. Did you hit the 'Ctrl' key why moving the mouse, or > > > change the preference to show the hyperlinks even without pressing the > > > 'Ctrl' key? > > The JavaDoc hover with my configuration appears (normally) by just moving > > the mouse cursor over an element without additional keyboard input required > > (as tool-tips usually (should) do ;-)) > > I talked about *hyperlinks*. The main thread is working on that and not on > hovers/tool tips as you can see in the stack trace. So, can you please try > to answer my question? > > > Moving to JDT Core as it seems to "hang" in #codeSelect. I did not operate the keyboard at all while moving the mouse, so no 'Ctrl' key hit, too. Hyperlinks are visualized with modifier required. By the way on my configuration (MacOS X), it's the cmd-Key ('⌘').
Note that if you just leave out the "+" in front of the package declarations, then we can just copy the whole source and paste it into the Package Explorer. > 3. Hover over a JavaDoc comment in package edu.hover.ref.Reference.f.Local > (probably several times). See how eclipse demands more and more CPU resources. "edu.hover.ref.Reference.f.Local" is not a package. It's a local class with a syntax error. Also note that some imports are missing. Is that intended? Where exactly do you hover? I can't reproduce any slowness.
(In reply to comment #5) > "edu.hover.ref.Reference.f.Local" is not a package. It's a local class with > a syntax error. Also note that some imports are missing. Is that intended? No the syntax errors were not intended. Calling Local a package is a typo, sorry. > Where exactly do you hover? I can't reproduce any slowness. Actually the problem has been observed with other sources. I tried to mimic the situation with the "test case" that is supplied. But I must admit that I did not exercise the test classes; it's written from scratch. In fact the problem is not reproducible with the test case that I have supplied. However with the other sources (which I cannot post here), I can certainly reproduce the problem, still.
Created attachment 232689 [details] JVisualVM Sampler Screenshot Apparently its the "Text Viewer Hover Presenter" thread that required much CPU time.
Created attachment 232690 [details] Stack trace of "Text Viewer Hover Presenter" thread
Comment on attachment 232690 [details] Stack trace of "Text Viewer Hover Presenter" thread Repeated stack traces show always AbstractCommentParser.java:385 as the top of the trace.
(In reply to comment #9) > Comment on attachment 232690 [details] > Stack trace of "Text Viewer Hover Presenter" thread > > Repeated stack traces show always AbstractCommentParser.java:385 as the top > of the trace. Thanks for that! The AbstractCommentParser#commentParse is a fairly large method and it would be difficult to pin point a bottle neck just looking at the code. Hope you can isolate a reproducible test case.
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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.
