Unoptimized code has a static call to optimized code.
Optimized code prologue goes to the OptimizeInvokedFunction runtime.
Callee schedule for background compilation and current code set the return entries return value.
Verify-on-transition triggers a safepoint, wherein the background compiler disables the old optimized code.
The OptimizedInvokedFunction stub calls through the disabled code.
FixCallersTarget see an unoptimized caller. BOOM
Similar problem without --verify-on-transition, except the safepoint comes from BackgroundCompiler::CompileOptimized.
Fixes#26927.
R=fschneider@google.com
Review URL: https://codereview.chromium.org/2418673002 .
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 .
Expand the range on a miss if all classes in the range have the same lookup result, otherwise transition to the stub that does a linear scan of ICData.
Because we do a depth-first sort of classes during AOT, if a call site sees only objects all inheriting the same function as the call target, the call site will be handled by this new stub.
Adjust LoadClassIdMayBeSmi on x64 to preserve the object.
R=fschneider@google.com
Review URL: https://codereview.chromium.org/2279563002 .
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 .
- 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 .
- Optimized instructions in the megamorphic stubs on X64, IA32, ARM, and ARM64.
In a micro benchmark testing megamorphic calls using 71 different receiver types,
the execution times goes from 2.6 sec to 1.4 sec.
BUG=
R=fschneider@google.com
Review URL: https://codereview.chromium.org/2131583002 .
Load the Code from the ic data array instead of the ObjectPool because we still need the Code object in the frame to find stackmaps / build stacktraces / build profile results.
Keep doing things the old way until all compilation is finished because evaluation of constants still needs functional lazy compilation and the compiler works with ICData that may contain as-yet-uncompiled functions. After compilation is finished, transform all the ICData from (cid, target function, count) to (cid, target code, entry point) and switch to the ICLookup stub that works with this representation.
Golem average +3.133% on ARM, +3.544% on x64
R=srdjan@google.com
Review URL: https://codereview.chromium.org/1799793002 .
Move optimizations for precompilation into separate file.
Remove precompilation-specific code from flow_graph_optimizer.cc.
Add precompilation-flags: They are const in the precompiled runtime. Started moving flags to use the new flag-definition macros.
Add libdart_lib_precompiled target.
Define PRECOMPILED_RUNTIME_MACRO in more places (dart_precompiled_runtime)
BUG=
R=rmacnak@google.com
Review URL: https://codereview.chromium.org/1714743002 .
They were used as the class of closure instances and as the type class of
function types.
All closure instances now have class _Closure and function types are represented
by a new class FunctionType extending AbstractType.
Fix issue 24567 and add regression test.
R=asiva@google.com, rmacnak@google.com
Review URL: https://codereview.chromium.org/1584223006 .
Instead of calling code object directly, call indirectly and
pass the code object in a register. The object pool is then loaded from
the code object. This is another preparation step for making generated code
relocatable.
All non-ia32 platforms:
No entry patching.
ARM:
PC marker (now code object) moves to the same place as on x64 (below saved PP, above saved FP).
R9 is now used as PP, R10 as CODE_REG.
BUG=
R=rmacnak@google.com
Review URL: https://codereview.chromium.org//1192103004 .
Fix bug in DecodeLoadWordFromPool: used Array::element_offset instead of ObjectPool::element_offset.
This only worked because they accidentally return the same value.
Remove virtual methods from InstructionsPatterns on ia32 and x64. Instead use a template for code reuse.
This avoids among others vtables for the *Pattern classes and saves >= 4K in VM binary code size.
BUG=
R=rmacnak@google.com
Review URL: https://codereview.chromium.org//1301963003 .
- Don't store the allocation tracing toggle bit in the class.
- Make sure that array and context slow path stubs are added to the code object's static call table.
- Add missing MaybeTraceAllocation to context allocation stub.
R=fschneider@google.com
Review URL: https://codereview.chromium.org//1292723002 .
This makes the code in the code generator independent from how stubs
are actually called (i.e. directly embedding the target address, or
indirectly by loading the target address from the code object).
BUG=
R=rmacnak@google.com
Review URL: https://codereview.chromium.org//1270803003 .
Cache a pointer to the isolate's Heap in the Thread object
and use it in generated code for allocation.
Change generated allocation code to load allocation-top and
end via THR (THR->heap.top). This is slightly slower than
embedding the address, but faster than loading it
via the Isolate (THR->isolate->heap.top)
BUG=
R=koda@google.com
Review URL: https://codereview.chromium.org//1263513002 .
This allows to make the last explicitly named stubs shared between isolates.
When sharing code stubs, we can't do patching at their entry anymore.
Therefore, I had to remove patching support of the array allocation stub.
Is this a functionality we want to keep?
The change is mostly performance-neutral because optimized code has an inlined fast
path for array allocation and only uses the stub for the slow-case.
The only isolate-specific stubs left are object allocation stubs which are
associated with their Class are per-isolate.
Since this CL removes any isolate-specific stubs from StubCode, it becomes AllStatic.
BUG=
R=koda@google.com
Review URL: https://codereview.chromium.org//1247783002 .
Make context allocation stub shared between isolates.
The fast-path used in optimized code still has isolate-specific
addresses inlined for performance reasons.
Common functions are moved into class_table.h/.cc.
This is a preparation for adding an isolate-independent version of the
allocation code and allocation tracking code.
BUG=
R=johnmccutchan@google.com
Review URL: https://codereview.chromium.org//1241863002 .
This CL also lifts the restriction that the object pool can't be used
in VM isolate code on x64 and arm64.
Stubs that perform allocation can't be shared yet, because the inline allocation
code is not yet isolate-independent. This will be added in a separate CL.
BUG=
R=rmacnak@google.com
Review URL: https://codereview.chromium.org//1229283002 .
This is needed to enable parallel marking/sweeping (and in the future, compilation) tasks to have their own zone allocations and to safely call code that relies on various scoped constructs (stack resources).
The next step is to migrate the scopes like NoSafepointScope, NoHandleScope, etc. from isolate- to thread-based interfaces.
NOTE: This is a copy of issue 1204303003.
BUG=
Review URL: https://codereview.chromium.org//1226403003 .
Ryan Macnak