incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Monteith <>
Subject Re: New draft versin of spec
Date Mon, 27 Jul 2009 16:26:14 GMT
Hi Konstantin,
    Thanks for you comments, I've added mine inline below.


Bobrovsky, Konstantin S wrote:
> Hi Steve, all,
> FYI: I added some comments to the Kato javadoc @
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) seems a specialization of kato.runtime, so could be used

> (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.
I'll fix these up when I come across them. I've been reviewing the Java 

> (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.
> ====================
> 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:


> 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 

> (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.
    ImagePointer JavaMethodIncarnation.getEntryPoint()

JavaMethodIncarnation is a placeholder for perhaps a more sensible name.
> -----Original Message-----
> From: Steve Poole [] 
> Sent: Sunday, July 26, 2009 12:17 AM
> To:
> 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.
> Cheers
> Steve

Stuart Monteith

View raw message