You are viewing a plain text version of this content. The canonical link for it is here.
Posted to kato-spec@incubator.apache.org by Steve Poole <sp...@googlemail.com> on 2009/11/25 13:44:24 UTC
Do we need to change the scope of the API design?
Stuart's note on diagnosing JNI problems (thanks for the review Stuart) has
touched on a key point concerning what we want to do and what we can do.
I think its time we discuss where we are and what happens next.
Our desire to specify an API that helps people solve problems has to be
tempered with practical implementation considerations. The API design
that IBM contributed to the Kato project is satisfiable by IBM JVMs (of
course), but for us to develop a matching reference implementation we know
now that we need to get much more information from the Sun JVM than we have
today. Developing a full solution to match the API as it stands today is
difficult for the Kato project as the code we would need to access is in
OpenJDK and is under the GPL.
Practically, we have few choices. We could
1 - Get a JVM Vendor to produce , or commit to produce an implementation
that fully covers the Image API side.
2 - Remove all the Image API side from the design
3 - Find a halfway point where some of the Image API stays and is optional.
I've had many conversations with people concerning option 1 and the response
is generally that its too expensive for the potential return. Both for
implementation and ongoing maintenance.
Option 2 seems very draconian - the ability to get at some of the native
information (such as the native thread for a Java thread) just seems too
useful to remove.
I'd opt for us moving the API design towards option 3 - there are some basic
changes we could do such as extracting the native access methods into a
separate interface and allowing the implementer the choice to use it.
We still need to get access to more data from the JVM (and perhaps in better
ways) than we have today. We need to get this data in such a manner as not
to require accessing GPL code and in a way that is cheap to maintain as the
JVM evolves.
My idea for resolving this conundrum is to propose that we include in our
API design either a new JVM 'C' API or extensions to JVMTI. We would not
implement these additions in the RI but would rely on others to provide an
implementation. (We would design the RI and the API to make this extra
information optional)
Comments?
--
Steve
RE: Do we need to change the scope of the API design?
Posted by "Bobrovsky, Konstantin S" <ko...@intel.com>.
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/
>
Re: Do we need to change the scope of the API design?
Posted by Stuart Monteith <st...@stoo.me.uk>.
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/
RE: Do we need to change the scope of the API design?
Posted by "Bobrovsky, Konstantin S" <ko...@intel.com>.
Hi Steve, all,
>I realised that when I talk about dropping the Image API its actually
>because we can't implement the Java Runtime API by reading from a core
>file. Not because we can't read a corefile. Now my sizing was based on
>the
>need to implement the whole of the API. The killer cost is the
>JavaRuntime
>piece. You need to be able to understand the internal layout of the JVM
>structures and learn how they stick together etc.
>
>If we agree that there is value in keeping the Image API around as a means
>of reading the contents of a core file without being able to get at Java
>Runtime information then we could do so. In that vision we'd just remove
>the ability to get a JavaRuntime object from the Image API - ie this
>method
>(
>http://hudson.zones.apache.org/hudson/view/Kato/job/kato.api-
>head/javadoc/org/apache/kato/image/ImageProcess.html#getRuntimes%28%29)
>would go.
>
>There are other little changes still required but the general idea seems
>quite reasonable. - just comes down to the value of corefile readers
>themselves
>
> What do you think?
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:
>
>> Steve,
>>
>> I see what you mean, thank you for the clarifications. I agree that
>having
>> an RI where a big chunk of the API is unimplemented can be quite
>frustrating
>> for end users. My only concern is the potential decrease in usability of
>> Kato-based products when the Image API is removed.
>> When there is an internal VM error such as wrong JIT-generated
>code
>> leading to a crash, we can not know beforehand what data will be
>> required to diagnose the problem. Having all available data (core
>> dump) is ideal.
>> In the beginning of the JSR many use cases have been developed, and it
>> would be interesting to estimate what share of them will be dropped with
>> dropping the Image API. What leaves a hope when Image API is gone :-) is
>> remaining opportunity for JVM vendors to still produce Kato
>implementations
>> which can read core dumps and still plug into the Kato-conforming set of
>> tools developed by 3rd parties. The loss would be a thick non-
>standardized
>> layer where external tools developers can't adhere to.
>>
>> > The runtime restrictions on the SA really effect it's usefulness for
>end
>> > users of our API.
>>
>> Are these impossibility to sell tools based on Kato implementation which
>> use SA source code or binaries? We have probably already discussed these
>> restrictions in the past, but I forgot, sorry.
>>
>> Its not an impossibility but without the classpath exception we can't
>build
>an implementation in Apache. The other problem is simply that SA needed
>you have have the same OS and JVM as the customer when analysing the dump.
>
>
>> > The cost of writing a corefile reader for hotspot is also
>> > quite large - it could easily take someone 6 months to write or more.
>>
>> That's pretty pessimistic, IMO :) (at least for the part covering Image
>> API). 3-5 months would be enough, in my estimation. But that's still big
>> chunk of work, I agree.
>>
>>
>I realised that when I talk about dropping the Image API its actually
>because we can't implement the Java Runtime API by reading from a core
>file. Not because we can't read a corefile. Now my sizing was based on
>the
>need to implement the whole of the API. The killer cost is the
>JavaRuntime
>piece. You need to be able to understand the internal layout of the JVM
>structures and learn how they stick together etc.
>
>If we agree that there is value in keeping the Image API around as a means
>of reading the contents of a core file without being able to get at Java
>Runtime information then we could do so. In that vision we'd just remove
>the ability to get a JavaRuntime object from the Image API - ie this
>method
>(
>http://hudson.zones.apache.org/hudson/view/Kato/job/kato.api-
>head/javadoc/org/apache/kato/image/ImageProcess.html#getRuntimes%28%29)
>would go.
>
>There are other little changes still required but the general idea seems
>quite reasonable. - just comes down to the value of corefile readers
>themselves
>
> What do you think?
>
>
>
>
>Thanks,
>> Konst
>>
>>
>> >-----Original Message-----
>> >From: Steve Poole [mailto:spoole167@googlemail.com]
>> >Sent: Friday, November 27, 2009 3:34 PM
>> >To: kato-spec@incubator.apache.org
>> >Subject: Re: Do we need to change the scope of the API design?
>> >
>> >On Thu, Nov 26, 2009 at 5:02 AM, Bobrovsky, Konstantin S <
>> >konstantin.s.bobrovsky@intel.com> wrote:
>> >
>> >> Hi Steve,
>> >>
>> >> I think the first option would be ideal of course. But I assume the
>> >> initiative to develop RI based on Sun's Serviceability Agent (which
>> would
>> >> lower the implementation cost dramatically) has failed because of
>> >> GPL-related issues. I wish there was a volunteer from the open-source
>> who
>> >> could adapt SA to the KATO API...
>> >>
>> >> That would be nice Konst. To be honest though, if I was wishing for
>help
>> >like this I would prefer to have someone work with us on creating the
>> >extended JVMTI or new C API interface as I wrote about previously.
>The
>> >runtime restrictions on the SA really effect it's usefulness for end
>users
>> >of our API. The cost of writing a corefile reader for hotspot is
>also
>> >quite large - it could easily take someone 6 months to write or more.
>> >Therefore I'd rather be pragmatic about this and focus on what can be
>done
>> >by us and what people say they want.
>> >
>> >From the other two, the second one (remove Image API) IMO would very
>much
>> >> discord with the original message of the JSR (*postmortem* analysis,
>> >which
>> >> means digging through the core dumps). So I'd vote for leaving as much
>> as
>> >> possible of the Image API in the spec, making parts optional as
>needed.
>> >>
>> >
>> >I understand about changing the message but I feel uncomfortable to say
>> the
>> >least to have a large part of our API not supported by the Reference
>> >Implementation. I will put together a proposal and explain what I
>think
>> >needs to be done.
>> >
>> >You can look at this from anoher point of view. We know that core file
>> >sizes are rising ( 8-30GB production heap sizes are now common) and we
>> >agreed thereforet at some point core files would become untenable.
>> That's
>> >why we have the "snapshot" api idea. It seems that for most people the
>> >usefulness of corefiles is already in doubt so lets focus on producing
>a
>> >new modern dump mechanism that is fast, scaleable, content configurable
>> >and generally cross JVM. Since we will be developing a reference
>> >implementation to go with the design we will effectively be producing a
>> >modern replacement for HPROF and since the format for this dump is not
>> part
>> >of the specification (as we have agreed that data formats are always
>> >constraining) we will not get rocks thrown at us by JVM vendors who want
>> to
>> >implement their own alternatives.
>> >
>> >I think developing the HPROF alternative is the right place to go.
>Users
>> >will understand the concept and we might actually gain input from
>existing
>> >HPROF users who want to see improvements made.
>> >
>> >We are building the current implementation just using JVMTI. Thats not
>> >good
>> >enough and we need to find ways of getting more data out of a JVM.
>Hence
>> >the idea of improving JVMTI or adding some new API. That is probably
>> >not
>> >the right way either but lets discuss..
>> >
>> >
>> >> 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: Wednesday, November 25, 2009 7:44 PM
>> >> >To: kato-spec@incubator.apache.org
>> >> >Subject: Do we need to change the scope of the API design?
>> >> >
>> >> >Stuart's note on diagnosing JNI problems (thanks for the review
>Stuart)
>> >> has
>> >> >touched on a key point concerning what we want to do and what we can
>> >do.
>> >> >
>> >> >I think its time we discuss where we are and what happens next.
>> >> >
>> >> >Our desire to specify an API that helps people solve problems has to
>be
>> >> >tempered with practical implementation considerations. The API
>> design
>> >> >that IBM contributed to the Kato project is satisfiable by IBM JVMs
>(of
>> >> >course), but for us to develop a matching reference implementation
>we
>> >> know
>> >> >now that we need to get much more information from the Sun JVM than
>we
>> >> have
>> >> >today. Developing a full solution to match the API as it stands
>today
>> >is
>> >> >difficult for the Kato project as the code we would need to access is
>> in
>> >> >OpenJDK and is under the GPL.
>> >> >
>> >> >Practically, we have few choices. We could
>> >> >
>> >> >1 - Get a JVM Vendor to produce , or commit to produce an
>> >implementation
>> >> >that fully covers the Image API side.
>> >> >2 - Remove all the Image API side from the design
>> >> >3 - Find a halfway point where some of the Image API stays and is
>> >> optional.
>> >> >
>> >> >I've had many conversations with people concerning option 1 and the
>> >> >response
>> >> >is generally that its too expensive for the potential return. Both
>for
>> >> >implementation and ongoing maintenance.
>> >> >
>> >> >Option 2 seems very draconian - the ability to get at some of the
>> >native
>> >> >information (such as the native thread for a Java thread) just seems
>> too
>> >> >useful to remove.
>> >> >
>> >> >I'd opt for us moving the API design towards option 3 - there are
>some
>> >> >basic
>> >> >changes we could do such as extracting the native access methods into
>a
>> >> >separate interface and allowing the implementer the choice to use it.
>> >> >
>> >> >We still need to get access to more data from the JVM (and perhaps in
>> >> >better
>> >> >ways) than we have today. We need to get this data in such a manner
>as
>> >> not
>> >> >to require accessing GPL code and in a way that is cheap to maintain
>as
>> >> the
>> >> >JVM evolves.
>> >> >
>> >> >My idea for resolving this conundrum is to propose that we include in
>> >our
>> >> >API design either a new JVM 'C' API or extensions to JVMTI. We would
>> >not
>> >> >implement these additions in the RI but would rely on others to
>provide
>> >an
>> >> >implementation. (We would design the RI and the API to make this
>extra
>> >> >information optional)
>> >> >
>> >> >Comments?
>> >> >
>> >> >
>> >> >--
>> >> >Steve
>> >>
>> >
>> >
>> >
>> >--
>> >Steve
>>
>
>
>
>--
>Steve
Re: Do we need to change the scope of the API design?
Posted by Steve Poole <sp...@googlemail.com>.
On Fri, Nov 27, 2009 at 10:35 AM, Bobrovsky, Konstantin S <
konstantin.s.bobrovsky@intel.com> wrote:
> Steve,
>
> I see what you mean, thank you for the clarifications. I agree that having
> an RI where a big chunk of the API is unimplemented can be quite frustrating
> for end users. My only concern is the potential decrease in usability of
> Kato-based products when the Image API is removed.
> When there is an internal VM error such as wrong JIT-generated code
> leading to a crash, we can not know beforehand what data will be
> required to diagnose the problem. Having all available data (core
> dump) is ideal.
> In the beginning of the JSR many use cases have been developed, and it
> would be interesting to estimate what share of them will be dropped with
> dropping the Image API. What leaves a hope when Image API is gone :-) is
> remaining opportunity for JVM vendors to still produce Kato implementations
> which can read core dumps and still plug into the Kato-conforming set of
> tools developed by 3rd parties. The loss would be a thick non-standardized
> layer where external tools developers can't adhere to.
>
> > The runtime restrictions on the SA really effect it's usefulness for end
> > users of our API.
>
> Are these impossibility to sell tools based on Kato implementation which
> use SA source code or binaries? We have probably already discussed these
> restrictions in the past, but I forgot, sorry.
>
> Its not an impossibility but without the classpath exception we can't build
an implementation in Apache. The other problem is simply that SA needed
you have have the same OS and JVM as the customer when analysing the dump.
> > The cost of writing a corefile reader for hotspot is also
> > quite large - it could easily take someone 6 months to write or more.
>
> That's pretty pessimistic, IMO :) (at least for the part covering Image
> API). 3-5 months would be enough, in my estimation. But that's still big
> chunk of work, I agree.
>
>
I realised that when I talk about dropping the Image API its actually
because we can't implement the Java Runtime API by reading from a core
file. Not because we can't read a corefile. Now my sizing was based on the
need to implement the whole of the API. The killer cost is the JavaRuntime
piece. You need to be able to understand the internal layout of the JVM
structures and learn how they stick together etc.
If we agree that there is value in keeping the Image API around as a means
of reading the contents of a core file without being able to get at Java
Runtime information then we could do so. In that vision we'd just remove
the ability to get a JavaRuntime object from the Image API - ie this method
(
http://hudson.zones.apache.org/hudson/view/Kato/job/kato.api-head/javadoc/org/apache/kato/image/ImageProcess.html#getRuntimes%28%29)
would go.
There are other little changes still required but the general idea seems
quite reasonable. - just comes down to the value of corefile readers
themselves
What do you think?
Thanks,
> Konst
>
>
> >-----Original Message-----
> >From: Steve Poole [mailto:spoole167@googlemail.com]
> >Sent: Friday, November 27, 2009 3:34 PM
> >To: kato-spec@incubator.apache.org
> >Subject: Re: Do we need to change the scope of the API design?
> >
> >On Thu, Nov 26, 2009 at 5:02 AM, Bobrovsky, Konstantin S <
> >konstantin.s.bobrovsky@intel.com> wrote:
> >
> >> Hi Steve,
> >>
> >> I think the first option would be ideal of course. But I assume the
> >> initiative to develop RI based on Sun's Serviceability Agent (which
> would
> >> lower the implementation cost dramatically) has failed because of
> >> GPL-related issues. I wish there was a volunteer from the open-source
> who
> >> could adapt SA to the KATO API...
> >>
> >> That would be nice Konst. To be honest though, if I was wishing for help
> >like this I would prefer to have someone work with us on creating the
> >extended JVMTI or new C API interface as I wrote about previously. The
> >runtime restrictions on the SA really effect it's usefulness for end users
> >of our API. The cost of writing a corefile reader for hotspot is also
> >quite large - it could easily take someone 6 months to write or more.
> >Therefore I'd rather be pragmatic about this and focus on what can be done
> >by us and what people say they want.
> >
> >From the other two, the second one (remove Image API) IMO would very much
> >> discord with the original message of the JSR (*postmortem* analysis,
> >which
> >> means digging through the core dumps). So I'd vote for leaving as much
> as
> >> possible of the Image API in the spec, making parts optional as needed.
> >>
> >
> >I understand about changing the message but I feel uncomfortable to say
> the
> >least to have a large part of our API not supported by the Reference
> >Implementation. I will put together a proposal and explain what I think
> >needs to be done.
> >
> >You can look at this from anoher point of view. We know that core file
> >sizes are rising ( 8-30GB production heap sizes are now common) and we
> >agreed thereforet at some point core files would become untenable.
> That's
> >why we have the "snapshot" api idea. It seems that for most people the
> >usefulness of corefiles is already in doubt so lets focus on producing a
> >new modern dump mechanism that is fast, scaleable, content configurable
> >and generally cross JVM. Since we will be developing a reference
> >implementation to go with the design we will effectively be producing a
> >modern replacement for HPROF and since the format for this dump is not
> part
> >of the specification (as we have agreed that data formats are always
> >constraining) we will not get rocks thrown at us by JVM vendors who want
> to
> >implement their own alternatives.
> >
> >I think developing the HPROF alternative is the right place to go. Users
> >will understand the concept and we might actually gain input from existing
> >HPROF users who want to see improvements made.
> >
> >We are building the current implementation just using JVMTI. Thats not
> >good
> >enough and we need to find ways of getting more data out of a JVM. Hence
> >the idea of improving JVMTI or adding some new API. That is probably
> >not
> >the right way either but lets discuss..
> >
> >
> >> 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: Wednesday, November 25, 2009 7:44 PM
> >> >To: kato-spec@incubator.apache.org
> >> >Subject: Do we need to change the scope of the API design?
> >> >
> >> >Stuart's note on diagnosing JNI problems (thanks for the review Stuart)
> >> has
> >> >touched on a key point concerning what we want to do and what we can
> >do.
> >> >
> >> >I think its time we discuss where we are and what happens next.
> >> >
> >> >Our desire to specify an API that helps people solve problems has to be
> >> >tempered with practical implementation considerations. The API
> design
> >> >that IBM contributed to the Kato project is satisfiable by IBM JVMs (of
> >> >course), but for us to develop a matching reference implementation we
> >> know
> >> >now that we need to get much more information from the Sun JVM than we
> >> have
> >> >today. Developing a full solution to match the API as it stands today
> >is
> >> >difficult for the Kato project as the code we would need to access is
> in
> >> >OpenJDK and is under the GPL.
> >> >
> >> >Practically, we have few choices. We could
> >> >
> >> >1 - Get a JVM Vendor to produce , or commit to produce an
> >implementation
> >> >that fully covers the Image API side.
> >> >2 - Remove all the Image API side from the design
> >> >3 - Find a halfway point where some of the Image API stays and is
> >> optional.
> >> >
> >> >I've had many conversations with people concerning option 1 and the
> >> >response
> >> >is generally that its too expensive for the potential return. Both for
> >> >implementation and ongoing maintenance.
> >> >
> >> >Option 2 seems very draconian - the ability to get at some of the
> >native
> >> >information (such as the native thread for a Java thread) just seems
> too
> >> >useful to remove.
> >> >
> >> >I'd opt for us moving the API design towards option 3 - there are some
> >> >basic
> >> >changes we could do such as extracting the native access methods into a
> >> >separate interface and allowing the implementer the choice to use it.
> >> >
> >> >We still need to get access to more data from the JVM (and perhaps in
> >> >better
> >> >ways) than we have today. We need to get this data in such a manner as
> >> not
> >> >to require accessing GPL code and in a way that is cheap to maintain as
> >> the
> >> >JVM evolves.
> >> >
> >> >My idea for resolving this conundrum is to propose that we include in
> >our
> >> >API design either a new JVM 'C' API or extensions to JVMTI. We would
> >not
> >> >implement these additions in the RI but would rely on others to provide
> >an
> >> >implementation. (We would design the RI and the API to make this extra
> >> >information optional)
> >> >
> >> >Comments?
> >> >
> >> >
> >> >--
> >> >Steve
> >>
> >
> >
> >
> >--
> >Steve
>
--
Steve
RE: Do we need to change the scope of the API design?
Posted by "Bobrovsky, Konstantin S" <ko...@intel.com>.
Hi Stuart,
This makes sense to me - thank you. I'm fine with basically any approach which makes it possible to plug-in parsers of different dump types in the future, and it was the original intent of the JSR, as I recall. I think it is fully OK if the initial RI can handle artifacts of only 1 type, provided that the API prescribes recipes for easy addition of new ones in the future.
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: Friday, November 27, 2009 11:50 PM
>To: kato-spec@incubator.apache.org
>Subject: Re: Do we need to change the scope of the API design?
>
>Hi Konstantin,
> Without a proper implementation of the Image API we are missing a
>whole raft of use cases, specifically those to do with
>JVM or JNI library diagnosis.
>
>While we might aim to do an implementation of the Kato API that could
>cope with heaps measured in 10s of gigabytes, I don't think the RI
>should. I'd fully expect there to be use cases for smaller JVMs,
>especially those applications that run on desktop machines. Not
>everything is a
>enterprise class JEE container. We should make provisions for both the
>small and the large, the smaller JVMs being catered by an full
>implementation that relies on core files. The larger JVM configurations
>should be supported by, perhaps proprietry, partial implementations of
>the API.
>
>Regarding SA. The situation was that we couldn't get the GNU Classpath
>restriction to apply to the SA classes, and it wasn't implemented
>as an API at the level we wished to link against. I believe that SA was
>the closest we could get as it had provisions for calling the debugger.
>Without support from Sun, using SA is not really an option.
>
>It might be a valid strategy for us to have just the Java API for the
>JSR, which should interest the largest portion of the Java community.
>Once it is seen that people are benefiting greatly from it, further
>investment might follow the initial specification and the Image API can
>then be specified and implemented in the open.
>
>There are reasons why we won't want to take that approach, we'll have to
>decide what is best on balance.
>
>Regards,
> Stuart
>
>Bobrovsky, Konstantin S wrote:
>> Steve,
>>
>> I see what you mean, thank you for the clarifications. I agree that
>having an RI where a big chunk of the API is unimplemented can be quite
>frustrating for end users. My only concern is the potential decrease in
>usability of Kato-based products when the Image API is removed.
>> When there is an internal VM error such as wrong JIT-generated code
>> leading to a crash, we can not know beforehand what data will be
>> required to diagnose the problem. Having all available data (core
>> dump) is ideal.
>> In the beginning of the JSR many use cases have been developed, and it
>would be interesting to estimate what share of them will be dropped with
>dropping the Image API. What leaves a hope when Image API is gone :-) is
>remaining opportunity for JVM vendors to still produce Kato implementations
>which can read core dumps and still plug into the Kato-conforming set of
>tools developed by 3rd parties. The loss would be a thick non-standardized
>layer where external tools developers can't adhere to.
>>
>>
>>> The runtime restrictions on the SA really effect it's usefulness for end
>>> users of our API.
>>>
>> Are these impossibility to sell tools based on Kato implementation which
>use SA source code or binaries? We have probably already discussed these
>restrictions in the past, but I forgot, sorry.
>>
>>
>>> The cost of writing a corefile reader for hotspot is also
>>> quite large - it could easily take someone 6 months to write or more.
>>>
>> That's pretty pessimistic, IMO :) (at least for the part covering Image
>API). 3-5 months would be enough, in my estimation. But that's still big
>chunk of work, I agree.
>>
>> Thanks,
>> Konst
>>
>>
>>
>>> -----Original Message-----
>>> From: Steve Poole [mailto:spoole167@googlemail.com]
>>> Sent: Friday, November 27, 2009 3:34 PM
>>> To: kato-spec@incubator.apache.org
>>> Subject: Re: Do we need to change the scope of the API design?
>>>
>>> On Thu, Nov 26, 2009 at 5:02 AM, Bobrovsky, Konstantin S<
>>> konstantin.s.bobrovsky@intel.com> wrote:
>>>
>>>
>>>> Hi Steve,
>>>>
>>>> I think the first option would be ideal of course. But I assume the
>>>> initiative to develop RI based on Sun's Serviceability Agent (which
>would
>>>> lower the implementation cost dramatically) has failed because of
>>>> GPL-related issues. I wish there was a volunteer from the open-source
>who
>>>> could adapt SA to the KATO API...
>>>>
>>>> That would be nice Konst. To be honest though, if I was wishing for
>help
>>>>
>>> like this I would prefer to have someone work with us on creating the
>>> extended JVMTI or new C API interface as I wrote about previously.
>The
>>> runtime restrictions on the SA really effect it's usefulness for end
>users
>>> of our API. The cost of writing a corefile reader for hotspot is
>also
>>> quite large - it could easily take someone 6 months to write or more.
>>> Therefore I'd rather be pragmatic about this and focus on what can be
>done
>>> by us and what people say they want.
>>>
>>>
>> > From the other two, the second one (remove Image API) IMO would very
>much
>>
>>>> discord with the original message of the JSR (*postmortem* analysis,
>>>>
>>> which
>>>
>>>> means digging through the core dumps). So I'd vote for leaving as much
>as
>>>> possible of the Image API in the spec, making parts optional as needed.
>>>>
>>>>
>>> I understand about changing the message but I feel uncomfortable to say
>the
>>> least to have a large part of our API not supported by the Reference
>>> Implementation. I will put together a proposal and explain what I
>think
>>> needs to be done.
>>>
>>> You can look at this from anoher point of view. We know that core file
>>> sizes are rising ( 8-30GB production heap sizes are now common) and we
>>> agreed thereforet at some point core files would become untenable.
>That's
>>> why we have the "snapshot" api idea. It seems that for most people the
>>> usefulness of corefiles is already in doubt so lets focus on producing
>a
>>> new modern dump mechanism that is fast, scaleable, content configurable
>>> and generally cross JVM. Since we will be developing a reference
>>> implementation to go with the design we will effectively be producing a
>>> modern replacement for HPROF and since the format for this dump is not
>part
>>> of the specification (as we have agreed that data formats are always
>>> constraining) we will not get rocks thrown at us by JVM vendors who want
>to
>>> implement their own alternatives.
>>>
>>> I think developing the HPROF alternative is the right place to go.
>Users
>>> will understand the concept and we might actually gain input from
>existing
>>> HPROF users who want to see improvements made.
>>>
>>> We are building the current implementation just using JVMTI. Thats not
>>> good
>>> enough and we need to find ways of getting more data out of a JVM.
>Hence
>>> the idea of improving JVMTI or adding some new API. That is probably
>>> not
>>> the right way either but lets discuss..
>>>
>>>
>>>
>>>> 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: Wednesday, November 25, 2009 7:44 PM
>>>>> To: kato-spec@incubator.apache.org
>>>>> Subject: Do we need to change the scope of the API design?
>>>>>
>>>>> Stuart's note on diagnosing JNI problems (thanks for the review
>Stuart)
>>>>>
>>>> has
>>>>
>>>>> touched on a key point concerning what we want to do and what we can
>>>>>
>>> do.
>>>
>>>>> I think its time we discuss where we are and what happens next.
>>>>>
>>>>> Our desire to specify an API that helps people solve problems has to
>be
>>>>> tempered with practical implementation considerations. The API
>design
>>>>> that IBM contributed to the Kato project is satisfiable by IBM JVMs
>(of
>>>>> course), but for us to develop a matching reference implementation we
>>>>>
>>>> know
>>>>
>>>>> now that we need to get much more information from the Sun JVM than we
>>>>>
>>>> have
>>>>
>>>>> today. Developing a full solution to match the API as it stands today
>>>>>
>>> is
>>>
>>>>> difficult for the Kato project as the code we would need to access is
>in
>>>>> OpenJDK and is under the GPL.
>>>>>
>>>>> Practically, we have few choices. We could
>>>>>
>>>>> 1 - Get a JVM Vendor to produce , or commit to produce an
>>>>>
>>> implementation
>>>
>>>>> that fully covers the Image API side.
>>>>> 2 - Remove all the Image API side from the design
>>>>> 3 - Find a halfway point where some of the Image API stays and is
>>>>>
>>>> optional.
>>>>
>>>>> I've had many conversations with people concerning option 1 and the
>>>>> response
>>>>> is generally that its too expensive for the potential return. Both
>for
>>>>> implementation and ongoing maintenance.
>>>>>
>>>>> Option 2 seems very draconian - the ability to get at some of the
>>>>>
>>> native
>>>
>>>>> information (such as the native thread for a Java thread) just seems
>too
>>>>> useful to remove.
>>>>>
>>>>> I'd opt for us moving the API design towards option 3 - there are some
>>>>> basic
>>>>> changes we could do such as extracting the native access methods into
>a
>>>>> separate interface and allowing the implementer the choice to use it.
>>>>>
>>>>> We still need to get access to more data from the JVM (and perhaps in
>>>>> better
>>>>> ways) than we have today. We need to get this data in such a manner
>as
>>>>>
>>>> not
>>>>
>>>>> to require accessing GPL code and in a way that is cheap to maintain
>as
>>>>>
>>>> the
>>>>
>>>>> JVM evolves.
>>>>>
>>>>> My idea for resolving this conundrum is to propose that we include in
>>>>>
>>> our
>>>
>>>>> API design either a new JVM 'C' API or extensions to JVMTI. We would
>>>>>
>>> not
>>>
>>>>> implement these additions in the RI but would rely on others to
>provide
>>>>>
>>> an
>>>
>>>>> implementation. (We would design the RI and the API to make this
>extra
>>>>> information optional)
>>>>>
>>>>> Comments?
>>>>>
>>>>>
>>>>> --
>>>>> Steve
>>>>>
>>>>
>>>
>>>
>>> --
>>> Steve
>>>
>
>--
>Stuart Monteith
>http://blog.stoo.me.uk/
Re: Do we need to change the scope of the API design?
Posted by Stuart Monteith <st...@stoo.me.uk>.
Hi Konstantin,
Without a proper implementation of the Image API we are missing a
whole raft of use cases, specifically those to do with
JVM or JNI library diagnosis.
While we might aim to do an implementation of the Kato API that could
cope with heaps measured in 10s of gigabytes, I don't think the RI
should. I'd fully expect there to be use cases for smaller JVMs,
especially those applications that run on desktop machines. Not
everything is a
enterprise class JEE container. We should make provisions for both the
small and the large, the smaller JVMs being catered by an full
implementation that relies on core files. The larger JVM configurations
should be supported by, perhaps proprietry, partial implementations of
the API.
Regarding SA. The situation was that we couldn't get the GNU Classpath
restriction to apply to the SA classes, and it wasn't implemented
as an API at the level we wished to link against. I believe that SA was
the closest we could get as it had provisions for calling the debugger.
Without support from Sun, using SA is not really an option.
It might be a valid strategy for us to have just the Java API for the
JSR, which should interest the largest portion of the Java community.
Once it is seen that people are benefiting greatly from it, further
investment might follow the initial specification and the Image API can
then be specified and implemented in the open.
There are reasons why we won't want to take that approach, we'll have to
decide what is best on balance.
Regards,
Stuart
Bobrovsky, Konstantin S wrote:
> Steve,
>
> I see what you mean, thank you for the clarifications. I agree that having an RI where a big chunk of the API is unimplemented can be quite frustrating for end users. My only concern is the potential decrease in usability of Kato-based products when the Image API is removed.
> When there is an internal VM error such as wrong JIT-generated code
> leading to a crash, we can not know beforehand what data will be
> required to diagnose the problem. Having all available data (core
> dump) is ideal.
> In the beginning of the JSR many use cases have been developed, and it would be interesting to estimate what share of them will be dropped with dropping the Image API. What leaves a hope when Image API is gone :-) is remaining opportunity for JVM vendors to still produce Kato implementations which can read core dumps and still plug into the Kato-conforming set of tools developed by 3rd parties. The loss would be a thick non-standardized layer where external tools developers can't adhere to.
>
>
>> The runtime restrictions on the SA really effect it's usefulness for end
>> users of our API.
>>
> Are these impossibility to sell tools based on Kato implementation which use SA source code or binaries? We have probably already discussed these restrictions in the past, but I forgot, sorry.
>
>
>> The cost of writing a corefile reader for hotspot is also
>> quite large - it could easily take someone 6 months to write or more.
>>
> That's pretty pessimistic, IMO :) (at least for the part covering Image API). 3-5 months would be enough, in my estimation. But that's still big chunk of work, I agree.
>
> Thanks,
> Konst
>
>
>
>> -----Original Message-----
>> From: Steve Poole [mailto:spoole167@googlemail.com]
>> Sent: Friday, November 27, 2009 3:34 PM
>> To: kato-spec@incubator.apache.org
>> Subject: Re: Do we need to change the scope of the API design?
>>
>> On Thu, Nov 26, 2009 at 5:02 AM, Bobrovsky, Konstantin S<
>> konstantin.s.bobrovsky@intel.com> wrote:
>>
>>
>>> Hi Steve,
>>>
>>> I think the first option would be ideal of course. But I assume the
>>> initiative to develop RI based on Sun's Serviceability Agent (which would
>>> lower the implementation cost dramatically) has failed because of
>>> GPL-related issues. I wish there was a volunteer from the open-source who
>>> could adapt SA to the KATO API...
>>>
>>> That would be nice Konst. To be honest though, if I was wishing for help
>>>
>> like this I would prefer to have someone work with us on creating the
>> extended JVMTI or new C API interface as I wrote about previously. The
>> runtime restrictions on the SA really effect it's usefulness for end users
>> of our API. The cost of writing a corefile reader for hotspot is also
>> quite large - it could easily take someone 6 months to write or more.
>> Therefore I'd rather be pragmatic about this and focus on what can be done
>> by us and what people say they want.
>>
>>
> > From the other two, the second one (remove Image API) IMO would very much
>
>>> discord with the original message of the JSR (*postmortem* analysis,
>>>
>> which
>>
>>> means digging through the core dumps). So I'd vote for leaving as much as
>>> possible of the Image API in the spec, making parts optional as needed.
>>>
>>>
>> I understand about changing the message but I feel uncomfortable to say the
>> least to have a large part of our API not supported by the Reference
>> Implementation. I will put together a proposal and explain what I think
>> needs to be done.
>>
>> You can look at this from anoher point of view. We know that core file
>> sizes are rising ( 8-30GB production heap sizes are now common) and we
>> agreed thereforet at some point core files would become untenable. That's
>> why we have the "snapshot" api idea. It seems that for most people the
>> usefulness of corefiles is already in doubt so lets focus on producing a
>> new modern dump mechanism that is fast, scaleable, content configurable
>> and generally cross JVM. Since we will be developing a reference
>> implementation to go with the design we will effectively be producing a
>> modern replacement for HPROF and since the format for this dump is not part
>> of the specification (as we have agreed that data formats are always
>> constraining) we will not get rocks thrown at us by JVM vendors who want to
>> implement their own alternatives.
>>
>> I think developing the HPROF alternative is the right place to go. Users
>> will understand the concept and we might actually gain input from existing
>> HPROF users who want to see improvements made.
>>
>> We are building the current implementation just using JVMTI. Thats not
>> good
>> enough and we need to find ways of getting more data out of a JVM. Hence
>> the idea of improving JVMTI or adding some new API. That is probably
>> not
>> the right way either but lets discuss..
>>
>>
>>
>>> 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: Wednesday, November 25, 2009 7:44 PM
>>>> To: kato-spec@incubator.apache.org
>>>> Subject: Do we need to change the scope of the API design?
>>>>
>>>> Stuart's note on diagnosing JNI problems (thanks for the review Stuart)
>>>>
>>> has
>>>
>>>> touched on a key point concerning what we want to do and what we can
>>>>
>> do.
>>
>>>> I think its time we discuss where we are and what happens next.
>>>>
>>>> Our desire to specify an API that helps people solve problems has to be
>>>> tempered with practical implementation considerations. The API design
>>>> that IBM contributed to the Kato project is satisfiable by IBM JVMs (of
>>>> course), but for us to develop a matching reference implementation we
>>>>
>>> know
>>>
>>>> now that we need to get much more information from the Sun JVM than we
>>>>
>>> have
>>>
>>>> today. Developing a full solution to match the API as it stands today
>>>>
>> is
>>
>>>> difficult for the Kato project as the code we would need to access is in
>>>> OpenJDK and is under the GPL.
>>>>
>>>> Practically, we have few choices. We could
>>>>
>>>> 1 - Get a JVM Vendor to produce , or commit to produce an
>>>>
>> implementation
>>
>>>> that fully covers the Image API side.
>>>> 2 - Remove all the Image API side from the design
>>>> 3 - Find a halfway point where some of the Image API stays and is
>>>>
>>> optional.
>>>
>>>> I've had many conversations with people concerning option 1 and the
>>>> response
>>>> is generally that its too expensive for the potential return. Both for
>>>> implementation and ongoing maintenance.
>>>>
>>>> Option 2 seems very draconian - the ability to get at some of the
>>>>
>> native
>>
>>>> information (such as the native thread for a Java thread) just seems too
>>>> useful to remove.
>>>>
>>>> I'd opt for us moving the API design towards option 3 - there are some
>>>> basic
>>>> changes we could do such as extracting the native access methods into a
>>>> separate interface and allowing the implementer the choice to use it.
>>>>
>>>> We still need to get access to more data from the JVM (and perhaps in
>>>> better
>>>> ways) than we have today. We need to get this data in such a manner as
>>>>
>>> not
>>>
>>>> to require accessing GPL code and in a way that is cheap to maintain as
>>>>
>>> the
>>>
>>>> JVM evolves.
>>>>
>>>> My idea for resolving this conundrum is to propose that we include in
>>>>
>> our
>>
>>>> API design either a new JVM 'C' API or extensions to JVMTI. We would
>>>>
>> not
>>
>>>> implement these additions in the RI but would rely on others to provide
>>>>
>> an
>>
>>>> implementation. (We would design the RI and the API to make this extra
>>>> information optional)
>>>>
>>>> Comments?
>>>>
>>>>
>>>> --
>>>> Steve
>>>>
>>>
>>
>>
>> --
>> Steve
>>
--
Stuart Monteith
http://blog.stoo.me.uk/
RE: Do we need to change the scope of the API design?
Posted by "Bobrovsky, Konstantin S" <ko...@intel.com>.
Steve,
I see what you mean, thank you for the clarifications. I agree that having an RI where a big chunk of the API is unimplemented can be quite frustrating for end users. My only concern is the potential decrease in usability of Kato-based products when the Image API is removed.
When there is an internal VM error such as wrong JIT-generated code
leading to a crash, we can not know beforehand what data will be
required to diagnose the problem. Having all available data (core
dump) is ideal.
In the beginning of the JSR many use cases have been developed, and it would be interesting to estimate what share of them will be dropped with dropping the Image API. What leaves a hope when Image API is gone :-) is remaining opportunity for JVM vendors to still produce Kato implementations which can read core dumps and still plug into the Kato-conforming set of tools developed by 3rd parties. The loss would be a thick non-standardized layer where external tools developers can't adhere to.
> The runtime restrictions on the SA really effect it's usefulness for end
> users of our API.
Are these impossibility to sell tools based on Kato implementation which use SA source code or binaries? We have probably already discussed these restrictions in the past, but I forgot, sorry.
> The cost of writing a corefile reader for hotspot is also
> quite large - it could easily take someone 6 months to write or more.
That's pretty pessimistic, IMO :) (at least for the part covering Image API). 3-5 months would be enough, in my estimation. But that's still big chunk of work, I agree.
Thanks,
Konst
>-----Original Message-----
>From: Steve Poole [mailto:spoole167@googlemail.com]
>Sent: Friday, November 27, 2009 3:34 PM
>To: kato-spec@incubator.apache.org
>Subject: Re: Do we need to change the scope of the API design?
>
>On Thu, Nov 26, 2009 at 5:02 AM, Bobrovsky, Konstantin S <
>konstantin.s.bobrovsky@intel.com> wrote:
>
>> Hi Steve,
>>
>> I think the first option would be ideal of course. But I assume the
>> initiative to develop RI based on Sun's Serviceability Agent (which would
>> lower the implementation cost dramatically) has failed because of
>> GPL-related issues. I wish there was a volunteer from the open-source who
>> could adapt SA to the KATO API...
>>
>> That would be nice Konst. To be honest though, if I was wishing for help
>like this I would prefer to have someone work with us on creating the
>extended JVMTI or new C API interface as I wrote about previously. The
>runtime restrictions on the SA really effect it's usefulness for end users
>of our API. The cost of writing a corefile reader for hotspot is also
>quite large - it could easily take someone 6 months to write or more.
>Therefore I'd rather be pragmatic about this and focus on what can be done
>by us and what people say they want.
>
>>From the other two, the second one (remove Image API) IMO would very much
>> discord with the original message of the JSR (*postmortem* analysis,
>which
>> means digging through the core dumps). So I'd vote for leaving as much as
>> possible of the Image API in the spec, making parts optional as needed.
>>
>
>I understand about changing the message but I feel uncomfortable to say the
>least to have a large part of our API not supported by the Reference
>Implementation. I will put together a proposal and explain what I think
>needs to be done.
>
>You can look at this from anoher point of view. We know that core file
>sizes are rising ( 8-30GB production heap sizes are now common) and we
>agreed thereforet at some point core files would become untenable. That's
>why we have the "snapshot" api idea. It seems that for most people the
>usefulness of corefiles is already in doubt so lets focus on producing a
>new modern dump mechanism that is fast, scaleable, content configurable
>and generally cross JVM. Since we will be developing a reference
>implementation to go with the design we will effectively be producing a
>modern replacement for HPROF and since the format for this dump is not part
>of the specification (as we have agreed that data formats are always
>constraining) we will not get rocks thrown at us by JVM vendors who want to
>implement their own alternatives.
>
>I think developing the HPROF alternative is the right place to go. Users
>will understand the concept and we might actually gain input from existing
>HPROF users who want to see improvements made.
>
>We are building the current implementation just using JVMTI. Thats not
>good
>enough and we need to find ways of getting more data out of a JVM. Hence
>the idea of improving JVMTI or adding some new API. That is probably
>not
>the right way either but lets discuss..
>
>
>> 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: Wednesday, November 25, 2009 7:44 PM
>> >To: kato-spec@incubator.apache.org
>> >Subject: Do we need to change the scope of the API design?
>> >
>> >Stuart's note on diagnosing JNI problems (thanks for the review Stuart)
>> has
>> >touched on a key point concerning what we want to do and what we can
>do.
>> >
>> >I think its time we discuss where we are and what happens next.
>> >
>> >Our desire to specify an API that helps people solve problems has to be
>> >tempered with practical implementation considerations. The API design
>> >that IBM contributed to the Kato project is satisfiable by IBM JVMs (of
>> >course), but for us to develop a matching reference implementation we
>> know
>> >now that we need to get much more information from the Sun JVM than we
>> have
>> >today. Developing a full solution to match the API as it stands today
>is
>> >difficult for the Kato project as the code we would need to access is in
>> >OpenJDK and is under the GPL.
>> >
>> >Practically, we have few choices. We could
>> >
>> >1 - Get a JVM Vendor to produce , or commit to produce an
>implementation
>> >that fully covers the Image API side.
>> >2 - Remove all the Image API side from the design
>> >3 - Find a halfway point where some of the Image API stays and is
>> optional.
>> >
>> >I've had many conversations with people concerning option 1 and the
>> >response
>> >is generally that its too expensive for the potential return. Both for
>> >implementation and ongoing maintenance.
>> >
>> >Option 2 seems very draconian - the ability to get at some of the
>native
>> >information (such as the native thread for a Java thread) just seems too
>> >useful to remove.
>> >
>> >I'd opt for us moving the API design towards option 3 - there are some
>> >basic
>> >changes we could do such as extracting the native access methods into a
>> >separate interface and allowing the implementer the choice to use it.
>> >
>> >We still need to get access to more data from the JVM (and perhaps in
>> >better
>> >ways) than we have today. We need to get this data in such a manner as
>> not
>> >to require accessing GPL code and in a way that is cheap to maintain as
>> the
>> >JVM evolves.
>> >
>> >My idea for resolving this conundrum is to propose that we include in
>our
>> >API design either a new JVM 'C' API or extensions to JVMTI. We would
>not
>> >implement these additions in the RI but would rely on others to provide
>an
>> >implementation. (We would design the RI and the API to make this extra
>> >information optional)
>> >
>> >Comments?
>> >
>> >
>> >--
>> >Steve
>>
>
>
>
>--
>Steve
Re: Do we need to change the scope of the API design?
Posted by Steve Poole <sp...@googlemail.com>.
On Thu, Nov 26, 2009 at 5:02 AM, Bobrovsky, Konstantin S <
konstantin.s.bobrovsky@intel.com> wrote:
> Hi Steve,
>
> I think the first option would be ideal of course. But I assume the
> initiative to develop RI based on Sun's Serviceability Agent (which would
> lower the implementation cost dramatically) has failed because of
> GPL-related issues. I wish there was a volunteer from the open-source who
> could adapt SA to the KATO API...
>
> That would be nice Konst. To be honest though, if I was wishing for help
like this I would prefer to have someone work with us on creating the
extended JVMTI or new C API interface as I wrote about previously. The
runtime restrictions on the SA really effect it's usefulness for end users
of our API. The cost of writing a corefile reader for hotspot is also
quite large - it could easily take someone 6 months to write or more.
Therefore I'd rather be pragmatic about this and focus on what can be done
by us and what people say they want.
From the other two, the second one (remove Image API) IMO would very much
> discord with the original message of the JSR (*postmortem* analysis, which
> means digging through the core dumps). So I'd vote for leaving as much as
> possible of the Image API in the spec, making parts optional as needed.
>
I understand about changing the message but I feel uncomfortable to say the
least to have a large part of our API not supported by the Reference
Implementation. I will put together a proposal and explain what I think
needs to be done.
You can look at this from anoher point of view. We know that core file
sizes are rising ( 8-30GB production heap sizes are now common) and we
agreed thereforet at some point core files would become untenable. That's
why we have the "snapshot" api idea. It seems that for most people the
usefulness of corefiles is already in doubt so lets focus on producing a
new modern dump mechanism that is fast, scaleable, content configurable
and generally cross JVM. Since we will be developing a reference
implementation to go with the design we will effectively be producing a
modern replacement for HPROF and since the format for this dump is not part
of the specification (as we have agreed that data formats are always
constraining) we will not get rocks thrown at us by JVM vendors who want to
implement their own alternatives.
I think developing the HPROF alternative is the right place to go. Users
will understand the concept and we might actually gain input from existing
HPROF users who want to see improvements made.
We are building the current implementation just using JVMTI. Thats not good
enough and we need to find ways of getting more data out of a JVM. Hence
the idea of improving JVMTI or adding some new API. That is probably not
the right way either but lets discuss..
> 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: Wednesday, November 25, 2009 7:44 PM
> >To: kato-spec@incubator.apache.org
> >Subject: Do we need to change the scope of the API design?
> >
> >Stuart's note on diagnosing JNI problems (thanks for the review Stuart)
> has
> >touched on a key point concerning what we want to do and what we can do.
> >
> >I think its time we discuss where we are and what happens next.
> >
> >Our desire to specify an API that helps people solve problems has to be
> >tempered with practical implementation considerations. The API design
> >that IBM contributed to the Kato project is satisfiable by IBM JVMs (of
> >course), but for us to develop a matching reference implementation we
> know
> >now that we need to get much more information from the Sun JVM than we
> have
> >today. Developing a full solution to match the API as it stands today is
> >difficult for the Kato project as the code we would need to access is in
> >OpenJDK and is under the GPL.
> >
> >Practically, we have few choices. We could
> >
> >1 - Get a JVM Vendor to produce , or commit to produce an implementation
> >that fully covers the Image API side.
> >2 - Remove all the Image API side from the design
> >3 - Find a halfway point where some of the Image API stays and is
> optional.
> >
> >I've had many conversations with people concerning option 1 and the
> >response
> >is generally that its too expensive for the potential return. Both for
> >implementation and ongoing maintenance.
> >
> >Option 2 seems very draconian - the ability to get at some of the native
> >information (such as the native thread for a Java thread) just seems too
> >useful to remove.
> >
> >I'd opt for us moving the API design towards option 3 - there are some
> >basic
> >changes we could do such as extracting the native access methods into a
> >separate interface and allowing the implementer the choice to use it.
> >
> >We still need to get access to more data from the JVM (and perhaps in
> >better
> >ways) than we have today. We need to get this data in such a manner as
> not
> >to require accessing GPL code and in a way that is cheap to maintain as
> the
> >JVM evolves.
> >
> >My idea for resolving this conundrum is to propose that we include in our
> >API design either a new JVM 'C' API or extensions to JVMTI. We would not
> >implement these additions in the RI but would rely on others to provide an
> >implementation. (We would design the RI and the API to make this extra
> >information optional)
> >
> >Comments?
> >
> >
> >--
> >Steve
>
--
Steve
RE: Do we need to change the scope of the API design?
Posted by "Bobrovsky, Konstantin S" <ko...@intel.com>.
Hi Steve,
I think the first option would be ideal of course. But I assume the initiative to develop RI based on Sun's Serviceability Agent (which would lower the implementation cost dramatically) has failed because of GPL-related issues. I wish there was a volunteer from the open-source who could adapt SA to the KATO API...
From the other two, the second one (remove Image API) IMO would very much discord with the original message of the JSR (*postmortem* analysis, which means digging through the core dumps). So I'd vote for leaving as much as possible of the Image API in the spec, making parts optional as needed.
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: Wednesday, November 25, 2009 7:44 PM
>To: kato-spec@incubator.apache.org
>Subject: Do we need to change the scope of the API design?
>
>Stuart's note on diagnosing JNI problems (thanks for the review Stuart) has
>touched on a key point concerning what we want to do and what we can do.
>
>I think its time we discuss where we are and what happens next.
>
>Our desire to specify an API that helps people solve problems has to be
>tempered with practical implementation considerations. The API design
>that IBM contributed to the Kato project is satisfiable by IBM JVMs (of
>course), but for us to develop a matching reference implementation we know
>now that we need to get much more information from the Sun JVM than we have
>today. Developing a full solution to match the API as it stands today is
>difficult for the Kato project as the code we would need to access is in
>OpenJDK and is under the GPL.
>
>Practically, we have few choices. We could
>
>1 - Get a JVM Vendor to produce , or commit to produce an implementation
>that fully covers the Image API side.
>2 - Remove all the Image API side from the design
>3 - Find a halfway point where some of the Image API stays and is optional.
>
>I've had many conversations with people concerning option 1 and the
>response
>is generally that its too expensive for the potential return. Both for
>implementation and ongoing maintenance.
>
>Option 2 seems very draconian - the ability to get at some of the native
>information (such as the native thread for a Java thread) just seems too
>useful to remove.
>
>I'd opt for us moving the API design towards option 3 - there are some
>basic
>changes we could do such as extracting the native access methods into a
>separate interface and allowing the implementer the choice to use it.
>
>We still need to get access to more data from the JVM (and perhaps in
>better
>ways) than we have today. We need to get this data in such a manner as not
>to require accessing GPL code and in a way that is cheap to maintain as the
>JVM evolves.
>
>My idea for resolving this conundrum is to propose that we include in our
>API design either a new JVM 'C' API or extensions to JVMTI. We would not
>implement these additions in the RI but would rely on others to provide an
>implementation. (We would design the RI and the API to make this extra
>information optional)
>
>Comments?
>
>
>--
>Steve
Re: Do we need to change the scope of the API design?
Posted by Stuart Monteith <st...@stoo.me.uk>.
Hello,
Comments sprinkled throughout...
Steve Poole wrote:
> On Wed, Dec 2, 2009 at 11:53 AM, Stuart Monteith<st...@stoo.me.uk> wrote:
>
>
>> Hello,
>> I agree Konstantin, technically any changes are going to be challenging,
>> actually
>> having changes accepted will probably be even more difficult. As this is
>> not a Sun led project,
>> JSR-326 couldn't make changes to the HotSpot JVM in the same way as JSR-163
>> (JVM TI).
>>
>> As a JSR we can propose them but they would not be accepted unless Jsr 326
>>
> made it into an Umbrella JSR.
> we would also have to consider how much a gap it would be to have a RI
> without the capability provided by these proposals.
>
>
>
I can't really make a judgement on how realistic this approach is.
Essentially what we are saying is we are
missing some JVM funtionality that would allow us to implement this
feature in our RI. Thing is, if this was
accepted into the umbrella JSR, would the RI even be the implementation
for HotSpot? Given the existing
ServiceAbility functionality, HotSpot would do well to use that instead
of the RI. Under such circumstances
I wouldn't expect that the additional JVMTI (or elsewhere) functionality
would be required, unless a separate
case could be made.
>> I think we need to understand what extensions for JVMTI we are talking
>> about, I don't believe
>> they have been written down. Perhaps if they were small and uncontroversial
>> the odds would be
>> better.
>>
>> I said JVMTI just as a way to get people thinking about the idea of a 'c'
>>
> level interface. I also had in my head that the sort of data we needed was
> going to be process level type stuff and a 'c' api made it easier to get at.
>
>
I think we ought to list what we think this functionality would be.
This is what I think the RI could do without modification to the JVM:
1. Retrieve the native thread IDs
2. Get system information - creation time, system type, processor type.
3. Get the ImageSymbols. Although without native memory, there might be
little point in doing so.
4. Maybe Native thread ID's, registers and perhaps stacks could be
retrieved by using GDB/MI.
5. Native libraries - ImageModule - could be reported. At a minimum
/proc can tell us.
6. Environment variables - as the environment is reported by the JVM itself.
7. Retrieve bytecode and constant pool information
Here is what I don't think we would ever do:
1. Native memory - otherwise, we'd just work on core files.
2. Get the signal that caused the dump (RI could never do this)
With the assistance of new JVMTI features we could return:
1. The native thread ID corresponding with a JavaThread.
2. Perhaps native thread registers and stacks with help from the JVM.
3. ?
4. I think that's it.
The biggest limiter will be the circumstances under which the RI could
be launched. i.e. there will be no crash diagnosis.
> My proposal is something like this
>
> 1 - The following methods signatures would be abstracted out into a
> separate interface (which I'll call NativeAccess to be contentious) :
>
> List<ImageSection> getSections();
>
>
> ImagePointer getAddress() throws CorruptDataException;
>
> (there are other methods of a similar intent which would be renamed to one
> of these)
>
> The method signature
>
> ImagePointer getID()
>
> would change to return either a primitive or a some new opaque handle object
>
>
So we could return:
public class JavaClassRIImpl implements JavaClass
for the RI but:
public class JavaClassCoreImpl implements JavaClass, NativeAccess
for a core file implementation that would allow us to get an address in
memory for the class.
The RI would just return the result of getID() which would effectively
be the record ID in the file.
That seems a reasonable way of implementing it.
It has the advantage that if a JavaClass or whatever is created but
doesn't actually exist in the JVM,
we can implement it without a "NativeAccess", which is a nicer way of
going about thing.
As this point reiterates:
> 2 - A particular implementation of the API would be at liberty to return
> objects which implemented this new Interface - but is not forced to do so
>
>
> 3 - That would leave us with
>
> 3A : JavaThread has two remaining methods for accessing native data :
>
> ImagePointer getJNIEnv() throws CorruptDataException;
> ImageThread getImageThread() throws CorruptDataException, DataUnavailable;
>
> I would be inclined to replace getJNIEnv and getImageThread on JavaThread
> with a single getNativeThread which returned an object from which you could
> do getJNIEnv etc It would probably be something called like
> NativeJavaThread and could (but is not required to) implement ImageThread
>
>
Applications could then compile against the purely implementation
agnostic classes. Other applications that
do analysis of the native side could be written, but with a greater
degree of care.
> 3b: JavaMethod has :
>
> List<ImageSection> getBytecodeSections();
> List<ImageSection> getCompiledSections();
>
> I would propose that for JavaMethod we converted List<ImageSection>
> getBytecodeSections(); into byte[] getByteCode();
>
> We also rename getCompiledSections() into getSections() so that it could be
> abstracted out into the NativeAccess interface
>
>
>
I think Konstantin will have lots to say, but all I would comment on is
how we think this might be used.
I see JavaMethods being used for the following:
o For identifying methods and their names in JavaLocation
o Perhaps for retrieving bytecodes for the recreation of .class files
(or generated/transformed classes)
o For retrieving compiled code for JIT diagnosis.
Are there others?
> 3C: JavaRuntime has :
>
> JavaObject getObjectAtAddress(ImagePointer address) throws
> CorruptDataException, IllegalArgumentException, MemoryAccessException,
> DataUnavailable;
>
> This get converted so the ImagePointer passed in becomes the same primitive
> or new opaque type as we define for getID()
>
>
> Summary: The abstraction and small changes decouples the process level
> stuff from the JavaRuntime. Those implementations who want to provide the
> data can do so but those who do not are not disadvantaged.
>
> That still leaves us with the desire to get at more of the native
> information which I think is mostly what I've listed above :
>
> A) Access to some native thread information
> B) Access to the JNIEnv of a JavaThread
> C) Bytecode loaded for a particular method
>
> I'll stop there and see what you all think...
>
>
>
> Regards,
> Stuart
>
> Bobrovsky, Konstantin S wrote:
>
>
>> Steve,
>>
>>> I found I did not answer this proposal
>>>
>>>
>>>
>>>
>>>> My idea for resolving this conundrum is to propose that we include in our
>>>> API design either a new JVM 'C' API or extensions to JVMTI. We would not
>>>> implement these additions in the RI but would rely on others to provide
>>>> an
>>>> implementation. (We would design the RI and the API to make this extra
>>>> information optional)
>>>>
>>>>
>>>>
>>> I'm a little skeptical about new C API or even JVMTI extensions. Sun put
>>> lots of efforts in developing JVMPI/JVMTI, endless list of bugs has been
>>> fixed - not only in JVMTI-specific code, but in other JVM and JIT parts
>>> which had to be changed to support certain JVMTI functionality (such as
>>> method entry/exit events, EarlyReturn support).
>>>
>>> There is a risk of this new API to require lots of efforts to develop and
>>> debug a proof-of-concept prototype (RI is possibly only for Harmony, I
>>> guess).
>>>
>>> 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
>>>
>>>
>>>
>>>
>> --
>> Stuart Monteith
>> http://blog.stoo.me.uk/
>>
>>
>>
>
>
--
Stuart Monteith
http://blog.stoo.me.uk/
RE: Do we need to change the scope of the API design?
Posted by "Bobrovsky, Konstantin S" <ko...@intel.com>.
Steve,
See my comments in-lined.
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: Wednesday, December 02, 2009 7:40 PM
>To: kato-spec@incubator.apache.org
>Subject: Re: Do we need to change the scope of the API design?
>
>On Wed, Dec 2, 2009 at 11:53 AM, Stuart Monteith <st...@stoo.me.uk>
>wrote:
>
>> Hello,
>> I agree Konstantin, technically any changes are going to be
>challenging,
>> actually
>> having changes accepted will probably be even more difficult. As this is
>> not a Sun led project,
>> JSR-326 couldn't make changes to the HotSpot JVM in the same way as JSR-
>163
>> (JVM TI).
>>
>> As a JSR we can propose them but they would not be accepted unless Jsr
>326
>made it into an Umbrella JSR.
>we would also have to consider how much a gap it would be to have a RI
>without the capability provided by these proposals.
>
>
>> I think we need to understand what extensions for JVMTI we are talking
>> about, I don't believe
>> they have been written down. Perhaps if they were small and
>uncontroversial
>> the odds would be
>> better.
>>
>> I said JVMTI just as a way to get people thinking about the idea of a 'c'
>level interface. I also had in my head that the sort of data we needed was
>going to be process level type stuff and a 'c' api made it easier to get
>at.
>
>
>My proposal is something like this
>
>1 - The following methods signatures would be abstracted out into a
>separate interface (which I'll call NativeAccess to be contentious) :
>
> List<ImageSection> getSections();
>
>
>ImagePointer getAddress() throws CorruptDataException;
>
>(there are other methods of a similar intent which would be renamed to one
>of these)
>
>The method signature
>
> ImagePointer getID()
>
>would change to return either a primitive or a some new opaque handle
>object
>
[Bobrovsky, Konstantin S]
I don't quite understand the intent here. Will this separate interface be extended by other KATO API elements?
>2 - A particular implementation of the API would be at liberty to return
>objects which implemented this new Interface - but is not forced to do so
>
[Bobrovsky, Konstantin S] Is this to avoid "empty" implementations in the API? E.g. client must check is 'obj instanceof NativeAccess' before querying id/address, and initial RI will have most objects not implementing the NativeAccess interface. - ?
>3 - That would leave us with
>
>3A : JavaThread has two remaining methods for accessing native data :
>
> ImagePointer getJNIEnv() throws CorruptDataException;
> ImageThread getImageThread() throws CorruptDataException, DataUnavailable;
>
>I would be inclined to replace getJNIEnv and getImageThread on JavaThread
>with a single getNativeThread which returned an object from which you could
>do getJNIEnv etc It would probably be something called like
>NativeJavaThread and could (but is not required to) implement ImageThread
>
>3b: JavaMethod has :
>
> List<ImageSection> getBytecodeSections();
> List<ImageSection> getCompiledSections();
>
>I would propose that for JavaMethod we converted List<ImageSection>
>getBytecodeSections(); into byte[] getByteCode();
[Bobrovsky, Konstantin S]
What it will return? Only method's bytecode? We should be able to access the rest of the classfile data (constant pool) - this can belong to JavaClass.
>
>We also rename getCompiledSections() into getSections() so that it could be
>abstracted out into the NativeAccess interface
>
[Bobrovsky, Konstantin S]
As I said earlier, I strongly believe that there should be an individual interface for representing method's code. I'll write more on this in a separate topic.
>
>3C: JavaRuntime has :
>
>JavaObject getObjectAtAddress(ImagePointer address) throws
>CorruptDataException, IllegalArgumentException, MemoryAccessException,
>DataUnavailable;
>
>This get converted so the ImagePointer passed in becomes the same primitive
>or new opaque type as we define for getID()
>
>
>Summary: The abstraction and small changes decouples the process level
>stuff from the JavaRuntime. Those implementations who want to provide the
>data can do so but those who do not are not disadvantaged.
>
>That still leaves us with the desire to get at more of the native
>information which I think is mostly what I've listed above :
>
>A) Access to some native thread information
>B) Access to the JNIEnv of a JavaThread
>C) Bytecode loaded for a particular method
>
>I'll stop there and see what you all think...
>
>
>
>Regards,
> Stuart
>
>Bobrovsky, Konstantin S wrote:
>
>> Steve,
>>>
>>> I found I did not answer this proposal
>>>
>>>
>>>
>>>> My idea for resolving this conundrum is to propose that we include in
>our
>>>> API design either a new JVM 'C' API or extensions to JVMTI. We would
>not
>>>> implement these additions in the RI but would rely on others to provide
>>>> an
>>>> implementation. (We would design the RI and the API to make this extra
>>>> information optional)
>>>>
>>>>
>>> I'm a little skeptical about new C API or even JVMTI extensions. Sun put
>>> lots of efforts in developing JVMPI/JVMTI, endless list of bugs has been
>>> fixed - not only in JVMTI-specific code, but in other JVM and JIT parts
>>> which had to be changed to support certain JVMTI functionality (such as
>>> method entry/exit events, EarlyReturn support).
>>>
>>> There is a risk of this new API to require lots of efforts to develop
>and
>>> debug a proof-of-concept prototype (RI is possibly only for Harmony, I
>>> guess).
>>>
>>> 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
>>>
>>>
>>>
>>
>> --
>> Stuart Monteith
>> http://blog.stoo.me.uk/
>>
>>
>
>
>--
>Steve
Re: Do we need to change the scope of the API design?
Posted by Steve Poole <sp...@googlemail.com>.
On Wed, Dec 2, 2009 at 11:53 AM, Stuart Monteith <st...@stoo.me.uk> wrote:
> Hello,
> I agree Konstantin, technically any changes are going to be challenging,
> actually
> having changes accepted will probably be even more difficult. As this is
> not a Sun led project,
> JSR-326 couldn't make changes to the HotSpot JVM in the same way as JSR-163
> (JVM TI).
>
> As a JSR we can propose them but they would not be accepted unless Jsr 326
made it into an Umbrella JSR.
we would also have to consider how much a gap it would be to have a RI
without the capability provided by these proposals.
> I think we need to understand what extensions for JVMTI we are talking
> about, I don't believe
> they have been written down. Perhaps if they were small and uncontroversial
> the odds would be
> better.
>
> I said JVMTI just as a way to get people thinking about the idea of a 'c'
level interface. I also had in my head that the sort of data we needed was
going to be process level type stuff and a 'c' api made it easier to get at.
My proposal is something like this
1 - The following methods signatures would be abstracted out into a
separate interface (which I'll call NativeAccess to be contentious) :
List<ImageSection> getSections();
ImagePointer getAddress() throws CorruptDataException;
(there are other methods of a similar intent which would be renamed to one
of these)
The method signature
ImagePointer getID()
would change to return either a primitive or a some new opaque handle object
2 - A particular implementation of the API would be at liberty to return
objects which implemented this new Interface - but is not forced to do so
3 - That would leave us with
3A : JavaThread has two remaining methods for accessing native data :
ImagePointer getJNIEnv() throws CorruptDataException;
ImageThread getImageThread() throws CorruptDataException, DataUnavailable;
I would be inclined to replace getJNIEnv and getImageThread on JavaThread
with a single getNativeThread which returned an object from which you could
do getJNIEnv etc It would probably be something called like
NativeJavaThread and could (but is not required to) implement ImageThread
3b: JavaMethod has :
List<ImageSection> getBytecodeSections();
List<ImageSection> getCompiledSections();
I would propose that for JavaMethod we converted List<ImageSection>
getBytecodeSections(); into byte[] getByteCode();
We also rename getCompiledSections() into getSections() so that it could be
abstracted out into the NativeAccess interface
3C: JavaRuntime has :
JavaObject getObjectAtAddress(ImagePointer address) throws
CorruptDataException, IllegalArgumentException, MemoryAccessException,
DataUnavailable;
This get converted so the ImagePointer passed in becomes the same primitive
or new opaque type as we define for getID()
Summary: The abstraction and small changes decouples the process level
stuff from the JavaRuntime. Those implementations who want to provide the
data can do so but those who do not are not disadvantaged.
That still leaves us with the desire to get at more of the native
information which I think is mostly what I've listed above :
A) Access to some native thread information
B) Access to the JNIEnv of a JavaThread
C) Bytecode loaded for a particular method
I'll stop there and see what you all think...
Regards,
Stuart
Bobrovsky, Konstantin S wrote:
> Steve,
>>
>> I found I did not answer this proposal
>>
>>
>>
>>> My idea for resolving this conundrum is to propose that we include in our
>>> API design either a new JVM 'C' API or extensions to JVMTI. We would not
>>> implement these additions in the RI but would rely on others to provide
>>> an
>>> implementation. (We would design the RI and the API to make this extra
>>> information optional)
>>>
>>>
>> I'm a little skeptical about new C API or even JVMTI extensions. Sun put
>> lots of efforts in developing JVMPI/JVMTI, endless list of bugs has been
>> fixed - not only in JVMTI-specific code, but in other JVM and JIT parts
>> which had to be changed to support certain JVMTI functionality (such as
>> method entry/exit events, EarlyReturn support).
>>
>> There is a risk of this new API to require lots of efforts to develop and
>> debug a proof-of-concept prototype (RI is possibly only for Harmony, I
>> guess).
>>
>> 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
>>
>>
>>
>
> --
> Stuart Monteith
> http://blog.stoo.me.uk/
>
>
--
Steve
Re: Do we need to change the scope of the API design?
Posted by Stuart Monteith <st...@stoo.me.uk>.
Hello,
I agree Konstantin, technically any changes are going to be
challenging, actually
having changes accepted will probably be even more difficult. As this is
not a Sun led project,
JSR-326 couldn't make changes to the HotSpot JVM in the same way as
JSR-163 (JVM TI).
I think we need to understand what extensions for JVMTI we are talking
about, I don't believe
they have been written down. Perhaps if they were small and
uncontroversial the odds would be
better.
Regards,
Stuart
Bobrovsky, Konstantin S wrote:
> Steve,
>
> I found I did not answer this proposal
>
>
>> My idea for resolving this conundrum is to propose that we include in our
>> API design either a new JVM 'C' API or extensions to JVMTI. We would not
>> implement these additions in the RI but would rely on others to provide an
>> implementation. (We would design the RI and the API to make this extra
>> information optional)
>>
> I'm a little skeptical about new C API or even JVMTI extensions. Sun put lots of efforts in developing JVMPI/JVMTI, endless list of bugs has been fixed - not only in JVMTI-specific code, but in other JVM and JIT parts which had to be changed to support certain JVMTI functionality (such as method entry/exit events, EarlyReturn support).
>
> There is a risk of this new API to require lots of efforts to develop and debug a proof-of-concept prototype (RI is possibly only for Harmony, I guess).
>
> 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
>
>
--
Stuart Monteith
http://blog.stoo.me.uk/
RE: Do we need to change the scope of the API design?
Posted by "Bobrovsky, Konstantin S" <ko...@intel.com>.
Steve,
I found I did not answer this proposal
>My idea for resolving this conundrum is to propose that we include in our
>API design either a new JVM 'C' API or extensions to JVMTI. We would not
>implement these additions in the RI but would rely on others to provide an
>implementation. (We would design the RI and the API to make this extra
>information optional)
I'm a little skeptical about new C API or even JVMTI extensions. Sun put lots of efforts in developing JVMPI/JVMTI, endless list of bugs has been fixed - not only in JVMTI-specific code, but in other JVM and JIT parts which had to be changed to support certain JVMTI functionality (such as method entry/exit events, EarlyReturn support).
There is a risk of this new API to require lots of efforts to develop and debug a proof-of-concept prototype (RI is possibly only for Harmony, I guess).
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: Wednesday, November 25, 2009 7:44 PM
>To: kato-spec@incubator.apache.org
>Subject: Do we need to change the scope of the API design?
>
>Stuart's note on diagnosing JNI problems (thanks for the review Stuart) has
>touched on a key point concerning what we want to do and what we can do.
>
>I think its time we discuss where we are and what happens next.
>
>Our desire to specify an API that helps people solve problems has to be
>tempered with practical implementation considerations. The API design
>that IBM contributed to the Kato project is satisfiable by IBM JVMs (of
>course), but for us to develop a matching reference implementation we know
>now that we need to get much more information from the Sun JVM than we have
>today. Developing a full solution to match the API as it stands today is
>difficult for the Kato project as the code we would need to access is in
>OpenJDK and is under the GPL.
>
>Practically, we have few choices. We could
>
>1 - Get a JVM Vendor to produce , or commit to produce an implementation
>that fully covers the Image API side.
>2 - Remove all the Image API side from the design
>3 - Find a halfway point where some of the Image API stays and is optional.
>
>I've had many conversations with people concerning option 1 and the
>response
>is generally that its too expensive for the potential return. Both for
>implementation and ongoing maintenance.
>
>Option 2 seems very draconian - the ability to get at some of the native
>information (such as the native thread for a Java thread) just seems too
>useful to remove.
>
>I'd opt for us moving the API design towards option 3 - there are some
>basic
>changes we could do such as extracting the native access methods into a
>separate interface and allowing the implementer the choice to use it.
>
>We still need to get access to more data from the JVM (and perhaps in
>better
>ways) than we have today. We need to get this data in such a manner as not
>to require accessing GPL code and in a way that is cheap to maintain as the
>JVM evolves.
>
>My idea for resolving this conundrum is to propose that we include in our
>API design either a new JVM 'C' API or extensions to JVMTI. We would not
>implement these additions in the RI but would rely on others to provide an
>implementation. (We would design the RI and the API to make this extra
>information optional)
>
>Comments?
>
>
>--
>Steve