incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Poole <>
Subject Re: Replacing ImagePointer references in the Java Runtime API
Date Fri, 08 Jan 2010 13:45:56 GMT
On Fri, Jan 8, 2010 at 1:03 PM, David Griffiths

> Hi Steve, I've read the discussion from last year about removing the
> Image API but don't understand. Why do people believe it is so
> difficult to implement the Image API? Are there particular parts of
> the Image API that they thought would be difficult? Not all of the
> Image API is required by the JavaRuntime API, do they also have
> problems with the subset that is? Are the folks you've talked to
> subscribed to this list and if so can they jump in?
Personally I think the Image API is the easy bit to implement and much
> less prone to change. Also there is scope for sharing implementations,
> eg the Image API for Linux core files can be used by Sun's Kato or by
> IBM's Kato. Not to mention the fact that having a well defined way for
> Java programs to access core files would have other spin-off benefits
> (example: when writing my zSeries emulator I ended up making it depend
> only on ImageInputStream so as to make the code as reusable as
> possible - if you wanted to disassemble some memory using the emulator
> all you needed to supply was an ImageInputStream implementation). Be
> nice to move to Java as much as possible for core file analysis and
> get away from gdb/dbx etc.
> Its not so much implementing the Image API etc that's the problem - it's
the coupling between the Image API and the JavaRuntime thats the issue.
The coupling is too tight at the moment.   The only dump that exists that
can satisfy the whole API today is the system dump from an IBM JVM.
We currently force the other dump implementors to create ImageAddressSpace,
ImageProcess, ImagePointer etc even though they are generally meaningless to

We do want to keep the Image API pieces around  but just loosen the coupling
between the native  and the Java portions.

Also, what do you mean by a "handle mechanism"?
> Currently the API uses ImagePointer as a handle for objects -  you can go
to the javaRuntime and get an JavaObject from an ImagePointer,  and from and
JavaObject you can get an ImagePointer.       For decoupling purposes (ie to
remove the dependency on ImagePointer) we can either make this process work
with primitive longs or create an alternative interface that doesn't have
the associated etc semantics that  ImagePointer has.

And why is it more heavy handed to create (say) a JavaObject from a
> primitive long than from an ImagePointer? Are you thinking about
> caching?
> Yep - thats my worry.  You can imagine that since implementations would
need to track the relationship between the long and the "real" object it
could easily be sub optimal if they had to keep a global cache between the
long and all types of entity within the Java Dump.

The extra point to consider in all this is that the "handle" whatever it is
needs to be able to be converted into a primitive value (number, string etc)
as we would expect in many cases that this value would  be used outside a
JVM (stored in a database for instance)

I was thinking that being able to convert the Handle into a String for would
be a good way to go.

> Dave
> On Fri, Jan 8, 2010 at 10:22 AM, Steve Poole <>
> wrote:
> > I'm making made some good inroads into updating the API to match what we
> > discussed last year in decoupling the Image API from the JavaRuntime API,
> > A problem I've hit is that we can't use just a long to represent a
> > JavaObject id instead of an ImagePointer (which was one of the
> suggestions)
> > .
> >
> > Currently the API for JavaObject lets you get an ImagePointer back to
> > represent its "id".    The JavaRuntime class allows you to provide an
> > ImagePointer and get back a JavaObject.   The original
> > idea was that we replaced these mechanisms with one where you could get a
> > long as an JavaObject Id and could provide JavaRuntime with a long and
> get
> > back the corresponding JavaObject.
> >
> > It turns out that there are other places where we use the ImagePointer as
> an
> > "id" and do the eqivilent round tripping.  I need to fix them too.
> Forcing
> > a implementation to reconstitute some of these other entities from a
> single
> > number is heavy handed - there is other context required in some places
> and
> > would require  an implementation to maintain a single name space (or is
> that
> > number space) for all of its entities.
> >
> > To remove those dependencies on ImagePointer and provide a sensible round
> > tripping mechanism it seems better to go with a handle mechanism instead.
> > I'm going to prototype that  implementation but I thought I should
> explain
> > why I'm doing it that way up front.
> >
> >
> >
> >
> >
> > --
> > Steve
> >


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message