incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bobrovsky, Konstantin S" <>
Subject RE: New draft versin of spec
Date Mon, 27 Jul 2009 03:56:11 GMT
Hi Steve, all,

FYI: I added some comments to the Kato javadoc @
I'm resending them to this list for convenience.

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

(1) seems a specialization of kato.runtime, so could be used instead.

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

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



There should also be a way to get the address the module was loaded at and, if possible, its


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.

'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 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.


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.

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.


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


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.

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?

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

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.

-----Original Message-----
From: Steve Poole [] 
Sent: Sunday, July 26, 2009 12:17 AM
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.



View raw message