incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bobrovsky, Konstantin S" <konstantin.s.bobrov...@intel.com>
Subject RE: Do we need to change the scope of the API design?
Date Wed, 02 Dec 2009 05:07:49 GMT
Hi Stuart,

>I think the API needs a little restructuring to make it unnecessary to
>traverse the Image API to get to the JavaRuntime

+1

>I understand that the Image is considered part of the Image API, but
>perhaps that can change.

I think what you propose is enough grounds for the change. I think few more changes would
be nice. How about: 

interface SystemInformation {
    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;
    public String getHostName() throws
        DataUnavailable, CorruptDataException;
    public Iterator<InetAddress> getIPAddresses()
        throws DataUnavailable;
}

interface Dump {
    SystemInformation getSystemInformation();
    List<ManagedRuntime> getRuntimes();
    long getCreationTime() throws DataUnavailable;

      /** @return value of an arbitrary property with given name or null */
	String getProperty(String key);
	String getIntProperty(String key);
}

interface ProcessImage extends Dump {
    List<ImageAddressSpaces> getAddressSpaces();
}

I assume, the org.apache.kato.FactoryRegistry will be preserved in the API and will be the
source for tools to get Images ("Dumps" in my interpretation above) for artifacts of different
types.

BTW, with the Image (Dump) extension to cover all dump types, the FactoryRegsitry framework
seems to fill the need in 'a framework similar to javax.imageio.spi but more light-weight'
I suggested earlier.

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: Stuart Monteith [mailto:stukato@stoo.me.uk]
>Sent: Tuesday, December 01, 2009 5:47 PM
>To: kato-spec@incubator.apache.org
>Subject: Re: Do we need to change the scope of the API design?
>
>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