Web Inspector: JSContext inspection should report exceptions in the console
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2014-02-21  Joseph Pecoraro  <pecoraro@apple.com>
2
3         Web Inspector: JSContext inspection should report exceptions in the console
4         https://bugs.webkit.org/show_bug.cgi?id=128776
5
6         Reviewed by Timothy Hatcher.
7
8         When JavaScript API functions have an exception, let the inspector
9         know so it can log the JavaScript and Native backtrace that caused
10         the exception.
11
12         Include some clean up of ConsoleMessage and ScriptCallStack construction.
13
14         * API/JSBase.cpp:
15         (JSEvaluateScript):
16         (JSCheckScriptSyntax):
17         * API/JSObjectRef.cpp:
18         (JSObjectMakeFunction):
19         (JSObjectMakeArray):
20         (JSObjectMakeDate):
21         (JSObjectMakeError):
22         (JSObjectMakeRegExp):
23         (JSObjectGetProperty):
24         (JSObjectSetProperty):
25         (JSObjectGetPropertyAtIndex):
26         (JSObjectSetPropertyAtIndex):
27         (JSObjectDeleteProperty):
28         (JSObjectCallAsFunction):
29         (JSObjectCallAsConstructor):
30         * API/JSValue.mm:
31         (reportExceptionToInspector):
32         (valueToArray):
33         (valueToDictionary):
34         * API/JSValueRef.cpp:
35         (JSValueIsEqual):
36         (JSValueIsInstanceOfConstructor):
37         (JSValueCreateJSONString):
38         (JSValueToNumber):
39         (JSValueToStringCopy):
40         (JSValueToObject):
41         When seeing an exception, let the inspector know there was an exception.
42
43         * inspector/JSGlobalObjectInspectorController.h:
44         * inspector/JSGlobalObjectInspectorController.cpp:
45         (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
46         (Inspector::JSGlobalObjectInspectorController::appendAPIBacktrace):
47         (Inspector::JSGlobalObjectInspectorController::reportAPIException):
48         Log API exceptions by also grabbing the native backtrace.
49
50         * inspector/ScriptCallStack.h:
51         * inspector/ScriptCallStack.cpp:
52         (Inspector::ScriptCallStack::firstNonNativeCallFrame):
53         (Inspector::ScriptCallStack::append):
54         Minor extensions to ScriptCallStack to make it easier to work with.
55
56         * inspector/ConsoleMessage.cpp:
57         (Inspector::ConsoleMessage::ConsoleMessage):
58         (Inspector::ConsoleMessage::autogenerateMetadata):
59         Provide better default information if the first call frame was native.
60
61         * inspector/ScriptCallStackFactory.cpp:
62         (Inspector::createScriptCallStack):
63         (Inspector::extractSourceInformationFromException):
64         (Inspector::createScriptCallStackFromException):
65         Perform the handling here of inserting a fake call frame for exceptions
66         if there was no call stack (e.g. a SyntaxError) or if the first call
67         frame had no information.
68
69         * inspector/ConsoleMessage.cpp:
70         (Inspector::ConsoleMessage::ConsoleMessage):
71         (Inspector::ConsoleMessage::autogenerateMetadata):
72         * inspector/ConsoleMessage.h:
73         * inspector/ScriptCallStackFactory.cpp:
74         (Inspector::createScriptCallStack):
75         (Inspector::createScriptCallStackForConsole):
76         * inspector/ScriptCallStackFactory.h:
77         * inspector/agents/InspectorConsoleAgent.cpp:
78         (Inspector::InspectorConsoleAgent::enable):
79         (Inspector::InspectorConsoleAgent::addMessageToConsole):
80         (Inspector::InspectorConsoleAgent::count):
81         * inspector/agents/JSGlobalObjectDebuggerAgent.cpp:
82         (Inspector::JSGlobalObjectDebuggerAgent::breakpointActionLog):
83         ConsoleMessage cleanup.
84
85 2014-02-20  Anders Carlsson  <andersca@apple.com>
86
87         Modernize JSGlobalLock and JSLockHolder
88         https://bugs.webkit.org/show_bug.cgi?id=129105
89
90         Reviewed by Michael Saboff.
91
92         Use std::mutex and std::thread::id where possible.
93
94         * runtime/JSLock.cpp:
95         (JSC::GlobalJSLock::GlobalJSLock):
96         (JSC::GlobalJSLock::~GlobalJSLock):
97         (JSC::GlobalJSLock::initialize):
98         (JSC::JSLock::JSLock):
99         (JSC::JSLock::lock):
100         (JSC::JSLock::unlock):
101         (JSC::JSLock::currentThreadIsHoldingLock):
102         * runtime/JSLock.h:
103
104 2014-02-20  Mark Lam  <mark.lam@apple.com>
105
106         virtualForWithFunction() should not throw an exception with a partially initialized frame.
107         <https://webkit.org/b/129134>
108
109         Reviewed by Michael Saboff.
110
111         Currently, when JITOperations.cpp's virtualForWithFunction() fails to
112         prepare the callee function for execution, it proceeds to throw the
113         exception using the callee frame which is only partially initialized
114         thus far. Instead, it should be throwing the exception using the caller
115         frame because:
116         1. the error happened "in" the caller while preparing the callee for
117            execution i.e. the caller frame is the top fully initialized frame
118            on the stack.
119         2. the callee frame is not fully initialized yet, and the unwind
120            mechanism cannot depend on the data in it.
121
122         * jit/JITOperations.cpp:
123
124 2014-02-20  Mark Lam  <mark.lam@apple.com>
125
126         DefaultGCActivityCallback::doWork() should reschedule if GC is deferred.
127         <https://webkit.org/b/129131>
128
129         Reviewed by Mark Hahnenberg.
130
131         Currently, DefaultGCActivityCallback::doWork() does not check if the GC
132         needs to be deferred before commencing. As a result, the GC may crash
133         and/or corrupt data because the VM is not in the consistent state needed
134         for the GC to run. With this fix, doWork() now checks if the GC is
135         supposed to be deferred and re-schedules if needed. It only commences
136         with GC'ing when it's safe to do so.
137
138         * runtime/GCActivityCallback.cpp:
139         (JSC::DefaultGCActivityCallback::doWork):
140
141 2014-02-20  Geoffrey Garen  <ggaren@apple.com>
142
143         Math.imul gives wrong results
144         https://bugs.webkit.org/show_bug.cgi?id=126345
145
146         Reviewed by Mark Hahnenberg.
147
148         Don't truncate non-int doubles to 0 -- that's just not how ToInt32 works.
149         Instead, take a slow path that will do the right thing.
150
151         * jit/ThunkGenerators.cpp:
152         (JSC::imulThunkGenerator):
153
154 2014-02-20  Filip Pizlo  <fpizlo@apple.com>
155
156         DFG should do its own static estimates of execution frequency before it starts creating OSR entrypoints
157         https://bugs.webkit.org/show_bug.cgi?id=129129
158
159         Reviewed by Geoffrey Garen.
160         
161         We estimate execution counts based on loop depth, and then use those to estimate branch
162         weights. These weights then get carried all the way down to LLVM prof branch_weights
163         meta-data.
164         
165         This is better than letting LLVM do its own static estimates, since by the time we
166         generate LLVM IR, we may have messed up the CFG due to OSR entrypoint creation. Of
167         course, it would be even better if we just slurped in some kind of execution counts
168         from profiling, but we don't do that, yet.
169
170         * CMakeLists.txt:
171         * GNUmakefile.list.am:
172         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
173         * JavaScriptCore.xcodeproj/project.pbxproj:
174         * dfg/DFGBasicBlock.cpp:
175         (JSC::DFG::BasicBlock::BasicBlock):
176         * dfg/DFGBasicBlock.h:
177         * dfg/DFGBlockInsertionSet.cpp:
178         (JSC::DFG::BlockInsertionSet::insert):
179         (JSC::DFG::BlockInsertionSet::insertBefore):
180         * dfg/DFGBlockInsertionSet.h:
181         * dfg/DFGByteCodeParser.cpp:
182         (JSC::DFG::ByteCodeParser::handleInlining):
183         (JSC::DFG::ByteCodeParser::parseCodeBlock):
184         * dfg/DFGCriticalEdgeBreakingPhase.cpp:
185         (JSC::DFG::CriticalEdgeBreakingPhase::breakCriticalEdge):
186         * dfg/DFGLoopPreHeaderCreationPhase.cpp:
187         (JSC::DFG::createPreHeader):
188         * dfg/DFGNaturalLoops.h:
189         (JSC::DFG::NaturalLoops::loopDepth):
190         * dfg/DFGOSREntrypointCreationPhase.cpp:
191         (JSC::DFG::OSREntrypointCreationPhase::run):
192         * dfg/DFGPlan.cpp:
193         (JSC::DFG::Plan::compileInThreadImpl):
194         * dfg/DFGStaticExecutionCountEstimationPhase.cpp: Added.
195         (JSC::DFG::StaticExecutionCountEstimationPhase::StaticExecutionCountEstimationPhase):
196         (JSC::DFG::StaticExecutionCountEstimationPhase::run):
197         (JSC::DFG::StaticExecutionCountEstimationPhase::applyCounts):
198         (JSC::DFG::performStaticExecutionCountEstimation):
199         * dfg/DFGStaticExecutionCountEstimationPhase.h: Added.
200
201 2014-02-20  Filip Pizlo  <fpizlo@apple.com>
202
203         FTL may not see a compact_unwind section if there weren't any stackmaps
204         https://bugs.webkit.org/show_bug.cgi?id=129125
205
206         Reviewed by Geoffrey Garen.
207         
208         It's OK to not have an unwind section, so long as the function also doesn't have any
209         OSR exits.
210
211         * ftl/FTLCompile.cpp:
212         (JSC::FTL::fixFunctionBasedOnStackMaps):
213         (JSC::FTL::compile):
214         * ftl/FTLUnwindInfo.cpp:
215         (JSC::FTL::UnwindInfo::parse):
216         * ftl/FTLUnwindInfo.h:
217
218 == Rolled over to ChangeLog-2014-02-20 ==