incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Griffiths <david.griffi...@gmail.com>
Subject Re: Snapshot Design Part II
Date Thu, 28 Jan 2010 14:28:41 GMT
The time taken to parse such a statement is insignificant compared to the
time taken to scan the entire heap counting the number of instances of a
class. But if you're doing a regular expression match on the class name of
each object you find then you want to compile the RE.

Cheers,

Dave

On Thu, Jan 28, 2010 at 2:05 PM, Alois Reitbauer <
alois.reitbauer@dynatrace.com> wrote:

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message