incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Poole <spoole...@googlemail.com>
Subject Re: Replacing ImagePointer references in the Java Runtime API
Date Mon, 11 Jan 2010 12:10:49 GMT
On Mon, Jan 11, 2010 at 11:43 AM, David Griffiths <david.griffiths@gmail.com
> wrote:

> I would be tempted to keep the interface as simple as possible unless
> anyone can think of a concrete example where things break down. If you
> ask the runtime for a JavaObject associated with an address (not token
> or handle or anything opaque like that :) then why do you need type
> info as well? Surely every VM implementation is able to deduce
> everything it needs from a raw address? (For compressed refs the value
> exposed would be the uncompressed raw address).
>
>
Well not really -  think of dumps where this is not an address - just some
reference  - might be a relative record number or an entry in a list.

Cheers,
>
> Dave
>
> On Mon, Jan 11, 2010 at 11:26 AM, Steve Poole <spoole167@googlemail.com>
> wrote:
> > Longs are definitely an option.
> >
> > For object recovery -  when you go to the JavaRuntime and ask for an
> object
> > you need to be able to provide the implementation with all the necessary
> > data it needs to find the object.   We  want to be able to ask for
> objects
> > of different types (beyond just JavaObject) so we need a mechanism where
> the
> > retriever can provide type and unique key info and get back the object.
> > We can do that with a Class / Long combination and that would be fine.
> >
> > I worry though about the cost of doing object recovery this way.  I'm
> > thinking of the fact that this object identity we've created would be
> great
> > for caching - you wouldn't have to hold the whole JavaObject object in a
> > cache just this new memento.    When you wanted the original you would go
> > the JavaRuntime and just ask.   But I think there is a need to allow the
> > implementor to store more info in this memento that just what we dictate.
> > Then when retrieving the object from the JavaRuntime the implementation
> may
> > be able to fast path to the data.  Having a specific interface would seem
> to
> > make that option available.
> >
> >
> >
> > On Mon, Jan 11, 2010 at 10:18 AM, David Griffiths <
> david.griffiths@gmail.com
> >> wrote:
> >
> >> Is there a reason you can't just use Long objects? Then you don't need
> >> to have any special way to construct them. I've been using primitive
> >> longs in Zebedee for many years and the only problem I've come across
> >> has been where you need to mark a pointer as null (uninitialized -
> >> mainly in the emulator). Using Long objects solves that.
> >>
> >> (I'm assuming things like compressed references will always stay
> >> internal to the implementation).
> >>
> >> Cheers,
> >>
> >> Dave
> >>
> >
> >
> >
> > --
> > Steve
> >
>



-- 
Steve

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