We are going to enable waitFor in 3.2 release
and disable it in 3.3.
This makes migration smoother for users that need
to use Isolate.resolvePackageUriSync which is
only added in 3.2.
The actual removal timeline remains the same:
we will remove waitFor in 3.4.
TEST=ci
Bug: https://github.com/dart-lang/sdk/issues/52121
Change-Id: I1ab7d07f874b3d914f070f1c358fcffaa96da28b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/329420
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
This is follow up for the previous change somewhat incorrectly used
FLAG_profiler in ~OSThread to determine whether we need to delete
interrupter related state. FLAG_profiler is mutable in non-PRODUCT
builds so this could create memory leak.
TEST=testing PRODUCT and non-PRODUCT builds manually
Change-Id: Icf5ca6b83daab91daa125755261700ba2dbb9533
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/328422
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
Lookup in the library import can be very slow and it is not needed
most of the time. This change makes Library::Lookup{Class,Function,Field}[AllowPrivate]
lookups local in the library and cleans up related or unused code.
TEST=ci
Change-Id: If5a99bce7d712ce3a898395f74d4febac0311048
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/323221
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
The main purpose of the low-level [PortMap] is to coordinate between
ports being opened & closed and concurrent message senders. That's the
only thing it should do.
Each isolate owns [ReceivePort]s. Only the isolate mutator can create
ports, delete them or change their "keeps-isolate-alive" state. Right
now it requires going via [PortMap] (which acquires lock) and
[MessageHandler] (which acquires lock) to change the
"keeps-isolate-alive" state of a port.
We'll move information whether a dart [ReceivePort] is closed and
whether it keeps the isolate alive into the [ReceivePort] object itself.
=> Changing the "keeps-isolate-alive" state of the port no longer
requires any locks. We could even avoid the runtime call itself in a
future CL.
Isolates are kept alive if there's any open receive ports (that have not
been marked as "does not keep isolate alive"). This is a property of an
isolate not of the message handler. For native message handlers we do
have a 1<->1 correspondence between port and handler (i.e. there's no
"number of open ports" tracking needed).
=> We'll move the logic of counting open receive ports and ports that
keep the isolate alive to the [Isolate].
=> We'll also remove locking around incrementing/decrementing or
accessing the counts.
=> The [IsolateMessageHandler] will ask the [Isolate] whether there's
any open ports for determining whether to shut down.
=> For native ports, the `Dart_NewNativePort()` & `Dart_CloseNativePort()`
functions will manage the lifetime (as their name also suggests).
Overall this makes the [Isolate] responsible for creation of dart
[ReceivePort]s and tracking whether the isolate should be kept alive:
* Isolate::CreateReceivePort()
* Isolate::SetReceivePortKeepAliveState()
* Isolate::CloseReceivePort()
TEST=ci
Change-Id: I847ae357c26254d3810cc277962e05deca18a1de
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317960
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
a) Remove 2 fields in our object representation:
* PatchClass::library_data_
* Library::kernel_data_
=> This saves O(#libraries + #patch-classes) which can amount up to
10+ MB for big apps, as we save not just the slots but the
[ExternalTypedData] objects they used to reference.
Instead we'll compute the KernelLibraryData when we need it by making a
[TypedDataView] of sub parts of the component.
b) We make a kernel binary be represented by a single [ExternalTypedData].
Whenever we need a sub-part of a kernel binary (e.g. one for each
component for concatinated kernels, or one for a library inside a
component) we use proper [TypedDataView]s for that.
c) As we sometimes need to create a view of only a particular library
within a component we need to find start/end of a library based on
index.
=> We store the library index instead of the library offset on
Library/PatchClass.
=> We can easily derive the start/end of a library from it's index by
looking at the kernel component encoding.
d) We make the [Reader] object work purely based on a pointer - instead
of making it have if/else when reading bytes (either from pointer or
from a view).
e) We make the [KernelProgramInfo] store the kernel_component and
various TD views into it.
TEST=ci
Change-Id: Ibe160881ff48635e834c3d647a977a144b5d0565
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/313561
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Creation of AppJit snapshot will not include the source of [Script]
objects (see `UntaggedScript::snapshot_to`). As a result there's no
point in letting the CFE embed the sources into the kernel if we
only use it to create an AppJit snapshot.
This is also in line with build rules for our dart-sdk, where we do the
kernel compilation separately, see utils/application_snapshot.gni:
```
template("application_snapshot") {
...
# Build the kernel file using the prebuilt VM to speed up the
# debug and simulator builds.
prebuilt_dart_action(target_name + "_dill") {
...
args = [
...
"--no-embed-sources",
...
]
[[[
}
...
}
```
TEST=ci
Change-Id: I4e17e49dc21af6102d62c2278dbd6ebbe387f7e8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/313560
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This splits `Dart::InitializeIsolate()` into
* `Dart::InitializeIsolateGroup()` that sets up an `IsolateGroup`
=> This is only done at isolate group creation time when the very
first isolate is created.
* `Dart::InitializeIsolate()` that sets up an `Isolate`.
=> This is done for every isolate.
This is purely refactoring / code cleanup.
TEST=ci
Change-Id: Ica906444f79fe49849b9e11e96f7c89184cb9d09
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311603
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This is a reland of commit 6f4bed30cc
Original change's description:
> [vm] Fix CompileType::CanBeFuture()
>
> In certain cases compiler can omit a type check in 'await e' if it can
> prove that expression 'e' cannot be evaluated to Future.
>
> Previously, if actual type of 'e' is unknown, CompileType::CanBeFuture()
> tested if static type of 'e' is a subtype of Future.
>
> This is not correct, as static type could have a subtype which is also
> a subtype of Future, but static type itself is not a subtype of Future:
>
> class A {}
> class B implements A, Future<A> {}
>
> A e = confuse(B()); // 'e' is B, but has a static type A.
> await e; // A is not a subtype of Future, but 'e' is Future
> // and should be awaited.
>
TEST=language/async/await_flatten_test
Fixes https://github.com/dart-lang/sdk/issues/52585
Change-Id: I37add9021261c95dee5930e031187868e821c161
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/309481
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
This reverts commit 6f4bed30cc.
Reason for revert: g3 failure (b/287294480).
Original change's description:
> [vm] Fix CompileType::CanBeFuture()
>
> In certain cases compiler can omit a type check in 'await e' if it can
> prove that expression 'e' cannot be evaluated to Future.
>
> Previously, if actual type of 'e' is unknown, CompileType::CanBeFuture()
> tested if static type of 'e' is a subtype of Future.
>
> This is not correct, as static type could have a subtype which is also
> a subtype of Future, but static type itself is not a subtype of Future:
>
> class A {}
> class B implements A, Future<A> {}
>
> A e = confuse(B()); // 'e' is B, but has a static type A.
> await e; // A is not a subtype of Future, but 'e' is Future
> // and should be awaited.
>
> TEST=language/async/await_flatten_test
> Fixes https://github.com/dart-lang/sdk/issues/52585
>
> Change-Id: I270a8260224246e1f8c16eff57231363a0f25ae6
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/309380
> Commit-Queue: Alexander Markov <alexmarkov@google.com>
> Reviewed-by: Ryan Macnak <rmacnak@google.com>
Change-Id: I87a08e46b4af6c57efa828c0f9041e6b5e51708e
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/309480
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Alexander Markov <alexmarkov@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
In certain cases compiler can omit a type check in 'await e' if it can
prove that expression 'e' cannot be evaluated to Future.
Previously, if actual type of 'e' is unknown, CompileType::CanBeFuture()
tested if static type of 'e' is a subtype of Future.
This is not correct, as static type could have a subtype which is also
a subtype of Future, but static type itself is not a subtype of Future:
class A {}
class B implements A, Future<A> {}
A e = confuse(B()); // 'e' is B, but has a static type A.
await e; // A is not a subtype of Future, but 'e' is Future
// and should be awaited.
TEST=language/async/await_flatten_test
Fixes https://github.com/dart-lang/sdk/issues/52585
Change-Id: I270a8260224246e1f8c16eff57231363a0f25ae6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/309380
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Patchset 1 is a reland of commit
f52bdb96aa, and Patchset 2 adds a
corrected reland of commit 0d0e301979.
The leak in g3 was caused by moving the `state_ = 0;` line before the
`owns_label()` check in `TimelineEvent::Reset`.
TEST=Ran the g3 tests that were failing on a cbuild copy with these
changes (sponge2/1134a5bb-5168-4e4c-bb03-72a7d7ad6ab4).
Original change's description:
> [VM/Timeline] Add Dart_RecordTimelineEvent Embedder API to support reporting flow events that can be serialized in Perfetto's format
>
> Added a deprecation notice to Dart_TimelineEvent as well.
>
> TEST=Used the embedder API to report an events of each of the following types:
> Dart_Timeline_Event_Begin, Dart_Timeline_Event_Duration,
> Dart_Timeline_Event_Instant, Dart_Timeline_Event_Async_Begin, and
> Dart_Timeline_Event_Async_Instant, each associated with flow IDs. Then,
> retrieved the trace using GetPerfettoVMTimeline and checked that flow arrows
> were displayed correctly in the Perfetto trace viewer.
>
> Change-Id: I82e49554b5970767e306dc4149a782e99a5c6512
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/302963
> Commit-Queue: Derek Xu <derekx@google.com>
> Reviewed-by: Ben Konyi <bkonyi@google.com>
Change-Id: I08783d6b5575fb3fe43da3203e58902bf9b7d038
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/308721
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Derek Xu <derekx@google.com>
This reverts commit f52bdb96aa.
Reason for revert: https://dart-review.googlesource.com/c/sdk/+/308360
was reverted due to g3 problems, and the code in this CL will leak
without the code in that CL.
Original change's description:
> [VM/Timeline] Add Dart_RecordTimelineEvent Embedder API to support reporting flow events that can be serialized in Perfetto's format
>
> Added a deprecation notice to Dart_TimelineEvent as well.
>
> TEST=Used the embedder API to report an events of each of the following types:
> Dart_Timeline_Event_Begin, Dart_Timeline_Event_Duration,
> Dart_Timeline_Event_Instant, Dart_Timeline_Event_Async_Begin, and
> Dart_Timeline_Event_Async_Instant, each associated with flow IDs. Then,
> retrieved the trace using GetPerfettoVMTimeline and checked that flow arrows
> were displayed correctly in the Perfetto trace viewer.
>
> Change-Id: I82e49554b5970767e306dc4149a782e99a5c6512
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/302963
> Commit-Queue: Derek Xu <derekx@google.com>
> Reviewed-by: Ben Konyi <bkonyi@google.com>
Change-Id: I98a259c7de8fa4b7dbcbe42f7332ab20b553e9cc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/308680
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Derek Xu <derekx@google.com>
Added a deprecation notice to Dart_TimelineEvent as well.
TEST=Used the embedder API to report an events of each of the following types:
Dart_Timeline_Event_Begin, Dart_Timeline_Event_Duration,
Dart_Timeline_Event_Instant, Dart_Timeline_Event_Async_Begin, and
Dart_Timeline_Event_Async_Instant, each associated with flow IDs. Then,
retrieved the trace using GetPerfettoVMTimeline and checked that flow arrows
were displayed correctly in the Perfetto trace viewer.
Change-Id: I82e49554b5970767e306dc4149a782e99a5c6512
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/302963
Commit-Queue: Derek Xu <derekx@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
This is a reland of commit 46e70a7c07
It turns out that flow events do need to be associated with IDs in
Chrome's trace format, so the diff between patchset 1 and 6 contains the
changes required to document that.
TEST=Checked that duration events still looked correct in traces written
by the Perfetto file recorder. Checked that events still looked correct
in traces recorded to the MacOS recorder. Checked that flow events still
looked correct in Observatory. Ran the
vm/cc/DartAPI_TimelineEvents_Serialization test in debug mode, and with
ASAN and TSAN.
CoreLibraryReviewExempt: Does not change any APIs, just stops passing a
value that will never be read. Specifically, we do not need to pass a
flow ID on the end side of track events.
Change-Id: I6b8bb3236339dbe54378b2e9dea06faf22b964a9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/306664
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Derek Xu <derekx@google.com>
This reverts commit 46e70a7c07.
Reason for revert: New asserts failing in Flutter Engine tests
Original change's description:
> Reland "[VM/Timeline] Make timestamp1_or_id variables more understandable"
>
> Relanding without changes because the cbuild failure was unrelated.
>
> TEST=Checked that duration events still looked correct in traces written
> by the Perfetto file recorder. Checked that events still looked correct
> in traces recorded to the MacOS recorder.
>
> This is a reland of commit 354e1d22cb
>
> Original change's description:
> > [VM/Timeline] Make timestamp1_or_id variables more understandable
> >
> > This CL improves documentation, and renames fields/methods to make it
> > more understandable that timestamp1 and id are stored in the same field
> > of dart::TimelineEvent (because the event types that need to store
> > timestamp1 are disjoint from the ones that need to store id).
> >
> > TEST=Checked that duration events still looked correct in traces written
> > by the Perfetto file recorder. Checked that events still looked correct
> > in traces recorded to the MacOS recorder.
> >
> > Change-Id: I25ff1f4c6cc432f035ac2be99fa7f162290ea77f
> > Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/305880
> > Reviewed-by: Ben Konyi <bkonyi@google.com>
> > Commit-Queue: Derek Xu <derekx@google.com>
>
> Change-Id: I28c0c3af9869900cc8bb2b3b416904a231d143e0
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/306301
> Reviewed-by: Ben Konyi <bkonyi@google.com>
> Commit-Queue: Derek Xu <derekx@google.com>
Change-Id: Ia1fe524268c06fd68c689fe048d8cc38a6ed8a23
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/306661
Reviewed-by: Ben Konyi <bkonyi@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Derek Xu <derekx@google.com>
Also changes pkg/native_stack_traces to return a parsed MachO file
if the MachO file doesn't contain DWARF information, so we can examine
its static symbol information for the new test.
Issue: https://github.com/flutter/flutter/issues/124715
TEST=vm/dart/unobfuscated_static_symbols
Change-Id: I07d3ced56eeba852ebe4178dfd2b66ebb899eb76
Cq-Include-Trybots: luci.dart.try:vm-aot-dwarf-linux-product-x64-try,vm-aot-linux-product-x64-try,vm-aot-linux-debug-x64-try,vm-aot-linux-release-x64-try,vm-aot-obfuscate-linux-release-x64-try,vm-aot-mac-product-arm64-try,vm-aot-mac-release-arm64-try,vm-aot-mac-release-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/305720
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Relanding without changes because the cbuild failure was unrelated.
TEST=Checked that duration events still looked correct in traces written
by the Perfetto file recorder. Checked that events still looked correct
in traces recorded to the MacOS recorder.
This is a reland of commit 354e1d22cb
Original change's description:
> [VM/Timeline] Make timestamp1_or_id variables more understandable
>
> This CL improves documentation, and renames fields/methods to make it
> more understandable that timestamp1 and id are stored in the same field
> of dart::TimelineEvent (because the event types that need to store
> timestamp1 are disjoint from the ones that need to store id).
>
> TEST=Checked that duration events still looked correct in traces written
> by the Perfetto file recorder. Checked that events still looked correct
> in traces recorded to the MacOS recorder.
>
> Change-Id: I25ff1f4c6cc432f035ac2be99fa7f162290ea77f
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/305880
> Reviewed-by: Ben Konyi <bkonyi@google.com>
> Commit-Queue: Derek Xu <derekx@google.com>
Change-Id: I28c0c3af9869900cc8bb2b3b416904a231d143e0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/306301
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Derek Xu <derekx@google.com>
This reverts commit 354e1d22cb.
Reason for revert: broke cbuild
Original change's description:
> [VM/Timeline] Make timestamp1_or_id variables more understandable
>
> This CL improves documentation, and renames fields/methods to make it
> more understandable that timestamp1 and id are stored in the same field
> of dart::TimelineEvent (because the event types that need to store
> timestamp1 are disjoint from the ones that need to store id).
>
> TEST=Checked that duration events still looked correct in traces written
> by the Perfetto file recorder. Checked that events still looked correct
> in traces recorded to the MacOS recorder.
>
> Change-Id: I25ff1f4c6cc432f035ac2be99fa7f162290ea77f
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/305880
> Reviewed-by: Ben Konyi <bkonyi@google.com>
> Commit-Queue: Derek Xu <derekx@google.com>
Change-Id: I37c74620105299c0b5e7725fd994609af177a9f8
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/306280
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Derek Xu <derekx@google.com>
This CL improves documentation, and renames fields/methods to make it
more understandable that timestamp1 and id are stored in the same field
of dart::TimelineEvent (because the event types that need to store
timestamp1 are disjoint from the ones that need to store id).
TEST=Checked that duration events still looked correct in traces written
by the Perfetto file recorder. Checked that events still looked correct
in traces recorded to the MacOS recorder.
Change-Id: I25ff1f4c6cc432f035ac2be99fa7f162290ea77f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/305880
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Derek Xu <derekx@google.com>
instead of just one ID
Sometimes the Flutter Engine is associating events with multiple flows,
this change is needed to allow events to be associated with multiple
flows in a Perfetto-format trace.
TEST=Checked the flow events reported through dart:developer still
looked correct when retrieved in Perfetto traces.
Change-Id: I2901ffde5e8b984abb1e924e014722bb0568f6d3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/305801
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Derek Xu <derekx@google.com>
TypeRef type wraps around another type and it was used to represent
a graph of recursive types. After [0], the only use of TypeRef is
for TypeParameter.bound which may indirectly reference the same
TypeParameter.
This change replaces TypeParameter.bound with TypeParameter.owner and
removes TypeRef entirely. Various parts of the VM no longer need to
handle and support TypeRefs.
TypeParameter.owner can reference a FunctionType, Class,
or, as an optimization, it can be set to null in order to share
class type parameters among different classes.
With the exception of the 'TypeParameter.owner' back pointer,
VM types are now not recursive and can be visited without
additional tracking.
Caveats:
* Generic FunctionType cannot be cloned in a shallow way:
when copying a FunctionType, type parameters should be cloned too
and their owners should be updated. For that reason,
a mapping between 'from' and 'to' function types
(FunctionTypeMapping) is maintained during type transformations
such as InstantiateFrom.
FunctionType::Clone is used instead of Object::Clone where
appropriate.
* When testing types for subtyping and equivalence, mapping
between function types is passed to make sure
type parameters belong to the equivalent function types.
* IL serializer needs to serialize function types as a whole before
serializing any types potentially pointing into the middle of a
function type (such as return type 'List<Y0>' pointing into
the middle of a function type 'List<Y0> Function<Y0>()').
[0] https://dart-review.googlesource.com/c/sdk/+/296300
TEST=ci
Change-Id: I67c2fd0117c6183a45e183919a7847fd1af70b3e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/294165
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Some cleanups factored out of a larger CL (which refactors enter/exit of threads):
* remove unused `#include "vm/thread_registry.h"`
* remove unused/unnecessary fields from [Thread] object
* rename IsMutator() -> IsDartMutator()
* make tests using setjmp() drain the sticky error
=> to ensure there's no sticky error on isolate shutdown
TEST=ci
Change-Id: I53935e8bd0628ab3768627d6d5e01c3f0e3a57ad
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296582
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
This supports flow events reported through dart:developer, but does not
support ones reported with Dart_TimelineEvent in dart_tools_api.h. That
will have to be supported in a future CL.
TEST=CI, manually verifying that flow arrows appeared on flow events in
the trace viewer for traces recorded with our Perfetto recorder
Change-Id: Ic75a8ce277b436a609c027c2c0d4e94b51031aa7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/280740
Reviewed-by: Stephen Adams <sra@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
This is a reland of commit 135443706b
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>
TEST=runtime/tests/vm/dart/regress_b_278841863_test.dart
Fixes b/278841863.
Change-Id: Ib1e20055bfb26e1df0a077300c69f0bec7152480
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296300
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Markov <alexmarkov@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>
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>
Also in this change:
- Add heap_size to Dart_HeapSamplingCreateCallback
- Remove heap_size from Dart_HeapSamplingReportCallback
TEST=Existing dart_api_impl_tests updated
Change-Id: Iaa8d340de94d95f93c94f4a3d29d6d889dad49de
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/294800
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
The only user of this API is no longer using it (see cl/519087228).
It's possible we'd re-introduce such an API in the future,
in which case we may want to:
- make it more clear what the GC times mean (are concurrent threads for
mark/sweep or parallel threads for paralell marking included,
is time in wallclock or cpu time, ...)
- include information more useful for users, such as maximum
synchronous pause times
TEST=ci
Change-Id: Idec6f1fdc406956889dd858f280dfe84bed0d10f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/291260
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Vyacheslav Egorov