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.

Bug 102527 - Too large heap size set by installer
Summary: Too large heap size set by installer
Status: VERIFIED FIXED
Alias: None
Product: installer
Classification: Unclassified
Component: NBI (show other bugs)
Version: 6.x
Hardware: All All
: P1 blocker (vote)
Assignee: Kirill Sorokin
URL:
Keywords: PERFORMANCE
Depends on:
Blocks: 99509
  Show dependency tree
 
Reported: 2007-04-25 18:01 UTC by _ rkubacki
Modified: 2007-04-30 15:50 UTC (History)
5 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description _ rkubacki 2007-04-25 18:01:52 UTC
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.
Comment 1 Kirill Sorokin 2007-04-26 15:21:39 UTC
-> 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.
Comment 2 _ rkubacki 2007-04-30 15:50:47 UTC
verified with 200704270000. thanks