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 Tue, 28 Jul 2009 15:19:21 GMT
On Mon, Jul 27, 2009 at 7:39 PM, Steve Poole <spoole167@googlemail.com>wrote:

>
>
> 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 :-)
>
>
I've applied this change to the API. It will be visible in the next drop of
the spec doc

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