I do some benchmarking with our benchmarker tool which uses "perf stat"
under the hood.
"perf stat" uses hardware counters, but we have a limited amount of
those. The benchmarker tool asks for 3 event types that will use 3
hardware counters. If there aren't 3 available it will do "scaling" and
only measure what it's asked some percentage of the time so it can still
measure all of the stuff it's asked.
This should be fine. My computer has 4 hardware counters. I think.
Only today I still experienced scaling.
And previously I asked for 4 event types because I had 4 hardware
counters, but then suddenly 1 went missing.
As it turns out another process was using hardware counters.
This CL includes a tool that - at least seeems to - be able to find
other processes using perf events (although it might not be events that
use hardware counters), thus possibly allowing you to kill that or those
process(es). I did, and I now have 4 hardware counters again.
I also made scaling more visible if it happens when using the benchmark
tool. Before it was hidden between other output, not it's also printed
at the end, together with a hint to use the new tool to attempt to fix
it.
Change-Id: Ia51db04a4f25d1d82c3d32b3901cded7d980e7f5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352525
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Nested macros: check that macro impls can themselves use macros.
Disallowed use: check that macros can't be used in the library in which they are declared, or in the same library cycle.
R=jakemac@google.com
Change-Id: I3b12afc27e5784edc217508b7763a9b448229877
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352522
Reviewed-by: Jake Macdonald <jakemac@google.com>
Commit-Queue: Morgan :) <davidmorgan@google.com>
Auto-Submit: Morgan :) <davidmorgan@google.com>
This reverts commit aec3ec0244.
- Corrected 'controlling condition' detection.
- Added test that is incorrectly compiled to infinite loop with incorrect controlling condition detection.
See https://github.com/dart-lang/sdk/issues/54115#issuecomment-1944285230 for an image of part of the CFG for `doWhileLoop` where the condition in B4 was previously mis-identified as controlling `phi(true,false)` at B12.
Issue: #54115
Change-Id: I0d2c2ff83b202071f6d7050d34de8ff25d05cb22
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352443
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
Precise new-space usage requires looking at all the TLAB pointers and normally only occurs under a GC safepoint. For external queries coarsen the answer to capacity.
TEST=g3
Bug: b/324221135
Change-Id: I0e83bbcddba21ddf539fb2afdedf2959cef2c078
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352682
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
- These tests rely on the internals of the old type system.
- Copy some expectations to the language suite when it looks like
there isn't already coverage for the same test.
Change-Id: I63bfa2bc94fb29b4e4f90c3c02cf0943d19764b6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352463
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Kallen Tu <kallentu@google.com>
This introduces an asyncExpectThrowsWhen to async_helper, similar to
Expect.throwsWhen, to allow specifying semantics under behavior
variations in this test.
We also update await_for_test to no longer skip expectations in dart2js.
Change-Id: Ie147f74f384a0e196e40b75c59fe585f011ede49
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/351721
Reviewed-by: Lasse Nielsen <lrn@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Today, most tests that touch on a behavior variation end up
skipping expectations or the entirety of a test for some
testing configurations. Moving forward, we'd like skip less
and try to account for the behavior variations if that's
reasonable.
This CL shows an approach to improve our test coverage for
behavior variations. We introduce two new methods to
[Expect] that allow us to conditionally check that a
function throws, depending on variation predicates.
The CL changes expectations for errors that don't occur
when dart2js omits parameter type checks or implicit
downcasts.
Note: originally I had the intention to introduce a name
parameter to `Expect.throws` and `Expect.throwsTypeError` to
avoid introducing a new API. However, because these APIs are
used for testing core language features, such as function
parameters themselves, we decided to keep the use of
features in these APIs as simple as it can be.
CoreLibraryReviewExempt: no public library semantic change - only improving test coverage under variations
Change-Id: I531657622655778491eaca8b37ba69ffaab559fc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/351340
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Support `checkedExplicitCasts`,`checkedImplicitDowncasts`, `checkedParameters`, `jsNumbers`, and `nativeNumbers`.
dart2js and DDC configs should support `jsNumbers`.
dart2js and dart2wasm (both optimized) do not support checked parameters nor implicit downcasts checks.
dart2wasm optimized does not support explicit cast checks.
This CL adds these features and makes sure certain configs are opting into these features.
Bug: https://github.com/dart-lang/sdk/issues/54798
Change-Id: If61d513569259317b1fb89c27d3fd97e3542697d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352103
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
These can't be deprecated for a while, at least not until 'dart:html' itself is.
In the mean time, we can at least discourage usage of it and direct developers to more appropriate, long-term solutions.
Contributes to https://github.com/dart-lang/sdk/issues/54852
CoreLibraryReviewExempt: Documentation only change that directs developers to more specific, performant, or flexible solutions.
Change-Id: I9d099a49909673f8af23eab480fdd225e56bcab2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/351961
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
This test deoptimizes, so it can't run in AOT.
TEST=runtime/tests/vm/dart/regress_54871_test.dart
Fixes: https://github.com/dart-lang/sdk/issues/54913
Change-Id: Ida2c67f20c8cf879db2cc9424f3d37535b76370d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352660
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Auto-Submit: Daco Harkes <dacoharkes@google.com>
`Pointer`s were not handled in deferred materialization of objects
on deoptimizations. This lead to the address field being written as a
tagged value, causing the actual address to be smitagged.
Subsequent uses of those addresses would lead to segfaults.
This CL handles the `Pointer`s manually to deal with the untagged
address.
`--trace-deoptimization-verbose` before this CL:
```
Deoptimizing [...]
_typedDataBase@8050071 <- Pointer: address=0x7ffff7488081
null Field @ offset(8) <- 140736616678128
null Field @ offset(16) <- TypeArguments: (H39d2e3b4) [Type: Never]
```
after this CL:
```
Deoptimizing [...]
_typedDataBase@8050071 <- Pointer: address=0x7fa2c0a88081
pointer@data <- 0x7fa29c16c0e0
pointer@type_args <- TypeArguments: (H39d2e3b4) [Type: Never]
```
TEST=runtime/tests/vm/dart/regress_54871_test.dart
TEST=tests/ffi/structs_test.dart with --hot-reload-rollback-test-mode
and --optimization-counter-threshold=50
Closes: https://github.com/dart-lang/sdk/issues/54871
Change-Id: I13b6404c8b098643b8ac0f59ee8e9bc635f33b8d
Cq-Include-Trybots: luci.dart.try:vm-reload-rollback-linux-debug-x64-try,vm-reload-rollback-linux-release-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352300
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
These ease my life slightly.
Examples:
Compile to executable to get faster runs:
```
out/ReleaseX64/dart-sdk/bin/dart compile exe pkg/front_end/tool/gitformat_cl.dart -o ~/bin/format_cl
out/ReleaseX64/dart-sdk/bin/dart compile exe pkg/front_end/tool/git_branch_helper.dart -o ~/bin/gitbranch
```
Now I can format my entire CL with
```
$ format_cl
Using file:///path/to/dart-sdk/sdk/out/ReleaseX64/dart
stdout> Formatted 3 files (0 changed) in 0.35 seconds.
```
and get info about my branching with
```
$ gitbranch
├── origin/main
│ ├── add_a_few_cfe_util_tools [ahead 2]
```
Change-Id: I2e89196ab702660a1486894d22678e3cd0c07994
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352641
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
We want dart2wasm be comparable to dart2js / dart2aot, the ladder two
are much more conservative with inlining compared to current dart2wasm.
The -O3 is described in the binaryen sources as agressive for
performance and therefore willing to compromise code size.
The -Os is more nuanced: It will perform many optimizations that are
done in -O3 (and e.g. not in -O2) but it will make inlining less
agressive.
This reduces flute compile-time by 10% and code size by 10%
This benchmark results are mixed (some things get faster, some things
slower). Naturally there'll be specialized micro benchmarks that
get hit hard by this.
Where performance matters we should rather make dart2wasm use better
inlining heuristics and annotate code with
`@pragma('wasm:prefer-inline')`
Change-Id: Idf7e75e4e385629c9cec66359efe0afe50db3e72
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352523
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
The newer version will contain optimizations that remove `array.len`
instructions of arrays that have a known length
Change-Id: I52a302fdfdc757e082c762c89cbcb68123025795
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352524
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Now that the types in the message were recently adjusted to include the '?', I think it's beneficial to focus on what the underlying problem is rather than the syntax.
Change-Id: I7e59ea3cc2ce618fe46052a9c5e04a973a5f6ab9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/349581
Auto-Submit: Parker Lougheed <parlough@gmail.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Chloe Stefantsova <cstefantsova@google.com>
The dart closures for the then/onError callbacks we use on a JS promise
will not flow back into dart. There's therefore no reason to use the
very heavyweight `allowInterop` mechanism.
This makes (after [0]) asynchronous calls to JS from Dart more than 2x
as fast.
This also aligns the `promiseToFuture` implementation with the extension on
`JSPromise` (see sdk/lib/_internal/wasm/lib/js_interop_patch.dart)
modulo the fact that the API doesn't work on interop types but Dart
types and needs therefore the full JS<->Dart conversion.
=> Maybe it would make sense to deprecate `promiseToFuture` / not offer it
in dart2wasm and make users use instead the extension on `JSPromise`
instead?
[0] https://dart-review.googlesource.com/c/sdk/+/352520
Change-Id: Ibc80bf083e7ec817f000257d6995108954060277
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352521
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
We're expecting to do multiple breaking changes to native_assets_cli
and native_assets_builder in the foreseeable future. So lets not break
the roller script for DEPS.
Change-Id: I6829de8d11e381fa2c56a974400ac636ec9e84cd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/350925
Reviewed-by: Moritz Sümmermann <mosum@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Also cleans up some wording and better explains all the possible
features of the annotation.
CoreLibraryReviewExempt: Docs for backend-specific library.
Change-Id: Id5f3e1ea09d2ceaf9f727eb7885b38319b978dd6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352441
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
These are tests for the specific apis of the old runtime type system
and they will never pass in the new type system.
Change-Id: I740fc06411cdc621b072782d22ec630c5b6bf96a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/341784
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
When a local variable is promoted to a record type, and then an
assignment statement is used to assign a record literal to that local
variable, if the fields of the new record literal are not assignable
to the fields of the promoted record type, that's not a problem; both
the analyzer and front end agree that the local variable is simply
demoted.
But the spec implies that if the old and new record _shapes_ are the
same, then a compile-time error will occur instead of a demotion. I've
created https://github.com/dart-lang/language/pull/3613 to bring the
spec in line with the implementations. This test demonstrates the
current behavior of the implementations, and makes sure that it
doesn't regress.
Change-Id: I0eacd7ca7f6579a35dbc34687113a2112418f368
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352462
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Prior to this CL, the CFE used a nullable type schema for null-aware
spread operators in list literals, but a non-nullable type schema for
null-aware spread operators in set and map literals. This was clearly
an oversight; a nullable type schema should be used for for null-aware
spread operators in all kinds of collection literals.
This change brings the CFE into alignment with the analyzer.
Fixes https://github.com/dart-lang/sdk/issues/54828.
Change-Id: I0d5aa128656c22211228f0dd35ccee40925b4ef0
Bug: https://github.com/dart-lang/sdk/issues/54828
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/349921
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
This significantly speeds up certain operations as it avoids calling
complex closure equality logic in the hashmap operations.
See also [0] regarding us leaking those closures.
[0] https://github.com/dart-lang/sdk/issues/54908
Change-Id: I046063884b88fbe53bc3cb397b0087693c9b928a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352520
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This will be paired with a hotfix to land in google3. Updating the
DEPS to use the latest version of package:web will be done in a
future commit.
Change-Id: Ia09b34e14250c9b2c2586d1dc369e9ccbab8b331
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/349960
Reviewed-by: Devon Carew <devoncarew@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
- Reorganize conditional impacts/uses so that unused impacts only overwrite nodes that no other member condition is satisfying.
- Use `isMemberProcessed` instead of `isLiveInstanceMember` since some member conditions might be static members.
- Update deferred load algorithm to account for conditional uses.
Change-Id: I53ce6d283c5b79e0a7c9e7562fdcfe744e37bbc7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352180
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
This test appears to be timing out consistently in windows.
We split the test in two shards (sound vs unsound null safety)
as an attempt to address this issue.
Fixes https://github.com/dart-lang/sdk/issues/54894
Change-Id: I2230be95b1685ef1e5656eae2e740a94a0eeb320
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352049
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
This is a reland of commit 244f8cee87
with fixes for the file URIs passed on the command line.
Original change's description:
> [ddc] Fix running d8 with test.py
>
> - Add build targets to compile .dill outlines for common test
> dependencies using kernel_worker.dart.
> - Build ddc modules for common test dependencies and move amd versions
> to a separate subdirectory.
>
> Change-Id: I126b5821f6aea00b753d83560c76f00c6c5edc61
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/350081
> Reviewed-by: Sigmund Cherem <sigmund@google.com>
> Commit-Queue: Nicholas Shahan <nshahan@google.com>
Change-Id: I5a77512984fda1d91c812f1e240e9c10609914f1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/351622
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
ZoneHandles out-live the HANDLESCOPE for class finalization, and can accumulate a lot of objects during FinalizeAllClasses.
TEST=ci
Bug: https://github.com/dart-lang/sdk/issues/54886
Change-Id: Ia1330e0f27770c1a786a1b70e56881127cd936b2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352052
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
- devtools server can now take the dtd uri as a parameter on startup
- dtdUri is passed to the server handler so that devtools can request it.
- FileService is implemented inside the Dart Tooling Daemon (dtd_impl)
- Added FileService.setProjectRoots
- Added unit tests and rpc exceptions
- on startup dtd now prints { uri, secret } so that the caller has the secret that allows them to call FileService.setProjectRoots
Fixes: https://github.com/dart-lang/sdk/issues/54790
Change-Id: I7a66aca2f8f06f6a611a46c727a9d5c2485fbe3e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/346922
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Dan Chevalier <danchevalier@google.com>
