Previously, when initializing from dill, if the dill we initialize from
has a macro in it (and we don't remove it because of invalidation) the
macro system would think it was a precompiled dill and thus not compile
it as something it could use for running macros. Then when it tried
to use it, it would figure out it didn't have it (and crash).
This CL fixes the issue by reworking the logic:
* Assume the platform is there (dart: uris)
* Assume the uris given specifically as precompiled (and not removed
because of invalidation in/by the incremental compiler) is there.
No tests are added, but it has been manually tested in flutter.
Change-Id: Ica6c4f2f0601334d50beccdd7cf9d5740e611384
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/239026
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This CL implements `NativeFinalizer` in the GC.
`FinalizerEntry`s are extended to track `external_size` and in which
`Heap::Space` the finalizable value is.
On attaching a native finalizer, the external size is added to the
relevant heap. When the finalizable value is promoted from new to old
space, the external size is promoted as well. And when a native
finalizer is run or is detached, the external size is removed from the
relevant heap again.
In contrast to Dart `Finalizer`s, `NativeFinalizer`s are run on isolate
shutdown.
When the `NativeFinalizer`s themselves are collected, the finalizers are
not run. Users should stick the native finalizer in a global variable to
ensure finalization. We will revisit this design when we add send and
exit support, because there is a design space to explore what to do in
that case. This current solution promises the least to users.
In this implementation native finalizers have a Dart entry to clean up
the entries from the `all_entries` field of the finalizer. We should
consider using another data structure that avoids the need for this Dart
entry. See the TODO left in the code.
Bug: https://github.com/dart-lang/sdk/issues/47777
TEST=runtime/tests/vm/dart(_2)/isolates/fast_object_copy_test.dart
TEST=runtime/vm/object_test.cc
TEST=tests/ffi(_2)/vmspecific_native_finalizer_*
Change-Id: I8f594c80c3c344ad83e1f2de10de028eb8456121
Cq-Include-Trybots: luci.dart.try:vm-kernel-reload-rollback-linux-debug-x64-try,vm-kernel-reload-linux-debug-x64-try,vm-ffi-android-debug-arm64c-try,dart-sdk-mac-arm64-try,vm-kernel-mac-release-arm64-try,pkg-mac-release-arm64-try,vm-kernel-precomp-nnbd-mac-release-arm64-try,vm-kernel-win-debug-x64c-try,vm-kernel-win-debug-x64-try,vm-kernel-precomp-win-debug-x64c-try,vm-kernel-nnbd-win-release-ia32-try,vm-ffi-android-debug-arm-try,vm-precomp-ffi-qemu-linux-release-arm-try,vm-kernel-mac-debug-x64-try,vm-kernel-nnbd-mac-debug-x64-try,vm-kernel-nnbd-linux-debug-ia32-try,benchmark-linux-try,flutter-frontend-try,pkg-linux-debug-try,vm-kernel-asan-linux-release-x64-try,vm-kernel-gcc-linux-try,vm-kernel-optcounter-threshold-linux-release-x64-try,vm-kernel-precomp-linux-debug-simarm_x64-try,vm-kernel-precomp-obfuscate-linux-release-x64-try,vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-linux-debug-x64c-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/236320
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
The order of operations for type inference of a generic invocation is
now:
1. Create some constraints on type parameters by trying to match the
return type of the invocation target as a subtype of the incoming
type context. (For a constructor invocation, the return type of
the invocation target is considered the raw uninstantiated type of
the class enclosing the constructor declaration.)
2. Downwards inference: partially solve the set of type constraints
accumulated in step 1, to produce a preliminary mapping of type
parameters to type schemas.
3. Recursively infer all arguments to the invocation, except that if
experimental feature `inference-update-1` is enabled, skip any
arguments that are function literals (a.k.a. "closures"). Obtain
the type contexts for the recursive inference by substituting the
preliminary mapping (from step 2) into the corresponding parameter
types of the invocation target. For each argument that is
recursively inferred, create additional constraints on type
parameters using the resulting static type.
4. If no arguments were skipped during step 3, go to step 7 (this
always happens if `inference-update-1` is disabled).
5. Horizontal inference: partially solve the set of type constraints
accumulated so far, to produce an updated preliminary mapping of
type parameters to type schemas.
6. Recursively infer all of the invocation arguments that were
previously skipped. As in step 3, obtain the type contexts for the
recursive inference by substituting the preliminary mapping (this
time from step 5) into the corresponding parameter types of the
invocation target. Again, for each argument that is recursively
inferred, create additional constraints on type parameters using
the resulting static type.
7. Upwards inference: solve the set of type constraints accumulated so
far, to produce a final mapping of type parameters to types. Check
that each type is a subtype of the bound of its corresponding type
parameter.
8. Check that the static type of each argument is assignable to the
type obtained by substituting the final mapping (from step 7) into
the corresponding parameter type of the invocation target.
9. Finally, obtain the static type of the invocation by substituting
the final mapping (from step 7) into the return type of the
invocation target.
This addresses simpler cases of
https://github.com/dart-lang/language/issues/731. Note that if
experimental flag `inference-update-1` is disabled, the behavior is
unchanged.
Note that steps 2 and 5 use the same algorithm as each other (they
only differ in how many type constraints have been accumulated so
far), so I've renamed the function that performs it from
`downwardsInfer` to `partialInfer`.
Change-Id: I10d3288d4f4ba9e2b6bc18409186ddc67ca2ee9d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/238881
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The test harness wasn't waiting on `CliAppFixture.onAppStarted` which
could cause an unhandled exception if the test cleanup started before
the target application finished initializing. This typically only
occurred while the test was running on a machine under load.
Fixes https://github.com/dart-lang/sdk/issues/48669
TEST=Locally while running under load (e.g., `stress -c 72`)
Change-Id: Ieb67e46f62c33101490899440574fb57fc0f8882
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/238922
Reviewed-by: Kenzie Davisson <kenzieschmoll@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
In order to address https://github.com/dart-lang/language/issues/731
(improved type inference for `fold` etc.) we're going to need to
sometimes defer analysis of invocation arguments that are closures, so
that closure parameters can have their types inferred based on other
parameters. To avoid annoying the user with inconsistent behaviors,
we defer analysis of closures in all circumstances, even if it's not
necessary to do so for type inference purposes.
This has a minor user-visible effect: if an invocation contains some
closures and some non-closures, any demotions that happen due to write
captures in the closures are postponed until the end of the
invocation; this means that the write-captured variables remain
promoted for other invocation arguments, even if those arguments
appear after the closure. This is safe because there is no way for
the closure to be called until after all of the other invocation
arguments are evaluated. See the language tests in this CL for
details.
Note that this change only has an effect when the experimental feature
`inference-update-1` is enabled.
Change-Id: I283fc5eb07af2aeca0a06d523011d8c4617fbad7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/237720
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Original CL in patchset 1.
Split-off https://dart-review.googlesource.com/c/sdk/+/238341
And pulled in fix https://dart-review.googlesource.com/c/sdk/+/238582
(Should merge cleanly when this lands later.)
This CL implements the `Finalizer` in the GC.
The GC is specially aware of two types of objects for the purposes of
running finalizers.
1) `FinalizerEntry`
2) `Finalizer` (`FinalizerBase`, `_FinalizerImpl`)
A `FinalizerEntry` contains the `value`, the optional `detach` key, and
the `token`, and a reference to the `finalizer`.
An entry only holds on weakly to the value, detach key, and finalizer.
(Similar to how `WeakReference` only holds on weakly to target).
A `Finalizer` contains all entries, a list of entries of which the value
is collected, and a reference to the isolate.
When a the value of an entry is GCed, the enry is added over to the
collected list.
If any entry is moved to the collected list, a message is sent that
invokes the finalizer to call the callback on all entries in that list.
When a finalizer is detached by the user, the entry token is set to the
entry itself and is removed from the all entries set.
This ensures that if the entry was already moved to the collected list,
the finalizer is not executed.
To speed up detaching, we use a weak map from detach keys to list of
entries. This ensures entries can be GCed.
Both the scavenger and marker tasks process finalizer entries in
parallel.
Parallel tasks use an atomic exchange on the head of the collected
entries list, ensuring no entries get lost.
The mutator thread is guaranteed to be stopped when processing entries.
This ensures that we do not need barriers for moving entries into the
finalizers collected list.
Dart reads and replaces the collected entries list also with an atomic
exchange, ensuring the GC doesn't run in between a load/store.
When a finalizer gets posted a message to process finalized objects, it
is being kept alive by the message.
An alternative design would be to pre-allocate a `WeakReference` in the
finalizer pointing to the finalizer, and send that itself.
This would be at the cost of an extra object.
Send and exit is not supported in this CL, support will be added in a
follow up CL. Trying to send will throw.
Bug: https://github.com/dart-lang/sdk/issues/47777
TEST=runtime/tests/vm/dart/finalizer/*
TEST=runtime/tests/vm/dart_2/isolates/fast_object_copy_test.dart
TEST=runtime/vm/object_test.cc
Change-Id: Ibdfeadc16d5d69ade50aae5b9f794284c4c4dbab
Cq-Include-Trybots: luci.dart.try:vm-kernel-reload-rollback-linux-debug-x64-try,vm-kernel-reload-linux-debug-x64-try,vm-ffi-android-debug-arm64c-try,dart-sdk-mac-arm64-try,vm-kernel-mac-release-arm64-try,pkg-mac-release-arm64-try,vm-kernel-precomp-nnbd-mac-release-arm64-try,vm-kernel-win-debug-x64c-try,vm-kernel-win-debug-x64-try,vm-kernel-precomp-win-debug-x64c-try,vm-kernel-nnbd-win-release-ia32-try,vm-ffi-android-debug-arm-try,vm-precomp-ffi-qemu-linux-release-arm-try,vm-kernel-mac-debug-x64-try,vm-kernel-nnbd-mac-debug-x64-try,vm-kernel-nnbd-linux-debug-ia32-try,benchmark-linux-try,flutter-analyze-try,flutter-frontend-try,pkg-linux-debug-try,vm-kernel-asan-linux-release-x64-try,vm-kernel-gcc-linux-try,vm-kernel-optcounter-threshold-linux-release-x64-try,vm-kernel-precomp-linux-debug-simarm_x64-try,vm-kernel-precomp-obfuscate-linux-release-x64-try,vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-linux-debug-x64c-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/238086
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
We must load the class id from the instance prior to _each_
subtype range check, as GenerateCidRangesCheck can clobber that
register during the check.
TEST=Manually tested by @dcharkes using repro from CL 238480.
Will add regression test on separate CL.
Change-Id: I1de6f4fdd9011f241d785082b4b4866d8b24fcfb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/238582
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
This allows us to avoid some redundant computation (we don't have to
match up arguments to the corresponding parameters twice). It also
paves the way for supporting improved type inference of `fold`
(https://github.com/dart-lang/language/issues/731) because it will
allow us to resolve some arguments (gathering more constraints), then
compute a new set of inferred types, then resolve more arguments, and
so on, rather than forcing us to do all the constraint gathering at
the end.
Change-Id: I67d8b8228390ced14281145a4614f66c8e3c7e73
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/238622
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
In the process, I removed 'useFastaParser' from both the public API and
the implementation class. I also removed 'enableTiming' from the public
API.
The other getters were left because they seem like reasonable options
for plugins to want to query. If you disagree, we can address them in a
future CL.
Change-Id: Ia5630b71190dd68bcd66199baa0c05846fcc37b8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/238661
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Rename DataSource -> DataSourceReader and SourceReader -> DataSource to more accurately reflect these classes' new roles. 'Writer' and 'Reader' are used for the higher level class that composes serialization operations. The 'Sink' and 'Source' handle the low-level conversions to/from the storage format.
Change-Id: I384b5f134beb040676f8e1ef4fba056e0c40358f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/238243
Reviewed-by: Joshua Litt <joshualitt@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
Copy comments from original interfaces to new DataSink and DataSource and organize methods based on original interface.
Note: If the reorganization makes the diff on this too complicated I can just add the comments and leave in the order it was in.
Change-Id: I959ae19d80ad330ef67334effb8aad8661689937
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/238242
Reviewed-by: Joshua Litt <joshualitt@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Move DataSource/DataSink to implement serialization via composition rather than inheritance taking simple interfaces that do low-level writes/reads.
Note: Names and locations of classes will change throughout the next several CLs.
Change-Id: I04807d64a1238b42308ec93e5b5dda6ef2101c00
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/238241
Reviewed-by: Joshua Litt <joshualitt@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Combine AbstractData(Source/Sink) and Data(Source/Sink) into a single class. This simplifies the inheritance hierarchy before switching to a composition structure.
Note: Names of classes will change throughout the next several CLs and comments from the interface get added back in here:
https://dart-review.googlesource.com/c/sdk/+/238242
Change-Id: I50597e04f5b18a1150da4822c4886d12896bed8f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/238240
Reviewed-by: Joshua Litt <joshualitt@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Copy mixin logic into AbstractSink/AbstractSource classes since these are the only usages of the mixins.
Note: Names and locations of classes will change throughout the next several CLs.
Change-Id: Ie154741a83c3488a098f3ebf5cf340f19a1a9c52
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/238220
Reviewed-by: Joshua Litt <joshualitt@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Johnni Winther