@chinmaygarde points out in that doc that it's possible to get to 0 after closing the last view, but it requires shutting down the Dart VM, there is now way to restart the DartVM after shutdown. I didn't find a bug on that, so I filed one: dart-lang/sdk#32990

Latest experiments show that this is a big problem on iOS also.

This is a blocking issue for customer: truth's evals. Not sure what the right label for that is, adding customer: critical for now.

During the shell refactor, I did add the ability to cleanly shut down the VM. However, since the VM couldn't be started back up after shutdown, currently, the sole instance of the VM is held in a single global pointer. Once the issue of not being able to call Dart_Initialize multiple times is settled, the engine should be able to correctly cleanup all VM related resources. The iOS embedder at that point should fully cleanup all resources. The Android API still has a few references to the the singleton FlutterMain that we should get to deprecating and cleaning up in the meantime however. I don't expect this to hold significant resource but still.

cc @jason-simmons

cc @a-siva

We have some static state in the Dart VM which either needs to be cleaned or made fields of a singleton object that gets deleted in Dart_Cleanup, will track this in the Dart issue dart-lang/sdk#21106

This issue is currently blocked on the Dart VM getting the ability to restart after being shut down.

We believe this will be unblocked soon.

@Hixie Is there a bug tracking this? After that is fixed, I still need to apply a minor patch to the engine to let go of the VM and reacquire it.

@chinmaygarde the Dart bug is dart-lang/sdk#21106

Latest status I could find was: https://dart-review.googlesource.com/c/sdk/+/76561#message-e413f837201d18a22e7ee2d458176d5424fc98b0
@bkonyi I hear you are working on this, is that correct? Can you let us know what the status is? Thanks!

The VM should be able to cleanup and reinitialize properly after this CL is fixed and landed (@chinmaygarde).

Looks like that landed. Is this ready to be implemented on the Flutter engine side now?

@a-siva Looks like patching in flutter/engine#6387 still causes failures. Could someone familiar with the VM patch that diff in locally and work past the crashes until all the unit tests pass? (./out/host_debug_unopt/runtime_unittests)

We have one Dart VM change related to this that is missing in the current Flutter version https://dart-review.googlesource.com/c/sdk/+/81442.
We are in the process of updating all the cherry picks for Dart into the 2.1_dev_9.x branch
(see https://github.com/dart-lang/sdk/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3Amerge-to-dev)
Once this is created we will roll this into the flutter engine.

I have patched this locally and tried the unit test and it passes just fine on Linux. On mac one of the unit test fails after about 500 iterations and I think it might be an engine or test issue. Need to chat with @chinmaygarde regarding this.

I don't think this covers everthing in here, but a lot of it will be covered when flutter/engine#6879 lands on the iOS side.

@chinmaygarde now that flutter/engine#7832 is landed, are we good to close this?

The patch had to be temporarily rolled back due to a failing test. The VM has been patched and I am awaiting a roll before re-landing. The tracking issue for this is filed here: #28184

Doing this safely has turned into a massive yak shave. The current issues being worked upon are as follows:
dart-lang/sdk#36502: Defer |Dart_Cleanup| till no isolates are in the middle of initialization. #36502
dart-lang/sdk#36503: Respect the message handler setting on the service isolate as it is shutting down. #36503
dart-lang/sdk#36504: "main" on the service isolate should be by posting a message on that isolate's message handler. #36504
dart-lang/sdk#36505: Let embedders create the service isolates on a thread of their choosing. #36505

Once the VM issues are resolved (I am working with the Dart team on this), I will have to make another pass and enable more unit-tests around secondary isolate spawns that may uncover more bugs. Hard to estimate the time remaining for this reason.

The Shell and the VM and can now safely be shutdown and cleanup all resources necessary at runtime. The shell and runtime unittests in the engine have been updated to verify this as well. The original patch that exposed this behavior to embedders was reverted because existing Flutter applications depend on "warming-up" the VM before launching the Flutter application. In the new world, there must be a shell instance running to prevent the VM from shutting down, or, a VM reference obtained from a running shell and reused across multiple shell instantiations. Without this extra bit of care, the work done to "warm-up" the Flutter application will lead to the a startup and shutdown of the VM (expensive) in the warm-up phase followed by another VM launch. After multiple benchmarks regressed, embedders were given back the old behavior by by adding the appropriately named Settings.leak_vm flag.

Now that the engine can guarantee thread safety of VM re-initialization, existing embedding APIs must be patched to account for this new behavior and set the leak_vm flag to false, templates updated and some strategy devised for existing applications in the wild depending on the warm-up behavior.

@chinmaygarde just to clarify, the remaining work here is all in the Dart VM -- specifically the four issues above? Should this be reassigned to @rmacnak-google / @a-siva for tracking?

No. Thanks to Ryan's patch in the Dart SDK related to safe shut-down of internal isolates, we should be good to go. The other open issues are still valid but are no longer blocking Flutter.

The next step is to audit existing applications/benchmarks to account for this new behavior. This is an open ended task that I am not sure how to proceed on. Original discussion that led to consensus on keeping the old behavior till embedders migrate was made here for reference.

If the original issue here is solved, can we move the remaining work to a new bug that clearly describes what problem remains to be fixed?

Are the originally affected customers satisfied with the current resolution?

Assigning to myself to break out sub-bugs and close this one.

Without additional information, we are unfortunately not sure how to resolve this issue. We are therefore reluctantly going to close this bug for now. Please don't hesitate to comment on the bug if you have any more information for us; we will reopen it right away!
Thanks for your contribution.

@chinmaygarde points out in that doc that it's possible to get to 0 after closing the last view, but it requires shutting down the Dart VM, there is now way to restart the DartVM after shutdown. I didn't find a bug on that, so I filed one: dart-lang/sdk#32990

I got the same issue, how could I shout down the Dart VM and restart the DartVM after shutdown

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.