next »

[ChrisE]

Marvin,

Context
So, I've got a large scene graph, with some depth in the tree but a *lot* of leaf nodes--in order to get good transparency, I'm giving each triangle in a sphere its own Shape3D (yes, this is wrong; no, it isn't permanent). I have a lot of nested spheres. This is intended just to illustrate the problem context.

Problem
The problem comes when I want to clean up the renderer. I use it in a sort of time-sharing method, so I frequently remove the entire scene and put other things into it.

Several of cycles of this will result in an OutOfMemory exception.

Investigation
Examining the heap with Jhat shows me that extra copies of Shape3D and Point3f, along with SceneGraphOpenGLReferences, BoundingSphere, and so on, are being held. Several objects without references at a higher level are also being held.

Interestingly enough, if I call System.GC after every scene freeing operation--and yes, not something I would do outside of troubuleshooting--I notice that the memory is reclaimed, and the bogus objects go away. This tells me that we aren't outright leaking memory, but that only the presumably more aggressive system GC can catch whatever is happening.

Theory

Examining the code, I see that a lot of the objects keep references to themselves, their parents, their children, etc., and so are probably hard to garbage collect incrementally.

Xith seems to have its own way of trying to handle memory management, and this doesn't quite seem to be working.

Question
Is there a way to force Xith to remove all of its scenegraphs, branchgroups, nodes, resources, soups, and whatever else it might have allocated (without actually shutting it down and bringing it back up again)?

Is there a way of being sure to completely free a node and its children?

Thanks!
-Chris

[Marvin Fröhlich]

I don't know, where these extra copies of Shape3D and Point3f could come from. Shape3Ds are never auto-created. They will always come from your code.

SceneGraphOpenGLReference objects are used to maintain the connection between the renderer and the scenegraph. Whenever a scenegraph object is GCed and its finalize() method is called, it's OpenGL reference is cleaned up wit hthe next render frame. This mechanism is not designed to be invoked by client code. As long as you keep the same instances af the whole graphs, you should be fine. Do you recreate parts of the graphs any time you add them back to the scenegraph?

[ChrisE]

Thanks for the reply; let me try to give a little more detail.

I'm not claiming that Shape3Ds are auto-created--didn't mean to give that impression. What happens is that my client code (I consider Xith sort of a server) creates geometry and registers it with the renderer (i.e., says "Here are the triangles, and here is who they should be parented to in the scenegraph.").

The issue is that I'll occasionally need to clear out the scenegraph, and when I do so objects often hang around for a long period of time, causing memory to balloon up. Is there a way of making sure objects that are no longer live (i.e., removeAllChildren()'ed and/or detach()'ed away) are garbage collected other than by calling System.GC?

[Marvin Fröhlich]

The garbage collector is able to collect objects, that have no other references than to each others. Though sometimes the GC doesn't behave as I'd expect.

Could you please try to detach all the parent/child dependencies of a detached sub graph? If this helps, we know more and can handle it.

Marvin

[ChrisE]

Marvin,

I added a ScheduledOp that wanders down the tree recursively and (leaf-node first) removes the nodes (it uses removeChild, so both directions are accounted for, I believe). This doesn't seem to help.

-Chris

EDIT: One more thing... this seems to be a direct function of the scene graph size; grouping the triangles together into single Shape3Ds gets rid of most of the memory usage.

[Marvin Fröhlich]

A Geometry uses DirectByteBuffers to hold the geometry data. I guess, this gets expensive, if you use one buffer for each triangle. This might explain it.

[ChrisE]

Another possible theory is the use of Finalize() in Geometry, and nio float buffer objects. I'm not super-tenured in Java, so is this also a possibility? The Sun docs (A.3.6 http://java.sun.com/docs/books/performance/1st_edition/html/JPAppGC.fm.html) mentioned that finalizers can postpone the GC.