> From: "Yazel, David J." <[EMAIL PROTECTED]>
> > How have people dealt with the need to attach and detach branch groups
> > without causing memory issues? I am not detecting any leaking, but I
> > could
> > be missing it. But my memory runtime increases steadily up to 200mb over
> > a
> > 20 minute run. Calling garbage collection might be the solution, but it
> > always causes a long pause, which isn't good.
If the heap is getting larger than the initial heap size then the garbage
collector is being run. If you are using JDK 1.3 the GC pauses are much less
noticable, only showing up for cases where the frame rate is very regular so
that the tiny pause is noticable.
The way to debug this is to use OptimizeIt (www.OptimizeIt.com). You can run
your program under the memory profiler, set a "mark" at the after initialization
and then look for where the new memory is being allocated as the heap size
increases. You may want to force a GC via the tool to clean up the trash. Look
for the objects which have increased the most in count or memory size (click on
the top of the columns, "Diff" or "Size diff", to sort using the values in that
column).
Once you have found objects which are increasing, you need to find out why they
are not being released and garbage collected. Double click on the object name
to go to explore where the objects are being allocated from. If you find
something that looks like it should be getting released, click on the "instances
and reference graphs" button to look at specific instances. This will take you
to a screen where you can look at the references to a specific object. Trace
back the references and look for what is referring to the object. This gets
tricky since you need to distinguish between the objects which should still be
allocated and the objects which should have been GC'd. You may find that the
object is being held in memory because it is still being referred to by Java3D.
If so, try to figure out if that is because you haven't really removed the
object from the scene graph or because Java3D has an error.
Recent releases of Java3D have fixed lots of problems like this, so the
"hanging" reference could be in either your code or Java3D.
As you can tell, this kind of problem can happen easily. Many times a huge
subgraph can be held in memory because a tiny piece of it is being referred to
and the whole thing is held together with bi-directional references.
> > There is in particular one
> > part where I am adding and removing single shapes with single associated
> > branchgroups on a fairly regular basis. These shapes are the same except
> > for the texture and the geomety, all other attributes are the same. Do
> > you
> > think there is merit to creating a new class called
> > ReusableDetachableShape
> > which has a method called Idle() which sets the geometry to null and the
> > texture to null. This sits in a pool which I can pull from when I need to
> > add a new shape, where upon it sets the geometry and the texture and
> > re-attaches it to the scene. This assumes that the constant construction
> > and nulling of the geometry object would not just cause the same problem I
> > have now, but to a lessor degree.
This only makes sense if you are creating and destroying these objects very
frequently. Java3D makes use of free lists internally, but where it makes
sense. In this case, the memory for Shape3Ds is probably not a huge part of
your heap. I suspect the problem is more likely that the geometry and texture
objects (where the real memory usage is) are not being GCd.
> > On a related note, are there currently any leaking bugs? It used to be if
> > a
> > shape shared any attributes with other shapes it was not freed, has this
> > been resolved?
I know that reference bugs have been fixed in each of the previous couple
releases. I don't know if any are currently open.
> > This whole problem seems to be a big issue. The scenegraph really lends
> > itself to fairly static environments. If you need to make changes
> > frequently, seems like there is a fairly stiff penalty.
I'd put it that making frequent changes requires careful coding to prevent
memory bloat. Garbage collection is an improvment over malloc/free, but it
isn't a perfect solution.
Doug Gehringer
Sun Microsystems
===========================================================================
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".
