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>
This is a revert of b6bbfff8c0c6c44cdab0d7d78 which temporarily disabled
this.
Turns out that a non-TSAN gen_snapshot would - when emitting code via
`Assembler::TsanLoadAcquire` - use an incorrect `Thread`-offset:
It calculated the offset via `Thread::OffsetFromThread`. That function
took a `dart::RuntimeEntry*` and tried to find its offset.
We happen to have the following leaf runtime entries:
#define LEAF_RUNTIME_ENTRY_LIST(V)
...
V(void, MsanUnpoison, void*, size_t)
V(void, MsanUnpoisonParam, size_t)
V(void, TsanLoadAcquire, void*)
V(void, TsanStoreRelease, void*)
...
It loops over all runtime entries and finds the first one that has the
identical `dart::RuntimeEntry::function_` pointer.
Though all 4 of them are `nullptr` at `gen_snapshot` time, so when
searching for offset for
`Thread::OffsetFromThread(kTsanLoadAcquireRuntimeEntry)`
it looked for the first runtime entry with `nullptr` function pointer -
which turned out to be `MsanUnpoison` (instead of `TsanLoadAcquire`).
=> The obvious fix is to use the `dart::RuntimeEntry*` pointer for
comparison instead of it's `function_` member.
TEST=ci
Issue b/287638965
Change-Id: I85c06674927978ef8561e9e7bdfab4823c0a8e1c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/312902
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
The adjustments to g3 build rules that allow running non-TSAN
gen_snapshot targeting TSAN AOT runtime aren't quite fleshed out yet.
So we temporarily let `gen_snapshot` detect whether to target TSAN by
whether it is itself compiled in TSAN (instead of via
`-DTARGET_USES_THREAD_SANITIZER`)
TEST=ci
Issue b/287638965
Change-Id: I2cd744f959d8302ba81cb1feceedee2756e02656
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/312901
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
This may simplify some g3 build rules as it allows passing this define
whenever we compile under TSAN - instead currently it can only be passed
if DART_PRECOPMILER is also passed.
TEST=ci
Change-Id: I73e51243716373cdeca7559b344408bb206e22ba
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/312801
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
The VM has two parts related to TSAN: compiler & runtime.
So far both parts used self-detection whether running with TSAN. This
implies that if AOT runtime runs under TSAN that the AOT compiler then
also has to run under TSAN (which is slow).
We separate the two by making the compiler use
`TARGET_USES_THREAD_SANITIZER`. It will be auto-detected by-default
except when `DART_PRECOPMILER` is set. In the precompiler case we
require the build rules to pass in whether the target runs under
TSAN or not.
Issue b/287638965
TEST=ci
Change-Id: Ib333a8a69ed2d7bdca7596014a0d25b103af25b6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/312480
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
This reverts commit c7b288492a.
Reason for revert: breaks tests in G3, b/287581831
Original change's description:
> [vm] Mark Zone memory as unallocated/allocated/uninitialized for Address and Memory Sanitizer.
>
> TEST=ci
> Change-Id: Ia283d9aefec767e6ccc4f1c88abba73ce1c35e87
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/212022
> Reviewed-by: Brian Quinlan <bquinlan@google.com>
> Commit-Queue: Ryan Macnak <rmacnak@google.com>
Change-Id: I94ce2141e7b16c8e4be6641253e37dfa82698486
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/309861
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Ilya Yanok <yanok@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
This is the same metadata system that will support async callbacks. The
main thing this does is take the trampolines that used to be JIT only,
and use them in AOT too. This is partly a safety thing (there's some
extra checks that used to be skipped on AOT), but mostly just so that
the metadata system is unified between the sync and async callbacks.
More details about the design:
https://docs.google.com/document/d/1QDjyY_6wOTOgURwpeYMKU9qEz0gKxx2MUrdruC6Kp6c/edit?usp=sharing
I split this off the async CL. Some of the comments refer to async
stuff that doesn't exist yet, but it's coming immediately after this so
I didn't update them.
Change-Id: Icd5e86934ee9ae34c2c0e2ed2bbd1b928a7184ac
TEST=ffi_callback_metadata_test.cc and CI
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/302903
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Liam Appelbe <liama@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
The ffi-callback related information on the [Thread] object is metadata
corresponding to ffi-callback-trampoline [Function] objects. There is
nothing thread or isolate specific about it.
Moving it away from [Thread] is needed because an [Isolate] can
have different [Thread] objects across its lifetime (see [0]): When
the stack of an isolate is empty, we reserve now the right to
re-cycle the [Thread]. If the isolate later runs again, it may
get a new [Thread] object.
This CL moves this information from [Thread] to the [ObjectStore]. In
addition we make the compiler be responsible for populating this
metadata - instead of doing this per-call site of
`Pointer.fromFunction()`. It will be preserved across snapshot writing
& snapshot reading (for AppJIT as well as AppAOT).
Similarly the JIT trampolines that are on Isolate aren't isolate
specific and can go to [IsolateGroup]. This simplifies doing the above
as the compiler can allocate those as well.
The effect is that [Thread] object gets smaller, GC doesn't have to
visit the 2 slots per-thread. It comes at expense of 2 more loads
when invoking the callback.
[0] https://dart-review.googlesource.com/c/sdk/+/297920
TEST=Regression test is vm/ffi{,_2}/invoke_callback_after_suspension_test
Change-Id: Ifde46a9f6e79819b5c0e359c3d3998d1d93b9b1e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/303700
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Liam Appelbe <liama@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
output unless there is an assertion or Fatal error.
(This is needed to ensure that we are able to run the flutter tests with
all these verifications turned on and not disturbing the output from the
tests with these extraneous trace messages)
TEST=ci
Change-Id: Ifb7211e340f1cf29f6d2bff412eb4107f9cb64a2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/299440
Commit-Queue: Siva Annamalai <asiva@google.com>
Reviewed-by: Ryan Macnak <rmacnak@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 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>
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>
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>
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>
- 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>
Refuse to initialize VM if current Mac OS X version is below
MAC_OS_X_VERSION_MIN_REQUIRED, which was configured in build
time through mac_sdk_min GN argument.
TEST=tested manually by changing return value of MacOSXVersion
Cq-Include-Trybots: luci.dart.try:dart-sdk-mac-arm64-try
Bug: https://github.com/flutter/flutter/issues/121739
Change-Id: I9d913516077dbb196e8d6ebd7fe9f3914de7c748
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/286932
Reviewed-by: Michael Thomsen <mit@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
This reverts commit 7424295ce9.
Reason for revert: Causes VM crash in internal tests - b/271081079
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: I1c4b0b78be3748b525b82ea66079dd95d412d82e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/285906
Auto-Submit: Oleh Prypin <oprypin@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Alexander Thomas <athom@google.com>
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>
Closes https://github.com/dart-lang/sdk/pull/50860
GitOrigin-RevId: b27066c37f93c8c6d1123d6ebd6a4c0afcf59844
Change-Id: I15fa4aea1dad45daf168e34d1c4450320ec9b40a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/277742
Commit-Queue: Alexander Thomas <athom@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Closes https://github.com/dart-lang/sdk/pull/50920
GitOrigin-RevId: fa87531bd0f52b69485c9d02ff9e44a4a29c6a91
Change-Id: I0ae8574a5b77087895e004079f221201bb550cf3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/278535
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Alexander Thomas <athom@google.com>
Allows embedders to programmatically request heap snapshot from a
running isolate group instead of relying on a vm-service or hidden
internal Dart APIs
Additionally we allow to include snapshot writing functionality into
PRODUCT builds using DART_ENABLE_HEAP_SNAPSHOT_WRITER define.
TEST=vm/cc/DartAPI_WriteHeapSnapshot
Bug: b/259115846
Change-Id: Ic3ef76e5fb9adcf8f23a1959f5238742b64ecde2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/273181
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
Previously, the VM used a linear array to cache previous instantiations
of a type arguments object. Now once the cache hits a certain number
of occupied entries, the VM changes to using a hash-based approach.
The InstantiateTypeArguments stubs have not yet been updated to
traverse the hash-based cache, so once the cache has grown too large,
all attempts at instantiations, even those that are in the cache, go to
the runtime. Thus, until the stubs are updated, this is only an
improvement if the cost of traversing the linear cache dominates the
cost of making a runtime call. Our benchmarks see a ~40% performance
regression for hash-based caches of size 100 but a ~400% performance
improvement for hash-based caches of size 1000. Thus, we currently
split the difference and set the maximum size of linear caches to 500.
TEST=vm/cc/TypeArguments_Cache_ManyInstantiations
Bug: https://github.com/dart-lang/sdk/issues/48344
Change-Id: I7f1376943523bb5bcd8b175cfb1936779ea73d60
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-dwarf-linux-product-x64-try,vm-kernel-precomp-linux-product-x64-try,vm-kernel-precomp-linux-release-x64-try,vm-kernel-precomp-nnbd-mac-release-arm64-try,vm-kernel-precomp-nnbd-linux-release-simarm_x64-try,vm-kernel-precomp-linux-release-simarm-try,vm-kernel-precomp-nnbd-linux-release-x64-try,vm-kernel-precomp-nnbd-linux-release-simarm64-try,vm-kernel-precomp-nnbd-linux-debug-simriscv64-try,vm-kernel-precomp-tsan-linux-release-x64-try,vm-kernel-tsan-linux-release-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/265325
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
To create a Dart standalone executable on MacOS, we modify the
dartaotruntime executable to add the snapshot contents, and the
VM looks into the executable on disk to find the snapshot to load.
Previously, we did this by adding a new 64-bit segment load command
with a single section, where the section's file offset and size
describes the inserted snapshot. This meant the Mach-O header size increased by 152 bytes.
Originally, this wasn't an issue as there was plenty of padding, but
later clang updates removed most of this padding, and so writing the
new header actually overwrote the initial contents of the first section
in the file, which happens to be the __text section. In addition, since
the first section's offset was now declared to be within the header,
utilities that strictly validated the Mach-O format, like codesign,
would report errors.
This CL changes it so that we actually reserve space in the
dartaotruntime header using the -add_empty_section flag to the linker.
In addition, we change from using a segment load command to using a
(40 byte) note load command. This is because a segment load command
specifies that the contents should be loaded in memory, but we don't
use that loaded version. Instead, the VM reloads it from the executable
on disk so it can appropriately mmap the different parts of the
snapshot. A note section instead just declares a section of the
executable as arbitrary data that the owner can read from the file
and use as desired, which is semantically closer to our current usage.
This CL also adds a test to pkg/dartdev/test/commands/compile_test to
ensure that corrupting a random part of the snapshot in the executable
causes signature verification to fail.
This CL also reverts CL 256208, thus relanding the clang changes
starting from June that originally raised awareness of the issue by
greatly reduced the amount of padding after the load commands.
TEST=pkg/dartdev/test/commands/compile_test
Bug: https://github.com/dart-lang/sdk/issues/49783
Change-Id: Iee554d87b0eabaecd7a534ca4e4facfefbce6385
Cq-Include-Trybots: luci.dart.try:analyzer-mac-release-try,dart-sdk-mac-arm64-try,dart-sdk-mac-try,pkg-mac-release-arm64-try,pkg-mac-release-try,vm-kernel-precomp-mac-product-x64-try,vm-kernel-precomp-nnbd-mac-release-arm64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/260108
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
Instead apply the same approach as we do in AOT: unbox based on the
static type information. There are no TFA results available in JIT,
but we could still unbox fields when running in sound null-safety.
TEST=ci
Cq-Include-Trybots: luci.dart.try:vm-kernel-reload-linux-release-x64-try,vm-kernel-reload-linux-debug-x64-try,vm-kernel-reload-rollback-linux-debug-x64-try,vm-kernel-reload-rollback-linux-release-x64-try,vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-linux-product-x64-try,vm-kernel-precomp-linux-release-x64-try,vm-kernel-precomp-nnbd-linux-release-simarm64-try,vm-kernel-linux-debug-simriscv64-try,vm-kernel-precomp-linux-debug-simriscv64-try,vm-kernel-nnbd-linux-release-ia32-try,vm-kernel-nnbd-linux-debug-x64-try,vm-kernel-nnbd-linux-debug-ia32-try,vm-kernel-nnbd-linux-release-simarm-try,vm-kernel-nnbd-linux-release-simarm64-try
Change-Id: Ide2e78c6659261ef8d245a4586cf699ea0fbb459
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/256211
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
* Merge ClassTable and SharedClassTable back together;
* Simplify handling of multiple arrays growing in sync;
* Refactor how reload deals with ClassTable.
The last change is the most important because it makes it
much easier to reason about the code. We move away from
copying bits and pieces of the class table and shared
class table into reload contexts.
Having two class table fields in the isolate group makes
it easier to reason about. One field contains program
class table (one modified by kernel loader and accessed
by various program structure cid lookups) and heap
walk class table (used by GC visitors). Normally these
two fields point to the same class table, but during
hot reload we temporary split them apart: original
class table is kept as a heap walk class table, while
program class table is replaced by a clone and updated
by reload.
If reload succeeds we drop original class table and
set program class table as heap walk one.
If reload fails we drop the program class table and
restore original one from heap walk table.
TEST=ci
Cq-Include-Trybots: luci.dart.try:vm-kernel-reload-linux-release-x64-try,vm-kernel-reload-linux-debug-x64-try,vm-kernel-reload-rollback-linux-debug-x64-try,vm-kernel-reload-rollback-linux-release-x64-try,vm-kernel-linux-debug-x64-try,vm-kernel-precomp-tsan-linux-release-x64-try,vm-kernel-tsan-linux-release-x64-try,vm-kernel-precomp-asan-linux-release-x64-try,vm-kernel-asan-linux-release-x64-try
Change-Id: I8b66259fcc474dea7dd2af063e4772df99be06c4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/258361
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Instead of using an integer literal use constexpr popcount
function instead.
The misalignment causes an incorrect generation of a call
to a shared write barrier stub for the last allocatable register
on ARM64.
Reported by Lin Zuojian <zuojian.lzj@alibaba-inc.com>
TEST=ci
Change-Id: I69ce32da958573be0ec8967e462f8a378a778a28
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/254401
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Examples of the new line added to non-symbolic stack traces:
os: linux arch: x64 comp: yes sim: no
(Running on linux-x64c)
os: macos arch: arm64 comp: no sim: yes
(Running on mac-simarm64)
This CL also abstracts out the separate hardcoded strings across
the codebase for host and target OS and architecture into
definitions in platform/globals.h to ensure that they stay
in sync across different uses.
TEST=vm/dart{,_2}/use_dwarf_stack_traces_flag
Issue: https://github.com/flutter/flutter/pull/101586
Change-Id: Ifdfea5138dd1003f561da0174e89aebc165bf9b0
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-dwarf-linux-product-x64-try,vm-kernel-precomp-linux-release-simarm-try,vm-kernel-precomp-linux-release-simarm64-try,vm-kernel-precomp-linux-release-simarm_x64-try,vm-kernel-precomp-linux-release-x64-try,vm-kernel-precomp-mac-product-x64-try,vm-kernel-precomp-nnbd-linux-release-x64-try,vm-kernel-precomp-nnbd-linux-release-simarm_x64-try,vm-kernel-precomp-win-release-x64-try,vm-kernel-precomp-nnbd-mac-release-arm64-try,vm-kernel-precomp-mac-release-simarm64-try,vm-ffi-android-release-arm-try,vm-ffi-android-release-arm64c-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/253283
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Even if the main program disables executable stacks, dlopen'ing a library that doesn't itself disable executable stack will switch the stack to executable. (Presumably in the name of compatability with GNU nested functions.)
Dart does not need executable stacks, and executable stacks are an additional attack surface.
TEST=readelf
Bug: b/229648756
Change-Id: Ia8c234ebc6178a26528d37b1359a10dd42039a9b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/241540
Reviewed-by: Tess Strickland <sstrickl@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
