Among the myriad of promises offered by Dart is snapshotting of VM images. My understanding is that VM snapshots will not be like Squeak images—that is Dart snapshots will not contain state information. Rather they will hold compile-time snapshots of the classes employed. These snapshots can be cached so that the next time that the browser request the Dart application, compilation can be by-passed for even faster startup. At least that's my understanding. I could be wrong.
A while back, Anton Muhin was kind enough to give me some pointers for getting it working. My compile machine died, but it has since returned from the dead.
I update
src/third_party/WebKit/Source/WebCore/bindings/dart/DartApplicationLoader.cpp
to enable snapshotting:// ... static bool isSnapshottingEnabled() { return true; } // ...Look at me, I'm a C++ programmer! Well, not quite, but I can compile it:
➜ src ./dartium_tools/build.py --mode=Release Running: make -j8 BUILDTYPE=Release chrome DumpRenderTree test_shell dart CXX(target) out/Release/obj.target/webcore_remaining/third_party/WebKit/Source/WebCore/bindings/dart/DartApplicationLoader.o make: Nothing to be done for `dart'. AR(target) out/Release/obj.target/third_party/WebKit/Source/WebCore/WebCore.gyp/libwebcore_remaining.a TOUCH out/Release/obj.target/third_party/WebKit/Source/WebCore/WebCore.gyp/webcore.stamp LINK(target) out/Release/chrome LINK(target) out/Release/DumpRenderTree LINK(target) out/Release/test_shell LINK(target) out/Release/chrome: Finished LINK(target) out/Release/DumpRenderTree: Finished LINK(target) out/Release/test_shell: FinishedWhen I run this again my Dart Comics application, however, I am greeted by a sad browser:
And the following STDERR output from Dartium:
dart/runtime/vm/raw_object_snapshot.cc:1094: error: unimplemented codeAnd indeed, line 1094 of
raw_object_snapshot.cc
is undefined:void RawLanguageError::WriteTo(SnapshotWriter* writer, intptr_t object_id, Snapshot::Kind kind) { UNIMPLEMENTED(); }Hrm... But why is that a
RawLanguageError::WriteTo
? The "Error" portion of that function is not encouraging. Grepping through the code, it seems like this may be coming from snapshot.cc
in the same directory:... switch (kind) { #define SNAPSHOT_WRITE(clazz) \ case clazz::kInstanceKind: { \ Raw##clazz* raw_obj = reinterpret_castUgh. Macros. Why did it have to be CPP macros?(raw); \ raw_obj->WriteTo(this, object_id, kind_); \ return; \ } \ CLASS_LIST_NO_OBJECT(SNAPSHOT_WRITE) #undef SNAPSHOT_WRITE ...
Kidding aside, I did not know that you could pass a macro to another macro to be invoked. But that is what CLASS_LIST_NO_OBJECT does—invokes SNAPSHOT_WRITE for every class that it defines, including
LanguageError
:// runtime/vm/raw_object.h // ... // Macrobatics to define the Object hierarchy of VM implementation classes. #define CLASS_LIST_NO_OBJECT(V) \ V(Class) \ V(UnresolvedClass) \ V(AbstractType) \ V(Type) \ V(TypeParameter) \ V(AbstractTypeArguments) \ V(TypeArguments) \ V(InstantiatedTypeArguments) \ V(Function) \ ... V(Error) \ V(ApiError) \ V(LanguageError) \ V(UnhandledException) \ V(UnwindError) \ ...And still, that does not help. Why is this a
RawLanguageError
WriteTo?Unfortunately, I am out of ideas, so I resort to removing my Dartium profile:
rm -rf .config/chromiumWhich has no effect. I had not really expected it to since my Chromium profile ought to be next to empty.
UPDATE: I figured it out. Eventually, I noodled out that "LanguageError" might mean that I had a problem with my Dart code. So I enabled type checking and assertions by restarting my (Linux) Dartium as:
DART_FLAGS='--enable_type_checks --enable_asserts' dartiumIndeed there were some errors (mostly cruft from one too many bleeding edge experiments). After resolving those issues, I was able to access my Dart Comics application. I still need to experiment with the actual results of snapshotting, but I will leave that for another night.
Day #401
No comments:
Post a Comment