incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Poole <spoole...@googlemail.com>
Subject Re: New draft versin of spec
Date Mon, 27 Jul 2009 18:39:02 GMT
On Mon, Jul 27, 2009 at 5:26 PM, Stuart Monteith <stukato@stoo.me.uk> 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<JavaMethodIncarnation> JavaMethod.getIncarnations()
>
> JavaMethodIncarnation JavaLocation.getMethodIncarnation()
>
> In JavaMethodIncarnation:
>   JavaMethod getMethod()
>   boolean isJITCompiled()
>   boolean isNative()
>   int compilationLevel()
>   List<ImageSection> 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/
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message