10

I'm running a Java program on my Core i7 laptop which has 8 cores (4 physical, 4 HT). The program uses 8 parallel threads and so it should use up all the CPU. When running with the '-server' parameter, it is at 100% all the time. Without it, it's around 50%-60% overall (always changing with peaks at 100% and dips at 30%). Here's what I find weird: when I run the program in debug and wait for a moment where CPU usage is especially low (30%) and then suspend execution to look at what the eight threads are doing, none of them are in a blocking state. Furthermore, there's are almost no synchronization between them. Here's what I'm wondering:

  1. What's the difference between server and client VM that would prevent the CPU to reach 100% in client?
  2. In the absence of synchronization, what could be keeping a thread from using up a core fully? (probably linked to 1)

Edit: Here's a thought: the code allocates big arrays and leaves them to GC pretty quickly. Does a thread sleep when calling 'new SomethingBig()' and allocating that memory takes time? If there is a single process in the VM handling allocations for a bunch of threads, I guess that could explain why they seem to pause at random, outside of synchronization blocks...

Edit2: I'm pretty sure it is caused by GC now. The CPU reaches 100% again if I give the VM 1500Mb instead of the default 500Mb. I think the slowdown doesn't happen in server mode because it uses more memory by default.

schmop
  • 1,440
  • 1
  • 12
  • 21
  • 2
    try to profile it with this http://www.yourkit.com/java/profiler/index.jsp – titus Feb 15 '13 at 11:30
  • possible duplicate of [Real differences between "java -server" and "java -client"?](http://stackoverflow.com/questions/198577/real-differences-between-java-server-and-java-client) – Perception Feb 15 '13 at 11:31
  • what are the threads doing? CPU work only? i/o operations? – Salvatorelab Feb 15 '13 at 11:31
  • @Perception Nothing in the conclusion of that thread helps me understand what is going on here. Startup time doesn't matter, and neither does speed of execution. I'm solely interested in CPU usage. – schmop Feb 15 '13 at 12:45
  • 1
    @TheBronx CPU work only. – schmop Feb 15 '13 at 12:47
  • If you really want to find out differences between what parameters the VM uses with -server or -client, use there options: -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal -XX:+LogVMOutput -XX:LogFile=jvm.log – Ralf H Feb 15 '13 at 13:58
  • You can get a pretty peek into what the JVM and your threads do by using jvisualvm. You can find the tool in the bin folder of your JDK. Have fun... – pushy Feb 15 '13 at 14:13

2 Answers2

3

Not related to Java specifically, but the number of threads you have should be more than the number of core you have to make best use of your CPU, this is because there are plenty times when a particular thread can not execute, as well as the more obvious waiting on a condition variable held by another thread, threads can be block for other reasons too like a cache miss could require the thread to wait will data is loaded into the cpus cache, it could have to wait for input from some source that is slower than the cpu, virtually memory paging could cause your thread to wait. By have more threads than you have core, when one thread is blocked for what ever reason, another can make use the that core that is freed up. A good initial value is about 1.5 X the number of cores you have.

Nathan Day
  • 5,981
  • 2
  • 24
  • 40
  • 1
    In this the case the threads are mostly unsynchronized. I've tried more threads and there is no difference in CPU usage. And in a general manner, if you have more threads than cores, performance will start decreasing as the CPU will be constantly switching between them, I believe. – schmop Feb 15 '13 at 15:00
2

If you want to monitor what the Java threads are doing, you should not be running the App in the debug mode and suspend it.

Rather, you should collect the thread dumps with kill -3 <pid> in the specific interval where the CPU usage drops.

Related to your second update, you should enable GC logging with time stamps and correlate the slowdowns/CPU usage drops with the times of Young/Full GC collections.

Aleš
  • 8,896
  • 8
  • 62
  • 107