We were only recording metadata positions when mirrors were enabled. Mirrors are not enabled for AOT, so this metadata became unavailable to the inliner. Now we always record metadata position.
The tree-shaker has been updated to know how to remove the metadata.
R=asiva@google.com
Review-Url: https://codereview.chromium.org/3003183003 .
AOT may infer the range of Cids to check in order to perform
'is' (instance-of) operation. It is possible that the range contains
the only Cid, so AOT can generate 1 comparison instead of 2.
Note that the optimization of 'x is T' where T is not extended nor
implemented does not fully cover this case, as T could be abstract with
a single subclass or implementor.
The notable real case for this optimization is 'x is double',
as double is an abstract class with single implementor _Double.
This CL also improves type propagation for InstanceOfInstr, and
enables printing of abstract types in IL printer.
R=rmacnak@google.com
Issue: https://github.com/dart-lang/sdk/issues/30480
Review-Url: https://codereview.chromium.org/3003793002 .
Summary:
1. Previously, in 'BuildGraphOfConvertedClosureFunction', the VM was unable to
correctly forward parameters to converted closure functions when
they were captured in the converted function's body. This could happen when, for
example, a closure was introduced into it by async conversion.
Now, this is fixed by an approach that mirrors the technique in
'BuildGraphOfFunction'.
2. Previously, local variables declared inside loop bodies were being saved in
the loop's enclosing context, so closures within the loop would see new
values initialized to the variable in subsequent iterations.
Now, this is fixed by creating nested contexts for all loops, regardless of
whether the loop variables are captured.
3. Previously, arity checks were not being performed on converted closures, so
they could be called with too few or too many arguments. In the former case, the
missing arguments would be filled in with garbage on the stack.
Now, the assembly generation in 'CompileGraph' inserts argument count checks
for converted closures as well as regular closures.
Test Plan:
Introduced new tests in the closure conversion suite to test each bug:
1. syncstart.dart
2. loop2.dart, blocks.dart, updated for_in_closure.dart
3. arity.dart
With these changes, closure conversion passes all co19 tests in non-checked mode, except those that are not passed without it:
python tools/test.py -m release -c dartk --vm-options "--reify --reify_generic_functions" co19
BUG=
R=dmitryas@google.com
Review-Url: https://codereview.chromium.org/3000333002 .
Finally clauses are inlined into try and catch blocks. This causes the parser to allocate at least two functions for any closure in a finally cause, only one of which will be registered by the flow graph builder. The unregistered function gets compiled, but the program visitor is unable to iterate it. To fix this, we use both the program visitor and the tree-shaker's work queue to apply fixups.
Fixes#30522R=asiva@google.com, cbernaschina@google.com
Review-Url: https://codereview.chromium.org/3003253002 .
The decision to grow is based on the fraction of the objects that became garbage in the previous scavenge. If the previous scavenge included a growth, the new size of new space does not affect this statistic. If the program's allocation pattern remains the same, the next scavenge will see the same garbage ratio and decide to grow again, even if we would have hit the desired garbage fraction at the current capacity. This CL changes the garbage fraction to use the post-growth capcity as the dominator to prevent this eager double-growth.
This change causes Flutter Gallery to stablize at a 4MB semispace instead of 16MB, with ~10ms instead of ~40ms scavenges while interacting with the time picker on a Nexus 4.
R=danunez@google.com
Review-Url: https://codereview.chromium.org/3003063002 .
This CL continues cleanup after Dart_MakeExternalString API was removed
in 5b694c1b1c.
* Replace Instruction::Effects() with Instruction::HasSideEffects().
* Prepare to clean up Instruction::Dependencies() - assert that it is
used only if AllowsCSE(). In such case it always returns
EffectSet::None().
* Clean up 2 separate maps for instructions with dependencies and
without dependencies in CSEInstructionMap, as it only works on
instructions with AllowsCSE() and, as a consequence, without
dependencies.
* Clean up code which was testing Dependencies() of CheckClassInstr
and CheckClassIdInstr.
* Fix LoadStaticFieldInstr::AllowsCSE() to take FLAG_fields_may_be_reset
into account - like in LoadStaticFieldInstr::Dependencies().
R=vegorov@google.com
Issue: https://github.com/dart-lang/sdk/issues/30474
Review-Url: https://codereview.chromium.org/3003593002 .
When a zero-sized string occurs as that last string in the Kernel
string table, the code would attempt to compute the address that lies
one element past the end of the string table's backing store. Though
this is benign in C++ as long as that address is not dereferenced, it
would trigger an assertion failure in TypedData::DataAddr.
Avoid triggering the assertion by performing the address arithmetic in
the caller based on DataAddr(0) rather than relying on the address
arithmetic in DataAddr.
This fixes issue 30420.
BUG=https://github.com/dart-lang/sdk/issues/30420R=aam@google.com, asiva@google.com
Review-Url: https://codereview.chromium.org/3003023002 .
Before this change, the column number of the StackOverflow error was
reported at the opening '(' of the function parameter list:
ReturnType function(...) { ... }
^
This change moves it to the opening '{':
ReturnType function(...) { ... }
^
In case of single statement functions with '=>', the location of the '='
is reported as the column number of the StackOverflow error.
R=asiva@google.com
Review-Url: https://codereview.chromium.org/3002833003 .
The virtual-collection component uses a div container as a viewport on
a fixed sized spacer div that emulates the full size of the content.
In the spacer div there is a relative positioned div that scrolls
both horizontally and vertically. While the internal items are fully
computed horizontally, vertically we render just a subset of the items.
This buffer component scrolls both horizontally and vertically due
to its father child relationship with the spacer div. When the viewport
is going to show items that are not rendered in the buffer we move
the buffer accordingly (it is relative positioned with a variable top)
and update the content.
Managing the header of a table though is challenging:
1. we want the header to be fixed vertically
2. we want it to scroll horizontally accordingly to the the rest of the
content
3. we want also to make this container took into consideration during
the width computation, to allow it to trigger the horizontal
scrollbar if it is wider that content.
4. we want the header to perceive the same available space as the
other items in the collection.
We cannot obtain (1) at the same time of (2) (3) and (4) via pure
CSS. The header must be child of just another element.
- If we make it children of collection itself we obtain just (1) while
we need to emulate the others via code.
- If we make it children of the viewport we obtain (2) (3) and (4),
but we need to emulate (1) via code.
The first implementation followed the second option. The side effect
though is that smooth scroll (touch or touchpad based) does not fire
the onScroll events required to keep the header on top fast enough to
avoid flickering.
Due to the fact that scroll is the main use case for this element the
new implementation uses the first approach. Vertical flickering is
a problem no more. We obtain (2) by changing the horizontal offset
of the container, possible flickering, but way less common.
We obtain (3) by adding an extra div in the viewport which has the
same minimum size of the header. We obtain (4) by updating the
width of the last header child during the resize operations.
R=asiva@google.com
Review-Url: https://codereview.chromium.org/2998103002 .
The Kernel C++ implementation no longer has classes like Library,
Class, Field, or String, so it's no longer necessary to explicitly
write `dart::` in most places.
BUG=
R=jensj@google.com
Review-Url: https://codereview.chromium.org/3001103002 .
The following problems are fixed in dart_bootstrap when it is used to
create AOT snapshot along with new kernel front-end:
* Data race between main isolate and service isolate when accessing
vmservice_io kernel program stored in DFE::kernel_vmservice_io_.
* Double-deletion of vmservice_io kernel file program from
VmService::LoadForGenPrecompiled / Dart_LoadLibrary /
LoadKernelProgram and then from DFE::~DFE.
It looks like both of these bugs were introduced in
c7faf2dc6b.
R=jensj@google.com, rmacnak@google.com
Review-Url: https://codereview.chromium.org/3002733002 .
Summary:
Previously, there was no support for generic methods in kernel. This prevented
us from being able to pass captured type arguments to the target top-level
function in converted closures, so these type arguments were always instantiated
to 'dynamic'.
Now, we save the type arguments to the closure creation operation in the
context, and read them out and forward them appropriately in closure wrapper
function. Since fasta doesn't currently support generic methods (their type
parameters are replaced by 'dynamic'), only top-level generic functions can
surface in kernel, as they are generated by closure conversion of closures that
capture type parameters of a class.
My focus here is enabling closure conversion to work in only these cases, and as
such, the code has some temporary "hacks" in the VM that may not work for
generic member functions or generic closures when they are enabled in fasta.
Test Plan:
I ran all the tests in closures/, and those which were previously expected to
crash due to missing VM support now pass and produce correct results.
Further testing is paused until we understand why the recent commit "[kernel]
Insert kernel bodies into VM heap" has broken all these tests.
Reviewers: regis@google.com, jensj@google.com, dmitryas@google.com
BUG=
R=dmitryas@google.com, jensj@google.com
Review-Url: https://codereview.chromium.org/2998803002 .