Kato API Design Topics

This page lists the topics for discussion and their eventual final status.

List

Reference	Description	status
1	The tracebuffers method on JavaRuntime API is an opaque method that is jvm specific. Unless it has value for other jvms it should be removed from the API	new
2	Returning JavaObjects from the heap: how should stack optimisations for objects be dealt with?	new
3	Are the descriptions of the hashcode methods on JavaOject clear and acceptable?	new
4	Should JavaObject being able to return monitors?	new
5	How should the API deal with java.concurrency support?	new
6	Should specific implementation details concerning JavaMonitors be exposed abd if so how?	new
7	Define user stories for bytecode sections etc? Should you be able to reconstitute classfiles for instance from a Dump?	new
8	JavaClassLoader - what is the findclass method for?	new
9	How do we deal with parallel class loading changes in Java 7?	new
10	JavaStackFrame Should be enhanced to allow retrieval of more JVM state - PC code , held monitors etc.	new
11	JavaLocation should have the ability to expose local variables	new
12	Need to specify what toString() should return for all API objects.	new
13	Clarify API support for mixed stack frames (of native and Java entries)	new
14	How to deal with values that are too big for Java entities. For instance what happens if top bit set in 64 address? No unsigned values in Java.	new
15	Need to clarify differences between CorruptData Exception and memory access.	new
16	What to do about iterators. They are not generic -some return corruptdata as well as other mixed objects.	new
17	Should the CorruptData object have a stack trace?	new
18	The API requires a provider mechanism. maybe URL based ie hotspot://	new
19	The API needs to be able to diferentiate between causing and failing threads and PIDS	new
20	Clarify why ImageProcess has a getPointerSize() method
21	Why have multiple heaps on the API?	new
22	JavaClassloader should have a type field so those impl who can say what type it is (ie jar, url system) can indicate so	new
22	JavaClassloader should have subtypes that can provide more common information - like real classpath or url etc	new