incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Monteith <stuk...@stoo.me.uk>
Subject Diagnosing JNI problems
Date Tue, 24 Nov 2009 13:53:45 GMT
Hello,
     I've just been looking at JNI and how we go about diagnosing 
crashes within that.
There are a number of weaknesses in this area in the API and the 
implementation of the
CJVMTI agent

In the API we are unable to:
     1. Determine the call stack through VM, JNI and native stack 
frames, with the correct
         interleaving. For example:

native      pthread_cond_wait()
native      Java_java_lang_Object_wait()
JNI         Object.wait()
Java        TestArticle.halt()

     2. We have no information on local and global variables in native code.
         This would would very useful for diagnosing native problem. Of 
course,
         if we could do that, we would essentially have gdb in Java.

     3. The JavaClass API does not easily allow us to determine the 
native function that implements
         a native method. While we can retrieve bytecode and compiled 
code sections, there is nothing
         to indicate where native code is held.

The implementation has issues too:

     1. There is very little to no native information. Native threads 
are entirely missing, for instance.

     2. The CJVMTI agent is not invoked during a JVM crash, which means 
that they cannot be diagnosed
         using our RI as it stands just now. There are the core file 
readers, but we'd need to decide
         how they would operate.

Practicably, unless we can address the implementation issues, the API 
issues are moot.
Given that, I'd propose that we concentrate on the Java API, and remove 
the Image API parts that cannot
be implemented, which will be unavoidable if we are to have a credible 
RI for the TCK.


Regards,
     Stuart

-- 
Stuart Monteith
http://blog.stoo.me.uk/


Mime
View raw message