Snapshots contain VM data structures representing the loaded script, in a serialized form similar to Smalltalk images. To better understand what is contained in the snapshot, we should take a look at what the Dart VM creates when it reads the script:
- Library objects that reference all top-level structures, such as classes or methods and top-level variables.
- Class objects containing all objects that describe all methods and fields.
- Script and Tokenstream objects representing all the downloaded source code.
- String objects for all used identifiers and string constants in the source code.
This object graph is serialized to a file when creating a snapshot using a format that is not an agnostic of architecture. This allows the Dart VM to deserialize this snapshot file on 32-bit or 64-bit machines and re-create all the necessary internal VM data structures much faster than reading the source scripts from a set of files (see John's answer).
To clarify, John answered a bit. When you create a snapshot, Dart VM does not parse ALL of the source code. He only needs to analyze the upper level of the sources in order to be able to extract the definitions of classes, methods and fields, since they are presented in a serialized graph. In particular, the bodies of the methods are not analyzed, and, as is usually the case, for the scripting language errors will be reported only after the control reaches a certain method.
The goal of Java bytecodes is completely different, as Ladicek points out. You can create a snapshot of the VM data structures in the JVM after loading the bytecodes to get a similar effect.
In short: the snapshot contains an efficient view of all the data structures allocated in the VM dart heap that are needed to run the script.
-Ivan
source share