Lazy async stacks were already enabled by-default in AOT mode in [0] - which made the
gen_snapshot invocations use "--lazy-async-stacks --no-causal-async-stacks".
This change does the same with the engine defaults, which makes this be enabled
by-default in JIT mode as well.
See go/dart-10x-faster-async for more information.
This is a re-land: A fix for what we believe to have caused the last revert has landed upstream in Dart in dart-lang/sdk@0004589
[0] flutter/flutter@3478232
Reland #19396 with a fix for improper scale that was affecting internal tests
Tested: Ran all unittests, ran internal tests, and ran workstation on Fuchsia
BUG: 53062, 53063
The fuchsia code around metrics and sizing was just sending this
information through a side-channel, when the engine already had the
information available. So, delete all of it to make future CLs simpler.
Additionally, the SceneUpdateContext has many unneccesary dependencies
re: metrics and PaintTasks. Break those to make future CLs simpler.
Tested: Ran all unittests and ran workstation on Fuchsia
BUG: 53062, 53063
This allows Fuchsia components executed by the Flutter runner to
specify a directory containing assets if they wish to store assets
separate from program data. This is specified in the program metadata
field within the component's specification with the new "assets"
attribute. If this attribute is absent, assets are loaded relative to
the path specified in the "data" attribute as before.
This is useful in the short term to use a location in the package where
we can store small files more efficiently. It is also potentially
useful longer term to enforce a stronger separatation between
executable program data and non-executable assets.
This commit adds some basic unit testing for the data parsing to the
flutter_runner_tests suite.
In order to better support different products on Fuchsia, we should
change performance-sensitive attributes based on config files passed in.
This change does so for `vsync_offset`.
On Fuchsia, we can now get executable VMOs from trusted backing
filesystems. This allows us to remove the use of replace_as_executable
in favor of opening files with `fdio_open_fd_at` with the
`OPEN_RIGHT_EXECUTABLE` flag and getting VMOs by calling
`fdio_get_vmo_exec`.
By moving the responsibility for executability into the filesystem, we
are able to remove `deprecated-ambient-replace-as-executable` from
component manifests for non-JIT runners (the JIT runners still call
replace_as_executable in Dart's allocator). It wasn't abundantly clear
whether .cmx files for tests were used purely in AOT runtime
environments or also saw JIT usage, so I left those as-is.
For context: this is a second attempt at #16690, which was reverted
because it broke the Dart JIT runner. The primary difference is that
this time around, we correctly handle absolute vs relative paths,
depending on whether library loading bottoms out in `fdio_open_fd` or
`fdio_open_fd_at`. I've added additional assertions to help ensure any
new usages use the correct shape of path.
Testing: I verified locally that the flutter product runner works on
Astro, and also successfully ran the Dart JIT example test (which was
the thing blocking the google3 roll with the previous attempt at this
patchset).
Co-authored-by: Drew Fisher <zarvox@google.com>
On Fuchsia, we can now get executable VMOs from trusted backing
filesystems. This allows us to remove the use of replace_as_executable
in favor of opening files with `fdio_open_fd_at` with the
`OPEN_RIGHT_EXECUTABLE` flag and getting VMOs by calling
`fdio_get_vmo_exec`.
By moving the responsibility for executability into the filesystem, we
should be able to remove deprecated-ambient-replace-as-executable from
component manifests for non-JIT runners (the JIT runners still call
replace_as_executable in Dart's allocator).
Test: verified locally that this works on Astro on a _user build with
the runtime allowlist tightened.
This was already enabled by-default in AOT mode in [0] - which made the
gen_snapshot invocations use "--lazy-async-stacks --no-causal-async-stacks".
See go/dart-10x-faster-async for more information.
[0] https://github.com/flutter/flutter/commit/347823234fd
The bug in the original CL was that we were not running replace_as_executable in OpenVmo if the namespace was not provided.
This was a divergence in behavior for MappedResource::LoadFromNamespace compared to the current implementation.
This reverts commit 4312d37eb1cdd0ed2e7b44647c7156499b741ac7.
Once https://fuchsia-review.googlesource.com/c/topaz/+/351729 lands, the
diagnostics directory will be present, this would be safe to do and the
roller won't be blocked again.
Since Flutter tracing is wired up to Fuchsia system level tracing (and
that includes Skia tracing within Flutter), it makes more sense to
enable Skia tracing by default on Fuchsia, and to control Flutter Skia
tracing, rely on whether Fuchsia system tracing is enabled, in progress,
and contains the "skia" category.
* [flutter_runner] Make rd and rx uniform
Currently we pass paths for readonly files and pass
in fds for rx. Now passing in fds everywhere.
* pass full paths
- Don't use 'unhandled' as that implies fatality which this is not
- Don't mention shutdown because this is not necessarily an exception-after-shutdown issue
Follow-up issue filed https://github.com/flutter/flutter/issues/41506 to implement the unit test for this.
Explicitly set |Application|'s |flutter::Settings| |trace_skia| field to
false (it currently defaults to false), in order to slightly simplify
the enabling skia trace events workflow.
PT-145 #comment-patch
Change-Id: Ib40f9ed3dc6f824056465db2cd45309c78b7e3b4
Build rules still reference creating share snapshot data and instructions. This makes the engine to always pass them as empty to the dart vm. To be followed up with a change to alter the build rules to stop referencing the shared snapshots.
This is not being used currently and the fact that the runner will be built outside of the flutter tree means that the apps will not have much to gain via shared snapshots. The rationale behind this change is to partially make migrating the runner out of topaz tree easier.
Change-Id: Ibc4dd6a298d65082416af753522f5a17c88a750a
* [fidl][flutter_runner] Port Migrate to new fit::optional compatible APIs
Updated all call-sites.
See: https://fuchsia-review.googlesource.com/c/fuchsia/+/304389
FIDL-564 #comment
Change-Id: I831712ffd4a47b8fc9cf1fe237b709a1b983109f
* fix observatory port and re-sync cmx files
This re-enables unhandled Dart error handling in Flutter applications,
which was removed in a76b958.
The error handling as originally landed was unsafe. Specifically, in the
case where the unhandled error handler was triggered during shutdown,
there was a race condition which could cause a crash in the following
scenario:
1. Runner::OnApplicationTerminate() is triggered, which posts a task to
the application's platform thread will free the Application instance
and terminate the platform thread.
2. Before that task is serviced, the unhandled error handler is called
(by hooks.dart -> window.cc -> ui_dart_state.cc) on the UI thread.
3. The kill task is serviced and the Application dtor and Thread::Quit()
are called, terminating the platform thread.
4. The unhandled error handler attempts to post a task to the platform
thread, whose thread was killed in step 3. This triggers a crash.
Fixing this requires a mechanism for the message loop to know that the
associated thread has been terminated out from under it.
This patch adds mitigation for this scenario, but remains
non-threadsafe/racy. We pass the unhandled error handler a weak pointer
to the Application and check it before posting a task to the platform
thread. This has two issues:
1. WeakPtr isn't threadsafe, and assumes that all operations occur on a
single thread. We're checking its value (which is mutated on the
platform thread) on the UI thread without synchronization.
2. Even with a guarantee that the WeakPtr state were synchronized,
there's a window between when we check the weak pointer and when we
post to the platform thread in which application shutdown and thread
destruction may occur.
This unsafe mitigation is being landed in order to unblock a high
priority bug (FL-256) on a short schedule, and a proper refactoring will
be required to make this properly threadsafe.
Change-Id: If60d1d3ca5799d82597f8a3acc4ddd3871058972
Ported from Topaz tree.
This is the topaz counterpart to
https://fuchsia-review.googlesource.com/c/fuchsia/+/277254.
This is a backwards-incompatible ABI change that will be landed together
with that CL. All clients have been migrated to be compatible with the
new ABI.
Change-Id: I07bb460ce3c6971eb671874db1f90e8c4906e656
Ported from Topaz tree.
