Green Thread Model
The green thread is the simplest threading library of JVM scheduled threads. In this model, each thread is an abstraction within the VM. The JVM is completely responsible for its creation and manages the process of context switching within a single process of the operating system. In other words, green threads are the sole property of JVM and its implementation. The underlying operating system has no part to play and can be blissfully unaware of the existence of any thread within the process. The OS sees JVM as a single process and a single thread. Therefore, any thread created by JVM is supposed to be maintained by it only. Green threads hold all the information related to the thread within the thread object itself. This information is included in each thread object, such as stack, to save the context of the caller, a program counter to keep track of the instruction currently executing, and other bookkeeping information. The life cycle of the thread is maintained by the JVM and is responsible also for context switching between multiple threads.
The context switching between multiple threads is done by saving all the state information of the current thread into the stack maintained by the thread object and replacing the information with the state of the target thread. The virtual machine operates on the stack of the target thread. Also, the program counter refers to the instruction of the target thread. The underlying OS neither sees nor maintains the intricacies of the thread. The OS simply views JVM as a single executing thread. The context switching and other intricacies of a green thread happens within the JVM only. These types of threads are very similar to the type of thread called user level thread of the OS because they exist within the user level of the underlying platform. In a nutshell, the characteristics of green threads are as follows:
- Created and managed solely by JVM, without any support from the underlying OS.
- Cannot take advantage of a multi-core system because they are processed singly.
- Due to single thread processing at a time, threads running are easy to synchronize and resource sharing is also simple. Thread execution is fast.
- Operates in the application level and is managed with the user space.
- Also called a many-to-one thread model because one thread is processed at a time.
Green thread was a thing of past. Since version 1.3, JVM is no longer implemented with green threads for any platform.
User vs System-level Thread Overview
Most operating systems operate in two logical parts, called user and system level. Typically, the core system processes execute at the system level and the application processes runs at the user level. The operating system kernel lies at the system level, which is responsible for handling system calls on behalf of the program that runs at user level. The programs that wants to avail the services provided by the operating system must transcend to the system level from the user level. Therefore, the threads that operate at the system level are called system-level threads and the threads that operate on the user level are called user-level threads. The operating system is responsible for the switching of threads between system to user level after it has availed system services. This is done to maintain security by controlling program execution privileges.
Native Thread Model
In the native thread model, the JVM creates and manages Java threads. But it does so using the thread API library of the underlying operating system. Therefore, naturally the implementation varies according to the underlying system. The thread model of the JVM is mapped to the thread library supported by the underlying platform. It typically has the following characteristics:
- Created and managed by the JVM with support from the underlying OS.
- Can take full advantage of the multi-core system because threads are implemented at system level and managed within the kernel space.
- Also called a many-to-many model because multiple threads can execute concurrently.
- Due to multiple concurrent thread execution, thread synchronization and resource sharing becomes complicated. This adversely affects the overall execution time of the thread.
The native threading model of Windows makes a one-to-one mapping between operating system threads and Java threads. For example, the 32-bit Windows provides seven priority levels of thread whereas the Java thread model has support for 11 priority levels. Therefore, while making a one-to-one mapping, some of the priority level gets overlapped. Moreover, the mapping of thread properties is varied among different versions of Windows. As a result, a program with a thread may exhibit slightly varied behavior on JVMs provided by different vendors.
There are no green threads implementation of JVM in the Windows operating system. As a result, all JVM for Windows operate on the Windows thread model.
The JVM implementation for the Linux platform used to support the green thread model prior to Java 1.3. Back then, Linux had no real support for the large concurrent execution of threads. Later, Linux started supporting native the POSIX thread library. This library becomes the basis for the support of the native thread model by JVM implementation and provides a one-to-one mapping between Java and kernel threads.
Scheduling threads is the most complicated affair of the threading model, and with native threads each platform deals with them uniquely. The green threads are scheduled by the JVM itself whereas native threads are scheduled by the operating system which hosts the JVM. Due to the variation of the host operating system, the native thread model is subjected to a number of subtle differences in scheduling Java threads. Although green threads were simple to implement, they totally lack the ability to utilize the underlying resources of the platform.
Oaks, S., & Wong, H. (1999). Java threads. O’Reilly.