incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Poole <spoole...@googlemail.com>
Subject Dump classifications for snapshots etc
Date Fri, 18 Dec 2009 11:20:03 GMT
I'm in the process of getting the TCK running and I've been updating the
harness and ant tasks etc.
Now I'm at the point where I need to resolve more about the basic triggering
of a Dump.

The TCK will work in two modes  (my names)

"legacy" -   for those implementations where the contents are inconsistent,
irratic ,  non dependable.
"structured" - for those implementations which can make upfront promises
about the contents of a dump

For legacy they TCK will explore the data available and ensure that the
basic contracts of the API are met.
For structured mode the TCK will ask the implementation what types of data
it can provide and test accordingly.

In both these modes there is a Scenario setup process where a well defined
scenario is created in a JVM and then a dump is triggered.
The objective being that the dump will contain known data that the TCK can
look for afterwards.

The ScenarioLauncher class needs to know how to trigger a dump.   The
default mechanism will be to use the javax.tools.diagnostics.vm.Dump class
which will "know" how to trigger a dump depending on the JVM in question.

 I've put smarts into the reference implementation  Dump API  code so that
it can determine what dumps are available.

What we have available today is :

On an IBM JVM we can call one of several  Java methods on  class called
com.ibm.jvm.Dump.  (all the gory details can be found off here
http://www.ibm.com/developerworks/java/jdk/diagnosis/)   On a Sun JVM we can
trigger an HPROF dump
On either - if the kato  CJVMTI dump is present we can trigger that.

How do we represent these options to the caller of
javax.tools.diagnostics.vm.Dump?

For the snapshot mechanism  we know we want to pass in a descriptor of
content that can be used to determine the best dump to execute.   So
somthing like

Dump.execute(DumpContentDescriptor)

Now how do we move to the next step and define more about these dump
contents -   we could do something like this..

// create new descriptor

DumpContentDescriptor descriptor=new DumpContentDescriptor();

// set whats needed
descriptor.requireThreads(true);
descriptor.requireClassLoaders(true);

// set that we want a quick dump rather than a small dump

descriptor.prefer(DumpContentDescriptor.SPEED_OVER_SIZE);


// execute the dump.

Dump.execute(descriptor);

For the speed over size type discussion it will get complicated and may not
be sensible but I wanted to explore the flavour of the idea.

Comments?

-- 
Steve

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