Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2503393002:
[cpu-profiler] use new source position information for deoptimization in cpu profiler (Closed)
|
Created:
4 years, 1 month ago by Tobias Tebbi Modified:
4 years, 1 month ago CC:
v8-reviews_googlegroups.com Target Ref:
refs/pending/heads/master Project:
v8 Visibility:
Public. |
Description[cpu-profiler] use new source position information for deoptimization in cpu profiler
The new SourcePosition class allows for precise tracking of source positions including the stack of inlinings. This CL makes the cpu profiler use this new information. Before, the cpu profiler used the deoptimization data to reconstruct the inlining stack. However, optimizing compilers (especially Turbofan) can hoist out checks such that the inlining stack of the deopt reason and the inlining stack of the position the deoptimizer jumps to can be different (the old cpu profiler tests and the ones introduced in this cl produce such situations for turbofan). In this case, relying on the deoptimization info produces paradoxical results, where the reported position is before the function responsible is called. Even worse, https://codereview.chromium.org/2451853002/ combines the precise position with the wrong inlining stack from the deopt info, leading to completely wrong results.
Other changes in this CL:
- DeoptInlinedFrame is no longer needed, because we can compute the correct inlining stack up front.
- I changed the cpu profiler tests back to test situations where deopt checks are hoisted out in Turbofan and made them robust enough to handle the differences between Crankshaft and Turbofan.
- I reversed the order of SourcePosition::InliningStack to make it match the cpu profiler convention.
- I removed CodeDeoptEvent::position, as it is no longer used.
R=alph@chromium.org
BUG=v8:5432
Committed: https://crrev.com/1b320d2039f961f8271a0b3e2a06abaf7bf0c3f0
Cr-Commit-Position: refs/heads/master@{#41168}
Patch Set 1 #Patch Set 2 : removed CodeDeoptEvent::position #
Total comments: 9
Patch Set 3 : addressed comments #Patch Set 4 : compile issues #
Total comments: 1
Patch Set 5 : fixed crash #Patch Set 6 : addressed comment #
Messages
Total messages: 35 (19 generated)
Description was changed from ========== [cpu-profiler] use new source position information for deoptimization in cpu profiler The new SourcePosition class allows for precise tracking of source positions including the stack of inlinings. This CL makes the cpu profiler use this new information. Before, the cpu profiler used the deoptimization data to reconstruct the inlining stack. However, optimizing compilers (especially Turbofan) can hoist out checks such that the inlining stack of the deopt reason and the inlining stack of the position the deoptimizer jumps to can be different (the old cpu profiler tests and the ones introduced in this cl produce such situations for turbofan). In this case, relying on the deoptimization info produces paradoxical results, where the reported position is before the function responsible is called. Even worse, https://codereview.chromium.org/2451853002/ combines the precise position with the wrong inlining stack from the deopt info, leading to completely wrong results. Other changes in this CL: - DeoptInlinedFrame is no longer needed, because we can compute the correct inlining stack up front. - I changed the cpu profiler tests back to test situations where deopt checks are hoisted out in Turbofan and made them robust enough to handle the differences between Crankshaft and Turbofan. - I reversed the order of SourcePosition::InliningStack to make it match the cpu profiler convention. R=alph@chromium.org BUG=v8:5432 ========== to ========== [cpu-profiler] use new source position information for deoptimization in cpu profiler The new SourcePosition class allows for precise tracking of source positions including the stack of inlinings. This CL makes the cpu profiler use this new information. Before, the cpu profiler used the deoptimization data to reconstruct the inlining stack. However, optimizing compilers (especially Turbofan) can hoist out checks such that the inlining stack of the deopt reason and the inlining stack of the position the deoptimizer jumps to can be different (the old cpu profiler tests and the ones introduced in this cl produce such situations for turbofan). In this case, relying on the deoptimization info produces paradoxical results, where the reported position is before the function responsible is called. Even worse, https://codereview.chromium.org/2451853002/ combines the precise position with the wrong inlining stack from the deopt info, leading to completely wrong results. Other changes in this CL: - DeoptInlinedFrame is no longer needed, because we can compute the correct inlining stack up front. - I changed the cpu profiler tests back to test situations where deopt checks are hoisted out in Turbofan and made them robust enough to handle the differences between Crankshaft and Turbofan. - I reversed the order of SourcePosition::InliningStack to make it match the cpu profiler convention. - I removed CodeDeoptEvent::position, as it is no longer used. R=alph@chromium.org BUG=v8:5432 ==========
alph@chromium.org changed reviewers: + yangguo@chromium.org
Great! Thanks for doing this. +yang for the stuff beyond src/profiler https://codereview.chromium.org/2503393002/diff/20001/src/profiler/profile-ge... File src/profiler/profile-generator.cc (right): https://codereview.chromium.org/2503393002/diff/20001/src/profiler/profile-ge... src/profiler/profile-generator.cc:162: .insert(std::make_pair(deopt_id, std::vector<CpuProfileDeoptFrame>())) I believe it's now ok to use std::move Could you please get rid of 'swap' hack while you're here. Thanks. https://codereview.chromium.org/2503393002/diff/20001/src/profiler/profiler-l... File src/profiler/profiler-listener.cc (right): https://codereview.chromium.org/2503393002/diff/20001/src/profiler/profiler-l... src/profiler/profiler-listener.cc:97: if (it.source_position().InliningId() != SourcePosition::kNotInlined) Why do you skip inlined positions? If it's not ready for this patch could you please keep the TODO. https://codereview.chromium.org/2503393002/diff/20001/src/profiler/profiler-l... src/profiler/profiler-listener.cc:251: Handle<Code> code(abstract_code->GetCode()); Why it needs a handle? https://codereview.chromium.org/2503393002/diff/20001/src/profiler/profiler-l... src/profiler/profiler-listener.cc:264: last_position = SourcePosition(script_offset, inlining_id); nit: use continue https://codereview.chromium.org/2503393002/diff/20001/test/cctest/test-cpu-pr... File test/cctest/test-cpu-profiler.cc (right): https://codereview.chromium.org/2503393002/diff/20001/test/cctest/test-cpu-pr... test/cctest/test-cpu-profiler.cc:1976: CHECK(static_cast<int>(offset(inlined_source, "* right")) - Please keep the abs otherwise any big enough value of position will make it pass. Also could you please remove the spaces around * and keep the distance <= 1. https://codereview.chromium.org/2503393002/diff/20001/test/cctest/test-cpu-pr... test/cctest/test-cpu-profiler.cc:2052: CHECK(static_cast<int>(offset(inlined_source, "* right")) - ditto
https://codereview.chromium.org/2503393002/diff/20001/src/profiler/profiler-l... File src/profiler/profiler-listener.cc (right): https://codereview.chromium.org/2503393002/diff/20001/src/profiler/profiler-l... src/profiler/profiler-listener.cc:97: if (it.source_position().InliningId() != SourcePosition::kNotInlined) On 2016/11/17 00:09:44, alph wrote: > Why do you skip inlined positions? > If it's not ready for this patch could you please keep the TODO. Sorry, yes, the TODO should stay. I skip inlined positions to maintain the old behavior. Is it safe to add inlined positions here as long as they are in the same script? We can easily get all needed information here, including the inlining stack and script ids. I just don't understand the cpu profiler well enough to know what to do here. https://codereview.chromium.org/2503393002/diff/20001/src/profiler/profiler-l... src/profiler/profiler-listener.cc:251: Handle<Code> code(abstract_code->GetCode()); On 2016/11/17 00:09:44, alph wrote: > Why it needs a handle? It needs a handle because last_position.InliningStack(code) is handlified (the reason is that it might initialize line ends, which allocates). Is there a reason why it should stay unhandlified? Is it safe to allocate from the profile listener?
Thank you! profiler lgtm https://codereview.chromium.org/2503393002/diff/20001/src/profiler/profiler-l... File src/profiler/profiler-listener.cc (right): https://codereview.chromium.org/2503393002/diff/20001/src/profiler/profiler-l... src/profiler/profiler-listener.cc:251: Handle<Code> code(abstract_code->GetCode()); On 2016/11/17 11:41:34, Tobias Tebbi wrote: > On 2016/11/17 00:09:44, alph wrote: > > Why it needs a handle? > > It needs a handle because last_position.InliningStack(code) is handlified (the > reason is that it might initialize line ends, which allocates). Is there a > reason why it should stay unhandlified? Is it safe to allocate from the profile > listener? Makes sense. Thanks. Handles are slower than raw access, so I'd avoid them whenever possible.
On 2016/11/18 22:51:46, alph wrote: > Thank you! profiler lgtm > > https://codereview.chromium.org/2503393002/diff/20001/src/profiler/profiler-l... > File src/profiler/profiler-listener.cc (right): > > https://codereview.chromium.org/2503393002/diff/20001/src/profiler/profiler-l... > src/profiler/profiler-listener.cc:251: Handle<Code> > code(abstract_code->GetCode()); > On 2016/11/17 11:41:34, Tobias Tebbi wrote: > > On 2016/11/17 00:09:44, alph wrote: > > > Why it needs a handle? > > > > It needs a handle because last_position.InliningStack(code) is handlified (the > > reason is that it might initialize line ends, which allocates). Is there a > > reason why it should stay unhandlified? Is it safe to allocate from the > profile > > listener? > > Makes sense. Thanks. Handles are slower than raw access, so I'd avoid them > whenever possible. Hmm... Just got it crashed while recording timeline on theverge.com Program received signal SIGSEGV, Segmentation fault. GetHeap (this=<optimized out>) at ../../v8/src/objects-inl.h:1359 1359 ->heap(); (gdb) bt #0 GetHeap (this=<optimized out>) at ../../v8/src/objects-inl.h:1359 #1 GetIsolate (this=<optimized out>) at ../../v8/src/objects-inl.h:1366 #2 v8::internal::Handle<v8::internal::SharedFunctionInfo>::Handle (this=0x7fff460b4070, object=0x100000006) at ../../v8/src/handles.h:99 #3 0x00007f605fe17cf3 in Info (this=<optimized out>, function=...) at ../../v8/src/source-position.cc:48 #4 v8::internal::SourcePosition::InliningStack (this=<optimized out>, code=...) at ../../v8/src/source-position.cc:84 #5 0x00007f605fc97f0e in v8::internal::ProfilerListener::RecordDeoptInlinedFrames (this=<optimized out>, entry=<optimized out>, abstract_code=<optimized out>) at ../../v8/src/profiler/profiler-listener.cc:272 #6 0x00007f605fc97c49 in v8::internal::ProfilerListener::CodeCreateEvent (this=<optimized out>, tag=v8::internal::CodeEventListener::LAZY_COMPILE_TAG, abstract_code=0x306568e71fc1, shared=<optimized out>, script_name=0x217f8acc7081, line=<optimized out>, column=<optimized out>) at ../../v8/src/profiler/profiler-listener.cc:112 #7 0x00007f605f70822b in v8::internal::CodeEventDispatcher::CodeCreateEvent (this=0x3db6a54fd620, tag=v8::internal::CodeEventListener::LAZY_COMPILE_TAG, code=0x306568e71fc1, shared=0x2c6482e20531, source=0x217f8acc7081, line=1, column=<optimized out>) at ../../v8/src/code-events.h:144 #8 0x00007f605f7039b1 in v8::internal::(anonymous namespace)::RecordFunctionCompilation (tag=v8::internal::CodeEventListener::LAZY_COMPILE_TAG, info=0x3db6ac4c4038) at ../../v8/src/compiler.cc:278 #9 0x00007f605f706bec in FinalizeOptimizedCompilationJob (job=<optimized out>) at ../../v8/src/compiler.cc:761 #10 v8::internal::Compiler::FinalizeCompilationJob (raw_job=0x3db6ac4c3f20) at ../../v8/src/compiler.cc:1690 #11 0x00007f605f6fc228 in v8::internal::OptimizingCompileDispatcher::InstallOptimizedFunctions (this=0x3db6a50aa560) at ../../v8/src/compiler-dispatcher/optimizing-compile-dispatcher.cc:191 #12 0x00007f605f9fb392 in v8::internal::StackGuard::HandleInterrupts (this=0x3db6a54af860) at ../../v8/src/execution.cc:468 #13 0x00007f605fd2607c in v8::internal::__RT_impl_Runtime_StackGuard (args=..., isolate=0x3db6a54ae020) at ../../v8/src/runtime/runtime-internal.cc:301 #14 0x00007f605fd25ef8 in Stats_Runtime_StackGuard (args_length=<optimized out>, args_object=<optimized out>, isolate=<optimized out>) at ../../v8/src/runtime/runtime-internal.cc:291 #15 v8::internal::Runtime_StackGuard (args_length=0, args_object=<optimized out>, isolate=0x3db6a54ae020) at ../../v8/src/runtime/runtime-internal.cc:291 #16 0x00003065689843a7 in ?? () #17 0x00007fff460b4d70 in ?? () #18 0x00003065689842e1 in ?? () Looks like it is not a SFI (but a SMI) in the LiteralArray at the given position.
The CQ bit was checked by tebbi@google.com to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: v8_linux64_gyp_rel_ng on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_linux64_gyp_rel_ng/build...)
The CQ bit was checked by tebbi@google.com to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
https://codereview.chromium.org/2503393002/diff/60001/src/profiler/profiler-l... File src/profiler/profiler-listener.cc (right): https://codereview.chromium.org/2503393002/diff/60001/src/profiler/profiler-l... src/profiler/profiler-listener.cc:268: if (!last_position.IsKnown()) continue; Should this happen? Can we have a CHECK against this if this can't happen?
Patchset #5 (id:80001) has been deleted
The bug was (@Yang indeed) in the indexing of the literals array. I fixed it and refactored the code accessing the inlined functions in the literals array. When running the timeline profiler in Chrome, I still get crashes from time to time, but they seem unrelated: Received signal 11 SEGV_MAPERR 000000000008 #0 0x7f9e98d2d87e base::debug::StackTrace::StackTrace() #1 0x7f9e98d2d3bf base::debug::(anonymous namespace)::StackDumpSignalHandler() #2 0x7f9e9917b330 <unknown> #3 0x7f9e7ec604cc WTF::StringImpl::is8Bit() #4 0x7f9e7ec9a69d WTF::String::is8Bit() #5 0x7f9e7fa2fa0b blink::maybeEncodeTextContent() #6 0x7f9e7fa2fed0 blink::InspectorPageAgent::cachedResourceContent() #7 0x7f9e7fa784a0 blink::NetworkResourcesData::ResourceData::clearWeakMembers() #8 0x7f9e7fa7b007 blink::TraceMethodDelegate<>::trampoline() #9 0x7f9e8996a8fc blink::CallbackStack::Item::call() #10 0x7f9e89981d93 blink::ThreadState::popAndInvokeThreadLocalWeakCallback() #11 0x7f9e89981f7a blink::ThreadState::threadLocalWeakProcessing() #12 0x7f9e89987f78 blink::ThreadState::preSweep() #13 0x7f9e89988903 blink::ThreadState::leaveSafePoint() #14 0x7f9e89540cde blink::SafePointScope::~SafePointScope() #15 0x7f9e89983a61 blink::ThreadState::collectGarbage() #16 0x7f9e8998469c blink::ThreadState::performIdleGC() #17 0x7f9e8998c2be _ZN4base8internal13FunctorTraitsIMN5blink11ThreadStateEFvdEvE6InvokeIPS3_JdEEEvS5_OT_DpOT0_ #18 0x7f9e8998c1c6 _ZN4base8internal12InvokeHelperILb0EvE8MakeItSoIRKMN5blink11ThreadStateEFvdEJPS5_dEEEvOT_DpOT0_ #19 0x7f9e8998c157 _ZN4base8internal7InvokerINS0_9BindStateIMN5blink11ThreadStateEFvdEJN3WTF17UnretainedWrapperIS4_LNS7_22FunctionThreadAffinityE1EEEEEEFvdEE7RunImplIRKS6_RKSt5tupleIJSA_EEJLm0EEEEvOT_OT0_NS_13IndexSequenceIJXspT1_EEEEOd #20 0x7f9e8998c08c _ZN4base8internal7InvokerINS0_9BindStateIMN5blink11ThreadStateEFvdEJN3WTF17UnretainedWrapperIS4_LNS7_22FunctionThreadAffinityE1EEEEEEFvdEE3RunEPNS0_13BindStateBaseEOd #21 0x7f9e89543cf1 base::internal::RunMixin<>::Run() #22 0x7f9e89543c14 WTF::Function<>::operator()() #23 0x7f9e895439cb blink::(anonymous namespace)::IdleTaskRunner::run() #24 0x7f9e898ca385 blink::scheduler::WebSchedulerImpl::runIdleTask() #25 0x7f9e898cb5cf _ZN4base8internal13FunctorTraitsIPFvSt10unique_ptrIN5blink9WebThread8IdleTaskESt14default_deleteIS5_EENS_9TimeTicksEEvE6InvokeIJS8_S9_EEEvSB_DpOT_ #26 0x7f9e898cb50d _ZN4base8internal12InvokeHelperILb0EvE8MakeItSoIRKPFvSt10unique_ptrIN5blink9WebThread8IdleTaskESt14default_deleteIS7_EENS_9TimeTicksEEJSA_SB_EEEvOT_DpOT0_ #27 0x7f9e898cb4a7 _ZN4base8internal7InvokerINS0_9BindStateIPFvSt10unique_ptrIN5blink9WebThread8IdleTaskESt14default_deleteIS6_EENS_9TimeTicksEEJNS0_13PassedWrapperIS9_EEEEEFvSA_EE7RunImplIRKSC_RKSt5tupleIJSE_EEJLm0EEEEvOT_OT0_NS_13IndexSequenceIJXspT1_EEEEOSA_ #28 0x7f9e898cb3dc _ZN4base8internal7InvokerINS0_9BindStateIPFvSt10unique_ptrIN5blink9WebThread8IdleTaskESt14default_deleteIS6_EENS_9TimeTicksEEJNS0_13PassedWrapperIS9_EEEEEFvSA_EE3RunEPNS0_13BindStateBaseEOSA_ #29 0x7f9e898c9906 base::internal::RunMixin<>::Run() #30 0x7f9e898c945d blink::scheduler::SingleThreadIdleTaskRunner::RunTask() #31 0x7f9e898c9c4c _ZN4base8internal13FunctorTraitsIMN5blink9scheduler26SingleThreadIdleTaskRunnerEFvNS_8CallbackIFvNS_9TimeTicksEELNS0_8CopyModeE1ELNS0_10RepeatModeE1EEEEvE6InvokeIRKNS_7WeakPtrIS4_EEJRKSA_EEEvSC_OT_DpOT0_ #32 0x7f9e898c9b4f _ZN4base8internal12InvokeHelperILb1EvE8MakeItSoIRKMN5blink9scheduler26SingleThreadIdleTaskRunnerEFvNS_8CallbackIFvNS_9TimeTicksEELNS0_8CopyModeE1ELNS0_10RepeatModeE1EEEERKNS_7WeakPtrIS6_EEJRKSC_EEEvOT_OT0_DpOT1_ #33 0x7f9e898c9ac3 _ZN4base8internal7InvokerINS0_9BindStateIMN5blink9scheduler26SingleThreadIdleTaskRunnerEFvNS_8CallbackIFvNS_9TimeTicksEELNS0_8CopyModeE1ELNS0_10RepeatModeE1EEEEJNS_7WeakPtrIS5_EESB_EEEFvvEE7RunImplIRKSD_RKSt5tupleIJSF_SB_EEJLm0ELm1EEEEvOT_OT0_NS_13IndexSequenceIJXspT1_EEEE #34 0x7f9e898c99dc _ZN4base8internal7InvokerINS0_9BindStateIMN5blink9scheduler26SingleThreadIdleTaskRunnerEFvNS_8CallbackIFvNS_9TimeTicksEELNS0_8CopyModeE1ELNS0_10RepeatModeE1EEEEJNS_7WeakPtrIS5_EESB_EEEFvvEE3RunEPNS0_13BindStateBaseE #35 0x7f9e98d33701 _ZNO4base8internal8RunMixinINS_8CallbackIFvvELNS0_8CopyModeE0ELNS0_10RepeatModeE0EEEE3RunEv #36 0x7f9e98d330d2 base::debug::TaskAnnotator::RunTask() #37 0x7f9e8989cf41 blink::scheduler::TaskQueueManager::ProcessTaskFromWorkQueue() #38 0x7f9e8989a8c2 blink::scheduler::TaskQueueManager::DoWork() #39 0x7f9e898a330c _ZN4base8internal13FunctorTraitsIMN5blink9scheduler16TaskQueueManagerEFvNS_9TimeTicksEbEvE6InvokeIRKNS_7WeakPtrIS4_EEJRKS5_RKbEEEvS7_OT_DpOT0_ #40 0x7f9e898a31e4 _ZN4base8internal12InvokeHelperILb1EvE8MakeItSoIRKMN5blink9scheduler16TaskQueueManagerEFvNS_9TimeTicksEbERKNS_7WeakPtrIS6_EEJRKS7_RKbEEEvOT_OT0_DpOT1_ #41 0x7f9e898a3144 _ZN4base8internal7InvokerINS0_9BindStateIMN5blink9scheduler16TaskQueueManagerEFvNS_9TimeTicksEbEJNS_7WeakPtrIS5_EES6_bEEEFvvEE7RunImplIRKS8_RKSt5tupleIJSA_S6_bEEJLm0ELm1ELm2EEEEvOT_OT0_NS_13IndexSequenceIJXspT1_EEEE #42 0x7f9e898a301c _ZN4base8internal7InvokerINS0_9BindStateIMN5blink9scheduler16TaskQueueManagerEFvNS_9TimeTicksEbEJNS_7WeakPtrIS5_EES6_bEEEFvvEE3RunEPNS0_13BindStateBaseE #43 0x7f9e98d33701 _ZNO4base8internal8RunMixinINS_8CallbackIFvvELNS0_8CopyModeE0ELNS0_10RepeatModeE0EEEE3RunEv #44 0x7f9e98d330d2 base::debug::TaskAnnotator::RunTask() #45 0x7f9e98dc4e6a base::MessageLoop::RunTask() #46 0x7f9e98dc50f4 base::MessageLoop::DeferOrRunPendingTask() #47 0x7f9e98dc53de base::MessageLoop::DoWork() #48 0x7f9e98ddcd33 base::MessagePumpDefault::Run() #49 0x7f9e98dc49ea base::MessageLoop::RunHandler() #50 0x7f9e98e6d484 base::RunLoop::Run() #51 0x7f9e93887dec content::RendererMain() #52 0x7f9e93c7da5e content::RunZygote() #53 0x7f9e93c7de70 content::RunNamedProcessTypeMain() #54 0x7f9e93c80292 content::ContentMainRunnerImpl::Run() #55 0x7f9e93c7d102 content::ContentMain() #56 0x7f9e99bb1dcb ChromeMain #57 0x7f9e99bb1d62 main #58 0x7f9e85947f45 __libc_start_main #59 0x7f9e99bb1c65 <unknown> r8: 0000000000000000 r9: 00007fffc1ef6900 r10: 00000000006c4020 r11: 0000000000000202 r12: 00007f9e99bb1c3c r13: 00007fffc1ef9c10 r14: 0000000000000000 r15: 00007f9e89eb79c3 di: 0000000000000000 si: 00007fffc1ef6680 bp: 00007fffc1ef63c0 bx: 00007fffc1ef6c40 dx: 00007fffc1ef68f8 ax: 0000000000000000 cx: 00007fffc1ef68f7 sp: 00007fffc1ef63c0 ip: 00007f9e7ec604cc efl: 0000000000010202 cgf: 0000000000000033 erf: 0000000000000004 trp: 000000000000000e msk: 0000000000000000 cr2: 0000000000000008
On 2016/11/21 16:03:51, Tobias Tebbi wrote: > The bug was (@Yang indeed) in the indexing of the literals array. I fixed it and > refactored the code accessing the inlined functions in the literals array. > > When running the timeline profiler in Chrome, I still get crashes from time to > time, but they seem unrelated: > > Received signal 11 SEGV_MAPERR 000000000008 > #0 0x7f9e98d2d87e base::debug::StackTrace::StackTrace() > #1 0x7f9e98d2d3bf base::debug::(anonymous namespace)::StackDumpSignalHandler() > #2 0x7f9e9917b330 <unknown> > #3 0x7f9e7ec604cc WTF::StringImpl::is8Bit() > #4 0x7f9e7ec9a69d WTF::String::is8Bit() > #5 0x7f9e7fa2fa0b blink::maybeEncodeTextContent() > #6 0x7f9e7fa2fed0 blink::InspectorPageAgent::cachedResourceContent() > #7 0x7f9e7fa784a0 blink::NetworkResourcesData::ResourceData::clearWeakMembers() > #8 0x7f9e7fa7b007 blink::TraceMethodDelegate<>::trampoline() > #9 0x7f9e8996a8fc blink::CallbackStack::Item::call() > #10 0x7f9e89981d93 blink::ThreadState::popAndInvokeThreadLocalWeakCallback() > #11 0x7f9e89981f7a blink::ThreadState::threadLocalWeakProcessing() > #12 0x7f9e89987f78 blink::ThreadState::preSweep() > #13 0x7f9e89988903 blink::ThreadState::leaveSafePoint() > #14 0x7f9e89540cde blink::SafePointScope::~SafePointScope() > #15 0x7f9e89983a61 blink::ThreadState::collectGarbage() > #16 0x7f9e8998469c blink::ThreadState::performIdleGC() > #17 0x7f9e8998c2be > _ZN4base8internal13FunctorTraitsIMN5blink11ThreadStateEFvdEvE6InvokeIPS3_JdEEEvS5_OT_DpOT0_ > #18 0x7f9e8998c1c6 > _ZN4base8internal12InvokeHelperILb0EvE8MakeItSoIRKMN5blink11ThreadStateEFvdEJPS5_dEEEvOT_DpOT0_ > #19 0x7f9e8998c157 > _ZN4base8internal7InvokerINS0_9BindStateIMN5blink11ThreadStateEFvdEJN3WTF17UnretainedWrapperIS4_LNS7_22FunctionThreadAffinityE1EEEEEEFvdEE7RunImplIRKS6_RKSt5tupleIJSA_EEJLm0EEEEvOT_OT0_NS_13IndexSequenceIJXspT1_EEEEOd > #20 0x7f9e8998c08c > _ZN4base8internal7InvokerINS0_9BindStateIMN5blink11ThreadStateEFvdEJN3WTF17UnretainedWrapperIS4_LNS7_22FunctionThreadAffinityE1EEEEEEFvdEE3RunEPNS0_13BindStateBaseEOd > #21 0x7f9e89543cf1 base::internal::RunMixin<>::Run() > #22 0x7f9e89543c14 WTF::Function<>::operator()() > #23 0x7f9e895439cb blink::(anonymous namespace)::IdleTaskRunner::run() > #24 0x7f9e898ca385 blink::scheduler::WebSchedulerImpl::runIdleTask() > #25 0x7f9e898cb5cf > _ZN4base8internal13FunctorTraitsIPFvSt10unique_ptrIN5blink9WebThread8IdleTaskESt14default_deleteIS5_EENS_9TimeTicksEEvE6InvokeIJS8_S9_EEEvSB_DpOT_ > #26 0x7f9e898cb50d > _ZN4base8internal12InvokeHelperILb0EvE8MakeItSoIRKPFvSt10unique_ptrIN5blink9WebThread8IdleTaskESt14default_deleteIS7_EENS_9TimeTicksEEJSA_SB_EEEvOT_DpOT0_ > #27 0x7f9e898cb4a7 > _ZN4base8internal7InvokerINS0_9BindStateIPFvSt10unique_ptrIN5blink9WebThread8IdleTaskESt14default_deleteIS6_EENS_9TimeTicksEEJNS0_13PassedWrapperIS9_EEEEEFvSA_EE7RunImplIRKSC_RKSt5tupleIJSE_EEJLm0EEEEvOT_OT0_NS_13IndexSequenceIJXspT1_EEEEOSA_ > #28 0x7f9e898cb3dc > _ZN4base8internal7InvokerINS0_9BindStateIPFvSt10unique_ptrIN5blink9WebThread8IdleTaskESt14default_deleteIS6_EENS_9TimeTicksEEJNS0_13PassedWrapperIS9_EEEEEFvSA_EE3RunEPNS0_13BindStateBaseEOSA_ > #29 0x7f9e898c9906 base::internal::RunMixin<>::Run() > #30 0x7f9e898c945d blink::scheduler::SingleThreadIdleTaskRunner::RunTask() > #31 0x7f9e898c9c4c > _ZN4base8internal13FunctorTraitsIMN5blink9scheduler26SingleThreadIdleTaskRunnerEFvNS_8CallbackIFvNS_9TimeTicksEELNS0_8CopyModeE1ELNS0_10RepeatModeE1EEEEvE6InvokeIRKNS_7WeakPtrIS4_EEJRKSA_EEEvSC_OT_DpOT0_ > #32 0x7f9e898c9b4f > _ZN4base8internal12InvokeHelperILb1EvE8MakeItSoIRKMN5blink9scheduler26SingleThreadIdleTaskRunnerEFvNS_8CallbackIFvNS_9TimeTicksEELNS0_8CopyModeE1ELNS0_10RepeatModeE1EEEERKNS_7WeakPtrIS6_EEJRKSC_EEEvOT_OT0_DpOT1_ > #33 0x7f9e898c9ac3 > _ZN4base8internal7InvokerINS0_9BindStateIMN5blink9scheduler26SingleThreadIdleTaskRunnerEFvNS_8CallbackIFvNS_9TimeTicksEELNS0_8CopyModeE1ELNS0_10RepeatModeE1EEEEJNS_7WeakPtrIS5_EESB_EEEFvvEE7RunImplIRKSD_RKSt5tupleIJSF_SB_EEJLm0ELm1EEEEvOT_OT0_NS_13IndexSequenceIJXspT1_EEEE > #34 0x7f9e898c99dc > _ZN4base8internal7InvokerINS0_9BindStateIMN5blink9scheduler26SingleThreadIdleTaskRunnerEFvNS_8CallbackIFvNS_9TimeTicksEELNS0_8CopyModeE1ELNS0_10RepeatModeE1EEEEJNS_7WeakPtrIS5_EESB_EEEFvvEE3RunEPNS0_13BindStateBaseE > #35 0x7f9e98d33701 > _ZNO4base8internal8RunMixinINS_8CallbackIFvvELNS0_8CopyModeE0ELNS0_10RepeatModeE0EEEE3RunEv > #36 0x7f9e98d330d2 base::debug::TaskAnnotator::RunTask() > #37 0x7f9e8989cf41 > blink::scheduler::TaskQueueManager::ProcessTaskFromWorkQueue() > #38 0x7f9e8989a8c2 blink::scheduler::TaskQueueManager::DoWork() > #39 0x7f9e898a330c > _ZN4base8internal13FunctorTraitsIMN5blink9scheduler16TaskQueueManagerEFvNS_9TimeTicksEbEvE6InvokeIRKNS_7WeakPtrIS4_EEJRKS5_RKbEEEvS7_OT_DpOT0_ > #40 0x7f9e898a31e4 > _ZN4base8internal12InvokeHelperILb1EvE8MakeItSoIRKMN5blink9scheduler16TaskQueueManagerEFvNS_9TimeTicksEbERKNS_7WeakPtrIS6_EEJRKS7_RKbEEEvOT_OT0_DpOT1_ > #41 0x7f9e898a3144 > _ZN4base8internal7InvokerINS0_9BindStateIMN5blink9scheduler16TaskQueueManagerEFvNS_9TimeTicksEbEJNS_7WeakPtrIS5_EES6_bEEEFvvEE7RunImplIRKS8_RKSt5tupleIJSA_S6_bEEJLm0ELm1ELm2EEEEvOT_OT0_NS_13IndexSequenceIJXspT1_EEEE > #42 0x7f9e898a301c > _ZN4base8internal7InvokerINS0_9BindStateIMN5blink9scheduler16TaskQueueManagerEFvNS_9TimeTicksEbEJNS_7WeakPtrIS5_EES6_bEEEFvvEE3RunEPNS0_13BindStateBaseE > #43 0x7f9e98d33701 > _ZNO4base8internal8RunMixinINS_8CallbackIFvvELNS0_8CopyModeE0ELNS0_10RepeatModeE0EEEE3RunEv > #44 0x7f9e98d330d2 base::debug::TaskAnnotator::RunTask() > #45 0x7f9e98dc4e6a base::MessageLoop::RunTask() > #46 0x7f9e98dc50f4 base::MessageLoop::DeferOrRunPendingTask() > #47 0x7f9e98dc53de base::MessageLoop::DoWork() > #48 0x7f9e98ddcd33 base::MessagePumpDefault::Run() > #49 0x7f9e98dc49ea base::MessageLoop::RunHandler() > #50 0x7f9e98e6d484 base::RunLoop::Run() > #51 0x7f9e93887dec content::RendererMain() > #52 0x7f9e93c7da5e content::RunZygote() > #53 0x7f9e93c7de70 content::RunNamedProcessTypeMain() > #54 0x7f9e93c80292 content::ContentMainRunnerImpl::Run() > #55 0x7f9e93c7d102 content::ContentMain() > #56 0x7f9e99bb1dcb ChromeMain > #57 0x7f9e99bb1d62 main > #58 0x7f9e85947f45 __libc_start_main > #59 0x7f9e99bb1c65 <unknown> > r8: 0000000000000000 r9: 00007fffc1ef6900 r10: 00000000006c4020 r11: > 0000000000000202 > r12: 00007f9e99bb1c3c r13: 00007fffc1ef9c10 r14: 0000000000000000 r15: > 00007f9e89eb79c3 > di: 0000000000000000 si: 00007fffc1ef6680 bp: 00007fffc1ef63c0 bx: > 00007fffc1ef6c40 > dx: 00007fffc1ef68f8 ax: 0000000000000000 cx: 00007fffc1ef68f7 sp: > 00007fffc1ef63c0 > ip: 00007f9e7ec604cc efl: 0000000000010202 cgf: 0000000000000033 erf: > 0000000000000004 > trp: 000000000000000e msk: 0000000000000000 cr2: 0000000000000008 Yes, it is not related. Looks like a bad DCHECK in blink. I'll fix it.
On 2016/11/21 19:59:52, alph wrote: > On 2016/11/21 16:03:51, Tobias Tebbi wrote: > > The bug was (@Yang indeed) in the indexing of the literals array. I fixed it > and > > refactored the code accessing the inlined functions in the literals array. > > > > When running the timeline profiler in Chrome, I still get crashes from time to > > time, but they seem unrelated: > > > > Received signal 11 SEGV_MAPERR 000000000008 > > #0 0x7f9e98d2d87e base::debug::StackTrace::StackTrace() > > #1 0x7f9e98d2d3bf base::debug::(anonymous namespace)::StackDumpSignalHandler() > > #2 0x7f9e9917b330 <unknown> > > #3 0x7f9e7ec604cc WTF::StringImpl::is8Bit() > > #4 0x7f9e7ec9a69d WTF::String::is8Bit() > > #5 0x7f9e7fa2fa0b blink::maybeEncodeTextContent() > > #6 0x7f9e7fa2fed0 blink::InspectorPageAgent::cachedResourceContent() > > #7 0x7f9e7fa784a0 > blink::NetworkResourcesData::ResourceData::clearWeakMembers() > > #8 0x7f9e7fa7b007 blink::TraceMethodDelegate<>::trampoline() > > #9 0x7f9e8996a8fc blink::CallbackStack::Item::call() > > #10 0x7f9e89981d93 blink::ThreadState::popAndInvokeThreadLocalWeakCallback() > > #11 0x7f9e89981f7a blink::ThreadState::threadLocalWeakProcessing() > > #12 0x7f9e89987f78 blink::ThreadState::preSweep() > > #13 0x7f9e89988903 blink::ThreadState::leaveSafePoint() > > #14 0x7f9e89540cde blink::SafePointScope::~SafePointScope() > > #15 0x7f9e89983a61 blink::ThreadState::collectGarbage() > > #16 0x7f9e8998469c blink::ThreadState::performIdleGC() > > #17 0x7f9e8998c2be > > > _ZN4base8internal13FunctorTraitsIMN5blink11ThreadStateEFvdEvE6InvokeIPS3_JdEEEvS5_OT_DpOT0_ > > #18 0x7f9e8998c1c6 > > > _ZN4base8internal12InvokeHelperILb0EvE8MakeItSoIRKMN5blink11ThreadStateEFvdEJPS5_dEEEvOT_DpOT0_ > > #19 0x7f9e8998c157 > > > _ZN4base8internal7InvokerINS0_9BindStateIMN5blink11ThreadStateEFvdEJN3WTF17UnretainedWrapperIS4_LNS7_22FunctionThreadAffinityE1EEEEEEFvdEE7RunImplIRKS6_RKSt5tupleIJSA_EEJLm0EEEEvOT_OT0_NS_13IndexSequenceIJXspT1_EEEEOd > > #20 0x7f9e8998c08c > > > _ZN4base8internal7InvokerINS0_9BindStateIMN5blink11ThreadStateEFvdEJN3WTF17UnretainedWrapperIS4_LNS7_22FunctionThreadAffinityE1EEEEEEFvdEE3RunEPNS0_13BindStateBaseEOd > > #21 0x7f9e89543cf1 base::internal::RunMixin<>::Run() > > #22 0x7f9e89543c14 WTF::Function<>::operator()() > > #23 0x7f9e895439cb blink::(anonymous namespace)::IdleTaskRunner::run() > > #24 0x7f9e898ca385 blink::scheduler::WebSchedulerImpl::runIdleTask() > > #25 0x7f9e898cb5cf > > > _ZN4base8internal13FunctorTraitsIPFvSt10unique_ptrIN5blink9WebThread8IdleTaskESt14default_deleteIS5_EENS_9TimeTicksEEvE6InvokeIJS8_S9_EEEvSB_DpOT_ > > #26 0x7f9e898cb50d > > > _ZN4base8internal12InvokeHelperILb0EvE8MakeItSoIRKPFvSt10unique_ptrIN5blink9WebThread8IdleTaskESt14default_deleteIS7_EENS_9TimeTicksEEJSA_SB_EEEvOT_DpOT0_ > > #27 0x7f9e898cb4a7 > > > _ZN4base8internal7InvokerINS0_9BindStateIPFvSt10unique_ptrIN5blink9WebThread8IdleTaskESt14default_deleteIS6_EENS_9TimeTicksEEJNS0_13PassedWrapperIS9_EEEEEFvSA_EE7RunImplIRKSC_RKSt5tupleIJSE_EEJLm0EEEEvOT_OT0_NS_13IndexSequenceIJXspT1_EEEEOSA_ > > #28 0x7f9e898cb3dc > > > _ZN4base8internal7InvokerINS0_9BindStateIPFvSt10unique_ptrIN5blink9WebThread8IdleTaskESt14default_deleteIS6_EENS_9TimeTicksEEJNS0_13PassedWrapperIS9_EEEEEFvSA_EE3RunEPNS0_13BindStateBaseEOSA_ > > #29 0x7f9e898c9906 base::internal::RunMixin<>::Run() > > #30 0x7f9e898c945d blink::scheduler::SingleThreadIdleTaskRunner::RunTask() > > #31 0x7f9e898c9c4c > > > _ZN4base8internal13FunctorTraitsIMN5blink9scheduler26SingleThreadIdleTaskRunnerEFvNS_8CallbackIFvNS_9TimeTicksEELNS0_8CopyModeE1ELNS0_10RepeatModeE1EEEEvE6InvokeIRKNS_7WeakPtrIS4_EEJRKSA_EEEvSC_OT_DpOT0_ > > #32 0x7f9e898c9b4f > > > _ZN4base8internal12InvokeHelperILb1EvE8MakeItSoIRKMN5blink9scheduler26SingleThreadIdleTaskRunnerEFvNS_8CallbackIFvNS_9TimeTicksEELNS0_8CopyModeE1ELNS0_10RepeatModeE1EEEERKNS_7WeakPtrIS6_EEJRKSC_EEEvOT_OT0_DpOT1_ > > #33 0x7f9e898c9ac3 > > > _ZN4base8internal7InvokerINS0_9BindStateIMN5blink9scheduler26SingleThreadIdleTaskRunnerEFvNS_8CallbackIFvNS_9TimeTicksEELNS0_8CopyModeE1ELNS0_10RepeatModeE1EEEEJNS_7WeakPtrIS5_EESB_EEEFvvEE7RunImplIRKSD_RKSt5tupleIJSF_SB_EEJLm0ELm1EEEEvOT_OT0_NS_13IndexSequenceIJXspT1_EEEE > > #34 0x7f9e898c99dc > > > _ZN4base8internal7InvokerINS0_9BindStateIMN5blink9scheduler26SingleThreadIdleTaskRunnerEFvNS_8CallbackIFvNS_9TimeTicksEELNS0_8CopyModeE1ELNS0_10RepeatModeE1EEEEJNS_7WeakPtrIS5_EESB_EEEFvvEE3RunEPNS0_13BindStateBaseE > > #35 0x7f9e98d33701 > > > _ZNO4base8internal8RunMixinINS_8CallbackIFvvELNS0_8CopyModeE0ELNS0_10RepeatModeE0EEEE3RunEv > > #36 0x7f9e98d330d2 base::debug::TaskAnnotator::RunTask() > > #37 0x7f9e8989cf41 > > blink::scheduler::TaskQueueManager::ProcessTaskFromWorkQueue() > > #38 0x7f9e8989a8c2 blink::scheduler::TaskQueueManager::DoWork() > > #39 0x7f9e898a330c > > > _ZN4base8internal13FunctorTraitsIMN5blink9scheduler16TaskQueueManagerEFvNS_9TimeTicksEbEvE6InvokeIRKNS_7WeakPtrIS4_EEJRKS5_RKbEEEvS7_OT_DpOT0_ > > #40 0x7f9e898a31e4 > > > _ZN4base8internal12InvokeHelperILb1EvE8MakeItSoIRKMN5blink9scheduler16TaskQueueManagerEFvNS_9TimeTicksEbERKNS_7WeakPtrIS6_EEJRKS7_RKbEEEvOT_OT0_DpOT1_ > > #41 0x7f9e898a3144 > > > _ZN4base8internal7InvokerINS0_9BindStateIMN5blink9scheduler16TaskQueueManagerEFvNS_9TimeTicksEbEJNS_7WeakPtrIS5_EES6_bEEEFvvEE7RunImplIRKS8_RKSt5tupleIJSA_S6_bEEJLm0ELm1ELm2EEEEvOT_OT0_NS_13IndexSequenceIJXspT1_EEEE > > #42 0x7f9e898a301c > > > _ZN4base8internal7InvokerINS0_9BindStateIMN5blink9scheduler16TaskQueueManagerEFvNS_9TimeTicksEbEJNS_7WeakPtrIS5_EES6_bEEEFvvEE3RunEPNS0_13BindStateBaseE > > #43 0x7f9e98d33701 > > > _ZNO4base8internal8RunMixinINS_8CallbackIFvvELNS0_8CopyModeE0ELNS0_10RepeatModeE0EEEE3RunEv > > #44 0x7f9e98d330d2 base::debug::TaskAnnotator::RunTask() > > #45 0x7f9e98dc4e6a base::MessageLoop::RunTask() > > #46 0x7f9e98dc50f4 base::MessageLoop::DeferOrRunPendingTask() > > #47 0x7f9e98dc53de base::MessageLoop::DoWork() > > #48 0x7f9e98ddcd33 base::MessagePumpDefault::Run() > > #49 0x7f9e98dc49ea base::MessageLoop::RunHandler() > > #50 0x7f9e98e6d484 base::RunLoop::Run() > > #51 0x7f9e93887dec content::RendererMain() > > #52 0x7f9e93c7da5e content::RunZygote() > > #53 0x7f9e93c7de70 content::RunNamedProcessTypeMain() > > #54 0x7f9e93c80292 content::ContentMainRunnerImpl::Run() > > #55 0x7f9e93c7d102 content::ContentMain() > > #56 0x7f9e99bb1dcb ChromeMain > > #57 0x7f9e99bb1d62 main > > #58 0x7f9e85947f45 __libc_start_main > > #59 0x7f9e99bb1c65 <unknown> > > r8: 0000000000000000 r9: 00007fffc1ef6900 r10: 00000000006c4020 r11: > > 0000000000000202 > > r12: 00007f9e99bb1c3c r13: 00007fffc1ef9c10 r14: 0000000000000000 r15: > > 00007f9e89eb79c3 > > di: 0000000000000000 si: 00007fffc1ef6680 bp: 00007fffc1ef63c0 bx: > > 00007fffc1ef6c40 > > dx: 00007fffc1ef68f8 ax: 0000000000000000 cx: 00007fffc1ef68f7 sp: > > 00007fffc1ef63c0 > > ip: 00007f9e7ec604cc efl: 0000000000010202 cgf: 0000000000000033 erf: > > 0000000000000004 > > trp: 000000000000000e msk: 0000000000000000 cr2: 0000000000000008 > > Yes, it is not related. Looks like a bad DCHECK in blink. I'll fix it. lgtm!
The CQ bit was checked by tebbi@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from alph@chromium.org Link to the patchset: https://codereview.chromium.org/2503393002/#ps120001 (title: "addressed comment")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: v8_presubmit on master.tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_presubmit/builds/29072)
tebbi@chromium.org changed reviewers: + bmeurer@chromium.org - alph@chromium.org, tebbi@google.com, yangguo@chromium.org
I need an LGTM from a Crankshaft and Turbofan owner.
LGTM
The CQ bit was checked by tebbi@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
CQ is committing da patch.
Bot data: {"patchset_id": 120001, "attempt_start_ts": 1479809328526430,
"parent_rev": "2bc121ecab181667a2a43d799b30a7c58623077d", "commit_rev":
"f2eace1d096d67de3aa76b4a1c552d7c740716d1"}
Message was sent while issue was closed.
Description was changed from ========== [cpu-profiler] use new source position information for deoptimization in cpu profiler The new SourcePosition class allows for precise tracking of source positions including the stack of inlinings. This CL makes the cpu profiler use this new information. Before, the cpu profiler used the deoptimization data to reconstruct the inlining stack. However, optimizing compilers (especially Turbofan) can hoist out checks such that the inlining stack of the deopt reason and the inlining stack of the position the deoptimizer jumps to can be different (the old cpu profiler tests and the ones introduced in this cl produce such situations for turbofan). In this case, relying on the deoptimization info produces paradoxical results, where the reported position is before the function responsible is called. Even worse, https://codereview.chromium.org/2451853002/ combines the precise position with the wrong inlining stack from the deopt info, leading to completely wrong results. Other changes in this CL: - DeoptInlinedFrame is no longer needed, because we can compute the correct inlining stack up front. - I changed the cpu profiler tests back to test situations where deopt checks are hoisted out in Turbofan and made them robust enough to handle the differences between Crankshaft and Turbofan. - I reversed the order of SourcePosition::InliningStack to make it match the cpu profiler convention. - I removed CodeDeoptEvent::position, as it is no longer used. R=alph@chromium.org BUG=v8:5432 ========== to ========== [cpu-profiler] use new source position information for deoptimization in cpu profiler The new SourcePosition class allows for precise tracking of source positions including the stack of inlinings. This CL makes the cpu profiler use this new information. Before, the cpu profiler used the deoptimization data to reconstruct the inlining stack. However, optimizing compilers (especially Turbofan) can hoist out checks such that the inlining stack of the deopt reason and the inlining stack of the position the deoptimizer jumps to can be different (the old cpu profiler tests and the ones introduced in this cl produce such situations for turbofan). In this case, relying on the deoptimization info produces paradoxical results, where the reported position is before the function responsible is called. Even worse, https://codereview.chromium.org/2451853002/ combines the precise position with the wrong inlining stack from the deopt info, leading to completely wrong results. Other changes in this CL: - DeoptInlinedFrame is no longer needed, because we can compute the correct inlining stack up front. - I changed the cpu profiler tests back to test situations where deopt checks are hoisted out in Turbofan and made them robust enough to handle the differences between Crankshaft and Turbofan. - I reversed the order of SourcePosition::InliningStack to make it match the cpu profiler convention. - I removed CodeDeoptEvent::position, as it is no longer used. R=alph@chromium.org BUG=v8:5432 ==========
Message was sent while issue was closed.
Committed patchset #6 (id:120001)
Message was sent while issue was closed.
Description was changed from ========== [cpu-profiler] use new source position information for deoptimization in cpu profiler The new SourcePosition class allows for precise tracking of source positions including the stack of inlinings. This CL makes the cpu profiler use this new information. Before, the cpu profiler used the deoptimization data to reconstruct the inlining stack. However, optimizing compilers (especially Turbofan) can hoist out checks such that the inlining stack of the deopt reason and the inlining stack of the position the deoptimizer jumps to can be different (the old cpu profiler tests and the ones introduced in this cl produce such situations for turbofan). In this case, relying on the deoptimization info produces paradoxical results, where the reported position is before the function responsible is called. Even worse, https://codereview.chromium.org/2451853002/ combines the precise position with the wrong inlining stack from the deopt info, leading to completely wrong results. Other changes in this CL: - DeoptInlinedFrame is no longer needed, because we can compute the correct inlining stack up front. - I changed the cpu profiler tests back to test situations where deopt checks are hoisted out in Turbofan and made them robust enough to handle the differences between Crankshaft and Turbofan. - I reversed the order of SourcePosition::InliningStack to make it match the cpu profiler convention. - I removed CodeDeoptEvent::position, as it is no longer used. R=alph@chromium.org BUG=v8:5432 ========== to ========== [cpu-profiler] use new source position information for deoptimization in cpu profiler The new SourcePosition class allows for precise tracking of source positions including the stack of inlinings. This CL makes the cpu profiler use this new information. Before, the cpu profiler used the deoptimization data to reconstruct the inlining stack. However, optimizing compilers (especially Turbofan) can hoist out checks such that the inlining stack of the deopt reason and the inlining stack of the position the deoptimizer jumps to can be different (the old cpu profiler tests and the ones introduced in this cl produce such situations for turbofan). In this case, relying on the deoptimization info produces paradoxical results, where the reported position is before the function responsible is called. Even worse, https://codereview.chromium.org/2451853002/ combines the precise position with the wrong inlining stack from the deopt info, leading to completely wrong results. Other changes in this CL: - DeoptInlinedFrame is no longer needed, because we can compute the correct inlining stack up front. - I changed the cpu profiler tests back to test situations where deopt checks are hoisted out in Turbofan and made them robust enough to handle the differences between Crankshaft and Turbofan. - I reversed the order of SourcePosition::InliningStack to make it match the cpu profiler convention. - I removed CodeDeoptEvent::position, as it is no longer used. R=alph@chromium.org BUG=v8:5432 Committed: https://crrev.com/1b320d2039f961f8271a0b3e2a06abaf7bf0c3f0 Cr-Commit-Position: refs/heads/master@{#41168} ==========
Message was sent while issue was closed.
Patchset 6 (id:??) landed as https://crrev.com/1b320d2039f961f8271a0b3e2a06abaf7bf0c3f0 Cr-Commit-Position: refs/heads/master@{#41168} |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
