Native Java Threads

Some java VM's have the ability to let the underlying OS handle thread scheduling. On many flavors (all?) of unix, a full blown system process is spawned for each java Thread. Benefits include possibly more robust scheduling, drawbacks include much more overhead involved in spawning threads, and possible ambiguity in scheduling policies (what scheduling method does your kernel use?).

Contrast to GreenJavaThreads ("AKA Lightweight Threads")

-McClainLooney

I think at least Sun's implementations have either used system threads (not full processes) or green threads only. Could someone confirm this? --AndersBengtsson

Very few Unices spawn a "full blown system process" for each Java Thread. I don't see how a JVM could efficiently run in such an environment--are we going to stick the whole blasted application--ByteCode, data, and JVM internals--in a shared memory region? Egads...

Linux uses the clone syscall to spawn threads and processes, but threads are not the same as processes. Rather, when creating a thread with clone, the kernel creates a new processor context but shares the virtual memory and other kernel structures between the new thread and its parent process. Thus the kernel schedules CPU time to the thread like a process but does not switch out virtual memory tables, etc. This is, therefore, exactly the same as in operating systems, such as Windows, in which threads and processes are separate concepts.

Most commercial, "enterprise-class" Unix variants have thread support in the kernel but provide N:M threading to user space, in which the pthreads implementation uses N kernel threads to run M lightweight user-space threads (where M is greater than N).

See: GreenVsNativeThreads