incubator-kato-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From spo...@apache.org
Subject svn commit: r806520 - /incubator/kato/trunk/org.apache.kato/kato.docs/src/docbkx/chapters/Introduction.xml
Date Fri, 21 Aug 2009 12:07:26 GMT
Author: spoole
Date: Fri Aug 21 12:07:26 2009
New Revision: 806520

URL: http://svn.apache.org/viewvc?rev=806520&view=rev
Log:
small tweeks to intro

Modified:
    incubator/kato/trunk/org.apache.kato/kato.docs/src/docbkx/chapters/Introduction.xml

Modified: incubator/kato/trunk/org.apache.kato/kato.docs/src/docbkx/chapters/Introduction.xml
URL: http://svn.apache.org/viewvc/incubator/kato/trunk/org.apache.kato/kato.docs/src/docbkx/chapters/Introduction.xml?rev=806520&r1=806519&r2=806520&view=diff
==============================================================================
--- incubator/kato/trunk/org.apache.kato/kato.docs/src/docbkx/chapters/Introduction.xml (original)
+++ incubator/kato/trunk/org.apache.kato/kato.docs/src/docbkx/chapters/Introduction.xml Fri
Aug 21 12:07:26 2009
@@ -7,18 +7,18 @@
 
 	<section xml:id="introduction.jsr326">
 		<title>What is JSR 326?</title>
-		<para>JSR 326 is intended to be a Java API specification for
+		<para>JSR 326 is intended to be a Java<superscript>tm</superscript> API
specification for
 			standardising how and what can be retrieved from the contents of
 			post-mortem artefacts -
 			typically process and JVM dumps.</para>
 		<para>Unusually for new APIs, this project will endeavour to
-			encompass the old and the new. A diagnostic solution that only works
+			encompass the old and the new, since diagnostic solution that only works
 			when users move to the latest release does little to improve
-			diagnosability in the short term. This project will consume existing
+			diagnosability in the short term.</para><para>This project will consume existing
 			dump artefacts as well as possible while developing an API that can
 			address the emerging trends in JVM and application directions. The
 			most obvious of these trends are the exploitation of very large
-			heaps, alternative languages and, paradoxically for Java, the
+			heaps, alternative languages and, paradoxically for Java<superscript>tm</superscript>,
the
 			increased use of native memory through vehicles such as NIO.</para>
 	</section>
 
@@ -53,13 +53,13 @@
 	<section xml:id="introduction.rationale">
 		<title>Rationale</title>
 		<para>JSR 326 exists because of the widely acknowledged limitations
-			in diagnosing Java application problems after the fact.
+			in diagnosing Java<superscript>tm</superscript> application problems after
the fact.
 			There are many
 			good ways to understand and diagnose problems while they
 			happen, but
 			few credible or pervasive tools exist for helping resolve
 			problems
-			when all has gone suddenly and horribly wrong.</para>
+			when it has all gone suddenly and horribly wrong.</para>
 		<para>
 			Outside of "live
 			monitoring" there is no standard way to provide
@@ -78,25 +78,17 @@
 			especially unexpected or intermittent
 			failures.</para>
 		<para>
-			Consequently these
-			users turn to the providers of their software
-			to work out what
-			is
-			happening.
-			Application, middleware, and JVM vendors
-			are spending
-			increasing time supporting
-			customers in problem diagnosis.
-		</para>
-		<para>Emerging
-			trends indicate that this is
-			going to get worse.
+			These users turn to the providers of their software
+			to work out what is	happening. Consequently application, middleware, and JVM vendors
+			are spending increasing time supporting	customers in problem diagnosis.
+		</para>
+		<para>Emerging trends indicate that this is	going to get worse.
 		</para>
 		<para>
 			Today JVM heap sizes are measured in small numbers of gigabytes,
 			processors on desktops come in twos or fours,
 			and most applications
-			running on a JVM are written in Java. To help
+			running on a JVM are written in Java<superscript>tm</superscript>. To help
 			analyse problems in
 			these configurations,
 			we use a disparate set of diagnostic tools and
@@ -107,9 +99,9 @@
 			things
 			quickly get complicated. There are point tools for problems
 			like
-			deadlock analysis or the ubiquitous Java out-of-memory problems,
+			deadlock analysis or the ubiquitous Java<superscript>tm</superscript> out-of-memory
problems,
 			but
-			overall the Java diagnostic tools arena is fragmented and JVM- or
+			overall the Java<superscript>tm</superscript> diagnostic tools arena is fragmented
and JVM- or
 			OS-specific. Tool writers have to choose their place in this matrix.
 		</para>
 		<para>We want to change that by removing the need for tool writers
@@ -140,11 +132,10 @@
 			also covers living, breathing applications where the dump artefacts
 			are deliberately produced as part of live monitoring activity.
 		</para>
-		<para>For JSR 326 "Post Mortem" just means "after the fact"</para>
 		<para>Live monitoring generally means tracing, profiling,
 			debugging, or even
 			bytecode monitoring and diagnosis by agents via the
-			java.lang.instrument API. It can be a surprise to understand that It
+			java.lang.instrument API. It can be a surprise to understand that it
 			can also mean analysis of dumps to look
 			for trends and gather
 			statistics.</para>
@@ -168,6 +159,7 @@
 			contents
 			of the snapshot later.
 		</para>
+		<para>For JSR 326 "Post Mortem" just means "after the fact"</para>
 	</section>
 	<section>
 		<title>Tell me more about "Diagnostic Artifacts"</title>



Mime
View raw message