Major memory leak in TransformShader

Engines, Libraries and Tools Xith3D Forums
#1

For some reason, TransformShader.TransformStateMap is leaking memory. When running one of simple tests with rotating cube, StateMap is fed with transforms, which is ok, but it never get cleaned up. Every frame, few objects get stuck there forever.

As far as I understand, StateMap tries to find StateNode for given transform. As it is not possible when transform has changed in any way, new StateNode is added - and never removed. Of course, with StateNode there is a stale reference to Transform3D, which in turn has a reference to matrix or two… While memory hit is not so bad (but it sums up quite quickly, something like 1MB per minute), I’m afraid that tree performance will get down after some time.

BTW, is there any particular reason to keep Transform nodes in TreeMap ? Do they have to be sorted in this order (seems more or less arbitrary, it is not a distance from viewpoint or something which could be used later) ? I’m afraid, that with more nodes, time used for sorting/checking it will start to take a lot of time.

#2

Good catch. I will see what I can do to clean that up.

#3

This is causing huge memory leaks. I did a very simple application that constantly rotates and moves 100 cubes on the screen. It hogs up the memory usage roughly 3 megabytes per second up to a certain point after java gives out of memory error. I am using Xith3d straight from the CVS.

This is directly related to com.xith3d.scenegraph.setTransform(Transform3D t). The more I call it, the more mem is wasted. I understand abies described exactly the same problem, only better. Same kind of problem lies also on this thread: http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=xith3d;action=display;num=1067755266
(Topic: Argh, memory leak stabs self in the face)

Is there any way to go around this problem, or should I patiently wait for the Xith3d experts to fix this problem?

Ps. Thanks for a great 3d library, nice work everyone.

#4

I’m seeming this issue aswell, at least I think I am :slight_smile:

Kev

#5

I just made a short test: I rotate a model around for quite a long time (half an hour?). The FPS rate went down and the app stopped to work at all (without an error message).

#6

Any news on the memory leak fix for setTransform()?

Kev

#7

Thanks for the reminder, I will put this on top of the list.

#8

Further to this, I got a little bogged down with the problem since it was causing me no end of slow down, and so …

It seems to be caused by the generation of loads and loads of StateNodes, all based around Transform3Ds. Now I don’t really understand what all this stuff is for. However, I also get a tonne of TreeMap entries showing up on the profile.

I had a look round the code and it seems to be a problem with the StateMap. Now, I can’t really tell the implications of the follow but it did at least seem to fix the problem without breaking any of my rendering…

Anyway, introduction over, here’s the change I made, thought it might help in finding the real problem…


    void assignState( StateTrackable trackable ) {

        StateNode sn = trackable.getStateNode();
        // Commenting out null check will enforce existing StateNode lookup on every shader creation, but this is
        // not a high performance impact because of the atom/shader caching handled now on higher level,
        // and we have to get new (or existing) id on change made
//        if (sn == null) {
            StateNode existing = (StateNode)states.get(trackable);
            if (existing != null) {
                trackable.setStateNode(existing);
            } else {
                sn = new StateNode(trackable);
                sn.id = nextId++;
                
                // took this out and replaced it with the line below, since first it
                // naively seems more logical but also seems to prevent the Transform3D
                // being reproduced over and over
                //states.put(sn.masterCopy,sn);
                states.put(trackable,sn);
                
                trackable.setStateNode(sn);
            }
//        }

    }

Apologies if this turns out to be a red herring so to speak.

Kev

#9

While that looks like it would work, it would actually cause some serious problems. Lets say you have Material A and Material B and they have exactly the same properties. They would be mapped to the same state. Now you update Material B. This would update the state, but Material A is mapped to that state, so it gets changed also.

I have solved the trabform leaking problem a different way, the same way I do it with textures, which is to assume that each instance of a transform is unique. This means that if you had two transforms which were actually the same values we would still change state, but that is probably pretty rare.

#10

Fantastic! ;D

Was wondering if I was being a little naive about the whole thing, hence the babbling above.

Is the change available yet?

Kev

#11

yep it is committed.

#12

Good work! At least it fixed my application problems.

Now I can share my Xith3d physics demo (it uses Open Dynamics Engine).