incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alois Reitbauer" <alois.reitba...@dynatrace.com>
Subject RE: Snapshot Design Part II
Date Thu, 28 Jan 2010 14:05:55 GMT
Hi,

I say we need the when and the where dynamic. I want to specify that I need a dump now and
 I also want to specify the content. Especially when analyzing an application at runtime or
based on incidents I do not know up-front what and when to dump. Precompiling certain definitions
might make sense as well. However then we need something like prepared statements e.g. "get
count of objects of class xyz"

- Alois



-----Original Message-----
From: Sonal Goyal [mailto:sonalgoyal4@gmail.com] 
Sent: Mittwoch, 27. Jänner 2010 15:46
To: kato-spec@incubator.apache.org
Subject: Re: Snapshot Design Part II

Hi,

My comments inline.

Thanks and Regards,
Sonal


On Mon, Jan 25, 2010 at 9:22 PM, Steve Poole <spoole167@googlemail.com>wrote:

> Let's explore the basic outline of this API.
>
> 1 - It is a VM side API. That is  - it is active on the running system.
>
> 2 - It is declarative.  That means , like SQL,  OQL or similar query 
> languages it is an API where the user describes what they want to have 
> happen. There are no call backs into user code for selection purposes.
> The
> reasoning behind this is:
>
> A) At the point where this collection process is triggered then JVM 
> may be in poor state - at least where running Java is concerned.
>
> B) A declarative form allows the JVM vendor to implement their 
> solution at what ever level they choose.
>
> C) Similarly,  larger execution optimisations can be made by the JVM.
>
> D) Having selection criteria written in Java could result in queries 
> altering that which is being queried. Ignoring the inefficiencies, 
> there is a risk there could be an infinite loop or deadlock.
>
> 3 - It is dynamic - in that the definition can generally be changed up 
> until the time when the collection is triggered.  It is at least 
> additive in that applications may wish to register their specific 
> selections to be dumped and these selections could be mutually 
> exclusive.  In the event of having an  "A and Not B"  + "B and Not A" 
> situation the API must resolve this into "A and B"
>

The way I see it, the snapshot definition comprises of -
a) When. Snapshot for OOM say.
b) What. The selections. Start from root and collect x y z.

Are we saying that both when and what can be dynamic? Or is it only the
selections?

>
> 4 - Multiple instances of the snapshot definition can be created and in
> progress at the same time.
>
> 5 - Definitions  have a mechanism to allow then to define when they would
> be
> triggered. This would cover particular failure events such as exceptions.
>

We may also want to define periodic snapshots, time based triggers.

>
> 6 -  There would be some concept of a default snapshot that would be
> triggered by the JVM on a failing condition such as Out of Memory.
>
> 7 - The selection process  that chooses what would be in the dump has to
> have at least three component parts
>
> A) A way to define a starting point - this could be a starting object,
> class,  thread , class loader or even the heap.
>
> B) A way to define what should be collected and at what level of
> representation. By package, by classloader ,  matching super/subclasses,
> implements an interface etc.   When reporting an object what gets reported
> -
> all fields, object references (ie some unique id)  , array sizes , array
> contents etc?
>
> C) A way to define range and direction.  Consider whats happens if you
> wanted to get all objects of a type that were contained in a Map.   At the
> API level a Map is a single idea: at the implementation level its a
> collection of objects.  When searching for an instance the search needs to
> either have an understanding of logical structures or just be constrained
> to
> a number of hops in navigating object relationships.  Maybe both.  Consider
> also if you wanted to dump all the threads, their stacks and list the
> object
> references (unique ids) they contain.   That's a different axis to the
> "walk
> the heap" process.
>
> 8 - The API should probably cater for the situation where the selection
> requirements need to be provided to the JVM on start up.  This may be due
> to
> performance issues or because we identify an entity or situation that can
> only be reached during startup.  I don't have an example at this point but
> I
> do want to mention the possibility.
>
>
> 9) Execution time performance of this API is critical  - the design must
> offer the implementer the option of ahead of time compilation for these
> selections.
>
> 10) It needs to be at the appropriate level.   Its easy to see that there
> are some likely scenarios for this API which will require that all objects
> in the heap are visited.   For instance if you wanted to get a list of the
> objects that had a reference to some other object.    Traversing the heap
> for JVMs is a standard activity.  It doesn't seem that difficult to imagine
> a JVMTI extension or equivalent that could provide a callback mechanism for
> each live object found.   On the other hand we don't want to "just" or
> maybe
> "even" provide a C level API since that would constrain the JVM and/or the
> JIT options for optimization.
>
>
> Steve
>

Mime
View raw message