--unsafe-package-serialization saves the frontend_server from having to
re-serialize everything all the time.
Before this CL, though, things could go wrong:
If you had a situation where you had previously compiled a file that
depend on a package A, and where (some of) package A depends on
package B this would happen:
- All of package A was serialized together.
- All of package B was serialized together.
When later, you compile something that depend less on package A - namely
on only on parts that does not depend on package B, but is included in
the previously serialized package A, the following would happen:
- The new (non-package) libraries would be serialized.
- Package A serialization would be reused.
This is basically fine: Running the app would be fine, everything it
actually depend on is there.
However, if the VM is forced to compile everything it now also compiles
stuff that was included - but really unused - from package A - namely
also the libraries that depend on package B --- which is not included.
This CL changes the last part by also including package B.
The result is that even more unused libraries are included, but that
the VM can survive a forceful compile.
Note that the --unsafe-package-serialization is only used for tests,
so the "including even more unused" part is probably not a big deal,
and all in all there's still a big speed advantage to doing this.
Change-Id: Iac06ba6f40c2caaacce641c5853e9491496dce53
Reviewed-on: https://dart-review.googlesource.com/c/78541
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Also, convert package:vm to use onDiagnostic.
We're consolidating all dependencies on package:front_end in one file per tool.
The idea is, if you want to depend on something in the package:front_end, you modify pkg/front_end/lib/src/api_unstable/vm.dart and consult with the front-end team.
These consolidated files will help us when designing a public API in the future.
Change-Id: I66bafdd0ae29605fd12f8d6c589dbc761e5c7a97
Reviewed-on: https://dart-review.googlesource.com/c/77581
Auto-Submit: Peter von der Ahé <ahe@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Peter von der Ahé <ahe@google.com>
This CL introduces an option - unsafe-package-serialization - where a
caller can select to reuse the serialization of packages. This makes it
unsafe in general, but if never invalidating packages, such as in tests,
it can be used to greatly increase the speed of processing many inputs.
This change - used in flutter - takes the time it takes to run
`flutter test` in `packages/flutter` from ~2 minutes 30 seconds to
~1 minute 15 seconds (on my machine).
A change to how flutter test executes the frontend_server
(to pass the option) is needed for it to take effect though.
Change-Id: Ibe47b43c41286eb08f80c9e7a398e1dc67bf9bc0
Reviewed-on: https://dart-review.googlesource.com/48200
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
frontend_server uses getTarget - which means we need to call
installAdditionalTargets to ensure that flutter & vm targets are
properly installed.
Change-Id: I00a3d06f76c3bd31fe4e27e3947abea4c7883c44
Reviewed-on: https://dart-review.googlesource.com/69464
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
With explicit exit() invocation, frontend_server_test only gets through first two tests before exiting.
Change-Id: Ica0b6f4f09baa8262b6097779be772877ca6f8d8
Reviewed-on: https://dart-review.googlesource.com/69220
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Do not start the kernel isolate from an app-jit snapshot when
creating app-jit snapshots as this causes build issues.
Change-Id: Id9e48526ab85cfc90aed030e492c432ebb32caef
Reviewed-on: https://dart-review.googlesource.com/65792
Reviewed-by: Siva Annamalai <asiva@google.com>
When invalidating changed files in frontend server, the state prior to
this CL was that a continue would jump to the next byte, not the next file
after it had seen that the file had changed. Thus it could possibly
invalidate the same file several times.
Change-Id: If6fb1042248d26a3ffe905b39fa3c3603198ca37
Reviewed-on: https://dart-review.googlesource.com/60245
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
The `@pragma` annotation on `vmservice_io.main` is modified to only mark it as a
root on non-product builds. Since the annotation is evaluated in the constant
transformation, we need to thread a flag through `gen_kernel.dart` indicating
whether the Kernel produced should target a product precompiler.
# Test Plan
Tested locally on Flutter. Unfortunately it's not possible to test the scenario where
`vmservice_io` is not included, since we don't have any "product" bots. Soon the
flag will be introduced into Flutter, and we will have some coverage from there.
Change-Id: I39f12343038fa221aafe5a55241bff4b8d14ec19
Reviewed-on: https://dart-review.googlesource.com/57501
Commit-Queue: Samir Jindel <sjindel@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
This CL updates the frontend_server to allow specifying what dill
file to initialize from.
Normally, it tries to initialize from the same dill file as is the
output. This is fine in many cases (e.g. flutter run always says it
should output to build/app.dill): The first time it compiles
everything, subsequent times (across restarts) it only recompiles
what's needed.
When running tests, however, the output is in a temporary directory,
so it doesn't work across restarts. The startup time for tests is
always rather high, because it always has to recompile everything.
This CL updates the frontend_server to allow specifying what dill
file to initialize from. Flutter can thus save the compiled test
file in a centralized location (e.g. build/test.dill) and load from
that across restarts.
Plumbing this into flutter yields the following result, when running
a single test (the one automatically created when creating a new
flutter project):
Before: ~5.5 seconds
Now, first run: ~5.5 second (unchanged)
Now, subsequent runs: ~3.4 seconds
Approximate breakdown:
Startup cost (e.g. if there's no test directory): ~ 800 ms
Starting up the actual frontend server: ~150 ms
Reading source from old dill, loading all relevant files
and invalidating source: ~ 300 ms
Compiling everything (or, rather, nothing as it's all
from the dill at this point): ~ 650 ms
Serializing: ~ 250 ms
Copying files: ~ 50 ms
Running the actual test: ~1100 ms
Total: ~3300 ms
`time flutter test --local-engine=host_debug --preview-dart-2`
says ~3.4 seconds...
To compare, --no-preview-dart-2 takes ~2.2 seconds,
so dart2 still has a (significantly) higher startup cost.
Moves the needle on https://github.com/flutter/flutter/issues/15767.
Change-Id: I36a2d05bc76e0193d369df42eb3b9f08416dd78f
Reviewed-on: https://dart-review.googlesource.com/51820
Reviewed-by: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Second try. First try was reverted because a previously empty URL (the
default 'always there' one) is now a null url instead, which wasn't
handled properly in the frontend_server.
See 47e9039512 for original details.
This reverts commit 4c9b712052.
Change-Id: I717eb927cbe29b6388e72f7e270428d234d44e4d
Reviewed-on: https://dart-review.googlesource.com/53580
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
This change adds experimental option '--import-dill' to front-end server
to specify existing kernel file to import when compiling a new one.
Newly generated kernel file will depend on the imported one and will
omit libraries available in the imported dill file, as well as platform
libraries.
Caveat: the new option is not compatible with '--incremental'.
Change-Id: Id637908afdb12f1829e5f634251fa9ad82676baf
Reviewed-on: https://dart-review.googlesource.com/54309
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
This allows frontend-server users(flutter) to do quick check whether frontend compilation reported errors as it produced output kernel file.
Change-Id: I6e4da8fac33104968eb7720200a1b7153ec8f3de
Reviewed-on: https://dart-review.googlesource.com/51000
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
This is the second attempt at this change.
The original try was committed as f9c7a4a22d.
The revert of that was committed as 2f68e82526.
This CL allows users of the incremental compiler to ask for a computeDelta
call to include the full Component in the output,
basically turning the incremental compiler into a batch compiler.
This CL furthermore changes the frontend_server (in pkg/vm) to use this
functionality.
This change - used in flutter - takes the time it takes to run
`flutter test` in `packages/flutter` from ~8 minutes 30 seconds to
~2 minutes 30 seconds (on my machine).
Fixes#32663.
Change-Id: I073e77b3596b33a24cabcfbcedf97bb0be7aa450
Reviewed-on: https://dart-review.googlesource.com/49125
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
This reverts commit f9c7a4a22d.
Reason for revert: This CL breaks the restart functionality in Flutter, when we restart we end up with an empty app.dill file (60 bytes).
Original change's description:
> Allow to output full component via computeDelta
>
> This CL allows users of the incremental compiler to ask for a computeDelta
> call to include the full Component in the output,
> basically turning the incremental compiler into a batch compiler.
>
> This CL furthermore changes the frontend_server (in pkg/vm) to use this
> functionality.
>
> This change - used in flutter - takes the time it takes to run
> `flutter test` in `packages/flutter` from ~8 minutes 30 seconds to
> ~2 minutes 30 seconds (on my machine).
>
> Change-Id: Ia185d28da1f97b0be5dad8814cd01a8f13482724
> Reviewed-on: https://dart-review.googlesource.com/47020
> Commit-Queue: Jens Johansen <jensj@google.com>
> Reviewed-by: Peter von der Ahé <ahe@google.com>
> Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
TBR=ahe@google.com,vegorov@google.com,jensj@google.com
Change-Id: I5ff39f9d78319413f4bbb7800e24bf27ab4ada9c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/48240
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
This CL allows users of the incremental compiler to ask for a computeDelta
call to include the full Component in the output,
basically turning the incremental compiler into a batch compiler.
This CL furthermore changes the frontend_server (in pkg/vm) to use this
functionality.
This change - used in flutter - takes the time it takes to run
`flutter test` in `packages/flutter` from ~8 minutes 30 seconds to
~2 minutes 30 seconds (on my machine).
Change-Id: Ia185d28da1f97b0be5dad8814cd01a8f13482724
Reviewed-on: https://dart-review.googlesource.com/47020
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Incremental reload request can switch to new main source. Until this CL, it caused reset of current incremental kernel file name back to full kernel file name, which resulted in full kernel file having incremental kernel contents.
BUG=dartbug.com/32384
Change-Id: Ie5037f7d6316fa262065f9ca6485879d7ee15b28
Reviewed-on: https://dart-review.googlesource.com/44901
Commit-Queue: Siva Annamalai <asiva@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Peter von der Ahé