incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Monteith <stuk...@stoo.me.uk>
Subject Re: Telling one JavaRuntime from another
Date Thu, 24 Sep 2009 16:33:55 GMT
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 <spoole167@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/


Mime
View raw message