You don’t have to worry about Dart garbage collector

In learning about Flutter, we know that the Widget is just a configuration file for the final RenderObject. It will be destroyed and created frequently during build. Don’t we need to worry about performance issues caused by its creation and destruction?

This is not necessary, as Dart is optimized for the creation and destruction of Flutter widgets. This is an important factor in Dart’s choice of Flutter in multiple languages, and can even be taken advantage of.

The following article parses the Garbage Collector for the Dart, interprets it, and interprets some of the content, including some of the typeset content.

The original address: https://medium.com/flutter/flutter-dont-fear-the-garbage-collector-d69b3ff1ca30

Dart is used as a development language and runtime mechanism for Flutter. Dart always retains the runtime mechanism, whether in debug or release mode, but there are big differences between the two build methods.

  • Under the debug model, Dart loads all the pipes (all the accessories needed) onto the device: Runtime, JIT (Just-in-time) compiler/interpreter (JIT for Android and Interpreter for iOS), debugging and performance analysis services.
  • In release mode, the JIT compiler/interpreter will be removed and the runtime will remain because the runtime is the main contributor to Flutter App.
The debug and release

The Dart runtime includes a very important component: the garbage collector, which allocates and frees memory when an object is instantiated or unreachable.

During Flutter operation, there will be many objects.

  • Before statelessWidgets are rendered (and, indeed, statefulWidgets), they are created.
  • When their status changes, they are destroyed again.
  • In fact, they have a short lifespan.
  • When we build a complex UI interface, there are thousands of such Widgets.

So, as Flutter developers, should we worry that the garbage collector doesn’t help us manage this well? (Does it cause a lot of performance problems?)

  • When Flutter is frequently creating and destroying widgets, is there an urgent need to limit this behavior?
  • It is common for new Flutter developers to create a reference Widget to replace the Widget in State when the State of a Widget does not need to change, so that it will not be destroyed or rebuilt.

There’s no need to do that

Concerns about Dart’s GC are unfounded (and unnecessary) because it’s generational architecture and implementation that allows us to create and destroy objects frequently and have an optimal solution. In most cases, we just need the Flutter engine to create and destroy Widgets the way it does.

The Dart in the GC

Dart’s GC is generational and consists of two phases: The Young Space Scavenger (scavenger for young collectors) and Parallel mark sweep collectors

Note: In fact the V8 engine works the same way

Scheduling

In order to minimize the impact of RG on App and UI performance, GC provides hooks to the Flutter engine, which are notified when the Flutter engine is policy that the App is idle and there is no user interaction. This gives the GC a window to run its mobile phase without affecting performance.

The garbage collector can also perform sliding compaction during those idle intervals to minimize memory overhead by reducing memory fragmentation.

The GC to do in your spare time

Stage 1: Young Space Scavenger

This phase focuses on cleaning up short-lived objects, such as StatelessWidgets. When it is blocked, it cleans much faster than the second generation of Mark and Sweep methods. And combined with scheduling, completion can eliminate the pause phenomenon when the program is running.

In essence, an object is allocated a contiguous amount of available memory until it is fully allocated. Dart uses bump Pointer (Note: Maintaining free_list redistribution, like malloc, is inefficient.) New space is allocated and processed very quickly.

The new space allocated for new objects is divided into two parts, called semi Spaces. One part is active, the other part is inactive. New objects are assigned to the active state, and once populated, objects that are still alive are copied from the active state to the inactive state, and dead objects are cleared. At this point the inactive state becomes active, and the above steps are repeated. (Note: GC to complete the above steps)

To determine which objects are alive or dead, GC starts with the root objects and examines their applications. The referenced objects (living objects) are then moved to the inactive state, and all living objects are moved directly. The dead Object is left behind;

For more information on this, see the Cheney algorithm.

img

Stage 2: Parallel Marking and Concurrent Sweeping

When objects reach a certain lifetime (they are not collected by the GC in the first phase), they are promoted to a new memory space managed by the second-generation collector: Mark-sweep.

The GC in this phase has two phases: the first phase, first traverses the object graph and then marks the objects that the person is using. In the second phase, the entire memory is scanned and any unmarked objects are reclaimed.

This GC mechanism blocks during the marking phase, with no memory changes and UI threads blocked. However, because ephemeral objects are processed in the Young Space Scavenger phase, this phase is very rare. However, because Flutter can call collection time, the performance impact is also seen to be minimal.

However, this often happens if the referencing program does not obey the generational mechanism. All this does not happen very often due to the Widget mechanism of Flutter, but we need to understand the mechanism.

Isolate

It is important to note that the Isolate mechanism in Dart has the concept of a private heap, independent of each other. Each Isolate has its own separate thread to run, and the GC of each Isolate does not affect the performance of other threads. Using Isolate is a good way to avoid blocking UI and reduce intensive tasks (note: you can use Isolate for time-consuming operations).

conclusion

Dart uses a powerful generational GC to minimize the performance impact of the GC in Flutter.

So you don’t need to worry about Dart’s garbage collector, which is the heart of our application.

Note: All content will be published on our official website. Later, Flutter will also update other technical articles, including TypeScript, React, Node, Uniapp, MPvue, data structures and algorithms, etc. We will also update some of our own learning experiences

The public,