incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carmine Cristallo <carminecrista...@gmail.com>
Subject NMAT user stories
Date Tue, 10 Feb 2009 12:33:02 GMT
Ciao!
What follows is a list of potential user stories relative to the
Native Memory Analysis Tool. Following Adam's example, I've identified
each story with a code ("NMATx") to make it easier to discuss about
them.
I look forward to receiving your feedback...


        Carmine


==============================
Native Memory Analysis Tool user stories
==============================

The main purpose of this tool is to identify potential memory leaks.

In the following user stories, the term "memory section" is used to
indicate a contiguous area of memory, usually identified by a name,
containing information of similar type. For example, in the ELF file
format, the ".text" section usually contains executable code.
The term "memory allocation" will instead be used to indicate the area
of memory reserved by a single call to a malloc-like function.

NMAT1: as a Service Engineer, I want to have a summary for each memory
section, in order to get an initial memory profile. *

NMAT2: as a Service Engineer, I want to know which are the memory
allocations, their sizes and their base addresses;

NMAT3: as a Service Engineer, given the address of a memory
allocation, I want to know where in the memory it is referenced and
whether it corresponds to any symbol;

NMAT4: as a Java Service Engineer, given the address of a memory
allocation, I want to list all the Java objects having a reference to
that address;

NMAT5: as a Java Service Engineer, given a sequence of bytes, I want
to list all of its occurrences in the address space, to be able to
find possible eyecatchers;

NMAT6: as a Java developer or Service Engineer, I want to list all the
occurrences of direct buffers and their path back to the heap roots,
in order to find the potential causes of native memory leaks;

NMAT7: as a Java developer, i want to list all the occurrences of JNI
references (as reported by the runtime) that cannot be found in any
native stack, in order to find the potential causes of native memory
leaks.


* Each memory section will have the following information associated with it
        - Base address
        - Size
        - Read / write characteristics
        - Present in the actual dump or in a library (I think this
clarifies what is meant by 'backed by a library')
        - If it is a thread stack

Mime
View raw message