On 7/31/2010 9:05 PM, Peter Firmstone wrote:
Patricia Shanahan wrote:
In addition to a limit related to the number of runnable tasks, a
TaskManager has a hard limit on the number of threads it will create.
The parameterless constructor has limit 10, and most other uses have
compile time limits in the range of 10 to 15 threads.
com.sun.jini.reggie.RegisrarImpl has a compile time limit of 50 threads.
com.sun.jini.mahalo.TxnManagerImpl creates two pools, settlerpool and
taskpool. The settlerpool has limit 150 threads. The taskpool has
limit 50 threads.
Even 150 threads could be low in a large server, especially if the
threads are used to wait for anything, so that each thread does not
need a hardware thread for a significant fraction of its life.
As noted in the NIO vs. IO discussion that Peter pointed out, the key
to getting good performance simply is to take advantage of the fact
that an idle thread is a cheap, simple way to remember the state of
some activity.
There is one approach that would minimize the number of changes but
increase flexibility. We could redefine the maximum thread count as
being the maximum number of threads per X, where X is a measure of
system size with a minimum of 1, but increasing on large systems.
X could be based on the number of processors, the maximum heap memory,
or some combination.
I'm in favour of this suggestion.
As a further refinement, perhaps we could make the value of X an
optional configuration parameter, and only calculate it from the
processor and memory data if it is not specified. As you have already
pointed out, we don't have effective access to very large systems, so
any setting we do for the largest systems will untested theory.
Patricia
