* Fixed service isolate not being initialized correctly due to bad name
The name for the service isolate was being set to the empty string,
causing the microtask loop to not be run on the service isolate leading
to the service hanging on the first 'await'. See
https://dart-review.googlesource.com/c/sdk/+/97107 for revert due to
this issue.
* Removed unnecessary params from DartCreateAndStartServiceIsolate
Link dart:* sources into engine for debugger source support
Currently, dart:* libraries appear to have no source in
debuggers like Observatory. With this change, these sources will be
available in debug mode applications. Sources for dart:* libraries are
lazily loaded on a script-by-script basis.
Refer to https://dart-review.googlesource.com/c/sdk/+/93375 for the Dart
SDK change.
The shell was already designed to cleanly shut down the VM but it couldnt
earlier as |Dart_Initialize| could never be called after a |Dart_Cleanup|. This
meant that shutting down an engine instance could not shut down the VM to save
memory because newly created engines in the process after that point couldn't
restart the VM. There can only be one VM running in a process at a time.
This patch separate the previous DartVM object into one that references a
running instance of the DartVM and a set of immutable dependencies that
components can reference even as the VM is shutting down.
Unit tests have been added to assert that non-overlapping engine launches use
difference VM instances.
This reverts commit 25559ed0779604d56c47c5d2341ffd16b137cd10.
Reason for revert: broken in AOT mode.
@pragma('vm:entry-point') placed on a function only instructs
the compiler to retain the function itself, but does not tell
compiler to generate and retain tear-off for this function.
In this PR _runMainZoned was marked as an entry-point but C++
code was trying to tear it off and use a closure, instead of
invoking it directly, which is not supported.
As of the migration to Dart 2, it has been necessary to compile Dart to
kernel prior to execution. The embedder currently requires that the
resulting kernel file be named `kernel_blob.bin` and be located at the
root of the assets directory passed to the embedder API.
This patch updates the test_fixtures build rule to perform a kernel
compile using frontend_server, outputting `kernel_blob.bin` to
`fixtures/test_target_name` directory, and updates the embedder
unittests to specify the kernel file rather than the Dart source file.
Since the kernel compiler requires a `main()` function to be defined, it
also updates `simple_main.dart` from runtime_unittests to define
`main()` rather than `simple_main()`.
This also updates all existing sub-targets to be testonly.
This relands commit ac9e521a1ddbb99816a93d92ce9fb70e950b3763, which was
reverted in commit 494112582932af98b282617d7a34b1fbb8c90307. Rather than
running as prebuilt_dart_action, we use dart_action to ensure the
frontend snapshot it compatible with the VM on which it's executed.
This reverts commit ac9e521a1ddbb99816a93d92ce9fb70e950b3763.
This broke dynamic release mode builds of
//flutter/runtime:runtime_fixtures_kernel (likely all product-mode
builds).
Compile embedder unit test Dart to kernel
As of the migration to Dart 2, it has been necessary to compile Dart to
kernel prior to execution. The embedder currently requires that the
resulting kernel file be named `kernel_blob.bin` and be located at the
root of the assets directory passed to the embedder API.
This patch updates the test_fixtures build rule to perform a kernel
compile using frontend_server, outputting `kernel_blob.bin` to
`fixtures/test_target_name` directory, and updates the embedder
unittests to specify the kernel file rather than the Dart source file.
Since the kernel compiler requires a `main()` function to be defined, it
also updates `simple_main.dart` from runtime_unittests to define
`main()` rather than `simple_main()`.
This also updates all existing sub-targets to be testonly.
In Dart 2, runtime checked mode has been eliminated. Many of these type
checks have been moved to static compile-time checks, the remainder are
enforced at runtime, and are no longer optional.
* Revert "Revert "Guard the service protocol's global handlers list with a reader/writer lock (#6888) #6895" (#6899)"
This reverts commit b6e93759faa92a96650e326b0e82578a6803c46d and applies fix for tests on Windows.
* Reland guard the service protocol's global handlers list with a reader/writer lock.
* Remove blank line
The service protocol holds the lock while waiting for completion of service
RPC tasks. These tasks (specifically hot restart/RunInView) may need to
modify a handler's description data.
Task execution and ServiceProtocol::SetHandlerDescription will obtain a shared
lock to make this possible. AddHandler and RemoveHandler will obtain an
exclusive lock in order to guard against a handler being deleted while a
service task is running.
The service protocol holds the lock while waiting for completion of service
RPC tasks. These tasks (specifically hot restart/RunInView) may need to
modify a handler's description data.
Task execution and ServiceProtocol::SetHandlerDescription will obtain a shared
lock to make this possible. AddHandler and RemoveHandler will obtain an
exclusive lock in order to guard against a handler being deleted while a
service task is running.
The service protocol's ListViews method needs to return description data for
each engine in the process. Previously ListViews would queue a task to each
UI thread to gather this data. However, the UI thread might be blocked from
executing tasks (e.g. if the Dart isolate is paused), resulting in a deadlock.
This change provides a copy of the engine's description data to the
ServiceProtocol's global list of engines, allowing ListViews to run without
accessing any UI threads.
Fixes https://github.com/flutter/flutter/issues/24400
* Set up secondary isolates with all kernel buffers rather than just one buffer.
* Capture copy of the list
* Make sure child_isolate_preparer_ is initialized only once
TL;DR: Offscreen surface is created on the render thread and device to host
transfer performed there before task completion on the UI thread.
While attempting to snapshot layer trees, the engine was attempting to use the
IO thread context. The reasoning was that this would be safe to do because any
textures uploaded to the GPU as a result of async texture upload would have
originated from this context and hence the handles would be valid in either
context. As it turns out, while the handles are valid, Skia does not support
this use-case because cross-context images transfer ownership of the image from
one context to another. So, when we made the hop from the UI thread to the IO
thread (for snapshotting), if either the UI or GPU threads released the last
reference to the texture backed image, the image would be invalid. This led to
such images being absent from the layer tree snapshot.
Simply referencing the images as they are being used on the IO thread is not
sufficient because accessing images on one context after their ownership has
already been transferred to another is not safe behavior (from Skia's
perspective, the handles are still valid in the sharegroup).
To work around these issues, it was decided that an offscreen render target
would be created on the render thread. The color attachment of this render
target could then be transferred as a cross context image to the IO thread for
the device to host tranfer.
Again, this is currently not quite possible because the only way to create
cross context images is from encoded data. Till Skia exposes the functionality
to create cross-context images from textures in one context, we do a device to
host transfer on the GPU thread. The side effect of this is that this is now
part of the frame workload (image compression, which dominate the wall time,
is still done of the IO thread).
A minor side effect of this patch is that the GPU latch needs to be waited on
before the UI thread tasks can be completed before shell initialization.
