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 Mon, 11 Jan 2010 11:26:12 GMT
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 <
> 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


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