dart2js previously syntactically matched on `Iterable<T>` and
`Stream<T>` exactly and did not compute the union-free type. The new
computation is a direct translation of the specified semantics.
Change-Id: Iaf916c6ba65e626181663ca554c38c90cdd88899
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/341337
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Mayank Patke <fishythefish@google.com>
This will allow users who are implementing their own deferred loading mechanism
to batch all the loads for a specific library. Today in order to do batching users have to gather the URIs passed to the `dartDeferedLibraryLoader` hook in a list and schedule (e.g. via setTimeout) a load for some future task.
The need to schedule a task has been shown to cause delays in IPL. But loading each part file individually can also be very expensive. So this allows for a compromise where bundling can be done synchronously per loaded library.
Adds ~8kB to unminified main files and ~2.5kB to minified main files.
Bug: https://github.com/dart-lang/sdk/issues/54202
Change-Id: I623643b03920988cda8b0f8b297944be35ffa606
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/340480
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
The current tracer does a separate visit of the entire JS AST using metadata from the JS printer in order to generate source maps. This new strategy uses a shadow tree tracking position info to generate source map metadata while the JS AST is bring printed. This saves us an entire tree walk and the memory overhead of storing metadata to pass to the separate source map tracer.
In local invocations of Dart2JS I see a memory improvement of >100MB in the emitter phase and a small time improvement of ~4%.
Change-Id: I622e7015e2eddc7835551f970386e13019394a79
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/336760
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
- Removes @staticInterop JS types declarations in favor of
typedefs (the function types' reified types and the typed data's
reified types have changed to make the type hierarchy work in the
JS backends).
- Adds extension types to dart:js_interop
- Adds a fromInteropObject helper to JSObject to avoid casting to
an extension type
- Deletes now stale tests
- Refactors some dart2wasm @staticInterop declarations since they
can no longer implement JS types
- Updates extension types tests to use the prefix extension_type
instead of inline_class
- Updates comments
CoreLibraryReviewExempt: Backend-specific library.
Change-Id: Ibe04afac9585ddb99fcf6dbaa7f12050d8b876dc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332860
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Recognize larger regions of no-op control flow. Ideally we would be able to remove these regions from the CFG. Until then, pattern matching larger regions leaves fewer ghost conditions in the generated code.
With pattern matching, we are seeing more examples where this is necessary.
Bug: #29475
Change-Id: Ib0981400883631f56940288f8a32fbc5f3985dfb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/340067
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
Before:
```
dart compile js --wrong-flag
Compile Dart to JavaScript.
Usage: dart compile js [arguments] <dart entry point>
-h, --help Print this usage information.
-h -v Show detailed information about all options.
-o, --output Write the output to <file name>.
-O<0,1,2,3,4> Set the compiler optimization level (defaults to -O1).
-O0 No optimizations (only meant for debugging the compiler).
-O1 Default (includes whole program analyses and inlining).
-O2 Safe production-oriented optimizations (like minification).
-O3 Potentially unsafe optimizations (see -h -v for details).
-O4 More agressive unsafe optimizations (see -h -v for details).
<-- TWO SPACES HERE and a newline
Error: Unknown option '--wrong-flag'.
```
After this change:
```
dart compile js --wrong-flag
Compile Dart to JavaScript.
Usage: dart compile js [arguments] <dart entry point>
-h, --help Print this usage information.
-h -v Show detailed information about all options.
-o, --output Write the output to <file name>.
-O<0,1,2,3,4> Set the compiler optimization level (defaults to -O1).
-O0 No optimizations (only meant for debugging the compiler).
-O1 Default (includes whole program analyses and inlining).
-O2 Safe production-oriented optimizations (like minification).
-O3 Potentially unsafe optimizations (see -h -v for details).
-O4 More agressive unsafe optimizations (see -h -v for details).
Error: Unknown option '--wrong-flag'.
```
R=sra@google.com
Change-Id: Ie0541d830b53e3e81b4b02a20988cbd41db64325
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/339300
Auto-Submit: Morgan :) <davidmorgan@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Morgan :) <davidmorgan@google.com>
This impact was added so the compiler would correctly consider
JavaScriptFunction live when allowInterop was used. At some
point, this behavior regressed but the effect of this was hidden
by the existence of dart:js_interop JS types. Because the JS
types were implemented using package:js classes, the compiler
assumed JavaScriptFunction was always live. As we are migrating
them to extension types, this bug resurfaced.
There are two key details in this CL:
- The allowInterop impact needs to register that JavaScriptFunction
is instantiated. needToInitializeIsolateAffinityTag is not enough.
- Both resolution and codegen need to add the impact. Before this
CL, we checked for use of allowInterop during SSA and registered
that it was being used, and we only processed the impact if it was
being used. However, this check of the registration only occurred
during resolution. Since resolution occurs before codegen, we never
actually processed the impact.
It isn't clear why both details are needed for
tests/web/regress/issue/37576_test to pass.
Change-Id: Ieff8ac5c4d040cc034f58ecb09a4246d2d8f87b7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/336626
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
With the exception of the one noted case, this change just adds an `OrNull` method variant for any write that was using `allowNull` and changes the call site to use the new `OrNull` method.
There are a few cases where we weren't using the `allowNull` parameter at all. In those cases I've removed the parameter without adding an `OrNull` variant.
Change-Id: Ie5eae4d7f2fb7ccaf9594b9c533afdd93bd99198
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/338280
Reviewed-by: Mayank Patke <fishythefish@google.com>
- Remove asserts that were checking for nulls during migration (via dynamic cast).
- Change map key containment asserts from `map[key] == null` to `!map.containsKey(key)` when the map isn't nullable. The null check makes it unclear if the map allows null without looking at the declaration.
- Update 2 constructors to use `super.`. Suggested by analyzer when I removed constructor bodies.
Change-Id: Idd8969dc84f889adeaaf4024ad6129babc76eb10
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/338240
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
In the emitter phase source informations are attached to nodes but we have made several changes to ensure the majority of nodes are GCed immediately after being printed. This deserializer cache is holding references to the associated source informations so those objects are not being GCed as well.
Locally see a >400MB memory improvement as a result.
Change-Id: I2fb849c7b0a063579f068bea7d22e7533d61ec05
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/337881
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
Some indexed objects might benefit from being deduped in the serialized contents (i.e. to reduce serialized data size) but might be short lived otherwise and therefore don't benefit from being cached by the deserializer.
This adds the option to read from the same index but deserialize a fresh object each time.
Change-Id: I405745fb7be28fa4c5b15640f90d83522f268a27
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/337901
Reviewed-by: Mayank Patke <fishythefish@google.com>
This is a reland of commit b9e25afcb4
Original change's description:
> [dart2js] Stop emitting a dill with closed world.
>
> All transformations to the dill are now performed with the CFE linker phase (phase0b). This means we no longer need to emit a dill as part of the closed world computation. This saves both time and memory resources associated with the cost of serialization during that phase.
>
> Change-Id: I28dde8a1eecd71e823880027505f62fc804fcca6
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332821
> Reviewed-by: Sigmund Cherem <sigmund@google.com>
> Reviewed-by: Mayank Patke <fishythefish@google.com>
> Commit-Queue: Nate Biggs <natebiggs@google.com>
Change-Id: Ia693213dcdc949a8ef4b4204cc033130274d2381
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/336982
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
Simplify the js_ast printer - it should not transform the program
while printing.
js_ast:
- Don't skip blocks containing a single statement.
- Don't rewrite arrow functions.
dart2js:
- Fix rewrite_async.dart to avoid a few singleton blocks.
- Static initializer thunks are transformed in arrow functions with expression bodies.
Change-Id: I4ab75c6ca7f580835a6c9d4eb45240d76df9d895
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/336820
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
This is a reland of commit bebd08746b
Original change's description:
> [dart2js] Evaluate CFE consts as part of phase 0b (CFE linker).
>
> Constants are current evaluated in a few places during closed world generation, primarily as part of the ScopeModelBuilder. The scope visitor was modifying the AST which meant we had to emit a new dill with these evaluated constants along with the closed world results.
>
> This change instead evaluates the constants directly after linking the Kernel as part of the global transformations. This means we can update the ScopeModelBuilder to not mutate the AST at all as all constants are already simplified.
>
> A potential follow up here is to simplify the ScopeModelBuilder since all nodes should already be simplified if they can be, we should be able to avoid visiting some children.
>
> After this change we only directly create a single ConstantEvaluator, the one in `load_kernel`. The const simplifier also creates one and a follow up CL moves this to to run right after this new transformation.
>
> Note: Alternate versions of this CL tried to make the global transformation simpler by either:
> 1) Running the const evaluator indiscriminately on all expressions. This didn't work because it lead to exponential computation on constants set up as a DAG (see tests/language/const/constant_dag_test).
> 2) Only evaluating ConstantExpression nodes to update UnevaluatedConstants. This does not cover all the cases where the ScopeModelBuilder is modifying the tree and lead to a different compiler output.
>
> Change-Id: I746d889b37feddc9ab6c386c6252016dec745e6e
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332601
> Reviewed-by: Mayank Patke <fishythefish@google.com>
Change-Id: I53871a57144a3a1bd363af141d8f31c8ffa5ca6d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/336221
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
All transformations to the dill are now performed with the CFE linker phase (phase0b). This means we no longer need to emit a dill as part of the closed world computation. This saves both time and memory resources associated with the cost of serialization during that phase.
Change-Id: I28dde8a1eecd71e823880027505f62fc804fcca6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332821
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
Constants are current evaluated in a few places during closed world generation, primarily as part of the ScopeModelBuilder. The scope visitor was modifying the AST which meant we had to emit a new dill with these evaluated constants along with the closed world results.
This change instead evaluates the constants directly after linking the Kernel as part of the global transformations. This means we can update the ScopeModelBuilder to not mutate the AST at all as all constants are already simplified.
A potential follow up here is to simplify the ScopeModelBuilder since all nodes should already be simplified if they can be, we should be able to avoid visiting some children.
After this change we only directly create a single ConstantEvaluator, the one in `load_kernel`. The const simplifier also creates one and a follow up CL moves this to to run right after this new transformation.
Note: Alternate versions of this CL tried to make the global transformation simpler by either:
1) Running the const evaluator indiscriminately on all expressions. This didn't work because it lead to exponential computation on constants set up as a DAG (see tests/language/const/constant_dag_test).
2) Only evaluating ConstantExpression nodes to update UnevaluatedConstants. This does not cover all the cases where the ScopeModelBuilder is modifying the tree and lead to a different compiler output.
Change-Id: I746d889b37feddc9ab6c386c6252016dec745e6e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332601
Reviewed-by: Mayank Patke <fishythefish@google.com>
I suspect that when the list of type preserving selectors was created the first/last setters either didn't exist or were just overlooked. Any dynamic List could have its inferred type changed by these operations.
Due to Dart2js's type representation this bug affects more than just dynamic lists. We track some simple values as part of the type system. So an operation that modifies a value can technically modify the type, as Dart2js represents it, even if the "real" type is preserved.
In the added test we would represent the list literal's type as "List(length: 2, elementType: Bool(true))". Notice the type states the elementType is specifically true, not just bool. Thus the first/last operations are modifying that type. But since we aren't registering this type change, SSA optimizes away the call/index and inlines the element itself.
Interestingly, this primarily manifested for bools due to a check in SSA:
https://github.com/dart-lang/sdk/blob/main/pkg/compiler/lib/src/ssa/optimize.dart#L475
In that code we are inlining constant-like expressions for the arguments of static invocations (such as the argument to a Expect.isTrue call). However, a few lines earlier you will see we only inline bool constants:
https://github.com/dart-lang/sdk/blob/main/pkg/compiler/lib/src/ssa/optimize.dart#L467
So when the list element type is anything other than a bool, this inlining does not trigger thus avoiding the bug.
Bug: https://github.com/dart-lang/sdk/issues/53944
Change-Id: I4e893903f335fc99b13cf526736c27bb066a4bad
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/334420
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
The Dart2JS team has agreed that this mode of compilation is no longer worth investing in at this time and its existence adds some overhead to other feature work so it is worth fully removing. In the future we may revisit this mode of compilation. Below is some more context for any future exploration in this space.
What didn't work with modular analysis:
- current modular analysis was computing impacts, which were dense (50% of the size of kernel)
- using it moved work to a modular phase, and cut Phase1 in half however end-to-end time was not better
- data overhead was very high
- it made it much harder to maintain invariants throughout the pipeline: the data is tightly coupled with the kernel AST, making it hard to make late modifications to the AST.
How to potentially make it better:
- make the data much more sparse
- make the data more independent from the kernel AST so that transformations are not breaking
- reduce the critical path in a more substantial way.
Note: We retain and ignore the commandline flags used for modular analysis in order to avoid breaking build pipelines that were passing them. We may remove these at a later date.
Change-Id: If574ce2358280ab5fedd89c62665328601e72e22
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/333360
Reviewed-by: Mayank Patke <fishythefish@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
The only constructor invocation of `NonConstantValue` is in the deserializer. Which means we're never creating any of these objects to serialize.
Also remove unused `handleClosureCall` method in `pkg/compiler/lib/src/inferrer/builder.dart`
Change-Id: I04e492bc4824795dd8fc109ee7464be56b27cb93
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332500
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
1. Add `Object` and `Map` to the very short list of names that are
unminified in the app.
2. Tweak test to avoid testing minified name.
Change-Id: Ide0cedc2950b5392eb6963403a48c0f89cd1b50a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332368
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
- Remove unused Map in source map emitter logic.
- Buffer output writing for both JS and source maps. Previously we were only buffering the source map writes.
During local compilations of a large program combined these amount to a >100MB improvement in memory usage.
Change-Id: I633c2f81aa28744e30c6a706bb3927423b38a6e0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331361
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
After further review the slight increase in memory usage is minimal and worth the improvement in runtime for each phase.
The new indices follow the same format as before, we assign each entity an index when it is registered into the entity map. However these new indices are only used by the entity maps and not as part of the serialization format for those entities. The index only exists to make look ups faster in the "map". As such, I've made the field private to prevent/discourage outside use of it.
Change-Id: I7a7c20a2dd51b01d2390bb4401545821a1014832
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331360
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
We recently added the ability to pass a `--write-dump-info-data=` flag to Dart2JS's emitter phase which will serialize the necessary metadata to run dump info as a standalone phase of the compiler.
This extra metadata was incurring an overhead since we were maintaining JS AST nodes longer in order to extract metadata out of them. With this change we get rid of that overhead. The nodes are only retained until they printed and then any references to them are freed.
After this change the memory usage of the emitter phase is the same with or without the `--write-dump-info-data=` flag. There is still however some additional overhead in runtime. This is of course unavoidable as we are doing extra work to serialize the data.
Change-Id: Ib45a0e1de96d41503cbd76217b841ff013ac0655
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331000
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
Given the change to use serialization indexing, these classes aren't necessary anymore. We can use the base entity and J- impls directly.
Change-Id: I1074429ca7165fa1dbf740cab96a1b432cdd0a3d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/326500
Reviewed-by: Sigmund Cherem <sigmund@google.com>
The element map indexing system adds complexity to our element model with little benefit. Serialization already has its own indexing logic that we now reuse for entities.
Some things to note:
1) Libraries are still assigned an index. We only use that index in one place in the namer to disambiguate members. I now assign these indices as a late final field when adding the libraries to the element map.
2) The sizes of serialized files get slightly bigger since serialization indexing uses "addresses" rather than incrementing numbers for the indices. This effect is very minimal (<4MB+ for the largest programs).
3) "Late" members (constructor and generator bodies) which are created during codegen must be tracked and registered separately. Before the index was used to determine which entities were "late".
I see a very small memory improvement across all phases because of this change. There is also a small regression in runtime because the entity map queries are hash map lookups instead of list index lookups now. I think this very small regression is worth the reduced complexity in the compiler.
If we care about getting that time regression back we can add an "IndexedEntityMixin" with a late final index member that the registry would set/manage internally and would allow it to go back to tracking entities in a List. The field should be private so it would only be used for this purpose. This would only be necessary if we find the added time overhead of the map lookups to be too much.
Change-Id: Idd6d22bfc6ab61943a07feb58b35287d50e7d72e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/326461
Reviewed-by: Mayank Patke <fishythefish@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
Simplifies indices management for serialization by reusing the same indexing readers/writers for each phase. This way the caches are shared across all the phases and we can decouple the indices with any specific data read.
This fixes an issue that prevented the indices from being used in certain read/write patterns. None of our current usages of these indices exhibited this pattern but later changes I have planned do run into this issue.
This new pattern is also more resilient to sharding/parallel data files. Previously there could be collisions if two files were written in "parallel" (such as the codegen shards) and later their address spaces had to be merged. Now we do the address space merging at read time when we have full knowledge of the parallel files and can therefore avoid collisions.
Change-Id: Iff4c1461e734fc00f251d81f9fff1b9db83484d6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/326460
Reviewed-by: Stephen Adams <sra@google.com>
This adds the representation field of an extension type declaration
as an abstract getter in the ExtensionTypeDeclaraiton marking it as
a ProcedureStubKind.RepresentationField
These are never used as interface targets and are therefore skipped
in the type flow analysis.
TEST=existing
Change-Id: Ie645e63e0995a31895e985a2025dccb1476d16bf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/330782
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Sam Rawlins