using all CPUs available with multiple threads ...

[Giovanni Azua]

Hello all,

I have rewritten a lengthy process to split
the long running job into several threads
2*CPU_count:

"2*(Runtime.getRuntime().availableProcessors())"

In Windows W2K and 2003 Server all of the CPUs (4 physical)
are used, so it really parallelize nicely but on Solaris does
not use more than one physical CPU, the second CPU remains
always idle.

Is there any way to ensure maximal usage of the physical CPUs
from Java? or is it something I must tweak on the specific OS?

TIA,
Best Regards,
Giovanni

 

[John C. Bollinger]

Hello all,

I have rewritten a lengthy process to split
the long running job into several threads
2*CPU_count:

"2*(Runtime.getRuntime().availableProcessors())"

In Windows W2K and 2003 Server all of the CPUs (4 physical)
are used, so it really parallelize nicely but on Solaris does
not use more than one physical CPU, the second CPU remains
always idle.

Is there any way to ensure maximal usage of the physical CPUs
from Java? or is it something I must tweak on the specific OS?

Java threads are assigned to CPUs at the discretion of the VM. There is
no way you can control it via Java, but there may be command-line
options that you can pass to the VM to alter its behavior, or you may be
able to use a different VM that behaves more as you want.

Assuming that you are using the Sun VM, have you tried the server
version (i.e. pass the -server option to java at startup)?

 

[Kevin McMurtrie]

Hello all,

I have rewritten a lengthy process to split
the long running job into several threads
2*CPU_count:

"2*(Runtime.getRuntime().availableProcessors())"

In Windows W2K and 2003 Server all of the CPUs (4 physical)
are used, so it really parallelize nicely but on Solaris does
not use more than one physical CPU, the second CPU remains
always idle.

Is there any way to ensure maximal usage of the physical CPUs
from Java? or is it something I must tweak on the specific OS?

TIA,
Best Regards,
Giovanni

How old is the Solaris setup? Systems from a few years ago needed heaps
of patches to enable native threading. Back then, "red threads" were
native and "green threads" were JVM managed. It might even have an
obsolete config file specifying green threads.

You could also have a weird race condition in your code. Block a busy
thread in a debugger and see of the others can continue processing.

Still another possibility is that the HotSpot compiler is running extra
slow for SPARC. CPU usage can be very sporadic until the major code
hotspots are compiled. It can be several minutes for a large app.
(Don't use the secret JVM parameter to add compiler threads. The
compiler isn't thread safe!)


I've used Java 1.4 on big Solaris, MacOS X, and Linux boxes. They all
thread very nicely.