I am really curious about how the JVM works with threads!
In my searches on the internet, I found some material about RTSJ, but I don't know if it's the right directions for my answers.
Can someone give me directions, material, articles or suggestions about the JVM scheduling algorithm?
I am also looking for information about the default configuration of Java threads in the scheduler, like how long does it take for every thread in case of time-slicing.
I appreciate any help, thank you!
There is no single Java Virtual Machine; JVM is a specification, and there are multiple implementations of it, including the OpenJDK version and the Sun version of it, among others. I don't know for certain, but I would guess that any reasonable JVM would simply use the underlying threading mechanism provided by the OS, which would imply POSIX Threads (pthreads) on UNIX (Mac OS X, Linux, etc.) and would imply WIN32 threads on Windows. Typically, those systems use a round-robin strategy by default.
It doesn't. The JVM uses operating system native threads, so the OS does the scheduling, not the JVM.
A while ago I wrote some articles on thread scheduling from the point of view of Java. However, on mainstream platforms, threading behaviour essentially depends on underlying OS threading.
Have a look in particular at my page on what is Java thread priority, which explains how Java's priority levels map to underlying OS threading priorities, and how in practice this makes threads of different priorities behave on Linux vs Windows. A major difference discussed is that under Linux there's more of a relationship between thread priority and the proportion of CPU allocated to a thread, whereas under Windows this isn't directly the case (see the graphs).
I don't have commenting rights so writing is here...
JVM invokes pthreads(generally used threading mechanism,other variants are there) for each corresponding request. But the scheduling here is done entirely by OS acting as host.
But it is a preferred approach and it is possible to schedule these threads by JVM. For example in Jikes RVM there are options to override this approach of OS decision. For example, in it threads are referred as RVMThread and they can be scheduled/manipulated using org.jikesrvm.schedular package classes.
For more reference
Related
While I was going through a book "The Complete Reference Java Ninth Edition", I come to know about a fact related to context switching in java threads.
Following is the excerpt:
In cases where two threads with the same priority are competing for CPU cycles, the
situation is a bit complicated. For operating systems such as Windows, threads of equal
priority are time-sliced automatically in round-robin fashion. For other types of operating
systems, threads of equal priority must voluntarily yield control to their peers. If they don’t,
the other threads will not run.
And a Caution to this :
CAUTION Portability problems can arise from the differences in the way that operating systems
context-switch threads of equal priority
I was wondering if there is any way to avoid the problems related to portability in above cases.
If I test my multithreaded code on windows and deploy it on Unix in production, would I be in trouble ?
Please correct me if my understanding is not perfect.
This text doesn't really say very much. It says "For operating systems such as Windows" but it doesn't specify which operating systems it considers "such as" Windows. I consider the text in the book misleading and not very useful in 2018.
In the earliest versions of Java, it was true that on most Unix-like operating systems, it was using "Green threads" which had this property.
Java has been using native threads on Linux for a very, very long time, so at this time, Linux should be considered "such as Windows" in this sense.
But the Java VM specification and the Java Language specifications do not guarantee pre-emptive threads, so it's still possible to make a JVM that is compliant with the specifications that doesn't have pre-emptive threads at the same priority. I don't know of any JVM implementations that are like that, however.
By the way, you didn't specify what type of "Unix" you were referring to, and you didn't specify which vendor/version of the JVM you were using - to give a 100% correct answer, you need to give that information.
Could someone please provide explanation how Java multi-threaded program (e.g. Tomcat servlet container) is able to use all cores of CPU when JVM is only single process on linux? Is there any good in-depth article that describes the subject in details?
EDIT #1: I'm not looking for advice how to implement multi-threaded program in Java. I'm looking for explanation of how JVM internally manages to use multiple cores on linux/windows while still being single process on the OS.
EDIT #2: The best explanation I managed to find is that Hotspot (Sun/Oracle JVM) implements threads as native threads on Linux using NPTL. So more less each thread in Java is lightweight process (native thread) on Linux. It is clearly visible using ps -eLf command that print outs not only process id (PPID) but also native thread id (LWP).
More details can be also found here:
http://www.velocityreviews.com/forums/t499841-java-5-threads-in-linux.html
Distinguishing between Java threads and OS threads?
EDIT #3: Wikipedia has short but nice entry on NPTL with some further references http://en.wikipedia.org/wiki/Native_POSIX_Thread_Library
The Linux kernel supports threads as first-class citizens. In fact to the kernel a thread isn't much different to a process, except that it shares a address space with another thread/process.
Some old versions of ps even showed a separate process for each thread by default and newer versions can enable this behavior using the -m flag.
The JVM is a single process with many threads. Each thread can be scheduled on a different CPU core. A single process can have many threads.
When Java software running inside the JVM asks for another thread the JVM starts another thread.
That is how the JVM manages to use multiple cores.
If you use the concurrency library and split up your work as much as you can, the JVM should handle the rest.
Take a look at this http://embarcaderos.net/2011/01/23/parallel-processing-and-multi-core-utilization-with-java/
I would start by reading the Concurrency Tutorial.
In particular, it explains the differences (and relationship) between processes and threads.
On the architectures that I'm familiar with, the threads (including JVM-created threads) are managed by the OS. The JVM simply uses the threading facilities provided by the operating system.
As what I know, Java is using operating system threads (in contrast to i.e. Erlang), that means that the threads created with Java on Windows and Linux may behave different.
Are there any differences on Java threads on Windows and Linux? What is the biggest difference? It's maybe only a difference in performance?
This is a very general question, so I'll give a general answer.
Java switched from green threads, to native threads early in its development. This does not mean that threads created on Windows and Linux will behave differently as both platforms will utilize native threads in their respective JVM implementations.
The thread interface exposed to Java by each OS, and similarly the native interfaces to threading via pthreads and Windows threads are very similar.
The biggest differences with respect to threading on the two platforms are that all threads on Linux are a form of process. Windows treats threads and processes very differently.
In my personal experience, native threads on Windows are slightly more lightweight and may perform slightly better within single process applications. Correspondingly (and perhaps irrelevant), are that Windows processes are extremely heavyweight compared with their Linux counterparts.
JVM hide all OS differences to you...
as was previously answered the threads on windows are big heavyweight that linux ones.
by experience a heavy multi threading application could have some delays with automatic memory garbage collector and those can generate huge memory peaks.
I have already used thread in both OS, and no differences for the java developer.
:)
I am really curious about how the JVM works with threads!
In my searches on the internet, I found some material about RTSJ, but I don't know if it's the right directions for my answers.
Can someone give me directions, material, articles or suggestions about the JVM scheduling algorithm?
I am also looking for information about the default configuration of Java threads in the scheduler, like how long does it take for every thread in case of time-slicing.
I appreciate any help, thank you!
There is no single Java Virtual Machine; JVM is a specification, and there are multiple implementations of it, including the OpenJDK version and the Sun version of it, among others. I don't know for certain, but I would guess that any reasonable JVM would simply use the underlying threading mechanism provided by the OS, which would imply POSIX Threads (pthreads) on UNIX (Mac OS X, Linux, etc.) and would imply WIN32 threads on Windows. Typically, those systems use a round-robin strategy by default.
It doesn't. The JVM uses operating system native threads, so the OS does the scheduling, not the JVM.
A while ago I wrote some articles on thread scheduling from the point of view of Java. However, on mainstream platforms, threading behaviour essentially depends on underlying OS threading.
Have a look in particular at my page on what is Java thread priority, which explains how Java's priority levels map to underlying OS threading priorities, and how in practice this makes threads of different priorities behave on Linux vs Windows. A major difference discussed is that under Linux there's more of a relationship between thread priority and the proportion of CPU allocated to a thread, whereas under Windows this isn't directly the case (see the graphs).
I don't have commenting rights so writing is here...
JVM invokes pthreads(generally used threading mechanism,other variants are there) for each corresponding request. But the scheduling here is done entirely by OS acting as host.
But it is a preferred approach and it is possible to schedule these threads by JVM. For example in Jikes RVM there are options to override this approach of OS decision. For example, in it threads are referred as RVMThread and they can be scheduled/manipulated using org.jikesrvm.schedular package classes.
For more reference
When I create a multi-threaded program and I use methods such as Wait or Signal to control threads among other things, does JVM control all the thread state changes or does the underlying OS have anything to do with it.
It depends on the implementation of the JVM. Most modern JVM's (Suns HotSpot, Oracles JRockit, IBM VMs) will use the Operating system threading model as this will give the best performance.
Early implementations used green threads - The VM was modelling the threads using itself. This was typically used when the platform or operating system it was running on didn't support threading. For example, in Java 1.1, Green Threads were used on Solaris. At the time, the common pattern to use multiple cores/CPU's in Solaris was to use multiple processes - only later were threads added to the Operating System.
The Java Language Specification does not specify how Threads must be implemented but in general, if the OS has threading support, modern JVM's will use the OS implementation. When there is no support in the OS, for example on low end mobile phones or in a Java Card implementation for example, then Green Threads will be used by the runtime.
In general, Java threads will map to OS threads and Java will make use of OS synchronisation primitives to implement synchronized/wait/signal/..., but the mapping is not as straightforward as you might think. In fact, the JVM uses some clever tricks to improve performance and implements as much of the synchronisation code itself (at least the uncontended case).
If you are really interested in the details, have a look at the JVM source code or at cmeerw.org/notes/java_sync.html which provides some overview of how Java's synchronisation primitives are implemented on Linux and Solaris.
In the early days of linux 2.4, at least the IBM JVM used separate processes to implement java threads. This resulted in a long time to switch between threads, as the system needed to activate a completely different process each time.