align max listeners check with VS Code extensions' expectations

[akosyakov]

What it does

• fix Error: Possible Emitter memory leak detected #6659

Since we support multi root workspaces and VS Code extensions we started seeing many false positive leaking emitters. This PR addresses it in similar approach as VS Code does:

• increase the max listeners threshold to 175 listeners
• only warn on first exceed and then every time the limit is exceeded by 50% again. So only real leaking emitter will be reported more than once.
• report the top stack trace

How to test

• For leaking configurations: install python, java and go VS Code extensions (use Extensions view) and open typescript, python, java and go files
• For leaking FS wathcing: add more than 6 workspace roots.
• Check that you don't have many repetitive warning in both cases.
• Check for leaking editors: align max listeners check with VS Code extensions' expectations #7508 (comment)

Review checklist

• as an author, I have thoroughly tested my changes and carefully followed the review guidelines

Reminder for reviewers

• as a reviewer, I agree to behave in accordance with the review guidelines

[akosyakov]

I have not time to test it myself yet, I will do later today if no one does it before.

[RomanNikitenko]

@akosyakov
I don't see the warning at starting Theia now, but I got it after using Peek widget and switching between editors:

I'll try at debugging as I mentioned here #7506 (review)

[RomanNikitenko]

Using these changes I can not reproduce the use case described here #7506 (review)

[akosyakov]

@RomanNikitenko about onPreferencesChanged, I want to remove custom threshold 64, but I have to understand whether it is false positive (which are expected sometimes) or it is a real leak (looking at stack trace it is not). I am struggling to reproduce. Do you know how many editors did you open to reproduce? Could you do it reliably? If so then how?

[akosyakov]

ok, I found a pretty serious memory leak: DisposableCollection.onDispose is never disposed, so clients like editor.onDispose(() => { lalal }) actually keeping a reference to an editor, the same for other places where we delegate to DisposableCollection.onDispose.

There is a problem that DisposableCollection can be reused many times, so if we dispose onDispose then on next dispose there won't be an event. Looking at clients though I could not find a single expecting second event, so it seems to be alright.

I'm going to dispose this event on first dispose. If we break some clients they should be fixed then. cc @svenefftinge @AlexTugarev

[akosyakov]

Monaco editors are also leaking somehow via our quick open controller:

[RomanNikitenko]

@akosyakov

I am struggling to reproduce. Do you know how many editors did you open to reproduce? Could you do it reliably? If so then how?

Yes, I can reproduce it. I had about 10 open editors then went to TaskService -> @inject(WidgetManager) , used Peek -> Peek References, opened 8 editors to get the error.
I refreshed a page to have a clean state before testing.

[RomanNikitenko]

@akosyakov
btw: looks like I caught the error related to serializeURI at testing memory leak, you can see it on the video of my previous comment.

[akosyakov]

@RomanNikitenko i think you stumbled over #6733

[akosyakov]

Leaking editors should be fixed by removing custom closures on editor dispose. They used to capture an editor instance.

One can verify by:

• opening multiple editors
• using quick open command and peek references
• closing all editors
• triggering garbage collection
• taking the heap shanshot
• and checking that there is no many MonacoEditor instances anymore

[akosyakov]

@RomanNikitenko Could you check again please? I've fixed leaking editors.

[RomanNikitenko]

Tested using this way
I can not reproduce it after update!

[RomanNikitenko]

Also tested using the heap snapshots.
I had 24 MonacoEditor objects when editors were open.
and 2 objects after closing them.
One of them is MonacoDiffEditor, can not recognize another one

[akosyakov]

@RomaNikitenko sometimes widgets are hold temporarily by some contribution, for instance, the toolbar holds a reference to latest current widget. But it is not a real leak, since a reference gets removed when another widget becomes current.

[RomanNikitenko]

for instance, the toolbar holds a reference to latest current widget.

agree, I had the same idea (reference to latest editor widget) when faced with it