Even though all canonical objects can be shared, they might cause
re-hashing on the receiver side due to user-defined get:hashCode
implementation.
This is why we do not consider the canonical bit (of a key in a map) when
determining whether rehashing is needed.
Though some well-known classes will have a properly behaved
get:hashCode, the most important being for kNullCid.
=> So we'll allow kNullCid, kBoolCid.
This makes receiving json data much faster due to not needing to re-hash
anymore (was done due to `null` values in the map backing store).
TEST=Existing test suite.
Change-Id: Ie6d39da7fe27ce8925644cf2c17a3944a9e936b2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/207080
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
MSVC(unlike clang) seems to have a problem with such a use:
```
ninja -t msvc -e environment.x64 --
"C:\src\depot_tools\win_toolchain\vs_files\20d5f2553f\VC\Tools\MSVC\14.26.28801\bin\Hostx64\x64/cl.exe"
/nologo /showIncludes /FC
@obj/runtime/vm/libdart_vm_jit.runtime_entry.obj.rsp /c
../../runtime/vm/runtime_entry.cc
/Foobj/runtime/vm/libdart_vm_jit.runtime_entry.obj
/Fdobj/runtime/vm/libdart_vm_jit_cc.pdb
C:\src\dart-sdk\sdk\runtime\vm\runtime_entry.cc(3683): error C2121: '#':
invalid character: possibly the result of a macro expansion
C:\src\dart-sdk\sdk\runtime\vm\runtime_entry.cc(3683): error C2059:
syntax error: 'if'
C:\src\dart-sdk\sdk\runtime\vm\runtime_entry.cc(3693): error C2121: '#':
invalid character: possibly the result of a macro expansion
C:\src\dart-sdk\sdk\runtime\vm\runtime_entry.cc(3693): error C2059:
syntax error: 'if'
```
TEST=build sdk on Windows with msvc(rather than clang)
Change-Id: I520b32bf38bc7880f45d93223779f10cbde59af6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/207041
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
We should use store-release when publishing static-const-field values
(to ensure initialalizing stores are visible) and use load-acquire when
accessing them (to please TSAN).
There's no locking required, since concurrent threads would evaluate to
the same canonical constant.
Issue https://github.com/dart-lang/sdk/issues/46628
TEST=Fixes data race reported by TSAN on iso-stress builder.
Change-Id: Ib50423705065ae491ba99b65090859db5afc9514
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/207025
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Tess Strickland <sstrickl@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
On Android native libraries can be mapped directly from an APK
they are stored uncompressed in it. In such situations the name
of the mapping no longer provides enough information for libunwindstack
to find the original ELF file and instead it has to rely on heuristics
to locate program header table. These heuristics currently assume that
program header table will be located in the RO mapping which precedes
RX mapping. This implies the following order of segments: RO (program
header, build id section if present, .rodata), RX (.text), RW (.dynamic
and .bss).
TEST=ci, manual
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-dwarf-linux-product-x64-try,vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-linux-release-x64-try
Change-Id: I3fa4de75c5d8841a90fd4cae1ab230d02c554f94
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206620
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Tess Strickland <sstrickl@google.com>
When doing optimizing compilations on the mutator thread (e.g. due to
--deterministic or --no-background-compilation) we can have situations
in which one thread is starting or in the middle of optimizing a
function while another has just deoptimized it, reaching the
deoptimization counter threshold.
We just remove this assertion which doesn't hold anymore with
--enable-isolate-groups enabled.
Fixes https://github.com/dart-lang/sdk/issues/46622
TEST=Fixes flaky assertion hit in vm/dart_2/isolates/regress_46539_test
Change-Id: I9812e3c6500113b7d948f96dc4cfcee607f56d39
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/207023
Reviewed-by: Tess Strickland <sstrickl@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This CL fixes AOT failures that happened after [0] landed. That code
removed lookup code for the `future_class()` in the
`ObjectStore::LazyInit*()` methods and replaced it with an assert instead.
The change was correct, since the lazy members should be initialized
on-demand - after the core, non-lazy members.
=> Though this seemed to not be the case in AOT, which hit the assert.
The reason [0] only caused failures in AOT is because in JIT the VM is
bootstrapped only from the vm_platform.dill file and as a secondary
embedder call the application.dill file is loaded.
Yet in AOT we have a combined full_application.dill which will all be
loaded during bootstrapping. That has caused the application to be
loaded before `ObjectStore::InitKnownObjects()` was invoked.
The initialization of [ObjectStore] which contains common core library
classes/functions/fields should happen before we use the kernel loader
to load user classes (since general kernel loading depends on the
[ObjectStore] being populated).
This also ensures that `ObjectStore::InitKnownObjects()` will be called
before `ObjectStore::LazyInit*()` - since they depend on the former having
run (e.g. that the non-lazy `future_class()` member of `ObjectStore`
was set).
[0] https://dart-review.googlesource.com/c/sdk/+/206782
TEST=Fixes AOT builders.
Change-Id: I0861d1a2f39effbcea08d7796742845b874a0084
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/207002
Reviewed-by: Tess Strickland <sstrickl@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
If two threads concurrently trigger initialization of the lazily
populated ObjectStore members, they have to coordinate.
We ensure mutual exclusion by holding a writer lock, to ensure only one
thread can perform the lazy initialization. Furthermore we use
store-release/load-acquire for those ObjectStore fields to ensure that
once an object is made available on ObjectStore all of it's initializing
stores are visible at that point.
We no longer make public setters for those fields, since they shouldn't
be used (only the getters + lazy initialization should be used)
Fixes https://github.com/dart-lang/sdk/issues/46611
TEST=Fixes TSAN races reported on iso-stres builder.
Change-Id: Icaf54bb224e74baf1bfbb4a9bfc386ebfbd52755
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206782
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Tess Strickland <sstrickl@google.com>
TTS can be generated on multiple threads at the same time and we should
therefore given them unique names by using an atomic counter.
Fixes https://github.com/dart-lang/sdk/issues/46609
TEST=Fixes one TSAN issue on iso-stress builder.
Change-Id: I4a318106a901cebe30914ac42f858cf3daced74c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206742
Reviewed-by: Tess Strickland <sstrickl@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
- Account for initialization-in-progress sentinel when checking static field types for reload.
- Don't read the true stack limit when setting or clearing interrupts.
TEST=ci
Bug: https://github.com/dart-lang/sdk/issues/46596
Change-Id: I80adb4d7d69f01125b7eae8215b5da4d2e467bda
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206662
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
When size get updated, class table update is not needed, causes tsan data race warnings.
Fixes https://github.com/dart-lang/sdk/issues/46538
TEST=IsolateSpawn on tsan
Change-Id: I8dac5faa413b0581e42d6b33adeef8e94e492870
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206329
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
We use message passing as comunication mechanism between isolates.
The transitive closure of an object to be sent is currently serialized
into a snapshot form and deserialized on the receiver side. Furthermore
the receiver side will re-hash any linked hashmaps in that graph.
If isolate gropus are enabled we have all isolates in a group work on
the same heap. That removes the need to use an intermediate
serialization format. It also removes the need for an O(n) step on the
receiver side.
This CL implements a fast transitive object copy implementation and
makes use of it a message that is to be passed to another isolate stays
within the same isolate group.
In the common case the object graph will fit into new space. So the
copy algorithm will try to take advantage of it by having a fast path
and a fallback path. Both of them effectively copy the graph in BFS
order.
The algorithm works effectively like a scavenge operation, but instead
of first copying the from-object to the to-space and then re-writing the
object in to-space to forward the pointers (which requires us writing to
the to-space memory twice), we only reserve space for to-objects and
then initialize the to-objects to it's final contents, including
forwarded pointers (i.e. write the to-space object only once).
Compared with a scavenge operation (which stores forwarding pointers in
the objects themselves), we use a [WeakTable] to store them. This is the
only remaining expensive part of the algorithm and could be further
optimized. To avoid relying on iterating the to-space, we'll remember
[from, to] addresses.
=> All of this works inside a [NoSafepointOperationScope] and avoids
usages of handles as well as write barriers.
While doing the transitive object copy, we'll share any object we can
safely share (canonical objects, strings, sendports, ...) instead of
copying it.
If the fast path fails (due to allocation failure or hitting) we'll
handlify any raw pointers and continue almost the same algorithm in a
safe way, where GC is possible at every object allocation site and
normal barriers are used for any stores of object pointers.
The copy algorithm uses templates to share the copy logic between the
fast and slow case (same copy routines can work on raw pointers as well
as handles).
There's a few special things to take into consideration:
* If we copy a view on external typed data we need to know the
external typed data address to compute the inner pointer of the
view, so we'll eagerly initialize external typed data.
* All external typed data needs to get a finalizer attached
(irrespective if the object copy suceeds or not) to ensure the
`malloc()`ed data is freed again.
* Transferables will only be transferred on successful transitive
copies. Also they need to attach finalizers to objects (which
requires all objects be in handles).
* We copy linked hashmaps as they are - instead of compressing the
data by removing deleted entries. We may need to re-hash those
hashmaps on the receiver side (similar to the snapshot-based copy
approach) since new object graph will have no identity hash codes
assigned to them. Though if the hashmaps only has sharable objects
as keys (very common, e.g. json) there is no need for re-hashing.
It changes the SendPort.* benchmarks as follows:
```
Benchmark | default | IG | IG + FOC
----------------------------------------------------------------------------------------------------------------------------
SendPort.Send.Nop(RunTimeRaw): | 0.25 us (1 x) | 0.26 us (0.96 x) | 0.25 us (1.00 x)
SendPort.Send.Json.400B(RunTimeRaw): | 4.15 us (1 x) | 1.45 us (2.86 x) | 1.05 us (3.95 x)
SendPort.Send.Json.5KB(RunTimeRaw): | 82.16 us (1 x) | 27.17 us (3.02 x) | 18.32 us (4.48 x)
SendPort.Send.Json.50KB(RunTimeRaw): | 784.70 us (1 x) | 242.10 us (3.24 x) | 165.50 us (4.74 x)
SendPort.Send.Json.500KB(RunTimeRaw): | 8510.4 us (1 x) | 3083.80 us (2.76 x) | 2311.29 us (3.68 x)
SendPort.Send.Json.5MB(RunTimeRaw): | 122381.33 us (1 x) | 62959.40 us (1.94 x) | 55492.10 us (2.21 x)
SendPort.Send.BinaryTree.2(RunTimeRaw): | 1.91 us (1 x) | 0.92 us (2.08 x) | 0.72 us (2.65 x)
SendPort.Send.BinaryTree.4(RunTimeRaw): | 6.32 us (1 x) | 2.70 us (2.34 x) | 2.10 us (3.01 x)
SendPort.Send.BinaryTree.6(RunTimeRaw): | 25.24 us (1 x) | 10.47 us (2.41 x) | 8.61 us (2.93 x)
SendPort.Send.BinaryTree.8(RunTimeRaw): | 104.08 us (1 x) | 41.08 us (2.53 x) | 33.51 us (3.11 x)
SendPort.Send.BinaryTree.10(RunTimeRaw): | 373.39 us (1 x) | 174.11 us (2.14 x) | 134.75 us (2.77 x)
SendPort.Send.BinaryTree.12(RunTimeRaw): | 1588.64 us (1 x) | 893.18 us (1.78 x) | 532.05 us (2.99 x)
SendPort.Send.BinaryTree.14(RunTimeRaw): | 6849.55 us (1 x) | 3705.19 us (1.85 x) | 2507.90 us (2.73 x)
SendPort.Receive.Nop(RunTimeRaw): | 0.67 us (1 x) | 0.69 us (0.97 x) | 0.68 us (0.99 x)
SendPort.Receive.Json.400B(RunTimeRaw): | 4.37 us (1 x) | 0.78 us (5.60 x) | 0.77 us (5.68 x)
SendPort.Receive.Json.5KB(RunTimeRaw): | 45.67 us (1 x) | 0.90 us (50.74 x) | 0.87 us (52.49 x)
SendPort.Receive.Json.50KB(RunTimeRaw): | 498.81 us (1 x) | 1.24 us (402.27 x) | 1.06 us (470.58 x)
SendPort.Receive.Json.500KB(RunTimeRaw): | 5366.02 us (1 x) | 4.22 us (1271.57 x) | 4.65 us (1153.98 x)
SendPort.Receive.Json.5MB(RunTimeRaw): | 101050.88 us (1 x) | 20.81 us (4855.88 x) | 21.0 us (4811.95 x)
SendPort.Receive.BinaryTree.2(RunTimeRaw): | 3.91 us (1 x) | 0.76 us (5.14 x) | 0.74 us (5.28 x)
SendPort.Receive.BinaryTree.4(RunTimeRaw): | 9.90 us (1 x) | 0.79 us (12.53 x) | 0.76 us (13.03 x)
SendPort.Receive.BinaryTree.6(RunTimeRaw): | 33.09 us (1 x) | 0.87 us (38.03 x) | 0.84 us (39.39 x)
SendPort.Receive.BinaryTree.8(RunTimeRaw): | 126.77 us (1 x) | 0.92 us (137.79 x) | 0.88 us (144.06 x)
SendPort.Receive.BinaryTree.10(RunTimeRaw): | 533.09 us (1 x) | 0.94 us (567.12 x) | 0.92 us (579.45 x)
SendPort.Receive.BinaryTree.12(RunTimeRaw): | 2223.23 us (1 x) | 3.03 us (733.74 x) | 3.04 us (731.33 x)
SendPort.Receive.BinaryTree.14(RunTimeRaw): | 8945.66 us (1 x) | 4.03 us (2219.77 x) | 4.30 us (2080.39 x)
```
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=vm/dart{,_2}/isolates/fast_object_copy{,2}_test
Change-Id: I835c59dab573d365b8a4b9d7c5359a6ea8d8b0a7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/203776
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Previously in Elf::Relocation, symbol names had this mapping:
* nullptr: relative to the start of the snapshot
* ".": relative to the position of the relocation
* otherwise, relative to the given static symbol value
Change this as follows:
* nullptr: relative to the position of the relocation
* "": relative to the start of the snapshot
* otherwise, relative to the given static symbol value
This uses the fact that in ELF, symbol tables always have an initial
symbol with a name of "" that has a value of 0, so now we only have to
handle the nullptr case specially there, instead of having to handle
three different cases.
TEST=Refactoring, so existing tests of snapshots.
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-debug-simarm_x64-try,vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-linux-release-simarm-try,vm-kernel-precomp-linux-release-simarm64-try,vm-kernel-precomp-dwarf-linux-product-x64-try
Change-Id: Icb428551091e5fcf04facd34a5bf57ea0d664fa4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206544
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
To do this, BitsContainer is changed to be a more rope-like
representation of section portions. In addition to containing
most of the same information stored per-section previously, each
portion also has a section-relative offset that is calculated when
it is added. Thus, merging two compatible BitsContainer sections
is just adding the portions from the second to the first, tweaking
the section-relative offset for each.
Other changes in this CL:
* Create PseudoSections subclasses for the elf header, program
header table, and section header table, so we can treat them
more uniformly with the other parts of the ELF snapshot.
* We now only allocate as much BSS space in the snapshot as is needed
for any text sections in the snapshot, instead of always allocating
a big enough BSS space for both VM and isolate, even for deferred
snapshots where there is no VM isolate.
* We already separated segment and section alignment in previous CLs,
so the fact that our own ELF loader needs load segments to be
page-aligned no longer means that the sections within those segments
also needs to be. Thus, we align individual instructions sections to
kMaxObjectAlignment, like readonly data sections, since both hold a
single Image object. This removes unnecessary intra-section padding.
TEST=Tests that check DWARF information and trybots that use ELF
snapshots.
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-debug-simarm_x64-try,vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-linux-release-simarm-try,vm-kernel-precomp-linux-release-simarm64-try,vm-kernel-precomp-dwarf-linux-product-x64-try
Change-Id: If0315c8b7b0f31481b676a8901f49cd3a44b5561
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206365
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
Create all symbol table-related sections after all other sections, right
before section re-ordering. Also remove the need to keep fields in the
Elf object for most of these sections, only keeping fields for the
static symbol table and the dynamic table, which handles updates
and finalization for the dynamic symbol table.
Reworks symbols so that they are stored in a growable array in the
symbol table instead of as separately allocated objects. Since this
disallows constant fields in Symbol objects due to the need for a copy
constructor, initialize the offset of symbols with the section-relative
offset. This can be adjusted to a snapshot-relative offset after
section memory offsets are computed.
Instead of updating indices and offsets by individually looking up
symbols via their name, just create a map from section indices to new
section indices (for index updates) or to memory offsets (for offset
adjustment) and iterate over all the symbols, applying the map
appropriately.
Move non-PT_LOAD, non-PT_PHDR segment creation into
OrderSectionsAndCreateSegments.
TEST=Refactoring, so existing ELF-based tests.
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-debug-simarm_x64-try,vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-linux-release-simarm64-try,vm-kernel-precomp-dwarf-linux-product-x64-try
Change-Id: Ic22f1bf3ab0b00ff3e73c431f92209526e787927
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206220
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
If two mutators concurrently execute a switchable call that targets a
code object which has been disabled, they both go to runtime trying to
fix that switchable call site's object pool.
This Cl ensures we use the same logic as for other miss handlers to
ensure we properly guard against concurrent accesses.
The attached regression test will trigger a segfault - though only
with low probability.
The changes to first land is: Avoid assuming the target can be called
directly. Instead always go through IC Stub when returning from miss
handler. We do that since a call site might not provide ARGS_DESC but
the target might need it.
Fixes https://github.com/dart-lang/sdk/issues/46539
Fixes https://github.com/dart-lang/sdk/issues/46553
TEST=vm/dart{,_2}/isolates/regress_46539_test
Change-Id: I18018fa286173d905c52b6e058a6c87b544ff18e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206373
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Revert the optimization that stores function entry point addresses
directly in these caches. It doesn't work in compressed mode, and
should be an unimportant optimization these days as most cases are
handled by the dispatch table.
Change-Id: I2ebbf6549aadb49c767553574a3bafe5d867d194
TEST=CI
Bug: https://github.com/dart-lang/sdk/issues/46468
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/205636
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Liam Appelbe <liama@google.com>
`_CompactLinkedHashSet` now extends `_HashVMBase`. The class hierarchy
is organized as mixins similar to LinkedHashMap to accomodate for the
other Sets not extending `_HashVMBase`.
Also, rearranges some code so that introducing ImmutableHashMap and
ImmutableHashSet is easier.
1) snapshot.h and snapshot.cc now have a MapReadFrom, MapWriteTo,
SetReadFrom, and SetWriteTo to facilitate code sharing between
mutable and immutable implementations similar to ArrayReadFrom and
ArrayWriteTo.
2) Macros for CLASS_LIST_MAPS and CLASS_LIST_SETS to facilitate
treating mutable and immutable implementations with the same handle.
Also similar to Array.
Clustered snapshots for HashMaps is currently dead code. This CL makes
it explicit by marking these as unreachable. Immutable maps and sets
will end up in the clustered snapshot in follow up CLs.
Bug: https://github.com/dart-lang/sdk/issues/36077
Bug: https://github.com/dart-lang/sdk/issues/45908
TEST=runtime/vm/object_test.cc
TEST=tests/**_test.dart on many bots
Change-Id: If3cc5ebb3138535aeb0d5e06d9da3d1c9fb2deb2
Cq-Include-Trybots: luci.dart.try:analyzer-nnbd-linux-release-try,app-kernel-linux-debug-x64-try,dart-sdk-linux-try,front-end-nnbd-linux-release-x64-try,pkg-linux-debug-try,vm-canary-linux-debug-try,vm-kernel-asan-linux-release-x64-try,vm-kernel-checked-linux-release-x64-try,vm-kernel-linux-debug-x64c-try,vm-kernel-linux-debug-x64-try,vm-kernel-linux-debug-simarm64c-try,vm-kernel-nnbd-linux-release-simarm-try,vm-kernel-optcounter-threshold-linux-release-x64-try,vm-kernel-precomp-android-release-arm_x64-try,vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-linux-debug-x64c-try,vm-kernel-reload-linux-debug-x64-try,vm-kernel-reload-rollback-linux-debug-x64-try,vm-precomp-ffi-qemu-linux-release-arm-try,vm-kernel-precomp-linux-release-simarm_x64-try,vm-kernel-precomp-linux-debug-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206222
Reviewed-by: Tess Strickland <sstrickl@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
It's not used outside of elf.cc and rarely used as a type outside
of SymbolTable, so nest it to avoid defining dart::Symbol.
TEST=Refactoring, so existing tests.
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-dwarf-linux-product-x64-try
Change-Id: Idc8895b95b021edf831bc310aff0cf3106de8eb1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206367
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
When FDE refers to CIE it needs to use the offset to CIE start
not CIE's payload start.
TEST=manually
Change-Id: Ic0661e882ab9284d34f5768070d05f9dad440dda
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206362
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Tess Strickland <sstrickl@google.com>
Test some of the assumptions from go/dart-vm-const-maps about
`CanonicalizeHash` in the VM being equal to Dart's `hashCode`.
In this CL this is true for integers, doubles, booleans, strings, null,
and type consts.
In this CL this is not true yet for Symbols, and user-defined const
instances.
Bug: https://github.com/dart-lang/sdk/issues/45908
TEST=runtime/vm/object_test.cc
Change-Id: Ic3b4495942177ad90aa4365eb7691ca731572cb5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206240
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Tess Strickland <sstrickl@google.com>
datastream.h is included in places where we cannot import the compiler
namespace, so we can't make compiler::target::word the type of
WriteTargetWord. That also would possibly silently truncate a
host-word sized value that was passed in instead of alerting to a
possible issue if those bits were important.
However, just using IsInt fails if the value being passed in is
a compiler::target::uword that is larger than the max value
that fits in a compiler::target::word. Instead, check for
truncation by checking the bit length of the value, which works
for both signed and unsigned target word values.
Original description:
Also remove previous (incorrect) uses in datastream.cc and
image_snapshot.cc, now that Utils::IsInt<T>(N, value) can now
be run for values of N >= sizeof(T).
Fixes https://github.com/dart-lang/sdk/issues/46572
TEST=language/generic/super_bounded_types_test passes on NNBD simarm,
added value that triggered failure to vm/cc/MagnitudeIsUint
Cq-Include-Trybots: luci.dart.try:vm-kernel-nnbd-linux-release-simarm-try,vm-kernel-precomp-linux-debug-simarm_x64-try
Change-Id: Idbfdda9f28243d206d482a1d9ac7ae76a5022ad2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206201
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
After https://dart-review.googlesource.com/c/sdk/+/201864 maintaining
vm/cc/PrintJSONPrimitives became manual.
This CL stops checking the actual token positions, so that we don't have
to update this test manually.
TEST=runtime/vm/object_test.cc PrintJSONPrimitives
Change-Id: I22475145f65de7d4f00770a8a6d0b711b8ff19f2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206084
Auto-Submit: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Also remove previous (incorrect) uses in datastream.cc and
image_snapshot.cc, now that Utils::IsInt<T>(N, value) can now
be run for values of N >= sizeof(T).
Fixes https://github.com/dart-lang/sdk/issues/46572
TEST=language/generic/super_bounded_types_test passes on NNBD simarm,
added value that triggered failure to vm/cc/MagnitudeIsUint
Cq-Include-Trybots: luci.dart.try:vm-kernel-nnbd-linux-release-simarm-try
Change-Id: Ibc2d2bb5037a8fdee11fc26fa2a313149d3ca274
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206083
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Instead create a copy of BitmapBuilder and mutate that. This
simplifies the logic, avoids unnecessary side-effects and
allows us to delete some code which existed solely to validate
that two independent slow-path calls don't mutate the same
stack_bitmap in incompatible ways.
To make it cheap to copy BitmapBuilder we inline BitmapBuilder
backing storage into the object itself. Inlined capacity has
been chosen by looking at bitmap size distributions from large
Flutter applications.
TEST=ci
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-linux-release-x64-try
Change-Id: I62ecb4ead388a367ad6904471d5923f5d1f5e3f4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/205783
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Tess Strickland <sstrickl@google.com>
This relands https://dart-review.googlesource.com/c/sdk/+/205633
but without renaming TARGET_OS_IPHONE to DART_TARGET_OS_IPHONE.
It also changes uses of TARGET_OS_IOS to
DART_TARGET_OS_MACOS_IOS to be consistent with the rest of the
VM.
TargetConditionals.h for XCode 13 defines several
TARGET_OS_* preprocessor symbols that confuse the
Dart build. There is probably a more targeted fix
for this, but renaming the symbols that Dart uses
will also prevent this problem if more symbols
are added to the platform headers in the future.
See: https://github.com/dart-lang/sdk/issues/46499
TEST=It builds.
Change-Id: Ie775c19dd23cfdf5f65e5ebc6ee4ec3a561676fa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/205860
Commit-Queue: Zach Anderson <zra@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Previous CLs made it so that we don't need to calculate memory offsets
until finalization. This means that we can now reorder sections as
desired and then calculate the memory offsets at the same time as the
file offsets.
Thus, we reorder them so that writable, non-executable allocated
sections come first (due to requirements by some loaders to not sandwich
writable segments between non-writable ones), followed by non-writable,
non-executable allocated sections, followed by non-writable, executable
sections, and finally unallocated sections (to avoid differences in
memory offsets between snapshots and separate debugging information).
This ordering minimizes the number of segments that need to be created
(5 or 6, depending on whether a build ID exists).
Since we can reorder, we also delay the creation of the build ID (if
generated) and BSS sections until finalization, instead of creating them
up front in the constructor.
TEST=Further refactorings, so existing tests.
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-debug-simarm_x64-try,vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-linux-release-simarm-try,vm-kernel-precomp-linux-release-simarm64-try,vm-kernel-precomp-dwarf-linux-product-x64-try
Change-Id: Id4142a021c2bb800938e8bc711b1b8a7529bff51
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/205780
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
This CL splits the creation of ELF symbols into two parts: an
initialization that creates the symbol with all information but
the offset, and a finalization that sets the offset appropriately.
The initialization happens eagerly when adding sections, and the
finalization happens just prior to writing out the ELF contents,
after all memory and file offsets have been calculated.
To ensure safety, retrieving the offset from a symbol checks that
the symbol has been properly finalized.
This removes another obstacle to reordering sections and segments.
TEST=Further refactorings, so existing tests.
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-debug-simarm_x64-try,vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-linux-release-simarm-try,vm-kernel-precomp-linux-release-simarm64-try,vm-kernel-precomp-dwarf-linux-product-x64-try
Change-Id: I5dcb0d2c685fb341478e9a7d90c67fc4649a4e75
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/205481
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Now that this class is used for more than wrapping Object tags, move it
to be alongside the BitField class and change its name to something more
representative of its role.
Also remove the need to change BitField declarations if the source type
of the bitfield is decltype(field) and the declaration of field is
changed from type T to type AtomicBitFieldContainer<T>.
TEST=Refactoring, so existing tests.
Cq-Include-Trybots: luci.dart.try:vm-kernel-tsan-linux-release-x64-try,vm-kernel-precomp-tsan-linux-release-x64-try,vm-kernel-precomp-linux-release-simarm_x64-try
Change-Id: If2f48ed4e209d71461c1b1ec81769e1485fbd6b0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/205782
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
