Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 125531 - Better handling of InsufficientMemoryException
Better handling of InsufficientMemoryException
Status: CLOSED FIXED
Product: ide
Classification: Unclassified
Component: Timers
6.x
All All
: P2 (vote)
: 6.x
Assigned To: Petr Nejedly
issues@apisupport
http://statistics.netbeans.org/except...
61fixes3-fixed, EXCEPTIONS_REPORT
: PERFORMANCE
: 125366 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-18 02:55 UTC by eliangela
Modified: 2011-05-24 13:47 UTC (History)
12 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
stacktrace (3.29 KB, text/plain)
2008-01-18 02:55 UTC, eliangela
Details
stacktrace (3.38 KB, text/plain)
2008-01-18 13:22 UTC, javydreamercsw
Details
stacktrace (3.36 KB, text/plain)
2008-01-22 15:25 UTC, dfa
Details
stacktrace (3.32 KB, text/plain)
2008-01-31 22:47 UTC, Michel Graciano
Details
stacktrace (2.93 KB, text/plain)
2008-02-01 20:55 UTC, dcherk
Details
stacktrace (2.94 KB, text/plain)
2008-02-13 15:12 UTC, Dan Kolar
Details
stacktrace (3.92 KB, text/plain)
2008-02-26 20:37 UTC, hbelalta
Details
stacktrace (3.30 KB, text/plain)
2008-03-18 17:08 UTC, Petr Dvorak
Details
screenshot 1 (89.29 KB, image/jpeg)
2008-04-21 13:33 UTC, kate
Details
screenshot 2 (94.28 KB, image/jpeg)
2008-04-21 13:34 UTC, kate
Details
screenshot 3 (89.14 KB, image/jpeg)
2008-04-21 13:34 UTC, kate
Details
Patch (579 bytes, patch)
2008-06-25 15:39 UTC, Pavel Flaska
Details | Diff
stacktrace (2.09 KB, text/plain)
2008-07-30 20:31 UTC, Michel Graciano
Details
stacktrace (259 bytes, text/plain)
2008-07-31 17:34 UTC, Unknown
Details
Patch against release61_fixes. (751 bytes, patch)
2008-08-04 16:14 UTC, Jan Lahoda
Details | Diff
Built module with the patch, from release61_fixes. (71.09 KB, application/octet-stream)
2008-08-04 16:15 UTC, Jan Lahoda
Details

Note You need to log in before you can comment on or make changes to this bug.
Description eliangela 2008-01-18 02:55:06 UTC
Build: NetBeans IDE 6.0 (Build 200711261600)
VM: Java HotSpot(TM) Client VM, 1.6.0_03-b05
OS: Windows XP, 5.1, x86

User Comments:
Comment 1 eliangela 2008-01-18 02:55:10 UTC
Created attachment 55228 [details]
stacktrace
Comment 2 javydreamercsw 2008-01-18 13:22:35 UTC
Build: NetBeans IDE 6.0 (Build 200711261600)
VM: Java HotSpot(TM) Client VM, 1.6.0_03-b05
OS: Windows XP, 5.1, x86

User Comments: 
Comment 3 javydreamercsw 2008-01-18 13:22:45 UTC
Created attachment 55245 [details]
stacktrace
Comment 4 dfa 2008-01-22 15:25:37 UTC
Build: NetBeans IDE 6.0 (Build 200711261600)
VM: Java HotSpot(TM) 64-Bit Server VM, 1.6.0_03-b05
OS: Linux, 2.6.23-gentoo-dfa, amd64

User Comments: 
Comment 5 dfa 2008-01-22 15:25:40 UTC
Created attachment 55377 [details]
stacktrace
Comment 6 Jan Becicka 2008-01-24 13:22:44 UTC
*** Issue 125366 has been marked as a duplicate of this issue. ***
Comment 7 Michel Graciano 2008-01-31 22:47:11 UTC
Build: NetBeans IDE Dev (Build 200801310006)
VM: Java HotSpot(TM) Client VM, 1.6.0_03-b05
OS: Linux, 2.6.22-14-generic, i386

User Comments: 
Comment 8 Michel Graciano 2008-01-31 22:47:15 UTC
Created attachment 55881 [details]
stacktrace
Comment 9 Jan Becicka 2008-02-01 09:12:16 UTC
Dane, please take a look at AbstractRefactoring.createProblemAndLog
Comment 10 dcherk 2008-02-01 20:55:30 UTC
Build: NetBeans IDE 6.0 RC2 (Build 200711201000)
VM: Java HotSpot(TM) Client VM, 1.6.0_03-b05
OS: Windows XP, 5.1, x86

User Comments: 
Comment 11 dcherk 2008-02-01 20:55:33 UTC
Created attachment 55936 [details]
stacktrace
Comment 12 Dan Kolar 2008-02-13 15:12:05 UTC
Build: NetBeans IDE Dev (Build 200802110004)
VM: Java HotSpot(TM) Client VM, 1.6.0_03-b02
OS: Windows XP, 5.1, x86

User Comments: 
Tried find usages on SetExecutionUriAction, with some netbeans modules opened
Comment 13 Dan Kolar 2008-02-13 15:12:15 UTC
Created attachment 56612 [details]
stacktrace
Comment 14 hbelalta 2008-02-26 20:37:15 UTC
Build: NetBeans IDE 6.0 (Build 200711261600)
VM: Java HotSpot(TM) Client VM, 1.6.0-b105
OS: Windows XP, 5.1, x86

User Comments: 
Comment 15 hbelalta 2008-02-26 20:37:18 UTC
Created attachment 57304 [details]
stacktrace
Comment 16 Exceptions Reporter 2008-03-09 15:08:24 UTC
This issue has already 20 duplicates 
Comment 17 Exceptions Reporter 2008-03-14 18:05:16 UTC
This issue has already 20 duplicates 
Comment 18 Petr Dvorak 2008-03-18 17:08:21 UTC
Build: NetBeans IDE Dev (Build 200803170003)
VM: Java HotSpot(TM) Client VM, 10.0-b19
OS: Linux, 2.6.24-12-generic, i386

User Comments: 
I moved JFrame form from one package to another one. Exception speaks about  a memory, but it does not seem possible at this moment...
Comment 19 Petr Dvorak 2008-03-18 17:08:31 UTC
Created attachment 58596 [details]
stacktrace
Comment 20 Jan Becicka 2008-03-18 19:37:57 UTC
Dane, please fix this one. It has many duplicates. Thanks
Comment 21 Daniel Prusa 2008-03-19 16:39:49 UTC
Fixed in 988ce607c302.
Comment 22 kate 2008-04-21 13:33:04 UTC
I am forced to reopen this issue because it still persists in RC 6.1.

Product Version: NetBeans IDE 6.1 RC1 (Build 200804100130)
Java: 1.6.0_10-beta; Java HotSpot(TM) Client VM 11.0-b11
System: Windows XP version 5.1 running on x86; Cp1252; en_US (nb)

There seems to be problem with move/refactor of more files when some file contains bad reference (i.e. imports package
that does not exist).

1. I selected more files within one project (one with bad reference).
2. I dragged them to another package (Projects view) [screenshot1].
3. "Move Classes" Dialog appeared. I pressed "Refactor" button [screenshot2].
4. Some strange* error was displayed. After that exception was thrown [screenshot3].

*I would not say there is not enough memory or that the source tree is too large (you can see, it is really small).


Comment 23 kate 2008-04-21 13:33:57 UTC
Created attachment 60491 [details]
screenshot 1
Comment 24 kate 2008-04-21 13:34:23 UTC
Created attachment 60492 [details]
screenshot 2
Comment 25 kate 2008-04-21 13:34:47 UTC
Created attachment 60493 [details]
screenshot 3
Comment 26 Exceptions Reporter 2008-06-05 19:33:48 UTC
This issue has already 50 duplicates 
see http://statistics.netbeans.org/exceptions/detail.do?id=13304
Comment 27 Jan Becicka 2008-06-06 11:39:22 UTC
Honzo, please take a look at it. Some hacking needs to be fine tuned in AbstractRefactoring.createProblemAndLog. Thanks.
Comment 28 Jan Pokorsky 2008-06-17 14:37:26 UTC
kate: I have tried to reproduce your case and it works with NB 6.1 and later. Please try it again with released NB 6.1
and released JDK 1.6.
Comment 29 Jan Pokorsky 2008-06-18 14:25:20 UTC
I have found steps to reproduce it. In case a refactoring action e.g. Move Class is invoked repeatedly memory starts to
grow rapidly then. Even the refactoring runs on simple project without dependencies.

According to the memory profiler it seems that there are plenty of javacs kept by soft references. We should find out 1)
who creates them and 2) why JMX Beans report them as insufficient memory.
Comment 30 Jan Pokorsky 2008-06-18 17:24:33 UTC
The root of this problem seems to be the timers module and namely InstanceWatcher.FinalizingToken class. This class
implements Object.finalize() method that prevents javacs to be garbage collected as expected. Problems disappeared after
disabling the module.

I am a bit surprised the module is part of NB 6.1 FCS. Anyway reassigning to apisupport/timers to resolve it.
Comment 31 Petr Nejedly 2008-06-25 12:06:57 UTC
I don't understand your evaluation.
First, timers don't use soft references at all, only weak references, which never* prevent GCing of the referenced objects.

And second, InstanceWatcher.FinalizingToken doesn't hold on any other instance, it is just a random (single) instance
with finalize method - there are much more finalizable instances on the heap all the time.

Where are those soft references really comming from?

Note: I'm not saying that timers module is not triggering this problem, I just want to know more...
The best solution would probably be to issue an update with this module disabled by default.

*) Well, I can imagine WeakReference being able to prevent cleaning the objects during scavenge...
Comment 32 Petr Nejedly 2008-06-25 12:30:03 UTC
BTW: What if you issued an explicit gc() in such case and retry?
Comment 33 Jan Pokorsky 2008-06-25 12:57:37 UTC
First I thought it is some SoftReference since the javac was released after filling the whole memory. Forcing GC sooner
did not help. VisualVM was not able to find a GC root.

Later, as I wrote above, the only suspicious references that I found were from InstanceWatcher
(JavacTaskImpl<-...<-InstanceWatcher.FinalizingToken<-Finalizer) and you are right that they are weak.

The solution was to disable the timers module. The problem disappeared immediately.

BTW InstanceWatcher.FinalizingToken DOES hold other references since it is not static nested class.
Comment 34 Pavel Flaska 2008-06-25 13:39:44 UTC
> The best solution would probably be to issue an update with this module disabled by default.

Yes, that is exactly what we want to do for the time being.
Comment 35 Pavel Flaska 2008-06-25 15:09:47 UTC
Cc'ing sustaining. 
Comment 36 Pavel Flaska 2008-06-25 15:39:17 UTC
Created attachment 63432 [details]
Patch
Comment 37 pslechta 2008-06-26 11:32:48 UTC
As discussed with pflaska, there should be no dependency on timers module and the module should be used only for
internal profiling of the IDE. So there should be no objections to disable it.
Comment 38 Jiri Prox 2008-06-26 13:33:05 UTC
patch is verified in current trunk
Comment 39 Jan Lahoda 2008-06-30 16:43:57 UTC
I did two changes in trunk:
-changed InstanceWatcher to use WeakReference+Utilities.activeReferenceQueue - cleaner, and will hopefully play nicer
with GC.
http://hg.netbeans.org/main/rev/7a73ff20b869
-the module is non-functional (Logger handler not registered+icon in the Memory toolbar hidden) when assertions are off.
The overhead of the module in the release should be therefore negligible. Can be overridden by a command line property.
http://hg.netbeans.org/main/rev/14831576319b
Comment 40 Quality Engineering 2008-07-01 04:47:03 UTC
Integrated into 'main-golden', available in NB_Trunk_Production #292 build
Changeset: http://hg.netbeans.org/main/rev/7a73ff20b869
User: Jan Lahoda <jlahoda@netbeans.org>
Log: #125531: do not use finalizers.
Comment 41 Jesse Glick 2008-07-18 18:23:45 UTC
I recommend jlahoda's #14831576319b (dynamic enablement of module's UI) be reverted, as well as Tonda's recent
#d94a37ba3d4c (hide of module from Plugin Manager), and that the module just be moved to the update center and out of
the build. If you want it, you install it and its UI appears, just like with other optional modules potentially useful
to NB developers (Project Metadata Inspector, System Properties, ...); if you want to turn it off or delete it, you do
so from PM like with any other functionality.
Comment 42 Jesse Glick 2008-07-18 18:24:28 UTC
In particular, the current state is broken:

http://deadlock.netbeans.org/hudson/job/nbms-and-javadoc/1958/testReport/org.netbeans.nbbuild/VerifyUpdateCenter/testAutoUpdateVisibility/

Some regular modules (that no one depends on) neither AutoUpdate-Show-In-Client nor AutoUpdate-Essential-Module
org.netbeans.modules.timers
Comment 43 Michel Graciano 2008-07-30 20:30:52 UTC
Build: NetBeans IDE Dev (Build 200807291401)
VM: Java HotSpot(TM) Client VM, 10.0-b23, Java(TM) SE Runtime Environment, 1.6.0_07-b06
OS: Linux, 2.6.24-20-generic, i386

User Comments: 


Stacktrace: 
java.io.IOException
        at org.netbeans.api.java.source.JavaSource.runModificationTask(JavaSource.java:992)
        at org.netbeans.modules.refactoring.java.spi.JavaRefactoringPlugin.processFiles(JavaRefactoringPlugin.java:244)
        at org.netbeans.modules.refactoring.java.spi.JavaRefactoringPlugin.processFiles(JavaRefactoringPlugin.java:231)
        at org.netbeans.modules.refactoring.java.plugins.JavaWhereUsedQueryPlugin.prepare(JavaWhereUsedQueryPlugin.java:200)
        at org.netbeans.modules.refactoring.api.AbstractRefactoring.pluginsPrepare(AbstractRefactoring.java:380)
        at org.netbeans.modules.refactoring.api.AbstractRefactoring.prepare(AbstractRefactoring.java:202)
Comment 44 Michel Graciano 2008-07-30 20:31:08 UTC
Created attachment 66115 [details]
stacktrace
Comment 45 Unknown 2008-07-31 17:34:02 UTC
Build: NetBeans IDE Dev (Build 200807301401)
VM: Java HotSpot(TM) 64-Bit Server VM, 10.0-b22, Java(TM) SE Runtime Environment, 1.6.0_06-b02
OS: Linux, 2.6.25-9.slh.1-sidux-amd64, amd64

User Comments: 


Stacktrace: 
java.io.IOException
Comment 46 Unknown 2008-07-31 17:34:07 UTC
Created attachment 66197 [details]
stacktrace
Comment 47 Jan Lahoda 2008-08-04 16:14:35 UTC
Created attachment 66503 [details]
Patch against release61_fixes.
Comment 48 Jan Lahoda 2008-08-04 16:15:23 UTC
Created attachment 66504 [details]
Built module with the patch, from release61_fixes.
Comment 50 Lukas Hasik 2008-08-05 13:51:22 UTC
patched jar tested with 6.1. The timers are gone after applying the new jar

->fixed, verified
Comment 51 Lukas Hasik 2008-08-05 13:51:43 UTC
v
Comment 52 rbalada 2008-08-05 20:24:57 UTC
I've imported tha attached changeset http://www.netbeans.org/nonav/issues/showattachment.cgi/66503/125531.diff into
release61_fixes repository as http://hg.netbeans.org/release61_fixes/rev/ba805dd42fab
Comment 53 Lukas Hasik 2008-08-21 09:56:04 UTC
verified in patch3 (2008-08-12_03-59-31)


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