Question

INITIAL QUESTION:

I have an app that uses ExecutorService to run 4 fixedThreadPool. When I use this architecture the app runs faster on Windows vice a single threaded architecture. But when I ran the ExecutorService architecture in linux my app’s performance was worser than singe threaded app.

The CPU and other hardwares on both the machines are identical. I even tried on different machines and got the same result. I even tried to limit the fixedThreadPool to 3 or 2 and still got slower performance. What could be the variable that I’m missing causing the slowness in linux machines?

ExecutorService execSvc =
     Executors.newFixedThreadPool(NUMBER_OF_PROCESSORS);
Perform perform[] = new Perform[n];
Future<?>[] future = new Future<?>[n];
for(int i=0;i<n;i++)
   future = execSvc.submit(perform[i]);
for(int i=0;i<n;i++)
//To wait until all done
   future[i].get();

Both the OS runs on same machine.
JAVA Version: windows 1.6.0_22, linux Open JDK1.6.0_20

EDIT:

I tried adding -Xincgc on linux and seems like for first few minutes the code runs fast as expected and after that it starts to speed and slow rapidly. Please see that the code chunk I created runs gazillion times in my app and can this indicate that the JVM GC behaves differently in different OS?

AFTER TRIALS:

After trying with 4 different linux machines it looks like the openJDK is causing issue. I shouldn’t have installed openJDK in the first place but thanks to @Alfabravo for pointing it out.

Answer 1

About the only thing I can think of is the at the memory settings are somehow different on the two systems and that you are running out of memory earlier in Linux-land. Here as some things to try:

• Increase the memory settings under Linux (duh). -Xmx1G or something

• Assign each future to null after you reap it. This may have little effect but might be worth it to help the GC out.

  for(int i = 0; i < n; i++) {
     future[i].get();
     future[i] = null;
  }
  

• Don’t store the Perform objects in an array. Just submit them and forget about them. If you still need them then return them in the Future<Perform> and then set them to null when you are done with them.
• The best win might be to not submit all of the jobs at once but keep 100 outstanding or something. Turn the Future array into a list and reap the onces that isDone() or isCancelled() and only submit to the pool if the size of the list is below some threshold. You’ll need a sleep to not spin. I actually did this recently so here is some sample code: http://pastebin.com/3TkkxGYT

Another thing to consider is that if your Perform tasks are very small then you may be just testing the context switching of the OS more than anything else. But I wouldn’t think it would slow down over time on its own.