incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Poole <>
Subject New Dump Formats etc
Date Tue, 03 Feb 2009 13:37:37 GMT
Hi all,  :

 I'm beginning to realise that for some of you this API *really* is about
collecting data from a live JVM.  I had thought originally that the
diagnostic artifacts and the data within it would be the same for analysing
live or dead jvms.   Its dawning on me that this is not what some of you
think.    The problem is that  If we need to include statistical data from a
live jvm into an artifact it raises the question of  what data and what
artifact.   The trend analysis discussion has started to identify the types
of data required -   what we haven't considered is how this data is going to
get out of the JVM.

I didn't  want to have the discussion about new dump types or additions to
the JVM  until we had a better handle on the problem space we were
tackling.  Since the live jvm monitoring is more "lively" that I expected It
looks like  we do need to start that  conversation now.   Lets start by
talking through the good and bad points of the principles

 Here's my starter below - please respond with your thoughts on why new dump
types / jvm extentions are a good or a  bad thing

1 -  Good - Its very likely that with the growth of the size of a JVMs
working set it will become impossible to move the diagnostic artifact
around  -  so having a new dump that can be selective in what it contains
will be a sensible alternative.   (it could even be possible for
applications to add there critical info the dump too)
 2 -  Bad -  Public data formats of this sort are bad - they can force an
implementor to go through hoops to convert internal data into external
3 -  Ugly - If we did not specify a public dump format and left it up to the
RI to create something that did the mappings  - that would be just as bad.
What ever the RI came up with would be by default the way to solve the
problem.  The RI's data format  would become public by default.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message