 Extending MAT by providing a new heap dump reader [message #516364] |
Tue, 23 February 2010 17:45  |
Erik Brangs
Messages: 36
Registered: February 2010 |
Member |
|
|
Hi,
I'm trying to extend MAT by providing a new heap dump reader.
Can anyone explain to me how the writing of the inbound/outbound indexes works and what the KeyWriterImpl is responsible for?
I'm having trouble at this point because I'm getting a NullPointerException in storeKey in KeyWriterImpl. The KeyWriter tries to access an id that does not belong to a ClassImpl. I assume that I am missing some references in my heap dump and/or using the Memory Analyzer APIs incorrectly but i have no idea what my mistake is.
PS: i'm developing against a 4xx revision of the memory analyzer
[Updated on: Tue, 02 March 2010 14:45] Report message to a moderator |
|
|
|
|
|
| Re: Extending MAT by providing a new heap dump reader [message #518191 is a reply to message #516364] |
Wed, 03 March 2010 12:28  |
 Andrew Johnson
Messages: 205
Registered: July 2009 |
Senior Member |
|
|
Yes, ClassImpl.usedHeapSize is the number of bytes used by the class object itself.
What this actually means varies with dump type. The DTFJ dump parser includes the size of bytecode and JITted code as well as the java.lang.Class object on the heap. HPROF dumps include a size based on the size of static fields.
http://dev.eclipse.org/blogs/memoryanalyzer/2010/02/25/heap- dump-analysis-with-memory-analyzer-part-2-shallow-size/
Including the byte code and JITted code sizes is a bit odd as those don't actually consume the heap, and so the MAT total heap size could exceed the -Xmx value, but it is also useful to know the big classes for non-heap memory reasons.
heapSizePerInstance is the default size of instances for non-array classes. For array classes this is the size of a pointer. The array pointer size used to be used to calculate the array size for ObjectArrayImpl/PrimitiveArrayImpl, but that is something that only the parser knows about, so now MAT always uses the array size table.
Normally all simple objects are of the same size. I've recently added a feature to allow simple objects of the same type but different sizes:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=301228
If a simple object is not of the default instance size for a class then the parser adds an entry for it to the array size map.
Dummy classes with zero class and instance sizes do work. I've used them in the DTFJ parser. Every object in MAT must have a type, so you still need to call addInstance(0) on the dummy class's type.
Running the DTFJ parser with -Dmat.methods_as_classes=true creates some dummy classes, in a completely different hierarchy from Java.
Java:
instance java.lang.Object, type class java.lang.Object
instance java.lang.String, type class java.lang.String
class java.lang.Object - type class java.lang.Class, superclass null
class java.lang.String - type class java.lang.Class, superclass class java.lang.Object
native memory/stacks/methods:
class <native memory>, type class <native memory type>, superclass null
class <native memory type>, type class <native memory type>, superclass class <native memory>
so
class <native memory> is like class java.lang.Object
class <native memory type> is like class java.lang.Class
I think here is a good place for discussions about extending MAT. You are an 'adopter', and it is good to see adopters as well as 'users'.
http://www.eclipse.org/projects/dev_process/development_proc ess.php#2_3_Three_Communities
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.04249 seconds
] 
Search
Help
Register
Login
Home
