incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Poole <spoole...@googlemail.com>
Subject Re: Replacing ImagePointer references in the Java Runtime API
Date Mon, 11 Jan 2010 10:09:01 GMT
hi Andrew - what you've suggested is pretty much what I've done though I've
added the capability for to retrieve the entity type as well as an
address.   I'll post the interface definition as a separate mail so not to
clog this one up.

For JavaLocation  I have just converted the getAddress() method  into
returning a long for now .  Its something we need to resolve though.

On Mon, Jan 11, 2010 at 9:50 AM, Andrew Johnson
<andrew_johnson@uk.ibm.com>wrote:

> 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
>
>
>
>
>
>
>


-- 
Steve

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message