When deciding whether to inline a function that has already been optimized
once, take a look at how many levels of inlining took place when it was
optimized stand-alone. If we don't have that much depth budget left, don't
inline. This is an attempt to avoid the situation where we inline a function
that was already optimized, and then fail to inline important things that are
in the inner loop.
The benchmarking server shows about a 3% improvement on average when running
the DartJS compiler.
This is a reland of https://codereview.chromium.org/2994283002/
Bug
R=vegorov@google.com
Change-Id: Ib2d1f0daad5d68d140bf0266c362dded7a4ea36b
Reviewed-on: https://dart-review.googlesource.com/7706
Commit-Queue: Erik Corry <erikcorry@google.com>
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
When deciding whether to inline a function that has already been optimized
once, take a look at how many levels of inlining took place when it was
optimized stand-alone. If we don't have that much depth budget left, don't
inline. This is an attempt to avoid the situation where we inline a function
that was already optimized, and then fail to inline important things that are
in the inner loop.
The benchmarking server shows about a 3% improvement on average when running
the DartJS compiler
This was reviewed and LGTMed at https://codereview.chromium.org/2994283002
Bug:
Change-Id: Ia731c89f32ac4eacd643965a36dcee35f610c141
Reviewed-on: https://dart-review.googlesource.com/7544
Reviewed-by: Vyacheslav Egorov <vegorov@google.com>
Commit-Queue: Vyacheslav Egorov <vegorov@google.com>
The assertions which tried to assert that we only use
StackFrameIterator to walk frames of the current thread was incorrect.
We already have cases where other threads will walk the stack of the
mutator thread, see below for an example where this can happen.
Thread::VisitObjectPointers was incorrectly passing Thread::Current() to
the StackFrameIterator instead of 'this'. (Code in thread_registry.cc will
loop over a number of threads and calls VisitObjectPointers on them)
Mutator thread:
0 pthread_cond_wait@@GLIBC_2.3.2
1 dart::Monitor::WaitMicros
2 dart::Monitor::Wait
3 dart::MonitorLocker::Wait
4 dart::ThreadBarrier::Sync
5 dart::GCMarker::MarkObjects
6 dart::PageSpace::MarkSweep
7 dart::Heap::CollectOldSpaceGarbage
8 dart::Heap::CollectNewSpaceGarbage
9 dart::Heap::CollectGarbage
10 dart::DN_HelperObject_<native>
11 dart::BootstrapNatives::<native>
<dart frames>
MarkTask thread:
1 dart::EntryFrame::VisitObjectPointers
2 dart::Thread::VisitObjectPointers <---- Walks mutator thread stack
3 dart::ThreadRegistry::VisitObjectPointers <---- Iterates over a number of threads
4 dart::Isolate::VisitStackPointers
5 dart::Isolate::VisitObjectPointers
6 dart::GCMarker::IterateRoots
7 dart::MarkTask::Run
8 dart::ThreadPool::Worker::Loop
9 dart::ThreadPool::Worker::Main
10 dart::ThreadStart
R=rmacnak@google.com
Review-Url: https://codereview.chromium.org/2845053003 .
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 .
Rework how we check guarded state consistency in background compiler.
Background compiler was storing original fields inside guarded fields list. This caused a race during inlining when inliner would copy guarded fields one by one from the callee function into the caller, because ParsedFunction::AddToGuardedFields looks at the guarded_cid to filter out those fields that should not be guarded.
As a result if some guarded field transitioned to unguarded (kDynamicCid) after callee graph construction but before list of guarded fields were copied then AddToGuardedFields would simply skip that field because it now has guarded_cid() == kDynamicCid.
We fix this race by always placing copies into the list of guarded fields and unwrapping them only in FinalizeCode.
Placing the copies also allows us to simplify a lot of code that was trying to verify guarded state consistency before committing the generated optimized code - now that we store copies in the list we can just compare their state to the originals and abort if the state is different.
Additionally fix deduplication check that was comparing original fields with copies - resulting in adding the same field into the list multiple times.
Add an assertion that verifies that we are not trying to access guarded_cid of original field from background compiler.
R=fschneider@google.com
BUG=
Review URL: https://codereview.chromium.org/2006793002 .
For now, change compilation-related flags to be regular
command line options. They won't affect the size of the
precompiled runtime anyway since the compiler is not included
there.
Also introduce a separate switch for precompiled runtime. This can be
used instead of the macro since it is a compile-time constant in the
precompiled runtime.
BUG=
Review URL: https://codereview.chromium.org/1759913002 .
Replace always_optimize_ and allow_recompilation_ with
FLAG_precompilation and !FLAG_precompilation.
They are equivalent and set only once according to the
--precompilation flag
BUG=
R=rmacnak@google.com
Review URL: https://codereview.chromium.org/1657153002 .
We introduce 3 invalidation generation counters: CHA, field and library prefixes. If one of the counters was incremented during compilation, and is relevant for that compilation, the code installation is skipped since that code may have become invalid in the meantime.
Add BackgroundCompilationResult that remembers the 3 invalidation generations.
The generational counter can rollover, which is OK.
BUG=
R=asiva@google.com
Review URL: https://codereview.chromium.org/1418813008 .
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 .
Erik Corry