Richard,
Thanks for your notes on this subject. I'm trying to find enough time to try
some of the switches that you've pointed out to me.
You are right to guess 'Full GC'. Here's the output of a 2 minute time test with
'-verbosegc':
ogl_ifb: disabling vertical retrace sync on buffer flip
[GC 77485K->71600K(86224K), 0.1540732 secs]
Frame:128, Total Time: 20.35, fps:6.29 (7167 KBytes free)
Frame:256, Total Time: 34.81, fps:8.86 (5943 KBytes free)
[GC 80752K->76152K(86224K), 0.1580618 secs]
Frame:384, Total Time: 46.22, fps:11.22 (7166 KBytes free)
Frame:512, Total Time: 59.92, fps:9.34 (5315 KBytes free)
Frame:640, Total Time: 73.13, fps:9.69 (2981 KBytes free)
[GC 85304K->77289K(86480K), 0.0459906 secs]
[Full GC 77289K->73060K(86480K), 1.4356604 secs]
Frame:768, Total Time: 86.79, fps:9.37 (55599 KBytes free)
Frame:896, Total Time: 98.81, fps:10.65 (51362 KBytes free)
Frame:1024, Total Time: 108.63, fps:13.04 (47408 KBytes free)
Frame:1152, Total Time: 115.27, fps:19.27 (45157 KBytes free)
[GC 86820K->73853K(130688K), 0.0632930 secs]
Frame:1280, Total Time: 120.60, fps:24.02 (56380 KBytes free)
Rendered 1302 frames in 120.02605779999976 seconds
Frames/second = 10.847644452086659
Note:
a) The 1.4 second 'Full GC' 75 seconds in.
b) How the free memory falls
Your comments about the 'Eden space' sound good. I also suspect that the garbage
is long-lived enough to make it out of the Eden space. I'll post back here once
I've had the chance to tweak the parameters you suggest to see if I can prevent
this.
Thanks for your input - you've given me something very helpful to go on !
Rob
Richard Smith - Systems Engineer - Melbourne wrote:
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".
--
Rob Nugent
Sun Microsystems, Southampton, UK
[EMAIL PROTECTED]
Tel: +44 (0) 1489 585503
Fax: +44 (0) 1489 881363
===========================================================================
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".
