When encountering call this.m(...) we can check if m resolves to the same
method in all concrete subclasses of the receiver class. If it does then
we don't need any checks and can just use a StaticCall instead of InstanceCall.
This is allows us to improve code quality for cases like:
class Base {
var _field;
foo() { _field = true; }
}
class A01 extends Base { }
...
class A16 extends Base { }
Previously AOT would generate InstanceCall(get:_field) in the method foo.
However with this change we generate StaticCall(...) which subsequently gets
handled by the inliner.
R=fschneider@google.com
BUG=
Review URL: https://codereview.chromium.org/2055263002 .
Thess place were forgotten when changing all allocations in the background
compiler to old-space. New-space allocation is not allowed in the background
compiler thread.
I added assert to places that should only be reachable during unoptimized compilation.
BUG=#26669
R=asiva@google.com
Review URL: https://codereview.chromium.org/2056813002 .
Steps towards generalizing summary creation bits (to allow for, among other things, flutter SDK summary creation). API is provisional (note still in `lib/src`).
Next up:
* move result writing out of `tool/` to allow for reuse
* `SummaryBuilder.forPackageMap(..)` factory (or similar) for use in the flutter SDK case
BUG=
R=brianwilkerson@google.com, paulberry@google.com
Review URL: https://codereview.chromium.org/2055543002 .
Previously if one marker marked the weak property and another marker marked its key then the first marker might stop marking before it sees that the key was marked.
Here is a possible concurrent execution, assuming P is a WeakProperty and K is P.key:
(Marker A) (Marker B)
| |
[ mark property P ] |
| |
[ drain marking stack ] |
[ no more work to do ] |
| [ mark K ]
| [ draing marking stack ]
| [ no more work to do ]
| |
| |
... ...
| |
[Finalize] [Finalize]
|
[Clear P]
In this execution we end up clearing P even though P.key is marked.
To fix this issue without reintroducing central WeakProperty processing
we change the marking phase loop in such a way that markers consider the
marking done only if all of them agree that they have no more weak properties
with marked keys.
Essentially the marking loop now has a separate phase where all markers check
their pending weak properties. The decision to proceed to the next marking phase
(weak handles processing) is done in lock step using barrier - either all threads
advance to the next stage or one of the threads finds a weak property
with marked key and unmarked value and all threads resume marking.
BUG=
R=asiva@google.com
Review URL: https://codereview.chromium.org/2041413005 .
If 'trackCacheDependencies' is set to 'false', this makes DDC
compilation of Angular2 project about 10% faster.
Unfortunately I was not able to avoid creating ResultDescriptor(s) and
adding them into WorkItem.inputTargetedResults altogether. It is used
in AnalysisTask._findCyclicPath() to create InfiniteTaskLoopException
with additional information.
R=brianwilkerson@google.com, paulberry@google.com
BUG=
Review URL: https://codereview.chromium.org/2054453002 .
NativeBehavior for method calls and field load/store are now computed
during resolution and apply as part of the world impact. This prepares
for (full) serialization/deserialization of native elements.
R=het@google.com
Review URL: https://codereview.chromium.org/2045223002 .
This CL should fix the problem that arose with commit
543a51ff3e. Here's the description from
that CL:
This CL adds tests for previously uncovered elements of the semantics
and includes fixes such that the desired behavior is obtained. In
particular, an `isInitializingFormal` element may now occur in contexts
where it wasn't expected until now, and changes were made to handle it.
It is also checked that a capture of an initializing formal (in a
function literal) captures the parameter, not the field.
R=johnniwinther@google.com
Review URL: https://codereview.chromium.org/2042293002 .
Follow-up from https://codereview.chromium.org/2043963004/, where a number of test cases were identified. In particular:
> - What if the package map is empty?
> - What if the package map doesn't have a package with an embedder file?
> - What is there is no package with an ext?
> - What if we don't find either one?
> - What happens if one or both of those files are invalid?
BUG=
R=brianwilkerson@google.com
Review URL: https://codereview.chromium.org/2046493006 .
This code should no longer be reachable. I think it was part of our early non-null primitive type experimentation. (Currently `null` literal is treated as bottom, so it should never be a downcast if casting from null.)
R=leafp@google.com
Review URL: https://codereview.chromium.org/2050443002 .
