Extending MAT by providing a new heap dump readerhttps://www.eclipse.org/forums/index.php/mv/msg/163200/516364/#msg_516364
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]]>Erik Brangs2010-02-23T17:45:41-00:00Re: Extending MAT by providing a new heap dump readerhttps://www.eclipse.org/forums/index.php/mv/msg/163200/516817/#msg_516817
DTFJIndexBuilder.validateIndices() does some checking for the DTFJ Parser as I found debugging index problems hard. You could try using this as a basis for checking your indexes. Perhaps this should be moved into the core of MAT.

Some things it checks:
1.indexToAddress index is in ascending order without duplicates.
2.all objects have a class index in objectToClass
3.all the class indexes found by objectToClass find a valid ClassImpl from idToClass
4.If the object is an ordinary object, i.e. idToClass == null then arrayToSize >= 0
5.for classes objId -> classImpl -> objectAddress is the same as objId -> address, also classImpl->getObjectId == objId
6.For classImpl getClassId == objId of class -> objectToClass
7.every class has a class loaderId
8.GC roots in range

Also for outbound refs, the first ref must be to the objects's class. This isn't checked, but is assumed by MAT.

Also for outbound refs, the first ref must be to the objects's class. This isn't checked, but is assumed by MAT.

Thanks a lot, that solved my problem.]]>Erik Brangs2010-02-26T16:39:03-00:00Re: Extending MAT by providing a new heap dump readerhttps://www.eclipse.org/forums/index.php/mv/msg/163200/517929/#msg_517929
I also want to add some dummy classes for unboxed types. Can I do this by providing a classImp with both usedHeapSize and heapSizePerInstance being zero?

Finally, is the forum a good place to ask these kind of questions or should I ask on the mailing list?]]>Erik Brangs2010-03-02T14:44:49-00:00Re: Extending MAT by providing a new heap dump readerhttps://www.eclipse.org/forums/index.php/mv/msg/163200/518191/#msg_518191
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.

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.

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
]]>Andrew Johnson2010-03-03T12:28:02-00:00Re: Extending MAT by providing a new heap dump readerhttps://www.eclipse.org/forums/index.php/mv/msg/163200/519316/#msg_519316
I couldn't resist to ask you: for what kind of heap dump format you are trying to extend MAT? We haven't had many adopters so far, and I'm really curious to learn more. Of course, only if you can talk about this and if you feel like sharing the info.

I couldn't resist to ask you: for what kind of heap dump format you are trying to extend MAT?

I do not want to raise expectations, because I'm a student and my time for the implementation is limited.

I'm trying to extend MAT for use with the metacircular Jikes Research Virtual Machine ( http://www.jikesrvm.org/ ). I'm doing this for a practical course at my university.

The Jikes RVM does not contain any way to do a heap dump at the moment so I am also trying to add that feature. This includes the definition of a new heap dump format. I use a text-based format defined by myself. I'm trying to dump only the information that is absolutely necessary.

I would use a binary format but that would require more complex changes and I'm already having enough trouble with the Jikes RVM. The dump feature is not working correctly at the moment, so I do not know how much progress I will be able to make with extending MAT. I'm not even done with the HeapObjectReader.]]>Erik Brangs2010-03-09T09:28:30-00:00Re: Extending MAT by providing a new heap dump readerhttps://www.eclipse.org/forums/index.php/mv/msg/163200/520999/#msg_520999
Have fun with your projects and if you have some further questions about the reader I hope we can answer them.
]]>Krum Tsvetkov2010-03-16T07:13:57-00:00