Background concurrent copying GC freed - Flutter

Viewed 53214

In my Flutter log I'm constantly getting this messages(just with some different numbers):

Background concurrent copying GC freed 153040(3MB) AllocSpace objects, 12(4MB) LOS objects, 49% free, 4MB/8MB, paused 819us total 173.633ms

I recently implemented the bloc pattern and I'm not that familiar with streams, maybe I've done something wrong there...

I got about 5000 lines of code so I can't post it all here, just wanna know if you know this problem, maybe it's a common error.

EDIT: Oh yeah, btw I'm testing on Android Emulator, Android Pie. My platform is Windows.

7 Answers

This is not an error, it's just an Android log message notifying you about when garbage collection takes place. Everything's normal. The log messages don't harm your app, see this question regarding the same topic on native Android. It's only a problem if you go out of memory, or you see performance hiccups due to garbage collection. Phew.


That being said, let's see how you might get less of these messages.

  • Typically, an emulator's resources are limited. So, the easiest way would be to increase the emulator's RAM size or use an actual phone instead of an emulator.

  • Secondly, make sure your logic doesn't handle huge amounts of data, or if it does, that it gets disposed as soon as possible.

  • Also, don't "cache" widgets yourself by storing them in a state like this:

    class _MyWidgetState extends State<MyWidget> {
      Widget button;
    
      @override
      void initState() {
        super.initState();
        button = RaisedButton(...);
      }
    
      @override
      Widget build() => button;
    }
    

    To get more information on why not to do this, check out my answer to a somewhat related question. Basically, Dart uses two types of garbage collectors, the Young Space Scavenger for short-lived objects and the Mark Sweep GC for long-lived ones. By caching your widgets manually, you're relying on the latter, which is slower and may actually notify Android about the freed memory, causing your logs.

  • Finally, you can always filter or ignore the logs. :D

Obviously it was a dumb mistake by myself... I made some update function, that added something to the Stream, and then instantly got called again because it was also listening to the Stream. So there was an infinite loop of adding and reacting to the Stream.

Thanks to anyone helping anyways, there are some useful tips!

It means your app is using memory and it is being freed by the GC(Garbage Collector).If the memory requirements are not too high you won't see GC firing up a lot of time to free the memory but if it uses too much memory then your app will lag. If there is performance hit then you need to fix it. Test this on a real phone if you can.

This should be normal, until your message says something like 0% Free, and the number GC freed is low. That means you are running out of memory and need to re-engineer your code.

Background concurrent copying GC freed 3(64B) AllocSpace objects, 0(0B) LOS objects, 0% free, 191MB/192MB, paused 217us total 1.338s

Don't mean to bump this question/answer but, in case is useful for others nowadays ... Another reason for this message to appear is when the logic of the application enters into an infinite loop (e.g. a cursor that never moves to Next record, etc). Eventually the GC starts doing too much work under such conditions.

Old question and some good answers already but, in my case, I forgot to include a cursor.moveToNext() in a DB query, -so I was running an infinite loop where I was creating an infinite number of objects- just in case it is useful to anybody.

In my case, I forgot to dispose my AnimationController object.

Related