incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Griffiths <david.griffi...@gmail.com>
Subject Re: Replacing ImagePointer references in the Java Runtime API
Date Fri, 08 Jan 2010 13:03:00 GMT
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.

Also, what do you mean by a "handle mechanism"?

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?

Cheers,

Dave

On Fri, Jan 8, 2010 at 10:22 AM, Steve Poole <spoole167@googlemail.com> 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
>

Mime
View raw message