We have tests that disable it but we train app-jit snapshot for Kernel with field guards enabled so
we need to make sure that Kernel isolate runs with correct settings matching the settings at the time
when app-jit snapshot was created.
BUG=
R=rmacnak@google.com
Review-Url: https://codereview.chromium.org/2715213008 .
Original CL: https://codereview.chromium.org/2692803006/
Original commit message:
Tracking the awaiter return call stack:
- [x] Each async function closure now knows who is awaiting on their
return. This is effectively the asynchronous equivalent of the 'frame pointer'.
- [x] Each async* function closure now knows how is listening on their
stream. This is effectively the asynchronous equivalent of the 'frame pointer'.
Detecting uncaught exceptions in async functions:
- [x] Code object keeps a map from :await_jump_var to token position
- [x] Exception Handlers keep track if they are generated (as part of compilation) or directly from user code
- [x] Debugger maps :await_jump_var to a specific try index
R=johnmccutchan@google.com
Review-Url: https://codereview.chromium.org/2725623003 .
Tracking the awaiter return call stack:
- [x] Each async function closure now knows who is awaiting on their
return. This is effectively the asynchronous equivalent of the 'frame pointer'.
- [x] Each async* function closure now knows how is listening on their
stream. This is effectively the asynchronous equivalent of the 'frame pointer'.
Detecting uncaught exceptions in async functions:
- [x] Code object keeps a map from :await_jump_var to token position
- [x] Exception Handlers keep track if they are generated (as part of compilation) or directly from user code
- [x] Debugger maps :await_jump_var to a specific try index
Fixes#27242R=rmacnak@google.com
Review-Url: https://codereview.chromium.org/2692803006 .
Also fix stack trace collection to always include invisible frames. It can happen that a visible function is inlined into an invisible function, and we don't expand inlined frames until we print a stack trace.
dart2js product x64:
compile time: 12.459s
VMIsolate(CodeSize): 152292
Isolate(CodeSize): 3343117
ReadOnlyData(CodeSize): 3728928
Instructions(CodeSize): 8677600
Total(CodeSize): 15901937
->
compile time: 14.195s (+13%)
VMIsolate(CodeSize): 174034
Isolate(CodeSize): 3892418 (+16%)
ReadOnlyData(CodeSize): 5036320 (+35%)
Instructions(CodeSize): 8682624
Total(CodeSize): 17785396 (+12%)
R=asiva@google.com
Review-Url: https://codereview.chromium.org/2687143005 .
CodeSourceMap now contains a small bytecode that describes changes to the token position and inlining stack as one moves through a function. This information is used by the disassembler to display inlining comments and by the profiler to properly blame ticks against source code.
Slightly shrinks the total size of code metadata; on dart2js compiling hello world, the final heap is
before 59.6MB total, 12.8MB List, 1.1MB CodeSourceMap
after 59.4MB total, 12.1MB List, 1.5MB CodeSourceMap
To be filtered and included in AOT code to expand inline frames in stack traces.
R=johnmccutchan@google.com
Review-Url: https://codereview.chromium.org/2670843006 .
On DBC calls return value on the stack instead of a dedicate register but not all calls have a return value (e.g. CheckStack does not) and such calls don't push anything. Implementation of a lazy deopt however assumed that value is always present and tried to manually preserve it by popping and pushing it back after the frame was rewritten. This of course damaged the frame if we performed a lazy deoptimization after the call that did not push anything.
Instead of manually preserving result value value use frame translation to handle it. This allows to handle calls that return value and those that do not uniformly in the Deopt bytecode. Compiler takes care of creating the right deoptimization environment instead.
BUG=
R=zra@google.com
Review-Url: https://codereview.chromium.org/2587133002 .
- Adjust fingerprints to be independent of the library's private key, which varies with load order.
- Use usage_counter in AOT inlining decisions if JIT feedback is available.
- Reduce inlining in cold functions.
dart2js product aot snapshot 15841351 -> 14436273 (-8.86%)
R=fschneider@google.com
Review-Url: https://codereview.chromium.org/2562693003 .
This helps inlining more functions -- since the size limits are already
much smaller than in the JIT, this does not increase overall code size
in many cases, but helps performance by inlining more calls in chains of
super constructors calls, super getters.
BUG=
R=rmacnak@google.com
Review URL: https://codereview.chromium.org/2494203003 .
The catch entry block has all locals in fixed locations
(Rj) where j = kNumberOfRegisters - i for parameter i.
This means we reserve a range of DBC registers at the top-end of the frame.
Those registers are blocked for general allocation to avoid any overlap
with the rest of the registers that are allocated from the bottom.
Each optimized frame with a try-catch will be kNumberOfRegisters wide.
BUG=
R=vegorov@google.com
Review URL: https://codereview.chromium.org/2388093003 .
When throwing to a frame scheduled for lazy deopt, update the continuation pc for that frame to be the catch handler.
Weaken new assert that the deopt pc belongs to the frame's code as the deopt pc for the last eager deopt in a function lies outside the code, after the call to the deopt stub.
R=fschneider@google.com
Review URL: https://codereview.chromium.org/2392613002 .
A switchable call in the monomorphic state is now basically the same cost as a test and call, so this is as performant without ht code size cost of the slow path megemorphic call.
Flutter gallery before:
VMIsolate(CodeSize): 114052
Isolate(CodeSize): 2250283
ReadOnlyData(CodeSize): 1744760
Instructions(CodeSize): 5679488
Total(CodeSize): 9788583
After:
VMIsolate(CodeSize): 114085
Isolate(CodeSize): 2047224
ReadOnlyData(CodeSize): 1666808
Instructions(CodeSize): 5405424 -4.8%
Total(CodeSize): 9233541 -5.6%
R=fschneider@google.com
Review URL: https://codereview.chromium.org/2376893003 .
Catch block entries need to be considered when doing lazy deoptimization.
In addition to the return, also patch all catch entry blocks in a function scheduled for lazy deoptimization.
Also, move restoring the pool pointer to the jump-to-handler stub to simplify patching the catch entry.
BUG=#27419
R=rmacnak@google.com
Review URL: https://codereview.chromium.org/2357343003 .
The call sequence is very similar to a classic IC call, except the guarded class and the target are loaded indirectly from the constant pool instead of as immediates. In the monomorphic case, we call directly to the expected target with a class check in the callee. In the unlinked, polymorphic and megamorphic cases, we call a stub; these case are now call-through instead of call-and-return.
Every code, except stubs involved in switchable calls, includes the class check sequence at the beginning. So we now distinguish between a checked and an unchecked entry point. Generated code except the switchable call continues to use the unchecked entry point.
PC offsets are calculated relative to the beginning of the instruction stream, rather than either entry point.
BUG=
R=fschneider@google.com
Review URL: https://codereview.chromium.org/2226893002 .
- [x] Start reloading even earlier.
- [x] Keep the value of FLAG_reload_every per-isolate (so spawned isolates reload eagerly too).
- [x] Adjust the reload every back off curve to be linear in the beginning.
- [x] Cap the reload every threshold at 1,000,000
- [x] Test status file updates.
- [x] Stop disabling the background compiler / OSR when running tests.
- [x] Skip multi tests with compilation errors when reloading.
BUG=
R=rmacnak@google.com
Review URL: https://codereview.chromium.org/2133823002 .
- Removed the flag use_megamorphic_stub and
- Removed StubCode::EmitMegamorphicLookup (inlined version of megamorphic call).
- Removed the null load in GenerateMegamorphicLookupStub for arm64 to match other platforms.
BUG=
R=fschneider@google.com
Review URL: https://codereview.chromium.org/2132803002 .
- [x] Add an is static call bit to ICData
- [x] Rewrite the reset ICData iterators to rely on that bit rather than the function's ic data map
BUG=
Review URL: https://codereview.chromium.org/2064693003 .
Most of the infrastructure is fixed to work with DBC stack layout:
- register allocator allocates DBC registers with the limitation that we allocate only 20 registers and bail out if anything needs spilling (there is no use implementing spilling on DBC because registers are memory locations themselves). We should be able to bump number of CPU registers on DBC up to 256 but this requires major surgery in some parts - so I postponed this;
- lazy deoptimization is implemented, eager deoptimization is not - because we don't emit any code that actually requires it. it's a minor change to support it once we have a target;
- stack scanning respects stack maps built by registers allocator;
We bailout from all unsupported instructions.
R=zra@google.com
Review URL: https://codereview.chromium.org/1992963002 .
The original IC data are only needed when we reference them from the generated code.
EmitMegamorphicInstanceCall does not emit them into the code, but calls
EmitMegamorphicInstanceCall -> ShouldInlineSmiStringHashCode -> NumberOfChecks,
which fails if the mutator thread grows the IC data concurrently.
BUG=
R=vegorov@google.com
Review URL: https://codereview.chromium.org/1994993002 .
We can't iterate over the original IC data (like NumberOfUsedChecks does) since
the mutator thread may grow the IC data array concurrently.
This works around this issue by using the cloned IC data.
BUG=
R=vegorov@google.com
Review URL: https://codereview.chromium.org/1993673002 .
This is a cut of the work that Todd and I collaborated on in the reload branch.
In this CL, we've dropped the loader port hacks, in other words, on stack reloading in the standalone embedder does not work yet.
- [x] Support for hot reloading of isolate source code
- [x] Unit test harness and many tests
- [x] Service protocol and Observatory support
- [x] Product build does not include support for hot reloading.
R=rmacnak@google.com
Review URL: https://codereview.chromium.org/1965823002 .
Vyacheslav Egorov