I have recently started multi-threaded programming with Java
in case of Linux threads , i know that the kernel schedules them(as they are the unit entities that are scheduled)but java programs are run on JVM which in my system (RHEL 6.1) is implemented as a program that is run as a user space instance .So, without the kernel being aware of the java threads, how come preemptive multitasking is done in JVM? it will be helpful if the whole mechanism of JVM and kernel interaction in doing this thing is given.
Please cite possible sources of info
Threads in the java/JVM process maps to a native thread and you can see both the java thread id and the native thread id in a thread stack trace dump. Get the thread stack of all java threads using your favorite tool:
command line signal like ctrl+break (windows) or ctrl+\ linux) in the console where the java program is running
command line tool (kill -QUIT or jstack from the jdk)
visual vm in the jdk and/or jmx etc
Example extract from the first line of such a thread dump:
... tid=0x0000002adaba9c00 nid=0x754c ...
tid = java thread id
nid = native id (the OS thread id)
Use the operating system's tools to find out more about the thread using the native id (it is in hex).
Inside the java code you have ThreadMXBean to retrieve more thread information programatically if you want
http://docs.oracle.com/javase/6/docs/api/java/lang/management/ThreadMXBean.html
Read Distinguish Java threads and OS threads?
As I said in the comment Java threads are ordinary OS threads just running JVM code
The jvm is just a normal process which starts with one thread and can spawn as much threads it likes afterwards. Scheduling is done on two levels - between processes and between threads inside processes. All this is done by the OS (via libs) - the jvm just hooks in. Google posix threads for more details - thats whats exposed (API) to the jvm.
This goes a bit into details:
http://www.ibm.com/developerworks/java/library/j-rtj3/
"but java programs are run on JVM which in my system (RHEL 6.1) is
implemented as a program that is run as a user space instance.So,
without the kernel being aware of the java threads ..."
This statement is incorrect for all modern JVM's that use native threads. I think thats been the default since Java 1.2.
Native Thread implementation by a JVM means that each time a thread instantiates/runs a thread in Java code, the JVM asks the OS to create the thread. Since these are native threads, the kernel knows about them and treats them accordingly. Furthermore, Linux supports/implements POSIX threads, and as such on a Linux based systems you will get pthread behavior for your Java apps' threads
Related
Will a java thread have a unique PID in UNIX environment? If I want to kill a specific thread of execution , is it possible to be done outside the program?
Oracle includes jvisualvm in the JDK\bin directory. You can use it to view threads running inside running JVM's. However, I don't see any support for terminating a thread.
Here they say Most implementations of the Java virtual machine run as a single process. A Java application can create additional processes using a ProcessBuilder object. So following this it seems that you can't without tinkering the vm. The alternative would be spawn a process instead of a thread.
I am analyzing the differences between approaches for taking thread dumps. Below are the couple of them I am researching on
Defining a jmx bean which triggers jstack through Runtime.exec() on clicking a declared bean operation.
Daemon thread executing "ManagementFactory.getThreadMXBean().dumpAllThreads(true, true)" repeatedly after a predefined interval.
Comparing the thread dump outputs between the two, I see the below disadvantages with approach 2
Thread dumps logged with approach 2 cannot be parsed by open source thread dump analyzers like TDA
The ouput does not include the native thread id which could be useful in analyzing high cpu issues (right?)
Any more?
I would appreciate to get suggestions/inputs on
Are there any disadvantages of executing jstack through Runtime.exec() in production code? any compatibility issues on various operating systems - windows, linux?
Any other approach to take thread dumps?
Thank you.
Edit -
A combined approach of 1 and 2 seems to be the way to go. We can have a dedicated thread running in background and printing the thread dumps in the log file in a format understood by the thread dump analyzers.
If any extra information is need (like say probably the native thread id) which is logged only by the jstack output, we do it manually as required.
You can use
jstack {pid} > stack-trace.log
running as the user on the box where the process is running.
If you run this multiple times you can use a diff to see which threads are active more easily.
For analysing the stack traces I use the following sampled periodically in a dedicated thread.
Map<Thread, StackTraceElement[]> allStackTraces = Thread.getAllStackTraces();
Using this information you can obtain the thread's id, run state and compare the stack traces.
With Java 8 in picture, jcmd is the preferred approach.
jcmd <PID> Thread.print
Following is the snippet from Oracle documentation :
The release of JDK 8 introduced Java Mission Control, Java Flight Recorder, and jcmd utility for diagnosing problems with JVM and Java applications. It is suggested to use the latest utility, jcmd instead of the previous jstack utility for enhanced diagnostics and reduced performance overhead.
However, shipping this with the application may be licensing implications which I am not sure.
If its a *nix I'd try kill -3 <PID>, but then you need to know the process id and maybe you don't have access to console?
I'd suggest you do all the heap analysis on a staging environment if there is such an env, then reflect your required Application Server tuning on production if any. If you need the dumps for analysis of your application's memory utilization, then perhaps you should consider profiling it for a better analysis.
Heap dumps are usually generated as a result of OutOfMemoryExceptions resulting from memory leaks and bad memory management.
Check your Application Server's documentation, most modern servers have means for producing dumps at runtime aside from the normal cause I mentioned earlier, the resulting dump might be vendor specific though.
I have a question about Java Threads. In java, while running on top of JVM, can threads run in parallel actually? Does JVM show OS each thread separately as they are? (enabling OS to run each Thread in multiple cores in the same time?) Or do they actually run interleaved only, as OS sees all threads as a one due to JVM? Hope my question is clear.
It depends on the implementation of the JVM. Modern implementation of JVM's expose Java threads to the OS.
I have a question about Java Threads. In java, while running on top of JVM, can threads run in parallel actually?
That is down to the OS and the hardware you have. However most JVMs on multi-core system can have threads running concurrently.
Does JVM show OS each thread separately as they are? (enabling OS to run each Thread in multiple cores in the same time?)
Most JVMs use the OS threads. In this case, there is no difference.
Or do they actually run interleaved only, as OS sees all threads as a one due to JVM?
Unless you have more than one thread needing to run (this is usually the case with most application) then only one thread will be running. In fact whenever your CPU load drops below one CPU, you have statically less than one thread running in your whole machine.
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 to run a Java program that uses the Thread class such that each Thread.run() results in running a proper kernel thread. Is there a way to achieve this by passing some command line parameter to the Java VM ? I am running Eclipse using Java 1.5 SDK (and jre1.5.0_18) on a Windows machine. I tried using -XX:+UseBoundThreads, but the task manager seems to be running both the threads (I am using a dual core machine) on the same core (the other core is idle).
Thanks.
I would like to run a Java program
that uses the Thread class such that
each Thread.run() results in running a
proper kernel thread.
If you call Thread.run(), you're not creating separate threads at all, you're executing everything sequentially in the main thread. What you have to do is call Thread.start(), which will create a new Thread and have it execute Thread.run().
The Windows JVM always uses native threads. However, it is up to the kernel to decide which core to run each thread on. There's absolutely no guarantee that starting two threads will be shared between 2 cores.
Incidentally, I think the UseBoundThreads option is solaris only, but I'm not too sure about that.
You can attach with jvisualvm to see which threads are running and how much CPU they use.
Thanks Guys.. although I don't know the right answer, currently, Java 1.6 in eclipse is giving me almost twice the performance on my dual-core for the code-base i am looking at...also, jvisualvm works great as a profiler..thanks!