incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Monteith <stuk...@stoo.me.uk>
Subject Re: Do we need to change the scope of the API design?
Date Tue, 01 Dec 2009 11:46:41 GMT
Hi,
     I would like to see us being able to access debugging information 
from the core-file readers through the Image API.
Being able to access it would allow some meaningful analysis to be done 
on the core file.

I think the API needs a little restructuring to make it unnecessary to 
traverse the Image API to get to the JavaRuntime, which makes
sense for non-core file dump types and is convenient for those 
applications only interested in analyzing the JavaRuntime. Not having
to traverse faked address spaces, and processes. One point I would like 
to make is that there is information in the Image that could
be provided for the JavaRuntime case.

For example:

     interface Image {
         List<ImageAddressSpaces> getAddressSpaces();
         String getProcessorType() throws DataUnavailable, 
CorruptDataException;
         String getProcessorSubType() throws DataUnavailable, 
CorruptDataException;
         int getProcessorCount() throws DataUnavailable;
         String getSystemType() throws DataUnavailable, 
CorruptDataException;
         String getSystemSubType() throws DataUnavailable, 
CorruptDataException;
         long getInstalledMemory() throws DataUnavailable;
         long getCreationTime() throws DataUnavailable;
         public String getHostName() throws DataUnavailable, 
CorruptDataException;
         public Iterator<InetAddress> getIPAddresses() throws 
DataUnavailable;

         List<ManagedRuntime> getRuntimes():
     }

I understand that the Image is considered part of the Image API, but 
perhaps that can change. Either way, dump formats without the
Image information would return an empty list in getAddressSpaces(), but 
could still report on the other information as well as returning
a JavaRuntime in getRuntimes(). For example, the CJVMTI API returns the 
creation time that was gathered when the dump was being generated - the 
rest of the Image object could be returned without too much trouble.


The CJVMTI API fakes an address space and process so that a JavaRuntime 
can be retrieved. I wouldn't look too closely at those object
though.

Yes, it was always the intention that the API would provide a consistent 
view of JVMs regardless of how the dump artifact was generated
and what was generating them. This work was spawned off from IBM's DTFJ 
which allows both the 1.4.2 and 5.0+ JVMs to be accesses
consistently even though they are completely different implementations. 
There also exists DTFJ implementations that can access other
dump types.

Of course, where I have written "consistent" read "consistent as 
possible", we try hard to address this problem, but it can be difficult to
balance making the API completely generic and exposing implementation 
specific details.

Regards,
     Stuart


Bobrovsky, Konstantin S wrote:
> Hi Steve, all,
>
> >-8 snip
>
> I think this is a good idea. Process-level core file analysis sometimes helps too and
it is good to standardize such things as ImageRegister/Process/Module/Section, etc.
>
> Instead of ImageProcess.getRuntimes, the task of (future) getting a JavaRuntime for a
core file by a 3rd party tool can probably be solved in another way.
>
> AFAIU, current RI uses an output from the CJVMTI agent (HPROF alternative) as the source
artifact for building a JavaRuntime based on it - is that correct? How do you envision tools
getting an instance of the JavaRuntime for the CJVMTI dump (the API does not seem to provide
a way)? I think the same mechanism can be used by tools to get one for a process image.
>
> JavaRuntime and its constituents seems to be a central part of the API, which tools will
heavily use. So I would go little further and have the API specify a standard way in which
tools can get a JavaRuntime instance for a given type of artifact. A good metaphor here is,
IMO, media files using different compression algorithms and codecs which are able to decode
them. And a framework similar to javax.imageio.spi (http://java.sun.com/j2se/1.5.0/docs/api/javax/imageio/spi/package-summary.html),
but more light-weight could be developed, so that a tool knowing input artifact type could
get a factory which can produce a JavaRuntime for it. In the initial RI there could only be
one supported artifact type - CJVMTI dump. This way no one can say the API does not have any
implementation. In the future, if someone decides to write, say, SA-based JavaRuntime provider
for core files, tool users would easily plug the implementation into their tools, provided
that the API specifies a consistent algorithm of "JavaRuntime providers" search.
>
> 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
>
>
>    
>> -----Original Message-----
>> From: Steve Poole [mailto:spoole167@googlemail.com]
>> Sent: Saturday, November 28, 2009 10:08 PM
>> To: kato-spec@incubator.apache.org
>> Subject: Re: Do we need to change the scope of the API design?
>>
>> On Fri, Nov 27, 2009 at 10:35 AM, Bobrovsky, Konstantin S<
>> konstantin.s.bobrovsky@intel.com>  wrote:
>> >-8 snip
>>      
>> --
>> Steve
>>      

-- 
Stuart Monteith
http://blog.stoo.me.uk/



Mime
View raw message