How to measure memory consumption during unit tests?

Question

Hello,
I'm looking for simple tools to automate measurement of overall memory consumption during some memory-sensitive unit tests.
I would like to apply this when running a batch of some test suite targetting tests that exercise memory-sensitive operations.
The intent is, to verify that a modification of code in this area does not introduce regression (raise) of memory consumption.
I would include it in the nightly build, and monitor evolution of summary figure (a-ah, the "userAccount" test suite consumed 615Mb last night, compared to 500Mb the night before... What did we check-in yesterday?)
Running on Win32, the system-level info of memory consumed is known not to be accurate.
Using perfmon is more accurate but it seems an overkill - plus it's difficult to automate, you have to attach it to an existing process...
I've looked in the hprof included in Sun's JDK, but it seems to be targetted at investigating problems rather than discovering them. In particular there isn't a "summary line" of the total memory consumed...
What tools do you use/suggest?

Answer 1

However this requires manual code in my unit test
classes themselves, e.g. in my setUp/tearDown
methods.
I was expecting something more orthogonal to the
tests, that I could activate or not depending on the
purpose of the test.Some IDEs display mmeory usage and execution time for each test/group of tests.
If I don't have another option, OK I'll wire my own
pre/post memory counting, maybe using AOP, and will
activate memory measurement only when needed.If you need to check the memory used, I would do this.
You can do the same thing with AOP. Unless you are using an AOP library, I doubt it is worth additional effort.
Have you actually used your suggestion to automate
memory consumption measurement as part of daily builds?Yes, but I have less than a dozen tests which fail if the memory consumption is significantly different.
I have more test which fail if the execution time is siginificantly different.
Rather than use the setUp()/tearDown() approach, I use the testMethod() as a wrapper for the real test and add the check inside it. This is useful as different test will use different amounts of memory.
Plus, I did not understand your suggestion, can you elaborate?
- I first assumed you meant freeMemory(), which, as
you suggest, is not accurate, since it returns "an
approximation of [available memory]"freeMemory gives the free memory from the total. The total can change so you need to take the total - free as the memory used.
- I re-read it and now assume you do mean
totalMemory(), which unfortunately will grow only
when more memory than the initial heap setting is
needed.more memory is needed when more memory is used. Unless your test uses a significant amount of memory there is no way to measure it reliably. i.e. if a GC is perform during a test, you can have the test appear to use less memory than it consumes.
- Eventually, I may need to inlcude calls to
System.gc() but I seem to remember it is best-effort
only (endless discussion) and may not help accuracy.if you do a System.gc(); followed by a Thread.yield() at the start it can improve things marginally.