incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Monteith <>
Subject Re: Replacing ImagePointer references in the Java Runtime API
Date Mon, 11 Jan 2010 17:19:19 GMT
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 
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:
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.


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