A bit more info on thread limits.. Linux 2.0 defines NR_TASKS in
/usr/src/linux/include/linux/tasks.h. The default is 512, but then
there's MAX_TASKS_PER_USER which is defined as NR_TASKS/2. So if I
understand right, that means that a Java process using native threads
is limited to 256 threads in the default kernel. It's possible that
boosting NR_TASKS up and recompiling the kernel will Just Work, but I
don't know. I also don't know the implications on kernel memory used
or scheduler performance.
The reason kernels have compiled-in limits like this is it greatly
simplifies and speeds up the scheduler. Dealing with dynamic memory
structures is a mess, particularly if you can't rely on the VM system
in the kernel to manage your memory. Most Unix kernels I know have
similar limits.
Another issue is pre-emptive multitasking. Java does *not* guarantee
pre-emptive multitasking, period. So in some sense, a correct Java
application should not care whether it's green threads or native threads.
Personally, I think it'd be nifty if Java/Linux were higher quality
than other Java implementations, and had nicer threading. The VM to
beat here is Windows NT, at least under Java 1.1.
The problem is, what improvements should one make? It's not clear that
guaranteeing preemption is the best thing, since Java is speced to not
guarantee it itself. Personally, I'd like to see thread creation and
switching time be optimized heavily, and secondarily to make sure that
Java/Linux can deal with a whole lot of threads at once.
Another angle to pursue is to follow what the Java Real Time Extension
people are up to; they will presumably need to augment the Java
threading model, and if Linux can track that we might have a leg up.
[EMAIL PROTECTED]
. . . . . . . . http://www.media.mit.edu/~nelson/
