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.

3 comments

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

0

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

0

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

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


0

Please sign in to leave a comment.