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 Mon, 11 Jan 2010 11:43:10 GMT
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).

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
>

Mime
View raw message