Matthew Hussey created JMOCK-262:
------------------------------------
Summary: Memory is getting leaked when using Action calls that are repeated many times
Key: JMOCK-262
URL:
https://jira.codehaus.org/browse/JMOCK-262 Project: jMock
Issue Type: Bug
Components: JMock 2.x.x Library
Affects Versions: 2.5.1
Environment: Windows 7, Eclipse. Java 1.7, JMock 2.6.0RC2 and JMock2.5.1
Reporter: Matthew Hussey
I was using mock objects to mock functions that are called many times so I could compare the functionality of two classes I had developed but kept getting OutOfMemory: GC Overhead Limit Exceeded or just OutOfMemory. I was using custom actions and after doing a heap dump I noticed that there were millions of Invocation instances along with the instances of the parameters they were holding. I've not prepared a version that doesn't use custom actions to prove the problem.
I am well aware that this code isn't how mocks are supposed to be used but I just wanted to invoke multiple mocked Action calls to highlight the issue. Anyway, commenting out the CONCRETE section causes an OutOfMemory exception, while commenting out the MOCK section allows the function to run perfectly, but isn't using JMock.
I am running using -Xmx128m to try and force the problem to occur earlier.
While typing this, I think I'm coming to the conclusion that this is a side-effect of holding onto the previous invocations so that the trace can contain all the invocations if there is any call that breaks the expectations. This means that the memory leak is by design rather than a bug but I think it's best to report it anyway.
I guess it would be nice to be able to disable the storing of the invocations if all that is needed is the mock functionality and asserts.
I'm kind of babbling now so I'll stop now.
/**
*
*/
package jMockMemoryTest;
import org.jmock.Expectations;
import org.jmock.Mockery;
/**
* @author matt
*
*/
public class JMockMemoryTest {
private interface SomethingMocked {
boolean isItEven(int num);
}
private final SomethingMocked sm;
public JMockMemoryTest(SomethingMocked sm) {
this.sm = sm;
}
int sumOfAllEvens(int limit) {
int total = 0;
for(int i = 0; i != limit; ++i) {
if(sm.isItEven(i)) {
++total;
}
}
return total;
}
private static class SomethingConcrete implements SomethingMocked {
@Override
public boolean isItEven(int num) {
return true;
}
}
/**
* @param args
*/
public static void main(String[] args) {
Mockery context = new Mockery();
// CONCRETE BEGIN
/*
final SomethingMocked mock = new SomethingConcrete();
*/
// CONCRETE END
// MOCK BEGIN
final SomethingMocked mock = context.mock(SomethingMocked.class);
context.checking(new Expectations() {
{
allowing(mock).isItEven(with(any(Integer.class))); will(returnValue(true));
}
});
// MOCK END
JMockMemoryTest jmmt = new JMockMemoryTest(mock);
for(int limit = 0; limit != 100000; ++limit) {
System.out.println(jmmt.sumOfAllEvens(limit));
}
}
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspaFor more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Some parts of this message have been removed.
Learn more about Nabble's security policy.
An interesting use of the framework
I fear this has to count as a won't fix, because much of the motivation of jMock is to consider how objects interact and provide a useful message when there's a problem. You might want to consider poking around a level below the Expectations() object to see if you could use the pieces to assemble something closer to what you need. It shouldn't be too hard.