incubator-kato-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject svn commit: r802784 - /incubator/kato/trunk/org.apache.kato/
Date Mon, 10 Aug 2009 13:21:33 GMT
Author: monteith
Date: Mon Aug 10 13:21:32 2009
New Revision: 802784

Add more detail to todo.xml explaining what is missing.


Modified: incubator/kato/trunk/org.apache.kato/
--- incubator/kato/trunk/org.apache.kato/ (original)
+++ incubator/kato/trunk/org.apache.kato/ Mon Aug 10
13:21:32 2009
@@ -29,36 +29,65 @@
   <title>Native and Java Frame interleaving</title>
+  <para>
+ 	The API presents native stack frames and Java stack frames in different places in the API
- in ImageThread
+ 	and JavaThread. This makes it difficult to understand the order in which Java methods and
native functions
+ 	have been called. Exposing the interleaving of native and Java frames would help, for example,
+ 	complex JNI functions.
+  </para>
-  <title>Optimization of data access (query support)</title>
+  <title>Optimisation of data access (query support)</title>
+  <para>
+	The current programmatic means of accessing data is not open to optimisation. Having a query
+	would enable the creation of useful indexes to speed up queries.  
+  </para>
-  <title>No support for identifing or handing generics in the Java Runtime</title>
+  <title>No support for identifying or handing generics in the Java Runtime</title>
+  <para>
+  	Currently it is impossible to determine any of the generic type information that is available
+  	JVMs implementing Java 5.0 or above. 
+  </para>
-  <title>No support for thread groups  in the Java Runtime</title>
+  <title>No support for thread groups in the Java Runtime</title>
+  <para>
+  	The API has no consistent means of reporting the ThreadGroups the JavaThreads belong to.
+  </para>
-  <title>Lack of consitancy in accessing JavaObjects</title>
+  <title>Lack of consistency in accessing JavaObjects</title>
-  Accessing data as their own type is difficult or impossible.
+	In order to access the contents of objects in most cases it is often necessary to implement,
as accesses
+	via the API, at least a subset of the functionality of the  methods in the class of the
object being accessed.
+	For example, to access all of the objects in a java.util.HashMap, knowledge of how HashMap
+	implemented is necessary. As HashMap can be implemented differently on different implementations
of the
+	Java SDK, it is difficult to write programs using the API that are truly Java SDK agnostic.
   <title>Need defined behaviour on what toString offers on each part of the API</title>
+  <para>
+  	The toString() method's behaviour is not specified in sufficient details across the whole
+  	For example, JavaStackFrame.toString() should return a string describing the stack location
+  	like in a Java stacktrace, so this should be specified so it can be implemented consistently.
+  </para>
-  <title>Can't see the finaliser info</title>
-  </sect3>
-  <sect3>
-  <title>No definitions about snapshotting</title>
+  <title>No definitions about snapshoting</title>
+  <para>
+  	It is desirable that there be a consistent means for generating dumps for later analysis
+  	by the API. An API to be used during runtime would enable applications to generate dumps
+  	it suits them. This would not be to the exclusion of other means of generating dumps 
+  	peculiar to particular JVM implementations. 
+  </para>
- </chapter>
\ No newline at end of file
+ </chapter>
\ No newline at end of file

View raw message