Some background on this problem. Dynamicsoft tried 1.4.1 with
>4000 threads (they're now trying 10,000) and needed to
reduce the Java thread stack size to accomplish this.
Unfortunately, this caused a stack overflow in a ParNewGC
thread because ThreadStackSize is used to set the stack size
for all threads except C2's compiler threads. The threads
affected are:
   vm, cms, parallel scavenge, ParNewGC, C1 compiler thread

-XX:ThreadStackSize=<int> modifies the thread
stack sizes of nearly all threads (all except C2),
and that VMThreadStackSize must be used to re-adjust them.

This happens because the following is executed first
in os:create_thread()

  if (stack_size == 0) {
    stack_size = JavaThread::stack_size_at_create();
  }

  . stack_size is a parameter of create_thread() that defaults to zero
  . stack_size_at_create() essentially returns the value of flag:
    ThreadStackSize, possibly extended by some guard pages.

This is clunky, and probably wrong. A google search shows that
the user community knows about ThreadStackSize, but not about
VMThreadStackSize. So before Dynamicsoft can be told about
VMThreadStackSize it will need to be sent to the CCC to be made
private since it's currently internal.

The vm-ish threads should have their own default size.

Currently, the stack sizes are:

           ThreadSS VMThreadSS CompilerThreadSS default_stack_size
 
SPARC 32 512K 0 C2:2048K C1:0 not used
SPARC 64 1024K 0 C2:2048K C1:0 not used
Solaris i486 256K 0 C2:2048K C1:0 not used

Linux i486 0 0 0 512K
Linux ia64 0 0 0 1024K
      
Win32 i486 0 0 0 ASSERTs:1024K 0
Win32 ia64 0 0 0 ASSERTs:1024K 0

Notes:
  1) 0 for VMThreadSS and CompilerThreadSS implies
     use of ThreadSS value

  2) 0 for ThreadSS implies use of default_stack_size