-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Experiment with having the analyzer (dart analyze
, dart language-server
) be an AOT snapshot
#50498
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I'm keen for us to explore this; wdyt @jacob314 ? |
It would be useful for us to understand how essential this is. While I agree that it's sounds promising in terms of performance, it has implications for the design of plugin support, so we need to know what the priority of this is. |
@bwilkerson given that we don't actively invest in JIT performance running performance sensitive code on JIT is in some sense a liability. We already aligned on AOT internally (where tools like analyzer and dart2js are compiled to AOT binaries) and it would be nice to bring external SDK onto the same page. |
To be clear, I'm not arguing against running AOT, I'm just trying to pin down the requirements for the plugin support. To the the best of my understanding, requiring that we support plugins in an AOT mode places some additional restrictions on the design. Your feedback on what our options are (current and potential) would be most welcome. |
Yes, as far as I understand, from a conversation with @aam , if a Dart program is running as an AOT snapshot, then any isolate launched with It is then curious to know whether we can compile a Dart program to an AOT snapshot using |
Could this AOT snapshot potentially be built using a |
If we compile to AOT snapshot, and run it...
The result of And if we compile to the native executable, the result of So, almost. We probably can use it to get the SDK path, and then find |
If we look at If we look at Can you elaborate why you'd want to do it with |
The first question to ask is: do plugins actually have to live in the same process? Maybe they can just be separate process (JIT mode) communicating with the main analyzer process some way. We can start with something very simple (e.g. stdin/out or sockets). If we discover that the protocol is very chatty and is bottlenecked on transferring data we can optimise the communication channel (e.g. use shared memory, etc, learn a few things from sophisticated IPC libraries like mojo). Out of process design has a number of benefits - better stability and users can actually see the memory cost of individual plugins. If out of process does not work for some reason - then we could consider allowing hybrid JIT & AOT mode when VM can host both AOT compiled and JIT compiled isolates at the same time. This is not impossible - but requires some investments. |
Unfortunately, the analysis server currently uses large amounts of memory and processor time. The primary problem we have with the current plugin prototype isn't the protocol between the server and the plugins, it's that inability to share data between them, which causes each plugin to have to repeat all of the analysis work, which means using as much memory and processor time as the analysis server itself. I think the solution has to allow us to share memory, but it sounds like that's still possible with separate processes, so there's some hope there. |
I think they can live in a separate process. It hinges on whether we can accept double memory for plugins customers (1 process for DAS; 1 process for DAS+plugins). |
This change adds a build target (see utils/analysis_server/BUILD.gn) called 'analysis_server_aot'. This new target is _not_ included in the Dart SDK (the create_sdk target). It's "opt-in" "for development." The name of the new output file matches that of other snapshots (see the dartdevc snapshots). Then we do special work in the plugin manager if "we are AOT." An analysis server running as AOT cannot spawn Isolates from a dart source files; we must first compile a dart source file to AOT as well, then we can spawn an Isolate to that AOT file. _Then_ when we run pub, we can no longer rely on using `Platform.executable`. `dartaotruntime pub get` is not a thing. We must instead find the `dart` tool on disk. To do that, we copy some complex discovery code from dartdev. Work towards #53402 Work towards #53576 Work towards #50498 Manually tested: * [+] analysis_server JIT snapshot works in IDE. * [+] analysis_server JIT snapshot works in IDE, with a legacy plugin (custom_lint). * [+] analysis_server JIT snapshot works at commandline. * [+] analysis_server AOT snapshot works in IDE. * [x] analysis_server AOT snapshot works in IDE, with a legacy plugin (custom_lint) - BROKEN. Need similar work that is done for new plugins. * [x] analysis_server AOT snapshot works at commandline - BROKEN. I think a fair bit of refactoring is required in dartdev lib/src/analysis_server.dart to use `VmInteropHandler.run` or similar. Change-Id: I53173c716fa2a763331ef524a96304f62165810e Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/417942 Commit-Queue: Samuel Rawlins <[email protected]> Reviewed-by: Siva Annamalai <[email protected]>
…command The `dart analyze` command is quite separate from the `dart language-server` command. This CL adds support for `dart analyze`. Work towards #50498 Change-Id: I60a846ae5d3452c2bb050bd07502084ff44b82c0 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/425188 Commit-Queue: Samuel Rawlins <[email protected]> Reviewed-by: Siva Annamalai <[email protected]>
Work towards #50498 Change-Id: Ie09063325062e1b2c3b70d3a2a65df4c33c74095 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/425981 Commit-Queue: Samuel Rawlins <[email protected]> Reviewed-by: Siva Annamalai <[email protected]>
In #50487 (comment) we saw how the AOT snapshot on the analyzer was likely faster than the jit snapshot.
We should see if it's possible to have it as an aot snapshot (e.g. integration with
pkg/dartdev
for, for instance,dart language-server
to work)./cc @mraleph
The text was updated successfully, but these errors were encountered: