incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bobrovsky, Konstantin S" <konstantin.s.bobrov...@intel.com>
Subject RE: Diagnosing JNI problems
Date Wed, 25 Nov 2009 14:27:09 GMT
Hi Stuart, all,

>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.

I did not actually see API parts which are principally not implementable - maybe I overlooked
something - could you please list them?

Can RI just throw some "DataUnavailable" exceptions in where it is hard to implement something
quickly for the "non-coredump" mode (which is the primary focus now, as I can see)?

BTW, I tried a simple JNI-involving application on hotspot/ia32, and I can see that it reports
interleaving frames of native JNI methods correctly up to the last Java frame:

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  ClassToLoad.nativeMethodWhichCrashes()V+0
j  ClassToLoad.<clinit>()V+8
v  ~StubRoutines::call_stub
j  JNITest.nativeMethod1()V+0
j  JNITest.JAVA_intermediateCall0()V+8
j  JNITest.JAVAMethod()V+8
v  ~StubRoutines::call_stub
j  JNITest.nativeMethod2()V+0
v  ~StubRoutines::call_stub
j  JNITest.nativeMethod0()V+0
j  JNITest.main([Ljava/lang/String;)V+0
v  ~StubRoutines::call_stub

(I can send you the test sources if you want). I did not try it on JRockit or any other JVM
though.

>     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.

Again, for hotspot it is pretty feasible. Pointer to the code of native method is kept within
a structure corresponding to this method.

What I can see is that CJVMTI-agent-produced dumps can not provide all the information necessary
to implement every part of current Kato API. But with core files much more data is available,
so we should not drop API parts which can't be implemented based on one of the artifact producers.


BTW, in the beginning of this JSR we spoke of possibility of using Sun's Serviceability Agent
implementation as another basis for implementation. Does anyone know of the status on this?

Thanks,
Konst
 
Intel Novosibirsk
Closed Joint Stock Company Intel A/O
Registered legal address: Krylatsky Hills Business Park, 
17 Krylatskaya Str., Bldg 4, Moscow 121614, 
Russian Federation
 

>-----Original Message-----
>From: Stuart Monteith [mailto:stukato@stoo.me.uk]
>Sent: Tuesday, November 24, 2009 7:54 PM
>To: kato-spec@incubator.apache.org
>Subject: Diagnosing JNI problems
>
>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