For example, I use Java to write a multi-threaded program with 5 threads. When I execute it, does the operating system (e.g. Windows 7) know that or it is just one task?
That depends on the JVM implementation.
However, in Linux platform , USUALLY there is one-one mapping between java thread and native thread.
Alternatively, the JVM could chose to implement using many-one mapping ,that is many java thread are running on one single native thread. This is called Green Thread.
Modern JVMs tend to use operating system threads, but it isn't specified, and the JVM is free to do otherwise.
Related
I have chat server application which we are going to deploy on 3 servers. chat application used lot of multithreading.
Basically i have to decide which os i should for those 3 servers. so i want to know how linux and windows handles java threads distinctively. what is the difference? who creates operating system threads? what memory are they assigning ?
If in future scope scalability and clustering which option is better?
If in future scope scalability and clustering which option is better?
Scalability and clustering are most likely hampered by the internal design of your code not by the JVM nor by the underlying OS. And without taking a very deep look into the code every statement about this is just hot noise but not a profound statement.
But the nice thing about Java is: It will run on both platform without changing your code. So the best you can do is: Benchmark both OSes on the same hardware (but do not use any kind of virtualization!) and use the best one for your purpose.
how linux and windows handles java threads distinctively.
The beauty of Java is that you don't really care. They just work. But if you are really curious, modern JVMs delegate thread handling to the operating system. So it is more of an OS question rather than Java.
what is the difference?
See above. Java has little to do here. It is about how threading is implemented in the host OS.
who creates operating system threads?
JVM asks OS to create them and provides a thin wrapper between Java Thread object and native threads.
what memory are they assigning ?
Each thread gets its own stack (seee -Xss JVM option). Also all threads share the same heap space.
Looks like I have messed up with Java Threads/OS Threads and Interpreted language.
Before I begin, I do understand that Green Threads are Java Threads where the threading is taken care of by the JVM and the entire Java process runs only as a single OS Thread. Thereby on a multi processor system it is useless.
Now my questions is. I have two Threads A and B. Each with 100 thousand lines of independent code. I run these threads in my Java Program on a multiprocessor system. Each Thread will be given a native OS Thread to RUN which can run on a different CPU but since Java is interpreted these threads will require to interact with the JVM again and again to convert the byte code to machine instructions ? Am I right ? If yes, than for smaller programs Java Threads wont be a big advantage ?
Once the Hotspot compiles both these execution paths both can be as good as native Threads ? Am I right ?
[EDIT] : An alternate question can be, assume you have a single Java Thread whose code is not JIT compiled, you create that Thread and start() it ? How does the OS Thread and JVM interact to run that Bytecode ?
thanks
Each Thread will be given a native OS
Thread to RUN which can run on a
different CPU but since Java is
interpreted these threads will require
to interact with the JVM again and
again to convert the byte code to
machine instructions ? Am I right ?
You are mixing two different things; JIT done by the VM and the threading support offered by the VM. Deep down inside, everything you do translates to some sort of native code. A byte-code instruction which uses thread is no different than a JIT'ed code which accesses threads.
If yes, than for smaller programs Java
Threads wont be a big advantage ?
Define small here. For short lived processes, yes, threading doesn't make that big a difference since your sequential execution is fast enough. Note that this again depends on the problem being solved. For UI toolkits, no matter how small the application, some sort of threading/asynchronous execution is required to keep the UI responsive.
Threading also makes sense when you have things which can be run in parallel. A typical example would be doing heavy IO in on thread and computation in another. You really wouldn't want to block your processing just because your main thread is blocked doing IO.
Once the Hotspot compiles both these
execution paths both can be as good as
native Threads ? Am I right ?
See my first point.
Threading really isn't a silver bullet, esp when it comes to the common misconception of "use threads to make this code go faster". A bit of reading and experience will be your best bet. Can I recommend getting a copy of this awesome book? :-)
#Sanjay: Infact now I can reframe my
question. If I have a Thread whose
code has not been JIT'd how does the
OS Thread execute it ?
Again I'll say it, threading is a completely different concept from JIT. Let's try to look at the execution of a program in simple terms:
java pkg.MyClass -> VM locates method
to be run -> Start executing the
byte-code for method line by line ->
convert each byte-code instruction to
its native counterpart -> instruction
executed by OS -> instruction executed
by machine
When JIT has kicked in:
java pkg.MyClass -> VM locates method
to be run which has been JIT'ed ->
locate the associated native code
for that method -> instruction
executed by OS -> instruction executed
by machine
As you can see, irrespective of the route you follow, the VM instruction has to be mapped to its native counterpart at some point in time. Whether that native code is stored for further re-use or thrown away if a different thing (optimization, remember?).
Hence to answer your question, whenever you write threading code, it is translated to native code and run by the OS. Whether that translation is done on the fly or looked up at that point in time is a completely different issue.
and the entire Java process runs only as a single OS Thread
This is not true. Thus not specified, we often see, that Java threads are in fact native OS threads and that multithreaded Java applications really make use of multi-core processors or multi-processor platforms.
A common recommendation is using a thread pool where the number of threads is proportional to the number of cores (factor 1-1.5). This is another hint, that the JVM is not restricted to a single OS thread / process.
From wkipedia:
In Java 1.1, green threads were the only threading model used by the JVM,[4] at least on Solaris. As green threads have some limitations compared to native threads, subsequent Java versions dropped them in favor of native threads.
Now, back in 2010 with Java 7 under development and Java 8 planned - are we really still interested in historic "green threads"??
Threading and running a byte code are separate issues. Green threads are used by JVM on platforms that do not have native support of threads. (IMHO I do not know which platform does not support threads).
Byte code is interpreted in real time and executed on native platform by JVM. JVM decides what are the most popular code fragments and performs so called Just in time compiling of these fragments, so it does not have to compile them again and again. This is independent on threading. If for example you have one thread that executes the same code fragment in loop you this fragment will be cached by just in time compiler.
Bottom line: do not worry about performance and threads. Java is strong enough to run everything you are coding.
Some Java-implementations may create
green threads like you describe it
(scheduling made by the JVM on a
single native thread), but normal
implementations of Java on PC use
multiple cores.
The JVM itself might already use different threads for the work to do (garbage collection, class loading, byte-code-verification, JIT-Compiler).
The OS runs a program called JVM. The JVM executes the Java-Bytecode. If every Java-Thread has an associated native thread (that makes sense and seems to be the case on PC-implementations), then the JVM-code in that thread executes the Java-code - JITed or interpreted - like on a single-thread-program. No difference here through multithreading.
As for as I know, Java threads can communicate using some thread APIs. But I want to know how the Java threads and the OS threads are communicting with each other. For example a Java thread needs to wait for some OS thread finishes its execution and returns some results to this Java thread and it process the same.
Many mix up threads and processes here, the jvm is a process which may spawn more threads. Threads are lighter processes which share memory within their process. A process on the other hand lives in his own address space, which makes the context switch more expensive. You can communicate between different processes via the IPC mechanisms provided by your OS and you can communicate between different threads within the same process due to shared memory and other techniques. What you can't is communicate from ThreadA(ProcessA) to ThreadA(ProcessB) without going through plain old IPC: ThreadA(ProcessA) -> ProcessA -> IPC(OS) -> ProcessB -> ThreadA(ProcessB)).
You can use RMI to communicate between two java processes, if you want to "talk" to native OS processes, you have to go JNI to call the IPC mechanisms your OS of choice provides imo.
Feel free to correct me here :)
Sidenote:
You cant see the threads of your JVM with a process manager (as long as your JVM does not map threads to native processes, which would be stupid but possible), you need to use jps and jstack to do that.
Every Instance of JVM is essentially an OS process.
Java threads usually but don't necessarily run on native threads and Java concurrency classes could but don't necessarily map onto native equivalents.
If you had to sync between a native thread and a Java thread, you will most likely have to consider writing a JNI method that your Java thread calls. This JNI method would do whatever native synchronization operation it needs to do and then return. Every platform is going to do this differently but I assume this wouldn't be too much of an issue if you need to inspect native threads in the first place.
I would like a solution that doesn't include critical sections or similar synchronization alternatives. I'm looking for something similar the equivalent of Fiber (user level threads) from Windows.
The OS manages what threads are processed on what core. You will need to assign the threads to a single core in the OS.
For instance. On windows, open task manager, go to the processes tab and right click on the java processes... then assign them to a specific core.
That is the best you are going to get.
To my knowledge there is no way you can achieve that.
Simply because the OS manages running threads and distributes resources according to it's scheduler.
Edit:
Since your goal is to have a "spare" core to run other processes on I'd suggest you use a thread manager and get the number of cores on the system (x) and then spawn at most x-1 threads on the specific system. That way you'll have your spare core.
The former statements still apply, you cannot specify which cores to run threads on unless you in the OS specify it. But from java, no.
Short of assigning the entire JVM to a single core, I'm not sure how you'd be able to do this. In Linux, you can use taskset:
http://www.cyberciti.biz/tips/setting-processor-affinity-certain-task-or-process.html
I suppose you could run your JVM within a virtualized environment (e.g., VirtualBox/VMWare instance) with one processor allocated, but I'm not sure that that gets you what you want.
I read this as asking if a Java application can control the thread affinity itself. Java does not provide any way to control this. It is treated as the business of the host operating system.
If anything can do it, the OS can, and they typically can, though the tools you use for thread pinning will be OS specific. (But if the OS is itself is virtualized, there are two levels of pinning. I don't know if that is going to work / be practical.)
There don't appear to be any relevant Hotspot JVM thread tuning options in modern JVMs.
If you were using a Rockit JVM you could choose between "native threads" (where there is a 1-1 mapping between Java and OS threads) and "thin threads" where multiple Java threads are multiplexed onto a small number of OS threads. But AFAIK, JRocket "thin threads" are only supported in 32bit mode, and they don't allow you to tune the number of OS threads used.
This is really the kind of question that you should be asking under a Sun support contract. They have people who have spent years figuring out how to get the best performance out of big Java apps.
What is the difference between threads in java and native threads?
Java threads can be implemented in any way that conforms to the specification. The specification doesn't require a specific implementation.
Effectively all modern desktop and/or server JVMs implement Java threads as native threads. That means that there is exactly 1 native thread for each Java thread and that the operating system does all the scheduling, just as it does for a C program, for example.
Some old JVMs and possibly some JVMs for devices with limited resources might implement threads in a way where the number of native threads used is smaller than the number of Java threads running (or possibly 1). Those implementations are said to implement so called "green threads". In this case the JVM itself is responsible for task switching and scheduling, as opposed to delegating that task to the operating system.
It depends on the implementation of the JVM, of course, but I think they are the same. It is, a Thread in Java is implemented via a native thread. You can expect/do with Java threads all kind of things you can with native threads.
Java threads and Native threads are completely different. Native thread is part of underlying platform (the OS).
Java threads are one of the feature of Java Language for supporting concurrency. Java specification controls API and functioning of Java threads. Ultimately Java threads will be mapped to native threads during execution of the java program.
Also java threads needn't get one to one mapped with native threads.
Java Threads (Thread class and Runnable interface) are a much higher-level API than native threads in memory-shared applications. I recommended this book "Java Threads" by Oaks and Wong http://shop.oreilly.com/product/9780596007829.do. It's common practice to implement the Runnable interface, but it depends on your code scope.