Thread Test on HotSpot 1.4 and JRockit 7.0

JVM Tutorials - Herong's Tutorial Examples

∟Thread Test on HotSpot 1.4 and JRockit 7.0

This section provides a tutorial example to see how many running threads can be supported on HotSpot 1.4.0_02 Client/Server and JRockit 7.0 JVMs.

An old version program was used in 2002 to perform a similar test on JRockit 7.0, HotSpot 1.4.0_02 Client and Server JVMs in 2002:

/* CrashThread.java
 * Copyright (c) HerongYang.com. All Rights Reserved.
 */
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);
   }
}

Output on JRockit 7.0:

10:28:21 AM Launched thread 1
......
10:28:22 AM Launched thread 16

Output on HotSpot Client 1.4.0_02:

10:30:06 AM Launched thread 1
......
10:30:09 AM Launched thread 16

Output on HotSpot Server 1.4.0_02:

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:

On JRockit 7.0: After launched 32 threads, the system was getting very sluggish. The mouse pointer was 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.
On HotSpot 1.4.0_02 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 even 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 someone verify this on a UNIX system?