44

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

Geek
  • 23,089
  • 20
  • 71
  • 85

4 Answers4

29

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.

Sanjay T. Sharma
  • 22,857
  • 4
  • 59
  • 71
  • Sorry for the rant, this answer got much longer than expected. ;-) – Sanjay T. Sharma Dec 13 '10 at 09:52
  • @Sanjay: If I get it right JIT will be done even before the Thread executes for the first time ? Essesntially the JVM first does the JIT for both Independent threads and than forwards to the OS Threads for execution ? – Geek Dec 13 '10 at 10:00
  • 1
    @Geek: As already mentioned, JIT and thread execution are two orthogonal issues. Yes, it is quite possible that the piece of code a Thread is about to execute might already have been JIT'ed by the VM. Also, there is no *forwarding* of execution. When a `start()` method is called on a Thread object, a new native OS thread is created, there is no forwarding between "Java thread" and "OS thread". Also, JIT is not mandatory. It might so happen that your thread would currently be executing code which has not being JIT'ed. JIT is a performance specific optimization. – Sanjay T. Sharma Dec 13 '10 at 10:20
  • @Sanjay: Like you mentioned "It might so happen that your thread would currently be executing code which has NOT being JIT'ed." So if this is the case How does the OS Thread interpret the Bytecode ? It has to go to the JVM again ? So if both the Threads A, B have to do this, how is this even remotely Threaded ? it is more like sequential. Am I missing something ? – Geek Dec 13 '10 at 10:58
  • @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 ? – Geek Dec 13 '10 at 11:01
  • @Sanjay: Excellent answer mate, I must say I learnt something. Thanks for your patience, I will select this answer as the correct answer if I dont recieve any better answer :-) – Geek Dec 13 '10 at 11:59
26

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"??

srk
  • 4,857
  • 12
  • 65
  • 109
Andreas Dolk
  • 113,398
  • 19
  • 180
  • 268
  • I was talking only about specific Threads prior to JDK i.2 known as Green Threads. – Geek Dec 13 '10 at 09:44
  • @Geek - you "mentioned" Green threads, but your question was (looking at the title) about Java threads in general. Please edit your question, if you're only interested in green threads and Java 1.1/1.2 – Andreas Dolk Dec 13 '10 at 09:58
  • Sure. Actually incase of Green Threads it is easy to understand how Byte code conversion is handled by the JVM when running two threads because the JVM has the entire control. I am not able to grasp it incase the two threads run as OS Threads. – Geek Dec 13 '10 at 10:04
  • @Andreas_D - what changes here in Java 7? Thanks, only if you have time to respond. – Steve Townsend Jul 01 '11 at 12:16
4

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.

AlexR
  • 114,158
  • 16
  • 130
  • 208
  • 3
    Java 1.0 on Solaris used green threads. Not sure anyone has since, but it is allowed for in the design. – Peter Lawrey Dec 13 '10 at 09:47
  • So like you said if I have all the code by JIT or through the hotspot, I can effectively run two Java threads as two OS Threads, fair enough. But I think JIT compilation happens on the first pass of the code so the first time when I run the code which starts two threads the two threads will still have to be interpreted ? Hence JVM will be involved by both the OS Threads. – Geek Dec 13 '10 at 09:47
  • As far as I know JVM creates a thin wrapper over native thread. All threads in one application share the same memory, so code compiled to native code will be shared among threads. – AlexR Dec 13 '10 at 10:01
  • Very close "code compiled to native.." when does this happen for all Thread related RUN Functions ? Does it happen even before the RUN methods are called ? If that is the case, i think I understood the Puzzle :-) – Geek Dec 13 '10 at 10:07
  • I still didn't get it completely. If java thread A is mapped to OS thread B and B is scheduled to run on CPU, how does B get native code from A? Does JVM compile byte code and place native code at a common place from where B continuously reads native code and knows which statement needs to be executed next whenever B gets CPU time? – the-dumb-programmer Nov 30 '16 at 16:46
4
  1. 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.
  2. The JVM itself might already use different threads for the work to do (garbage collection, class loading, byte-code-verification, JIT-Compiler).
  3. 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.
Mnementh
  • 50,487
  • 48
  • 148
  • 202