views:

152

answers:

2

I have a large scene graph in Java 3D consisting out of a Group which contains around 3500 Switches, each containing a Shape3D and a Group, the latter contains two more Shape3Ds.

The reason for this setup is that each of the 3500 Switches must be able to be either completely hidden or have either of its two children visible.

The problem occurs when I try to modify the geometry of the two Shape3Ds in the Group in a Switch. I have attempted the following:

  • Change Group to BranchGroup. When the geometry needs to be changed I detach the BranchGroup and create a new one, with updated geometry, to replace it. Leaks huge amounts of memory. For example, the initial memory usage will be around 100 MB. A change in geometry later it is around 400 MB.

  • Make the Geometry editable. When the geometry needs to be changed I edit it directly. Leaks huge amounts of memory. Similar to above.

  • Make the Geometry editable, but by reference. When the geometry needs to be changed I call updateData(...) with an appropriate GeometryUpdater, which then does its thing. Leaks memory.

  • Recreate the entire scene graph. When the geometry needs to be changed, I detach the entire scene graph, recreate it from scratch using the updated geometry, and attach the new scene graph. Leaks memory.

I can't help but feel there is something basic about Java 3D memory management that I'm missing and that is common to all my attempts.

The speed of changing the geometry is not an issue, as it is a rare occurence. The memory problem, however, is serious.

+2  A: 

It's usually misleading to use tools that monitor memory at the operating system level to deduce memory leaks in a Java Virtual Machine. The JVM has its own ideas on when it is efficient to claim and reclaim memory.

If you could explain how you are observing the memory leak and why it is a serious problem then it might be easier to answer your question.

  • How are you measuring memory usage?
  • If you force a garbage collection and output the memory usage do you still see the leak?
  • Does the memory problem cause a java.lang.OutOfMemoryError ?

You might also be interested in this question: http://stackoverflow.com/questions/1716597/java-memory-leak-detection-tools

richj
To answer your questions: I'm looking at java's memory usage in the OS, reporting it using Runtime and having a closer look using TPTP; yes, after forcing -- or rather, suggesting to the VM -- a garbage collection, memory usage stays roughly equal; and yes, given enough consecutive changes to the geometry, a java.lang.OutOfMemoryError will be thrown.
Toon Van Acker
Do you have any behavior nodes? If you do, could these be holding on to memory?
richj
I was also wondering if the nodes are cloned as duplicates or by reference.
richj
If you are compiling your BranchGroups: "BranchGroup.compile() creates and caches a newly compiled scene graph." I'm not sure if the "caches" is significant. I can't find any detail on the cache, or any mention of how to clear the cache.
richj
I haven't quite gotten there yet, but it does seem related to compiling. Although, of course, not compiling isn't really an option as the performance of the scene goes to hell.
Toon Van Acker
+1  A: 

Attach to your program with visualvm (available as jvisualvm binary in the JDK), and use the profiler to get an idea where your memory goes.

Thorbjørn Ravn Andersen