Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 183201 - Sampling of CC does not end, NB uses 100% of CPU
Sampling of CC does not end, NB uses 100% of CPU
Status: CLOSED FIXED
Product: ide
Classification: Unclassified
Component: Performance
3.x
PC Linux
: P1 (vote)
: TBD
Assigned To: Jaroslav Tulach
issues@performance
: PERFORMANCE
: 183237 183482 183621 183821 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-03-30 14:58 UTC by Tomas Mysik
Modified: 2011-05-25 11:40 UTC (History)
13 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
IDE log (148.53 KB, text/x-vhdl)
2010-03-30 14:58 UTC, Tomas Mysik
Details
snapshot 1 (3.91 KB, application/octet-stream)
2010-03-30 14:58 UTC, Tomas Mysik
Details
snapshot 2 (11.52 KB, application/octet-stream)
2010-03-30 14:58 UTC, Tomas Mysik
Details
Snapshot of NetBeans hogging CPU, suspect CC Sampling again? (204.56 KB, application/octet-stream)
2010-04-07 14:45 UTC, tnleeuw
Details
snapshot (3.36 KB, application/octet-stream)
2010-04-11 18:19 UTC, Tomas Mysik
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tomas Mysik 2010-03-30 14:58:04 UTC
Created attachment 96357 [details]
IDE log

NB started to use 100% of my CPU and it never ended, in a snapshot one can see that there are several loggers for CC that never end.

I'm going to attach 2 snapshots, I also have a heap dump if needed.

Product Version: NetBeans IDE Dev (Build 100330-8b0b096d59ba)
Java: 1.6.0_16; Java HotSpot(TM) 64-Bit Server VM 14.2-b01
System: Linux version 2.6.31-20-generic running on amd64; UTF-8; cs_CZ (nb)
Comment 1 Tomas Mysik 2010-03-30 14:58:27 UTC
Created attachment 96358 [details]
snapshot 1
Comment 2 Tomas Mysik 2010-03-30 14:58:46 UTC
Created attachment 96359 [details]
snapshot 2
Comment 3 Tomas Pavek 2010-03-31 13:06:21 UTC
*** Bug 183237 has been marked as a duplicate of this bug. ***
Comment 4 Tomas Mysik 2010-04-02 07:57:02 UTC
Jardo, please have a look at this issue, it is extremely annoying to restart the IDE (with all the NB modules loaded) several times a day.... Thanks a lot.
Comment 5 Jaroslav Tulach 2010-04-05 17:16:42 UTC
null
Comment 6 Jaroslav Tulach 2010-04-05 17:19:54 UTC
changeset   : 166215:234c4f0d6291
author      : Jaroslav Tulach <jtulach@netbeans.org>
date        : Mon Apr 05 19:16:22 CEST 2010
summary     : #183201: At most one CC profiling shall be in progress
Comment 7 Quality Engineering 2010-04-06 04:25:57 UTC
Integrated into 'main-golden', will be available in build *201004060201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/234c4f0d6291
User: Jaroslav Tulach <jtulach@netbeans.org>
Log: #183201: At most one CC profiling shall be in progress
Comment 8 Tomas Mysik 2010-04-07 07:36:32 UTC
Jardo, are you sure that the fix is correct? Cannot happen that one profiling thread will be running forever?
Comment 9 Peter Pis 2010-04-07 08:17:34 UTC
*** Bug 183621 has been marked as a duplicate of this bug. ***
Comment 10 tnleeuw 2010-04-07 14:45:46 UTC
Created attachment 96862 [details]
Snapshot of NetBeans hogging CPU, suspect CC Sampling again?

NetBeans nightly 201004070201 still slows down tremendously, hogging all CPU. I don't know if it's the same cause, but if I interpret the data correctly, a lot of time is still taken up by logger-completion threads, like in previous snapshots I uploaded to a defect marked as duplicate of this one -- which is why I'm uploading the new snapshot here.

Almost all time seems to go into java.lang.ProcessImpl.waitFor()?
Comment 11 tnleeuw 2010-04-07 15:14:16 UTC
As an additional comment, I didn't really notice any slowdowns when I was just copy-pasting most changes, using alt-/ for variable name completions.

Only when I started to make changes that invoked proper code-completion, triggering it myself manually a couple of times, NetBeans started to slow down.

So I do suspect code completion is still involved.

I'm however not sure that it's exactly the same problem as the original problem report so I'm hesitant to re-open the defect myself.
Comment 12 Jaroslav Tulach 2010-04-07 16:53:38 UTC
Tomáši, after the http://hg.netbeans.org/main/rev/234c4f0d6291, there is a singleton profiler for completion. But still the snapshot shows three logger-completion threads running. Is not somethign broken in the SelfProfileAction itself?
Comment 13 Tomas Hurka 2010-04-07 18:34:44 UTC
I do not see nothing wrong in SelfProfileAction and there were no changes in that area for some time and it looks like this issue appears in recent builds.
Comment 14 Tomas Mysik 2010-04-07 19:20:15 UTC
I did not have this problem in the build from today (at least I did not notice), however, as I wrote in comment #8:

> Jardo, are you sure that the fix is correct? Cannot happen that one profiling
> thread will be running forever?

I think that the problem is that the profiling thread is not ended correctly, so lowering their number to one is great improvement but probably not the best fix :) Or am I missing something?
Comment 15 Jaroslav Tulach 2010-04-07 21:57:02 UTC
> Or am I missing something?

The reality is somehow being missed. Nobody knows why there are multiple threads doing the profiling. Code inspection does not seem to help.
Comment 16 Peter Pis 2010-04-08 08:28:31 UTC
So is it ok to have this issue marked as FIXED?
Comment 17 tnleeuw 2010-04-08 08:45:06 UTC
Actually, since I still experience this problem, I don't think it can be marked FIXED yet?

Only since I'm not a member of the project, I don't want to reopen it myself, since I can't decide if my problem is different from this defect or still the same cause as the original defect.
Comment 18 Peter Pis 2010-04-10 16:37:07 UTC
*** Bug 183821 has been marked as a duplicate of this bug. ***
Comment 19 Peter Pis 2010-04-10 16:37:36 UTC
Reopening.
Comment 20 Peter Pis 2010-04-10 16:38:34 UTC
*** Bug 183621 has been marked as a duplicate of this bug. ***
Comment 21 Tomas Mysik 2010-04-11 18:19:57 UTC
Created attachment 97034 [details]
snapshot

Is this snapshot OK or not?

Product Version: NetBeans IDE Dev (Build 100409-1a1477cad8d5)
Java: 1.6.0_16; Java HotSpot(TM) 64-Bit Server VM 14.2-b01
System: Linux version 2.6.31-20-generic running on amd64; UTF-8; cs_CZ (nb)
Comment 22 Tomas Mysik 2010-04-11 18:25:01 UTC
(In reply to comment #21)
> Is this snapshot OK or not?

I guess NOT because my IDE uses 100% of my CPU and I need to restart it.
Comment 23 David Strupl 2010-04-13 19:44:34 UTC
Tomas Hurka said in a comment to #183993 that this one is P1 and that what I saw is in fact this problem.

BTW I have a heap dump from today's morning build with OOME if it is useful for anything (I guess not).
Comment 24 Jaroslav Tulach 2010-04-14 08:13:34 UTC
Addressed in bug 183832. For 6.9 beta I suggest to disable this code (it will be disabled for release too):

diff -r c4b4eaaa2f9e editor.completion/src/org/netbeans/modules/editor/completion/CompletionImpl.java
--- a/editor.completion/src/org/netbeans/modules/editor/completion/CompletionImpl.java  Fri Apr 09 10:05:40 2010 +0200
+++ b/editor.completion/src/org/netbeans/modules/editor/completion/CompletionImpl.java  Wed Apr 14 10:13:42 2010 +0200
@@ -1752,7 +1752,7 @@
         if (profiler == null) {
             return;
         }
-        profile = new Profile(profiler, when);
+// disable for beta:        profile = new Profile(profiler, when);
     }

     private static final class Profile implements Runnable {

Tondo, you have the 6.9 beta clone, can you comment the above line in it? Thanks.
Comment 25 Antonin Nebuzelsky 2010-04-14 08:41:58 UTC
Fixed in Beta:

http://hg.netbeans.org/release69_beta/rev/055321af1257
Comment 26 Vitezslav Stejskal 2010-04-14 10:11:25 UTC
[1] somewhat improves the situation, although even with this fix I saw logger-completion not being terminated and running forever (until I killed the IDE). IMO there are exit paths in the CC code that do not call CompletionImpl.stopProfiling().

[1] http://hg.netbeans.org/jet-main/rev/e92a68613f37
Comment 27 Vitezslav Stejskal 2010-04-14 10:22:57 UTC
Since this problem is NOT satisfactorily resolved in trunk I am reopening this report.

I know that after Tonda's fix in release69_beta this is not an issue for 6.9beta builds, but I don't know how to express this state in Bugzilla. However, I DO remember Netbeans releases and practices when looking at a bug report one could have determined where exactly the problem was fixed (eg. in trunk only, in both trunk and the release branch, on the release branch only). Unfortunately we don't seem to care much about such practices anymore.
Comment 28 Antonin Nebuzelsky 2010-04-14 10:33:07 UTC
For the follow-up on trunk reassigning back to Jarda.
Comment 29 Tomas Pavek 2010-04-14 11:25:10 UTC
What about the fix Jarda did in issue 183832? I.e. http://hg.netbeans.org/core-main/rev/0b27d337bc62. Isn't Vita's [1] in conflict with that?

Anyway these two issues look like the same thing now.
Comment 30 Vitezslav Stejskal 2010-04-14 13:14:46 UTC
(In reply to comment #29)
> What about the fix Jarda did in issue 183832? I.e.
> http://hg.netbeans.org/core-main/rev/0b27d337bc62. Isn't Vita's [1] in conflict
> with that?

Yes, it is. After a quick look Jarda's fix looks better though. On top of the changes that I did he also found and fixed some places where stopProfiling() should have been called, but was not. So, whoever happens to be resolving this conflict should probably just choose Jarda's fix and ignore mine, which will hopefully make their life easier.
Comment 31 Jaroslav Tulach 2010-04-14 17:20:13 UTC
conflict resolved in: http://hg.netbeans.org/core-main/rev/af1cde3fc070
Comment 32 Jaroslav Tulach 2010-04-14 17:29:54 UTC
*** Bug 183482 has been marked as a duplicate of this bug. ***
Comment 33 Vitezslav Stejskal 2010-04-16 10:30:44 UTC
(In reply to comment #31)
> conflict resolved in: http://hg.netbeans.org/core-main/rev/af1cde3fc070

thanks
Comment 34 loseyou2him 2010-08-02 16:38:30 UTC
This still bogs my install down considerably.  In instances where the number of files is very large on PHP prodjects, such as with Magento, the IDE becomes nearly unusable because these checks are triggered on what seems to be nearly every change I make.  The only fix is to turn off the checking altogether.

Here are some thoughts/suggestions.
1) Why are we re-checking the whole project when changes are made in one place.  Would a more tiered approach to caching help here (ie only check based on a more limited criteria)?
2) Can we do something to thread this and throttle it's CPU usage?
3) Can we add a setting that would limit the number of re-scans per specified time period (ie only scan 10 times per hour).

I know this is not an easy task as dealing with a large number of files is no simple thing.  However, the 100% CPU usage and downtime is really annoying.  Thanks for looking into this.
Comment 35 Tomas Hurka 2010-08-04 04:57:35 UTC
(In reply to comment #34)
> This still bogs my install down considerably.  In instances where the number of
> files is very large on PHP prodjects, such as with Magento, the IDE becomes
> nearly unusable because these checks are triggered on what seems to be nearly
> every change I make.  The only fix is to turn off the checking altogether.
> 
> Here are some thoughts/suggestions.
> 1) Why are we re-checking the whole project when changes are made in one place.
>  Would a more tiered approach to caching help here (ie only check based on a
> more limited criteria)?
> 2) Can we do something to thread this and throttle it's CPU usage?
> 3) Can we add a setting that would limit the number of re-scans per specified
> time period (ie only scan 10 times per hour).
> 
> I know this is not an easy task as dealing with a large number of files is no
> simple thing.  However, the 100% CPU usage and downtime is really annoying. 
> Thanks for looking into this.

This is different issue. Please file a separate one. Thanks.
Comment 36 mikato 2010-12-08 21:41:33 UTC
Wow, I built my new work comp with a Core i7-950, 8GB memory, and an SSD and this is the first I've noticed any type of slowness on it!  It is halting and not allowing cursor movement, scrolling etc. for several seconds delay.  Meanwhile other programs are fine.  I notice javaw.exe is using up to 16% CPU during this and almost 700Mb of memory (netbeans is just 1,104K).  I haven't noticed this before.  I only started using NetBeans after building the new comp 3+ weeks ago however I have put a lot of my code into it.  The file that this started on is an 800 line JSP with lots of Java code and HTML and I was going through and retabbing all the HTML.  I'm reporting it immediately so haven't had time to notice it happening on anything else, but I have edited other large JSPs perhaps not as heavily with no effect.

I exited and restarted NetBeans and it did it again.  However I went to a different file for editing and then back and now it seems to be ok.  Strange.

NetBeans v6.9.1
Windows 7


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo