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!
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.
We Have a Multi-threaded Application in JAVA which has multiple threads running in parallel. Now we want to run all these threads on a single core. Currently application is running on a system having more then one Cores.
We know there is a technique available ProcesAffinity in .Net Framework to set process affinity.
But we don't want to depend on .Net Framework, because our application is build in java.
Do we set Process affinity using Bat file and run our application executable jar file through Bat file?
Currently our application is running on Window XP. So we need a solution that should be working fine on XP platform.
EDIT:
It's possible: See Java thread affinity
Pure Java doesn't support running a thread on specific processor. Check the SO question linked above.
Personally, I don't think that the fact that this cannot be set in pure Java is a bad thing, as to me, how an app is run does very much depend on the OS, so therefore a OS-specific solution isn't a bad thing.
You can use the MS psexec utility to set the affinity:
psexec -a 1 java -jar myapplication.jar
Would instruct that all of the threads created by java would be run on the lowest CPU.
And this line would be your .BAT file...
You cannot do it in pure Java. But on some versions of Windows, you can do it via operating system utilities; see https://superuser.com/questions/309617/how-to-limit-a-process-to-a-single-cpu-core ... and you might be able to do this by calling native libraries via JNI.
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
I have a big program in Java that uses multithreading. In some cases, the program starts using 100% of three cores of my eight core system. In normal use, the program use all cores at 1-2%. How can I find the class that's overloading cores?
Use a profiler such as the jvisualvm that is bundled with jdk-1.6.0_10
The best solution is to use a profiler - that's what they're built for, and there's a great one bundled with Java 6.
Another (far from being as ideal a solution) is to run your program in the Eclipse IDE (if that's what you use) in debug mode. You can then look at the running threads. IF a lot of them are suspended, the one that is not might be your culprit. Force it to break (from the toolbar) and you can see where it is. There are many chances that you'll find a clear loop or busy waiting.
Use a profiler to figure out which thread(s) are using all of your CPU cycles, and the method(s) they are executing.
If you are using Eclipse, you can use the TPTP profiling tool.
If you are going the commercial profiler route then I would recommend using Dynatrace.
Try taking threads dump (see jps, jstack commands) and then see which methods are executed.
If you are using Java over UNIX or some versions of Linux look into DTrace with Java.
I have a program 'foo' running different threads, fooT1, fooT2, .. fooTn.
Now if I want write another program 'bar', which could kill the thread fooTr, is that possible?
Reason: One of the thread fooTr tracks product license. If this thread is killed; one may run this product indefinitely. And killing 'foo' itself is tolerable as 'foo' as that is exactly what is being done on license expiry.
System: Fedora Distribution of Linux
Note: The commands which start JVM and program foo are placed in /etc/init.d and anyone who has a decent knowledge of rc.1/rc.2/rc.3 structure can change/add the starting parameters to these.
I hope my question is clear. If not, I can always edit it.
Actually the java debugger will allow you to kill a thread by injecting an exception into it. I was just trying to work out how to use this feature to kill a thread without wiping out the whole jvm, when I came across this question. If you run the jvm with command line options like:
java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8888 your.app.Main
and connect the debugger with something like:
jdb -attach 127.0.0.1:8888
you can type:
threads
to get a list of the running threads, and use the kill command to kill a running thread. The bit I'm currently not sure about is the syntax of this kill command, I have tried the obvious:
kill 0xe2e new java.lang.IllegalArgumentException("er");
and I get the messages:
killing thread: Swank REPL Thread
Thread not suspended
Expression must evaluate to an object
("Swank REPL Thread" is the thread I want to kill, and yes, I've tried suspending it first ;)
Still my inability to use the java debugger aside, it looks to me like a thread can be killed at random. Maybe you can just make sure you ignore all exceptions and keep running and that will be enough, but I'm not sure about that.
To my knowledge it is not possible to do this directly. What you could consider however is to create some kind of service on your 'foo' that can be called from 'bar' to kill the thread. There are, of course, hundreds of ways to implement this. My first thought would be to do this using RMI.
You could do this even without a separate application. Write your own startup class, which performs a pass-through of parameters to the original startup class of the application. Your class's main method though would create a thread that periodically checks the list of all threads (e.g., Thread.getAllStackTraces or Thread.enumerate), finds the offending thread, and invokes stop() on it. Although Thread.stop is deprecated, it still works.
Another option is to run the application under a Java debugger, say, jdb and then suspend/kill the required thread. You could also add parameters to the application's startup so that the JVM can be attached to, then attach jdb to the running JVM and suspect/kill the thread.
Until now isn´t possible to run to diferent programs in the same JVM, but some people is investigating it, in order to reduce the startup time and the memory and cpu usage of diferent java programs runing in the same machine