This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 156184 - Inspect hierarchy causes infinite loop and memory leak; forced to kill the IDE
Summary: Inspect hierarchy causes infinite loop and memory leak; forced to kill the IDE
Status: RESOLVED FIXED
Alias: None
Product: java
Classification: Unclassified
Component: Navigation (show other bugs)
Version: 6.x
Hardware: All All
: P3 blocker with 1 vote (vote)
Assignee: Tomas Zezula
URL:
Keywords: PERFORMANCE
Depends on:
Blocks:
 
Reported: 2008-12-31 06:30 UTC by _ wadechandler
Modified: 2012-10-29 16:53 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Java file I was playing with when the issue started happening. (1.85 KB, text/plain)
2008-12-31 06:33 UTC, _ wadechandler
Details
form file for the .java file (1.58 KB, text/plain)
2008-12-31 06:33 UTC, _ wadechandler
Details
The thread dump I created from NB (28.56 KB, text/plain)
2008-12-31 06:34 UTC, _ wadechandler
Details
last log file from NB afterI killed the process (79.66 KB, text/plain)
2008-12-31 06:35 UTC, _ wadechandler
Details

Note You need to log in before you can comment on or make changes to this bug.
Description _ wadechandler 2008-12-31 06:30:12 UTC
I was checking out the hierarchy functionality in Java files. I ran into an issue which consistently caused infinite
loops etc. I have a thread dump and some example code. Too, in this code when I click on the add method it tries to show
me the hierarchy for Component at different times. It showed me that a couple times, then started always locking the IDE
and forcing me to close the IDE with the windows task manager. Seems if I right click on add and choose to navigate and
inspect the hierarchy the dialog that pops up should tell me which in the hierarchy of the JFrame extension all the way
back to Container implements or overrides this method such as the way Eclipse works. I'll post the example code and
thread dump after I post the issue.
Comment 1 _ wadechandler 2008-12-31 06:33:23 UTC
Created attachment 75373 [details]
Java file I was playing with when the issue started happening.
Comment 2 _ wadechandler 2008-12-31 06:33:56 UTC
Created attachment 75374 [details]
form file for the .java file
Comment 3 _ wadechandler 2008-12-31 06:34:47 UTC
Created attachment 75375 [details]
The thread dump I created from NB
Comment 4 _ wadechandler 2008-12-31 06:35:49 UTC
Created attachment 75376 [details]
last log file from NB afterI killed the process
Comment 5 Jiri Prox 2009-01-03 10:52:30 UTC
I've tried this and the IDE was not blocked, but it takes quite a long time to compute the hierarchy tree (about 30s).
According to the threaddump it is also your case. Can you please verify it? 

The second part of this issue is rather an enhancement. Inspect hierarchy (alt-shift-f12) now only get the type under
caret and show hierarchy tree for it. It does not respect finer elements such as methods. Anyway thanks for an idea for
enhancing this feature.
Comment 6 _ wadechandler 2009-01-03 21:02:00 UTC
OK. Further testing shows that I can create the scenario you had in most circumstances. I can open the application with
this test file in it and get that result; takes about 30 seconds. However, I can then open ireport or some other sets of
NB module projects from the NB sources along with this project, right click on the UI forms overridden add method, and
the hierarchy view never shows, the CPU usage keeps growing, it hadn't returned after 10 or so minutes or more, the IDE
is locked up, and memory usage is over 400MB. Basically:

1) I started a new IDE session.
2) I opened this test project with the attached test UI file.
3) I can consistently make it take roughly 30 seconds to complete the hierarchy view. This is apparently only on the
"subtype hierarchy" as well. You can click on the other buttons and it shows pretty fast. Click on the subtype button
and it takes a while. Flip back and forth between super and sub type hierarchies to make the issue show.
4) I then opened some NB RCP projects, tried to view the hierarchy, and the issue kicks up. This happens with iReport or
NB sources. Surely others.

The funny thing is that I thought maybe some things would be related to scanning. So, I specifically tried it with the
form module opened while scanning and it finished in a couple minutes. When it was done scanning I tried again, and it
didn't finish, at least not within any close to usable amount of time, though 30 seconds isn't very usable either. I
thought perhaps too it was related to the number of and sizes of libraries used, so I opened up a couple web projects
and added every single library to them from the IDE. I could perform the action in 30 seconds or roughly 30
seconds...maybe it took a little longer. The worse problem occurs when RCP project are opened for some reason. 

Either way though, I'm not sure why that activity takes so long. Well, I suppose if running a subtype query on a class
can be difficult, but still much less CPU usage such as sleeping the thread for some nanos or millis or yielding can be
helpful. Seems this must not be happening, or if it is not long enough as the disk is being accessed very fast, but as
the CPU usage is so high I expect it to be related to threading issues as well. Too, if it is done on the UI thread that
is bad; I haven't dug into the sources to see all the details, but can only guess what it is doing. I know when I ran
the action when scanning was running that the scanning progress bar never updated until finished or at least until the
dialog appears at which time more work is needed, so I assume some expensive work is being done on the ET. 

Too, aside from blocking the UI it seems while searching pieces of the UI or Node tree can be updated so the user gets
some pieces of information as the search takes place. Also, some kind of a status bar versus just a node to indicate
something is happening might be better. That way the tree can be updated, node children, as things are found until the
query is over.

It seems maybe the cache isn't being used to find out the sub types. Perhaps that could be changed and this action could
be much faster. After scanning it looks like this should be possible. If not possible now, maybe this needs to be sure
and make its way into the new parsing API so super type information is stored for all classes as well so that sub types
can be found in milli seconds to a very few seconds with database query type speeds.
Comment 7 ericjs 2010-02-11 19:29:20 UTC
See also: Bug 169908
Comment 8 Tomas Zezula 2012-10-29 16:53:17 UTC
Fixed jet-main eeef442a248e
The hierarchy view was completely rewritten in NB 7.3 targeting both the new UI spec and performance.