We have a C/C++ SDK lib (on Solaris) that supports JNI. Customer has a Java App (single threaded) that calls our SDK. In one of our function, we can pthread_self several times. It turns out even in this single threaded Java App, pthread_self returns different values. In the latest test, when the program starts, pthread_self returns 2, and later on it returns 9. Is this normal? If no, what can causes this?

java applications generally have a few threads, even if the main code is "single threaded". for instance, the java code could have finalizers which call your sdk, where the finalizer is run by the GC thread. you'd have to know more about the java application...

Yes, I know that JVM can create multiple threads even is the App itself is single threaded. But that is not the case here. Some more details. The Java App calls one of our function (call it FunctionA here). Inside FunctionA we call another function in our SDK lib (call it FunctionB here).

Inside FunctionA, we call pthread_self, and get 2. After that FunctionA calls FunctionB. Inside FunctionB, we call pthread_self, and get 9.

FunctionA talks to a server. So it is possible that the thread is preempted when FunctionA is waiting for the server's reply. Before it is preempted, it is running in thread 2. Then when it is loaded back, it is shifted to thread 9? Is this normal?

When the jvm calls into native code using JNI, it's basically running that code in the same way that the code would be run if you compiled and ran it from a C program. so any weird behavior you would see while your code is executing has nothing to do w/ the jvm.

Not necessarily true. From a C program, a single threaded app is really single threaded. But using JVM via JNI, even though we write a single threaded JAVA app, it is still running in a multithreaded env, right?

What I suspect is that the Java App is preempted in the middle of the execution when it is waiting for the server reply, and it is loaded back later. Since the JVM owns 9 threads, for some unknown reason, it is loaded back into a different thread. On the other hand, this won't happen in the C program case, right? The process has only one thread. Even if it is preempted for any reason, it can only be loaded back to the exact same thread.

I am not saying this is a problem of the JVM, but to figure out the root cause, I want to know if anything can cause such strange behavior.

I'm no expert by far, but I get the nagging feeling that this is actually related to multicore execution. To the outside world a Java program can be single threaded, but under the hood it may very well be that multiple (native) threads are employed to optimize for multicore execution.

But I'm -really- making wild guesses here, I have no reference at all to back that up.

989018 wrote:
Not necessarily true. From a C program, a single threaded app is really single threaded. But using JVM via JNI, even though we write a single threaded JAVA app, it is still running in a multithreaded env, right?

What I suspect is that the Java App is preempted in the middle of the execution when it is waiting for the server reply, and it is loaded back later. Since the JVM owns 9 threads, for some unknown reason, it is loaded back into a different thread. On the other hand, this won't happen in the C program case, right? The process has only one thread. Even if it is preempted for any reason, it can only be loaded back to the exact same thread.

huh? i'm saying that the jvm invoking native code is exactly the same as a C program invoking the code. anything that could happen in the C program could happen in the jvm invoked JNI program. the jvm is not using some other magical version of system threads which are different than the system threads used by a C program.

gimbal2 wrote:
I'm no expert by far, but I get the nagging feeling that this is actually related to multicore execution. To the outside world a Java program can be single threaded, but under the hood it may very well be that multiple (native) threads are employed to optimize for multicore execution.

But I'm -really- making wild guesses here, I have no reference at all to back that up.

not on any jvm that i am aware of. most modern jvms use native threads. back in the day, the sun jvm had a "green threads" option where each "java thread" was not necessarily tied to a specific native thread, however i don't think that exists anymore. dunno if there are any other jvm impls which do this sort of thing, but certainly not the oracle/openjdk jvm.

regardless, that doesn't have anything to do with the OP, who is referring to native code execution, not java byte code execution.

We can't reproduce the problem locally. Our customer is using jdk_1.6.0_35 that came with the WebLogic installation. We don't have WebLogic, and we use jse_1.6.0_35 in our local test. Are those two very different?

989018 wrote:
We can't reproduce the problem locally. Our customer is using jdk_1.6.0_35 that came with the WebLogic installation. We don't have WebLogic, and we use jse_1.6.0_35 in our local test. Are those two very different?

Thanks again.

Why not execute your C++ program from directly from the OS and see if the problem goes away. My guess is that it won't go away and therefore the problem has nothing to do with java.