[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[mat-dev] Display of stack information
|
I've committed some changes to DTFJIndexBuilder
and DTFJHeapObjectReader to show a new way of viewing stack frame information.
These changes are protected by getExtraInfo
and getExtraInfo2 flags so should not affect normal operation.
Krum's stack trace viewer is useful
but is not that tightly integrated into the rest of MAT.
My idea, which I've had for some months,
is to treat stack frames as though they are Java objects of type the method
being executed. These means you have a pseudo Java object for each stack
frame. The thread refers to the frame and the frame refers to the locals
so you can easily see from the paths view which piece of code is keeping
an object alive. The instances of a frame are accumulated by method as
the method is treated as a pseudo Java class. This means you can tell from
the histogram view how many threads are executing a method. (Recursive
calls count more than once.)
If the size of the pseudo object is
taken as the size of the stack frame then the stack space used by all threads
executing that method can be seen from the shallow heap total for the method.
The retained set of a thread filtered
by method classes ".*\(.*" shows an accumulation of all the stack
frames for a thread. The shallow heap total shows the stack space used.
Pseudo-fields in the stack frame give
details of the line number, the compilation state, the current PC or JITted
code location, the frame number and the stack depth.
The OQL query
select * from ".*\(.*" s
where s.frameNumber = 0
finds all the stack frames (i.e. objects
of a class with a '(' in the name) where the frameNumber field is zero,
i.e. all tops of stacks.
If the byte code and JITted code size
is taken to be the size of the method pseudo class then by viewing all
the classes then filtering on methods ".*\(.*" it is easy to
find the methods with lots of code.
Please try out the changes by just rebuilding
with the getExtraInfo and getExtraInfo2 flags turned on.
Things I'm not sure about:
- How to explain the concept to
a user
- Whether all the method pseudo
classes will be confusing to a user or whether a standard histogram view
should exclude them.
- How to turn off and on this
mode - getSnapshotInfo().getProperty()
?
- How should method psuedo-classes
be named? E.g. org.eclipse.mat.dtfjtests.Collections.main([Ljava/lang/String;)V
or do we need the modifiers public/private/native etc. or can we omit the
return type or should the method name be separated from the class by a
space or dollar so that the package is still the package of the class
- The names of the pseudo-fields
Andrew Johnson
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature