Provide hints on the type of mappings provided to the Dart VM.

[chinmaygarde]

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.

[chinmaygarde]

@rmacnak-google @a-siva: Let me know if I missed something from our conversation yesterday. cc @jason-simmons @zanderso who are looking into similar issues with engine managed snapshots.

[a-siva]

The CL that @rmacnak-google has here https://dart-review.googlesource.com/c/sdk/+/216580 has demonstrated that it does reduce the resident memory size of the app process (see numbers in the CL).
We should try and get this landed for the next stable release, what is the suggested path forward.

[zanderso]

It looks like the memory footprint savings are a bit under 10%. Do I have that right? It's a pretty nice chunk. There are only 6 working days before we start trying to cut the branch, so the schedule might be tight, but my suggestion would be that @jason-simmons continue on to this issue after #91382.

[a-siva]

It looks like the memory footprint savings are a bit under 10%. Do I have that right? It's a pretty nice chunk. There are only 6 working days before we start trying to cut the branch, so the schedule might be tight, but my suggestion would be that @jason-simmons continue on to this issue after #91382.

The change itself is small, I think if we agree on the plumbing needed for the engine, we could land the Dart side of the change early next week and ensure it gets rolled in.

[a-siva]

@zanderso @jason-simmons The commit https://dart-review.googlesource.com/c/sdk/+/216580 has rolled into the engine and I think the change to use it in the engine can now be done.

[jason-simmons]

@rmacnak-google has a PR in progress: flutter/engine#29320

[zanderso]

Is there anything left to do on this? Should we close it?

[a-siva]

I believe we can close it.

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.