Wouldn't each thread require its own copy of the JVM?
I am trying to figure out how the JVM works in regards to spawning multiple threads. I think my mental model might be off a bit, but right now I'm stuck with this idea: since only one copy of the JVM is running at a time, wouldn't each thread require its own copy of the JVM? I understand that multiple threads of a Java application are mapped to native os threads, but I don't understand how threads that don't start the JVM crunch bytecode; that all threads have access to the JVM in some way? thanks, any help is appreciated.
source to share
This is a bit oversimplified and some of what I wrote is not strictly correct, but the gist is:
since there is only one copy of the JVM at any given time, wouldn't each thread require its own copy of the JVM?
Not really. You can allow multiple threads to read from the same piece of memory (as in the same address in memory) and hence only have one JVM. However, you have to be careful that threads do not create a mess when they simultaneously access such shared resources (JVMs) as they do in the real world (imagine two people trying to type two different documents at the same time from the same PC).
One strategy to keep multiple threads running along with some shared resource (e.g. JVM (stack, heap, bytecode compiler), console, printer, etc.) actually contains copies for each thread (one PC for each person), For example , each thread has its own stack.
This, however, is not the only way. For example, immutable resources (such as class bytecodes in memory) can be shared across multiple threads seamlessly across shared memory. If part of the memo does not change, two people can safely view the memo at the same time. Likewise, since the bytecode class does not change, multiple threads can read them simultaneously from a single copy.
Another way is to use blocking to sort events between threads (whoever touches the mouse to use the PC). For example, you can imagine a JVM that has only one byte code interpreter that is common to all threads and is protected by one global lock (which would be very inefficient in practice, but you get the idea).
There is also another advanced mechanism that allows multiple threads to share resources. The people who developed the JVM used these techniques and why you don't need a copy of the JVM for every thread.
source to share
but I don't understand how threads that don't start the JVM crunch the bytecode; that all threads have access to the JVM in some way?
http://www.artima.com/insidejvm/ed2/jvmP.html explains it well. Here's what he says:
" Each thread of a running Java application is a separate instance of the virtual machine execution engine. From the beginning of its life cycle to the end, the thread executes either bytecodes or its own methods. A thread can execute bytecodes directly, by interpreting or executing natively based on silicone or indirectly by compiling and executing the resulting native code at a specific point in time. The Java virtual machine implementation can use other threads that are not visible to the running application, such as the thread that is performing garbage collection. Such threads do not need to be "instances" of the execution engine. all threads belonging to a running application are execution engines in action. "
To summarize my understanding of this:
For each thread (execpt GC thread and ilk), the corresponding ExecutionEngine instance (in the same JVM) converts the bytecodes to machine instructions and the native OS thread executes these machine instructions. Of course, I'm not talking about the green theme here.
source to share
By definition, threads in a Java application have the same memory space, so they run in the same JVM. This way, you can easily share objects across multiple threads, do synchronization, etc., whatever happens in the JVM.
One way to ensure that processes have their own memory space and threads in an application have the same memory space.
source to share