incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Monteith <>
Subject Re: "Snapshot" support
Date Tue, 08 Sep 2009 14:53:01 GMT
I think the functionality to be addressed by this API and the JVM are:

1. When to generate the dump.
2. What to call the dump file.
3. What should be in the dump.
4. What should do the dumping.

1. When to generate the dump.
There would be a few use cases met by just having a method that 
generates a dump file when it is called.
In addition there may be certain events where we'd want a dump file 
For example:
    when exceptions are thrown.
    when OOM occurs.
    when a time interval has expired.

These kinds of features already exist. For example, there is already a 
JMX MBean that can be invoked to generate a heapdump.
The IBM J9 JVM has features whereby dumps can be generated given certain 
command line parameters - these are non-standard and
can't be set at runtime.
Should we be providing this within the JMX infrastructure?

2. What to call the dump file.
I think it might be useful if we can provide a template to name the 
file, much like core file configuration might be done on linux, etc.

3. What should be in the dump.
I think this will require some use cases. But to my rough thoughts are:

 * Enable callers to choose what types of information - e.g. threads? 
Monitors? objects+classes? memory? imagethreads?
 * Enable callers to identify certain entities in the JVM to dump, and 
dump only them.
   - Dump thread "This name", or the thread "java.lang.Thread thisthread;"
   - Dump classes in classloader "java.lang.Classloader loader;"
   - Dump objects of certain types identified with java.lang.Class.
   - Dump all objects from this point in the object graph up to n 
references away - a truncated object graph.
   - Dump all objects "tagged" in a certain way using bytecode injection.

Those are my rough ideas, how some of this would be specified are just 
details ^_^

4. What should do the dumping.

There may be multiple implementations of the snapshot API available.
I'd hope that for each JVM there'd be a fully-featured, highly 
integrated implementation. However, that might not be the case.
One way to select an implementation would be by automatically choosing 
the implementation that provides the functionality that are being 
requested. e.g. an dump needing a memory dump would choose the 
implementation that uses core dumps.
An alternative would be to choose them by name, or by class.



Steve Poole wrote:
> One of the capabilities that this API is intended to provide is support for
> "Snapshots"
> This is  based on the idea that for various reasons the dumps that we can
> get today can be too big, take too long to generate , not have the right
> information etc.
> Also we need to recognise that dumps are not only produced to help diagnose
> a failure.  Some users consume dumps as part of monitoring a live system.
> So we need to discuss (at least)
> a)  How dump content configuration would work
> b)  What sorts of data are needed in a snapshot dump
> This is the largest outstanding piece of the API.   Now with Alois and
> Andreas on board we can start to clarify usecases and  resolve the design
> Cheers
> Steve

Stuart Monteith

View raw message