RESOLVED FIXED 76969
Make DFG update topCallFrame 
https://bugs.webkit.org/show_bug.cgi?id=76969
Summary Make DFG update topCallFrame
Oliver Hunt
Reported 2012-01-24 17:53:10 PST
Make DFG update topCallFrame
Attachments
Patch (24.15 KB, patch)
2012-01-24 17:56 PST, Oliver Hunt 		no flags
DetailsFormatted DiffDiff
Patch (24.08 KB, patch)
2012-01-24 17:57 PST, Oliver Hunt 		fpizlo: review+
DetailsFormatted DiffDiff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.
Oliver Hunt
Comment 1 2012-01-24 17:56:09 PST
Created attachment 123861 [details] Patch
Oliver Hunt
Comment 2 2012-01-24 17:57:48 PST
Created attachment 123862 [details] Patch
Filip Pizlo
Comment 3 2012-01-25 11:40:32 PST
Comment on attachment 123862 [details] Patch r=me.
Oliver Hunt
Comment 4 2012-01-25 11:43:41 PST
Committed r105905: <http://trac.webkit.org/changeset/105905>
Geoffrey Garen
Comment 5 2012-01-25 11:44:43 PST
Comment on attachment 123862 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=123862&action=review Can you post performance results? > Source/JavaScriptCore/interpreter/Interpreter.h:91 > + class NativeCallFrameTracer { > + public: > + ALWAYS_INLINE NativeCallFrameTracer(JSGlobalData* global, CallFrame* callFrame) > + { > + ASSERT(global); > + ASSERT(callFrame); > + global->topCallFrame = callFrame; > + } > + }; Is it OK that we don't reset topCallFrame on destruction? When do we need to reset it, and when can we skip that step? I don't think the words "native" and "tracer" are clear enough to distinguish NativeCallFrameTracer from TopCallFrameSetter. Answers to the above questions can provide us with a better name.
Note You need to log in before you can comment on or make changes to this bug.