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.
If users installs full IDE netbeans.conf is updated to contain -J-Xmx512m. This is too big heap most of tasks and can cause serious troubles to our users. Although this is requested by some teams (ent. and UML IIRC) still it is very likely that more users will suffer from this settings than see its benefits. 1) It makes the IDE unusable on machines with 512MB of physical RAM. The whole system will start to swap when the heap grows to 200-250MB. Maybe even sooner depending on evironment - expect that OS + mailer + web browser occupy ~150MB, overhead of JVM is next 120-200MB including perm gen area, stacks, native code, native data. Do not forget that users will want to run their application. Also note that the heap will grow to 200MB during common JavaSE development easily. Repeating of edit/compile/debug cycle is enough here. 16% of respondent to last performance survey claimed that they have 512MB on their machine. 2) It is hardly usable even with 1GB of RAM. Before we start to count as we do for previous case note that GC delays with default collector are longer with larger heap - >1s to do full GC on a 380MB heap on my PentiumM 1.7GHz, JDK 6.0u1. It means responsivenes is affected too. Similar computation will reveal that we have serious problem if the heap size grows to ~400MB and do some interesting development. RSS of process is >600MB. If you do JavaEE development and use glassfish that has the same -Xmx512m setting and customized NewRatio it will likely use 200MB of Java heap even to run our samples. 300MB RSS of this process is common (and there is not too much shared). Add another small footprint for Java DB. Similarly development on top of NetBeans platform is almost unusable in this configuration. 1GB RAM is the most common amount of memory reported in last performance survey (45% of users). 3) (minor note) Those task that needs such a large memory should be documented and they are less typical. Since the purpose of M9 is to give good preview we can expect more early adopters and less people using this for daily work. Personally I'd accept -Xmx192m for this milestone. Of course better solution is needed for FCS.
-> FIXED For UML the Xmx value would be set to 192m. For SOA (according to Sergey S) this is not required, so Xmx won't be modified.
verified with 200704270000. thanks