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>
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>
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>
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 current hot-reload implementation [0] will perform a reload by
first sending OOB messages to all isolates and waiting until those OOB
messages are being handled. The handler of the OOB message will block
the thread (and unschedule isolate) and notify the thread performing
reload it's ready.
This requires that all isolates within a group can actually run & block.
This is the case for the VM implementation of isolates (as they are
run an unlimited size thread pool).
Though flutter seems to multiplex several engine isolates on the same OS
thread. Reloading can then result in one engine isolate performing
reload waiting for another to act on the OOB message (which it will not
do as it's multiplexed on the same thread as the former).
Now that we have a more flexible safepointing mechanism (introduced in
[1]) we can utilize for hot reloading by introducing a new "reloading"
safepoint level.
Reload safepoints
-----------------------
We introduce a new safepoint level (SafepointLevel::kGCAndDeoptAndReload).
Being at a "reload safepoint" implies being at a "deopt safepoint"
which implies being at a "gc safepoint".
Code has to explicitly opt-into making safepoint checks participate /
check into "reload safepoints" using [ReloadParticipationScope]. We do
that at certain well-defined places where reload is possible (e.g. event
loop boundaries, descheduling of isolates, OOM message processing, ...).
While running under [NoReloadScope] we disable checking into "reload
safepoints".
Initiator of hot-reload
-----------------------
When a mutator initiates a reload operation (e.g. as part of a
`ReloadSources` `vm-service` API call) it will use a
[ReloadSafepointOperationScope] to get all other mutators to a
safepoint.
For mutators that aren't already at a "reload safepoint", we'll
notify them via an OOB message (instead of scheduling kVMInterrupt).
While waiting for all mutators to check into a "reload safepoint", the
thread is itself at a safepoint (as other mutators may perform lower
level safepoint operations - e.g. GC, Deopt, ...)
Once all mutators are at a "reload safepoint" the thread will take
ownership of all safepoint levels.
Other mutators
-----------------------
Mutators can be at a "reload safepoint" already (e.g. isolate is not
scheduled). If they try to exit safepoint they will block until the
reload operation is finished.
Mutators that are not at a "reload safepoint" (e.g. executing Dart or VM
code) will be sent an OOB message indicating it should check into a
"reload safepoint". We assume mutators make progress until they can
process OOB message.
Mutators may run under a [NoReloadScope] when handling the OOM message.
In that case they will not check into the "reload safepoint" and simply
ignore the message. To ensure the thread will eventually check-in,
we'll make the destructor of [~NoReloadScope] check & send itself a new OOB
message indicating reload should happen. Eventually getting the mutator
to process the OOM message (which is a well-defined place where we can
check into the reload safepoint).
Non-isolate mutators such as the background compiler do not react to OOB
messages. This means that either those mutators have to be stopped (e.g.
bg compiler) before initiating a reload safepoint operation, the
threads have to explicitly opt-into participating in reload safepoints
or the threads have to deschedule themselves eventually.
Misc
----
Owning a reload safepoint operation implies also owning the deopt &
gc safepoint operation. Yet some code would like to ensure it actually
runs under a [DeoptSafepointOperatoinScope]/[GCSafepointOperationScope].
=> The `Thread::OwnsGCSafepoint()` handles that.
While performing hot-reload we may exercise common code (e.g. kernel
loader, ...) that acquires safepoint locks. Normally it's disallows to
acquire safepoint locks while holding a safepoint operation (since
mutators may be stopped at places where they hold locks, creating
deadlock scenarios).
=> We explicitly opt code into participating in reload safepointing
requests. Those well-defined places aren't holding safepoint locks.
=> The `Thread::CanAcquireSafepointLocks()` will return `true` despite
owning a reload operation. (But if one also holds deopt/gc safepoint
operation it will return false)
Example where this matters: As part of hot-reload, we load kernel which
may create new symbols. The symbol creation code may acquire the symbol
lock and `InsertNewOrGet()` a symbol. This is safe as other mutators
don't hold the symbol lock at reload safepoints. The same cannot be said
for Deopt/GC safepoint operations - as they can interrupt code at many
more places where there's no guarantee that no locks are held.
[0] https://dart-review.googlesource.com/c/sdk/+/187461
[1] https://dart-review.googlesource.com/c/sdk/+/196927
Issue https://github.com/flutter/flutter/issues/124546
TEST=Newly added Reload_* tests.
Change-Id: I6842d7d2b284d043cc047fd702b7c5c7dd1fa3c5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296183
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
The sweeper threads are bypassing safepoints and have no need for normal
mutator state (e.g. storebuffer, marking stacks, .,..) on the [Thread]
object.
This fixes a TSAN report where sweeper would clear reusable handles
(which it didn't actually modify) and scavenger is reading those
handles (which arguably it doesn't have to either).
Issue https://github.com/dart-lang/sdk/issues/52125
TEST=ci
Change-Id: I03a36e8518b6c00eb7f3b57f65fd469dddba23e0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296860
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
An embedder (or the VM) can exit an isolate via `Thread::ExitIsolate()`
at a point where there's still active state (e.g. dart frames).
Because of this the VM has so far conservatively retained the [Thread]
object of dart mutators throughout the isolate's lifetime. After which
is was manually `delete`ed. We'd never re-use those [Thread] objects (we
do re-use [Thread] objects of non-dart-mutator threads).
When exiting via `Thread::ExitIsolate()` with active state, the mutator
was assumed to be at-safepoint at all levels. It was removed from the
thread registry's active threads. This also means that when e.g. GC runs
it can't use the thread registry to find all active threads it may
need to scan, instead it uses [Isolate::mutator_thread_] of all isolates.
This causes a variety of subtle issues, but the main one that motivated
this change is the following:
If a thread obtains a safepoint operation it means all other mutators
are parked. The thread owning the safepoint can do whatever it likes.
When introducing reload operation safepoints, a thread may want to
ReloadSafepointOperation reload(thread);
...
// Compile sources.
{
TransitionVMToNative transition(thread);
// Will temporarily exit & re-enter current isolate.
response_port = Dart_NewNativePort();
Dart_PostCObject(kernel_isolate_port, ...);
// Wait on [response_port] for response.
}
This will cause the reloading thread to own the reload safepoint
operation but still transition states and even exit/re-enter the
isolate. Though this is currently not possible in the way enter/exit is
implemented.
So we'll refactor this fragile code in the following way:
* Move thread enter/exit logic entirely to the [Thread] object.
* Keep used threads in the thread registry's active list.
=> This allows us to keep various state on the [Thread] and thereby
avoids clearing it when suspending & re-initialing it when resuming
=> It makes nested `Thread::ExitIsolate()` faster as we mainly have
to enter safepoint (avoid acquiring threads lock, avoid releasing
storebuffers, ...)
=> It makes nested `Thread::EnterIsolate()` faster as we mainly have
to leave the safepoint (avoid acquiring threads lock, avoid acquiring
storebuffers, ...).
=> A mutator can now own a safepoint operation (e.g. reload safepoint
operation) and still `ExitSafepoint()` / `EnterSafepoint()` safely -
as those are based on the normal `EnterSafepoint()` and
`LeaveSafepoint()` APIs.
* We separate
- Suspend & Resume of a dart mutator (possibly with active stack)
- Setup & Reset of state only relevant for dart mutators
- Setup & Reset of state relevant for any mutator
* We unify how the [Thread] objects are freed between dart mutator and
non-dart mutators: [Thread] objects without state can be given back to
the [ThreadRegistry] and re-used (instead of being deleted in
`Isolate::~Isolate`)
* We have capability to free [Thread] objects if a dart mutator has an
empty stack & re-use for another isolate of the same group.
(In future we may have N Thread objects for N cores and the threads
would even maintain their TLABs when switching between isolates)
* Since we allow reusing of [Thread] objects also for dart mutators now,
we have extensive asserts to ensure they are "clean" when they get
into the free list and come out "clean" again.
TEST=ci
Change-Id: Id85e8e484efd98d28e323b33795716420e619986
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296585
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
The latter will factor into a page's alignment offset.
TEST=ci
Change-Id: Iee5117efb3278399e0fd09b21ea92eadc8237296
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/263680
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Ryan Macnak <rmacnak@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>
TEST=Loaded the response from a getPerfettoVMTimeline request in the
Perfetto trace viewer and made sure everything looked correct.
Change-Id: I8d4bc35fb36601701976c28653db92b2161e4724
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/288066
Commit-Queue: Derek Xu <derekx@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
TEST=Manually verified that the modified CLI options worked as expected, CI
Change-Id: Ibaa308e5c9c3b96c939e2007ee2eaaca30eae280
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/288063
Reviewed-by: Ben Konyi <bkonyi@google.com>
This CL removes the packet_ member in TimelineEventPerfettoFileRecorder
and adds a packet_ member to TimelineEventRecorder. This member will be
used when sending Perfetto traces through the VM Service.
TEST=manually verified that traces recorded with the Perfetto file
recorder still contained correct information, CI
Change-Id: I796369ea0832c265a04e37d91bc09f93967979a8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/288061
Reviewed-by: Ben Konyi <bkonyi@google.com>
This will allow us to reuse the shared logic when returning Perfetto
traces through the service. This CL also changes some pointer parameters
to const reference parameters.
TEST=manually verified that traces recorded with the JSON file
recorder still contained correct information, CI
Change-Id: I70ac5183959dd8c6efeb55d4891a8e00d3550ca5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/288060
Reviewed-by: Ben Konyi <bkonyi@google.com>
TEST=manually verified that traces recorded with the Perfetto file
recorder still contained correct information, CI
Change-Id: I4bd132dd9e703274ffc262eb7e000e6ee6df4bf8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/287923
Reviewed-by: Ben Konyi <bkonyi@google.com>
TEST=manually verified that traces recorded with the Perfetto file
recorder had correct async track names, CI
Change-Id: Icca1b92d164299140565972b4be8c6c9b7338159
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/288021
Reviewed-by: Ben Konyi <bkonyi@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>
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>
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>
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>
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>
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>
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>
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>
These are params of the "library_for_all_configs" template, and I
believe they should also be params of
"library_for_all_configs_with_compiler".
Change-Id: I9fe959a98a9a1d0ebd2bea8f0959bcba4fc794ee
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/295420
Commit-Queue: Derek Xu <derekx@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
The "dart_maybe_product_config" and "dart_product_config" configs in
runtime/BUILD.gn have logic to avoid building PRODUCT artifacts in debug builds.
"library_for_all_configs" should account for this and include
extra_nonproduct_deps in debug builds even when conf.is_product is true.
Change-Id: I98a6e35fcb6f90b751d2c98f35c70ded04990b92
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/295120
Commit-Queue: Derek Xu <derekx@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
For applications that want to have arbitrary number of isolates call
into native code that may be blocking, we expose the API functions that
allows those native threads to exit an isolate before running
long/blocking code.
Without the ability to exit/re-enter isolate, one may experience
deadlocks as we have a fixed limit on the number of concurrently
executing isolates atm.
In the longer term we may find a way to do this automatically
with low overhead, see [0]. But since those API functions are quite
stable and we already expose e.g. `Dart_{Enter,Exit}Scope`, I don't
see a reason not to expose `Dart_{Enter,Exit}Isolate`.
Difference to original CL:
Do use STL synchronization primitives (as the ones in runtime/bin
are not always available in shared libraries)
[0] Issue https://github.com/dart-lang/sdk/issues/51261
Issue https://github.com/dart-lang/sdk/issues/51254
TEST=ffi{,_2}/dl_api_exit_enter_isolate_test
Change-Id: Id817e8d4edb3db35f029248d62388cbd0682001d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/294980
Reviewed-by: Daco Harkes <dacoharkes@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>
This reverts commit a2512819f8.
Reason for revert: FFI tests fail to link on Windows, fail to load on product-mode Android
Original change's description:
> [vm] Expose Dart_{CurrentIsolate,ExitIsolate,EnterIsolate}
>
> For applications that want to have arbitrary number of isolates call
> into native code that may be blocking, we expose the API functions that
> allows those native threads to exit an isolate before running
> long/blocking code.
>
> Without the ability to exit/re-enter isolate, one may experience
> deadlocks as we have a fixed limit on the number of concurrently
> executing isolates atm.
>
> In the longer term we may find a way to do this automatically
> with low overhead, see [0]. But since those API functions are quite
> stable and we already expose e.g. `Dart_{Enter,Exit}Scope`, I don't
> see a reason not to expose `Dart_{Enter,Exit}Isolate`.
>
> [0] Issue https://github.com/dart-lang/sdk/issues/51261
>
> Issue https://github.com/dart-lang/sdk/issues/51254
>
> TEST=ffi{,_2}/dl_api_exit_enter_isolate_test
>
> Change-Id: I91c772ca962fddb87919663fea07939a498fa205
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/292722
> Commit-Queue: Martin Kustermann <kustermann@google.com>
> Reviewed-by: Daco Harkes <dacoharkes@google.com>
> Reviewed-by: Ryan Macnak <rmacnak@google.com>
Change-Id: I05ad5b9ce24754a68693160e470f8eb71a812c75
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/294860
Auto-Submit: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Change-Id: Icf489686d790be195e37db37727782227d2f3704
TEST=Version bump autogenerated by scripts
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/294600
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: William Hesse <whesse@google.com>
For applications that want to have arbitrary number of isolates call
into native code that may be blocking, we expose the API functions that
allows those native threads to exit an isolate before running
long/blocking code.
Without the ability to exit/re-enter isolate, one may experience
deadlocks as we have a fixed limit on the number of concurrently
executing isolates atm.
In the longer term we may find a way to do this automatically
with low overhead, see [0]. But since those API functions are quite
stable and we already expose e.g. `Dart_{Enter,Exit}Scope`, I don't
see a reason not to expose `Dart_{Enter,Exit}Isolate`.
[0] Issue https://github.com/dart-lang/sdk/issues/51261
Issue https://github.com/dart-lang/sdk/issues/51254
TEST=ffi{,_2}/dl_api_exit_enter_isolate_test
Change-Id: I91c772ca962fddb87919663fea07939a498fa205
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/292722
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Tested: No tests. Removing functionality, all existing tests running is a success.
Change-Id: I25eb84347e1d133d465671223f4d3b037116c5e7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/294241
Reviewed-by: Liam Appelbe <liama@google.com>
Auto-Submit: Lasse Nielsen <lrn@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Kevin Chisholm <kevinjchisholm@google.com>
Reviewed-by: Kevin Moore <kevmoo@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
This reduces code size ~10k, but more importantly it is easier to read profiling results without duplicate entries.
TEST=ci
Change-Id: I14c4a0d78d856242c5493df6de629ce048753c38
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/294440
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Liam Appelbe <liama@google.com>
Unfortunately we cannot enable -Wzero-as-null-pointer-constant because of zlib and icu headers we include.
TEST=build
Change-Id: I9ffd7d7e26f2b3dd616ce54d164b92e60a2366dc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/293882
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
This change adds x64 unwinding information for generated code allowing Windows to actually call registered unhandled exception filters(Crashpad or dart-builtin crash handler).
BUG=https://github.com/dart-lang/sdk/issues/51726
TEST=ffi\ffi_induce_a_crash_test.dart
Change-Id: I1d9dd208f2c030b51a1146afa1048d419847fef7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/294129
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
TryCatchOptimizer pass reasonably expects for all MayThrow instructions
to have environment. AllocateSmallRecord instruction which is inserted
when boxing an unboxed record result of a call didn't have environment,
which caused crash in TryCatchOptimizer.
The fix is to copy the environment from a call instruction when
inserting AllocateSmallRecord.
TEST=runtime/tests/vm/dart/records_return_value_unboxing_il_test.dart
Fixes https://github.com/dart-lang/sdk/issues/51972
Cq-Include-Trybots: luci.dart.try:vm-aot-linux-release-x64-try
Change-Id: I5b7a097329ee10638eeba2ab0d4eb2f272afebc5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/293966
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Also adds `firstOrNull`, `lastOrNull`, `singleOrNull`, and `elementAtOrNull`.
I chose `nonNulls` instead of `whereNotNull()`.
The latter should have been a getter, but isn't.
Making it a getter in the platform libraries would be confusing,
and make migrating from `package:collection`'s function harder,
so instead I gave it a completely new name.
The alternative would be to retain the non-idiomatic `whereNotNull()`
for familiarity. But then it would be tool late to fix.
Fixes#49928
BUG= https://github.com/dart-lang/sdk/issues/49928
CoreLibraryReviewExempt: Everybody's on vacation, everybody everywhere.
Change-Id: If464e3bd6bc97cbeefc3e5084b4cbaadac3f1e95
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/290760
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Makes `Iterable` a mixin class with a `const` constructor,
and `IterableBase` and `IterableMixin` (to-be-deprecated) aliases
for it.
Combining everything in one place avoids (some) code
duplication.
Also gave the methods a quick overhaul for formatting,
removing uses of `late` and unnecessary element accesses,
and some general tweaks.
CoreLibraryReviewExempt: Refactoring of redundant types.
Tested: Refactoring. If existing tests work, it works.
Change-Id: Ie49a88f713d386d2d118c53606a71bdd50e1eb11
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/287600
Reviewed-by: Brian Quinlan <bquinlan@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
With the addition of records, it now makes sense to create an API
for parallelizing of futures of different types, like `Future.wait`
does for collections of same-typed futures.
The `wait` getters here apply to tuples of 2-9 futures of distinct types, which should be enough for most reasonable uses.
Planned addition for Dart 3.0.
CoreLibraryReviewExempt: Everybody's on vacation, everybody everywhere.
Change-Id: Iaa814e02e2274082bb8a29b9a18b4930bcc953bb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/288903
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Pure interfaces made `interface`s
implementation classes which cannot/should not be extended made `final`.
A class like `HasHMap` which provides the `Map` interface,
and no implementation except factory constructors
for internal implementations, is made `final`.
Unified {List,Set,Map}{Base,Mixin} into their `Base` class.
Deprecations are retained in comments for now, to be landed
separately. Search for '// TODO: @Deprecated'.
Tested: No new test, only adding restrictions on use.
CoreLibraryReviewExempt: Everybody's on vacation, everybody everywhere.
Change-Id: Ia83b8a3bb20b5b214546b328d4492de6658253db
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/288240
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Previously, a type with known cid was immediately selected, even
if another type also has a known cid. Now, if cids match, the static
types are also compared. This is useful for record types, because
static record type is more accurate than known kRecordCid.
TEST=vm/dart/records_field_operations_il_test
Issue: https://github.com/dart-lang/sdk/issues/51637
Cq-Include-Trybots: luci.dart.try:vm-aot-linux-release-x64-try,vm-aot-linux-debug-x64-try
Change-Id: I4e528d80a355a79d428bf3f03212c5a65af0b661
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/292983
Auto-Submit: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This is used only for the architecture-independent CodeRelocator_OutOfRange tests, never in real programs.
TEST=ci
Bug: https://github.com/dart-lang/sdk/issues/48333
Change-Id: Ia79a86a867117a3889caac11f88ded1abadb5329
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/292204
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This API can be used by app developers that want to diagnose high
memory consumption by dumping state of Dart VM heap at specific
points in their apps code and later analyzing those dumps offline
(e.g. using the tool in `<sdk>/runtime/tools/heapsnapshot`).
TEST=Existing test suite.
Change-Id: I04de6ba564f7b9eaf8b59d41fc4b3ec35ce8d2e5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/279972
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Michael Thomsen <mit@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Reviewed-by: Jacob Richman <jacobr@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
There are currently users that implement classes (e.g. for mocking
purposes) that implement/extend NativeFieldWrappers and send such
objects across isolates.
This CL ensures such mocks can be sent across isolates again (which was
disabled in breaking change in [0]) as long as mocks do not extend NFW
(and therefore have actual native fields).
In the future the [NativeFieldWrapperClass]s will be marked as `base`
and therefore prevent implementing them, see issue [1].
=> At this point this CL can be reverted again.
[0] https://dart-review.googlesource.com/c/sdk/+/289027
[1] https://github.com/dart-lang/sdk/issues/51896
TEST=adjusted isolate tests
Change-Id: I5fe1110e7046761e3606927063d3ad5e2b4bf4e0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/292320
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
This is another reland of 4f8333e80e.
Third time is the charm.
CoreLibraryReviewExempt: Reland of accepted CL.
Change-Id: I4ea8326af91c168b044d252162571d3fe697e4b0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/289826
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
- Mostly restores the pre-kernel behavior, except that actual arguments are not passed to the NoSuchMethodError.
- Instead of a vague error message, the call site whose target is missing is now part of the stack trace and the name/kind of the missing target is part of the exception message.
- If the missing target is on a branch not taken, things properly succeed.
TEST=ci
Bug: https://github.com/dart-lang/sdk/issues/37517
Bug: https://github.com/flutter/flutter/issues/122626
Change-Id: Ic3d5a386caa8d1627d8452a5601bc728ad519987
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/291055
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
