This reverts commit 6194209b28.
Reason for revert: issues on arm32
Original change's description:
> [vm, gc] Mark through new-space.
>
> - Initial and final marking no longer visit all of new-space, reducing the STW pause for major GC.
> - A scavenge during concurrent marking must forward / filter objects in the marking worklist that are moved / collected, increasing the STW pause for minor GC.
> - Unreachable intergenerational cycles and weak references are collected in the next mark-sweep instead of first requiring enough scavenges to promote the whole cycle or weak target into old-space.
> - Artificial minor GCs are no longer needed to avoid memory leaks from back-to-back major GCs.
> - reachabilityBarrier is now just a count of major GCs.
>
> TEST=ci
> Change-Id: I3668a2e56821f9eadf96e38c228dab27be656016
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/309826
> Reviewed-by: Siva Annamalai <asiva@google.com>
> Commit-Queue: Ryan Macnak <rmacnak@google.com>
Change-Id: I434eb595c9e7858efc8c9b07cbca954e5649f506
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/319321
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
- Initial and final marking no longer visit all of new-space, reducing the STW pause for major GC.
- A scavenge during concurrent marking must forward / filter objects in the marking worklist that are moved / collected, increasing the STW pause for minor GC.
- Unreachable intergenerational cycles and weak references are collected in the next mark-sweep instead of first requiring enough scavenges to promote the whole cycle or weak target into old-space.
- Artificial minor GCs are no longer needed to avoid memory leaks from back-to-back major GCs.
- reachabilityBarrier is now just a count of major GCs.
TEST=ci
Change-Id: I3668a2e56821f9eadf96e38c228dab27be656016
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/309826
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
TEST=ci
Change-Id: I4277a4f4f2c3bd9dedd9e325167b67130b5afc2d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/319260
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Previously the code was using `fgets` with a fixed
size buffer. This lead to a confusing behavior where
lines longer than 255 characters would be read
in multiple chunks and cause crashes in the parsing code.
Additionally make extraction of the path component slightly
more robust by searching for path field forward rather than
backwards. Path might contain white space and searching
backwards might stumble on that.
This is a reland of 95474f44f1
with changes to android min-sdk to make android ARM builds
succeed (getline requires SDK 18+).
TEST=manually
Change-Id: I8b36fcd178680aed7f856bc884a5cd188a5f6e85
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/319480
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
The [Environment] represents 2 different things:
* before (env, deopt-id): The state of unoptimized frame right before
the IL instruction is executed
* after (env, deopt-id): The state of unoptimized frame right after
the call machine instruction instruction (i.e. which may not be
after the IL instruction - as it may still have to drop arguments)
The environment's prune-count specifies the number of entries from the
[Environment] to be removed to get from before-env to after-env.
This prune-count includes generally most of `<IR>::InputCount()` - as
most IR instructions consume their inputs (which location summary may
e.g. require in registers) before doing any call. Though it doesn't include
arguments as we currently have a stack-based calling convention and both
optimized and unoptimized code will explicitly drop them after the machine
call instruction.
Our optimizing compiler may emit speculative instructions. Those will
receive an environment that makes before (env, deopt-id) and after (env,
deopt-id) the same - as both eager and lazy deopt will target a
before (env, deopt-id).
=> We should ensure that the prune-count is set to 0, ensuring we won't
prune anything in case an IL instruction was marked with
`MarkAsLazyDeoptToBeforeDeoptId`.
=> This is a preparation for inlining force-optimized functions: If we
inline them and some callee IL instruction performs lazy deopt it should
re-try the call without any pruned inputs.
TEST=ci
Change-Id: I091c9fa962b376200dc5cfb6ea8c9a47ef43810f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/319440
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
This test is flaky and timing out on hot reload bots.
Change-Id: If0c9574ac80405d14765e4ada4fdee8e6bce9d79
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/319001
Reviewed-by: Alexander Aprelev <aam@google.com>
Auto-Submit: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Alexander Aprelev <aam@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>
If a thread owns a lock already before acquiring the safepoint
operation, it can re-acquire the same lock inside the safepoint
operation (as it's a NOP and canoot lead to deadlocks).
TEST=ci
Change-Id: I4a7c3526683e09d4408d97aca9e9b59d6ca53d19
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/318662
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
All uses of `PortMap::Create()` would call `PortMap::SetPortState()`
after creating the port. To avoid acquiring the port map lock twice, we
can initialize the state already in `PortMap::Create()`.
Additionally we fix an existing issue by making the isolate's main port
a control port (instead of leaving it as a `kNewPort`).
As a side-effect we'll no longer have any allocated ports with state
`kNewPort`.
We also remove the unused `PortMap::IsLocalPort()`
TEST=ci
Change-Id: I6198792a8e1132580b60262f10a807c5b12f9eaf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317680
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
The test generates many classes, compiles a lot of code and executs very
large function.
This is too slow under TSAN
TEST=Skip vm/cc/ManyClasses on TSAN
Change-Id: I867fe9c1d50e7e976cd0a58659464c3eada5e56c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/318640
Reviewed-by: Tess Strickland <sstrickl@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
After simplifying the handling of annotations in the kernel loader in
[0] we no longer need to use handle-based access to pragmas.
Also use bit field to represent detected pragmas.
[0] https://dart-review.googlesource.com/c/sdk/+/290502
TEST=ci
Change-Id: I2e21c9e96accce1580964e617f05e4316563b463
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/318260
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
When evaluating an expressino at a breakpoint that's inside a closure,
the closure may refer to anything it closes over. That includes the
`this` from an enclosing method.
So depending on whether a closure's parent chain is an instance method
or a static method, the expression evaluation function is going to be an
instance method or a static method.
=> We walk up the parent chain to determine the correct enclosing class.
=> This avoids making a Type object with a cid from a top-level class (see [0])
Handling this correctly will now try to get the `this` when invoking an
eval function that has an enclosing instance method. Though we may often
have "<optimized out>" the `this` (e.g. due to not capturing it in
closure context chain).
=> We still allow running the expression evaluation function in this
case, but only if the expression being evaluated doesn't access `this`.
A similar issue occurs when trying to use variables in the eval
expression that the closure didn't capture. This results in a confusing
CFE compile-time error. This is a separate issue and tracked in [1].
=> We update the test to distinuish the cases that this CL makes passing
and those that are failing due to [1].
Fixes [0] https://github.com/dart-lang/sdk/issues/53061
See also [1] https://github.com/dart-lang/sdk/issues/53087
TEST=Fixes part of service/evaluate_activation_test failures
Change-Id: I3bb24e7338c7b2f12d5340311d944cb59a455641
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317540
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This reverts commit 95474f44f1.
Reason for revert: getline seems to be missing on some platforms we target (e.g. Android).
Original change's description:
> [vm/service] Use getline to read /proc/self/smaps
>
> Previously the code was using `fgets` with a fixed
> size buffer. This lead to a confusing behavior where
> lines longer than 255 characters would be read
> in multiple chunks and cause crashes in the parsing code.
>
> Additionally make extraction of the path component slightly
> more robust by searching for path field forward rather than
> backwards. Path might contain white space and searching
> backwards might stumble on that.
>
> TEST=manually
>
> Change-Id: I1d23df4a79b04721d3a812e19eae9b8ad0e955fa
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317683
> Commit-Queue: Slava Egorov <vegorov@google.com>
> Reviewed-by: Ben Konyi <bkonyi@google.com>
Change-Id: Iaa6886f318884f9ac17487b2ab59621bb44fcb3b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317781
Auto-Submit: Slava Egorov <vegorov@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Previously the code was using `fgets` with a fixed
size buffer. This lead to a confusing behavior where
lines longer than 255 characters would be read
in multiple chunks and cause crashes in the parsing code.
Additionally make extraction of the path component slightly
more robust by searching for path field forward rather than
backwards. Path might contain white space and searching
backwards might stumble on that.
TEST=manually
Change-Id: I1d23df4a79b04721d3a812e19eae9b8ad0e955fa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317683
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Fix the service type `TypeParameters` to recognize it is a heap object.
Exhaustively test that the service client libraries can handle inflating all types produced by the VM. Compare vm/cc/PrintJSON, which exhaustively tests the VM can generate any type.
TEST=ci
Bug: https://github.com/dart-lang/sdk/issues/52893
Change-Id: Id1f080656ef6e999e69f2ebb5b9961fa3b461e4a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316862
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
When there is a shape change, class/library forwarding remains fused with the instance forwarding, and enum forwarding happens in a separate become operation.
TEST=ci
Bug: https://github.com/flutter/flutter/issues/131446
Change-Id: Iff2aacc664fbfcbc39c6aabd3698b413d18671cf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/317521
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
This renames InlineClass to ExtensionTypeDeclaration, and InlineType
to ExtensionType. Members of extension type declarations are called
extension type members instead of extension type declaration members
for "brevity".
TEST=existing
Change-Id: I91ed62533ddd345644492f04dc3310d007460288
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316780
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
This language feature allows type promotion to apply to private final
fields, e.g.:
class C {
final int? _x;
C(this._x);
}
f(C c) {
if (c._x != null) {
print(c._x.abs()); // (1)
}
}
Previously the line marked (1) would have needed to be written
`print(c._x!.abs());`.
Note that to ensure soundness, there are certain restrictions:
- Public fields don't undergo promotion (because a public field might
be overridden by a class in some other library).
- Non-final fields don't undergo promotion (because a non-final field
might be modified as a side effect of code executed between the type
test and the field's usage).
- Fields that are forwarded to `noSuchMethod` in the same library
don't undergo promotion (because there's no guarantee that
`noSuchMethod` will return the same value on every invocation). For
example:
class C {
final int? _x;
C(this._x);
}
class D implements C {
@override
noSuchMethod(...) => ...;
}
f(C c) {
if (c._x != null) {
print(c._x.abs()); // ERROR: `c._x` might dispatch to
// `D.noSuchMethod`, in which case there's
// no guarantee that it will return a
// non-null value the second time it's
// invoked.
}
}
- If two classes define fields or getters of the same name, and
promotion is not permitted for one of them, then it isn't permitted
for the other. This is because there might be a class in some other
library that's a subclass of both classes, causing a reference to
one field or getter to dispatch to the other. For example:
class C {
final int? _x;
C(this._x);
}
class D {
int? get _x => ...;
}
f(C c) {
if (c._x != null) {
print(c._x.abs()); // ERROR: `c._x` might dispatch to `D._x`
// (e.g. because some library might declare
// `class E extends D implements C`), in
// which case there's no guarantee that it
// will return a non-null value the second
// time it's invoked.
}
}
Change-Id: Ib9183581aa0194377e38ab70d37c3e9f0bb57a75
Bug: https://github.com/dart-lang/language/issues/2020
Tested: TAP global presubmit
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/314600
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This removes ExtensionType, ExtensionTypeShowHideClause and
CallSiteAccessKind from package:kernel which where only used by the now
removed 'extension-types' experiment.
A follow-up CL will rename InlineClass/InlineType to
ExtensionTypeDeclaration/ExtensionType to match the names of the
Extension Type feature currently being implemented.
TEST=existing
Change-Id: I58d2e8b0a92ac61329ee161cc6884a2c0e6f87ae
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316420
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
This change is almost trivial. The closure is stored on the callback's
RawReceivePort, not in the VM. So we can basically just remove the CFE
check and it pretty much works. The only problem is that we can't set
function.FfiCallbackTarget anymore, so most of the CL is dealing with
that.
A few places were deciding whether an FFI trampoline was a call or a
callback based on whether function.FfiCallbackTarget() was null. But
now the target will be null for async callbacks. So instead I've added
a new value to the FfiCallbackKind enum (and renamed it), and changed
those checks.
Sync callback closures will be a separate CL, because they're more
complicated.
Bug: https://github.com/dart-lang/sdk/issues/52689
Change-Id: I8e5dfb557362e679f66195b735c3c382e6792840
TEST=async_void_function_callbacks_test.dart
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316160
Commit-Queue: Liam Appelbe <liama@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Enum forwarding requires evaluating and canonicalizing the new enum instances. If these in turn refer to other instances of classes with shape changes, canonicalization may try to compare instances of the old and new shapes and dereference past the end of an object. By waiting for instance morphing to complete, canonicalization can only see instances with the new shape.
Also, don't attempt to forward Enum.values. When an enum member is added or removed, this has the same merging problem as 40442.
Cf. bad074cc49.
TEST=ci
Bug: https://github.com/flutter/flutter/issues/129177
Bug: https://github.com/dart-lang/sdk/issues/53039
Change-Id: Ib7a54db30c4d16a6ae6e1acd595dc7482134165b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316527
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
This reverts commit 6ef967fb07.
Reason for revert: https://github.com/dart-lang/sdk/issues/53039
Original change's description:
> [vm, reload] Delay enum forwarding until after instance morphing.
>
> Enum forwarding requires evaluating and canonicalizing the new enum instances. If these in turn refer to other instances of classes with shape changes, canonicalization may try to compare instances of the old and new shapes and dereference past the end of an object. By waiting for instance morphing to complete, canonicalization can only see instances with the new shape.
>
> Also, don't attempt to forward Enum.values. When an enum member is added or removed, this has the same merging problem as 40442.
>
> Cf. bad074cc49.
>
> TEST=ci
> Bug: https://github.com/flutter/flutter/issues/129177
> Change-Id: I19d0508059bade8496000eeea257bb0730f11d17
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316041
> Reviewed-by: Ben Konyi <bkonyi@google.com>
> Commit-Queue: Ryan Macnak <rmacnak@google.com>
Bug: https://github.com/flutter/flutter/issues/129177
Change-Id: I8aa09be5d8fd72460ab26294ed94a5075135d48b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316501
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Allow updating weak handles etc to happen in parallel with work-stealing.
Also make LocalBlockWorklist more symmetric with BlockWorklist.
Cf. 4495c2b30a
TEST=ci
Change-Id: Id58fe16be92028b1aa4dd8f097769b4107f2a3f0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316043
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Instead use external pointer block lists so that the same weakling can be pending for both minor and major GC at the same time. When we begin marking through new-space in major GCs, this will need to happen for weaklings in new-space. Once the pending lists are independent, it is easy to handle the reverse case. This also improves the promptness with which old-space weaklings with unreachable new-space targets are clear.
TEST=ci
Change-Id: I46a0a78eeae0210caad48a162c8d64a9af79e749
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/314863
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Enum forwarding requires evaluating and canonicalizing the new enum instances. If these in turn refer to other instances of classes with shape changes, canonicalization may try to compare instances of the old and new shapes and dereference past the end of an object. By waiting for instance morphing to complete, canonicalization can only see instances with the new shape.
Also, don't attempt to forward Enum.values. When an enum member is added or removed, this has the same merging problem as 40442.
Cf. bad074cc49.
TEST=ci
Bug: https://github.com/flutter/flutter/issues/129177
Change-Id: I19d0508059bade8496000eeea257bb0730f11d17
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316041
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Tested: CQ
Change-Id: I16210697b47dd85aec8743b457e773b044cab81f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316200
Reviewed-by: William Hesse <whesse@google.com>
Commit-Queue: Alexander Thomas <athom@google.com>
Whether the reordered objects fail to fit depends non-deterministically on the parallel worker speeds and the exact contents of new-space that vary with each VM or core library change.
Bug: https://github.com/dart-lang/sdk/issues/52936
Change-Id: I6e287d42b5ca77d2ffafd9a5a053118617d6fe51
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/313940
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Also
* Make C++ offset_extractor binaries emit entire if/def condition
(including product vs non-product)
=> This makes it much nicer to look up offsets, as the preceding
#if condition will be the whole condition.
* Run the builds & offset extractions in parallel
This will make it easier to extend the cross product of our
configurations that require different offsets (e.g. sanitizers)
TEST=Manually run.
Change-Id: I458deb7a1c9403ab3624dd6b6ca51df72d6a6b28
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/312442
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Tess Strickland <sstrickl@google.com>
The change in [0] has propagated now everywhere, so we can use
`utf8.encode()` instead of the longer `const Utf8Encoder.convert()`.
As the checked-in SDK has been rolled to include [0] we can now rely on
the better return type.
[0] https://github.com/dart-lang/sdk/issues/52801
TEST=ci
CoreLibraryReviewExempt: Minor cleanup.
Change-Id: I2c0144023e03b2c265582d83a7fb9469b02f1570
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/313563
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
