One thing I noticed when running the example is that there appears to be
a considerable amount of "garbage" getting promoted from Eden through
survivor spaces into Old generation heap.
Instead of using -verbose:gc I used the following to get more detailed analysis:
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintHeapAtGC
I was able to reduce the impact of GC by a huge margin, simply by using a
larger Eden space, which happens as a byproduct of "-server -Xms64m -Xmx64m".
Of course, I could also have explicitly specified a larger Eden through
-XX:NewSize=20m -XX:MaxNewSize=20m. I'm still left wondering why the garbage
isn't being cleaned up from Eden though.
On my system there are also several other processes running in the background
from time to time e.g. mozilla, netscape, acroread. I was able to improve the
stability further by running it as a realtime process, since it wasn't
cpu-bound. And by stable, I'm referring to about 0.7% of frames being outside
the 13-14ms between frames expected when displaying at 76Hz. The three
slowest frames were 18, 27 and 159ms over a 3 minute period.
============================================================================
,-_|\ 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".
