incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Griffiths <>
Subject Re: Replacing ImagePointer references in the Java Runtime API
Date Mon, 11 Jan 2010 20:46:23 GMT
Maybe it would help to have some examples of why you would ever need
to have handles divorced and floating free from the objects they
represent? The only situation I can think of offhand is where you are
doing something interactive (eg gdb/jformat style) and want to display
info for a given address.



On Mon, Jan 11, 2010 at 5:19 PM, Stuart Monteith <> wrote:
> There are methods on ImagePointer that allow you to access the underlying
> memory.
> I am in favour of having a separation between those methods and the ID's
> returned
> from the classes in our API. I am still to be convinced though about the use
> cases
> beyond a simple long. I guess this is from performing:
>    whatever.getID().getAddress()
> and performing operations on said address. If in 99% of the cases you are
> taking the
> ImagePointer/Handle and stripping out the long, what is the point in having
> it?
> Where we might have a problem is with the round-tripping. But we should
> consider carefully
> the level of uniqueness there is.
> One proposal is to have a method that given a Handle, will return an object
> of any type within the API, of the correct type.
>    Object getThing(Handle handle);
> another is to have a method for each type:
>    JavaClass getClass(Handle handle)
>    JavaObject getObject(Handle handle)
> of course, what happens when we get down to:
>    JavaMethod getMethod(Handle handle)
> If the ID of a method is unique within the system , that's fine. But what if
> the ID for a method is an ordinal for a
> particular class? Method 1 in class A won't be the same method as method 1
> in class B.
> So should we use long as ID's and make statements about the uniqueness of
> the IDs? We could make it a matter
> of policy for them to be unique system wide, but that might not make sense
> under some circumstances.
> Thoughts?
> In that context a long is probably not
> David Griffiths wrote:
>> 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.
> --
> Stuart Monteith

View raw message