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.
FFJ40EE-EA #020301_1 jdk1.4.0, Solaris 5.8 window configuration MDI Probably ireproducible. Just changed root node of some localfilesystem and then tried to expand it. CPU jumps to 100% for cca 5 minutes. Severeal thread dumps are attached. (Note, the file system structure was small). After this ide looks ok again. Filing this only because if someone will check the stacktraces. This happens me several times in the past.
Created attachment 4968 [details] bunch of ftds
looks like GC kicks in and WeakListners start to unregister, at the same time someone else needs those listeners so they are being re-registered. (rougly speaking) It reminds me that we actually need time-out weak references not weak references per se which get GC'ed everytime a full GC cycle is run.
Agreed, we have a need for something halfway between a weak and soft ref... should have a configurable timeout, and every call to get() records the last time this happened. If get() is not called for the timeout period, the ref is made available for collection during the next GC cycle as a weak ref.
No, Trung, it is not caused by early unregistration of listeners. It is even not caused by those WeakListeners. There is a refresh process running in the background, caused by the root folder change. Honza told me he changed the root on the deeply expanded $HOME. Because the FS was expanded deeply, there was a lot of DataObjects crated and they were rerecognized. To the WeakListener collection: During the rerecognition, MimeSupport, when consulted, creates a CachedFileObject and hooks it through WeakListener on the real FileObject to reflect possible changes in them (a bit of overkill for short-living object, but we can't really controll its lifetime). These get collected very quickly, which is right behavoiur. Moreover, DOs existing in the previous configuration will be invalidated (the FOs under them won't exist any more) and thus GCed as well and their listeners get freed too. The unregistration itself (although visible in the dumps) should not be to costly unles there is a big folder (see issue 20715), but I can speed it up for listener sequences of the same kind (I have the code already prepared, I was working on WL refactoring). So the problem probably lies in the amount of DOs and especially DataFolders revalidated. It may be possible that there is some work done multiple times, but not because of WeakReferences. Generally, I've proposed implementation of a timed reference long time ago, but this is probably not the place where we need it. FOs are weak referenced but the FolderList, once created for them, is soft cached and so the FOs are effectively softly reachable.
BTW: I've streamlined the timed WeakListener unregistration to be faster, less memory intensive and doing less introspection.
Set target milestone to TBD
Unfortunatelly there is missing information if user experienced UI freeze. 100% CPU load is OK if it does not affect AWT events processing. I'm able to simulate 100% CPU load that does not affect AWT processing, but I'm unable to simulate 100% CPU load that blocks/starves AWT. Unfortunatelly in reality it ocassionaly occures e.g. while Java parsing thread is active.
If there is work that have to be done, nothing can prevent it. Changing the root of LFS is evil (for other reasons as well), so closing as wontfix.
Peter is right - verifying.