Also only check instruction inlining IDs if the token position is
real or synthetic, since that's when we need to know which function
an instruction belongs to.
Code size changes on Flutter gallery in release mode:
* ARM7: total -1.29%, isolate: -2.42%, readonly: -3.65%
* ARM8: total -1.38%, isolate: -2.38%, readonly: -3.28%
Bug: https://github.com/dart-lang/sdk/issues/44436
TEST=Existing tests on trybots plus benchmarking numbers above.
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-product-x64-try,vm-kernel-linux-product-x64-try,vm-kernel-precomp-linux-debug-simarm_x64-try,vm-kernel-precomp-linux-release-simarm64-try,vm-kernel-linux-release-simarm64-try,vm-kernel-linux-release-simarm-try,vm-kernel-linux-release-ia32-try
Change-Id: I7c8e52d9607a037b2f7b47a3544531e7a3e8eda7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/176522
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
To make this less likely to occur in the future, we remove the need to
call StartInliningInterval separately from BeginCodeSourceRange.
Instead, the inlining ID (if any) is provided to BeginCodeSourceRange,
and in the CodeSourceMapBuilder, that method starts the inlining
interval.
Changes to code size for Flutter gallery in release mode:
* ARM7: total: +0.67%, readonly: +1.97%, isolate: +1.22%
* ARM8: total: +1.17%, readonly: +3.13%, isolate: +1.63%
TEST=Existing tests, manual use of --check-token-positions to see
that failures due to deferred code prior to CL did not appear.
Bug: https://github.com/dart-lang/sdk/issues/44436
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-product-x64-try,vm-kernel-linux-product-x64-try,vm-kernel-precomp-linux-debug-simarm_x64-try,vm-kernel-precomp-linux-release-simarm64-try,vm-kernel-linux-release-simarm64-try,vm-kernel-linux-release-simarm-try,vm-kernel-linux-release-ia32-try
Change-Id: I7d2764edae572fa528ae519aae9abfe9a8d694aa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175366
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
When this flag is enabled, then the validity of real token positions are
checked in three places:
* FlowGraphChecker::VisitInstruction
* CodeSourceMapBuilder::BufferChangeLocation
* DescriptorList::AddDescriptor
The validity check ensures that, if the flow graph has an inlining
ID, that the instruction has an inlining ID and that any real token
position is a valid source offset for the appropriate script (found
via the inlining ID) by attempting to look up line and column.
This flag is disabled by default until existing issues with invalid
inlining IDs and token positions are resolved.
TEST=Enabled the flag manually to check that it caught invalid token
positions.
Bug: https://github.com/dart-lang/sdk/issues/44436
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-release-x64-try,vm-kernel-precomp-linux-product-x64-try
Change-Id: I86439db3661d976ac4ea608d132e3277425615d5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175641
Reviewed-by: Martin Kustermann <kustermann@google.com>
Attempts to run class finalizaton on background thread revealed the problem where during optimization(which could run on mutator thread too) we might need to finalize previously unseen class, load annotatons for it, load and set some constant fields. This could result in updating Fields guarded_cid, requires check during installation of newly produced optimized code. Because mutator thread is currently exempt from cloning and validating fields guards, that could result in invalid optimized code installation.
This CL ensures that fields are always cloned in optimizing compiler even when it runs on mutator thread.
Ability to run multiple optimizing compilers is also needed for dartbug.com/36097.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=existing test suite with ltw isolate groups enabled, https://dart-review.googlesource.com/c/sdk/+/176300 mocked up test(still to be improved).
Change-Id: I608f4abff30b468cb9d0ab270221a0ba72c32470
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175341
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
First, change LocationForPosition and TokenRangeAtLine to return
whether they successfully located the offset/line. Also change the
wrappers in Script (GetTokenLocation and TokenRangeAtLine) to return
whether or not any information was successfully located.
These methods now only change the out parameters in the case that
appropriate information was found, so any unconditional uses of the out
parameters need the out parameters to be appropriately initialized.
We now allow negative lines to be requested in TokenRangeAtLine (with
the failure behavior described above) so the line returned by
LocationAtPosition can be fed into TokenRangeAtLine without intermediate
checking.
The calculation of the token length, which uses the script source and
not the line starts array, has been moved to a new method,
Script::GetTokenLength. The new method returns the length (or a
negative value if the token length could not be determined) instead of
using an out parameter.
TEST=Existing tests on trybots, to ensure tests using current
line/number info aren't affected.
Bug: https://github.com/dart-lang/sdk/issues/44436
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-product-x64-try,vm-kernel-linux-product-x64-try,vm-kernel-linux-release-simarm-try,vm-kernel-linux-release-simarm64-try,vm-kernel-precomp-linux-release-simarm64-try,vm-kernel-precomp-linux-release-simarm-try
Change-Id: Ibc048a226d11ff9a340a8d249654d07720fdf115
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175365
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Clement Skau <cskau@google.com>
Instead, split each old use into the following cases:
* If the TokenPosition value is expected to be a real token position,
then use TokenPosition::Pos().
* If the TokenPosition is being serialized in some way, then use
TokenPosition::Serialize() and change the place where the
TokenPosition is recreated to use TokenPosition::Deserialize().
* If the value of the TokenPosition is being printed for debugging
purposes, then just use TokenPosition::ToCString() instead.
That is, we try to pin down when token positions are expected to
be real vs. when other types of token positions can be found.
Another source of possible error when using token positions is to
convert between synthetic and real token positions. In the past,
synthetic token positions may have been based off real token positions,
but that is no longer the case. Thus, all methods that allow
that conversion have been removed, and instead there is a new static
method for constructing synthetic tokens from valid nonces.
This CL also makes it so that Pos() and relational operators on token
positions are only defined on real token positions, to avoid any
assumptions about what the value encoded in synthetic positions mean. To
help with cases where non-real token positions may occur, four helper
methods are added:
* TokenPosition::Min(a, b): A static method that returns the smallest
real token position provided. If neither `a` or `b` are real,
returns `a`.
* TokenPosition::Max(a, b): A static method that returns the largest
real token position provided. If neither `a` or `b` are real,
returns `a`.
* TokenPosition::IsWithin(start, end): Determines whether `this` falls
between `start` and `end` (inclusive). If `this` is non-real, then it
must be either `start` or `end` if synthetic, otherwise false.
Otherwise, we mimic the old style of range checking, which means that
non-real starts and ends are treated as less than every real token.
* TokenPosition::CompareForSorting(other): Unlike the relational
operators, provides a comparison between any types of token positions
for purposes such as sorting. Currently only used in the profiler.
It also changes TokenPosition::ToCString() to tag synthetic token
positions, so they can be distinguished from real ones at a glance.
TEST=Existing test suite on trybots, especially the observatory tests
which make heavy use of the debugger and the unit tests for the
profiler/source report modules.
Bug: https://github.com/dart-lang/sdk/issues/44436
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-nnbd-linux-debug-x64-try,vm-kernel-precomp-linux-debug-x64-try,vm-kernel-nnbd-linux-debug-x64-try,vm-kernel-linux-debug-x64-try,vm-kernel-linux-release-x64-try,vm-kernel-nnbd-linux-release-x64-try,vm-kernel-precomp-linux-release-x64-try,vm-kernel-precomp-nnbd-linux-release-x64-try,vm-kernel-linux-product-x64-try,vm-kernel-precomp-linux-product-x64-try
Change-Id: Ic06aa0bc7a1f0fbac7257ed22ca5e7e0ccd7f3f2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/174924
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
This CL adds passing structs by value in FFI trampolines.
Nested structs and inline arrays are future work.
C defines passing empty structs as undefined behavior, so that is not
supported in this CL.
Suggested review order:
1) commit message
2) ffi/marshaller (decisions for what is done in IL and what in MC)
3) frontend/kernel_to_il (IL construction)
4) backend/il (MC generation from IL)
5) rest in VM
Overall architecture is that structs are split up into word-size chunks
in IL when this is possible: 1 definition in IL per chunk, 1 Location in
IL per chunk, and 1 NativeLocation for the backend per chunk.
In some cases it is not possible or less convenient to split into
chunks. In these cases TypedDataBase objects are stored into and loaded
from directly in machine code.
The various cases:
- FFI call arguments which are not passed as pointers: pass individual
chunks to FFI call which already have the right location.
- FFI call arguments which are passed as pointers: Pass in TypedDataBase
to FFI call, allocate space on the stack, and make a copy on the stack
and pass the copies' address to the callee.
- FFI call return value: pass in TypedData to FFI call, and copy result
in machine code.
- FFI callback arguments which are not passed as pointers: IL definition
for each chunk, and populate a new TypedData with those chunks.
- FFI callback arguments which are passed as pointer: IL definition for
the pointer, and copying of contents in IL.
- FFI return value when location is pointer: Copy data to callee result
location in IL.
- FFI return value when location is not a pointer: Copy data in machine
code to the right registers.
Some other notes about the implementation:
- Due to Store/LoadIndexed loading doubles from float arrays, we use
a int32 instead and use the BitCastInstr.
- Linux ia32 uses `ret 4` when returning structs by value. This requires
special casing in the FFI callback trampolines to either use `ret` or
`ret 4` when returning.
- The 1 IL definition, 1 Location, and 1 NativeLocation approach does
not remove the need for special casing PairLocations in the machine
code generation because they are 1 Location belonging to 1 definition.
Because of the amount of corner cases in the calling conventions that
need to be covered, the tests are generated, rather than hand-written.
ABIs tested on CQ: x64 (Linux, MacOS, Windows), ia32 (Linux, Windows),
arm (Android softFP, Linux hardFP), arm64 Android.
ABIs tested locally through Flutter: ia32 Android (emulator), x64 iOS
(simulator), arm64 iOS.
ABIs not tested: arm iOS.
TEST=runtime/bin/ffi_test/ffi_test_functions_generated.cc
TEST=runtime/bin/ffi_test/ffi_test_functions.cc
TEST=tests/{ffi,ffi_2}/function_structs_by_value_generated_test.dart
TEST=tests/{ffi,ffi_2}/function_callbacks_structs_by_value_generated_tes
TEST=tests/{ffi,ffi_2}/function_callbacks_structs_by_value_test.dart
TEST=tests/{ffi,ffi_2}/vmspecific_static_checks_test.dart
Closes https://github.com/dart-lang/sdk/issues/36730.
Change-Id: I474d3a4ee1faadbe767ddadd1b696e24d8dc364c
Cq-Include-Trybots: luci.dart.try:dart-sdk-linux-try,dart-sdk-mac-try,dart-sdk-win-try,vm-ffi-android-debug-arm-try,vm-ffi-android-debug-arm64-try,vm-kernel-asan-linux-release-x64-try,vm-kernel-mac-debug-x64-try,vm-kernel-linux-debug-ia32-try,vm-kernel-linux-debug-x64-try,vm-kernel-nnbd-linux-debug-x64-try,vm-kernel-nnbd-linux-debug-ia32-try,vm-kernel-nnbd-mac-release-x64-try,vm-kernel-nnbd-win-debug-x64-try,vm-kernel-precomp-linux-debug-x64-try,vm-kernel-precomp-linux-debug-simarm_x64-try,vm-kernel-precomp-nnbd-linux-debug-x64-try,vm-kernel-precomp-win-release-x64-try,vm-kernel-reload-linux-debug-x64-try,vm-kernel-reload-rollback-linux-debug-x64-try,vm-kernel-win-debug-x64-try,vm-kernel-win-debug-ia32-try,vm-precomp-ffi-qemu-linux-release-arm-try,vm-kernel-precomp-obfuscate-linux-release-x64-try,vm-kernel-msan-linux-release-x64-try,vm-kernel-precomp-msan-linux-release-x64-try,vm-kernel-precomp-android-release-arm_x64-try,analyzer-analysis-server-linux-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/140290
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Front-end marks certain calls (currently in collection literals) as
not requiring covariant parameter checks (invariant).
VM can use that flag to generate calls through unchecked entry point.
TEST=vm/cc/StreamingFlowGraphBuilder_InvariantFlagInListLiterals
Change-Id: I8d0dc09ea4867f41d20f6d7b6ba9e0940ff555dd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175880
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Under certain circumstances we see that gen_snapshot spends significant
portion of time in kernel. This happens with --trace_precompiler_to
option specified on the command line.
This change reduces number of I/O operations required to write
--trace_precompiler_to output by adding a memory buffer for the whole
output.
TEST=pkg/vm_snapshot_analysis/test/precompiler_trace_test.dart
Change-Id: I7c2b3fbf1f6b6bee950c2d23809e68e4698f84f4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175780
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
In particular, make it so that the type testing stub testing
framework can use the same indirect stub call generation as
the flow graph compiler. This avoids having to change generation
in two places if we later update how indirect calls are generated.
Other changes:
* Generate a register mask of modified registers instead of a boolean
for more precise reporting of what was modified.
* Add a STCInternalRegs struct, like TTSInternalRegs, which exposes
the registers not preserved by the subtype test cache stubs.
* Be more precise in the TypeTestABI about which registers are preserved
on successful checks (namely, the inputs provided by AssertAssignable
and InstanceOf) and which may not be, and add the TTS and STC internal
registers to the non-preserved list.
TEST=Ran modified test on trybots for each supported architecture.
Cq-Include-Trybots: luci.dart.try:vm-kernel-linux-release-simarm64-try,vm-kernel-linux-release-x64-try,vm-kernel-linux-release-simarm-try,vm-kernel-linux-release-ia32-try
Change-Id: I58711213bc54572ea7f1e6525707fd193a000235
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/173721
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
This CL allows register allocator to mark functions as frameless
in AOT bare instructions mode if they don't contain calls (with an
exception for write barrier related calls), don't require
spills and don't use optional or named parameters.
Calls to Write Barrier helper stubs introduce some complexity
on ARM/ARM64, where we need to take into account that return
address needs to be explicitly spilled from LR register. To keep
the code size balance (frame setup vs manual LR spilling on WB
slow path) we allow one instruction with a write barrier
per frameless function.
Flutter Gallery snapshot becomes 800KB smaller (3% reduction), but
APK size for some reason increases by .1%. On a large internal
application effect is much smaller (60K - 0.16% reduction).
Flutter Gallery is disproportionally affected by the change due to
abnormal amount of small getters originating from localizations:
each localized phrase becomes a getter returning a constant on a
localization specific class.
TEST=tested through normal test suite
Cq-Include-Trybots: luci.dart.try:vm-kernel-linux-release-simarm-try,vm-kernel-linux-release-simarm64-try,vm-kernel-precomp-linux-release-simarm-try,vm-kernel-precomp-linux-release-simarm64-try,vm-ffi-android-release-arm64-try,vm-ffi-android-release-arm-try,vm-kernel-precomp-android-release-arm_x64-try,vm-kernel-precomp-android-release-arm64-try
Change-Id: I86cb45a57567ee654ead388957ac4e561634ef9c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175304
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Assembler now always knows whether LR contains return address
or can be safely cloberred.
TEST=tested through normal test suite
Cq-Include-Trybots: luci.dart.try:vm-kernel-linux-release-simarm-try,vm-kernel-linux-release-simarm64-try,vm-kernel-precomp-linux-release-simarm-try,vm-kernel-precomp-linux-release-simarm64-try,vm-ffi-android-release-arm64-try,vm-ffi-android-release-arm-try,vm-kernel-precomp-android-release-arm_x64-try,vm-kernel-precomp-android-release-arm64-try
Change-Id: I0b436509389cfd29ee413fd28930fb2d6b07616e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/174468
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This CL enables dart:ffi on Fuchsia.
It has the necessary VM changes for x64 and arm64.
- Allocate VM callback trampoline memory pages with RX.
- Do not use x18 on arm64.
- Save x18 on arm64 in Thread to be able to restore it on exceptions.
We do not have a bot testing this
https://github.com/dart-lang/sdk/issues/38752.
The bot only tests the build, it does not run the emulator.
Manual build and test steps x64 Fuchsia emulator:
```
tools/build.py --os=fuchsia -m debug fuchsia_ffi_test_package
xvfb-run third_party/fuchsia/sdk/linux/bin/femu.sh --image qemu-x64 -N --headless
third_party/fuchsia/sdk/linux/bin/fserve.sh --bucket fuchsia-sdk --image qemu-x64 --device-name step-atom-yard-juicy
third_party/fuchsia/sdk/linux/bin/fpublish.sh out/DebugFuchsiaX64/gen/dart_ffi_test_debug/dart_ffi_test_debug.far
third_party/fuchsia/sdk/linux/bin/fssh.sh --device-name step-atom-yard-juicy run fuchsia-pkg://fuchsia.com/dart_ffi_test_debug#meta/dart.cmx --ignore-unrecognized-flags --packages=/pkg/data/.packages --disable-dart-dev /pkg/data/tests/ffi/all_positive.dart
```
Manual build and test steps arm64 Fuchsia emulator:
```
tools/build.py --no-start-goma --os=fuchsia -m debug -a arm64 fuchsia_ffi_test_package
xvfb-run third_party/fuchsia/sdk/linux/bin/femu.sh --image qemu-arm64 -N --headless --experiment-arm64
third_party/fuchsia/sdk/linux/bin/fserve.sh --bucket fuchsia-sdk --image qemu-arm64 --device-name step-atom-yard-juicy
third_party/fuchsia/sdk/linux/bin/fpublish.sh out/DebugFuchsiaARM64/gen/dart_ffi_test_debug/dart_ffi_test_debug.far
third_party/fuchsia/sdk/linux/bin/fssh.sh --device-name step-atom-yard-juicy run fuchsia-pkg://fuchsia.com/dart_ffi_test_debug#meta/dart.cmx --ignore-unrecognized-flags --packages=/pkg/data/.packages --disable-dart-dev /pkg/data/tests/ffi/all_positive.dart
```
Note that running on the arm64 emulator takes over an hour.
This has been tested on an Estelle device.
TEST=Manual test steps above.
The AOT mode has seen an initial test in g3 by rolling gen_snapshot and
the flutter runner.
Arm64 x18 treatment along the lines of
https://dart-review.googlesource.com/c/sdk/+/119481:
- FfiCallInstr, does not modify x18 at all. We do not have to do
anything special when having a C++ frame on top of a Dart frame.
- NativeEntryInstr and NativeReturnInstr, saves and restores x18 with
PushNativeCalleeSavedRegisters && PopNativeCalleeSavedRegisters. Also
save to the thread field in both places. That way the JumpToFrame stub
can load from the thread field.
Closes: https://github.com/dart-lang/sdk/issues/44434
Change-Id: Ide29369c878fed5909a0d6f7d4c3f7508e179f25
Cq-Include-Trybots: luci.dart.try:vm-fuchsia-release-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/173273
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
If multiple threads want to obtain metadata they might both evaluate and
possibly cache the result of evaluation. Since the kernel loader
initialy adds metadata mappings (the value being kernel offsets) we use
the existing `IG->program_lock()` which the kernel loader already holds.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=Tests using --enable-isolate-groups with JIT sharing.
Change-Id: I3b618f196abe9f7b584e4135a72a0017399ff2d5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175301
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
This CL makes use of the now included constant constructor coverage
in the dill file.
It works like this:
* When the CFE evaluates constants, every constant constructor
invocation evaluated saves the reference to the constructor in the
`Source` (from the Components uri to source table) for the callers
Library.
* This data is loaded into the VM in a "raw" format.
* When a request for coverage comes in, the VM - on top of the normal
coverage processing - goes through all scripts to find constant
constructor coverage for the requested script and offset. Note that
all scripts must be checked because library A can have evaluated a
constructor from library B - so even if only coverage for library B
was requested, library A has to be checked.
For all constructors found the start and end position is reported as
covered. Note that this does not mark any initializes and there are
(at least currently) no good way of marking which initializes were
evaluated (because it has to be stable across edits even when the
`advanced invalidation feature` is enabled).
* Note that the reason for the coverage to work on references - as
hinted above - is because we want it to be stable across hot reloads
even if/when advanced invalidation is enabled. This means, that
library A cannot record "positional coverage" for library B because
library B might get (for instance) new comments that will make any old
offsets invalid. By using references we always lookup in the current
world and use the correct offsets.
https://github.com/dart-lang/sdk/issues/38934
TEST=Existing test suite, new tests for the new coverage added.
Change-Id: I29531247a4b91a99d9a459cfdefbb9798e9c948f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175246
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Remove the use of Fields, which have since the metadata mechanism was introduced come to require global registration.
Retain some sloppiness matching of declarations by name instead of identity for the sake of hot reload.
TEST=ci
Change-Id: Ifa4cc7724096c606f994b057b7838e124ceb3626
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175141
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Emphasize that the operation is going away,
and mark constructor as deprecated.
TEST= Refactoring+deprecation only, covered by existing tests.
Change-Id: I82aa044cd2cf7bf347b624371399f44bda8f4a07
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/173261
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
The layout of WeakProperty is defined in C++ instead of Dart. Add missing recognition of its accessors so the compiler can use direct field access instead of always going through natives. Compare LinkedHashMap.
Change the sentinel for WeakProperty lists to object null so that no special constructor is needed.
TEST=ci
Bug: https://github.com/dart-lang/sdk/issues/44333
Change-Id: I8686383053c2c345c972b6615b514a1381e79fda
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/175001
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
The Next() method on TokenPositions used to increment the internal
value_ field, but now creates a new TokenPosition with value_ + 1.
There are only three places this is used:
* Getting the token position after the end token position for
implicit closure functions in the scope builder.
* Getting the token position after the end token position for
variable declarations in the scope builder.
* Iterating over the token positions on a single source line in
the debugger.
So the overhead of creating new TokenPositions vs. mutating the original
should be limited, compared to the benefit of being able to assume
TokenPosition values are constant once created. There's too much
dependence on the copy and copy assignment operators due to the previous
possibility of mutation to make the internal field constant at the
moment without much more sweeping changes, unfortunately.
Also remove the copy assignment in initializing TokenPosition constants.
TEST=Tested using existing tests on trybots.
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-nnbd-linux-debug-x64-try,vm-kernel-precomp-linux-debug-x64-try,vm-kernel-nnbd-linux-debug-x64-try,vm-kernel-linux-debug-x64-try,vm-kernel-linux-release-x64-try,vm-kernel-nnbd-linux-release-x64-try,vm-kernel-precomp-linux-release-x64-try,vm-kernel-precomp-nnbd-linux-release-x64-try,vm-kernel-linux-product-x64-try,vm-kernel-precomp-linux-product-x64-try
Change-Id: Ie18b7f45bd9c6a43647ecd189330d91a4dff373b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/174922
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Clement Skau <cskau@google.com>
We serialize all changes to patchable call state to ensure we always
make progress (e.g. transition from Monomorphic -> Polymorphic).
Only if the miss handler actually needs to patch the patchable call do
we stop mutators - if it only updates ICData we don't have to do that.
=> In the future we might introduce a more clever mechanism to avoid
stopping mutators.
The CL also moves some locks from Isolate to IsolateGroup to ensure
all mutators use the same lock, since they operate on shared data
structures.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=Existing isolate tests that --enable-isolate-groups.
Change-Id: I4a11a8b8bb65581c6aba11cdf73acdea0f24a502
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/174469
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
The enum `ProcedureStubKind` together with the flag `isSynthetic`
replaces the flags `isForwardingStub`, `isForwardingSemiStub`,
`isNoSuchMethodForwarder` and `isMemberSignature`.
The semantics of the existing properties on `Procedure` is unchanged.
The new MixinStub and MixinSuperStub stub kinds are not used yet and
the stub target for NoSuchMethodForwarder is not set yet.
TEST=refactoring
Change-Id: I6e81970dbb4baf0229f43c2a0bf0d5e575e65043
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/174462
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
With lightweights isolates enabled we need to ensure to update entries
in MetamorphicCache in sequence with mutual exclusion.
This CL adds appropriate locking for the MegamorphicCache.
Right now this is safe in AOT because the entire SwitchableCallMiss
handler runs with stopped mutators. A future CL will relax this. That
future CL will also move the megamorphic mutex from Isolate to
IsolateGroup, since the megamoprhic caches are shared within an isolate
group.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=CL is purely a refactoring.
Change-Id: I30305b04027d2bf9b4d5f6b1700bf158d38bdba7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/174467
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Since they are accessed via closures, dynamic calls are handled via
dynamic closure call dispatchers and so no non-covariant argument
checking remains at this point.
TEST=Existing FFI tests on trybots, also added a few dynamic cast
tests just in case.
Bug: https://github.com/dart-lang/sdk/issues/44343
Cq-Include-Trybots: luci.dart.try:vm-precomp-ffi-qemu-linux-release-arm-try,vm-ffi-android-product-arm64-try,vm-ffi-android-product-arm-try
Change-Id: If8daa2d71de4e9391dd35b31b62b67a8e7e69ffe
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/174463
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
This reverts commit 5370c56c80.
Reason for revert: Failures on
dartk-android-product-arm
dartk-android-product-arm
dartkp-linux-release-arm-qemu
like this:
sizeof(ScriptLayout) got 64, Script_InstanceSize expected 56
../../runtime/vm/dart.cc: 160: error: CheckOffsets failed. Try updating offsets by running ./tools/run_offsets_extractor.sh
sizeof(ScriptLayout) got 64, AOT_Script_InstanceSize expected 56
../../runtime/vm/dart.cc: 160: error: CheckOffsets failed. Try updating offsets by running ./tools/run_offsets_extractor.sh
Original change's description:
> [VM] Read and report constant constructor coverage from dill
>
> This CL makes use of the now included constant constructor coverage
> in the dill file.
>
> It works like this:
> * When the CFE evaluates constants, every constant constructor
> invocation evaluated saves the reference to the constructor in the
> `Source` (from the Components uri to source table) for the callers
> Library.
> * This data is loaded into the VM in a "raw" format.
> * When a request for coverage comes in, the VM - on top of the normal
> coverage processing - goes through all scripts to find constant
> constructor coverage for the requested script and offset. Note that
> all scripts must be checked because library A can have evaluated a
> constructor from library B - so even if only coverage for library B
> was requested, library A has to be checked.
> For all constructors found the start and end position is reported as
> covered. Note that this does not mark any initializes and there are
> (at least currently) no good way of marking which initializes were
> evaluated (because it has to be stable across edits even when the
> `advanced invalidation feature` is enabled).
> * Note that the reason for the coverage to work on references - as
> hinted above - is because we want it to be stable across hot reloads
> even if/when advanced invalidation is enabled. This means, that
> library A cannot record "positional coverage" for library B because
> library B might get (for instance) new comments that will make any old
> offsets invalid. By using references we always lookup in the current
> world and use the correct offsets.
>
> https://github.com/dart-lang/sdk/issues/38934
>
> TEST=Existing test suite, new tests for the new coverage added.
>
> Change-Id: I925963d1a9b9907efe621c72deb7348fa3be5ae8
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/171949
> Commit-Queue: Jens Johansen <jensj@google.com>
> Reviewed-by: Ben Konyi <bkonyi@google.com>
> Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
TBR=vegorov@google.com,bkonyi@google.com,jensj@google.com
Change-Id: I5187e6749d59ded250ec0933a94db0536485b70a
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/174470
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This CL makes use of the now included constant constructor coverage
in the dill file.
It works like this:
* When the CFE evaluates constants, every constant constructor
invocation evaluated saves the reference to the constructor in the
`Source` (from the Components uri to source table) for the callers
Library.
* This data is loaded into the VM in a "raw" format.
* When a request for coverage comes in, the VM - on top of the normal
coverage processing - goes through all scripts to find constant
constructor coverage for the requested script and offset. Note that
all scripts must be checked because library A can have evaluated a
constructor from library B - so even if only coverage for library B
was requested, library A has to be checked.
For all constructors found the start and end position is reported as
covered. Note that this does not mark any initializes and there are
(at least currently) no good way of marking which initializes were
evaluated (because it has to be stable across edits even when the
`advanced invalidation feature` is enabled).
* Note that the reason for the coverage to work on references - as
hinted above - is because we want it to be stable across hot reloads
even if/when advanced invalidation is enabled. This means, that
library A cannot record "positional coverage" for library B because
library B might get (for instance) new comments that will make any old
offsets invalid. By using references we always lookup in the current
world and use the correct offsets.
https://github.com/dart-lang/sdk/issues/38934
TEST=Existing test suite, new tests for the new coverage added.
Change-Id: I925963d1a9b9907efe621c72deb7348fa3be5ae8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/171949
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
All existing embedders have been opted into --lazy-async-stacks, the
VM also uses it as it's default in all configurations.
After this CL, any user of --causal-async-stacks will get an error
message when trying to use it.
=> In any such case, please simply remove the flag.
TEST=Exhaustive CQ.
Bug: https://github.com/dart-lang/sdk/issues/37668
Change-Id: Ia440afcf2dba464aa8b8cf381b93bbac8eb9f8dc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/172564
Commit-Queue: Clement Skau <cskau@google.com>
Reviewed-by: Clement Skau <cskau@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
An address containing an object header is sometimes interpreted as a object slot due to array truncation and concurrent marking/sweeping. Always accessing it as a word assuages TSAN that it won't be subject to tearing, and allows for the removal of TSAN suppressions from header access. In turn, this will allow TSAN to verify some acquire/release header accesses.
TEST=tsan
Bug: https://github.com/dart-lang/sdk/issues/44091
Change-Id: I7bf6449bf7dfeabd9db76e4bb37456e3be2d5124
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/172861
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Both ARM and ARM64 variants did not account for the
fact that TransitionNativeToGenerated will clobber
LR on slow path.
TEST=tests/ffi/regress_jump_to_frame_test.dart
Cq-Include-Trybots: luci.dart.try:vm-ffi-android-release-arm-try,vm-ffi-android-release-arm64-try,vm-kernel-linux-release-simarm64-try,vm-kernel-linux-release-simarm-try,vm-kernel-precomp-linux-release-simarm-try,vm-kernel-precomp-linux-release-simarm64-try
Change-Id: I40d48b720b2a7f31ff20903a887295ab2034662c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/173962
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
To prevent unoptimized compilations of functions from modifying
ICData objects, we'll ensure to populate the ICData with the right
information when it's created.
Furthermore this moves out resolution related code from ICData which
really doesn't belong there.
TEST=Refactoring of already tested code.
Issue https://github.com/dart-lang/sdk/issues/36097
Change-Id: I4b71118c02687a047077f2709c188b5d8a825de2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/173968
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
The `ICData::AddTarget()` is always used directly after allocation of an
ICData (if needed). We'll remove it and add a `ICData::NewForStaticCall()`
which guarantees the ICData is correctly initialized from the start.
This avoids mental overhead of needing to think about whether
`AddTarget()` needs locking or not.
TEST=Refactoring of already tested code.
Issue https://github.com/dart-lang/sdk/issues/36097
Change-Id: I3529dd881887afb281c83b72117bdb9247a8dff0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/173760
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
As part of making lightweight isolates work in JIT, we will need to
ensure that whenever a new isolate is spawned it will get it's initial
global field table populated.
In order to achieve this we make the isolate groups initial field table
the authoritive place where we
a) register initial static field values
b) serializer reads them from, deserializer writes them to
This allows us to also remove the `FieldLayout::initial_saved_value_`
that was present for both static and non-static fields. In reality this
initial saved value is only meaningful for static fields though it was
kept in memory as well as (de)serialized even for non-static fields.
The one place where it was actually used for non-static fields was
incorrect and should instead use `null`.
The removal of this field results in net removal of code in this CL.
Issue https://github.com/dart-lang/sdk/issues/36097
TEST=Internal refactoring, relying on existing test coverage.
Change-Id: I088a87e2ea159bac7fa7f1f360da553d752e6569
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/173263
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
As part of making lightweight isolates work in JIT, we will need to
ensure that whenever a new static field is loaded, it will get a new
slot on every isolate and the possibly initial static value is set in
all isolates's field state.
In order to achieve this we first move field registration out of
Field::New*() - to the place where the field is created and the initial
static field value is known.
In a future CL we will make a field registration be performed on all
isolates in a group.
TEST=CL is internal refactoring, existing test coverage.
Issue https://github.com/dart-lang/sdk/issues/36097
Change-Id: I802ae55b841be173733dbd0ad3dbffeebd5c1889
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/173260
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
This disables field unboxing in JIT with enabled lightweight isolates because currently unboxed generated code won't behave correctly if another isolate updates field unboxed state: for that guarded_cid updates would require stopping all isolates, getting to a safepoint.
Use of field guards(guarded_cid, is_nullable) in optimized compiler is concurrent-safe because each optimized compiler operates on its own clones of fields, which are checked for consistency with latest(mutator) state just before optimized code is installed.
Use of field guards in optimized generated code is safe because vm is brought to a safepoint and optimized code is deoptimized as soon as field guards are invalidated.
Use of field guards in generated unoptimized code outside of unboxed fields(transition to boxed from previously unboxed field is not safe which is why field unboxing is disabled) and use of field guards in unoptimized compiler is safe because transitions through guarded_cid and is_nullable makes less and less optimistic assumptions about the field state.
Issue https://github.com/dart-lang/sdk/issues/36097.
TEST=existing test suite
Change-Id: I00d37a49df483814c846b17c9c49e0dc6ce701e1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/172860
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
Tess Strickland