How JVM thread scheduler control threads for multiprocessors?
JVM use underlying OS(Unix, Windows etc) threading mechanism to schedule java thread on multiprocessor system.
As the others answered correctly, JVM uses the underlying OS (Windows 10 in my case) to manage threads. The windows OS will do pre-emptive (priority-based) scheduling. If there exists multiple threads with Highest priority, windows will use round-robin based time-slicing scheduling for the threads.
( Reference:- https://docs.microsoft.com/en-us/windows/win32/procthread/scheduling-priorities )
To answer the specific question about the multi-processor systems (windows again here as OS), it depends on the architecture such a system is using. Typically there are 2 types of architecture
- NUMA - Non Uniform Memory Access
- SMP - Symmetric Multi-Processing
In case of NUMA, the thread is assigned to a processor which is closer (physically) to the memory being used. Because, that way the memory access is faster.
However, in an SMP computer, two or more identical processors or cores connect to a single shared main memory. Essentially, it is like running things on a single integrated processor. Here, we cannot guarantee which processor the thread will be assigned to.
You can also specify a thread to execute on a particular processor by setting the "ThreadAffinity" or the "Thread Ideal Processor" property.
( Reference:- https://docs.microsoft.com/en-us/windows/win32/procthread/multiple-processors ).
Hope this helps !! Cheers !!
The term “JVM thread scheduler” makes only sense, if we consider operating system, JVM and class library as an execution environment as a whole. Then, it’s guaranteed that this environment has a scheduler, regardless of how it is implemented.
In most of today’s implementations the JVM will create an operating system level thread for each Java thread and does no active scheduling activity itself. But a particular JVM implementation may contain a scheduler for operating systems that don’t have one.
E.g., for Sun’s JVM that was the case back in the last millennium. At this time, there was the option to use green threads, as opposed to native threads. Note that these threads implemented without the aid of the operating system aren’t capable of using multiple CPUs/cores.
So in practice, when you run your example program, the operating system’s scheduler may indeed assign the second thread to a different core. However, since this is a tiny program, it’s also possible that the first thread terminates before the second even starts its actual work, and in that case, it will likely run on the same core as the first, but there is no guaranty about any particular scheduling behavior at all.
While there is no guaranty regarding a particular scheduling behavior, most SMP libraries and tools are built on the (founded) assumption, that if there are enough runnable threads with sufficient workload, the underlying system will assign these threads to available CPU cores.