After using DAS with it for a few days, I find it more distracting
than useful.
Change-Id: I20da35e06958c79a6d458546937b616d45b0c909
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296281
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Change-Id: I62581c6874b211c57da61639f460685790acb40d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296021
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
The "@compile-error" comment is an old not-great way of defining static
error tests.
Note that the behavior of the code under test here had changed
significantly, but the test didn't catch it at all because
"@compile-error" is too coarse-grained.
See: https://github.com/dart-lang/sdk/issues/45634
Change-Id: I4b6c4e1fd36770e13f7b5ca100b42b0b8b2983ae
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296121
Commit-Queue: Jake Macdonald <jakemac@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Auto-Submit: Bob Nystrom <rnystrom@google.com>
I'm unable to reproduce this, but there are probably many reasons an isolate could go away while we're doing this async work (such as the app shutting down or a restart). If it does, we should never throw because the results of configuring an isolate are not important if the isolate has gone.
Fixes https://github.com/flutter/flutter/issues/125064
Change-Id: Idb8972a5e77109783799fed70dd8b64e3f702bf5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296201
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
This reverts commit 135443706b.
Reason for revert: breaks many targets in G3, see b/278841863
Original change's description:
> [vm] Avoid expanding/flattening type arguments vectors in Type objects
>
> 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>
Change-Id: If0b2077305620593b8f03ebf6c135375c4086b1a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296182
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Ilya Yanok <yanok@google.com>
For every isolate there should be only one mutator with
a unique [Thread] object.
We change existing tests that use this functionality to instead use
`Thread::{Enter,Exit}IsolateGroupAsHelper`. It also results in a net
removal of code.
TEST=ci
Change-Id: Ic326e868a98ddedbab5b8c429252d38ea71bbf04
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/295940
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
During safepoint we can distinguish between
* owner of the safepoint operation (which is running code)
* everyone else (which are all blocked
Currently `Thread::IsAtSafepoint()` will return true for both. Since the
thread owning the safepoint operation is running, it's not actually
guaranteed that it's at "safe" point (e.g. to GC or to deopt) - it
really depends on what it's doing.
=> This CL will change it so that only actually parked threads will
have `Thread::IsAtSafepoint()`.
In order to do that we change varrious usages of `IsAtSafepoint()` to be
more precise:
* `Thread::OwnsSafepoint()`: True if this thread owns the
active safepoint. The thread is running.
* `Thread::OwnsGCSafepoint()`: True if the active safepoint is a GC
(or Deopt) safepoint and this thread owns it. The thread is running.
* `Thread::OwnsDeoptSafepoint()`: True if the active safepoint is a
Deopt safepoint and this thread owns it. The thread is running.
* `Thread::CanAcquireSafepointLocks()`: True if the thread is allowed
to acquire safepoint locks.
* `Thread::IsAtSafepoint()`: true if this thread is parked at a
safepoint
TEST=ci
Change-Id: I1a5a6727e84843ae79e0a344c438da19b7d6d916
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/295781
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
This CL makes some refactorings to the current safepoint mechanism:
* When owning safepoint level L we set current thread to be only at
safepoint level L (not Thread::Current()->current_safepoint_level()).
This ensures that after [WaitUntilThreadsReachedSafepointLevel] all
other threads are actually parked.
* When having nested safepoint scopes we increase operation count on
the level we own and all nested levels. This will (in later CL) allow
detection which closest scope we're in.
TEST=ci
Change-Id: Iffb2e9f4eea817a381acbd7a771bc75f5a89877b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/295541
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Currently when `switch` expression is nullable (so the values are boxed)
we currently use `ref.eq` to compare the values.
This doesn't work as expected when one of the values is a constant and
the other one is a runtime-allocated value. Example:
void test(bool? x) {
switch (x) {
case false:
print('no');
case true:
print('yes');
case null:
print('maybe');
}
}
bool runtimeTrue = int.parse('1') == 1;
void main() {
test(runtimeTrue);
}
Here the return value of `runtimeTrue` is boxed in the call site of
`test`. In the body of `test` we use globals for constants `true` and
`false`, which are never equal to runtime-allocated values.
We now use `identical` in these cases, which handles `bool`, `String`,
and `num` values as expected and compares the rest using `ref.eq`.
New passing test: co19/LanguageFeatures/Patterns/exhaustiveness_A01_t10
Fixes#52075
Change-Id: Ibbeda7525fd40cfec5ee477493d0d96ac6e139b2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/295941
Commit-Queue: Ömer Ağacan <omersa@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
This contains two minor formatting changes to records.
Change-Id: Ib90479ae60646c7cb0d5c746b5772fc63ee2a0f0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296026
Commit-Queue: Alexander Thomas <athom@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Removing this cache means that errors from dill-loaded sources only display an offset rather than an exact file location. This makes debugging externally reported issues more difficult.
See here for more background: https://github.com/dart-lang/sdk/issues/52020#issuecomment-1513533855
Change-Id: I243d0bd340708ddbf979d77b5e9559751ee1b79e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296040
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
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>
This CL pulls in dart-lang/native packages and runs them on the
pkg bots.
Bug: https://github.com/dart-lang/sdk/issues/50565
Change-Id: Ifcd8ba25f8bdfeca8f4c161adfc3c20e0ce500d1
Cq-Include-Trybots: luci.dart.try:pkg-linux-debug-try,pkg-linux-release-try,pkg-mac-release-arm64-try,pkg-mac-release-try,pkg-win-release-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/295280
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: William Hesse <whesse@google.com>
Dynamically probe and load system functions for adding/deleting unwinding instructions to ensure vm can gracefully handle running on Windows 7, where those functions are not available.
Fixes https://github.com/dart-lang/sdk/issues/52071
TEST=ci
Change-Id: If4696bb8172d12f84f49d1d10affd7930a5bedfe
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/295741
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
Go to the runtime so TSAN sees the instrumented access to Thread::safepoint_state_, avoiding false data race reports.
TEST=tsan
Bug: https://github.com/dart-lang/sdk/issues/52024
Change-Id: Ic686bac2221d8ac6b9865ce9c82a4c36711037a7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/295740
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
