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.
release40, custom build from 10/11/04 sources Scenario: increase ulimit to >1500 (otherwise the IDE will fail miserably) *) open project nbbuild/misc and all dependencies *) close all of them - here the project disappears but looks like nothing else happens *) Press gc several times - scanning dialog apperas (Why!?) (here it crashes with ulimit on 1024 files as it starts opening more and more DB files) *) Press gc more - The heap usage is lowered only slightly Notes: -) all of this was without a single file open. -) It seems that memory used by ClassIndexes was quite reduced, but it looked like if another platform got parsed/scanned (while I had no project open at that time) -) More memory used by more instances of MDRCache$FacilityCache$CacheReference and e.g. MOFID: Why is something getting into memory while all I'm doing is closing projects? I expected the memory usage would go down at least to state of a simple project opened, but it went only from 36MB heap (all projects) to 30MB heap (empty workspace)
Fixed. Checking in src/org/netbeans/modules/javacore/JMManager.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/JMManager.java,v <-- JMManager.java new revision: 1.74; previous revision: 1.73 done Processing log script arguments... More commits to come... Checking in src/org/netbeans/modules/javacore/classpath/MergedClassPathImplementation.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/classpath/MergedClassPathImplementation.java,v <-- MergedClassPathImplementation.java new revision: 1.11; previous revision: 1.10 done
Tomas Z., could you please review the fix?
Ok, I will look at it.
Diff urls: http://java.netbeans.org/source/browse/java/javacore/src/org/netbeans/modules/javacore/JMManager.java.diff?r1=1.73&r2=1.74 http://java.netbeans.org/source/browse/java/javacore/src/org/netbeans/modules/javacore/classpath/MergedClassPathImplementation.java.diff?r1=1.10&r2=1.11
Do you plan to merge the fix into release40 including the INFORMATIONAL exception logging? I'd prefer to exclude it for the production 4.0 build.
Aren't the INFORMATIONAL exceptions suppressed in the release by default? If not, why? It should be quite easy with ErrorManager - otherwise I don't see a reason why to use it instead of simple e.printStackTrace(). Btw. in this particular case the exception should never occur. Anyway, if it occurs, why it should not be logged to help us finding bugs when somebody submitts their messages.log?
I believe they're suppressed in the console. They still appear in the message.log, don't they? If not, please disregard my request as irrelevant. If the exception is extremely rare as you say and it might help to track down potentially serious problems, then keep it in. I've recently seen some informational exceptions that weren't rare at all and were good only for polluting message logs and confusing users.
OK, this one is very rare. In fact it should never occur based on the code in FileObject.getURL method: public final URL getURL() throws FileStateInvalidException { // XXX why does this still throw FSIE? need not return URLMapper.findURL(this, URLMapper.INTERNAL); }
INFORMATIONAL is put into log only, if it is rare and it helps to find a problem it should stay there.
Ok, agreed. No objections from me.
The patch looks fine to me.
Fixed in release40 branch. Checking in src/org/netbeans/modules/javacore/JMManager.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/JMManager.java,v <-- JMManager.java new revision: 1.73.2.1; previous revision: 1.73 done Processing log script arguments... More commits to come... Checking in src/org/netbeans/modules/javacore/classpath/MergedClassPathImplementation.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/classpath/MergedClassPathImplementation.java,v <-- MergedClassPathImplementation.java new revision: 1.10.4.1; previous revision: 1.10 done
Works OK even on release40 branch now. After closing all projects and several GC cycles, only ~18MB of heap memory is used (JDK ClassIndex in memory).
Reorganization of java component