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 13:05:41 GMT
Ok, I guess you must mean hprof dumps as an example. The spec just
says that objects have ids but doesn't say what that id represents.
Even though the id can be represented as a long I guess if it's an
index into a particular heap then you would also need to encode which
heap the object belonged to... on the other hand if you are never
going to say to the runtime "give me the object for this address
(which I have somehow obtained by some external mechanism, possible
from a log file)" then as Stuart said earlier, why have handles at
all, why not always pass around the JavaObject itself? In fact looking
at Andrew's list of uses of ImagePointer, they are all pretty much
used for getting the real actual address - I can't see much scope for
the roundtripping you're concerned about.

Cheers,

Dave

On Mon, Jan 11, 2010 at 12:10 PM, Steve Poole <spoole167@googlemail.com> wrote:
> 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
View raw message