<rdar://problem/18167563>

Created attachment 237361 [details] WIP: add hooks

Created attachment 237477 [details] Proposed fix Patch depends on 136381 and 136380. It fixes profile data, but a similar fix needs to happen for TimelineRecords, which independently record their own start/stop times.

Comment on attachment 237477 [details] Proposed fix View in context: https://bugs.webkit.org/attachment.cgi?id=237477&action=review > Source/JavaScriptCore/profiler/LegacyProfiler.cpp:141 > + callFunctionForProfilesWithGroup(std::bind(&ProfileGenerator::willExecute, std::placeholders::_1, callerCallFrame, callIdentifier), m_currentProfiles, callerCallFrame->lexicalGlobalObject()->profileGroup()); std::bind + std::placeholders === magic > Source/JavaScriptCore/profiler/ProfileGenerator.cpp:131 > + last.setTotalTime(m_debuggerPaused ? 0.0 : currentTime() - last.startTime()); Couldn't we subtract out the time between pause and resume?

Comment on attachment 237477 [details] Proposed fix View in context: https://bugs.webkit.org/attachment.cgi?id=237477&action=review >> Source/JavaScriptCore/profiler/LegacyProfiler.cpp:141 >> + callFunctionForProfilesWithGroup(std::bind(&ProfileGenerator::willExecute, std::placeholders::_1, callerCallFrame, callIdentifier), m_currentProfiles, callerCallFrame->lexicalGlobalObject()->profileGroup()); > > std::bind + std::placeholders === magic Yeah, it's almost like JavaScript. It can get you in trouble if you copy big things by accident. In this case (AFAIK), it will copy the arguments (a bunch of pointers and scalars) into a stuct on the stack. >> Source/JavaScriptCore/profiler/ProfileGenerator.cpp:131 >> + last.setTotalTime(m_debuggerPaused ? 0.0 : currentTime() - last.startTime()); > > Couldn't we subtract out the time between pause and resume? Yeah, it could do something like that, or reset the start time of all active nodes when didContinue is received. I would have to examine the order of operations more closely, but when I wrote this patch I never hit a breakpoint inside didPause- the debugger was already paused by the time the profiler got the willExecute. Maybe I need to set the breakpoint so it will pause with a bigger call stack. I have no quick way of testing a smarter approach because the timeline records still have wrong times and those seem to be used as the timeline row's "overall" time.

Committed r173264: <http://trac.webkit.org/changeset/173264>