Change the calling convention of the sync* body to fix bugs and avoid allocations.
- Body takes the controlling _SyncStarIterator as a parameter.
- `yield` assigns directly to the `_current` field and returns.
- `yield*` calls a method on the controlling iterator (rather than returning the iterable). This avoids an allocation to wrap the iterable, a type test to distinguish `yield` from `yield*`, and allows the `get:iterator` call to happen in the dynamic scope of try-catch surrounding the `yield*` to that it will catch any exceptions.
- Avoid using IIFE to bind constants just to call the body.
- Use a dummy body to avoid the need to testing termination of the body.
Tests now passing:
co19_2/Language/Statements/Yield_and_Yield_Each/Yield_Each/execution_sync_t05
language_2/sync_star/move_past_end_test
language_2/sync_star/sync_star_exception_current_test
language_2/sync_star/sync_star_exception_iterator_test
language_2/sync_star/sync_star_exception_nested_test
language_2/sync_star/sync_star_exception_test
Bug: #51992
Change-Id: I397b470e121b8d71242ac28b3130637b78a1d0dc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/294685
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
Inference runtime metrics on a large program:
-----Before-----
Duration - Mean: 182.303 Median: 174.500 Max: 292.0
Memory - Mean: 5857.426 Median: 5752.639 Max: 6167.91
-----After-----
Duration - Mean: 144.525 Median: 133.500 Max: 242.0
Memory - Mean: 5867.756 Median: 5727.506 Max: 6262.414
This shows ~20% improvement in runtime and virtually no change in memory usage. Previously we saw a memory regression due to this change. But thanks to improvements in the representation of TypeInformation nodes that memory regression no longer exists.
Code size for this program is also very similar before and after this change.
Before: 43258484 bytes JS
After: 43258444 bytes JS
Change-Id: I6512637f16d83f3127fd1c060bb770ae56405b88
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/295460
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Previously, vectors of type arguments were expanded to include type
arguments corresponding to superclasses both in the instances of
generic classes and in Type objects (after type finalization).
As a result, Type objects after finalization could be recursive and
need to use extra TypeRef objects to break loops. The finalization of
types was very complex and sometimes slow.
This change simplifies the representation of Type objects: now they
always have short type argument vectors, corresponding only to
the type parameters of their own classes (both before and after
finalization). Vectors of type arguments in the instances of generic
classes are still expanded/flattened.
This greatly simplifies type finalization, makes Type objects
non-recursive and removes the need to create and handle excessive
TypeRefs for type arguments corresponding to superclasses,
as those type arguments are no longer included into types.
The only remaining use of TypeRefs is for bounds of type parameters.
In order to expand/flatten type arguments, new methods Type::GetInstanceTypeArguments / Class::GetInstanceTypeArguments
are introduced. They build canonical declaration type arguments
once (for each class), and then instantiate them as needed.
There are also simple helper methods to shrink type arguments (TypeArguments::FromInstanceTypeArguments) and expand type arguments without filling type arguments corresponding to superclasses (TypeArguments::ToInstantiatorTypeArguments).
Time of edge case 'regress_51960_test' 15min -> 300ms.
TEST=ci, runtime/tests/vm/dart/regress_51960_test.dart
Fixes https://github.com/dart-lang/sdk/issues/52022
Fixes https://github.com/dart-lang/sdk/issues/51960
Change-Id: I75b466b74698a33c0bb5e1dcbd29542e413812a1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/295060
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
The main reason is to do this change is to avoid inconsistencies in what is considered to be a `JSArray`. Using `Array.isArray` allows js-interop where the JavaScript code subclasses `Array`.
dart2js-production results:
ArrayLoop.pseudopoly.hoisted1-indexing -50.20%
ArrayLoop.pseudopoly.indexing -35.18%
Iteration.concat.manual 11.69%
ListCopy.List.int.unmodifiable.2 12.03%
ListCopy.for.int.2 12.58%
ListCopy.spread.int.2 13.57%
ListCopy.toList.fixed.100 16.06%
ListCopy.List.of.fixed.100 16.96%
ListCopy.toList.100 17.28%
ListCopy.spread.int.cast.2 18.45%
ObjectHash.hash.5 19.62%
TypedDataPoly.A_UVx5.view.2 21.12%
ObjectHash.manual.5 21.70%
ListCopy.spread.int.map.2 21.96%
ListCopy.spread.int.cast.100 22.12%
TypedDataPoly.A_UVx5.view.100 23.04%
ListCopy.spread.int.map.100 25.26%
ListCopy.List.of.100 27.88%
ImagingGaussianBlurOnce 29.67%
MegaEquality 37.90%
An investigation of the two regressions shows that they benefit from a micro-benchmarking effect. The previous code was monomorphic at the property access in `receiver.constructor == Array`. If this is forced to be polymorphic, the baseline is quite a bit worse, leading to an improvement in line with some of the other benchmarks.
Change-Id: I5c265b1d7408fbd41da9c6fa17472bf648000c8d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/287140
Reviewed-by: Nate Biggs <natebiggs@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
This is a reland of commit 4cd9c9c666
This will be relanded without changes because we discussed the .proto
definition package name clashing problem with the Dart in google3 team,
and we have decided that the best solution is to ignore the checked in
.proto files in google3 builds.
TEST=Recorded traces with the Perfetto file recorder and explored them
in Perfetto's trace viewer, CI
Original change's description:
> Reland "[VM] Begin supporting Perfetto file recorder"
>
> This is a reland of commit 7424295ce9
>
> The differences between this reland and the original CL are: now the
> Perfetto file recorder does not get built in PRODUCT builds, and it does
> not get built unless the SUPPORT_PERFETTO macro is defined.
>
> TEST=Recorded traces with the Perfetto file recorder and explored them
> in Perfetto's trace viewer, CI
>
> Original change's description:
> > [VM] Begin supporting Perfetto file recorder
> >
> > This CL adds the `TimelineEventPerfettoFileRecorder` class, which is a
> > timeline recorder that writes a trace to file in Perfetto's proto
> > format. This CL supports the recording of all types of timeline events
> > except flow events. Support for flow events will be added in a future
> > CL.
> >
> > TEST=Recorded traces with the Perfetto file recorder and explored them
> > in Perfetto's trace viewer, CI
> >
> > Change-Id: Iaa2051e536589a473c5e15f9de9bb9c251f13d38
> > Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/278942
> > Reviewed-by: Ben Konyi <bkonyi@google.com>
> > Commit-Queue: Derek Xu <derekx@google.com>
>
> Change-Id: I8713f704b5fbeed5f1231012bce8a32aaf566ae4
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/286020
> Reviewed-by: Ben Konyi <bkonyi@google.com>
> Commit-Queue: Derek Xu <derekx@google.com>
Change-Id: Ia97ef1f0fe73e76c7022623b9ae7e21a4ea73a46
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/295804
Commit-Queue: Derek Xu <derekx@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
This was part of an older mechanism that set the checked stack limit based on the SP values we had seen so far. Today we query the exact stack boundaries on all platforms.
TEST=ci
Change-Id: I5692d97b5d4f9104ee9796de7406eb5f050ac276
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/295745
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
These dependency overrides prevent pub from getting confused about the
fact that our SDK development is in a mono-repo; that in turn allows
unit tests to be run from inside vscode using the standard test
integration.
Change-Id: I7629375f0ba4b07cd9ccdbb69f243d8eb0aa555a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/295660
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This reverts commit 4cd9c9c666.
Reason for revert: reusing the same proto package for copied files breaks rolling it to G3.
Original change's description:
> Reland "[VM] Begin supporting Perfetto file recorder"
>
> This is a reland of commit 7424295ce9
>
> The differences between this reland and the original CL are: now the
> Perfetto file recorder does not get built in PRODUCT builds, and it does
> not get built unless the SUPPORT_PERFETTO macro is defined.
>
> TEST=Recorded traces with the Perfetto file recorder and explored them
> in Perfetto's trace viewer, CI
>
> Original change's description:
> > [VM] Begin supporting Perfetto file recorder
> >
> > This CL adds the `TimelineEventPerfettoFileRecorder` class, which is a
> > timeline recorder that writes a trace to file in Perfetto's proto
> > format. This CL supports the recording of all types of timeline events
> > except flow events. Support for flow events will be added in a future
> > CL.
> >
> > TEST=Recorded traces with the Perfetto file recorder and explored them
> > in Perfetto's trace viewer, CI
> >
> > Change-Id: Iaa2051e536589a473c5e15f9de9bb9c251f13d38
> > Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/278942
> > Reviewed-by: Ben Konyi <bkonyi@google.com>
> > Commit-Queue: Derek Xu <derekx@google.com>
>
> Change-Id: I8713f704b5fbeed5f1231012bce8a32aaf566ae4
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/286020
> Reviewed-by: Ben Konyi <bkonyi@google.com>
> Commit-Queue: Derek Xu <derekx@google.com>
Change-Id: I2da67ffe5bff01d568f32f682455bb2c789499b0
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/295821
Commit-Queue: Ilya Yanok <yanok@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Reviewed-by: Oleh Prypin <oprypin@google.com>
Reviewed-by: Ivan Inozemtsev <iinozemtsev@google.com>
These dependency overrides prevent pub from getting confused about the
fact that our SDK development is in a mono-repo; that in turn allows
unit tests to be run from inside vscode using the standard test
integration.
Change-Id: Ica94f0a49d8c79f6a1f6395707b02d36da20089d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/295661
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
TypeArgumentClassFinder.FindClass always returns null (because
non-null values are never stored to TypeArgumentClassFinder::klass_).
Consequently, code using TypeArgumentClassFinder
(TypeUsageInfo::PropagateTypeArguments) seems to be redundant and
can be removed, along with another utility class
TypeArgumentInstantiator.
TEST=ci
Cq-Include-Trybots: luci.dart.try:vm-aot-linux-debug-x64-try,vm-aot-linux-release-x64-try
Change-Id: I7bfc98e5c4d5b4d3effa639031ae4bd6dce25643
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/295382
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
lauren n. liberda