On Fri, Nov 19, 1999 at 03:54:42PM -0600, [EMAIL PROTECTED] wrote:
>
> [Nathan]
> The JVM is a multi-threaded native application. Most of the time it's
> running native code that implements an interpreter, but some of the time
> it's running native code that doesn't happen to be in the interpreter
> (such as JNI methods or JIT-compiled code)....
>
> [Lee]
> {
> This is a great comment! I didn't pay attention to the
> simple but important fact - "The JVM is a multi-threaded
> native application". Can we say that when java calls a native
> method, what really happens is JVM, the native application,
> loads a shared lib into its (JVM's) memory space and invokes
> one of the shared lib's methods. Therefore, no new thread is
> created at the time when java calls a native method. Is it
> right or I miss something again here?
You got it! The shared library is loaded into the JVM's shared library
address space when Java executes the System.loadLibrary() call.
> [Lee]
> If it's true, then why you say "When Java creates a native
> thread" below? Is a new thread really created when java calls
> a native method, and how?
No. A new thread is created when Java code invokes Thread.start().
It's an explicit operation, and certainly not something that just
happens when you jump between Java and native code.
Native code can also create new threads with pthread_create(), but
they need to "attach" to the Java JVM so the JVM knows about them.
> [Nathan]
> The important thing is that both the JVM and your native code use the
> same threading mechanism. Since you're using pthread_create() to create
> threads, you need to run a version of the JVM (native) that uses the
> same system. AFAIK, there's no way for JNI code to create new threads
> in a green thread environment.
>
> [Lee]
> {
> They uses the same threading mechanism or the same thread?
> }
Same *mechanism*. When you run with native threads, you run a version of
the JVM that creates its threads with pthread_create() - just like your
native code is doing. When you run with green threads, you're running
with a threading emulation library from Sun that has its own API, isn't
accessible from your native code, and will tend to crash and burn if
someone in the process space creates threads with pthread_create().
The thing to understand about green threads is that they were Sun's way
of getting Java onto a lot of platforms before those platforms had good
native threading mechanisms. Even today, as the Blackdown team struggles
with Linux's threading quirks, the green-threaded version of the JVM
tends to be more reliable. Green threads have their own interesting
"features": they're not preemptive, and they're not available to native
code that wants to create or manage threads. But they work.
> [Nathan]
> At any rate, all threads (native or green) are running "in the same
> process". With native threads, however, different threads have their
> own PIDs and entries in the process table, which results in confusing
> "ps" results. (Which is why I put "in the same process" in quotes - if
> you define a "process" as something with its own PID, then the threads
> are processes... but they *are* lightweight processes!)
>
> [Lee]
> {
> http://pauillac.inria.fr/~xleroy/linuxthreads/README says that
> threads not sharing parent's pid is a known bug (see "KNOWN BUGS
> AND LIMITATIONS" section). Is it right?
>
> Can you see a new process besides "java" process after java calls
> a native method? I made a simple jni code, run it and couldn't
> find extra process besides "java" by using "ps -a". The native
> method is a infinity loop, so I have time to check ps.
Again, calling JNI methods doesn't create a new thread... calling
Thread.start() does. That's why you don't see a new thread just by
calling native code.
The information in that README file is correct; it happens just as much
with multi-threaded C++ applications as with Java. But it's a limitation,
not a bug. This "feature", along with some others (for example, how the
thread stacks are laid out in the address space), makes it difficult to
create a multi-threaded application with more than a few hundred threads.
Now, applications with hundreds of threads are arguably employing Bad
Programming Practice, but there are developers who will defend to the
death their right to create such applications and who consider the
per-thread use of precious resources (slots in the process table) to be
a bug.
But it isn't a bug. There's no spec that says threads have to share the
same PID. Ignoring this quirk, Linux threads are true threads: they run
in a common process space, and the cost of context-switching between
them is lower than the cost of context-switching between heavyweight
processes.
Nathan
----------------------------------------------------------------------
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
