Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 324949

Summary:	Tidy up usage of threads index
Product:	[Tools] MAT	Reporter:	Andrew Johnson <andrew_johnson>
Component:	Core	Assignee:	Andrew Johnson <andrew_johnson>
Status:	RESOLVED FIXED	QA Contact:
Severity:	minor
Priority:	P3
Version:	1.1
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:

Description Andrew Johnson

2010-09-10 07:35:24 EDT

The thread stack information is passed from the parser in a text file with extension .threads

We don't currently delete this file when the indexes are deleted. See SnapshotHistoryView.java

Do we document the format of this file?

Should this file be names dump.threads.index instead of dump.threads ?

Is there anything else?

Comment 1 Andrew Johnson

2012-01-10 08:55:18 EST

Renaming this file would be tricky as then old versions of MAT couldn't reopen dumps parsed with a newer version. We should reconsider this when the index format is changed for another reason.
SnapshotHistoryView does now delete the threads file.
SnapshotFactoryImpl.deleteIndexFiles does not delete the threads file though.
It might be possible to get the IndexManager to handle the threads file.
The IndexManager should be able to handle the RetainSizeCache index though.

The threads file format is multiple sections as follows:

Thread 0x7ffe04c1890
 at java.lang.Object.wait(JI)V (Native Method)
 at java.lang.Object.wait()V (Object.java:167)
 at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.getNextEvent()Lorg/eclipse/osgi/framework/eventmgr/EventManager$EventThread$Queued; (EventManager.java:397)
 at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run()V (EventManager.java:333)

 locals:
  objecId=0x7ffe04c1890, line=0
  objecId=0x7ffe04c1890, line=2
  objecId=0x7ffe04c1890, line=2
  objecId=0x7ffe04c1890, line=3

"Thread" is matched to find the start of a section for a thread
The thread address is optional - but if omitted then none of the information is stored for that thread.
The stack frame data is just text, but should be in the same format as a Java stack trace.
A blank line ends the stack trace.
"locals" starts the local variable information
The line number in the stack trace (0-based) is matched by the decimal number following the "line=".
If the line number is found then the the object id is matched using the "0x" and the "," comma to delimit the hex address of the object on the stack frame.
A blank line ends the local variable section.

Comment 2 Andrew Johnson

2012-01-10 11:51:51 EST

I've updated the wiki: http://wiki.eclipse.org/MemoryAnalyzer/Adding_a_new_heap_dump_format_to_the_Memory_Analyzer#IIndexBuilder

I've changed the file delete methdo on reparse to correctly delete the index files and the threads index.

I've change the index file date comparison to not reparse if the dump and index are the same date.

Comment 3 Andrew Johnson

2012-04-24 05:24:59 EDT

The file encoding of the threads index file could be important, particularly if there are accented characters in thread class names and the indexed dumps are reopened on different systems.
Notes are already encoded in UTF-8, so we should do the same for threads index.

Comment 4 Andrew Johnson

2018-05-06 05:25:19 EDT

The file encoding is now UTF-8 (changed a long while ago)
This work is now complete