Flutter-intellij: out of memory with big parts

[benoitskipr]

Steps to Reproduce

working within big files that have big (or maybe multiple?) part s makes editing laggy until AS runs out of memory, doesn't seem to happen in VS Code.

some_class.dart
part 'some_class.d.dart';

changing it to :

import 'some_class_part.dart';
export 'some_class_part.dart';

instantly makes editing faster, no more lag or out of memory errors

I'm not the only one noticing it : https://stackoverflow.com/questions/64734912/android-studio-running-out-of-memory-while-editing-big-multipart-dart-files

Version info

[✓] Flutter (Channel unknown, 1.22.2, on Mac OS X 10.15.7 19H15, locale en-BE)

[✓] Android toolchain - develop for Android devices (Android SDK version 30.0.2)
[✓] Xcode - develop for iOS and macOS (Xcode 12.1)
[✓] Chrome - develop for the web
[!] Android Studio (version 4.1)
✗ Flutter plugin not installed; this adds Flutter specific functionality.
✗ Dart plugin not installed; this adds Dart specific functionality.
[✓] VS Code (version 1.51.0)

[✓] Connected device (2 available)
! Error: Benoit’s iPhone is not connected. Xcode will continue when Benoit’s iPhone is connected. (code -13)

(happens as well on 1.22.2 stable)

[pq]

/fyi @alexander-doroshko @jwren @scheglov

[alexander-doroshko]

Memory snapshot may help to find memory consumers (Help -> Diagnostics Tools -> Capture Memory Snapshot)

[benoitskipr]

@alexander-doroshko I'm missing that last menu item, could it be 'Analyze memory usage' one level up ?

[alexander-doroshko]

Maybe Capture Memory Snapshot is only in later IDE versions. 'Analyze memory usage' could help as well (in the menu or right in the Out Of Memory dialog).

[benoitskipr]

memoryusagereport.txt
hope I did it correcly
I'll try to create a repro project
thanks

[4uzhoy]

Faced up with that problem today, after updating flutter sdk to 1.22.4, if downgrade to
[√] Flutter (Channel stable, 1.20.2, on Microsoft Windows [Version 10.0.18363.1198], locale ru-RU)
problem disappears, for me this more option than changing 'part' to import-export

[stevemessick]

I took a quick look at the log posted by @benoitskipr. There are some questionable entries. None of these are weak references.

13: [45.3K/1.45MB] [45.3K/1.45MB] org.dartlang.analysis.server.protocol.Location
14: [45.3K/2.71MB] [45.3K/2.71MB] org.dartlang.analysis.server.protocol.Element
The OP did say the files are big, so maybe 45K instances of Location and Element is not unexpected.

15: [45.1K/3.61MB] [45.1K/3.61MB] org.dartlang.analysis.server.protocol.AvailableSuggestion
I don't remember what AvailableSuggestion is used for but it sounds like something in the UI and should not need so many instances. OTOH, big files might have that many.

16: [40.4K/ 647KB] [40.4K/ 647KB] io.flutter.run.ObservatoryFile$Position
OK, big files, but it is still a lot of Position instances.

21: [26.3K/ 632KB] [26.3K/ 632KB] com.intellij.openapi.actionSystem.impl.ActionUpdater$$Lambda$1701
34: [16.1K/ 258KB] [16.1K/ 258KB] com.intellij.openapi.actionSystem.Presentation$$Lambda$461
I'd like to understand why we need 26K lambdas for ActionUpdater and 16K for Presentation.

36: [13.2K/ 727KB] [13.2K/ 727KB] com.intellij.openapi.actionSystem.AnActionEvent
Is 13K instances of AnActionEvent expected?

37: [13.2K/ 317KB] [13.2K/ 317KB] io.flutter.view.FlutterViewToggleableAction$$Lambda$6414
Another lambda-count that makes me wonder if something is not quite right.

@alexander-doroshko is my intuition accurate (these are too big) or do the instance counts look reasonable to you?

[alexander-doroshko]

@stevemessick Thanks for taking a look.

AvailableSuggestion is information about symbols (classes, fields, methods, etc.) that Analysis Server sends to IDE and IDE must keep it in memory because Analysis Server may reference any of AvailableSuggestion by id during code completion. So in projects with a lot of source files and dependencies, it's kind of expected that there are a lot of AvailableSuggestions. An they, in turn, reference Element, Location, String, and finally char[].

Are there more AvailableSuggestions than there should be? It's hard to say without having a real project in hands.

Other mentioned items are even more suspicious. You'll find paths from GC roots in that txt file. Looks like some Flutter-plugin classes collect lots of objects that they probably don't need and thus cause memory leaks. I haven't looked through the source code, but I think classes like io.flutter.utils.EventStream and key: io.flutter.utils.StreamSubscription need closer attention. One of the paths pasted:

CLASS: com.intellij.openapi.actionSystem.Presentation (19994 objects)
Root 1:
[ 8.9K/ 44%/ 730KB] 10.3MB          1   ROOT: Static field: org.dartlang.vm.service.logging.Logging.logger
[ 8.9K/ 44%/ 730KB] 10.3MB          1   (root): io.flutter.vmService.DartVmServiceDebugProcess$3
[ 8.9K/ 44%/ 730KB] 10.3MB          1   this$0: io.flutter.run.FlutterDebugProcess
[8.89K/ 44%/ 729KB] 6.83MB          1   app: io.flutter.run.daemon.FlutterApp
[8.89K/ 44%/ 728KB] 6.49MB          1   myVMServiceManager: io.flutter.vmService.VMServiceManager
[8.89K/ 44%/ 728KB] 6.25MB          1   serviceExtensions: gnu.trove.THashMap
[8.89K/ 44%/ 728KB] 6.25MB          1   _values: java.lang.Object[]
[8.89K/ 44%/ 728KB] 6.24MB          5   []: io.flutter.utils.EventStream
[8.89K/ 44%/ 728KB] 6.24MB          5   subscriptions: java.util.LinkedHashSet
[8.89K/ 44%/ 728KB] 6.24MB          5   map: java.util.LinkedHashMap
[8.87K/ 44%/ 727KB] 6.22MB          5   table: java.util.HashMap$Node[]
[8.87K/ 44%/ 727KB] 6.06MB       7140   []: java.util.LinkedHashMap$Entry
[7.14K/ 35%/ 585KB] 4.63MB       7140   key: io.flutter.utils.StreamSubscription
[7.14K/ 35%/ 585KB] 4.43MB       7140   onData: io.flutter.view.FlutterViewToggleableAction$$Lambda$6414
[7.14K/ 35%/ 585KB] 4.26MB       7140   arg$2: com.intellij.openapi.actionSystem.AnActionEvent
[7.14K/ 35%/ 585KB] 3.19MB       7140 * myPresentation: com.intellij.openapi.actionSystem.Presentation

[stevemessick]

Thanks @alexander-doroshko. I assume VSCode uses its equivalent of AvailableSuggestion similarly to the Flutter plugin, and since this problem is not happening to VSCode we can ignore that class. @DanTup can you confirm?

@jacob314 even for a large file, do you expect to have 7.14K instances of a single lambda in FlutterViewToggleableAction?

/cc @devoncarew

[DanTup]

I assume VSCode uses its equivalent of AvailableSuggestion similarly to the Flutter plugin, and since this problem is not happening to VSCode we can ignore that class. @DanTup can you confirm?

This depends on whether the LSP Preview setting is enabled. It's off by default, though will soon become default. @benoitskipr - do you have that enabled?

If LSP Preview is off, then AvailableSuggestions are cached in the client. If LSP Preview is on, then they are not (as the completion list comes entirely from the server each time).

[jacob314]

I would expect on the order of 10 instances of FlutterViewToggleableAction not 7.14K.

[benoitskipr]

@DanTup sry, what do you mean by LSP ? how do I check for it ?

[DanTup]

@benoitskipr it's an option in the VS Code settings:

It's off by default, so if you're not aware of it you probably don't have it enabled. In that case, VS Code would be caching AvailableSuggestionSets in its own process (although I'm not sure if there's an easy way to get a memory dump to compare that to Android Studio).

[benoitskipr]

Thanks, no then, can't even find that option in AS

[devoncarew]

I don't know if it can be the main cause of this OOM situation, but we do have a likely leak in FlutterViewToggleableAction.

https://github.com/flutter/flutter-intellij/blob/master/src/io/flutter/view/FlutterViewToggleableAction.java#L61

Above, we add a new StreamSubscription with every call to AnAction.update(), but never remove the subscription.

[hacker1024]

It looks like this may have been closed accidentally due to the "resolves" keyword in the merged PR.

[devoncarew]

@hacker1024 - thanks, good catch!

I'm going to close this again however as a likely dup of https://github.com/flutter/flutter-intellij/issues/5108. The fix for that issue is cherry-picked into our upcoming beta release. I'll ping that other issue once the beta is out.