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.
Summary: | PermGen memory error with empty stand-alone module suite | ||
---|---|---|---|
Product: | platform | Reporter: | stefika |
Component: | Module System | Assignee: | Jesse Glick <jglick> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | ||
Priority: | P3 | ||
Version: | 6.x | ||
Hardware: | PC | ||
OS: | Mac OS X | ||
Issue Type: | ENHANCEMENT | Exception Reporter: |
Description
stefika
2010-03-17 17:12:21 UTC
(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. |