Bug 411359

Summary: Javadoc hover may eat up lots of CPU resources
Product: [Eclipse Project] JDT Reporter: Andreas Rudolph <Andreas.Rudolph>
Component: CoreAssignee: JDT-Core-Inbox <jdt-core-inbox>
Status: CLOSED WONTFIX QA Contact:
Severity: normal    
Priority: P3 CC: daniel_megert, jarthana, markus.kell.r
Version: 3.8.2Keywords: needinfo
Target Milestone: ---   
Hardware: PC   
OS: Mac OS X   
Whiteboard: stalebug
Attachments:
Description Flags
Thread dump of frozen Eclipse instance (created via JVisualVM)
none
JVisualVM Sampler Screenshot
none
Stack trace of "Text Viewer Hover Presenter" thread none

Description Andreas Rudolph CLA 2013-06-21 08:24:32 EDT
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).
Comment 1 Dani Megert CLA 2013-06-21 08:32:39 EDT
> 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?
Comment 2 Andreas Rudolph CLA 2013-06-21 08:46:33 EDT
(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 ;-))
Comment 3 Dani Megert CLA 2013-06-21 08:51:17 EDT
(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.
Comment 4 Andreas Rudolph CLA 2013-06-21 08:57:42 EDT
(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 ('⌘').
Comment 5 Markus Keller CLA 2013-06-21 13:27:26 EDT
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.
Comment 6 Andreas Rudolph CLA 2013-06-24 04:23:44 EDT
(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.
Comment 7 Andreas Rudolph CLA 2013-06-24 04:51:01 EDT
Created attachment 232689 [details]
JVisualVM Sampler Screenshot

Apparently its the "Text Viewer Hover Presenter" thread that required much CPU time.
Comment 8 Andreas Rudolph CLA 2013-06-24 04:53:06 EDT
Created attachment 232690 [details]
Stack trace of "Text Viewer Hover Presenter" thread
Comment 9 Andreas Rudolph CLA 2013-06-24 04:54:29 EDT
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.
Comment 10 Jay Arthanareeswaran CLA 2013-06-24 05:36:31 EDT
(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.
Comment 11 Eclipse Genie CLA 2020-02-20 14:06:21 EST
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.