> 'jw' makes a **very** interesting point.
>
> Is this a built-in problem that 'no one wants to talk about', or is there
> some tweak or technique or 'magic' that is able to mitigate the 'fact of
> life' existence of garbage collection that is known only to some
> (particularly those who **never** mention this as a problem)?
(lets see if I can press the correct key here - my prior attempt
at replaying seems to have been cut in half).
When it comes to GC, the current GC style in most of Sun's JDK uses
tried-and-true technology. It also happens to be pretty much the worst
kind of GC for real-time animation purposes (10-40fps per second), as the
GC time is 1. too long (200-2000ms) and 2. increases in time with the
amount of memory _used_ - not the amount of memory that needs garbage
collection.
In jdk1.1, you could get down the instances of GC by increasing heapsize,
turning off the async gc thread by -noasyncgc, and hunting down memory burn
by carefully managing and reusing objects (a real-time heap analyzer such
as OptimizeIt or JProbe is invaluable here).
In the windows version of 1.2, and the reference version on Solaris,
the GC is still pretty much the same, with the exception that you now no
longer can turn off the asyncgc, probably due to the introduction of
Weak References. In addition, the stacksize is dynamically adjusted, meaning
that if you don't use enough of it, it will get returned to the system.
All you have left to do is to try and burn as little memory as possible,
but you are probably going to have a gc run of 200-500ms every few
seconds.
However, all is not lost. The Solaris (SPARC - haven't tried the x86)
production release uses a _much_ better GC, a generational one. It works
by allocating memory on small mini-heaps. After a certain minimum time has
passed and a mini-heap has been filled, it does a GC run _only on the
memory allocated since the last mini-heap was created_. Any memory still
occupied is compacted and a new mini-heap started.
This is _much_ faster than a complete GC - on the U60 (1x360Mhz UII CPU),
such a mini-GC takes only 10-50ms, running every now and then depending on
your memory burn - I've gotten it down to once every 5-10 seconds after
a lot of optimizing. This means loosing one frame on a 40fps animation,
which should be good enough.
If you don't manage to clear the mini-heaps completly, each mini-gc
will eat a little bit of memory, meaning the heap will in the end become
full and required a complete GC, which will take the usual
200-2000 ms. However, if memory burn is carefully managed, this may be
delayed indefinitely, or at least not more often than every few minutes.
On the Solaris production release, it may also be triggered using the
System.gc() call, so you might be able to get it in where it isn't
too visible.
Note here that it may be importent to control memory burn because the
longer between the mini-gc's, the more objects in the mini-heap has the
chance to go out-of-scope and be GC'ed.
This GC - or possibly an even better one - should become available as
part of the HotSpot VM, at least according to the HotSpot white paper.
So, if you are interested in using Java for animation, HotSpot is
pretty much required (unless you are lucky enough to run on Solaris SPARC).
Apart from that, the most importent thing you can do is to control
the memory burn.
/Mats
=====================================================================
To subscribe/unsubscribe, send mail to [EMAIL PROTECTED]
Java 3D Home Page: http://java.sun.com/products/java-media/3D/
