This section describes a thread testing programs and test results with HotSpot Client VM and HotSpot Server VM.
To find out the maximum number of threads we can run, I wrote the following
program:
/**
* CrashThread.java
* Copyright (c) 2002 by Dr. Herong Yang, herongyang.com
*/
import java.util.*;
import java.text.*;
class CrashThread extends Thread {
public static void main(String[] a) {
Thread t;
int m = 16;
Date now;
DateFormat df = DateFormat.getTimeInstance();
for (int n=1; n<=m; n++) {
now = new Date();
t = new CrashThread();
t.start();
System.out.println(df.format(now) + " Launched thread "+n);
}
}
public void run() {
while (true);
}
}
The program is a simple thread with infinite while loop in the run() method.
The main() method is included in the thread to avoid writing another class
to launch the thread repeatedly. The program was compiled with J2SDK 1.4.0_02,
and executed with the same memory options: -Xms2m -Xmx64m.
Output on JRockit JVM:
10:28:21 AM Launched thread 1
......
10:28:22 AM Launched thread 16
Output on HotSpot Client:
10:30:06 AM Launched thread 1
......
10:30:09 AM Launched thread 16
Output on HotSpot Server:
10:31:56 AM Launched thread 1
......
10:31:58 AM Launched thread 16
As you can see, all 3 JVMs had no problems launching 16 threads, and kept them
running. Note that all threads are user threads by default. They continue to
run even after the calling threads has been terminated.
When I increase the number of threads to 32, the executions were getting interesting:
JRockit JVM: After launched 32 threads, the system was getting very sluggish. The
mouse pointer were very much alive, but any mouse click would take about 30 seconds for the
system to respond. I was able to end the JVM process by the system task manager.
HotSpot Client and Server: After launched 32 threads, the system basically got jammed.
Only the mouse pointer can be moved around. No response to any mouse clicks. I had to
turn off the power to restart the system.
I guess the problem was in the operating system (Windows 2000). It failed to treat
the running JVM process as one single process event it had 32 threads running inside.
The operating system should be able to put the JVM process in wait mode when its
CPU time share is used up, and process my mouse clicks before returning back to
the JVM process. Could some one verify this on a UNIX system?
