From kato-spec-return-216-apmail-incubator-kato-spec-archive=incubator.apache.org@incubator.apache.org Mon Jul 27 18:38:31 2009 Return-Path: Delivered-To: apmail-incubator-kato-spec-archive@minotaur.apache.org Received: (qmail 82047 invoked from network); 27 Jul 2009 18:38:30 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 27 Jul 2009 18:38:30 -0000 Received: (qmail 94765 invoked by uid 500); 27 Jul 2009 18:39:36 -0000 Delivered-To: apmail-incubator-kato-spec-archive@incubator.apache.org Received: (qmail 94735 invoked by uid 500); 27 Jul 2009 18:39:36 -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 94697 invoked by uid 99); 27 Jul 2009 18:39:35 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 27 Jul 2009 18:39:35 +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.220.228 as permitted sender) Received: from [209.85.220.228] (HELO mail-fx0-f228.google.com) (209.85.220.228) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 27 Jul 2009 18:39:23 +0000 Received: by fxm28 with SMTP id 28so2914756fxm.12 for ; Mon, 27 Jul 2009 11:39:02 -0700 (PDT) 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=G9whg7NrxrN4vrlmIOEdSFbfEAin0FCfflWPTOFye1g=; b=xAypdnudGxVmJNMY01W14Qh3jhtZi1i138t1VHO0d7zqhYWY72T92vcIEDB6E2XIfp 5rKs8RqXdTaOnf9Y55aGAk2xM1jkSwNK9IY5mJf5rh+JutskI1z9fMf5RLaoOI+3OTjJ ViFTtrRjh24YEOGVFw2rYCYFUsxS8jjK2g7y0= 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=BMzvfFUUNM8iycG6scWVshRaq4ophd5c0LD4NjvDQ2izQ37aGEkSkR+foDjnz4wLuN RrV28VAMPK45UcPxF11tkTF+4L0n8VSWEdAcnJGVvz+7poerQ85Aj3z9cZGKv8/jjeKC 9B+KgygcnIqnxfsxpF8C+zgGsR9Inkli840ZM= MIME-Version: 1.0 Received: by 10.204.120.201 with SMTP id e9mr3378587bkr.187.1248719942124; Mon, 27 Jul 2009 11:39:02 -0700 (PDT) In-Reply-To: <4A6DD526.3080409@stoo.me.uk> References: <4A6DD526.3080409@stoo.me.uk> Date: Mon, 27 Jul 2009 19:39:02 +0100 Message-ID: Subject: Re: New draft versin of spec From: Steve Poole To: kato-spec@incubator.apache.org Content-Type: multipart/alternative; boundary=001636c5a73d93052b046fb44473 X-Virus-Checked: Checked by ClamAV on apache.org --001636c5a73d93052b046fb44473 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Mon, Jul 27, 2009 at 5:26 PM, Stuart Monteith wrote: > Hi Konstantin, > Thanks for you comments, I've added mine inline below. > > Regards, > Stuart > > Bobrovsky, Konstantin S wrote: > >> Hi Steve, all, >> >> FYI: I added some comments to the Kato javadoc @ >> http://cwiki.apache.org/confluence/display/KATO/JavaDoc+comments. I'm >> resending them to this list for convenience. >> >> 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 >> Top-level >> ========= >> >> (1) kato.java seems a specialization of kato.runtime, so kato.runtime.java >> could be used instead. >> >> >> > +1 +1 (does that become +2 :-) > > > (2) I noticed that there are API elements in the form of List >> get[SomeEntityName]() and javadoc does not specify objects of which type >> will be returned in the resulting list. E.g. ImageThread.getStackFrames(). >> >> >> > I'll fix these up when I come across them. I've been reviewing the Java > runtime. > > (3) It would be nice to have an opportunity to create an Image* object >> from a pointer into an image (having ImagePointer instance which describes >> the start of the Image* entity) >> >> >> > Can you give an example? I can see how this might be useful for the java > API, but I don't see how it'd be useful for image. > > org.apache.kato.image >> ===================== >> >> ImageModule >> ----------- >> >> There should also be a way to get the address the module was loaded at >> and, if possible, its size. >> >> >> > I think this is a JavaDoc issue. ImageModule.getSections() returns > ImageSections that contain the information you are asking for. It is not > clear from > the doc that this is the case. > >> ImageRegister >> ------------- >> >> register names for different CPUs should probably follow the naming >> convention adopted in the official specification of this CPU. This way tools >> would work uniformly with different Kato implementations. >> >> >> > I think having us specify the register set for every possible processor > architecture is inappropriate, so I agree. > >> 'Long' or 'Integer' might be too vague for specifying register type. How >> about '64 bit' or '32 bit' plus an additional characteristic such as >> 'general purpose/floating point/application/flags/...' ? >> >> > The "Type" information is there to describe which subclass of Number will > be returned by ImageRegister.getValue(). But you're right, it doesn't > actually describe > what the register contains. > >> The register sets specified here should be complete, otherwise we could >> get implementation/tool incompatibilites for the registers missing from this >> javadoc. One of the alternative ways for specifying them could be just a >> link to the corresponding external specification. >> >> >> > I have to agree with linking to the external specification. There has to be > at least some agreement to the set of registers available. > >> org.apache.kato.java >> ==================== >> >> JavaReference >> ------------- >> >> (1) >> sometimes it is very helpful to know where the heap root actually resides >> - the corresponding CPU register and/or memory address (in a memory stack >> frame or register stack frame), and this info is usually available in Java >> runtimes. >> >> >> > So, this would be something like: ImagePointer JavaReference.getAddress() > and ImageRegister JavaReference.getRegister(), with a boolean for both? > > (2) >> It seems the API here lacks a REFERENCE_DIRIVED reference type to describe >> derived references (pointers), which point to an interrior of a Java object >> - to an array element, for example. Derived references are reported to >> Garbage Collector in pairs with references to their base Java objects. >> >> >> >> > The JavaReference types are the same as what you would get from JVMTI, so > that's why we have that limited list. > If I were to implement this, I would have had the reference just be like > any other reference to a field or element. > But if we were to expand it, I'd suggest something like the following: > > REFERENCE_DERIVED_ARRAY_ELEMENT > REFERENCE_DERIVED_OBJECT_FIELD > REFERENCE_DERIVED_CLASS_FIELD > > > JavaRuntime >> ----------- >> >> (1) We should have somewhere in the API means to iterate trough generated >> code sequences other than managed methods - so-called 'stubs'. Each stub is >> similar to a method: it has a name, (possibly, multiple) code sections. This >> interface (JavaRuntime) seems an appropriate place for this API. >> >> (2) Not all methods within a Java runtime are necessarily compiled. Many >> may remain interpreted, others might not even have a bytecode. So I would >> suggest to replace 'getCompiledMethods' with smth like 'getJavaMethods' or >> add 'getInterpretedMethods', 'getMethodsWithoutCode'. >> >> >> > The intention isn't for all of the methods to be compiled, the method will > just list those methods that are compiled. I would argue for us actually > removing the JavaRuntime.getCompiledMethods() if we don't have a reason for > including it. > > Apparently we may also have native methods that have their stubs compiled > too. > >> JavaStackFrame >> -------------- >> >> (1) >> Usually, Java stack frames contain information about Java monitors held in >> this frame. This is necessary because Java spec requires "forced" release of >> all monitors held by a method in case it "completes abruptly". So something >> like >> List getHeldMonitors() >> would be really useful. >> >> >> > I agree, having the API explictly show where monitors are held would take > people closer towards diagnosing deadlocks, as opposed to having them read > through their code and work out where they were taken. It may not always be > obvious from reading code which monitor has actually been taken. > +1 > > > (2) >> API also needs to support 'split' stack frames on Itanium - every frame >> has a traditinal memory stack frame and additionally, a register stack frame >> where Register Stack Engine (RSE) spills current register frame during a >> call (and restores from upon return). >> >> Maybe this could be done via delegating responsibility for such support to >> an Itanium-specific implementaion of the spec? >> >> >> > The API isn't very good at exposing the native information. With the > currently JavaThread.getStackSections() could return two ImageSections if > you are on IA64. > Certainly that's what we do for ImageThread.getStackSections() on IBM's > 1.4.2 IA64 Linux implementation. > > One of the the unresolved problems I have with the API is how to relate all > of the different frame types. Just now Java frame could be on it's own "Java > stack", > on the native stack as interpreted or compiled code, could be a native > method with a stub calling a C/C++ function, and we don't help with this. > For example, if you have a stack like: > > C function frame > stub frame > native method frame > compiled method frame (on native stack) > interpreted method frame (on own stack) > > how do you derive that information from the Kato API? I don't think we can. > > (3) >> while getLocation() can provide information about what method this frame >> belongs to, this method may have several compiled or interpreted >> "incarnations". So, I would suggest to add the following: >> >> boolean isCompiledFrame() >> boolean isInterpretedFrame() >> >> /** @return an ImageSection containing the compiled code to which this >> stack frame corresponds */ >> ImageSection getCode() >> >> >> > I agree with this, there can be several incarnations of a method inflight > that we aren't presenting. Contrary to your suggestion, should we make it > easy to > get all java method incarnations? I might suggest that we have: > > List JavaMethod.getIncarnations() > > JavaMethodIncarnation JavaLocation.getMethodIncarnation() > > In JavaMethodIncarnation: > JavaMethod getMethod() > boolean isJITCompiled() > boolean isNative() > int compilationLevel() > List getSections(); > > (4) >> note that sometimes methods are compiled with the entry point being not >> the first method's bytecode (compilation for so-called on-stack-replacement >> or OSR). So each compiled version of a method should also be annotated with >> bytecode index where the entry point for this compilation is. In this sense, >> ImageSection is not enough to describe a compiled code. >> >> >> > Sure, > ImagePointer JavaMethodIncarnation.getEntryPoint() > ? > > JavaMethodIncarnation is a placeholder for perhaps a more sensible name. > I can see the benefit and I agree we could look for a different name. > > -----Original Message----- >> From: Steve Poole [mailto:spoole167@googlemail.com] Sent: Sunday, July >> 26, 2009 12:17 AM >> To: kato-spec@incubator.apache.org >> Subject: New draft versin of spec >> >> I've just posted to the wiki a docbook based version of the specification. >> Still needs work but a lot better than it was. >> >> >> >> http://cwiki.apache.org/confluence/download/attachments/2326547/spec-edr-25july2009.pdf >> >> Cheers >> >> Steve >> >> > > -- > Stuart Monteith > http://blog.stoo.me.uk/ > > --001636c5a73d93052b046fb44473--