SimpleIntentions memory leak?
Hello Etienne, it looks like there's a bad memory leak when users have
both SimpleIntentions and my internal company plugin installed. My
plugin provides references (via ReferenceProviderRegistry) and
inspections in certain XML files. When opening these XML files, memory
usage climbs almost instantly to the maximum, even before making any
edit to the file, and performance gets very bad. I wonder if you have
source code available for the plugin, or if you're willing to
investigate the problem.
It looks like most of the retained size is from data inside VirtualFile
userData structure.
Please sign in to leave a comment.
Hi Keith
Tough accusation ;) But I'm surely open to investigate it.
If I understand you correctly, the memory increase happens BEFORE even triggering any quick fixes? If that's true, the memory leak would have to be somewhere in IntentionAction.isAvailable() or in LocalInspectionTool.checkXyz()? Do you agree?
IntentionActions: my IntentionActions do nothing but walking the psi tree and doing instanceof checks. To me, there is no potential for a memory leak.
LocalInspectionTools: my LocalInspectionTools check fields, methods, and classes. Do they get called when one opens an XML file? If not, there could only be a memory leak from a previous Java file inspection, I'd say.
LocalInspectionTools: besides instanceof checks and walking the psi tree, I have one place where I call
field.getManager().getElementFactory().createTypeByFQClassName(checkedType, type.getResolveScope());
but I do not keep on to the returned value outside method scope. I also have a two static finals that reference other constants: VariableKind and JavaTokenType.
Did you try to narrow down the problem by disabling the intentions and then enabling them one by one?
I'll send you the complete sources since I currently don't have the time to put them on the wiki.
--Etienne
If you never override checkFile(), then your stuff shouldn't be called on stock XML files (other than JSP/X). If all of your inspections are Java-specific (and you aren't trying to do tricky and ill-advised things where you look directly at import statements), you should never need to override checkFile().
You need to be careful with inspections that could trigger in non-Java files, since they can can easily be much larger than Java files, and there's no provision for checking inspections on some subset of the file on edit. Every change results in checkFile() being run on the entire file, whereas most changes to Java files only result in checkMethod() or checkField() being run on the changed method or field.
--Dave Griffith
Hi Dave
Thanks for the feedback.
I can confirm that I don't use checkFile() at all and I don't make any ill-advised things as far as I can tell ;)
--Etienne