Skip to content

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

Open
jensjoha opened this issue Nov 17, 2022 · 12 comments
Assignees
Labels
area-devexp For issues related to the analysis server, IDE support, linter, `dart fix`, and diagnostic messages. devexp-server Issues related to some aspect of the analysis server P2 A bug or feature request we're likely to work on type-enhancement A request for a change that isn't a bug

Comments

@jensjoha
Copy link
Contributor

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

@devoncarew devoncarew added the legacy-area-analyzer Use area-devexp instead. label Nov 17, 2022
@pq pq added the P2 A bug or feature request we're likely to work on label Nov 17, 2022
@mit-mit
Copy link
Member

mit-mit commented May 17, 2023

I'm keen for us to explore this; wdyt @jacob314 ?

@bwilkerson
Copy link
Member

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.

@mraleph
Copy link
Member

mraleph commented May 22, 2023

@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.

@bwilkerson
Copy link
Member

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.

@jacob314 @srawlins @scheglov

@srawlins
Copy link
Member

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 Isolate.spawnUri must point to an AOT snapshot, and that AOT snapshot must be compiled with the exact same version of Dart as the running process.

It is then curious to know whether we can compile a Dart program to an AOT snapshot using Platform.resolvedExecutable... (though this would not work if compiled as a standalone executable).

@mit-mit
Copy link
Member

mit-mit commented May 22, 2023

Could this AOT snapshot potentially be built using a build.dart file, @dcharkes ?

@scheglov
Copy link
Contributor

If we compile to AOT snapshot, and run it...

$ dart compile aot-snapshot /Users/scheglov/dart/test/bin/test.dart
$ dartaotruntime /Users/scheglov/dart/test/bin/test.aot

The result of Platform.resolvedExecutable is /Users/scheglov/Applications/dart-sdk/bin/dartaotruntime.

And if we compile to the native executable, the result of Platform.resolvedExecutable is this native executable test.exe.

So, almost. We probably can use it to get the SDK path, and then find dart there.

@dcharkes
Copy link
Contributor

dcharkes commented May 22, 2023

Could this AOT snapshot potentially be built using a build.dart file, @dcharkes ?

If we look at package:analyzer as a completely standalone package, yes. We would invoke dart compile ... instead of C compiler or a download in the build.dart of package:analyzer. Which would ensure we have that AOT snapshot somewhere. But I don't see the point of doing that over just caching on the first invocation, since we would not be using any of the dylib bundling logic, nor do we use @Native for automatic asset finding in Dart code.

If we look at dart analyze as part of the SDK, we would need to do more work. We don't support building native assets for packages that are part of the SDK itself yet.

Can you elaborate why you'd want to do it with build.dart over just the normal SDK build script @mit-mit ?

@mraleph
Copy link
Member

mraleph commented May 22, 2023

@srawlins @bwilkerson

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.

@bwilkerson
Copy link
Member

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.

@srawlins
Copy link
Member

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).

@srawlins srawlins added the type-enhancement A request for a change that isn't a bug label Mar 15, 2024
@srawlins srawlins added the devexp-server Issues related to some aspect of the analysis server label Dec 13, 2024
@bwilkerson bwilkerson added area-devexp For issues related to the analysis server, IDE support, linter, `dart fix`, and diagnostic messages. and removed legacy-area-analyzer Use area-devexp instead. labels Feb 21, 2025
copybara-service bot pushed a commit that referenced this issue Apr 23, 2025
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]>
@srawlins
Copy link
Member

srawlins commented May 2, 2025

@srawlins srawlins self-assigned this May 2, 2025
copybara-service bot pushed a commit that referenced this issue May 2, 2025
…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]>
copybara-service bot pushed a commit that referenced this issue May 5, 2025
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]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-devexp For issues related to the analysis server, IDE support, linter, `dart fix`, and diagnostic messages. devexp-server Issues related to some aspect of the analysis server P2 A bug or feature request we're likely to work on type-enhancement A request for a change that isn't a bug
Projects
None yet
Development

No branches or pull requests

9 participants