The Flutter Engine creates multiple mappings on Dart VM and Isolates initialization. However, not all regions in these mappings have the same usage and lifecycle requirements. Some are read-only while others are executable. Some are needed for the entire lifetime of the VM or Isolate while others can be freed immediately.

Ideally, the engine would have discrete mappings for each usage and precisely manage the lifecycle of each mapping on its own. However the number, size, and mechanism to generate these mappings is not fixed. This significantly complicates application packaging. These mappings are also internal implementation details in the VM.

The VM would like to provide advice to the operating system on how it intends to use various regions within the larger mappings. This is primarily done with platform specific calls like madvise. However, this is currently not possible today because VM doesn’t know how the mapping was created. All the engine gives the VM today is a pointer to the mapping and its size. With just this information, the VM cannot guarantee that the advice it gives the operating system is sound.

For instance, in the case of madvise and MADV_DONTNEED on Linux & Darwin, anonymous private mappings will be zero-filled. This will mess up subsequent uses of the mapping.

The engine already has knowledge about the types of mappings it gives the VM. This is done via subclasses of the pure virtual fml::Mapping in the engine. The engine and the VM should coordinate on a mechanism for tagging these mappings when they are provided to the the VM.

This approach should yield observable reductions in the memory usage of Flutter applications on platforms where the madvise call (or its platform specific implementation) is supported and implemented.