Experiment with having the analyzer (`dart analyze`, `dart language-server`) be an AOT snapshot

[jensjoha]

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

[mit-mit]

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

[bwilkerson]

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]

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

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]

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]

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

[scheglov]

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]

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]

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

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]

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