Remove separate table for predefined classes. The original allocation stats CL had this separate to allow directly embedding the table address into code, but we no longer embed addresses to support AppAOT and AppJIT.
Change-Id: Ida3d0764ac8ff179c0541ee73a3283c9c50affab
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/97286
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
- Don't waste time scrubbing or qualifying function metadata names.
- Don't waste time scrubbing or lib qualifying function names for timeline events.
- Give intrinsic functions a grace usage counter.
- Fix wrong flag guarding stack overflow name-based slow paths.
Change-Id: Ib78e7e4f8de51208266190fff2d1f7eb8d80c329
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/97174
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
See https://github.com/tc39/proposal-regexp-named-groups
for a high-level description of the feature and examples. This is one of the
features requested in https://github.com/dart-lang/sdk/issues/34935.
This is a partial implementation because while there is a way to retrieve
groups via Dart by name, it requires casting the returned Match to the
new RegExpMatch interface to avoid changing the RegExp interface.
Changing the RegExp interface will happen in a future update, since there
are other planned changes to the RegExp interface coming soon and that way
we only change it once. See https://github.com/dart-lang/sdk/issues/36171
for more details on the planned changes.
Also, since only BMP regular expressions are supported, not full
Unicode ones (i.e., those with the /u flag in ECMAscript), \k<NAME>
will only be parsed as a named back reference if there are named
captures in the string. Otherwise, the \k will be parsed as the identity
escape for backwards compatibility. The new tests illustrate this
difference.
Change-Id: Ieeb0374813db78924c9aa8ac3e652dfb6d4a5934
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/95461
Commit-Queue: Stevie Strickland <sstrickl@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Jenny Messerly <jmesserly@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This removes the 3 fields from the classes in Dart and instead describes
the layout in C++ via a RawTypedDataView class (as already do with
normal RawTypedData). The existing "semi" TypedDataView handle class is
changed to be a real handle class.
This decreases performance of some microbenchmarks due to field guards
not being used anymore (before the JIT could add a field guard to view classes
guarding that only normal typed data is used as backing store (and not e.g. external
typed data)
Issue https://github.com/dart-lang/sdk/issues/35154
Issue https://github.com/dart-lang/sdk/issues/31954
Change-Id: I7a0022b843a4c0fa69f53dedcc4c7bd2117cdc37
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/96806
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
See https://github.com/tc39/proposal-regexp-lookbehind
for a high-level description of the feature and examples. This is one of the
features requested in https://github.com/dart-lang/sdk/issues/34935.
This work takes the feature as present in the v8 engine and appropriately
merges it into our irregexp fork. Notable changes to the irregexp codebase to
introduce this feature:
-----
We can no longer assume that all matching proceeds forwards, since lookbehind
matching proceeds backwards. Similarly, we cannot assume that we can only be
at the start of a string if we started matching from that point. The direction
of matching must also be taken into consideration when doing bounds checking,
which previously assumed the engine would never attempt to look before the
start of a string.
-----
We may now parse backreferences to captures before the capture they
reference, since we parse regular expressions left to right, but lookbehinds
perform captures as they evaluate the string from right to left. Since
RegExpBackReference objects contain a pointer to their corresponding capture,
this means that we may need to create RegExpCapture objects prior to the
parsing of the corresponding captured subexpression.
Thus, RegExpCapture objects are now only initialized with their index, and the
body is set later when the subexpression is encountered and parsed. This means
any method that operates on the body of a RegExpCapture can no longer be const,
which also affects the rest of the RegExpTree class hierarchy. This also means
that we don't have a valid max_match length for backreferences based off the
capture body, and must assume they can end up being any length.
-----
Change-Id: Iffe0e71b17b1a0c6fea77235e8aee5c093005811
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/94540
Commit-Queue: Stevie Strickland <sstrickl@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This refactoring moves receiver variable (previously known as this_variable)
from ScopeBuildingResult into ParsedFunction, like other special variables.
This is done as ScopeBuildingResult is AST-specific and not available
in bytecode, but certain flow graph builders use receiver variable
(for example to load instantiator type arguments for type arguments
checks).
This CL also introduces convenience ParsedFunction::ParameterVariable()
method to reduce repetitive incantations
parsed_function->node_sequence()->scope()->VariableAt(..)
to a more readable
parsed_function->ParameterVariable(..)
Change-Id: I427536abfa412de9916b79cf2e56e06f2f2f1d71
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/96842
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Auto-Submit: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Aart Bik <ajcbik@google.com>
/sys/kernel/debug/tracing is the old path[1] and only present for
backwards compatibility. Check the new path first otherwise accessing
/sys/kernel/debug/tracing will cause debugfs to be mounted. If
permissions are not set correctly after the mount, the user process may
not have a way to access the trace_marker.
[1] https://www.kernel.org/doc/Documentation/trace/ftrace.txt
Bug: None
Change-Id: Ifbd967c0f7298c8877c23bd4908d172b94f9e2d2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/96832
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Rationale:
The problem was that we were evaluating field
initializers while still loading the constant
table. This hit two asserts (1) having pending
potential_natives() when entering codegen and
(2) not being able to evaluate constants
since the table has not been loaded yet. The
solution is to simply postpone enum field
initialization (forced to avoid hot reload
issues) while loading the constant table
until right after the table is ready.
https://github.com/dart-lang/sdk/issues/36153
Change-Id: I5060476e5b3b49e555cfc507fb398ef0144b44d0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/96844
Commit-Queue: Aart Bik <ajcbik@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
For some reason this code used deopt_id from the environment attached
to the AssertAssignable instruction, rather than deopt_id from the
instruction itself.
Under certain conditions this deopt_id is -1 which usually does
not cause any problems because no other code uses it.
Compiler is now changed in a way that only sets Environment::deopt_id_
for outer environments and innermost environment always has deopt_id_ set
to DeoptId::kNone.
This bug manifested itself as a very rare crash on lib_2/convert/chunked_conversion_utf8_test.dart
test on optcounter bot.
This change also converts an assertion that verifies that deoptimization target
always exists into a FATAL to make such crashes more informative.
TEST=runtime/tests/vm/dart/licm_and_assert_strengthening_test.dart
Change-Id: Ib58237b0f4ae279dcf9d88cac031156e88bf4828
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/96657
Auto-Submit: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
Until a better solution is found, disable dual mapping of code on docker
containers that fail setting exec permissions on dual mappings.
Change-Id: Ic7477e1ef70ae0ea4d0187284702d5a3ee594edf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/96668
Commit-Queue: Régis Crelier <regis@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
Auto-Submit: Régis Crelier <regis@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
This change extracts code which reads kernel in order to get
covariance attributes of parameters into a separate function.
This removes code duplication and makes it easier to hook up
reading of covariance attributes from bytecode in future.
Change-Id: Ia19caf3edaf45df9e0bb1bdc715fac21d26788dc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/96560
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Auto-Submit: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Samir Jindel <sjindel@google.com>
The catch entry moves are serialized in a space-efficient manner using a
suffix tree. The deserialization logic was not always correctly reading
the right catch entry moves which can cause incorrect stack frame on
catch entries and therefore can cause crashes.
Change-Id: Ic0eda8924f80262f5477ed5606eb6f74c55242c3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/96104
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
These arise when the constant evaluator partially evaluates collections
containing spreads or control-flow constructs with unevaluated
subexpressions. They are removed by the final constant evaluation.
Change-Id: Icdd155c4805cbcefe6aa4b45c2f85ec258e7bd36
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/95760
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Samir Jindel