| [mat-dev] Proposal: MAT Warning System |
Proposal for an extensible warning system in MAT:
1. A new extension point named org.eclipse.mat.api.warningResolver. In a similar fashion to nameResolver, a class would be annotated with @Subject and implement an interface IClassSpecificWarningResolver with a method named resolveWarning. This would return an instance of a class WarningResolution which has two items: an enumeration value (Warning would be the only choice initially) and a "details" String.
2. A method is added to IObject: List<WarningResolution> getClassSpecificWarnings();
3. In a tree view, in the same way that any nameResolvers are called for each row, any warningResolvers would be called for each row. If a warningResolver returns a Warning result, the row is color coded. If there are multiple warning resolvers, the highest enumeration value is the one chosen. By default, the color for warning would be red, but there should be a preference to choose the color. Additionally, the context menu is modified to add an item at the top called "Warning Details." When clicked, this raises a dialog with the "details" Strings returned from the warningResolvers previously.
4. In an HTML view, any tree views converted to HTML tables should also have color coded rows, if applicable.
5. There is a special subject @Subject("*") which instructs MAT to call it's resolveWarning method for every class. This could be used by class-independent warning analysis, for example: Warn if an object's retained heap is > x% of total heap size.
6. A set of preferences are added: A checkbox to completely enable or disable the warning system (enabled by default) along with a way to choose the color for a warning.
Let me know what you think. If the proposal is good, I'll start working on a patch and send it to the group for review when ready. Also, this is changing the API (adding an extension point and adding a method to IObject) -- does that affect versioning, etc.?
Some other thoughts:
1. I thought about making IClassSpecificWarningResolver extend IQuery, and then clicking the warning details context menu item would run an instance of IClassSpecificWarningResolver to show a normal query. The problem is that this would be complicated to deal with if there are two or more warning resolvers for the same class and it would complicate the implementation for extensions.
2. An additional report could exist on the Overview screen under Reports named "Show Any Warnings." This would require finding all warningResolver extensions and passing each instance of the subject classes to check for warnings.
3. There could also be a preference to automatically run the report in #2 when loading a heapdump and show any warnings in a section in the Overview report.4. Options #2 and #3 could of course be very expensive so maybe an extension marks itself somehow as able to check for important warnings in some lightweight way, perhaps through a separate method call instead of passing all object instances to resolveWarning.
4. Options #2 and #3 could of course be very expensive so maybe an extension marks itself somehow as able to check for important warnings in some lightweight way, perhaps through a separate method call instead of passing all object instances to resolveWarning.
--
Kevin Grigorenko
IBM WAS SWAT Team
kevin.grigorenko@xxxxxxxxxx
Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/kevgrig/?lang=en