From kato-spec-return-280-apmail-incubator-kato-spec-archive=incubator.apache.org@incubator.apache.org Thu Nov 26 07:57:33 2009 Return-Path: Delivered-To: apmail-incubator-kato-spec-archive@minotaur.apache.org Received: (qmail 94770 invoked from network); 26 Nov 2009 07:57:33 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 26 Nov 2009 07:57:33 -0000 Received: (qmail 46079 invoked by uid 500); 26 Nov 2009 07:57:33 -0000 Delivered-To: apmail-incubator-kato-spec-archive@incubator.apache.org Received: (qmail 46043 invoked by uid 500); 26 Nov 2009 07:57:33 -0000 Mailing-List: contact kato-spec-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: kato-spec@incubator.apache.org Delivered-To: mailing list kato-spec@incubator.apache.org Received: (qmail 46033 invoked by uid 99); 26 Nov 2009 07:57:32 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 26 Nov 2009 07:57:32 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of spoole167@googlemail.com designates 209.85.219.220 as permitted sender) Received: from [209.85.219.220] (HELO mail-ew0-f220.google.com) (209.85.219.220) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 26 Nov 2009 07:57:21 +0000 Received: by ewy20 with SMTP id 20so277477ewy.20 for ; Wed, 25 Nov 2009 23:57:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=yYehfN3DwMxU5wMQNrupW29t0JexPuwIIUQeOkQSVEY=; b=skdoRXqLB9lV9N50P5wsBZkP5i7BpyPxmS5dBd238ymxwfmc4L274WijK7gSpDhddC YpCDd5L3TnlH223GZrMXoLHWO0x/87yYdUHL7/o9VKdKobn5+Z+ldNwRZR4NX029xaiu 9BYmE/vHVRGOUYMHjt5mgxFFPdrlgrb1zK4sk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=FMIEghb12L0n/UYg5IZ5F5FJ8+BPupL1OsaQKZzXIWPjGJZCVXpMx1pJTVwJzJzQu1 tY4hO3X4qAG40VnPIweFwrSj44wptoqIPG8LbOgApf9UTrdnnNNvzw9+F2779SGRBpgC frUhcWUBzAF2brDRLV5lvLsXhy27t4IZGMZok= MIME-Version: 1.0 Received: by 10.213.0.195 with SMTP id 3mr2420892ebc.81.1259222221362; Wed, 25 Nov 2009 23:57:01 -0800 (PST) In-Reply-To: References: <4B0BE569.2030307@stoo.me.uk> Date: Thu, 26 Nov 2009 07:57:01 +0000 Message-ID: Subject: Re: Diagnosing JNI problems From: Steve Poole To: kato-spec@incubator.apache.org Content-Type: multipart/alternative; boundary=000e0cd1fd7232989404794185d6 X-Virus-Checked: Checked by ClamAV on apache.org --000e0cd1fd7232989404794185d6 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 25, 2009 at 2:27 PM, Bobrovsky, Konstantin S < konstantin.s.bobrovsky@intel.com> wrote: > 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)? > > Yes its possible that an implementation can do that - my general concern though is about having too many methods , interfaces, classes etc that do nothing in the RI. If we have a specification in which a few methods are not implemented in the RI I'd be comfortable but not if the number becomes excessive. Historically for JSRs the RI is almost always the only implementation. The RI then has to be a credible , useful, implementation running against the Sun JVM. Building an implementation that uses core files requires understanding of the data structures inside the JVM. That information is available in OpenJDK but the licence is wrong for Apache and the amount of work is substantial. 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.()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? > > Nicholas Sterling worked hard for us with Sun to get the SA interface amended so that it was covered under the classpath exception ( http://openjdk.java.net/legal/gplv2+ce.html ) Unfortunately this was not possible. To be honest though we did think that the runtime restrictions imposed by SA (ie need to run with same build of JVM) was going to cause us problems and reduce adoption. 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/ > > -- Steve --000e0cd1fd7232989404794185d6--