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.
Build: NetBeans IDE 7.3.1 (Build 201306052037) VM: Java HotSpot(TM) 64-Bit Server VM, 23.7-b01, Java(TM) SE Runtime Environment, 1.7.0_17-b02 OS: Mac OS X User Comments: szmitek: Opening Projects GUEST: The comunication with Apache Tomcat is very slow. Maximum slowness yet reported was 273365 ms, average is 89010
Created attachment 136860 [details] nps snapshot
It seems that sun.java2d.opengl.OGLRenderQueue.flushBuffer() blocks rendering of the UI, I'm afraid there is nothing I can do with that -> WONTFIX
*** Bug 225708 has been marked as a duplicate of this bug. ***
I think the error text is misleading. I've found a way that seems to reproduce this problem. It seems to relate to background scanning after performing a clean on a maven project. What seems to be the cause is that the IDE is performing a background scan and the next event that occurs is a paint event which naturally causes a low performance error, but is a side-affect to the cause.
Created attachment 161969 [details] NetBeans stderr log Standard error with IDE open for ~10 days where performance has slowly degraded to near impossible usability.
Created attachment 161970 [details] NetBeans sdtout log with thread-dump This file contains three thread dumps, first while the background scanning occurs which is taking a significant amount of time and blocking all IDE operations. The IDE can not be used within this time. There were two more taken after background scanning completed.
Related to what brettryan reports, I have noticed that sometimes the background scanning process can become problematic while launching NetBeans. If there where project open when you closed, the IDE starts, open the projects and starts a background scan. Sometimes, for a reason that I have not been able to determine, the scanning process can bring the machine to its knees. The only option in that case is to kill the NetBeans process. Upon opening again you have to close immediately the open projects, to avoid the scanning. Because of that unpredictable problem I have instructed my team to always close the projects before exiting the IDE. Nevertheless, I'm sure there is a bug hidden in the background scanning process.
Most of the reports are from Mac OS X and the slowness data shows overloading of java2d drawing pipeline caused by heapview in Performance toolbar. There is JDK bug https://bugs.openjdk.java.net/browse/JDK-8087201 filed for this problem and it is fixed in JDK 8u66. So running NetBeans in JDK 8u66 should improve the situation. Another workaround is to disable 'Performance toolbar' (right-click the IDE toolbar).
(In reply to Tomas Hurka from comment #8) > Most of the reports are from Mac OS X and the slowness data shows > overloading of java2d drawing pipeline caused by heapview in Performance > toolbar. There is JDK bug https://bugs.openjdk.java.net/browse/JDK-8087201 > filed for this problem and it is fixed in JDK 8u66. So running NetBeans in > JDK 8u66 should improve the situation. Another workaround is to disable > 'Performance toolbar' (right-click the IDE toolbar). With due respect this is not the cause but a symptom of it. I have been running the latests JDK and in my attached I was running u102 or u101. I will disable performance toolbar and repeat but what will happen is some other exception will get reported as the symptom instead. The slowness is being detected as a symptom to the IDE's background scanning, which as I've demonstrated in my attached logs and thread dump gets longer and longer the IDE has been running. The drawing pipeline also does not explain the eventual OOME caused by this if you continue to leave the IDE running through this. There is without question a memory leak somewhere suspected being in bAckground scanning.
(In reply to brettryan from comment #9) > (In reply to Tomas Hurka from comment #8) > > Most of the reports are from Mac OS X and the slowness data shows > > overloading of java2d drawing pipeline caused by heapview in Performance > > toolbar. There is JDK bug https://bugs.openjdk.java.net/browse/JDK-8087201 > > filed for this problem and it is fixed in JDK 8u66. So running NetBeans in > > JDK 8u66 should improve the situation. Another workaround is to disable > > 'Performance toolbar' (right-click the IDE toolbar). > > With due respect this is not the cause but a symptom of it. > I have been > running the latests JDK and in my attached I was running u102 or u101. I > will disable performance toolbar and repeat but what will happen is some > other exception will get reported as the symptom instead. This is good, since we will get better info to diagnose your problem. > The slowness is being detected as a symptom to the IDE's background > scanning, which as I've demonstrated in my attached logs and thread dump > gets longer and longer the IDE has been running. It is hard to tell without proper slowness report. > The drawing pipeline also does not explain the eventual OOME caused by this > if you continue to leave the IDE running through this. OOME should be reported as separate issue, We need a heap dump to be able to diagnose it. > There is without question a memory leak somewhere suspected being in > bAckground scanning. Can you provide steps how to reproduce it?
(In reply to Tomas Hurka from comment #10) > This is good, since we will get better info to diagnose your problem. I've disabled the performance toolbar and the symptoms are exactly the same, whenever background scanning fires the IDE locks up, I eventually "Not enough memory to compile" which is irritating because the IDE has plenty, it's just eating it all up over time. > > The slowness is being detected as a symptom to the IDE's background > > scanning, which as I've demonstrated in my attached logs and thread dump > > gets longer and longer the IDE has been running. > It is hard to tell without proper slowness report. > > > The drawing pipeline also does not explain the eventual OOME caused by this > > if you continue to leave the IDE running through this. > OOME should be reported as separate issue, We need a heap dump to be able to > diagnose it. One problem with the IDE is that when the notification appears it leads the user to believe they aren't giving the IDE enough memory, giving the link [1]. Which isn't valid, because if this were the case it would appear on day 1 not day 3 of running the IDE. Again though, this bug IS actually cause by the OOME. It's just being hidden by the fact that the IDE is picking up on the fact it can't itself render because the IDE is blocking itself. > > There is without question a memory leak somewhere suspected being in > > bAckground scanning. > Can you provide steps how to reproduce it? I don't know how I'd provide steps. Providing steps to reveal a memory leak isn't the easiest thing to do. Having said that, in my comment on 2016-07-05 I did mention that if I run then clean a maven based web project with CoS turned on I eventually get the issue after the clean occurs where background scanning will bring the IDE to its knees and I get low memory exceptions. If you can help me figure out a way to reproduce this quicker then I can try my best to do so. [1]: http://wiki.netbeans.org/InsufficientMemoryToIndexRoot
Created attachment 162309 [details] Netbeans sdtout log with thread-dump Have produced thread dump while performance toolbar is off. There's three thread dummps, two while the IDE was locked up and another when it freed aka. two while background scanning, one after.