the problem seems to be with “new JitterMatrix()” as i see the same memory growth with the simple example code at the bottom.

intel mbp, osx 10.5.7, max 5.0.8

import com.cycling74.max.*;
import com.cycling74.jitter.*;

public class matrixTest extends MaxObject
 {
	public matrixTest()
	{
		declareIO(1, 1);
	}

	public void jit_matrix(String inname)
	{
		JitterMatrix mat = new JitterMatrix(inname);		

		outlet(0, "jit_matrix", inname);
	}
}

import com.cycling74.max.*;
import com.cycling74.jitter.*;

public class matrixTest extends MaxObject
{

	private JitterMatrix mat; //still works without private

	public matrixTest()
	{
		mat = new JitterMatrix();
		declareIO(1, 1);

	}

	public void jit_matrix(String inname)
	{
		mat.frommatrix(inname);		

		outlet(0, "jit_matrix", inname);
	}
}

Untested, and it has been about six months since I’ve done this exactly, but something like that is what you need.

import com.cycling74.max.*;
import com.cycling74.jitter.*;

public class matrixTest extends MaxObject
{

	private JitterMatrix mat; //still works without private

	public matrixTest()
	{
		mat = new JitterMatrix();
		declareIO(1, 1);

	}

	public void jit_matrix(String inname)
	{
		mat = frommatrix(inname);		

		outlet(0, "jit_matrix", mat.getName());
	}
}

yes, i’m aware of this. but i think it shouldn’t be like that.

Quote:

What you want to do is create your JitterMatrix object once in your constructor, and then just reassign it in your ji_matrix() method.

the frommatrix method is what seems to work correctly – thanks for pointing me to it!
and yes, forget about the outlet call. it isn’t even needed to demonstrate the problem.

i was simply modifying a source file from /examples/jitter-examples/java/. and they all use “new JitterMatrix()” inside the jit_matrix method. which obviously is a bad idea.
someone should definitely correct these examples.

volker.

Makes sense on the Java end and I imagine some sort of fix to the Jitter Java library to avoid this could cause some other problems.

It would be really useful (if anyone with the power to make these changes is watching) to have this pointed out in the documentation, because I didn’t realize this myself until I noticed the memory leak.

Yes! Not only should this be pointed out in the documentation, but those examples really should be fixed. Hopefully that change can get made so others don’t have to find this thread to figure it out (or more likely, not realize the problem, but run into potentially HUGE memory leaks).

I guess I shouldn’t sit around hoping someone notices this thread. I’ll send an email to support linking to this right now so hopefully this will be addressed.

The current workaround would be to do something like what Roth has suggested.

-Ben

The current workaround would be to do something like what Roth has suggested.

-Ben

I did a little searching and found this post from 3 years ago that I now remember looking at this spring when I ran into this problem.

http://www.cycling74.com/forums/index.php?t=msg&goto=75336&rid=4220&S=d002c59b26a677b6db151281208c7d44&srch=garbage#msg_75336

This lead me to believe that this was not a bug, but related to creating Java references to Max C objects causing the reference count to never fall to zero. I don’t claim to be an expert Java programmer, but it seems to me that if the current Max/Java garbage collection issues were documented, it would actually be a feature. Forcing the work around I mentioned would offer some CPU benefit as would not be allocating/deallocating objects at every method call. It may not be much, but as someone who runs into many CPU walls, I’ll do everything I can. I realize fixing this “bug” would not prevent me from continuing to use my workaround, but it seems like a built in way of forcing more efficient style (at least if it were properly documented).

Thoughts?

“You will want to call JitterMatrix.freepeer() to free any C resources which are not handled fast enough by the garbage collector.”

It might be that the GC is not getting triggered on these objects aggressively (since it has no idea about the C memory behind the scenes).

So, in regards to the examples, it may be a case of “do as we say, not as we do”

-Ben