c01f9fb8a9
Our TLAB sizes and maximum new space size constrain the number of parallel mutator threads we can have. Having too many mutator threads would cause constant races between threads to acquire TLABs. In reality we should constrain the number of threads to be at most the number of cores, since at most that many threads can run in parallel (i.e. at the same time). This CL extends the TreadPool implementation to be constrained by a maximum size. Furthermore it makes each isolate group's have it's own pool with constrained size and schedule all group member mutator / message handler tasks on that pool. Issue https://github.com/dart-lang/sdk/issues/36097 Change-Id: I095c749adad827ab892f33713a32be594d7606d1 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/145382 Commit-Queue: Martin Kustermann <kustermann@google.com> Reviewed-by: Alexander Aprelev <aam@google.com> Reviewed-by: Ryan Macnak <rmacnak@google.com>
Dart VM Compilation Pipeline
This folder contains Dart VM compilation pipeline.
Compilation pipeline is mainly responsible for converting AST or Kernel AST into IL flow graphs and then generating native code from IL.
It has the following structure:
| Directory | What goes there |
|---|---|
assembler/ |
Assemblers and disassemblers |
backend/ |
IL based compilation backend: optimization passes and architecture specific code generation rules |
frontend/ |
Frontends responsible for converting AST into IL |
jit/ |
JIT specific passes and compilation pipeline entry points |
aot/ |
AOT specific passes and compilation pipeline entry points |
. |
Shared code or code without clear designation. |
Currently there are no layering restrictions and components from different subfolders can reference each other.