> De: "John Hening" <[email protected]> > À: "mechanical-sympathy" <[email protected]> > 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 -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
