cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <>
Subject [HEADS UP] Don't use -Xincgc with JDK 1.4
Date Wed, 20 Feb 2002 18:48:31 GMT
There was a tip running around late last year that if you ran the JVM 
with the -Xincgc that the system would perform better.  With my current
testing using JDK 1.4 (final release), I found that enabling that option
lengthens the time of the ECM/ContainerManager test by a factor of 2. 
In both cases, the overall time is lengthened.  For the 
ContainerManager, it is only 1.5 times as long; but for the ECM it is 
twice as long.

While incremental garbage collection is supposed to make you spend less
time in the garbage collector, it is called more often.  The net result
is that you spend more time in the garbage collector.

Incremental GC cycles are only about 10 ms in length, while the small
GC cycles are roughly .1-6ms.  A full GC takes anywhere between 100 to
1500 ms to complete.  Full GCs are few and far between in a well tuned
system, while regular GC cycles occur every second or so.  The problem
with incremental garbage collection is it is called every 4 seconds or

I look forward to the day where the JVM GC cycles are completely 
asynchronous (I think this is slated for JDK 1.5).  Currently all 
threads are stopped while garbage collection occurs.

Regarding other options I tried:

      Not alot of change.  Class GC doesn't happen often as most Avalon
      systems keep using the set of classes it has.  When run with
      -verbosegc, I only detected one instance of Class GC--and that
      was related to a JUnit class only used during startup....

      The test is flawed in that there is not alot of JVM/OS signalling
      to begin with.  It *may* help a Servlet environment, and it *may*
      hurt.  My test is all JVM bound, and the filesystem is only
      accessed at set up.

      Presizing the JVM memmory usage had little affect on the test.
      Just make sure your -Xmx is set high enough....

      This is a strictness checking parameter.  It provides stricter
      rules checking on the bytecode.  Don't worry--we pass.

      Provides a very useful human readable dump of JVM activity.  Hats
      off to the JDK 1.4 crew!


"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin

To unsubscribe, e-mail:
For additional commands, email:

View raw message