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.
I've got an email from one of our customer : ----------------- Specifically my problem is that NetBeans memory usage can go from around 60MB to 300 or over 500MB of memory by opening a single source file in some cases. Unfortunately, I have not managed to recall a case where I can reproduce an out-of-memory today, but I have managed to repeatedly produce a spike from 60MB to around 320MB by opening a single source file. I have attached the source file as well as before and after memory histograms and the NetBeans log file. -----------------
Created attachment 38339 [details] the file - causing OOME
Created attachment 38340 [details] heap-histogram 1
Created attachment 38341 [details] heap-histogram 2
Created attachment 38344 [details] message.log
I originally thought there is a leaked java parser or something, but there were only 4 javac.Name[] instances - only 4 live parser contexts, I'd say. So the parser is parsing too much data for some reason (it shouldn't AFAIK - it should resolve against known symbols in MDR). It might be an issue with MDR broken or something like this. In such case I'd suggest the user to first try deleting $userdir/var/cache, or eventually reproducing against completly clean userdir. I can hardly get to the same state as the user, as the attached source is not the problematic thing alone, it has dependencies (wt.*) that make the impact.
Comments from Jess: ----------- I deleted cache/*, let the scan complete, shutdown the IDE (to let everything close), opened the IDE, let the re-scan complete, and then opened the file. I did all of this in Java 5 (1.5.0_11) in this case. [I'd previously tested with both Java 5 and Java 6.] This time the full heap was consumed as best I could tell (I had allocated 352MB in this case). I didn't get a clear OutOfMemory in the GUI, but I did get ErrorChecker: Java heap space in the log file. ----------------- Also, in case it is of interest the mdrstorage directory contains 89.5 MB of stuff after the clean MDR rebuild. -----------------
Probably already fixed when MDR based model was replaced by the javac based model. I will try to open the attached file.
Fixed by new javac based model.
I think this issue has much more to do with the size of my projects and their metadata than simply the single source file in question. Unfortunately with ~30K classes, dozens of projects, and dozens and 3rd-party libraries, this is not something I can readily share. It could *very* well be that the new javac-based model in NetBeans 6 addresses the issue. That's a great resolution *if* NetBeans 6 reaches the functionality and stability level of NetBeans 5.5 soon. If not, then this having to wait for NetBeans 6 to stabilize may quite frankly force some users to switch to Eclipse.
Jess, have you tried last NB 6.0 Milestone 7 build ? It's available http://wiki.netbeans.org/wiki/view/MilestoneDownloads
verified
I admit I've had other distractions that have kept me from trying this with NB 6 milestones, but I'm curious how the fix was verified.
Reorganization of java component