Support deferred loading snapshots in the Dart VM

[nex3]

Currently, it's not possible to use Dart's deferred loading feature in snapshots. This means that programs that sometimes use large chunks of code have to pay a substantial price up front even when that code isn't used (see issue #20470). It also means that snapshots aren't a reliable means of precompiling user code (issue #20482 and issue #20483), since that code may include deferred imports.

[iposva-google]

I am sorry, but I cannot reproduce the reported issue. Below is my sample program which loads deferred libraries from the local file system as well as from remote http servers:

File Bug20484.dart:
import 'Bug20484-def.dart' deferred as local;
import 'http://www.posva.com/dart/Bug20484-def.dart' deferred as remote;

main() {
  print("Before loading local.");
  local.loadLibrary().then(() {
    print("Loaded local library.");
    print(local.value);
    remote.loadLibrary().then(() {
      print("Loaded remote library.");
      print(remote.value);
    }).catchError((err) {
      print("Loading remote failed with:\n$err");
    });
  }).catchError((err) {
    print("Loading local failed with:\n$err");
  });
}

File Bug20484-def.dart:
var value = "This value is from the local library.";

File http://www.posva.com/dart/Bug20484-def.dart:
var value = "This value is from the remote library.";

Running without a snapshot as follows:
$ dart Bug20484.dart
Before loading local.
Loaded local library.
This value is from the local library.
Loaded remote library.
This value is from the remote library.
$

Creating a snapshot:
$ dart --snapshot=Bug20484.snap Bug20484.dart
$

Running with snapshot:
$ dart Bug20484.snap
Before loading local.
Loaded local library.
This value is from the local library.
Loaded remote library.
This value is from the remote library.
$

---

Added CannotReproduce label.

[nex3]

Sorry, I wasn't very clear in my report. What we need is the ability to deferred-load snapshots from other snapshots. In particular, we need something like dart2js's deferred loading support, where compiling a Dart application also compiles its deferred libraries.

For example, I'd expect your example to produce something like Bug20484.snap, Bug20484.part.1.snap, and Bug20484.part.2.snap.

---

Added Triaged label.
Changed the title to: "Support deferred loading snapshots in the Dart VM".

[sethladd]

Do we have a pub run startup perf bug so we can mark this as blocking that?

[iposva-google]

Regarding a comment 2: What you are looking for is a deployment tool. That would be dart2dart and not a script snapshot.

It seems that we are done here then.

---

Added AsDesigned label.

[nex3]

Seth: This is only blocking performance of executables with deferred loads, so I don't know how much sense it makes to mark it blocking on the performance bug for all executables.

Ivan: Snapshots are necessary for loading executables quickly. Currently there's no support at all for loading a snapshot of deferred code. A deferred load can only import Dart source, which is very slow. At the very least, we need a way to import a snapshot in a deferred way.

Even if we had that, though, there's no way for someone running the snapshot compiler to know what libraries need to be deferred without parsing and traversing the entire application. That's why it's important for the VM's snapshot tool to automatically generate the deferred snapshots that it will later load.

---

Added Triaged label.

[iposva-google]

As pointed out before this is a deployment tool question, not a VM snapshot question.

---

Added AsDesigned label.

[munificent]

Let me fill in some more context. As you know, we're working on optimizing the startup time of pub run. When pub runs a user's command-line application, we want to get it running as quickly as possible.

An obvious piece of overhead when starting an application is locating, loading, and parsing all of the source code. Large applications are often spread across hundreds of files, which is a lot of distinct IO operations.

Fortunately, the VM supports snapshots. Right now, Natalie is adding support to pub for pre-compiling an executable. When a user pulls down some package that exposes a command-line application, we compile it to a snapshot.

We put this snapshot in a special cache directory that is for the most part invisible to the user. We only put the snapshot there. When the user runs pub run, we then spawn a Dart process using that snapshot instead of loading from the package's source code.

If that application uses a deferred library, then the snapshot generated by the VM is no longer a complete snapshot of the entire program. When the VM loads the deferred libraries, it will try to read in other Dart files from source at paths that do not exist on the file system relative to the snapshot. (And, in the presence of transformers, do not exist on the file system at all.)

We don't want to copy all of the .dart source files into that cache directory in addition to the snapshot. Doing that, and then reading them in at startup defeats the purpose of caching and snapshotting.

I can't see how the current behavior is useful to a user unless you explicitly declare that they are disallowed from using deferred libraries. Can you describe how you expect a user to use snapshots in a real-world scenario?

---

cc @dgrove.
cc @larsbak.
Added Triaged label.

[nex3]

Marking this as "not planned" effectively means that deferred loading is invalid in any code that might possibly be used in a command-line context. Are we okay with that? @dgrove @kasperl