Executing thread by JVM.

[John Hening]

Hello, 

I would like to ask for threads in Java. As we know, JVM uses system threads (native threads). So, for example it uses Linux threads. In simplification a thread is a stack + piece of code to execute. 

Let's consider:

Thread t = new Thread(() -> {`any_code`});
t.start();
t.join();

`any_code` will be compile to bytecode. So, how does the t is executed? We can assume that that code wouldn't be jited. I cannot understand what is a "content" of that thread? After all, bytecode must be interpreted 

by JVM. So, does the thread execute a JVM that interprets a bytecode `any_code`? 

[Tom Lee]

Hey John,

Without commenting on whether threads in Java are always tied to native threads (I don't think this is always strictly true), sounds like there might be a misunderstanding here. What is special about threads in particular that make you think `any_code` wouldn't be JIT-able here? Put another way: code in the thread that creates `t` (e.g. the "main" thread) could presumably be JIT-ed, so why not the code in `t`?

When you run javac, you end up with classfiles that contain bytecode & metadata. That bytecode is loaded by the JVM at runtime. A JVM might then start profiling this code using a bytecode interpreter to identify "hot" methods. Those might then become candidates for the JIT. I'm not sure that threads really come into it -- at least not at the level you're talking about.

This story can get a little more complicated when you're using the server compiler & tiered compilation (pretty sure this is the default in Oracle JVM for Java 8, at least on Linux):  https://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html#tieredcompilation ... but even then, threads don't really change the story.

Does this help at all?

Cheers,

Tom

On Sun, Nov 12, 2017 at 3:17 PM, John Hening <goci...@gmail.com> wrote:

Hello, 

I would like to ask for threads in Java. As we know, JVM uses system threads (native threads). So, for example it uses Linux threads. In simplification a thread is a stack + piece of code to execute. 

Let's consider:

Thread t = new Thread(() -> {`any_code`});
t.start();
t.join();

`any_code` will be compile to bytecode. So, how the thread is executed? We can assume that that code wouldn't be jited. I cannot understand what is a content of that thread? After all, bytecode must be interpreted 

by JVM. So, does the thread execute a JVM that interprets a bytecode `any_code`?

--
You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mechanical-sympathy+unsub...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Tom Lee / http://tomlee.co / @tglee

[Remi Forax]

De: "John Hening" <goci...@gmail.com>
À: "mechanical-sympathy" <mechanica...@googlegroups.com>
Envoyé: Lundi 13 Novembre 2017 00:17:32
Objet: Executing thread by JVM.

Hello, 

I would like to ask for threads in Java. As we know, JVM uses system threads (native threads). So, for example it uses Linux threads. In simplification a thread is a stack + piece of code to execute. 

it depends on the Java VM, for Hotspot (the OpenJDK VM), it uses only one stack with different kind of stackframes (one stackframe by method activation, method call if you prefer).

There are different kind of stackframe depending on if the stackframe represent a call that is executed by the interpreter, a call to C (through JNI), a call to a JITed method (in fact there are more than one JIT and they do not use the same calling convention for historical reason), etc.

The stackframe for the interpreter is described here

  https://wiki.openjdk.java.net/display/HotSpot/JavaControlStack

Let's consider:

Thread t = new Thread(() -> {`any_code`});
t.start();
t.join();

`any_code` will be compile to bytecode.

usually as a static method by the compiler at compile time, not at runtime.

 So, how the thread is executed? 

you create a native thread, something like pthread_create with a C function pointer, when you do a pthread_start, the function pointer is executed and it will either create a stack frame entry that will either execute the code in the interpreter or a stack frame entry that will execute the JITed code. 

We can assume that that code wouldn't be jited.

No, you can ask the JIT to always generate a JITed code with no interpreter. In that case, the bytecode will be JITed, transformed to assembly code and the assembly code will create the stackframe entry, run the code and pop the stack frame entry at the end. Note that Hotspot is able to deoptimize the code in the middle of the JITed code, so the created stack frame entry as to be large enough to take all values from the register and spill them on the stack before bailing out to the interpreter.

 I cannot understand what is a content of that thread? After all, bytecode must be interpreted 

again, not necessarily

by JVM. So, does the thread execute a JVM that interprets a bytecode `any_code`?

see above.

Rémi

[Nitsan Wakart]

Default behavior for what you describe:

- An OS thread is created, and tied to a new Thread object. Your code is the "Runnable" for that Thread

- When the thread is started a bunch of JVM runtime code is executed, finally calling into Thread::run, which in turn calls into your code.

- Your code is initially executed in the interpreter but may be OSR compiled if it contains a long running loop.

Now, AFAIK, none of the above is enshrined in the JVM spec so an OS thread may or may not be created, your code might be compiled ahead of time, JIT compiled immediately by some compiler at runtime, or never compiled. This will depend on the JVM implementation, flags you pass to the JVM etc.

"does the thread execute a JVM" -> this implies forking a new process, perhaps unintentionally, but for clarity the JVM does not spawn a new process per thread.

[John Hening]

You explained me that. Thank you :)