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.
We are encountering a PermGen out of memory error in NetBeans in our environment. We ran it through the profiler, but noticed our code was only taking up about 2k of ram, which was clearly not the problem, so we started trying to reproduce it in other module suites, with success. The exact procedure to generate the PermGen memory error was: 1. Create a new empty module suite. It does not matter if you add modules to it or not. 2. Turn the suite into a stand-alone project through the properties menu 3. Create a new java project 4. Debug the java project 5. Create another new java project 6. Debug the new java project After you do this (and sometimes debug a few more times), a PermGen memory error will be thrown that basically crashes the newly built version of NetBeans. Caveats: 1. This only happens in a stand-alone release, NOT a as nbm plugins, so far as I can tell. 2. This can be trivially fixed by increasing the memory usage to netbeans in the .conf file, however, many users will not know to do this, and either way, the default setting shouldn't be so low that this this happens even in the case where there are no modules (or a suite that takes up only 2k of ram). We've tested this on NetBeans 6.8: 1. Windows XP and 7, both 23 and 64 bit 2. Mac OS X 10.6 As far as we can tell, it is reproducible eon all of these platforms.
(In reply to comment #0) > This only happens in a stand-alone release, NOT a as nbm plugins, so far as > I can tell. Because when you create the suite as a set of modules added on top of the NB app, the IDE's standard launcher is used, which includes a netbeans.conf that sets a larger-than-default permgen size (among other customizations). > This can be trivially fixed by increasing the memory usage to netbeans in > the .conf file And that is what you should do when creating a custom application: tune JVM startup parameters in a way appropriate for what that app is doing. (If the app happens to be a NB-like Java IDE, then you might start by copying the NB IDE's parameters, but in most cases it will be something quite different.) > even in the case where there are no modules If you create a standalone app but decline (in the dialog that appears at this time) to use only the recommended initial Platform subset - i.e. you agree to include all the modules present in all the clusters in the IDE - then you have hundreds of modules and you will definitely need to do some tuning. An app using only the default Platform subset runs fine with default JVM settings.
I think I need to communicate more clearly about what I think the problem is. While I definitely agree with your point that the standard procedure is to modify your .conf script to update the amount of memory that the system can allocate max, my point is that the _way_ that you do this is pretty esoteric. As such, maybe what I am suggesting here is a request for enhancement, not a defect. For example, here's one way that this could be "fixed" in my view: 1. In the properties window for the module suite, a few additional options are available: a. Max Memory b. Min Memory c. Other VM flags/options you want to pass 2. When the user clicks build (e.g., build zip), the appropriate .conf file will be generated into your zip distribution/launcher/etc. Now, I recognize that the netbeans installer does modify this file, and that's perfectly sensible since every install could potentially be a little different, but it would be nice if we could "visually" make this process more transparent, at least for the most common options you might want to change in these conf files. This, as opposed to: 1) track down weird memory errors, 2) discover it's in a .conf file, 3) modify some pretty non-readable parameters (e.g., -J-Xms24m, -J-Xmx64m), 4)add into the build script the new file so that it generates into the zip distribution. So, all in all, my point is that it would be nice if we could do something seemingly easy like "set the max memory to 200 megs instead of 64 megs" without having to go through this process. Just to make it clear, I've changed this to a request for enhancement and re-opened it like that. Hopefully, that's clear.
This part is already filed in similar form. *** This bug has been marked as a duplicate of bug 64618 ***