Community
Participate
Working Groups
Some user written queries might only apply for dumps when certain software was running. Having the queries appear all the time in the query menu and query browser is confusing, and will get more so with additional queries e.g. JRuby The queries are context sensitive and will only appear if the required data is available. This is useful for queries such as unreachable objects, or path to GC roots which doesn't work with multiple objects. If this could be extended, e.g. so queries only appear if a certain class is present in the dump or as the type of objects in the selection then that might help. The @Subject annotation is used for name resolvers. Perhaps this could be used for queries.
One way would be tagging queries as: @Subject("org.eclipse.osgi.framework.internal.core.BundleRepository") public class BundleRegistryQuery implements IQuery Another would be something like this to indicate that the IClass should be filled in with the particular class. (Consider duplicate classes though.) How does this work with object selections - does the selection have to be a class object, or does it take the type of the selected object? public class BundleRegistryQuery implements IQuery @Argument(filter="org.eclipse.osgi.framework.internal.core.BundleRepository") public IClass cls; Another would be the following to say that all objects need to be of a particular type. Would this reject the query if not all the selection were of the required type, or would it just omit those objects (and possibly reject the query if no objects were then found)? public class BundleRegistryQuery implements IQuery @Argument(filter="java.util.AbstractMap") public IHeapObjectArgument args; or public class BundleRegistryQuery implements IQuery @Subject("java.util.AbstractMap") @Argument public IHeapObjectArgument args; @Subject is declared in the org.eclipse.mat.api bundle so isn't available to the org.eclipse.mat.report bundle, so QueryDescriptor can't do anything with @Subject The normal way of checking whether queries can be used is something like: query.accept(editor.getQueryContext()) && policy.accept(query) The first part says whether the data type is available for each argument, and then policy determines whether the selection context e.g. single or multiple objects or none etc. is suitable for the query, so e.g. a query not expecting an object or selection won't appear as a pop-up query. query is QueryDescriptor.accept in o.e.mat.report, which for each argument does if (!context.available(argument.getType(), argument.getAdvice()) && // !context.converts(argument.getType(), argument.getAdvice())) and the context.available() is defined in o.e.mat.api or o.e.mat.ui context.available() is used to see if a particular type is available from the query context, with a little bit of extra information from the Advice for the particular argument. There isn't quite enough information to tag say an IClass argument with a name to say only fill this in with a particular class as the Advice is just an Enum, and the whole argument is not available to the context.available call. The actual instance of the query is not yet available, so we cannot see if the argument has a default value and use that to flag the argument as being required to be a particular type. The policy might be usable to control how or whether arguments are filled in. It would be useful if new queries still worked on old versions of MAT.
I have check in some code to use Subject and Subjects annotations on queries. I've marked this use as experimental as I'm not sure if this is the best way yet. I've also modified the query history so it only displays a query in the history if the context, policy and subjects support it. I've also tagged the two Eclipse queries, the bundle explorer and leaking bundles query. This showed a bug as the leaking bundles query didn't appear on an Eclipse dump, and it seems the class name has changed, so I updated the query. @Subjects({"org.eclipse.osgi.framework.internal.core.BundleLoaderProxy", "org.eclipse.osgi.internal.loader.BundleLoaderProxy"})
New Gerrit change created: https://git.eclipse.org/r/138741
Gerrit change https://git.eclipse.org/r/138741 was merged to [master]. Commit: http://git.eclipse.org/c/mat/org.eclipse.mat.git/commit/?id=8c46cff36f323bbc0f92b5bc9fb4611aeecb0808
The above are changes for @Subject for the weak reference and finalizer reference queries.
Ideally the ArraysBySizeQuery would have: @Subjects({"byte[]", "boolean[]", "short[]", "char[]", "int[]", "float[]", "long[]", "double[]", "java.lang.Object[]"}) and QueryContextMenu - the pop-up menu on button 2 clicking on some results would only show the query if at least one object matched that selection. We have to be a bit careful for performance - we can't check millions of objects. We also need to be careful about matching subclasses. In the Java language, Object[] has a superclass of Object, and String[][] also has a superclass of object, but is an instance of Object[][] or even Object[]. It would be useful though if Subjects("java.lang.Number[][]") matched java.lang.Long[][]. Possible technique: Check the subject classes exist in the dump - if there are not then disallow the query. Check up to a limit (1000?, 1000?) objects to see if any match the subjects. If there are more objects than the limit, allow the query. Special case IContextObjectSet from a class histogram or superclass histogram as we can just check the class type instead of all the objects.
New Gerrit change created: https://git.eclipse.org/r/151634
Gerrit change https://git.eclipse.org/r/151634 was merged to [master]. Commit: http://git.eclipse.org/c/mat/org.eclipse.mat.git/commit/?id=d33ccaae4a3207c94797533baef0fd0ef0baaf1b
New Gerrit change created: https://git.eclipse.org/r/151671
Gerrit change https://git.eclipse.org/r/151671 was merged to [master]. Commit: http://git.eclipse.org/c/mat/org.eclipse.mat.git/commit/?id=dfb9ebe3385a02d7fe8a2a9cacbc29e5b46fa4e8
I've done the changes I have in mind - now it is a case of testing them.
The collection queries now have @Subjects annotations so they only appear when useful.
New Gerrit change created: https://git.eclipse.org/r/151726
Gerrit change https://git.eclipse.org/r/151726 was merged to [master]. Commit: http://git.eclipse.org/c/mat/org.eclipse.mat.git/commit/?id=985a2cebbab382d161340d967658891aa8961175
I have done all my changes. We just need to check that the context menu pop-up isn't slow on huge dumps. If it is then we need to know the exact type of selection, from which query and which selected objects, so that we can fix QueryContextMenu.
