commit | 7b50b7a8e650035c435c4d48abdc4ba90206df9e | [log] [tgz] |
---|---|---|
author | Alexander Markov <alexmarkov@google.com> | Wed Jun 26 18:25:26 2019 +0000 |
committer | commit-bot@chromium.org <commit-bot@chromium.org> | Wed Jun 26 18:25:26 2019 +0000 |
tree | 03b6687d9b68433cf0330fd04a53df2ce183db8d | |
parent | c1c24c2e192c45792e08217337a01e1d60fc224d [diff] |
[vm/bytecode] Bootstrapping VM from bytecode Previously, core snapshot was generated from AST (because --enable-interpreter/--use-bytecode-compiler was not specified when building core snapshot). As the result, CL https://dart.googlesource.com/sdk/+/da8cb470cc94830a98d49532e8d5d1a5b3d80f8b which declared libraries in bytecode also removed bytecode entirely from core snapshot in Dart SDK. This CL enables bytecode by default if --bytecode argument is specified for gn.py. This enables JIT compiler from bytecode (interpreter is still disabled by default but can be enabled using --enable-interpreter). Core snapshot and other snapshots now have bytecode. This change revealed a bunch of bugs which are fixed in this CL: * _Closure fields were treated as unboxing candidates which triggered assertion in LoadFieldTOS in interpreter. * Several places should load class declarations if they are not loaded yet. * Canonicalization of TypeRef objects which are not fully initialized may cause duplicate entries in the hash table of canonical TypeArguments. This triggers assertions when hash table is rehashed. The solution is to avoid canonicalization of non-root recursive types and recursive type arguments. Also, TypeRef::Canonicalize and TypeRef::Hash are reverted to assert and work only if type was set. * Native wrapper classes are eagerly stamped as type-finalized which caused assertion failures when reading their class declarations from bytecode. * When building flow graph for FFI trampolines kernel offset of library (which is now declared in bytecode) was queried. Added special case to Function::KernelDataProgramOffset(). * In interpreter-only mode with simulator (e.g. SIMARM64) if simulator is not called before code is interrupted with stack overflow check, simulator returns get_sp() = 0, which was treated as stack overflow. * test standalone_2/io/platform_resolved_executable_test.dart spawns sub-process but it didn't pass VM options. Change-Id: I81bc4f1a4c6725cfa246a435ebe5d8abe43abc67 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/107199 Commit-Queue: Alexander Markov <alexmarkov@google.com> Reviewed-by: Ryan Macnak <rmacnak@google.com> Reviewed-by: RĂ©gis Crelier <regis@google.com>
Dart is:
Optimized for UI: Develop with a programming language specialized around the needs of user interface creation
Productive: Make changes iteratively: use hot reload to see the result instantly in your running app
Fast on all platforms: Compile to ARM & x64 machine code for mobile, desktop, and backend. Or compile to JavaScript for the web
Dart has flexible compiler technology lets you run Dart code in different ways, depending on your target platform and goals:
Dart Native: For programs targeting devices (mobile, desktop, server, and more), Dart Native includes both a Dart VM with JIT (just-in-time) compilation and an AOT (ahead-of-time) compiler for producing machine code.
Dart Web: For programs targeting the web, Dart Web includes both a development time compiler (dartdevc) and a production time compiler (dart2js).
Dart is free and open source.
Visit the dart.dev to learn more about the language, tools, getting started, and more.
Browse pub.dev for more packages and libraries contributed by the community and the Dart team.
If you want to build Dart yourself, here is a guide to getting the source, preparing your machine to build the SDK, and building.
There are more documents on our wiki.
The easiest way to contribute to Dart is to file issues.
You can also contribute patches, as described in Contributing.