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: Telling one JavaRuntime from another
Date Fri, 25 Sep 2009 06:51:26 GMT
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 <stukato@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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message