Moving the class name of the allocated object to the allocation callback
gives more flexibility to the embedder, which may decide to track all
sampled allocations, not just those that are still alive.
TEST=Updated DartAPI_HeapSampling_*
Change-Id: Iaae290e15b67ca3e47d72e1896fa6e32b2d4b081
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/297761
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Previously this step happened during `buildOutlineNodes`, but since
`buildOutlineNodes` happens in source order, this means that anonymous
mixins would only get their sealed and final attributes properly
inferred if they appeared *after* their immediate supertypes in source
order. By moving this step to `checkSupertypes`, we ensure that the
computation is correct regardless of source order, because
`checkSupertypes` happens in class hierarchy order.
Fixes#52048.
Bug: https://github.com/dart-lang/sdk/issues/52048
Change-Id: Ib9f1f3dafded88681a26f09e4d21dfd44e70dfd3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/297901
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This CL splits up `Reference.node` in to the most-often fast-case and the
has-to-load case, making the procedure smaller which makes the VM inline
it. This was "verified" by looking at the VMs optimized flow graph for
`Reference.asClass`.
This CL furthermore reduces the number of "calls" to `Reference.node`
by almost half (a reduction of over 3 mio calls when compiling
`compile.dart`) by "caching" the `.node` call in the `as*` methods.
Change-Id: I7b5497397a11f05fdeaf05d6cc420072d98dc030
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/298101
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
When instrumenting one can use "--count" to instrument counting method
calls instead of instrumenting to create a flame graph.
From that I can for instance see that `Reference.node` is called 6+ mio
times when compiling compile.dart.
Example run:
out/ReleaseX64/dart pkg/front_end/tool/flame/instrumenter.dart pkg/front_end/tool/_fasta/compile.dart --count
out/ReleaseX64/dart pkg/front_end/tool/_fasta/compile.dart.dill.instrumented.dill pkg/front_end/tool/_fasta/compile.dart
Change-Id: I583f4b53a474c3777bb059ea89d932607b7c23ad
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/298100
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Could for instance be run like this:
out/ReleaseX64/dart pkg/front_end/tool/flame/instrumenter.dart pkg/front_end/tool/_fasta/compile.dart
out/ReleaseX64/dart pkg/front_end/tool/_fasta/compile.dart.dill.instrumented.dill --omit-platform pkg/front_end/tool/_fasta/compile.dart
out/ReleaseX64/dart pkg/front_end/tool/flame/instrumenter.dart pkg/front_end/tool/_fasta/compile.dart --candidates=cfe_compile_trace_candidates.txt
out/ReleaseX64/dart pkg/front_end/tool/_fasta/compile.dart.dill.instrumented.dill --omit-platform pkg/front_end/tool/_fasta/compile.dart
out/ReleaseX64/dart pkg/front_end/tool/flame/instrumenter.dart pkg/front_end/tool/_fasta/compile.dart --candidates=cfe_compile_trace_candidates_subsequent.txt
out/ReleaseX64/dart pkg/front_end/tool/_fasta/compile.dart.dill.instrumented.dill --omit-platform pkg/front_end/tool/_fasta/compile.dart
* The first command compiles and instruments "compile.dart" to record
all procedure calls.
* The second command runs the instrumented compiler on "compile.dart"
(but it could have compiled anything). Because every procedure is
instrumented this will take a lot longer than a usual run.
This produces a trace "cfe_compile_trace.txt" with every call taking
at least 1000 microseconds. This can be displayed via Chromes
about://tracing tool.
It also produces a file "cfe_compile_trace_candidates.txt" with a map
of the procedures that on average took at least 500 microseconds.
* The third command compiles and instruments "compile.dart", this time
only instrumenting the procedures mentioned in the map
"cfe_compile_trace_candidates.txt".
* The forth command runs the instrumented compiler on "compile.dart".
This run shouldn't take significantly longer than a non-instrumented
run. It produces a new "cfe_compile_trace.txt" which this time is
not filtered. It also produces a file
"cfe_compile_trace_candidates_subsequent.txt" of recorded procedures
that on average took at least 50 microseconds.
* The fifth and sixth commands repeats the third and forth but
instrumenting only the procedures mention in
"cfe_compile_trace_candidates_subsequent.txt".
The third iteration might not be needed, but if the first run was on a
smaller input (which it isn't in this example) there might be some calls
that on average took long enough to be included in the candidate list
because the first call was slow and there were only very few of them,
making the second trace very big because there are now a lot of - as it
turns out - very quick calls recorded. Adding the third iteration will
filter (at least some of) those out.
Change-Id: I702c5c9142e525502b02f37744fcdc9d2b0f9b20
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296902
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This is a reland of commit bbacf39e9c
Original change's description:
> [analysis_server] Analyze fix data in fix_data folder
>
> Fixes part of https://github.com/dart-lang/sdk/issues/52126.
>
> Change-Id: Ib4bd7830a2f644eacedccd375c7c8dc60f040d33
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296801
> Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
> Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Change-Id: I571c1e4f87fdf0095d003d496f3c5d88e5cf0ff8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/297940
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Makes more prominent that you can use '-v' to show
extra details about all options.
The message after this change will look as follows:
```
Compile Dart to JavaScript.
Usage: dart compile js [arguments] <dart entry point>
(use -h -v for detailed information about all options)
-h, --help Print this usage information
-o, --output Write the output to <file name>.
-O<0,1,2,3,4> Set the compiler optimization level (defaults to -O1).
```
Fixes https://github.com/dart-lang/sdk/issues/51982
Change-Id: I76fe5478b4a1d4b2ae2170eca72d764bc4d120b4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/294164
Reviewed-by: Nate Biggs <natebiggs@google.com>
Reviewed-by: Devon Carew <devoncarew@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
- variance_subtype_cast_test.dart: Pass soundNullSafety flag so @dart=2.7 flag doesn't get added to test.
- logical_expression_test.dart: Remove test as this is now covered by test added in https://dart-review.googlesource.com/c/sdk/+/297360.
Change-Id: I02d0fb816c5b41dad31014152ff3a796a528904c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/297860
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Change-Id: I564b60940475f40fa842e03d9b03ef0f7b06e9ae
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/297820
Reviewed-by: Kevin Moore <kevmoo@google.com>
Reviewed-by: Michael Thomsen <mit@google.com>
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Kevin Moore <kevmoo@google.com>
These were added during the Dart 2 test migration as a way to indicate
why a test was expected to fail. But, like negative tests, they have
very poorly granularity.
Static error tests are strictly superior.
The co19 tests have been migrated off of these markers for a couple of
years, so our own language tests were the only holdouts. I see no uses
of "@syntax-error", "@runtime-error", or "@static-warning". I have now
migrated all of the tests that contained "@compile-error" to be proper
static error tests.
This simplifies the test runner and makes our tests more precise.
Fix#45634.
Change-Id: I0f46d110b6f322d98187e734195ecba7524574af
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296720
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: William Hesse <whesse@google.com>
Auto-Submit: Bob Nystrom <rnystrom@google.com>
This is being done to allow us to access the utils from
profiler_service.cc.
TEST=Requested a trace using the getPerfettoVMTimeline RPC and confirmed
that it still looked correct.
Change-Id: Icfb7a5b41da0fc987a72098c4345e7e108b6566e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/297740
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Derek Xu <derekx@google.com>
I did not change any of the test cases. I did change the names of the
tests to be more consistent, and in the process I found a couple of
tests where the test code was identical, so I deleted the duplicates.
I expect that there will be more cleanup that we'll want to do after
all of the contributor tests have been converted and merged together,
but I wanted this CL to be as straightforward as possible given its
size.
Change-Id: I2cbb6b5c0718fbbc36da521ee3c4fc7d00c36dcb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/297720
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
No functional changes here but there have been some refactors inside the meta model that required some minor tweaks (URI moved from a type alias to string to a spec-defined base type).
I also improved the handling of some type references in the comments we bring in so they're clickable in more places.
Change-Id: I7c725d01b6d7bc0925979b8118dbfd8952f78724
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/297482
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This fixes the handling of list types in exhaustiveness checking so
that custom list implementations can be exhausted as lists.
The change doesn't include handling of sealed class and enums as lists
but test for these are added.
Closes#51973
Change-Id: I66bcff99c5262a82513dbde1e5561284846ceace
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/297460
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Cutting the shards from 10 to 4 makes the shards time out after 90
minutes on the slowest builders. Even the fastest builders have shard
runtimes of 30 minutes.
Changing the sharding of JIT builder tests from 4 to 8 for both VM tests
and co19 tests.
Fixup after https://dart-review.googlesource.com/c/sdk/+/294140
Change-Id: I813aa40b6aac0fc5083a9606b71d00e78ce71ffc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/297480
Commit-Queue: William Hesse <whesse@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
This CL adds more benchmarking points, specifically giving more insight
into where body_buildBodies time goes.
It furthermore changes how overlapping subdivides are handled.
Previously only the first subdivide was actually recorded, meaning that
if a subdivide `a` contained a subdivide `b` only subdivide `a` would
have any time recorded for it. Now instead subdivide `b` will get data
recorded for the time it runs; this time will then _not_ be added to
`a`s total. For instance if subdivide `a` spends one second, then
(while still being in subdivide `a`) we enter subdivide `b` and spend
one second there, exit it, and spend yet another second before we exit
subdivide `a` before we would just have recorded 3 seconds for subdivide
`a`, now we will instead record 2 seconds for subdivide `a` and 1 second
for subdivide `b`.
Additionally a "system subdivide" is automatically added summarizing
any unaccounted for subdivide time, and an extra entry describing the
estimated subdivide recording overhead figues too.
As an additional note, enabling benchmarking seems to add ~6-7% runtime,
and because we specifically add additional parsing phases to measure
that separately the token stream can change before doing the actual
parsing, meaning that when enabling benchmarking some errors might be
swallowed.
Change-Id: I07ef42657c385031e8bb8680738442cf04fe2263
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/295540
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This reverts commit bbacf39e9c.
Reason for revert: Causing flutter/engine to fail to roll into flutter/flutter. See https://github.com/flutter/flutter/pull/125363.
Original change's description:
> [analysis_server] Analyze fix data in fix_data folder
>
> Fixes part of https://github.com/dart-lang/sdk/issues/52126.
>
> Change-Id: Ib4bd7830a2f644eacedccd375c7c8dc60f040d33
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296801
> Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
> Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Change-Id: I109a4b2c596ad22d73eaf0ac3e25f53a35ba5e28
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/297320
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Zach Anderson <zra@google.com>
This CL replaces https://dart-review.googlesource.com/c/sdk/+/296900
The `List` constructor is removed in Dart 3.0.
Some of the `@patch` implementations were not removed.
This is *high priority*. It seems the left-over `@patch factory List` constructor did not cause any errors, instead it *added* a constructor to `List` that can be used in web compiled code. Even if `List` doesn't have such a constructor in the SDK code proper.
The VM and analyzer will say the invocation is an error, but dart2js happily compiles it and runs.
(It used to be that patches couldn't add public members, that security seems to have been removed.)
Also removes code which tries to detect "the unnamed List constructor",
which is no longer a thing, and a number of invocations of the constructor, where it's not clear that the test is aware that the constructor no longer exists, and is not marked as `@dart=2.x` with x < 12.
TEST=ci
Change-Id: I4ffaf3ae2c4e75ca06e7ba0bf19187b6376f3888
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/297100
Reviewed-by: Brian Quinlan <bquinlan@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
What was being logged as "kernel bytes" or "Dart characters" included the size of the platform dill as well. Changed the text for that to the more general "input bytes". The new source bytes number is the number of bytes registered to Dart2JS by the CFE. This registration is done when the CFE is being run modularly or directly from sources.
When being run modularly the input to phase 0 (CFE-only) is slightly larger (includes extra files) but the input to phase 1 (closed world) ends up matching the non-modular value.
Example output:
Compiled 14,927,936 input bytes (8,010,096 characters source) to 11,647,944 kernel bytes in 0.48 seconds using 114.082 MB of memory
Change-Id: Idaaaf6f9c906659434a9af50882b7ed3343e601a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/297020
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Before the calling convention change during the introduction of AOT, this was used to get code metadata associated with a frame. Its remaining non-test use is forming service IDs for code object, which can use the regular visitors.
TEST=ci
Change-Id: Ica8eafe988d19eba8d905d9dc5907afbfd559118
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296705
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
After the Page is unregistered, the only reference to its VirtualMemory is in memory not traced by LSAN. If exit happens here before the VirtualMemory is deleted or put into the global cache, it appears to be leaked.
TEST=lsan
Bug: https://github.com/dart-lang/sdk/issues/51560
Change-Id: I973e09bb19910d9cdcc3af6c8c9a188f095df36a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/297040
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
The analyzer team has decided to adopt the convention of using `TODO`
comments to document long term issues that should persist in the
codebase, and `FIXME` comments to document short term issues that need
immediate attention. They may even consider adding a presubmit hook
to ensure that `FIXME` comments are only used during local
development.
Accordingly, it makes sense to suppress `TODO` comments from being
surfaced to the IDE "problems" view (since there are hundreds of them,
and they're not immediately actionable). This makes VSCode's
"problems" view much more usable in "tree" mode.
Change-Id: I11a0c59132fb98c1c86fb4adf22d1fdf3b547c80
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/295662
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
