4

I have noticed that executing large mostly Junit 3.x test suites, causes Eclipse to shititself and lockup. Even when i allocate a lot of heap and perm gen (1200m and 400m) it hums along and then just freezes and then continues, taking quite some time. If i run the tests in small batches then things are fairly quick and the freezes pretty much never happen.

I have checked the memory usage while the tests run and they are no where near the maximum for either the given max heap or perm, so those should not be a problem...

Does anyone have tips on how to get around this.

mP.
  • 18,002
  • 10
  • 71
  • 105
  • 1
    Did you tried first this `eclipse.ini`? http://stackoverflow.com/questions/142357/what-are-the-best-jvm-settings-for-eclipse/3275659#3275659 – VonC Feb 01 '11 at 14:29
  • Yes i have stated the values of what are obvious causes not enough heap and perm gen. They are large enough... – mP. Feb 04 '11 at 21:52
  • @mP: but the `eclipse.ini` I mentioned is not about just heap and perm gen size. It is the exact combination of options that makes Eclipse runs smoothly on our workstations. – VonC Feb 15 '11 at 04:55
  • Are the test cases writing a lot log messages to the console view? You may want to reduce the logging to only display failures then re-run only the failed test with logging level increased to view the detailed log for debugging. – blissfool Feb 15 '11 at 22:45
  • Theres v little logging. Eclipse isnt freezing because of dozens and dozens of text hitting the console. – mP. Feb 16 '11 at 00:04
  • Dump the stack of eclipse itself to see what happened. kill -3 to dump stacktrace of eclipse on linux – Kane Feb 16 '11 at 05:35

3 Answers3

3

This might already be something you tried but ... if you are running your unit tests as "JUnit plug-in tests" ... then your settings for Xmx and MaxPermSize in eclispe.ini are useless.

eclipse.ini settings allow you to change the settings for your current Eclipse. Any Eclipse instance spawned from this Eclipse will still have the defaults settings (something like Xms40m and Xmx512m). You also have to change these.

Open the launch configuration you use for your tests ("Run > Run Configurations...", select the one you use to launch your unit tests) and go to the "Arguments" tab. There, in the "VM Arguments" text area, input your new memory settings as you did in the eclipse.ini file (I use -Xms256m -Xmx1536m -XX:MaxPermSize=256m for my most expensive test suites ... but you might need more).

The main issue though might be to try and fix the potential memory leaks of your unit tests. Are you sure you don't have more unloading/memory freeing/... in the tearDown()? Running your tests under profiling might help (we use Yourkit java profiler to this end where I work... but it isn't free. JConsole might help you there, see also http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html).

Kellindil
  • 4,523
  • 21
  • 20
  • They are not running as plugin tests and yes the settings mentioned in the q are the VM settings used for the JUNIT test launcher itself. – mP. Feb 17 '11 at 13:08
  • Then all I can think about is either a memory leak (which would simply fill in your heap whatever your settings) or a dead lock. I can only recommend you to profile your unit tests to see which objects eat your whole memory, or to launch it in debug mode and "pause" the whole thing after a while to try and determine whether there is a deadlock happening at some place. – Kellindil Feb 17 '11 at 13:14
0

Not allowed to comment and hence Adding it here.. you have checked the memory, hence that option is closed

Few other things to try:

I am not sure, if you tried playing with the fork options on junit.

Is it rebuilding the target classes again and again? Can you watch the target folder?

Did you try recreating the workspace? Just suggesting this because you seem to have covered the main issues - memory, logging etc..

luckylak
  • 279
  • 3
  • 13
  • Recreating workspace -yes. Id rather avoid running junit via ant to use fork that would slow things even more while probably avoiding the freezing. – mP. Feb 17 '11 at 09:57
0

There may be some kind of memory leak in your program that only appears if you run all the tests. You haven't mentioned if you get the same problems if you run your tests externally.

I would recommend running some kind of memory analyzer around the time of the freeze-up. Something like MAT http://www.eclipse.org/mat/ has helped me in the past. You could also try running multiple sessions of jstack to get an idea of what is happening over time.

Andrew Eisenberg
  • 28,387
  • 9
  • 92
  • 148