I'm still curious about the 1.5 second GC as it sounds strange that large
amounts of short-lived garbage could cause it. FWIW on a relatively slow
machine with j2se1.4.1_01 I tried measuring the effect of creating large
amount of garbage e.g.
100M x new Garbage()
class Garbage {
double[] memory = new double[4];
...
}
elapsed #GCs per GC JVM
65.56 3052 <1ms -client
54.71 3058 <1ms -server
45.54 55 1-7ms -server -Xms256m -Xmx256m \
-XX:NewSize=120m -XX:MaxNewSize=120m
All these GCs are only of the Eden space. Its when I create circumstances where
FULL GCs are performed that suddenly it takes 800ms - 1.5 seconds per GC [and
blew the elapsed time out to about 95 seconds]. For the purposes of creating
this artifically either the following did it:
-Xms256m -Xmx256m -XX:NewSize=140m -XX:MaxNewSize=140m
or
-Xms256m -Xmx256m -XX:NewSize=120m -XX:MaxNewSize=120m \
-XX:PretenureSizeThreshold=16 -XX:MaxTenuringThreshold=0
[Of course I can't imagine ever wanting to use such a small PretenureSizeThre
Hence I'm wondering whether the 1.5 seconds reported is due to FULL GC. If the
picking routines are truly generating garbage then they should be cleaned up
very efficiently in Eden. However if they are not so short-lived, getting
tenured and ending up in Old then that would be bad news.
============================================================================
,-_|\ Richard Smith - SE Melbourne
/ \ Sun Microsystems Australia Phone : +61 3 9869 6200
[EMAIL PROTECTED] Direct : +61 3 9869 6224
\_,-._/ 476 St Kilda Road Fax : +61 3 9869 6290
v Melbourne Vic 3004 Australia
===========================================================================
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
