You are viewing a plain text version of this content. The canonical link for it is here.
Posted to kato-spec@incubator.apache.org by Steve Poole <sp...@googlemail.com> on 2010/01/08 10:22:08 UTC
Replacing ImagePointer references in the Java Runtime API
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
Re: Replacing ImagePointer references in the Java Runtime API
Posted by Steve Poole <sp...@googlemail.com>.
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
<an...@uk.ibm.com>wrote:
> Steve Poole <sp...@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
Re: Replacing ImagePointer references in the Java Runtime API
Posted by David Griffiths <da...@gmail.com>.
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.
Cheers,
Dave
On Mon, Jan 11, 2010 at 5:19 PM, Stuart Monteith <st...@stoo.me.uk> 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
> http://blog.stoo.me.uk/
>
>
Re: Replacing ImagePointer references in the Java Runtime API
Posted by Stuart Monteith <st...@stoo.me.uk>.
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
http://blog.stoo.me.uk/
Re: Replacing ImagePointer references in the Java Runtime API
Posted by David Griffiths <da...@gmail.com>.
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 <sp...@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 <sp...@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
>
Re: Replacing ImagePointer references in the Java Runtime API
Posted by Steve Poole <sp...@googlemail.com>.
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 <sp...@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
Re: Replacing ImagePointer references in the Java Runtime API
Posted by David Griffiths <da...@gmail.com>.
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).
Cheers,
Dave
On Mon, Jan 11, 2010 at 11:26 AM, Steve Poole <sp...@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
>
Re: Replacing ImagePointer references in the Java Runtime API
Posted by Steve Poole <sp...@googlemail.com>.
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
Re: Replacing ImagePointer references in the Java Runtime API
Posted by David Griffiths <da...@gmail.com>.
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
Re: Replacing ImagePointer references in the Java Runtime API
Posted by Andrew Johnson <an...@uk.ibm.com>.
Steve Poole <sp...@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
Re: Replacing ImagePointer references in the Java Runtime API
Posted by Steve Poole <sp...@googlemail.com>.
On Fri, Jan 8, 2010 at 1:03 PM, David Griffiths
<da...@gmail.com>wrote:
> Hi Steve, I've read the discussion from last year about removing the
> Image API but don't understand. Why do people believe it is so
> difficult to implement the Image API? Are there particular parts of
> the Image API that they thought would be difficult? Not all of the
> Image API is required by the JavaRuntime API, do they also have
> problems with the subset that is? Are the folks you've talked to
> subscribed to this list and if so can they jump in?
>
>
Personally I think the Image API is the easy bit to implement and much
> less prone to change. Also there is scope for sharing implementations,
> eg the Image API for Linux core files can be used by Sun's Kato or by
> IBM's Kato. Not to mention the fact that having a well defined way for
> Java programs to access core files would have other spin-off benefits
> (example: when writing my zSeries emulator I ended up making it depend
> only on ImageInputStream so as to make the code as reusable as
> possible - if you wanted to disassemble some memory using the emulator
> all you needed to supply was an ImageInputStream implementation). Be
> nice to move to Java as much as possible for core file analysis and
> get away from gdb/dbx etc.
>
> Its not so much implementing the Image API etc that's the problem - it's
the coupling between the Image API and the JavaRuntime thats the issue.
The coupling is too tight at the moment. The only dump that exists that
can satisfy the whole API today is the system dump from an IBM JVM.
We currently force the other dump implementors to create ImageAddressSpace,
ImageProcess, ImagePointer etc even though they are generally meaningless to
them
We do want to keep the Image API pieces around but just loosen the coupling
between the native and the Java portions.
Also, what do you mean by a "handle mechanism"?
>
> Currently the API uses ImagePointer as a handle for objects - you can go
to the javaRuntime and get an JavaObject from an ImagePointer, and from and
JavaObject you can get an ImagePointer. For decoupling purposes (ie to
remove the dependency on ImagePointer) we can either make this process work
with primitive longs or create an alternative interface that doesn't have
the associated etc semantics that ImagePointer has.
And why is it more heavy handed to create (say) a JavaObject from a
> primitive long than from an ImagePointer? Are you thinking about
> caching?
>
> Yep - thats my worry. You can imagine that since implementations would
need to track the relationship between the long and the "real" object it
could easily be sub optimal if they had to keep a global cache between the
long and all types of entity within the Java Dump.
The extra point to consider in all this is that the "handle" whatever it is
needs to be able to be converted into a primitive value (number, string etc)
as we would expect in many cases that this value would be used outside a
JVM (stored in a database for instance)
I was thinking that being able to convert the Handle into a String for would
be a good way to go.
Cheers,
>
> Dave
>
> On Fri, Jan 8, 2010 at 10:22 AM, Steve Poole <sp...@googlemail.com>
> wrote:
> > 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
> >
>
--
Steve
Re: Replacing ImagePointer references in the Java Runtime API
Posted by David Griffiths <da...@gmail.com>.
Hi Steve, I've read the discussion from last year about removing the
Image API but don't understand. Why do people believe it is so
difficult to implement the Image API? Are there particular parts of
the Image API that they thought would be difficult? Not all of the
Image API is required by the JavaRuntime API, do they also have
problems with the subset that is? Are the folks you've talked to
subscribed to this list and if so can they jump in?
Personally I think the Image API is the easy bit to implement and much
less prone to change. Also there is scope for sharing implementations,
eg the Image API for Linux core files can be used by Sun's Kato or by
IBM's Kato. Not to mention the fact that having a well defined way for
Java programs to access core files would have other spin-off benefits
(example: when writing my zSeries emulator I ended up making it depend
only on ImageInputStream so as to make the code as reusable as
possible - if you wanted to disassemble some memory using the emulator
all you needed to supply was an ImageInputStream implementation). Be
nice to move to Java as much as possible for core file analysis and
get away from gdb/dbx etc.
Also, what do you mean by a "handle mechanism"?
And why is it more heavy handed to create (say) a JavaObject from a
primitive long than from an ImagePointer? Are you thinking about
caching?
Cheers,
Dave
On Fri, Jan 8, 2010 at 10:22 AM, Steve Poole <sp...@googlemail.com> wrote:
> 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
>