const objects that are declared in .h files are supposed to have
out-of-line definitions in their corresponding .cc file. It seems like
CL 101222 happened to expose this for Message::kIllegalPort.
Change-Id: I9656037581eb6406eaf3289dfcf705db90862a26
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/102122
Commit-Queue: Matthew Dempsky <mdempsky@google.com>
Auto-Submit: Matthew Dempsky <mdempsky@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
There were rare crashes
../../runtime/vm/compiler/call_specializer.cc: 1393: error: expected: call->MatchesCoreName(Symbols::_simpleInstanceOf())
version=2.3.0-edge.796ebc6069bde3a59475a9b45075f49e50b0cc34 (Thu May 9 09:38:28 2019 -0700) on "linux_x64"
thread=82540, isolate=vm-service(0x558748c5d200)
pc 0x000055874635dd6c fp 0x00007fa94dd3bf30 dart::Profiler::DumpStackTrace(void*)
pc 0x0000558745f90332 fp 0x00007fa94dd3c010 dart::Assert::Fail(char const*, ...)
pc 0x000055874653909b fp 0x00007fa94dd3c0a0 dart::CallSpecializer::ReplaceWithInstanceOf(dart::InstanceCallInstr*)
pc 0x0000558746496ed6 fp 0x00007fa94dd3c0f0 dart::FlowGraphVisitor::VisitBlocks()
when running
tools/test.py --repeat 5000 -n dartkb-mixed-linux-debug-x64 language_2/null_test
at the rate ~1-3 crashes per 30,000 test cases.
The problem is that in function
bool InstanceCallInstr::MatchesCoreName(const String& name) {
return function_name().raw() == Library::PrivateCoreLibName(name).raw();
}
'function_name().raw()' is evaluated before PrivateCoreLibName(name) is called
and saved in a temporary (register). PrivateCoreLibName may trigger GC and
relocate objects. In such case, 'PrivateCoreLibName(name).raw()' results in a
moved object, which is compared to a stale object address.
This CL fixes InstanceCallInstr::MatchesCoreName and other similar places
by introducing Library::IsPrivateCoreLibName, which is also a little bit more
efficient as it avoids extra symbol table lookup.
Change-Id: I4dc91c586b0c595a3e85d6da13b98fc2248fb8fd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/102120
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Aart Bik <ajcbik@google.com>
The stack slot in question may contain a stale value, but it could
be scanned by GC, so the fix is to clean it up even if it looks
unused.
While debugging I saw bytecode PCs in that stack slot.
So it is likely that compact bytecode instructions (68de477535)
increased the probability of these crashes, as with compact bytecodes
PCs could be unaligned and treated as Dart objects by GC, while
previously PCs were always aligned and treated as Smis by GC,
effectively masking the failure.
Fixes https://github.com/dart-lang/sdk/issues/36909
Change-Id: I82ccaa2bd87aca4ca4b44c9db69b0efd18dad955
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/102061
Reviewed-by: Régis Crelier <regis@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
While adding support for new compact bytecode instructions,
VM also keeps support for old bytecode instructions to preserve
backwards compatibility and allow soft transition.
This change is separate from bytecode generator changes in order
to test VM with old bytecode generator.
Corresponding bytecode generator changes:
https://dart-review.googlesource.com/c/sdk/+/99400
Change-Id: Icf5ceee7d51f27ffe3f79d0eae81e0ddc0a7e855
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/101062
Reviewed-by: Ryan Macnak <rmacnak@google.com>
It already is a static method in implementation, so this way
we don't duplicate the work of looking up the library. In addition,
it checks has_pragma, so we don't need to check before calling it.
Change-Id: I88281cf22615e30157c842c570bd0f6b499a6a3d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/101821
Commit-Queue: Teagan Strickland <sstrickl@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
The Fuchsia SDK can now be consumed by non-Fuchsia buildroots to produce
Fuchsia artifacts.
The Fuchsia SDK comes with a JSON manifest that describes the various SDK
"parts". GN targets are stamped for each of these parts. The location of these
GN targets can be configured. That location is set to |fuchsia_sdk_root| in
each buildroot. This variable is defined in //build/fuchsia/sdk.gni in each
buildroot. For buildroots that don't care or know about the Fuchsia SDK, that
file may not exist. This is why, the import of that file is guarded behind
the is_fuchsia flag. When the Fuchsia SDK is enabled, that file will define
values for two required variable |using_fuchsia_sdk| and |fuchsia_sdk_root|.
The first flag defines if the SDK is being used. If unset (but defined), the
builds are in-tree. Eventually we want only SDK builds. |fuchsia_sdk_root|
is set to the spot in the buildroot where the GN targets for the SDK parts
are stamped.
Change-Id: I604612c8d6a21efb07b323610e80b596abc1a6dd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/101540
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Chinmay Garde <chinmaygarde@google.com>
Message is a C++ type with a simple ownership model appropriate for
std::unique_ptr. This CL applies the following changes:
1. All uses of "new Message(...)" are replaced with
"Message::New(...)", which is effectively
"std::make_unique<Message>(...)". (The latter was only added in C++14,
but Dart still compiles in C++11 mode.)
2. All owning Message* are replaced with std::unique_ptr<Message>. The
notable exception is MessageQueue, which still uses raw Message*
internally to simplify the linked list handling.
3. All "delete message;" statements are removed.
4. Uses of "NULL" replaced with "nullptr" as necessary.
Change-Id: I05b5804289f2a225bfa05d3c1631129358fed373
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/101222
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Matthew Dempsky <mdempsky@google.com>
Forward jumps in bytecode usually go to the 'else' part (skipping 'then')
or exit loops. In order to generate Branch instructions in flow graph
which would represent ifs and loop conditions more naturally the first ('true')
successor of a BranchInstr should correspond to fallthrough in bytecode, and not the
target of a Jump bytecode instructions.
This results in a slightly better register allocation.
Golem shows overall improvement +0.4620% on x64 and +0.8395% on arm64.
Issue: https://github.com/dart-lang/sdk/issues/36429
Change-Id: I1ea581ef9f5998eb960914680d0e867c57639f1f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/101361
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
'is' checks which are represented as _simpleInstanceOf() calls
are sometimes recognized by Token::kIS and not by a target of a call.
Before: TypeChecks.IsCheck(RunTime): 279.63057234726693 us.
After: TypeChecks.IsCheck(RunTime): 200.77956524794217 us.
(best of 5 runs)
Issue: https://github.com/dart-lang/sdk/issues/36429
Change-Id: I5a22222c59c33d2fa8262383a597c2c013ab61b6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/101322
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
When provided, the opcode is implicitly inserted before each provided
MatchCode, which simplifies test cases that contain kMoveGlob or
kMoveParallelMoves before all other types of entries.
Change-Id: I51119fb66176cb54e1588687aa53b8d4ce80d9b5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/101290
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Teagan Strickland <sstrickl@google.com>
Once breakpointLocation has been resolved into token position, line breakpoint and column breakpoint should be the same. Then check only token position to remove possible duplicates.
Also some variable renaming. A "bpt" could be class "Breakpoint" or class "BreakpointLocation" in different part of functions. Rename the variables to reduce confusion.
Bug: https://github.com/dart-lang/sdk/issues/35368
Change-Id: I0875b5b48300a800acacf55440b65d892f4e9301
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/101060
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Zichang Guo <zichangguo@google.com>
Previously when computing aliasing during load propagation we only
propagated aliasing from X[C'|S'] to *[C''|S''] for S' < S''.
The code incorrectly assumed that this propagation is symmetric (which
it is not) and expected that *[C|S] would be cross aliased with X[C'|S']
when *[C|S] is visited.
Now we split symmetric and non-symmetric parts of the aliasing
computation: X[C'|S'] propagates aliasing to X[C''|S''] for S' < S'' -
which is symmetric. Separately if X is an aliased instance we propagate
aliasing from X[C'|S'] to *[C|S] for all sizes S.
Change-Id: Iccd4c73a18ffd3f60fd179df43a6b117e0844b64
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/101281
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
When resolving column breakpoint, debugger will lookup the character in the source of script to make sure the column has been specified within the range of a valid identifier.
With this CL, column breakpoint will be resolved previous safepoint position, if requested column falls within [saftpoint, next_safepoint/end of line(smaller one)]. For example, setting column breakpoint on left bracket of a function call might be resolved to function call now. Setting on the end of line will resolved to previous safepoint.
BUG: https://github.com/dart-lang/sdk/issues/36642
Change-Id: I16427772fde4c653da7629e3340282ef1d9046eb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/100404
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Zichang Guo <zichangguo@google.com>
Previously, IsolateReloadContext::CheckpointClasses() was filling
local_saved_class_table with raw pointers to classes and at the same
time it was adding classes to the set which is based on Array.
After that local_saved_class_table was saved into saved_class_table_
were it becomes visible to GC. However, adding an element to the set
may trigger GC in the middle and pointers for already processed
classes in local_saved_class_table are not visited and are not updated
if GC moves a Class object.
Also, IsolateReloadContext::VisitObjectPointers was not visiting
classes in saved_class_table_ properly as it was interpreting it as
an array of saved_num_cids_ pointers (while it is an array of
ClassAndSize elements).
This change fixes flaky crashes in vm/dart/trigger_gc_in_native_test.
Change-Id: I25b2e50995cf580bc9347f06875d344f75a1a950
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/100728
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Background compiler could be running while Dart_SortClasses() clears all
code. It causes flaky crashes on vm/dart/appjit_bytecode_simple_test test
as background compiler may need to access bytecode, which can be read in
mutator thread only.
Also, background compiler may potentially add new code which would not be
compatible with rearranged class ids.
This CL stops background compiler in Dart_SortClasses() before code is
cleared to avoid these conflicts.
Change-Id: Ide30d469dc1c4b0e853a2244dc2ddfd5cb70d86a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/100726
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
vm/cc/GenKernelKernel* tests enabled interpreter by setting
FLAG_enable_interpreter in order to benchmark bytecode reading.
As a side effect, this enables interpretation of special functions
(like implicit getters) on other isolates such as kernel-service isolate.
They may even reach compilation threshold and unoptimized background
compilation is triggered. However, as isolate was created with
FLAG_enable_interpreter == false, unoptimized BackgroundCompiler was not
created, so it causes flaky crashes.
A less intrusive way to enable bytecode reading is to set
FLAG_use_bytecode_compiler.
Change-Id: Ie0601d43816b29c62fb0278ed4666d38fc4328c3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/100788
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Zach Anderson <zra@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
This work pulls in v8 support for these features with
appropriate changes for Dart and closes
https://github.com/dart-lang/sdk/issues/34935.
This adds support for the following features:
* Interpreting patterns as Unicode patterns instead of
BMP patterns
* the dotAll flag (`/s`) for changing the behavior
of '.' to also match line terminators
* Escapes for character classes described by Unicode
property groups (e.g., \p{Greek} to match all Greek
characters, or \P{Greek} for all non-Greek characters).
The following TC39 proposals describe some of the added features:
* https://github.com/tc39/proposal-regexp-dotall-flag
* https://github.com/tc39/proposal-regexp-unicode-property-escapes
These additional changes are included:
* Extends named capture group names to include the full
range of identifier characters supported by ECMAScript,
not just ASCII.
* Changing the RegExp interface to return RegExpMatch
objects, not Match objects, so that downcasting is
not necessary to use named capture groups from Dart
**Note**: The changes to the RegExp interface are a
breaking change for implementers of the RegExp interface.
Current users of the RegExp interface (i.e., code using Dart
RegExp objects) will not be affected.
Change-Id: Ie62e6082a0e2fedc1680ef2576ce0c6db80fc19a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/100641
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Stevie Strickland <sstrickl@google.com>
Ryan Macnak