incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Johnson <andrew_john...@uk.ibm.com>
Subject Re: Replacing ImagePointer references in the Java Runtime API
Date Mon, 11 Jan 2010 09:50:13 GMT
Steve Poole <spoole167@googlemail.com> wrote on 08/01/2010 10:22:08:
> 
> I'm making made some good inroads into updating the API to match what we
> discussed last year in decoupling the Image API from the JavaRuntime 
API,
> A problem I've hit is that we can't use just a long to represent a
> JavaObject id instead of an ImagePointer (which was one of the 
suggestions)
> .
> 
> Currently the API for JavaObject lets you get an ImagePointer back to
> represent its "id".    The JavaRuntime class allows you to provide an
> ImagePointer and get back a JavaObject.   The original
> idea was that we replaced these mechanisms with one where you could get 
a
> long as an JavaObject Id and could provide JavaRuntime with a long and 
get
> back the corresponding JavaObject.
> 
> It turns out that there are other places where we use the ImagePointer 
as an
> "id" and do the eqivilent round tripping.  I need to fix them too. 
Forcing
> a implementation to reconstitute some of these other entities from a 
single
> number is heavy handed - there is other context required in some places 
and
> would require  an implementation to maintain a single name space (or is 
that
> number space) for all of its entities.
> 
> To remove those dependencies on ImagePointer and provide a sensible 
round
> tripping mechanism it seems better to go with a handle mechanism 
instead.
> I'm going to prototype that  implementation but I thought I should 
explain
> why I'm doing it that way up front.
> -- 
> Steve
You could have
package javax.tools.diagnostics.runtime;
interface RuntimePointer {
   public long getAddress();
}

then if the implementation had access to the memory then the 
implementation
of RuntimePointer could also implement ImagePointer.

You would need a way of constructing a RuntimePointer though, so that 
getObjectAtAddress could be called with a stored value. That then means 
that
arbitrary RuntimePointers could be built. equals() and hashCode() need to
be defined. Would RuntimePointer be just constructed - new 
RuntimePointer(val)
or built from the JavaRuntime or the ManagedRuntime, or change this method 
to
JavaRuntime.getObjectAtAddress(long addr)

Uses of ImagePointer in package javax.tools.diagnostics.runtime.java

JavaRuntime
public ImagePointer getJavaVM()
public JavaObject getObjectAtAddress(ImagePointer address)
JavaStackFrame
public ImagePointer getBasePointer()
JavaObject
public ImagePointer getID()
public List getSections()
- does an implementation without Image support just return an empty list?
JavaThread
public ImagePointer getJNIEnv()
JavaClass
public ImagePointer getID()
JavaVMOption
public ImagePointer getExtraInfo()
JavaMonitor
public ImagePointer getID()
JavaLocation
public ImagePointer getAddress()
Fetches the absolute address of the code which this location represents.
This pointer will be contained within one of the segments returned by
getBytecodeSections() or getCompiledSections() of the method returned by
getMethod().
null may be returned, particularly for methods with no bytecode or 
compiled
sections (e.g. some native methods)

What happens with JavaLocation.getAddress if the implementation could 
return
an address, but had no section knowledge?

Andrew Johnson
(personal view)






Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU







Mime
View raw message