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

Bug 329694

Summary:	Add more thread details from DTFJ
Product:	[Tools] MAT	Reporter:	Andrew Johnson <andrew_johnson>
Component:	Core	Assignee:	Andrew Johnson <andrew_johnson>
Status:	RESOLVED FIXED	QA Contact:
Severity:	enhancement
Priority:	P3
Version:	1.1
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:

Description Andrew Johnson

2010-11-08 12:48:56 EST

DTFJ provides additional information about threads from IBM dumps.
E.g. thread names from javacore, JNIEnv, priority, thread state etc, native stacks etc.

We could add this to the thread overview and thread details using an IThreadDetailsResolver.

One problem is that the additional columns will appear as empty columns in HPROF dumps if the DTFJ feature is installed.

This is because the getColumns() is method on the thread details resolver, and has no knowledge of the current dump type, so will always return the extra DTFJ columns.

This method doesn't seem entirely safe however. A Column can have its state changed e.g. with the sorting(SortDirection) method. This might cause problems if the column list was associated with the resolver object, which seems to have one instance per MAT, as the state could change. Fortunately we can get a new copy each time getColumn is called. Then there is the question as to whether IThreadInfo.setValue(col, val) will work properly as the column could change. Fortunately column equality is done via the name, so it does work.

We might then need to try to modify ThreadInfoImpl to only return the useful columns.

Comment 1 Andrew Johnson

2010-11-09 01:44:29 EST

The solution to the extra columns in HPROF dumps is to modify ThreadInfoImpl to only return used columns associated with the thread(s).

Comment 2 Andrew Johnson

2010-12-07 09:54:16 EST

The current code causes the following exception when thread overview is run on an HPROF dump without the DTFJ feature installed.

This is because resolution of the com.ibm.dtfj.api plug-in is optional, so that the org.eclipse.mat.dtfj plug-in can always be installed an run. This means that the DTFJ thread resolver is visible, but instantiating it causes this error.

org.eclipse.core.runtime.CoreException: Plug-in "org.eclipse.mat.dtfj" was unable to instantiate class "org.eclipse.mat.dtfj.ThreadDetailsResolver".
at org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.throwException(RegistryStrategyOSGI.java:180)
at org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.createExecutableExtension(RegistryStrategyOSGI.java:174)
at org.eclipse.core.internal.registry.ExtensionRegistry.createExecutableExtension(ExtensionRegistry.java:874)
at org.eclipse.core.internal.registry.ConfigurationElement.createExecutableExtension(ConfigurationElement.java:243)
at org.eclipse.core.internal.registry.ConfigurationElementHandle.createExecutableExtension(ConfigurationElementHandle.java:51)
at org.eclipse.mat.snapshot.registry.ThreadDetailResolverRegistry.createDelegate(ThreadDetailResolverRegistry.java:36)
at org.eclipse.mat.snapshot.registry.ThreadDetailResolverRegistry.createDelegate(ThreadDetailResolverRegistry.java:1)
at org.eclipse.mat.util.RegistryReader.addExtension(RegistryReader.java:77)
at org.eclipse.mat.util.RegistryReader.init(RegistryReader.java:62)
at org.eclipse.mat.snapshot.registry.ThreadDetailResolverRegistry.<init>(ThreadDetailResolverRegistry.java:30)
at org.eclipse.mat.snapshot.registry.ThreadDetailResolverRegistry.<clinit>(ThreadDetailResolverRegistry.java:21)
at org.eclipse.mat.inspections.threads.ThreadInfoImpl.extractFromDetailsResolver(ThreadInfoImpl.java:126)
at org.eclipse.mat.inspections.threads.ThreadInfoImpl.build(ThreadInfoImpl.java:71)
at org.eclipse.mat.inspections.threads.ThreadOverviewQuery.execute(ThreadOverviewQuery.java:60)
at org.eclipse.mat.query.registry.ArgumentSet.execute(ArgumentSet.java:129)
at org.eclipse.mat.ui.QueryExecution$ExecutionJob.run(QueryExecution.java:174)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Caused by: java.lang.NoClassDefFoundError: com/ibm/dtfj/image/CorruptDataException
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Unknown Source)
at java.lang.Class.getConstructor0(Unknown Source)
at java.lang.Class.newInstance0(Unknown Source)
at java.lang.Class.newInstance(Unknown Source)
at org.eclipse.core.internal.registry.osgi.RegistryStrategyOSGI.createExecutableExtension(RegistryStrategyOSGI.java:170)
... 15 more
Caused by: java.lang.ClassNotFoundException: com.ibm.dtfj.image.CorruptDataException
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:489)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:405)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:393)
at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:105)
at java.lang.ClassLoader.loadClass(Unknown Source)
... 21 more

Comment 3 Andrew Johnson

2010-12-07 12:19:09 EST

I've put a fix for the NoClassDefFoundError. We now create a simple class that delegates to the existing thread resolver class, and ignore an error on creating the existing thread resolver class.

Comment 4 Andrew Johnson

2011-01-22 10:59:06 EST

The code now works.