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 2009/09/23 14:36:37 UTC
Telling one JavaRuntime from another
Random thought here.
We've said that in this API you can't use == but have to use .equals().
This is a consequence of the fact that we are trying to squeeze big dumps
into small heaps and want to allow implements the ability to only cache what
they need.. So I was just thinking about how to resolve the question of
determining if one Javaruntime instance was the same as another. It's
horribly possible that for somecases you'd have to do a complete and
exhaustive graph comparision of all the objects in the runtime instance.
The JavaRuntime API does't have any method to allow you to get any fast,
dump unique information - such as the underlying Image or even a dump
timestamp. Given that we want to support the JavaRuntime class as a 1st
class entity like Image we need to add something to resolve this problem.
How about adding a method to Image and JavaRuntime that returns a unique
identifer , one that would be different but persistent (ie you'd get the
same value if you opened the same dump file) Maybe then its simply a
method that exposes the file the dump is read from?
Cheers
Steve
Re: Telling one JavaRuntime from another
Posted by Steve Poole <sp...@googlemail.com>.
Here's my scenerio :
I'm building a persistent caching layer on top of a JavaRuntime instance
in which I write data to a database. I need to know if the if the
JavaRuntime object I've been given is one I've seen before on a previous run
so I can connect to the data I previously cached. ( Remember that I only
have the JavaRuntime Interface as an entry point)
On Thu, Sep 24, 2009 at 5:33 PM, Stuart Monteith <st...@stoo.me.uk> wrote:
> While the specification currently abstains from defining the behaviour of
> comparisons between objects from different dumps,
> we can discuss how it would work should we define a behaviour.
>
> There are varying degrees of difference.
> Should we regard two JavaRuntimes from two different dumps from the same
> JVM as equal()?
> I say we should, and instead use the Image to test for equality between
> dumps.
>
> I'd say that the aspects contributing to a JavaRuntime's identity are:
> The system it is running on.
> Its process identification information.
> Its main thread identification (ImageThread id) (this should be the first
> thread and last thread).
> The addresses of non-movable permanent structures.
> Not:
> The object graph - this can change.
> The classes
> Non-main thread information.
> Monitors
>
> Of course, I'm just considering JavaRuntimes backed by core files.
> Determining identity is more difficult with hprof, etc.
>
> Regards,
> Stuart
>
>
> Andrew Johnson wrote:
>
>> Steve Poole <sp...@googlemail.com> wrote on 23/09/2009 15:36:37:
>>
>>
>>> Random thought here.
>>>
>>> We've said that in this API you can't use == but have to use .equals().
>>> This is a consequence of the fact that we are trying to squeeze big
>>>
>> dumps
>>
>>
>>> into small heaps and want to allow implements the ability to only cache
>>>
>>>
>> what
>>
>>
>>> they need.. So I was just thinking about how to resolve the question
>>>
>>>
>> of
>>
>>
>>> determining if one Javaruntime instance was the same as another. It's
>>> horribly possible that for somecases you'd have to do a complete and
>>> exhaustive graph comparision of all the objects in the runtime instance.
>>>
>>> The JavaRuntime API does't have any method to allow you to get any fast,
>>> dump unique information - such as the underlying Image or even a dump
>>> timestamp. Given that we want to support the JavaRuntime class as a
>>>
>>>
>> 1st
>>
>>
>>> class entity like Image we need to add something to resolve this
>>>
>> problem.
>>
>>
>>> How about adding a method to Image and JavaRuntime that returns a unique
>>> identifer , one that would be different but persistent (ie you'd get
>>>
>> the
>>
>>
>>> same value if you opened the same dump file) Maybe then its simply a
>>> method that exposes the file the dump is read from?
>>>
>>> Cheers
>>>
>>> Steve
>>>
>>>
>> I don't see the point.
>> The spec. says:
>> The behaviour of equals against objects from different snapshots is not
>> defined.
>>
>> (I'm assuming 'not defined' means returning true or false, not
>> deliberately
>> doing something perverse.)
>>
>> so we do not have to worry about Java runtimes from different snapsnots.
>> Most implementations won't dynamically build JavaRuntimes so they can do a
>> quick reference comparison in equals().
>>
>> Also, the getJavaVM() returns a unique pointer. If pointer equality
>> compares
>> the address space and the addresses then the JavaRuntime.equals method can
>> compare the getJavaVM pointers.
>>
>> The ImageAddressSpace could do with an unique id (String?, parsable as
>> long or int if numeric).
>>
>> I presume if you open a dump twice then those are different snapshots, so
>> do not have to compare equal.
>>
>> Andrew Johnson
>>
>>
>>
>>
>>
>>
>>
>> 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
>>
>>
>>
>>
>>
>>
>>
>>
>
> --
> Stuart Monteith
> http://blog.stoo.me.uk/
>
>
Re: Telling one JavaRuntime from another
Posted by Stuart Monteith <st...@stoo.me.uk>.
While the specification currently abstains from defining the behaviour
of comparisons between objects from different dumps,
we can discuss how it would work should we define a behaviour.
There are varying degrees of difference.
Should we regard two JavaRuntimes from two different dumps from the same
JVM as equal()?
I say we should, and instead use the Image to test for equality between
dumps.
I'd say that the aspects contributing to a JavaRuntime's identity are:
The system it is running on.
Its process identification information.
Its main thread identification (ImageThread id) (this should be the
first thread and last thread).
The addresses of non-movable permanent structures.
Not:
The object graph - this can change.
The classes
Non-main thread information.
Monitors
Of course, I'm just considering JavaRuntimes backed by core files.
Determining identity is more difficult with hprof, etc.
Regards,
Stuart
Andrew Johnson wrote:
> Steve Poole <sp...@googlemail.com> wrote on 23/09/2009 15:36:37:
>
>> Random thought here.
>>
>> We've said that in this API you can't use == but have to use .equals().
>> This is a consequence of the fact that we are trying to squeeze big
>>
> dumps
>
>> into small heaps and want to allow implements the ability to only cache
>>
> what
>
>> they need.. So I was just thinking about how to resolve the question
>>
> of
>
>> determining if one Javaruntime instance was the same as another. It's
>> horribly possible that for somecases you'd have to do a complete and
>> exhaustive graph comparision of all the objects in the runtime instance.
>>
>> The JavaRuntime API does't have any method to allow you to get any fast,
>> dump unique information - such as the underlying Image or even a dump
>> timestamp. Given that we want to support the JavaRuntime class as a
>>
> 1st
>
>> class entity like Image we need to add something to resolve this
>>
> problem.
>
>> How about adding a method to Image and JavaRuntime that returns a unique
>> identifer , one that would be different but persistent (ie you'd get
>>
> the
>
>> same value if you opened the same dump file) Maybe then its simply a
>> method that exposes the file the dump is read from?
>>
>> Cheers
>>
>> Steve
>>
> I don't see the point.
>
> The spec. says:
> The behaviour of equals against objects from different snapshots is not
> defined.
>
> (I'm assuming 'not defined' means returning true or false, not
> deliberately
> doing something perverse.)
>
> so we do not have to worry about Java runtimes from different snapsnots.
> Most implementations won't dynamically build JavaRuntimes so they can do a
> quick reference comparison in equals().
>
> Also, the getJavaVM() returns a unique pointer. If pointer equality
> compares
> the address space and the addresses then the JavaRuntime.equals method can
> compare the getJavaVM pointers.
>
> The ImageAddressSpace could do with an unique id (String?, parsable as
> long or int if numeric).
>
> I presume if you open a dump twice then those are different snapshots, so
> do not have to compare equal.
>
> Andrew Johnson
>
>
>
>
>
>
>
> 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
>
>
>
>
>
>
>
--
Stuart Monteith
http://blog.stoo.me.uk/
Re: Telling one JavaRuntime from another
Posted by Andrew Johnson <an...@uk.ibm.com>.
Steve Poole <sp...@googlemail.com> wrote on 23/09/2009 15:36:37:
> Random thought here.
>
> We've said that in this API you can't use == but have to use .equals().
> This is a consequence of the fact that we are trying to squeeze big
dumps
> into small heaps and want to allow implements the ability to only cache
what
> they need.. So I was just thinking about how to resolve the question
of
> determining if one Javaruntime instance was the same as another. It's
> horribly possible that for somecases you'd have to do a complete and
> exhaustive graph comparision of all the objects in the runtime instance.
>
> The JavaRuntime API does't have any method to allow you to get any fast,
> dump unique information - such as the underlying Image or even a dump
> timestamp. Given that we want to support the JavaRuntime class as a
1st
> class entity like Image we need to add something to resolve this
problem.
>
>
> How about adding a method to Image and JavaRuntime that returns a unique
> identifer , one that would be different but persistent (ie you'd get
the
> same value if you opened the same dump file) Maybe then its simply a
> method that exposes the file the dump is read from?
>
> Cheers
>
> Steve
I don't see the point.
The spec. says:
The behaviour of equals against objects from different snapshots is not
defined.
(I'm assuming 'not defined' means returning true or false, not
deliberately
doing something perverse.)
so we do not have to worry about Java runtimes from different snapsnots.
Most implementations won't dynamically build JavaRuntimes so they can do a
quick reference comparison in equals().
Also, the getJavaVM() returns a unique pointer. If pointer equality
compares
the address space and the addresses then the JavaRuntime.equals method can
compare the getJavaVM pointers.
The ImageAddressSpace could do with an unique id (String?, parsable as
long or int if numeric).
I presume if you open a dump twice then those are different snapshots, so
do not have to compare equal.
Andrew Johnson
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