Maximum number of threads

Question

I have an application for which I am interested in obtaining as many simultaneous
threads as possble (e.g. 10's and possibly 100's of thousands of threads).
More specifically I have developed a simulation language formalism in which the
dynamics of each "entity" moving through a network of queues is coordinated by
a separate thread of execution.
This is not a traditional application where all or even some small number are
intended to run concurrently. A single executive thread is responsible for alternately
activating and deactivating individual threads to reflect the time ordered sequencing
of events corresponding to each entity's movement through the system of queues.
As a result, only a single thread is executing at one time.
Using a separate thread for each entity off-loads the task of managing each's
execution context to the JVM. The resource contention issues that arise in a
standard multi-threaded application don't apply here.
For "large" systems though (ones populated by many entities simultaneously) I
need many threads.
I'm using JRockit's thin thread model on a Windows XP machine and am "only" able
to get approximately 25000 threads at which point the JVM hangs with no diagnostic.
I say "only" because at that point there seems to be plenty of heap space left
as well as Page File space left in the XP's Virtual Memory system.
I'm using the following JVM command line:
java -Xthinthreads -Xss32K -Xms256M -Xmx256M -Xallocationtype:global
Surprisingly, by altering the heap size upward from 256MB to 512MB acutally causes
the VM to hang with fewer threads (only 20000 or so)
Using allicationtype:global and altering the stack size of the threads seems to
have little effect on the maximum number attainable.
It seems the maximum number of threads attaible should be a function of the size
of the heap space, and the amount of physical and virtual memory limits on the
system.
My empirical evidence, however, seems to indicate there is some internal VM limit.
Can someone explain for me the implementation of the thin thread model and its
limitations w.r.t. the number of threads it can support?
Thanks in advance for you help.

Answer 1

You might try to use the new java.util.concurrent.* api available in j2se
1.5.0 as
a base for your implementation instead.
/Robert
"Staffan Larsen" <[email protected]> wrote in message
news:40f63c6b$1@mktnews1...
The reason for the "artifical" limitation of 32767 is that each thread
needs to have it's own id. The way the object synchonization algorithm
works, there has to be space for this id in the header of each object.
The header has a very limited amount of space (currently 2 words) and
thus there is not space for a larger thread id than 32767.
You may be interested (but sad) to know that the thinthreads model has
been removed from later versions of JRockit. The reason was the overhead
of maintaining and supporting multiple threading systems was just too
much work for a small return. Although, for very specialized systems
(like yours) it would give a higher return.
About your calculation. You said in you first post that you set -Xss32k
which means that each thread will take at least 32k memory, more likey
40k with other overhead. That means about 25 threads per MB or 25000 per
GB, given that everything scales linearly.
Regards,
/Staffan
Kevin Healy wrote:
Staffan,
Thanks for your response. Certainly in a traditional multi-threaded
applications
where there exist many runnable threads competing for resources, thepoint of
diminishing returns is usually on the order of 10's of threads; but, asI mentioned,
this is not a traditional application. In this case, the threadingframework
is used as a natural and convenient way to manage the execution contextof the
(many) entities in the system. Since I'm not interested in trueconcurrency or
exploiting parallelism, I view threads as just data and it strikes methat I should
be able to get as many as I have room for. In fact the green threadsmodel of
the pre JDK 1.4 JVM's was well-suited to this kind of application but itseems
the JVM implementors have not considered this in removing support forgreen threads
in their newest releases. The thin threads model of JRockit is the nextbest
thing but the 32767 limit seems entirely artificial.
Do you know of any way to bump up that limitation or who I might contactat BEA
about the matter?
I'm aware that stack space and other context specific data must beallocated for
each thread so let's say for the sake of argument that each thread takes10KB
of data. That means I get 100 threads per 1MB and it would take 1GB toget my
100,000 threads. That is not an unusually large amount of data ontoday's desktop
computer. Furthermore, with the advent of 64bit computing on thedesktop, we'll
see machines supporting much more than 4GB.
Staffan Larsen <[email protected]> wrote:
First: which version of JRockit is this with?
With thinthreads the limit is 32767 threads. But you may run into other
limits before that. When you increase the heapsize you "steal" memory
from the system (which would otherwise be used for stacks and other data
structures) and that is why you can run fewer threads with a larger
heap.
>>>
I don't think it is realistic to run 100's of thousands of threads in
one single system.
Regards,
/Staffan
Kevin Healy wrote:
I have an application for which I am interested in obtaining as manysimultaneous
threads as possble (e.g. 10's and possibly 100's of thousands of
threads).
>>>>
More specifically I have developed a simulation language formalismin which the
dynamics of each "entity" moving through a network of queues is
coordinated
>>>
by
a separate thread of execution.
This is not a traditional application where all or even some smallnumber are
intended to run concurrently. A single executive thread is responsiblefor alternately
activating and deactivating individual threads to reflect the timeordered sequencing
of events corresponding to each entity's movement through the systemof queues.
As a result, only a single thread is executing at one time.
Using a separate thread for each entity off-loads the task of managingeach's
execution context to the JVM. The resource contention issues thatarise in a
standard multi-threaded application don't apply here.
For "large" systems though (ones populated by many entities
simultaneously)
>>>
I
need many threads.
I'm using JRockit's thin thread model on a Windows XP machine and am"only" able
to get approximately 25000 threads at which point the JVM hangs withno diagnostic.
I say "only" because at that point there seems to be plenty of heapspace left
as well as Page File space left in the XP's Virtual Memory system.
I'm using the following JVM command line:
java -Xthinthreads -Xss32K -Xms256M -Xmx256M -Xallocationtype:global
Surprisingly, by altering the heap size upward from 256MB to 512MBacutally causes
the VM to hang with fewer threads (only 20000 or so)
Using allicationtype:global and altering the stack size of the threadsseems to
have little effect on the maximum number attainable.
It seems the maximum number of threads attaible should be a functionof the size
of the heap space, and the amount of physical and virtual memory limitson the
system.
My empirical evidence, however, seems to indicate there is some
internal
>>>
VM limit.
Can someone explain for me the implementation of the thin thread modeland its
limitations w.r.t. the number of threads it can support?
Thanks in advance for you help.