Unreviewed, rolling out r189136.
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2015-08-28  Commit Queue  <commit-queue@webkit.org>
2
3         Unreviewed, rolling out r189136.
4         https://bugs.webkit.org/show_bug.cgi?id=148608
5
6         Made JSC tests flaky (Requested by ap on #webkit).
7
8         Reverted changeset:
9
10         "[JSC][x86] Improve the compare functions when comparing with
11         zero"
12         https://bugs.webkit.org/show_bug.cgi?id=148536
13         http://trac.webkit.org/changeset/189136
14
15 2015-08-28  Benjamin Poulain  <bpoulain@apple.com>
16
17         [JSC] Get rid of DFG's MergeMode
18         https://bugs.webkit.org/show_bug.cgi?id=148245
19
20         Reviewed by Mark Lam.
21
22         That code has become useless, the merge mode is always MergeToSuccessors.
23
24         * JavaScriptCore.xcodeproj/project.pbxproj:
25         * dfg/DFGCFAPhase.cpp:
26         (JSC::DFG::CFAPhase::performBlockCFA):
27         * dfg/DFGInPlaceAbstractState.cpp:
28         (JSC::DFG::InPlaceAbstractState::endBasicBlock):
29         * dfg/DFGInPlaceAbstractState.h:
30         * dfg/DFGMergeMode.h: Removed.
31
32 2015-08-28  Benjamin Poulain  <bpoulain@apple.com>
33
34         [JSC][x86] Improve the compare functions when comparing with zero
35         https://bugs.webkit.org/show_bug.cgi?id=148536
36
37         Reviewed by Geoffrey Garen.
38
39         This patch has two parts:
40         1) The macro assembler gets an additional cmp->test optimization
41            for LessThan and GreaterThanOrEqual.
42            Instead of comparing the value with an immediate, test the value
43            with itself and use the flag.
44         2) Extend the DFG JIT optimization of compare.
45            In particular, use the same optimization in compileInt32Compare()
46            as we have in compilePeepHoleBooleanBranch().
47            The generator compileInt32Compare() is unfortunately very
48            common due to MoveHints placed between the Compare node and the Branch
49            node.
50
51         * assembler/MacroAssembler.h:
52         (JSC::MacroAssembler::compare32):
53         * assembler/MacroAssemblerX86Common.h:
54         (JSC::MacroAssemblerX86Common::branch32):
55         (JSC::MacroAssemblerX86Common::compare32):
56         * dfg/DFGSpeculativeJIT.cpp:
57         (JSC::DFG::SpeculativeJIT::compilePeepHoleBooleanBranch):
58         * dfg/DFGSpeculativeJIT64.cpp:
59         (JSC::DFG::SpeculativeJIT::compileInt32Compare):
60
61 2015-08-28  Mark Lam  <mark.lam@apple.com>
62
63         Add MacroAssemblerPrinter support for printing memory.
64         https://bugs.webkit.org/show_bug.cgi?id=148600
65
66         Reviewed by Saam Barati.
67
68         Previously, we can dump registers at runtime.  Now we can dump memory too.
69         See comment in MacroAssemblerPrinter.h for examples of how to do this.
70
71         * assembler/MacroAssemblerPrinter.cpp:
72         (JSC::printMemory):
73         (JSC::MacroAssemblerPrinter::printCallback):
74         * assembler/MacroAssemblerPrinter.h:
75         (JSC::Memory::Memory):
76         (JSC::MemWord::MemWord):
77         (JSC::MacroAssemblerPrinter::PrintArg::PrintArg):
78
79 2015-08-28  Khem Raj  <raj.khem@gmail.com>
80
81         JavaScriptCore fails to build using GCC 5
82         https://bugs.webkit.org/show_bug.cgi?id=147815
83
84         Reviewed by Filip Pizlo.
85
86         * runtime/JSObject.cpp: Explicitly instantiate all variants of
87         putByIndexBeyondVectorLengthWithAttributes used by JSArray.cpp.
88
89 2015-08-28  Mark Lam  <mark.lam@apple.com>
90
91         Refactor the JIT printer out of the AbstractMacroAssembler into MacroAssemblerPrinter.
92         https://bugs.webkit.org/show_bug.cgi?id=148595
93
94         Reviewed by Geoffrey Garen.
95
96         Why do this?
97         1. MacroAssembler::print() code (except for the prototype) need no longer be parsed
98            when compiling C++ files that don't need it.
99         2. Adding support for more printable types to MacroAssemblerPrinter::PrintArg
100            triggers recompilation of less files.
101         3. The printing code is for most the part common between all target platforms and
102            was previously duplicated by cut-and-paste to all the varieties of MacroAssemblers
103            that support the MASM_PROBE mechanism.  Now, there is only one copy in
104            MacroAssemblerPrinter.
105
106         * CMakeLists.txt:
107         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
108         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
109         * JavaScriptCore.xcodeproj/project.pbxproj:
110
111         * assembler/AbstractMacroAssembler.h:
112         (JSC::AbstractMacroAssembler::ProbeContext::print): Deleted.
113         - Removed this function because it is no longer useful since we have this more
114           flexible print() functionality.
115
116         (JSC::AbstractMacroAssembler::printIndent): Deleted.
117         (JSC::AbstractMacroAssembler::printCPU): Deleted.
118         (JSC::AbstractMacroAssembler::print): Deleted.
119         (JSC::AbstractMacroAssembler::PrintArg::PrintArg): Deleted.
120         (JSC::AbstractMacroAssembler::appendPrintArg): Deleted.
121         (JSC::AbstractMacroAssembler::printInternal): Deleted.
122         (JSC::AbstractMacroAssembler::printCallback): Deleted.
123         - These got moved into MacroAssemblerPrinter.cpp.
124
125         * assembler/MacroAssembler.h:
126         * assembler/MacroAssemblerARM.cpp:
127         (JSC::MacroAssemblerARM::printCPURegisters): Deleted.
128         (JSC::MacroAssemblerARM::printRegister): Deleted.
129         * assembler/MacroAssemblerARM.h:
130         * assembler/MacroAssemblerARMv7.cpp:
131         (JSC::MacroAssemblerARMv7::printCPURegisters): Deleted.
132         (JSC::MacroAssemblerARMv7::printRegister): Deleted.
133         * assembler/MacroAssemblerARMv7.h:
134         * assembler/MacroAssemblerX86Common.cpp:
135         (JSC::MacroAssemblerX86Common::printCPURegisters): Deleted.
136         (JSC::MacroAssemblerX86Common::printRegister): Deleted.
137         * assembler/MacroAssemblerX86Common.h:
138         - Deleted a whole bunch of mostly duplicated code.
139
140         * assembler/MacroAssemblerPrinter.cpp: Added.
141         (JSC::printIndent):
142         (JSC::printCPU):
143         (JSC::printCPURegisters):
144         (JSC::printRegister):
145         (JSC::MacroAssemblerPrinter::printCallback):
146         * assembler/MacroAssemblerPrinter.h: Added.
147         (JSC::MacroAssemblerPrinter::print):
148         (JSC::MacroAssemblerPrinter::PrintArg::PrintArg):
149         (JSC::MacroAssemblerPrinter::appendPrintArg):
150         (JSC::MacroAssembler::print):
151
152 2015-08-28  Filip Pizlo  <fpizlo@apple.com>
153
154         LICM should be sound even if the CFG has changed
155         https://bugs.webkit.org/show_bug.cgi?id=148259
156
157         Reviewed by Benjamin Poulain.
158
159         Prior to this change, LICM expected a certain CFG shape around a loop: broken critical edges,
160         a pre-header, and the pre-header's terminal has exitOK. LICM would either crash on an
161         assertion, or generate code that fails validation, if these conditions weren't met.
162
163         The broken critical edge assumption is fine; so far we are assuming that SSA means broken
164         critical edges. We may revisit this, but we don't have to right now.
165
166         The other assumptions are not fine, because it's hard to guarantee that every phase will
167         preserve the presence of pre-headers. Even if we required that pre-headers are regenerated
168         before LICM, that regeneration wouldn't be guaranteed to create pre-headers that have exitOK at
169         the terminal. That's because once in SSA, the loop header probably has exitOK=false at the
170         head because of Phi's. Pre-header creation has no choice but to use the Node::origin from the
171         loop header, which means creating a pre-header that has exitOK=false. Regardless of whether
172         that's a fixable problem, it seems that our best short-term approach is just to be defensive
173         and turn undesirable pathologies into performance bugs and not crashes.
174
175         For the foreseeable future, once pre-headers are created they will probably not be removed. Our
176         current CFG simplification phase doesn't have a rule for removing pre-headers (since it doesn't
177         have any jump threading). So, it wouldn't be profitable to put effort towards reneration of
178         pre-headers for LICM's benefit.
179
180         Also, we cannot guarantee that some sequence of CFG transformations will not create a loop that
181         doesn't have a pre-header. This would be super rare. But you could imagine that some program
182         has control flow encoded using relooping (like
183         https://github.com/kripken/Relooper/blob/master/paper.pdf). If that happens, our compiler will
184         probably incrementally discover the "original" CFG. That may happen only after SSA conversion,
185         and so after pre-header generation. This is super unlikely for a bunch of reasons, but it
186         *could* happen.
187
188         So, this patch just makes sure that if pre-headers are missing or cannot be exited from, LICM
189         will simply avoid hoisting out of that block. At some point later, we can worry about a more
190         comprehensive solution to the pre-header problem. That's covered by this bug:
191         https://bugs.webkit.org/show_bug.cgi?id=148586
192
193         * dfg/DFGLICMPhase.cpp:
194         (JSC::DFG::LICMPhase::run):
195         (JSC::DFG::LICMPhase::attemptHoist):
196         * dfg/DFGPlan.cpp:
197         (JSC::DFG::Plan::compileInThreadImpl):
198         * runtime/Options.h:
199         * tests/stress/licm-no-pre-header.js: Added.
200         (foo):
201         * tests/stress/licm-pre-header-cannot-exit.js: Added.
202         (foo):
203
204 2015-08-28  Yusuke Suzuki  <utatane.tea@gmail.com>
205
206         Move std::function from JSFunction into NativeStdFunctionCell to correctly destroy the heap allocated std::function
207         https://bugs.webkit.org/show_bug.cgi?id=148262
208
209         Reviewed by Filip Pizlo.
210
211         std::function is heap allocated value. So if this is held in the JSCell, the cell should be destructible.
212         Before this patch, it is held in the JSStdFunction. JSStdFunction is the derived class from the JSFunction,
213         and they are not destructible. So it leaked the memory.
214
215         This patch extracts std::function field from the JSStdFunction to the NativeStdFunctionCell. NativeStdFunctionCell
216         is responsible for destructing the held std::function.
217         Instead of moving std::function to the ExecutableBase, we move it to the newly created NativeStdFunctionCell cell.
218         The reason is the following.
219
220         - Each NativeExecutable (in 64_32 JIT environment) has the trampolines to call given host functions.
221           And the address of the host function is directly embedded on the JIT-compiled trampoline code.
222         - To suppress the overuse of the executable memory (which is used to generate the trampoline), NativeExecutable
223           is cached. The host function address is used as the key to look up the cached executable from the table.
224         - In all the JSStdFunction, we use the same host function that immediately calls the each std::function.
225         - As a result, without any change, all the JSStdFunction hit the same cached NativeExecutable even if the held
226           std::function is different.
227         - To solve it, if we put the std::function in the NativeExecutable, we need to add this std::function
228           identity (like address) to the cache key, because the address of the stub host function (that calls the
229           std::function) is the same in the all JSStdFunction.
230         - But since the std::function will be allocated in the heap, this address is always different. So caching has
231           no effect.
232         - If we do not cache the NativeExecutable that holds the std::function, each time when creating the JSStdFunction,
233           we need to regenerate the completely same trampolines (since it just calls the same host function stub that
234           calls the std::function).
235
236         And this patch drops JSArrowFunction::destroy because (1) JSArrowFunction is not destructible and (2) it no longer
237         holds any fields that require destructions.
238
239         * CMakeLists.txt:
240         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
241         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
242         * JavaScriptCore.xcodeproj/project.pbxproj:
243         * jsc.cpp:
244         (runWithScripts):
245         * runtime/JSArrowFunction.cpp:
246         (JSC::JSArrowFunction::destroy): Deleted.
247         * runtime/JSArrowFunction.h:
248         * runtime/JSFunction.cpp:
249         (JSC::JSFunction::lookUpOrCreateNativeExecutable):
250         (JSC::JSFunction::create):
251         (JSC::getNativeExecutable): Deleted.
252         (JSC::JSStdFunction::JSStdFunction): Deleted.
253         (JSC::runStdFunction): Deleted.
254         * runtime/JSFunction.h:
255         * runtime/JSGlobalObject.cpp:
256         (JSC::JSGlobalObject::init):
257         (JSC::JSGlobalObject::visitChildren):
258         * runtime/JSGlobalObject.h:
259         (JSC::JSGlobalObject::nativeStdFunctionStructure):
260         * runtime/JSNativeStdFunction.cpp: Added.
261         (JSC::JSNativeStdFunction::JSNativeStdFunction):
262         (JSC::JSNativeStdFunction::visitChildren):
263         (JSC::JSNativeStdFunction::finishCreation):
264         (JSC::runStdFunction):
265         (JSC::JSNativeStdFunction::create):
266         * runtime/JSNativeStdFunction.h: Copied from Source/JavaScriptCore/runtime/JSArrowFunction.h.
267         (JSC::JSNativeStdFunction::createStructure):
268         (JSC::JSNativeStdFunction::nativeStdFunctionCell):
269         * runtime/NativeStdFunctionCell.cpp: Added.
270         (JSC::NativeStdFunctionCell::create):
271         (JSC::NativeStdFunctionCell::NativeStdFunctionCell):
272         (JSC::NativeStdFunctionCell::destroy):
273         * runtime/NativeStdFunctionCell.h: Added.
274         (JSC::NativeStdFunctionCell::createStructure):
275         (JSC::NativeStdFunctionCell::function):
276         * runtime/VM.cpp:
277         (JSC::VM::VM):
278         * runtime/VM.h:
279
280 2015-08-28  Sukolsak Sakshuwong  <sukolsak@gmail.com>
281
282         Create WebAssembly functions
283         https://bugs.webkit.org/show_bug.cgi?id=148373
284
285         Reviewed by Filip Pizlo.
286
287         Create functions from WebAssembly files generated by pack-asmjs
288         <https://github.com/WebAssembly/polyfill-prototype-1>.
289         WebAssembly functions created by this patch can only return 0.
290         Actual code generation will be implemented in subsequent patches.
291
292         This patch introduces WebAssemblyExecutable, a new subclass of
293         ExecutableBase for WebAssembly functions. CodeBlocks can now have
294         an owner that is not a ScriptExecutable. This patch changes the
295         return type of CodeBlock::ownerExecutable() from ScriptExecutable*
296         to ExecutableBase*. It also changes code that calls ScriptExecutable's
297         methods on CodeBlock::ownerExecutable() to use
298         CodeBlock::ownerScriptExecutable(), which does jsCast<ScriptExecutable*>.
299
300         Since ownerScriptExecutable() is called from WebCore and it uses
301         jsCast<ScriptExecutable*>, this patch needs to export
302         ScriptExecutable::info(). This should fix the build error in
303         https://bugs.webkit.org/show_bug.cgi?id=148555
304
305         * bytecode/CodeBlock.cpp:
306         (JSC::CodeBlock::hash):
307         (JSC::CodeBlock::sourceCodeForTools):
308         (JSC::CodeBlock::dumpAssumingJITType):
309         (JSC::CodeBlock::dumpSource):
310         (JSC::CodeBlock::CodeBlock):
311         (JSC::CodeBlock::finalizeUnconditionally):
312         (JSC::CodeBlock::lineNumberForBytecodeOffset):
313         (JSC::CodeBlock::expressionRangeForBytecodeOffset):
314         (JSC::CodeBlock::install):
315         (JSC::CodeBlock::newReplacement):
316         (JSC::WebAssemblyCodeBlock::replacement):
317         (JSC::WebAssemblyCodeBlock::capabilityLevelInternal):
318         (JSC::CodeBlock::updateAllPredictions):
319         (JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
320         * bytecode/CodeBlock.h:
321         (JSC::CodeBlock::ownerExecutable):
322         (JSC::CodeBlock::ownerScriptExecutable):
323         (JSC::CodeBlock::codeType):
324         (JSC::WebAssemblyCodeBlock::WebAssemblyCodeBlock):
325         * debugger/Debugger.cpp:
326         (JSC::Debugger::toggleBreakpoint):
327         * debugger/DebuggerCallFrame.cpp:
328         (JSC::DebuggerCallFrame::sourceIDForCallFrame):
329         * dfg/DFGByteCodeParser.cpp:
330         (JSC::DFG::ByteCodeParser::InlineStackEntry::executable):
331         (JSC::DFG::ByteCodeParser::inliningCost):
332         (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
333         (JSC::DFG::ByteCodeParser::parseCodeBlock):
334         * dfg/DFGCapabilities.cpp:
335         (JSC::DFG::isSupportedForInlining):
336         (JSC::DFG::mightCompileEval):
337         (JSC::DFG::mightCompileProgram):
338         (JSC::DFG::mightCompileFunctionForCall):
339         (JSC::DFG::mightCompileFunctionForConstruct):
340         * dfg/DFGGraph.h:
341         (JSC::DFG::Graph::executableFor):
342         * dfg/DFGOSREntry.cpp:
343         (JSC::DFG::prepareOSREntry):
344         * inspector/ScriptCallStackFactory.cpp:
345         (Inspector::CreateScriptCallStackFunctor::operator()):
346         * interpreter/Interpreter.cpp:
347         (JSC::eval):
348         (JSC::isWebAssemblyExecutable):
349         (JSC::GetStackTraceFunctor::operator()):
350         (JSC::UnwindFunctor::operator()):
351         * interpreter/StackVisitor.cpp:
352         (JSC::StackVisitor::Frame::sourceURL):
353         (JSC::StackVisitor::Frame::computeLineAndColumn):
354         * jit/JITOperations.cpp:
355         * jit/Repatch.cpp:
356         (JSC::linkPolymorphicCall):
357         * llint/LLIntData.cpp:
358         (JSC::LLInt::Data::performAssertions):
359         * llint/LLIntSlowPaths.cpp:
360         (JSC::LLInt::setUpCall):
361         * llint/LowLevelInterpreter.asm:
362         * runtime/CommonSlowPaths.cpp:
363         (JSC::SLOW_PATH_DECL):
364         * runtime/Executable.cpp:
365         (JSC::WebAssemblyExecutable::WebAssemblyExecutable):
366         (JSC::WebAssemblyExecutable::destroy):
367         (JSC::WebAssemblyExecutable::visitChildren):
368         (JSC::WebAssemblyExecutable::clearCode):
369         (JSC::WebAssemblyExecutable::prepareForExecution):
370         * runtime/Executable.h:
371         (JSC::ExecutableBase::isEvalExecutable):
372         (JSC::ExecutableBase::isFunctionExecutable):
373         (JSC::ExecutableBase::isProgramExecutable):
374         (JSC::ExecutableBase::isWebAssemblyExecutable):
375         (JSC::ExecutableBase::clearCodeVirtual):
376         * runtime/JSFunction.cpp:
377         (JSC::JSFunction::create):
378         * runtime/JSFunction.h:
379         * runtime/JSFunctionInlines.h:
380         (JSC::JSFunction::JSFunction):
381         (JSC::JSFunction::isBuiltinFunction):
382         * runtime/JSType.h:
383         * runtime/VM.cpp:
384         (JSC::VM::VM):
385         * runtime/VM.h:
386         * wasm/JSWASMModule.h:
387         (JSC::JSWASMModule::functions):
388         * wasm/WASMFunctionParser.cpp:
389         (JSC::WASMFunctionParser::compile):
390         * wasm/WASMFunctionParser.h:
391         * wasm/WASMModuleParser.cpp:
392         (JSC::WASMModuleParser::WASMModuleParser):
393         (JSC::WASMModuleParser::parse):
394         (JSC::WASMModuleParser::parseFunctionDeclarationSection):
395         (JSC::WASMModuleParser::parseFunctionDefinition):
396         (JSC::WASMModuleParser::parseExportSection):
397         (JSC::parseWebAssembly):
398         * wasm/WASMModuleParser.h:
399
400 2015-08-28  Mark Lam  <mark.lam@apple.com>
401
402         [Follow up] ScratchRegisterAllocator::preserveReusedRegistersByPushing() should allow room for C helper calls and keep sp properly aligned.
403         https://bugs.webkit.org/show_bug.cgi?id=148564
404
405         Not reviewed.
406
407         Updated the test to run with //@ runNoCJITNoAccessInlining instead of specifying
408         the JSC option directly via //@ run().  This is the right thing to do in order
409         to guarantee that the test will be compiled by the DFG.
410
411         * tests/stress/regress-148564.js:
412
413 2015-08-28  Joseph Pecoraro  <pecoraro@apple.com>
414
415         Web Inspector: Separate creating a style sheet from adding a new rule in the protocol
416         https://bugs.webkit.org/show_bug.cgi?id=148502
417
418         Reviewed by Timothy Hatcher.
419
420         * inspector/protocol/CSS.json:
421         Add CSS.createStyleSheet. Modify CSS.addRule.
422
423 2015-08-28  Mark Lam  <mark.lam@apple.com>
424
425         ScratchRegisterAllocator::preserveReusedRegistersByPushing() should allow room for C helper calls and keep sp properly aligned.
426         https://bugs.webkit.org/show_bug.cgi?id=148564
427
428         Reviewed by Saam Barati.
429
430         ScratchRegisterAllocator::preserveReusedRegistersByPushing() pushes registers on
431         the stack in order to preserve them.  But emitPutTransitionStub() (which uses
432         preserveReusedRegistersByPushing()) may also emit a call to a C helper function
433         to flush the heap write barrier buffer.  The code for emitting a C helper call
434         expects the stack pointer (sp) to already be pointing to a location on the stack
435         where there's adequate space reserved for storing the arguments to the C helper,
436         and that space is expected to be at the top of the stack.  Hence, there is a
437         conflict of expectations.  As a result, the arguments for the C helper will
438         overwrite and corrupt the values that are pushed on the stack by
439         preserveReusedRegistersByPushing().
440
441         In addition, JIT compiled functions always position the sp such that it will be
442         aligned (according to platform ABI dictates) after a C call is made (i.e. after
443         the frame pointer and return address is pushed on to the stack).
444         preserveReusedRegistersByPushing()'s arbitrary pushing of a number of saved
445         register values may mess up this alignment.
446
447         The fix is to have preserveReusedRegistersByPushing(), after it has pushed the
448         saved register values, adjust the sp to reserve an additional amount of stack
449         space needed for C call helpers plus any padding needed to restore proper sp
450         alignment.  The stack's ReservedZone will ensure that we have enough stack space
451         for this.  ScratchRegisterAllocator::restoreReusedRegistersByPopping() also
452         needs to be updated to perform the complement of this behavior.
453
454         * jit/Repatch.cpp:
455         (JSC::emitPutReplaceStub):
456         (JSC::emitPutTransitionStub):
457         * jit/ScratchRegisterAllocator.cpp:
458         (JSC::ScratchRegisterAllocator::allocateScratchGPR):
459         (JSC::ScratchRegisterAllocator::allocateScratchFPR):
460         (JSC::ScratchRegisterAllocator::preserveReusedRegistersByPushing):
461         (JSC::ScratchRegisterAllocator::restoreReusedRegistersByPopping):
462         * jit/ScratchRegisterAllocator.h:
463         (JSC::ScratchRegisterAllocator::numberOfReusedRegisters):
464         * tests/stress/regress-148564.js: Added.
465         (test):
466         (runTest):
467
468 2015-08-28  Csaba Osztrogon√°c  <ossy@webkit.org>
469
470         Unreviewed Windows buildfix.
471
472         Revert part of r189072 since the original change was rolled out by r189085.
473
474         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
475         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
476
477 2015-08-28  Csaba Osztrogon√°c  <ossy@webkit.org>
478
479         Unreviewed Windows buildfix.
480
481         Revert r189077 since the original change was rolled out by r189085.
482
483         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
484         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
485
486 2015-08-27  Yusuke Suzuki  <utatane.tea@gmail.com>
487
488         [ES6] Implement Module execution and Loader's ready / link phase
489         https://bugs.webkit.org/show_bug.cgi?id=148172
490
491         Reviewed by Saam Barati.
492
493         This patch adds the link / ready phases to the existing module loader.
494         They are just the stubs and the actual implementations will be
495         forthcoming in the subsequnt patch.
496
497         And this patch paves the way to instantiate the module environment and
498         compile the executable code in the link phase. Move declaredVariables /
499         lexicalVariables from ModuleAnalyzer to JSModuleRecord to use them when
500         instantiating the module environment. Hold the source code in
501         JSModuleRecord to construct the executable in the link phase. And to
502         use HostResolveImportedModule operation from the C++ side, we expose
503         the JSMap from C++ to JS and use it in the builtin JS module loader
504         code.
505
506         * builtins/ModuleLoaderObject.js:
507         (requestResolveDependencies.resolveDependenciesPromise.this.requestInstantiate.then.):
508         (requestLink):
509         (requestReady):
510         (link):
511         (moduleEvaluation):
512         (loadModule):
513         * parser/ModuleAnalyzer.cpp:
514         (JSC::ModuleAnalyzer::ModuleAnalyzer):
515         (JSC::ModuleAnalyzer::analyze):
516         * parser/ModuleAnalyzer.h:
517         * runtime/Completion.cpp:
518         (JSC::checkModuleSyntax):
519         * runtime/JSModuleRecord.cpp:
520         (JSC::JSModuleRecord::finishCreation):
521         (JSC::JSModuleRecord::visitChildren):
522         (JSC::identifierToJSValue):
523         (JSC::JSModuleRecord::hostResolveImportedModule):
524         (JSC::JSModuleRecord::link):
525         (JSC::JSModuleRecord::execute):
526         * runtime/JSModuleRecord.h:
527         (JSC::JSModuleRecord::create):
528         (JSC::JSModuleRecord::sourceCode):
529         (JSC::JSModuleRecord::moduleKey):
530         (JSC::JSModuleRecord::exportEntries):
531         (JSC::JSModuleRecord::importEntries):
532         (JSC::JSModuleRecord::declaredVariables):
533         (JSC::JSModuleRecord::lexicalVariables):
534         (JSC::JSModuleRecord::JSModuleRecord):
535         * runtime/ModuleLoaderObject.cpp:
536         (JSC::moduleLoaderObjectParseModule):
537         (JSC::moduleLoaderObjectRequestedModules):
538         (JSC::moduleLoaderObjectModuleDeclarationInstantiation):
539         (JSC::moduleLoaderObjectEvaluate):
540         (JSC::ModuleLoaderObject::requestInstantiateAll): Deleted.
541         * runtime/ModuleLoaderObject.h:
542
543 2015-08-27  Mark Lam  <mark.lam@apple.com>
544
545         Add noDFG() to jsc to prevent DFG compilation of a specified function.
546         https://bugs.webkit.org/show_bug.cgi?id=148559
547
548         Reviewed by Geoffrey Garen and Saam Barati.
549
550         * API/JSCTestRunnerUtils.cpp:
551         (JSC::setNeverInline):
552         (JSC::setNeverOptimize):
553         * API/JSCTestRunnerUtils.h:
554         * bytecode/CodeBlock.cpp:
555         (JSC::CodeBlock::dumpAssumingJITType):
556         * dfg/DFGCapabilities.cpp:
557         (JSC::DFG::mightCompileEval):
558         (JSC::DFG::mightCompileProgram):
559         (JSC::DFG::mightCompileFunctionForCall):
560         (JSC::DFG::mightCompileFunctionForConstruct):
561         (JSC::DFG::mightInlineFunctionForCall):
562         * jsc.cpp:
563         (GlobalObject::finishCreation):
564         (functionNoDFG):
565         * runtime/Executable.h:
566         (JSC::ScriptExecutable::ecmaMode):
567         (JSC::ScriptExecutable::setNeverInline):
568         (JSC::ScriptExecutable::setNeverOptimize):
569         (JSC::ScriptExecutable::setDidTryToEnterInLoop):
570         (JSC::ScriptExecutable::neverInline):
571         (JSC::ScriptExecutable::neverOptimize):
572         (JSC::ScriptExecutable::didTryToEnterInLoop):
573         (JSC::ScriptExecutable::isInliningCandidate):
574         (JSC::ScriptExecutable::isOkToOptimize):
575         (JSC::ScriptExecutable::addressOfDidTryToEnterInLoop):
576         * runtime/TestRunnerUtils.cpp:
577         (JSC::setNeverInline):
578         (JSC::setNeverOptimize):
579         (JSC::optimizeNextInvocation):
580         * runtime/TestRunnerUtils.h:
581
582 2015-08-27  Commit Queue  <commit-queue@webkit.org>
583
584         Unreviewed, rolling out r189064 and r189084.
585         https://bugs.webkit.org/show_bug.cgi?id=148560
586
587         Breaks 117 JSC tests. (Requested by mlam on #webkit).
588
589         Reverted changesets:
590
591         "[ES6] Add TypedArray.prototype functionality."
592         https://bugs.webkit.org/show_bug.cgi?id=148035
593         http://trac.webkit.org/changeset/189064
594
595         "Unbreak JSC tests (broken since r189064)."
596         http://trac.webkit.org/changeset/189084
597
598 2015-08-27  Commit Queue  <commit-queue@webkit.org>
599
600         Unreviewed, rolling out r189079.
601         https://bugs.webkit.org/show_bug.cgi?id=148555
602
603         broke the build (Requested by jessieberlin on #webkit).
604
605         Reverted changeset:
606
607         "Create WebAssembly functions"
608         https://bugs.webkit.org/show_bug.cgi?id=148373
609         http://trac.webkit.org/changeset/189079
610
611 2015-08-27  Sukolsak Sakshuwong  <sukolsak@gmail.com>
612
613         Create WebAssembly functions
614         https://bugs.webkit.org/show_bug.cgi?id=148373
615
616         Reviewed by Geoffrey Garen.
617
618         Create functions from WebAssembly files generated by pack-asmjs
619         <https://github.com/WebAssembly/polyfill-prototype-1>.
620         WebAssembly functions created by this patch can only return 0.
621         Actual code generation will be implemented in subsequent patches.
622
623         * bytecode/CodeBlock.cpp:
624         (JSC::CodeBlock::hash):
625         (JSC::CodeBlock::sourceCodeForTools):
626         (JSC::CodeBlock::dumpAssumingJITType):
627         (JSC::CodeBlock::dumpSource):
628         (JSC::CodeBlock::CodeBlock):
629         (JSC::CodeBlock::finalizeUnconditionally):
630         (JSC::CodeBlock::lineNumberForBytecodeOffset):
631         (JSC::CodeBlock::expressionRangeForBytecodeOffset):
632         (JSC::CodeBlock::install):
633         (JSC::CodeBlock::newReplacement):
634         (JSC::WebAssemblyCodeBlock::replacement):
635         (JSC::WebAssemblyCodeBlock::capabilityLevelInternal):
636         (JSC::CodeBlock::updateAllPredictions):
637         (JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
638         * bytecode/CodeBlock.h:
639         (JSC::CodeBlock::ownerExecutable):
640         (JSC::CodeBlock::ownerScriptExecutable):
641         (JSC::CodeBlock::codeType):
642         (JSC::WebAssemblyCodeBlock::WebAssemblyCodeBlock):
643         * debugger/Debugger.cpp:
644         (JSC::Debugger::toggleBreakpoint):
645         * debugger/DebuggerCallFrame.cpp:
646         (JSC::DebuggerCallFrame::sourceIDForCallFrame):
647         * dfg/DFGByteCodeParser.cpp:
648         (JSC::DFG::ByteCodeParser::InlineStackEntry::executable):
649         (JSC::DFG::ByteCodeParser::inliningCost):
650         (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
651         (JSC::DFG::ByteCodeParser::parseCodeBlock):
652         * dfg/DFGCapabilities.cpp:
653         (JSC::DFG::isSupportedForInlining):
654         * dfg/DFGGraph.h:
655         (JSC::DFG::Graph::executableFor):
656         * dfg/DFGOSREntry.cpp:
657         (JSC::DFG::prepareOSREntry):
658         * inspector/ScriptCallStackFactory.cpp:
659         (Inspector::CreateScriptCallStackFunctor::operator()):
660         * interpreter/Interpreter.cpp:
661         (JSC::eval):
662         (JSC::isWebAssemblyExecutable):
663         (JSC::GetStackTraceFunctor::operator()):
664         (JSC::UnwindFunctor::operator()):
665         * interpreter/StackVisitor.cpp:
666         (JSC::StackVisitor::Frame::sourceURL):
667         (JSC::StackVisitor::Frame::computeLineAndColumn):
668         * jit/JITOperations.cpp:
669         * jit/Repatch.cpp:
670         (JSC::isWebAssemblyExecutable):
671         (JSC::linkPolymorphicCall):
672         * llint/LLIntData.cpp:
673         (JSC::LLInt::Data::performAssertions):
674         * llint/LLIntSlowPaths.cpp:
675         (JSC::LLInt::setUpCall):
676         * llint/LowLevelInterpreter.asm:
677         * runtime/CommonSlowPaths.cpp:
678         (JSC::SLOW_PATH_DECL):
679         * runtime/Executable.cpp:
680         (JSC::WebAssemblyExecutable::WebAssemblyExecutable):
681         (JSC::WebAssemblyExecutable::destroy):
682         (JSC::WebAssemblyExecutable::visitChildren):
683         (JSC::WebAssemblyExecutable::clearCode):
684         (JSC::WebAssemblyExecutable::prepareForExecution):
685         * runtime/Executable.h:
686         (JSC::ExecutableBase::isEvalExecutable):
687         (JSC::ExecutableBase::isFunctionExecutable):
688         (JSC::ExecutableBase::isProgramExecutable):
689         (JSC::ExecutableBase::isWebAssemblyExecutable):
690         (JSC::ExecutableBase::clearCodeVirtual):
691         * runtime/JSFunction.cpp:
692         (JSC::JSFunction::create):
693         * runtime/JSFunction.h:
694         * runtime/JSFunctionInlines.h:
695         (JSC::JSFunction::JSFunction):
696         (JSC::JSFunction::isBuiltinFunction):
697         * runtime/JSType.h:
698         * runtime/VM.cpp:
699         (JSC::VM::VM):
700         * runtime/VM.h:
701         * wasm/JSWASMModule.h:
702         (JSC::JSWASMModule::functions):
703         * wasm/WASMFunctionParser.cpp:
704         (JSC::WASMFunctionParser::compile):
705         * wasm/WASMFunctionParser.h:
706         * wasm/WASMModuleParser.cpp:
707         (JSC::WASMModuleParser::WASMModuleParser):
708         (JSC::WASMModuleParser::parse):
709         (JSC::WASMModuleParser::parseFunctionDeclarationSection):
710         (JSC::WASMModuleParser::parseFunctionDefinition):
711         (JSC::WASMModuleParser::parseExportSection):
712         (JSC::parseWebAssembly):
713         * wasm/WASMModuleParser.h:
714
715 2015-08-27  Brent Fulgham  <bfulgham@apple.com>
716
717         [Win] Unreviewed build fix after r189064.
718
719         JSTypedArrayViewPrototypes.{h,cpp} -> JSTypedArrayViewPrototype.{h,cpp}
720
721         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
722         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
723
724 2015-08-27  Alex Christensen  <achristensen@webkit.org>
725
726         Make DLLLauncherMain executables dependent on dll
727         https://bugs.webkit.org/show_bug.cgi?id=148548
728
729         Reviewed by Brent Fulgham.
730
731         * shell/CMakeLists.txt:
732         * shell/PlatformWin.cmake:
733
734 2015-08-27  Filip Pizlo  <fpizlo@apple.com>
735
736         DFG::StrCat isn't really effectful
737         https://bugs.webkit.org/show_bug.cgi?id=148443
738
739         Reviewed by Geoffrey Garen.
740
741         I previously made the DFG StrCat node effectful because it is implemented by calling a
742         DFGOperations function that could cause arbitrary effects. But, the node is only generated from the
743         op_strcat bytecode operation, and that operation is only used when we first ensure that its
744         operands are primitives. Primitive operands to StrCat cannot cause arbitrary side-effects. The
745         reason why I didn't immediately mark StrCat as pure was because there was nothing in DFG IR that
746         guaranteed that StrCat's children were primitives.
747
748         This change adds a KnownPrimitiveUse use kind, and applies it to StrCat. This allows us to mark
749         StrCat as being pure. This should be a speed-up because we can CSE StrCat and because it means that
750         we can OSR exit after a StrCat (a pure node doesn't clobber exit state), so we can convert more
751         of a large string concatenation into MakeRope's.
752
753         * dfg/DFGAbstractInterpreterInlines.h:
754         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
755         * dfg/DFGClobberize.h:
756         (JSC::DFG::clobberize):
757         * dfg/DFGFixupPhase.cpp:
758         (JSC::DFG::FixupPhase::fixupNode):
759         (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
760         * dfg/DFGOperations.cpp:
761         * dfg/DFGSafeToExecute.h:
762         (JSC::DFG::SafeToExecuteEdge::operator()):
763         * dfg/DFGSpeculativeJIT.cpp:
764         (JSC::DFG::SpeculativeJIT::speculate):
765         * dfg/DFGSpeculativeJIT32_64.cpp:
766         (JSC::DFG::SpeculativeJIT::compile):
767         * dfg/DFGSpeculativeJIT64.cpp:
768         (JSC::DFG::SpeculativeJIT::compile):
769         * dfg/DFGUseKind.cpp:
770         (WTF::printInternal):
771         * dfg/DFGUseKind.h:
772         (JSC::DFG::typeFilterFor):
773         (JSC::DFG::shouldNotHaveTypeCheck):
774         * ftl/FTLCapabilities.cpp:
775         (JSC::FTL::canCompile):
776         * ftl/FTLLowerDFGToLLVM.cpp:
777         (JSC::FTL::DFG::LowerDFGToLLVM::compileStrCat):
778         (JSC::FTL::DFG::LowerDFGToLLVM::speculate):
779
780 2015-08-27  Brent Fulgham  <bfulgham@apple.com>
781
782         [Win] Unreviewed build fix after r189064.
783
784         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
785         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
786
787 2015-08-27  Yusuke Suzuki  <utatane.tea@gmail.com>
788
789         Add module loader "resolve" hook for local file system to test the loader in JSC shell
790         https://bugs.webkit.org/show_bug.cgi?id=148543
791
792         Reviewed by Filip Pizlo.
793
794         Add the module loader "resolve" hook to the JSC shell.
795         It takes the module name and the referrer module key and resolves the name to the unique module key.
796
797         resolve(ModuleName moduleName, ModuleKey referrer) -> Promise<ModuleKey>
798
799         In the JSC shell, since we load the module from the local file system, we treat an absolute file path
800         as a module key. So, in this patch, we implement the "resolve" hook that resolves the module name to
801         the absolute file path.
802
803         This local file system "resolve" functionality makes JSC shell easy to test the module loader.
804
805         * jsc.cpp:
806         (GlobalObject::finishCreation):
807         (GlobalObject::moduleLoaderFetch):
808         (pathSeparator):
809         (extractDirectoryName):
810         (currentWorkingDirectory):
811         (resolvePath):
812         (GlobalObject::moduleLoaderResolve):
813         (functionDrainMicrotasks):
814         * runtime/JSInternalPromiseDeferred.cpp:
815         (JSC::JSInternalPromiseDeferred::resolve):
816         (JSC::JSInternalPromiseDeferred::reject):
817         * runtime/JSInternalPromiseDeferred.h:
818         * tests/stress/pathname-resolve.js: Added.
819         (shouldBe):
820         (shouldThrow):
821
822 2015-08-27  Filip Pizlo  <fpizlo@apple.com>
823
824         Unreviewed, fix some FIXMEs and add some new ones, based on things we've learned from some
825         recent OSR exit work.
826
827         * dfg/DFGLICMPhase.cpp:
828         (JSC::DFG::LICMPhase::run):
829         (JSC::DFG::LICMPhase::attemptHoist):
830         * dfg/DFGMayExit.cpp:
831         * dfg/DFGMayExit.h:
832
833 2015-08-27  Keith Miller  <keith_miller@apple.com>
834
835         [ES6] Add TypedArray.prototype functionality.
836         https://bugs.webkit.org/show_bug.cgi?id=148035
837
838         Reviewed by Geoffrey Garen.
839
840         This patch should add most of the functionality for
841         the prototype properties of TypedArray objects in ES6.
842         There are a few exceptions to this, which will be added
843         in upcoming patches:
844
845         1) First we do not use the species constructor for some
846         of the TypedArray prototype functions (namely: map, filter,
847         slice, and subarray). That will need to be added when
848         species constructors are finished.
849
850         2) TypedArrays still have a length, byteOffset, byteLength,
851         and buffer are still attached to the TypedArray instance (in
852         the spec they are on the TypedArray.prototype instance object)
853         since the JIT currently assumes those properties are fixed.
854
855         3) The TypedArray.constructor property is not added yet
856         as it should point to the TypedArray instance object,
857         which will be added in a future patch.
858
859         * CMakeLists.txt:
860         * JavaScriptCore.xcodeproj/project.pbxproj:
861         * builtins/TypedArray.prototype.js: Added.
862         (every):
863         (find):
864         (findIndex):
865         (forEach):
866         (some):
867         (sort.min):
868         (sort.merge):
869         (sort.mergeSort):
870         (sort):
871         (reduce):
872         (reduceRight):
873         (map):
874         (filter):
875         (toLocaleString):
876         * runtime/ArrayPrototype.cpp:
877         * runtime/ArrayPrototype.h:
878         * runtime/CommonIdentifiers.h:
879         * runtime/JSGenericTypedArrayView.h:
880         (JSC::sortFloat):
881         (JSC::JSGenericTypedArrayView::toAdaptorNativeFromValue):
882         (JSC::JSGenericTypedArrayView::setRangeToValue):
883         (JSC::JSGenericTypedArrayView::sort):
884         * runtime/JSGenericTypedArrayViewInlines.h:
885         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h: Added.
886         (JSC::argumentClampedIndexFromStartOrEnd):
887         (JSC::genericTypedArrayViewProtoFuncSet):
888         (JSC::genericTypedArrayViewProtoFuncEntries):
889         (JSC::genericTypedArrayViewProtoFuncCopyWithin):
890         (JSC::genericTypedArrayViewProtoFuncFill):
891         (JSC::genericTypedArrayViewProtoFuncIndexOf):
892         (JSC::genericTypedArrayViewProtoFuncJoin):
893         (JSC::genericTypedArrayViewProtoFuncKeys):
894         (JSC::genericTypedArrayViewProtoFuncLastIndexOf):
895         (JSC::genericTypedArrayViewProtoGetterFuncLength):
896         (JSC::genericTypedArrayViewProtoGetterFuncByteLength):
897         (JSC::genericTypedArrayViewProtoGetterFuncByteOffset):
898         (JSC::genericTypedArrayViewProtoFuncReverse):
899         (JSC::genericTypedArrayViewPrivateFuncSort):
900         (JSC::genericTypedArrayViewProtoFuncSlice):
901         (JSC::genericTypedArrayViewProtoFuncSubarray):
902         (JSC::typedArrayViewProtoFuncValues):
903         * runtime/JSGenericTypedArrayViewPrototypeInlines.h:
904         (JSC::JSGenericTypedArrayViewPrototype<ViewClass>::finishCreation):
905         (JSC::genericTypedArrayViewProtoFuncSet): Deleted.
906         (JSC::genericTypedArrayViewProtoFuncSubarray): Deleted.
907         * runtime/JSGlobalObject.cpp:
908         (JSC::JSGlobalObject::init):
909         * runtime/JSObject.h:
910         * runtime/JSTypedArrayPrototypes.cpp:
911         * runtime/JSTypedArrayPrototypes.h:
912         * runtime/JSTypedArrayViewPrototype.cpp: Added.
913         (JSC::typedArrayViewPrivateFuncLength):
914         (JSC::typedArrayViewPrivateFuncSort):
915         (JSC::typedArrayViewProtoFuncSet):
916         (JSC::typedArrayViewProtoFuncEntries):
917         (JSC::typedArrayViewProtoFuncCopyWithin):
918         (JSC::typedArrayViewProtoFuncFill):
919         (JSC::typedArrayViewProtoFuncLastIndexOf):
920         (JSC::typedArrayViewProtoFuncIndexOf):
921         (JSC::typedArrayViewProtoFuncJoin):
922         (JSC::typedArrayViewProtoFuncKeys):
923         (JSC::typedArrayViewProtoGetterFuncLength):
924         (JSC::typedArrayViewProtoGetterFuncByteLength):
925         (JSC::typedArrayViewProtoGetterFuncByteOffset):
926         (JSC::typedArrayViewProtoFuncReverse):
927         (JSC::typedArrayViewProtoFuncSubarray):
928         (JSC::typedArrayViewProtoFuncSlice):
929         (JSC::typedArrayViewProtoFuncValues):
930         (JSC::JSTypedArrayViewPrototype::JSTypedArrayViewPrototype):
931         (JSC::JSTypedArrayViewPrototype::finishCreation):
932         (JSC::JSTypedArrayViewPrototype::create):
933         (JSC::JSTypedArrayViewPrototype::createStructure):
934         * runtime/JSTypedArrayViewPrototype.h: Copied from Source/JavaScriptCore/runtime/JSTypedArrayPrototypes.cpp.
935
936 2015-08-27  Alex Christensen  <achristensen@webkit.org>
937
938         Isolate Source directories in CMake build
939         https://bugs.webkit.org/show_bug.cgi?id=148389
940
941         Reviewed by Brent Fulgham.
942
943         * PlatformWin.cmake:
944         Include ../include/private to find WTF headers in internal build.
945         Don't use a script to generate forwarding headers.
946         * shell/PlatformWin.cmake:
947         Copy inspector scripts to the forwarding headers directory to be used by WebCore.
948
949 2015-08-27  Alex Christensen  <achristensen@webkit.org>
950
951         [Win CMake] Fix incremental build after r188673
952         https://bugs.webkit.org/show_bug.cgi?id=148539
953
954         Reviewed by Brent Fulgham.
955
956         * PlatformWin.cmake:
957         Use xcopy as a build step instead of file(COPY ...) to copy updated headers.
958
959 2015-08-27  Jon Davis  <jond@apple.com>
960
961         Include ES6 Generators and Proxy object status to feature status page.
962         https://bugs.webkit.org/show_bug.cgi?id=148095
963
964         Reviewed by Timothy Hatcher.
965
966         * features.json:
967
968 2015-08-27  Filip Pizlo  <fpizlo@apple.com>
969
970         Unreviewed, add a comment to describe something I learned about a confusingly-named function.
971
972         * dfg/DFGUseKind.h:
973         (JSC::DFG::isCell):
974
975 2015-08-27  Basile Clement  <basile_clement@apple.com>
976
977         REGRESSION(r184779): Possible read-after-free in JavaScriptCore/dfg/DFGClobberize.h
978         https://bugs.webkit.org/show_bug.cgi?id=148411
979
980         Reviewed by Geoffrey Garen and Filip Pizlo.
981
982         * dfg/DFGClobberize.h:
983         (JSC::DFG::clobberize):
984
985 2015-08-27  Brian Burg  <bburg@apple.com>
986
987         Web Inspector: FrontendChannel should know its own connection type
988         https://bugs.webkit.org/show_bug.cgi?id=148482
989
990         Reviewed by Joseph Pecoraro.
991
992         * inspector/InspectorFrontendChannel.h: Add connectionType().
993         * inspector/remote/RemoteInspectorDebuggableConnection.h:
994
995 2015-08-26  Filip Pizlo  <fpizlo@apple.com>
996
997         Node::origin should always be set, and the dead zone due to SSA Phis can just use exitOK=false
998         https://bugs.webkit.org/show_bug.cgi?id=148462
999
1000         Reviewed by Saam Barati.
1001
1002         The need to label nodes that absolutely cannot exit was first observed when we introduced SSA form.
1003         We indicated this by not setting the CodeOrigin.
1004
1005         But just recently (http://trac.webkit.org/changeset/188979), we added a more comprehensive "exitOK"
1006         bit in NodeOrigin. After that change, there were two ways of indicating that you cannot exit:
1007         !exitOK and an unset NodeOrigin. An unset NodeOrigin implied !exitOK.
1008
1009         Now, this change is about removing the old way so that we only use !exitOK. From now on, all nodes
1010         must have their NodeOrigin set, and the IR validation will check this. This means that I could
1011         remove various pieces of cruft for dealing with unset NodeOrigins, but I did have to add some new
1012         cruft to ensure that all nodes we create have a NodeOrigin.
1013
1014         This change simplifies our IR by having a simpler rule about when NodeOrigin is set: it's always
1015         set.
1016
1017         * dfg/DFGBasicBlock.cpp:
1018         (JSC::DFG::BasicBlock::isInBlock):
1019         (JSC::DFG::BasicBlock::removePredecessor):
1020         (JSC::DFG::BasicBlock::firstOriginNode): Deleted.
1021         (JSC::DFG::BasicBlock::firstOrigin): Deleted.
1022         * dfg/DFGBasicBlock.h:
1023         (JSC::DFG::BasicBlock::begin):
1024         (JSC::DFG::BasicBlock::end):
1025         (JSC::DFG::BasicBlock::numSuccessors):
1026         (JSC::DFG::BasicBlock::successor):
1027         * dfg/DFGCombinedLiveness.cpp:
1028         (JSC::DFG::liveNodesAtHead):
1029         * dfg/DFGConstantHoistingPhase.cpp:
1030         * dfg/DFGCriticalEdgeBreakingPhase.cpp:
1031         (JSC::DFG::CriticalEdgeBreakingPhase::breakCriticalEdge):
1032         * dfg/DFGForAllKills.h:
1033         (JSC::DFG::forAllKilledOperands):
1034         * dfg/DFGIntegerRangeOptimizationPhase.cpp:
1035         * dfg/DFGLoopPreHeaderCreationPhase.cpp:
1036         (JSC::DFG::createPreHeader):
1037         (JSC::DFG::LoopPreHeaderCreationPhase::run):
1038         * dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
1039         (JSC::DFG::OSRAvailabilityAnalysisPhase::run):
1040         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1041         * dfg/DFGPutStackSinkingPhase.cpp:
1042         * dfg/DFGSSAConversionPhase.cpp:
1043         (JSC::DFG::SSAConversionPhase::run):
1044         * dfg/DFGValidate.cpp:
1045         (JSC::DFG::Validate::validate):
1046         (JSC::DFG::Validate::validateSSA):
1047
1048 2015-08-26  Saam barati  <sbarati@apple.com>
1049
1050         MarkedBlock::allocateBlock will have the wrong allocation size when (sizeof(MarkedBlock) + bytes) is divisible by WTF::pageSize()
1051         https://bugs.webkit.org/show_bug.cgi?id=148500
1052
1053         Reviewed by Mark Lam.
1054
1055         Consider the following scenario:
1056         - On OS X, WTF::pageSize() is 4*1024 bytes.
1057         - JSEnvironmentRecord::allocationSizeForScopeSize(6621) == 53000
1058         - sizeof(MarkedBlock) == 248
1059         - (248 + 53000) is a multiple of 4*1024.
1060         - (248 + 53000)/(4*1024) == 13
1061
1062         We will allocate a chunk of memory of size 53248 bytes that looks like this:
1063         0            248       256                       53248       53256
1064         [Marked Block | 8 bytes |  payload     ......      ]  8 bytes  |
1065                                 ^                                      ^
1066                            Our Environment record starts here.         ^
1067                                                                        ^
1068                                                                  Our last JSValue in the environment record will go from byte 53248 to 53256. But, we don't own this memory.
1069
1070         We need to ensure that we round up sizeof(MarkedBlock) to an
1071         atomSize boundary. We need to do this because the first atom
1072         inside the MarkedBlock will start at the rounded up multiple
1073         of atomSize past MarkedBlock. If we end up with an allocation
1074         that is perfectly aligned to the page size, then we will be short
1075         8 bytes (in the current implementation where atomSize is 16 bytes,
1076         and MarkedBlock is 248 bytes).
1077
1078         * heap/MarkedAllocator.cpp:
1079         (JSC::MarkedAllocator::allocateBlock):
1080         * tests/stress/heap-allocator-allocates-incorrect-size-for-activation.js: Added.
1081         (use):
1082         (makeFunction):
1083
1084 2015-08-26  Mark Lam  <mark.lam@apple.com>
1085
1086         watchdog m_didFire state erroneously retained.
1087         https://bugs.webkit.org/show_bug.cgi?id=131082
1088
1089         Reviewed by Geoffrey Garen.
1090
1091         The watchdog can fire for 2 reasons:
1092         1. an external controlling entity (i.e. another thread) has scheduled termination
1093            of the script thread via watchdog::terminateSoon().
1094         2. the allowed CPU time has expired.
1095
1096         For case 1, we're doing away with the m_didFire flag.  Watchdog::terminateSoon() 
1097         will set the timer deadlines and m_timeLimit to 0, and m_timerDidFire to true.
1098         This will get the script thread to check Watchdog::didFire() and terminate
1099         execution.
1100
1101         Note: the watchdog only guarantees that script execution will terminate as soon
1102         as possible due to a time limit of 0.  Once we've exited the VM, the client of the
1103         VM is responsible from keeping a flag to prevent new script execution.
1104
1105         In a race condition, if terminateSoon() is called just after execution has gotten
1106         past the client's reentry check and the client is in the process of re-entering,
1107         the worst that can happen is that we will schedule the watchdog timer to fire
1108         after a period of 0.  This will terminate script execution quickly, and thereafter
1109         the client's check should be able to prevent further entry into the VM.
1110
1111         The correctness (i.e. has no race condition) of this type of termination relies
1112         on the termination state being sticky.  Once the script thread is terminated this
1113         way, the VM will continue to terminate scripts quickly until the client sets the
1114         time limit to a non-zero value (or clears it which sets the time limit to
1115         noTimeLimit).
1116
1117         For case 2, the watchdog does not alter m_timeLimit.  If the CPU deadline has
1118         been reached, the script thread will terminate execution and exit the VM.
1119
1120         If the client of the VM starts new script execution, the watchdog will allow
1121         execution for the specified m_timeLimit.  In this case, since m_timeLimit is not
1122         0, the script gets a fresh allowance of CPU time to execute.  Hence, terminations
1123         due to watchdog time outs are no longer sticky.
1124
1125         * API/JSContextRef.cpp:
1126         (JSContextGroupSetExecutionTimeLimit):
1127         (JSContextGroupClearExecutionTimeLimit):
1128         * API/tests/ExecutionTimeLimitTest.cpp:
1129         - Add test scenarios to verify that the watchdog is automatically reset by the VM
1130           upon throwing the TerminatedExecutionException.
1131
1132         (testResetAfterTimeout):
1133         (testExecutionTimeLimit):
1134         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1135         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1136         * JavaScriptCore.xcodeproj/project.pbxproj:
1137         * dfg/DFGByteCodeParser.cpp:
1138         (JSC::DFG::ByteCodeParser::parseBlock):
1139         * interpreter/Interpreter.cpp:
1140         (JSC::Interpreter::execute):
1141         (JSC::Interpreter::executeCall):
1142         (JSC::Interpreter::executeConstruct):
1143         * jit/JITOpcodes.cpp:
1144         (JSC::JIT::emit_op_loop_hint):
1145         (JSC::JIT::emitSlow_op_loop_hint):
1146         * jit/JITOperations.cpp:
1147         * llint/LLIntSlowPaths.cpp:
1148         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1149         * runtime/VM.cpp:
1150         (JSC::VM::VM):
1151         (JSC::VM::ensureWatchdog):
1152         * runtime/VM.h:
1153         * runtime/VMInlines.h: Added.
1154         (JSC::VM::shouldTriggerTermination):
1155         * runtime/Watchdog.cpp:
1156         (JSC::Watchdog::Watchdog):
1157         (JSC::Watchdog::setTimeLimit):
1158         (JSC::Watchdog::terminateSoon):
1159         (JSC::Watchdog::didFireSlow):
1160         (JSC::Watchdog::hasTimeLimit):
1161         (JSC::Watchdog::enteredVM):
1162         (JSC::Watchdog::exitedVM):
1163         (JSC::Watchdog::startTimer):
1164         (JSC::Watchdog::stopTimer):
1165         (JSC::Watchdog::hasStartedTimer): Deleted.
1166         (JSC::Watchdog::fire): Deleted.
1167         * runtime/Watchdog.h:
1168         (JSC::Watchdog::didFire):
1169         (JSC::Watchdog::timerDidFireAddress):
1170
1171 2015-08-26  Joseph Pecoraro  <pecoraro@apple.com>
1172
1173         Web Inspector: Implement tracking of active stylesheets in the frontend
1174         https://bugs.webkit.org/show_bug.cgi?id=105828
1175
1176         Reviewed by Timothy Hatcher.
1177
1178         * inspector/protocol/CSS.json:
1179         Add new events for when a StyleSheet is added or removed.
1180
1181 2015-08-26  Chris Dumez  <cdumez@apple.com>
1182
1183         Distinguish Web IDL callback interfaces from Web IDL callback functions
1184         https://bugs.webkit.org/show_bug.cgi?id=148434
1185
1186         Reviewed by Geoffrey Garen.
1187
1188         Add isNull() convenience method on PropertyName.
1189
1190         * runtime/PropertyName.h:
1191         (JSC::PropertyName::isNull):
1192
1193 2015-08-26  Filip Pizlo  <fpizlo@apple.com>
1194
1195         Node::origin should be able to tell you if it's OK to exit
1196         https://bugs.webkit.org/show_bug.cgi?id=145204
1197
1198         Reviewed by Geoffrey Garen.
1199
1200         This is a major change to DFG IR, that makes it easier to reason about where nodes with
1201         speculations can be soundly hoisted.
1202
1203         A program in DFG IR is a sequence of operations that compute the values of SSA variables,
1204         perform effects on the heap or stack, and perform updates to the OSR exit state. Because
1205         effects and OSR exit updates are interleaved, there are points in execution where exiting
1206         simply won't work. For example, we may have some bytecode operation:
1207
1208             [  24] op_foo loc42 // does something, and puts a value in loc42.
1209
1210         that gets compiled down to a sequence of DFG IR nodes like:
1211
1212             a: Foo(W:Heap, R:World, bc#24) // writes heap, reads world - i.e. an observable effect.
1213             b: MovHint(@a, loc42, bc#24)
1214             c: SetLocal(Check:Int32:@a, loc42, bc#24, exit: bc#26)
1215
1216         Note that we can OSR exit at @a because we haven't yet performed any effects for bc#24 yet and
1217         we have performed all effects for prior bytecode operations. That's what the origin.forExit
1218         being set to "bc#24" guarantees. So, an OSR exit at @a would transfer execution to bc#24 and
1219         this would not be observable. But at @b, if we try to exit to bc#24 as indicated by forExit, we
1220         would end up causing the side effect of bc#24 to execute a second time. This would be
1221         observable, so we cannot do it. And we cannot exit to the next instruction - bc#26 - either,
1222         because @b is responsible for updating the OSR state to indicate that the result of @a should
1223         be put into loc42. It's not until we get to @c that we can exit again.
1224
1225         This is a confusing, but useful, property of DFG IR. It's useful because it allows us to use IR
1226         to spell out how we would have affected the bytecode state, and we use this to implement hard
1227         things like object allocation elimination, where we use IR instructions to indicate what object
1228         allocation and mutation operations we would have performed, and which bytecode variables would
1229         have pointed to those objects. So long as IR allows us to describe how OSR exit state is
1230         updated, there will be points in execution where that state is invalid - especially if the IR
1231         to update exit state is separate from the IR to perform actual effects.
1232
1233         But this property is super confusing! It's difficult to explain that somehow magically, @b is a
1234         bad place to put OSR exits, and that magically we will only have OSR exits at @a. Of course, it
1235         all kind of makes sense - we insert OSR exit checks in phases that *know* where it's safe to
1236         exit - but it's just too opaque. This also gets in the way of more sophisticated
1237         transformations. For example, LICM barely works - it magically knows that loop pre-headers are
1238         good places to exit from, but it has no way of determining if that is actually true. It would
1239         be odd to introduce a restriction that anytime some block qualifies as a pre-header according
1240         to our loop calculator, it must end with a terminal at which it is OK to exit. So, our choices
1241         are to either leave LICM in a magical state and exercise extreme caution when introducing new
1242         optimizations that hoist checks, or to do something to make the "can I exit here" property more
1243         explicit in IR.
1244
1245         We have already, in a separate change, added a NodeOrigin::exitOK property, though it didn't do
1246         anything yet. This change puts exitOK to work, and makes it an integral part of IR. The key
1247         intuition behind this change is that if we know which nodes clobber exit state - i.e. after the
1248         node, it's no longer possible to OSR exit until the exit state is fixed up - then we can figure
1249         out where it's fine to exit. This change mostly adopts the already implicit rule that it's
1250         always safe to exit right at the boundary of exit origins (in between two nodes where
1251         origin.forExit differs), and adds a new node, called ExitOK, which is a kind of declaration
1252         that exit state is good again. When making this change, I struggled with the question of
1253         whether to make origin.exitOK be explicit, or something that we can compute with an analysis.
1254         Of course if we are armed with a clobbersExitState(Node*) function, we can find the places
1255         where it's fine to exit. But this kind of computation could get quite sophisticated if the
1256         nodes belonging to an exit origin are lowered to a control-flow construct. It would also be
1257         harder to see what the original intent was, if we found an error: is the bug that we shouldn't
1258         be clobbering exit state, or that we shouldn't be exiting? This change opts to make exitOK be
1259         an explicit property of IR, so that DFG IR validation will reject any program where exitOK is
1260         true after a node that clobbersExitState(), or if exitOK is true after a node has exitOK set to
1261         false - unless the latter node has a different exit origin or is an ExitOK node. It will also
1262         reject any program where a node mayExit() with !exitOK.
1263
1264         It turns out that this revealed a lot of sloppiness and what almost looked like an outright
1265         bug: the callee property of an inline closure call frame was being set up "as if" by the
1266         callee's op_enter. If we did hoist a check per the old rule - to the boundary of exit origins -
1267         then we would crash because the callee is unknown. It also revealed that LICM could *almost*
1268         get hosed by having a pre-header where there are effects before the jump. I wasn't able to
1269         construct a test case that would crash trunk, but I also couldn't quite prove why such a
1270         program couldn't be constructed. I did fix the issue in loop pre-header creation, and the
1271         validater does catch the issue because of its exitOK assertions.
1272
1273         This doesn't yet add any other safeguards to LICM - that phase still expects that pre-headers
1274         are in place and that they were created in such a way that their terminal origins have exitOK.
1275         It also still keeps the old way of saying "not OK to exit" - having a clear NodeOrigin. In a
1276         later patch I'll remove that and use !exitOK everywhere. Note that I did consider using clear
1277         NodeOrigins to signify that it's not OK to exit, but that would make DFGForAllKills a lot more
1278         expensive - it would have to sometimes search to find nearby forExit origins if the current
1279         node doesn't have it set - and that's a critical phase for DFG compilation performance.
1280         Requiring that forExit is usually set to *something* and that properly shadows the original
1281         bytecode is cheap and easy, so it seemed like a good trade-off.
1282
1283         This change has no performance effect. Its only effect is that it makes the compiler easier to
1284         understand by turning a previously magical concept into an explicit one.
1285
1286         * CMakeLists.txt:
1287         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1288         * JavaScriptCore.xcodeproj/project.pbxproj:
1289         * dfg/DFGAbstractHeap.h:
1290         * dfg/DFGAbstractInterpreterInlines.h:
1291         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1292         * dfg/DFGArgumentsEliminationPhase.cpp:
1293         * dfg/DFGByteCodeParser.cpp:
1294         (JSC::DFG::ByteCodeParser::setDirect):
1295         (JSC::DFG::ByteCodeParser::currentNodeOrigin):
1296         (JSC::DFG::ByteCodeParser::branchData):
1297         (JSC::DFG::ByteCodeParser::addToGraph):
1298         (JSC::DFG::ByteCodeParser::handleCall):
1299         (JSC::DFG::ByteCodeParser::inlineCall):
1300         (JSC::DFG::ByteCodeParser::handleInlining):
1301         (JSC::DFG::ByteCodeParser::handleGetById):
1302         (JSC::DFG::ByteCodeParser::handlePutById):
1303         (JSC::DFG::ByteCodeParser::parseBlock):
1304         * dfg/DFGCFGSimplificationPhase.cpp:
1305         (JSC::DFG::CFGSimplificationPhase::run):
1306         * dfg/DFGClobberize.h:
1307         (JSC::DFG::clobberize):
1308         * dfg/DFGClobbersExitState.cpp: Added.
1309         (JSC::DFG::clobbersExitState):
1310         * dfg/DFGClobbersExitState.h: Added.
1311         * dfg/DFGConstantFoldingPhase.cpp:
1312         (JSC::DFG::ConstantFoldingPhase::emitPutByOffset):
1313         * dfg/DFGDoesGC.cpp:
1314         (JSC::DFG::doesGC):
1315         * dfg/DFGFixupPhase.cpp:
1316         (JSC::DFG::FixupPhase::fixupNode):
1317         (JSC::DFG::FixupPhase::convertStringAddUse):
1318         (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
1319         (JSC::DFG::FixupPhase::fixupGetAndSetLocalsInBlock):
1320         (JSC::DFG::FixupPhase::fixupChecksInBlock):
1321         * dfg/DFGFlushFormat.h:
1322         (JSC::DFG::useKindFor):
1323         (JSC::DFG::uncheckedUseKindFor):
1324         (JSC::DFG::typeFilterFor):
1325         * dfg/DFGGraph.cpp:
1326         (JSC::DFG::printWhiteSpace):
1327         (JSC::DFG::Graph::dumpCodeOrigin):
1328         (JSC::DFG::Graph::dump):
1329         * dfg/DFGGraph.h:
1330         (JSC::DFG::Graph::addSpeculationMode):
1331         * dfg/DFGInsertionSet.cpp:
1332         (JSC::DFG::InsertionSet::insertSlow):
1333         (JSC::DFG::InsertionSet::execute):
1334         * dfg/DFGLoopPreHeaderCreationPhase.cpp:
1335         (JSC::DFG::LoopPreHeaderCreationPhase::run):
1336         * dfg/DFGMayExit.cpp:
1337         (JSC::DFG::mayExit):
1338         (WTF::printInternal):
1339         * dfg/DFGMayExit.h:
1340         * dfg/DFGMovHintRemovalPhase.cpp:
1341         * dfg/DFGNodeOrigin.cpp: Added.
1342         (JSC::DFG::NodeOrigin::dump):
1343         * dfg/DFGNodeOrigin.h:
1344         (JSC::DFG::NodeOrigin::NodeOrigin):
1345         (JSC::DFG::NodeOrigin::isSet):
1346         (JSC::DFG::NodeOrigin::withSemantic):
1347         (JSC::DFG::NodeOrigin::withExitOK):
1348         (JSC::DFG::NodeOrigin::withInvalidExit):
1349         (JSC::DFG::NodeOrigin::takeValidExit):
1350         (JSC::DFG::NodeOrigin::forInsertingAfter):
1351         (JSC::DFG::NodeOrigin::operator==):
1352         (JSC::DFG::NodeOrigin::operator!=):
1353         * dfg/DFGNodeType.h:
1354         * dfg/DFGOSREntrypointCreationPhase.cpp:
1355         (JSC::DFG::OSREntrypointCreationPhase::run):
1356         * dfg/DFGOSRExit.cpp:
1357         (JSC::DFG::OSRExit::OSRExit):
1358         (JSC::DFG::OSRExit::setPatchableCodeOffset):
1359         * dfg/DFGOSRExitBase.h:
1360         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1361         * dfg/DFGPhantomInsertionPhase.cpp:
1362         * dfg/DFGPhase.cpp:
1363         (JSC::DFG::Phase::validate):
1364         (JSC::DFG::Phase::beginPhase):
1365         (JSC::DFG::Phase::endPhase):
1366         * dfg/DFGPhase.h:
1367         (JSC::DFG::Phase::vm):
1368         (JSC::DFG::Phase::codeBlock):
1369         (JSC::DFG::Phase::profiledBlock):
1370         * dfg/DFGPredictionPropagationPhase.cpp:
1371         (JSC::DFG::PredictionPropagationPhase::propagate):
1372         * dfg/DFGPutStackSinkingPhase.cpp:
1373         * dfg/DFGSSAConversionPhase.cpp:
1374         (JSC::DFG::SSAConversionPhase::run):
1375         * dfg/DFGSafeToExecute.h:
1376         (JSC::DFG::safeToExecute):
1377         * dfg/DFGSpeculativeJIT.cpp:
1378         (JSC::DFG::SpeculativeJIT::SpeculativeJIT):
1379         (JSC::DFG::SpeculativeJIT::speculationCheck):
1380         (JSC::DFG::SpeculativeJIT::emitInvalidationPoint):
1381         (JSC::DFG::SpeculativeJIT::terminateSpeculativeExecution):
1382         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
1383         (JSC::DFG::SpeculativeJIT::checkArgumentTypes):
1384         (JSC::DFG::SpeculativeJIT::compile):
1385         * dfg/DFGSpeculativeJIT.h:
1386         * dfg/DFGSpeculativeJIT32_64.cpp:
1387         (JSC::DFG::SpeculativeJIT::compile):
1388         * dfg/DFGSpeculativeJIT64.cpp:
1389         (JSC::DFG::SpeculativeJIT::compile):
1390         * dfg/DFGStoreBarrierInsertionPhase.cpp:
1391         * dfg/DFGTypeCheckHoistingPhase.cpp:
1392         (JSC::DFG::TypeCheckHoistingPhase::run):
1393         * dfg/DFGValidate.cpp:
1394         (JSC::DFG::Validate::validate):
1395         * ftl/FTLCapabilities.cpp:
1396         (JSC::FTL::canCompile):
1397         * ftl/FTLLowerDFGToLLVM.cpp:
1398         (JSC::FTL::DFG::LowerDFGToLLVM::lower):
1399         (JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
1400         (JSC::FTL::DFG::LowerDFGToLLVM::compileUpsilon):
1401         (JSC::FTL::DFG::LowerDFGToLLVM::compileInvalidationPoint):
1402         (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
1403
1404 2015-08-26  Andreas Kling  <akling@apple.com>
1405
1406         [JSC] StructureTransitionTable should eagerly deallocate single-transition WeakImpls.
1407         <https://webkit.org/b/148478>
1408
1409         Reviewed by Geoffrey Garen.
1410
1411         Use a WeakHandleOwner to eagerly deallocate StructureTransitionTable's Weak pointers
1412         when it's using the single-transition optimization and the Structure it transitioned
1413         to has been GC'd.
1414
1415         This prevents Structures from keeping WeakBlocks alive longer than necessary when
1416         they've been transitioned away from but are still in use themselves.
1417
1418         * runtime/Structure.cpp:
1419         (JSC::singleSlotTransitionWeakOwner):
1420         (JSC::StructureTransitionTable::singleTransition):
1421         (JSC::StructureTransitionTable::setSingleTransition):
1422         (JSC::StructureTransitionTable::add):
1423         * runtime/StructureTransitionTable.h:
1424         (JSC::StructureTransitionTable::singleTransition): Deleted.
1425         (JSC::StructureTransitionTable::setSingleTransition): Deleted.
1426
1427 2015-08-26  Brian Burg  <bburg@apple.com>
1428
1429         Web Inspector: REGRESSION(r188965): BackendDispatcher loses request ids when called re-entrantly
1430         https://bugs.webkit.org/show_bug.cgi?id=148480
1431
1432         Reviewed by Joseph Pecoraro.
1433
1434         I added an assertion that m_currentRequestId is Nullopt when dispatch() is called, but this should
1435         not hold if dispatching a backend command while debugger is paused. I will remove the assertion
1436         and add proper scoping for all dispatch() branches.
1437
1438         No new tests, this wrong assert caused inspector/dom-debugger/node-removed.html to crash reliably.
1439
1440         * inspector/InspectorBackendDispatcher.cpp:
1441         (Inspector::BackendDispatcher::dispatch): Cover each exit with an appropriate TemporaryChange scope.
1442
1443 2015-08-26  Sukolsak Sakshuwong  <sukolsak@gmail.com>
1444
1445         Remove the unused *Executable::unlinkCalls() and CodeBlock::unlinkCalls()
1446         https://bugs.webkit.org/show_bug.cgi?id=148469
1447
1448         Reviewed by Geoffrey Garen.
1449
1450         We use CodeBlock::unlinkIncomingCalls() to unlink calls.
1451         (...)Executable::unlinkCalls() and CodeBlock::unlinkCalls() are no longer used.
1452
1453         * bytecode/CodeBlock.cpp:
1454         (JSC::CodeBlock::unlinkCalls): Deleted.
1455         * bytecode/CodeBlock.h:
1456         * runtime/Executable.cpp:
1457         (JSC::EvalExecutable::unlinkCalls): Deleted.
1458         (JSC::ProgramExecutable::unlinkCalls): Deleted.
1459         (JSC::FunctionExecutable::unlinkCalls): Deleted.
1460         * runtime/Executable.h:
1461         (JSC::ScriptExecutable::unlinkCalls): Deleted.
1462
1463 2015-08-25  Brian Burg  <bburg@apple.com>
1464
1465         Web Inspector: no need to allocate protocolErrors array for every dispatched backend command
1466         https://bugs.webkit.org/show_bug.cgi?id=146466
1467
1468         Reviewed by Joseph Pecoraro.
1469
1470         Clean up some of the backend dispatcher code, with a focus on eliminating useless allocations
1471         of objects in the common case when no protocol errors happen. This is done by saving the
1472         current id of each request as it is being processed by the backend dispatcher, and tagging any
1473         subsequent errors with that id. This also means we don't have to thread the requestId except
1474         in the async command code path.
1475
1476         This patch also lifts some common code shared between all generated backend command
1477         implementatations into the per-domain dispatch method instead. This reduces generated code size.
1478
1479         To be consistent, this patch standardizes on calling the id of a backend message its 'requestId'.
1480         Requests can be handled synchronously or asynchronously (triggered via the 'async' property).
1481
1482         No new tests, covered by existing protocol tests.
1483
1484         * inspector/InspectorBackendDispatcher.cpp:
1485         (Inspector::BackendDispatcher::CallbackBase::CallbackBase): Split the two code paths for reporting
1486         success and failure.
1487
1488         (Inspector::BackendDispatcher::CallbackBase::sendFailure):
1489         (Inspector::BackendDispatcher::CallbackBase::sendSuccess): Renamed from sendIfActive.
1490         (Inspector::BackendDispatcher::dispatch): Reset counters and current requestId before dispatching.
1491         No need to manually thread the requestId to all reportProtocolError calls.
1492
1493         (Inspector::BackendDispatcher::hasProtocolErrors): Added.
1494         (Inspector::BackendDispatcher::sendResponse):
1495         (Inspector::BackendDispatcher::sendPendingErrors): Send any saved protocol errors to the frontend.
1496         Always send a 'data' member with all of the errors, even if there's just one. We might want to add
1497         more information about errors later.
1498
1499         (Inspector::BackendDispatcher::reportProtocolError): Enqueue a protocol error to be sent later.
1500         (Inspector::BackendDispatcher::getPropertyValue): Remove useless type parameters and nuke most of
1501         the type conversion methods. Use std::function types instead of function pointer types.
1502
1503         (Inspector::castToInteger): Added.
1504         (Inspector::castToNumber): Added.
1505         (Inspector::BackendDispatcher::getInteger):
1506         (Inspector::BackendDispatcher::getDouble):
1507         (Inspector::BackendDispatcher::getString):
1508         (Inspector::BackendDispatcher::getBoolean):
1509         (Inspector::BackendDispatcher::getObject):
1510         (Inspector::BackendDispatcher::getArray):
1511         (Inspector::BackendDispatcher::getValue):
1512         (Inspector::getPropertyValue): Deleted.
1513         (Inspector::AsMethodBridges::asInteger): Deleted.
1514         (Inspector::AsMethodBridges::asDouble): Deleted.
1515         (Inspector::AsMethodBridges::asString): Deleted.
1516         (Inspector::AsMethodBridges::asBoolean): Deleted.
1517         (Inspector::AsMethodBridges::asObject): Deleted.
1518         (Inspector::AsMethodBridges::asArray): Deleted.
1519         (Inspector::AsMethodBridges::asValue): Deleted.
1520         * inspector/InspectorBackendDispatcher.h:
1521         * inspector/scripts/codegen/cpp_generator_templates.py: Extract 'params' object in domain dispatch method.
1522         Omit requestIds where possible. Convert dispatch tables to use NeverDestroyed. Check the protocol error count
1523         to decide whether to abort the dispatch or not, rather than allocating our own errors array.
1524
1525         * inspector/scripts/codegen/cpp_generator_templates.py:
1526         (void):
1527         * inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py: Revert to passing RefPtr<InspectorObject>
1528         since parameters are now being passed rather than the message object. Some commands do not require parameters.
1529         * inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
1530         (CppBackendDispatcherImplementationGenerator.generate_output):
1531         (CppBackendDispatcherImplementationGenerator._generate_small_dispatcher_switch_implementation_for_domain):
1532         (CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command):
1533         * inspector/scripts/codegen/generate_objc_backend_dispatcher_header.py:
1534         (ObjCBackendDispatcherHeaderGenerator._generate_objc_handler_declaration_for_command):
1535         * inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
1536         (ObjCConfigurationImplementationGenerator._generate_handler_implementation_for_command):
1537         (ObjCConfigurationImplementationGenerator._generate_success_block_for_command):
1538         * inspector/scripts/codegen/objc_generator_templates.py:
1539
1540         Rebaseline some protocol generator tests.
1541         * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
1542         * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
1543         * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
1544         * inspector/scripts/tests/expected/enum-values.json-result:
1545         * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
1546         * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
1547         * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
1548         * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
1549         * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
1550         * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
1551         * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
1552         * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
1553         * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
1554
1555 2015-08-25  Saam barati  <sbarati@apple.com>
1556
1557         Lets rename codeOriginIndex to callSiteIndex and get rid of CallFrame::Location.
1558         https://bugs.webkit.org/show_bug.cgi?id=148213
1559
1560         Reviewed by Filip Pizlo.
1561
1562         This patch introduces a struct called CallSiteIndex which is
1563         used as a wrapper for a 32-bit int to place things in the tag for ArgumentCount 
1564         in the call frame. On 32-bit we place Instruction* into this slot for LLInt and Basline.
1565         For 32-bit DFG we place a an index into the code origin table in this slot.
1566         On 64-bit we place a bytecode offset into this slot for LLInt and Baseline.
1567         On 64-bit we place the index into the code origin table in this slot in the
1568         DFG/FTL.
1569
1570         This patch also gets rid of the encoding scheme that describes if something is a
1571         bytecode index or a code origin table index. This information can always
1572         be determined based on the CodeBlock's' JITType.
1573
1574         StructureStubInfo now also has a CallSiteIndex which it stores to
1575         the call frame when making a call.
1576
1577         * bytecode/CodeBlock.h:
1578         (JSC::CodeBlock::hasCodeOrigins):
1579         (JSC::CodeBlock::canGetCodeOrigin):
1580         (JSC::CodeBlock::codeOrigin):
1581         (JSC::CodeBlock::addFrequentExitSite):
1582         * bytecode/StructureStubInfo.h:
1583         (JSC::StructureStubInfo::StructureStubInfo):
1584         * dfg/DFGCommonData.cpp:
1585         (JSC::DFG::CommonData::notifyCompilingStructureTransition):
1586         (JSC::DFG::CommonData::addCodeOrigin):
1587         (JSC::DFG::CommonData::shrinkToFit):
1588         * dfg/DFGCommonData.h:
1589         (JSC::DFG::CommonData::CommonData):
1590         * dfg/DFGJITCompiler.h:
1591         (JSC::DFG::JITCompiler::setEndOfCode):
1592         (JSC::DFG::JITCompiler::addCallSite):
1593         (JSC::DFG::JITCompiler::emitStoreCodeOrigin):
1594         * dfg/DFGOSRExitCompilerCommon.cpp:
1595         (JSC::DFG::reifyInlinedCallFrames):
1596         * dfg/DFGSpeculativeJIT.cpp:
1597         (JSC::DFG::SpeculativeJIT::compileIn):
1598         * dfg/DFGSpeculativeJIT32_64.cpp:
1599         (JSC::DFG::SpeculativeJIT::cachedGetById):
1600         (JSC::DFG::SpeculativeJIT::cachedPutById):
1601         * dfg/DFGSpeculativeJIT64.cpp:
1602         (JSC::DFG::SpeculativeJIT::cachedGetById):
1603         (JSC::DFG::SpeculativeJIT::cachedPutById):
1604         * ftl/FTLCompile.cpp:
1605         (JSC::FTL::mmAllocateDataSection):
1606         * ftl/FTLInlineCacheDescriptor.h:
1607         (JSC::FTL::InlineCacheDescriptor::InlineCacheDescriptor):
1608         (JSC::FTL::InlineCacheDescriptor::stackmapID):
1609         (JSC::FTL::InlineCacheDescriptor::callSiteIndex):
1610         (JSC::FTL::InlineCacheDescriptor::uid):
1611         (JSC::FTL::GetByIdDescriptor::GetByIdDescriptor):
1612         (JSC::FTL::PutByIdDescriptor::PutByIdDescriptor):
1613         (JSC::FTL::CheckInDescriptor::CheckInDescriptor):
1614         (JSC::FTL::InlineCacheDescriptor::codeOrigin): Deleted.
1615         * ftl/FTLLink.cpp:
1616         (JSC::FTL::link):
1617         * ftl/FTLLowerDFGToLLVM.cpp:
1618         (JSC::FTL::DFG::LowerDFGToLLVM::compilePutById):
1619         (JSC::FTL::DFG::LowerDFGToLLVM::compileIn):
1620         (JSC::FTL::DFG::LowerDFGToLLVM::getById):
1621         (JSC::FTL::DFG::LowerDFGToLLVM::callPreflight):
1622         * ftl/FTLSlowPathCall.cpp:
1623         (JSC::FTL::storeCodeOrigin):
1624         * interpreter/CallFrame.cpp:
1625         (JSC::CallFrame::currentVPC):
1626         (JSC::CallFrame::setCurrentVPC):
1627         (JSC::CallFrame::callSiteBitsAsBytecodeOffset):
1628         (JSC::CallFrame::bytecodeOffset):
1629         (JSC::CallFrame::codeOrigin):
1630         (JSC::CallFrame::topOfFrameInternal):
1631         (JSC::CallFrame::locationAsBytecodeOffset): Deleted.
1632         (JSC::CallFrame::setLocationAsBytecodeOffset): Deleted.
1633         (JSC::CallFrame::bytecodeOffsetFromCodeOriginIndex): Deleted.
1634         * interpreter/CallFrame.h:
1635         (JSC::CallSiteIndex::CallSiteIndex):
1636         (JSC::CallSiteIndex::bits):
1637         (JSC::ExecState::returnPCOffset):
1638         (JSC::ExecState::abstractReturnPC):
1639         (JSC::ExecState::topOfFrame):
1640         (JSC::ExecState::setCallerFrame):
1641         (JSC::ExecState::setScope):
1642         (JSC::ExecState::currentVPC): Deleted.
1643         (JSC::ExecState::setCurrentVPC): Deleted.
1644         * interpreter/CallFrameInlines.h:
1645         (JSC::CallFrame::callSiteBitsAreBytecodeOffset):
1646         (JSC::CallFrame::callSiteBitsAreCodeOriginIndex):
1647         (JSC::CallFrame::callSiteAsRawBits):
1648         (JSC::CallFrame::callSiteIndex):
1649         (JSC::CallFrame::hasActivation):
1650         (JSC::CallFrame::Location::encode): Deleted.
1651         (JSC::CallFrame::Location::decode): Deleted.
1652         (JSC::CallFrame::Location::encodeAsBytecodeOffset): Deleted.
1653         (JSC::CallFrame::Location::encodeAsBytecodeInstruction): Deleted.
1654         (JSC::CallFrame::Location::encodeAsCodeOriginIndex): Deleted.
1655         (JSC::CallFrame::Location::isBytecodeLocation): Deleted.
1656         (JSC::CallFrame::Location::isCodeOriginIndex): Deleted.
1657         (JSC::CallFrame::hasLocationAsBytecodeOffset): Deleted.
1658         (JSC::CallFrame::hasLocationAsCodeOriginIndex): Deleted.
1659         (JSC::CallFrame::locationAsRawBits): Deleted.
1660         (JSC::CallFrame::setLocationAsRawBits): Deleted.
1661         (JSC::CallFrame::locationAsBytecodeOffset): Deleted.
1662         (JSC::CallFrame::setLocationAsBytecodeOffset): Deleted.
1663         (JSC::CallFrame::locationAsCodeOriginIndex): Deleted.
1664         * interpreter/StackVisitor.cpp:
1665         (JSC::StackVisitor::readFrame):
1666         (JSC::StackVisitor::readNonInlinedFrame):
1667         (JSC::StackVisitor::Frame::print):
1668         * jit/JITCall.cpp:
1669         (JSC::JIT::compileOpCall):
1670         * jit/JITCall32_64.cpp:
1671         (JSC::JIT::compileOpCall):
1672         * jit/JITInlineCacheGenerator.cpp:
1673         (JSC::garbageStubInfo):
1674         (JSC::JITInlineCacheGenerator::JITInlineCacheGenerator):
1675         (JSC::JITByIdGenerator::JITByIdGenerator):
1676         (JSC::JITByIdGenerator::generateFastPathChecks):
1677         (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
1678         (JSC::JITGetByIdGenerator::generateFastPath):
1679         (JSC::JITPutByIdGenerator::JITPutByIdGenerator):
1680         * jit/JITInlineCacheGenerator.h:
1681         (JSC::JITInlineCacheGenerator::JITInlineCacheGenerator):
1682         (JSC::JITInlineCacheGenerator::stubInfo):
1683         (JSC::JITByIdGenerator::JITByIdGenerator):
1684         (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
1685         (JSC::JITPutByIdGenerator::JITPutByIdGenerator):
1686         * jit/JITInlines.h:
1687         (JSC::JIT::updateTopCallFrame):
1688         * jit/JITOperations.cpp:
1689         (JSC::getByVal):
1690         (JSC::tryGetByValOptimize):
1691         * jit/JITPropertyAccess.cpp:
1692         (JSC::JIT::emitGetByValWithCachedId):
1693         (JSC::JIT::emitPutByValWithCachedId):
1694         (JSC::JIT::emit_op_get_by_id):
1695         (JSC::JIT::emit_op_put_by_id):
1696         * jit/JITPropertyAccess32_64.cpp:
1697         (JSC::JIT::emitGetByValWithCachedId):
1698         (JSC::JIT::emitPutByValWithCachedId):
1699         (JSC::JIT::emit_op_get_by_id):
1700         (JSC::JIT::emit_op_put_by_id):
1701         * jit/Repatch.cpp:
1702         (JSC::generateByIdStub):
1703
1704 2015-08-25 Aleksandr Skachkov   <gskachkov@gmail.com>
1705
1706         Function.prototype.toString is incorrect for ArrowFunction
1707         https://bugs.webkit.org/show_bug.cgi?id=148148
1708
1709         Reviewed by Saam Barati.
1710         
1711         Added correct support of toString() method for arrow function.
1712
1713         * parser/ASTBuilder.h:
1714         (JSC::ASTBuilder::createFunctionMetadata):
1715         (JSC::ASTBuilder::createArrowFunctionExpr):
1716         * parser/Nodes.cpp:
1717         (JSC::FunctionMetadataNode::FunctionMetadataNode):
1718         * parser/Nodes.h:
1719         * parser/Parser.cpp:
1720         (JSC::Parser<LexerType>::parseFunctionBody):
1721         (JSC::Parser<LexerType>::parseFunctionInfo):
1722         * parser/SyntaxChecker.h:
1723         (JSC::SyntaxChecker::createFunctionMetadata):
1724         * runtime/FunctionPrototype.cpp:
1725         (JSC::functionProtoFuncToString):
1726         * tests/stress/arrowfunction-tostring.js: Added.
1727
1728 2015-08-25  Saam barati  <sbarati@apple.com>
1729
1730         Callee can be incorrectly overridden when it's captured
1731         https://bugs.webkit.org/show_bug.cgi?id=148400
1732
1733         Reviewed by Filip Pizlo.
1734
1735         We now resort to always creating the function name scope
1736         when the function name is in scope. Because the bytecode
1737         generator now has a notion of local lexical scoping,
1738         this incurs no runtime penalty for function expression names
1739         that aren't heap allocated. If they are heap allocated,
1740         this means we may now have one more scope on the runtime
1741         scope stack than before. This modification simplifies the
1742         callee initialization code and uses the lexical scoping constructs
1743         to implement this. This implementation also ensures
1744         that everything Just Works for function's with default
1745         parameter values. Before this patch, IIFE functions
1746         with default parameter values and a captured function
1747         name would crash JSC.
1748
1749         * bytecompiler/BytecodeGenerator.cpp:
1750         (JSC::BytecodeGenerator::BytecodeGenerator):
1751         (JSC::BytecodeGenerator::pushLexicalScopeInternal):
1752         (JSC::BytecodeGenerator::popLexicalScopeInternal):
1753         (JSC::BytecodeGenerator::variable):
1754         (JSC::BytecodeGenerator::resolveType):
1755         (JSC::BytecodeGenerator::emitThrowTypeError):
1756         (JSC::BytecodeGenerator::emitPushFunctionNameScope):
1757         (JSC::BytecodeGenerator::emitReadOnlyExceptionIfNeeded):
1758         * bytecompiler/BytecodeGenerator.h:
1759         (JSC::Variable::isReadOnly):
1760         (JSC::Variable::isSpecial):
1761         (JSC::Variable::isConst):
1762         (JSC::Variable::setIsReadOnly):
1763         * bytecompiler/NodesCodegen.cpp:
1764         (JSC::PostfixNode::emitResolve):
1765         (JSC::PrefixNode::emitResolve):
1766         (JSC::ReadModifyResolveNode::emitBytecode):
1767         (JSC::AssignResolveNode::emitBytecode):
1768         (JSC::BindingNode::bindValue):
1769         * tests/stress/IIFE-es6-default-parameters.js: Added.
1770         (assert):
1771         (.):
1772         * tests/stress/IIFE-function-name-captured.js: Added.
1773         (assert):
1774         (.):
1775
1776 2015-08-24  Brian Burg  <bburg@apple.com>
1777
1778         Web Inspector: add protocol test for existing error handling performed by the backend
1779         https://bugs.webkit.org/show_bug.cgi?id=147097
1780
1781         Reviewed by Joseph Pecoraro.
1782
1783         A new test revealed that the protocol "method" parameter was being parsed in a naive way.
1784         Rewrite it to use String::split and improve error checking to avoid failing later.
1785
1786         * inspector/InspectorBackendDispatcher.cpp:
1787         (Inspector::BackendDispatcher::dispatch):
1788
1789 2015-08-24  Yusuke Suzuki  <utatane.tea@gmail.com>
1790
1791         [ES6] Return JSInternalPromise as result of evaluateModule
1792         https://bugs.webkit.org/show_bug.cgi?id=148173
1793
1794         Reviewed by Saam Barati.
1795
1796         Now evaluateModule returns JSInternalPromise* as its result value.
1797         When an error occurs while loading or executing the modules,
1798         this promise is rejected by that error. By leveraging this, we implemented
1799         asynchronous error reporting when executing the modules in JSC shell.
1800
1801         And this patch also changes the evaluateModule signature to accept the entry
1802         point by the moduleName. By using it, JSC shell can start executing the modules
1803         with the entry point module name.
1804
1805         * builtins/ModuleLoaderObject.js:
1806         (loadModule):
1807         * jsc.cpp:
1808         (dumpException):
1809         (runWithScripts):
1810         * runtime/Completion.cpp:
1811         (JSC::evaluateModule):
1812         * runtime/Completion.h:
1813         * runtime/JSInternalPromise.cpp:
1814         (JSC::JSInternalPromise::then):
1815         * runtime/JSInternalPromise.h:
1816         * runtime/ModuleLoaderObject.cpp:
1817         (JSC::ModuleLoaderObject::requestInstantiateAll):
1818         (JSC::ModuleLoaderObject::loadModule):
1819         (JSC::ModuleLoaderObject::resolve):
1820         (JSC::ModuleLoaderObject::fetch):
1821         (JSC::ModuleLoaderObject::translate):
1822         (JSC::ModuleLoaderObject::instantiate):
1823         (JSC::moduleLoaderObjectParseModule):
1824         * runtime/ModuleLoaderObject.h:
1825
1826 2015-08-24  Basile Clement  <basile_clement@apple.com>
1827
1828         REPTACH is not a word
1829         https://bugs.webkit.org/show_bug.cgi?id=148401
1830
1831         Reviewed by Saam Barati.
1832
1833         * assembler/MacroAssemblerX86_64.h:
1834         (JSC::MacroAssemblerX86_64::callWithSlowPathReturnType):
1835         (JSC::MacroAssemblerX86_64::call):
1836         (JSC::MacroAssemblerX86_64::tailRecursiveCall):
1837         (JSC::MacroAssemblerX86_64::makeTailRecursiveCall):
1838         (JSC::MacroAssemblerX86_64::readCallTarget):
1839         (JSC::MacroAssemblerX86_64::linkCall):
1840         (JSC::MacroAssemblerX86_64::repatchCall):
1841
1842 2015-08-24  Mark Lam  <mark.lam@apple.com>
1843
1844         Add support for setting JSC options from a file.
1845         https://bugs.webkit.org/show_bug.cgi?id=148394
1846
1847         Reviewed by Saam Barati.
1848
1849         This is needed for environments where the JSC executable does not have access to
1850         environmental variables.  This is only needed for debugging, and is currently
1851         guarded under a #define USE_OPTIONS_FILE in Options.cpp, and is disabled by
1852         default.
1853
1854         Also fixed Options::setOptions() to be allow for whitespace that is not a single
1855         ' '.  This makes setOptions() much more flexible and friendlier to use for loading
1856         options in general.
1857
1858         For example, this current use case of loading options from a file may have '\n's
1859         in the character stream, and this feature is easier to implement if setOptions()
1860         just support more than 1 whitespace char between options, and recognize whitespace
1861         characters other than ' '.
1862
1863         * runtime/Options.cpp:
1864         (JSC::parse):
1865         (JSC::Options::initialize):
1866         (JSC::Options::setOptions):
1867
1868 2015-08-24  Filip Pizlo  <fpizlo@apple.com>
1869
1870         DFG::FixupPhase should use the lambda form of m_graph.doToChildren() rather than the old macro
1871         https://bugs.webkit.org/show_bug.cgi?id=148397
1872
1873         Reviewed by Geoffrey Garen.
1874
1875         We used to iterate the edges of a node by using the DFG_NODE_DO_TO_CHILDREN macro. We
1876         don't need to do that anymore since we have the lambda-based m_graph.doToChildren(). This
1877         allows us to get rid of a bunch of helper methods in DFG::FixupPhase.
1878
1879         I also took the opportunity to give the injectTypeConversionsInBlock() method a more
1880         generic name, since after https://bugs.webkit.org/show_bug.cgi?id=145204 it will be used
1881         for fix-up of checks more broadly.
1882
1883         * dfg/DFGFixupPhase.cpp:
1884         (JSC::DFG::FixupPhase::run):
1885         (JSC::DFG::FixupPhase::attemptToMakeGetTypedArrayByteOffset):
1886         (JSC::DFG::FixupPhase::fixupChecksInBlock):
1887         (JSC::DFG::FixupPhase::injectTypeConversionsInBlock): Deleted.
1888         (JSC::DFG::FixupPhase::tryToRelaxRepresentation): Deleted.
1889         (JSC::DFG::FixupPhase::fixEdgeRepresentation): Deleted.
1890         (JSC::DFG::FixupPhase::injectTypeConversionsForEdge): Deleted.
1891
1892 2015-08-24  Geoffrey Garen  <ggaren@apple.com>
1893
1894         Some renaming to clarify CodeBlock and UnlinkedCodeBlock
1895         https://bugs.webkit.org/show_bug.cgi?id=148391
1896
1897         Reviewed by Saam Barati.
1898
1899         * bytecode/UnlinkedFunctionExecutable.cpp:
1900         (JSC::generateUnlinkedFunctionCodeBlock):
1901         (JSC::UnlinkedFunctionExecutable::visitChildren):
1902         (JSC::UnlinkedFunctionExecutable::fromGlobalCode):
1903         (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
1904         (JSC::generateFunctionCodeBlock): Deleted.
1905         (JSC::UnlinkedFunctionExecutable::codeBlockFor): Deleted.
1906         * bytecode/UnlinkedFunctionExecutable.h: Call our CodeBlocks "unlinked"
1907         in the name for clarity, since we are unlinked. 
1908
1909         * heap/Heap.cpp:
1910         (JSC::Heap::objectTypeCounts):
1911         (JSC::Heap::deleteAllCodeBlocks):
1912         (JSC::Heap::deleteAllUnlinkedCodeBlocks):
1913         (JSC::Heap::clearUnmarkedExecutables):
1914         (JSC::Heap::deleteOldCode):
1915         (JSC::Heap::FinalizerOwner::finalize):
1916         (JSC::Heap::addExecutable):
1917         (JSC::Heap::collectAllGarbageIfNotDoneRecently):
1918         (JSC::Heap::deleteAllCompiledCode): Deleted.
1919         (JSC::Heap::deleteAllUnlinkedFunctionCode): Deleted.
1920         (JSC::Heap::addCompiledCode): Deleted.
1921         * heap/Heap.h:
1922         (JSC::Heap::notifyIsSafeToCollect):
1923         (JSC::Heap::isSafeToCollect):
1924         (JSC::Heap::sizeBeforeLastFullCollection):
1925         (JSC::Heap::sizeAfterLastFullCollection):
1926         (JSC::Heap::compiledCode): Deleted.
1927
1928             deleteAllCompiledCode => deleteAllCodeBlocks because "compiled"
1929             is a broad phrase these days.
1930
1931             m_compiledCode => m_executables for the same reason.
1932
1933             addCompiledCode => addExecutable for the same reason.
1934
1935             deleteAllUnlinkedFunctionCode => deleteAllUnlinkedCodeBlocks
1936             for consistency.
1937
1938         * jsc.cpp:
1939         (functionDeleteAllCompiledCode):
1940
1941         * runtime/Executable.cpp:
1942         (JSC::ScriptExecutable::newCodeBlockFor): codeBlockFor => unlinkedCodeBlockFor
1943
1944         (JSC::FunctionExecutable::clearUnlinkedCodeForRecompilation): Deleted.
1945         It was strange to put this function on executable, since its name implied
1946         that it only changed the executable, but it actually changed all cached
1947         code. Now, a client that wants to change cached code must do so explicitly.
1948
1949         * runtime/Executable.h:
1950         (JSC::ScriptExecutable::finishCreation):
1951         * runtime/VM.cpp:
1952         (JSC::VM::deleteAllCode):
1953         * runtime/VMEntryScope.cpp:
1954         (JSC::VMEntryScope::VMEntryScope): Updated for renames above.
1955
1956 2015-08-22  Filip Pizlo  <fpizlo@apple.com>
1957
1958         DFG::InsertionSet should be tolerant of occasional out-of-order insertions
1959         https://bugs.webkit.org/show_bug.cgi?id=148367
1960
1961         Reviewed by Geoffrey Garen and Saam Barati.
1962
1963         Since forever, the DFG::InsertionSet has been the way we insert nodes into DFG IR, and it
1964         requires that you walk a block in order and perform insertions in order: you can't insert
1965         something at index J, then at index I where I < J, except if you do a second pass.
1966
1967         This restriction makes sense, because it enables a very fast algorithm. And it's very
1968         rare that a phase would need to insert things out of order.
1969
1970         But sometimes - rarely - we need to insert things slightly out-of-order. For example we
1971         may want to insert a node at index J, but to insert a check associated with that node, we
1972         may need to use index I where I < J. This will come up from the work on
1973         https://bugs.webkit.org/show_bug.cgi?id=145204. And it has already come up in the past.
1974         It seems like it would be best to just lift this restriction.
1975
1976         * CMakeLists.txt:
1977         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1978         * JavaScriptCore.xcodeproj/project.pbxproj:
1979         * dfg/DFGInsertionSet.cpp: Added.
1980         (JSC::DFG::InsertionSet::insertSlow):
1981         * dfg/DFGInsertionSet.h:
1982         (JSC::DFG::InsertionSet::InsertionSet):
1983         (JSC::DFG::InsertionSet::graph):
1984         (JSC::DFG::InsertionSet::insert):
1985         (JSC::DFG::InsertionSet::execute):
1986
1987 2015-08-24  Yusuke Suzuki  <utatane.tea@gmail.com>
1988
1989         Create ById IC for ByVal operation only when the specific Id comes more than once
1990         https://bugs.webkit.org/show_bug.cgi?id=148288
1991
1992         Reviewed by Geoffrey Garen.
1993
1994         After introducing byId ICs into byVal ops, byVal ops creates much ICs than before.
1995         The failure fixed in r188767 figures out these ICs are created even if this op is executed only once.
1996
1997         The situation is the following;
1998         In the current code, when byVal op is executed with the Id, we immediately set up the byId IC for that byVal op.
1999         But setting up JITGetByIdGenerator generates the fast path IC code and consumes executable memory.
2000         As a result, if we call eval("contains byVal ops") with the different strings repeatedly under no-llint environment, each eval call creates byId IC for byVal and consumes executable memory.
2001
2002         To solve it, we will add "seen" flag to ByValInfo.
2003         And we will create the IC on the second byVal op call with the same Id.
2004
2005         * bytecode/ByValInfo.h:
2006         (JSC::ByValInfo::ByValInfo):
2007         * jit/JITOperations.cpp:
2008         (JSC::tryGetByValOptimize):
2009         * jit/JITPropertyAccess.cpp:
2010         (JSC::JIT::privateCompileGetByValWithCachedId): Deleted.
2011         (JSC::JIT::privateCompilePutByValWithCachedId): Deleted.
2012
2013 2015-08-23  Benjamin Poulain  <bpoulain@apple.com>
2014
2015         [JSC] Get rid of NodePointerTraits
2016         https://bugs.webkit.org/show_bug.cgi?id=148340
2017
2018         Reviewed by Anders Carlsson.
2019
2020         NodePointerTraits does exactly the same thing has the default trait.
2021
2022         * dfg/DFGBasicBlock.h:
2023         * dfg/DFGCommon.h:
2024         (JSC::DFG::NodePointerTraits::defaultValue): Deleted.
2025         (JSC::DFG::NodePointerTraits::isEmptyForDump): Deleted.
2026
2027 2015-08-23  Benjamin Poulain  <bpoulain@apple.com>
2028
2029         [JSC] Reduce the memory usage of BytecodeLivenessAnalysis
2030         https://bugs.webkit.org/show_bug.cgi?id=148353
2031
2032         Reviewed by Darin Adler.
2033
2034         BytecodeLivenessAnalysis easily takes kilobytes of memory for
2035         non trivial blocks and that memory sticks around because
2036         it stored on CodeBlock.
2037
2038         This patch reduces that memory use a bit.
2039
2040         Most of the memory is in the array of BytecodeBasicBlock.
2041         BytecodeBasicBlock is shrunk by:
2042         -Making it not ref-counted.
2043         -Removing m_predecessors, it was only used for debugging and
2044          is usually big.
2045         -Added a shrinkToFit() phase to shrink the vectors once we are
2046          done building the BytecodeBasicBlock.
2047
2048         There are more things we should do in the future:
2049         -Store all the BytecodeBasicBlock direclty in the array.
2050          We know the size ahead of time, this would be a pure win.
2051          The only tricky part is changing m_successors to have the
2052          index of the successor instead of a pointer.
2053         -Stop putting duplicates in m_successors.
2054
2055         * bytecode/BytecodeBasicBlock.cpp:
2056         (JSC::computeBytecodeBasicBlocks):
2057         (JSC::BytecodeBasicBlock::shrinkToFit): Deleted.
2058         (JSC::linkBlocks): Deleted.
2059         * bytecode/BytecodeBasicBlock.h:
2060         (JSC::BytecodeBasicBlock::addSuccessor):
2061         (JSC::BytecodeBasicBlock::addPredecessor): Deleted.
2062         (JSC::BytecodeBasicBlock::predecessors): Deleted.
2063         * bytecode/BytecodeLivenessAnalysis.cpp:
2064         (JSC::getLeaderOffsetForBasicBlock):
2065         (JSC::findBasicBlockWithLeaderOffset):
2066         (JSC::findBasicBlockForBytecodeOffset):
2067         (JSC::stepOverInstruction):
2068         (JSC::computeLocalLivenessForBytecodeOffset):
2069         (JSC::computeLocalLivenessForBlock):
2070         (JSC::BytecodeLivenessAnalysis::dumpResults): Deleted.
2071         * bytecode/BytecodeLivenessAnalysis.h:
2072
2073 2015-08-23  Geoffrey Garen  <ggaren@apple.com>
2074
2075         Unreviewed, rolling back in r188792.
2076         https://bugs.webkit.org/show_bug.cgi?id=148347
2077
2078         Previously reverted changesets:
2079
2080         "Unify code paths for manually deleting all code"
2081         https://bugs.webkit.org/show_bug.cgi?id=148280
2082         http://trac.webkit.org/changeset/188792
2083
2084         The previous patch caused some inspector tests to hang because it
2085         introduced extra calls to sourceParsed, and sourceParsed is
2086         pathologically slow in WK1 debug builds. This patch restores pre-existing
2087         code to limit calls to sourceParsed, excluding code not being debugged
2088         (i.e., inspector code).
2089
2090 2015-08-23  Geoffrey Garen  <ggaren@apple.com>
2091
2092         Unreviewed, rolling back in r188803.
2093
2094         Previously reverted changesets:
2095
2096         "Debugger's VM should never be null"
2097         https://bugs.webkit.org/show_bug.cgi?id=148341
2098         http://trac.webkit.org/changeset/188803
2099
2100         * debugger/Debugger.cpp:
2101         (JSC::Debugger::Debugger):
2102         (JSC::Debugger::attach):
2103         (JSC::Debugger::detach):
2104         (JSC::Debugger::isAttached):
2105         (JSC::Debugger::setSteppingMode):
2106         (JSC::Debugger::registerCodeBlock):
2107         (JSC::Debugger::toggleBreakpoint):
2108         (JSC::Debugger::recompileAllJSFunctions):
2109         (JSC::Debugger::setBreakpoint):
2110         (JSC::Debugger::clearBreakpoints):
2111         (JSC::Debugger::clearDebuggerRequests):
2112         (JSC::Debugger::setBreakpointsActivated):
2113         (JSC::Debugger::breakProgram):
2114         (JSC::Debugger::stepOutOfFunction):
2115         (JSC::Debugger::returnEvent):
2116         (JSC::Debugger::didExecuteProgram):
2117         * debugger/Debugger.h:
2118         * inspector/JSGlobalObjectScriptDebugServer.cpp:
2119         (Inspector::JSGlobalObjectScriptDebugServer::JSGlobalObjectScriptDebugServer):
2120         (Inspector::JSGlobalObjectScriptDebugServer::removeListener):
2121         (Inspector::JSGlobalObjectScriptDebugServer::runEventLoopWhilePaused):
2122         (Inspector::JSGlobalObjectScriptDebugServer::recompileAllJSFunctions): Deleted.
2123         * inspector/JSGlobalObjectScriptDebugServer.h:
2124         * inspector/ScriptDebugServer.cpp:
2125         (Inspector::ScriptDebugServer::ScriptDebugServer):
2126         * inspector/ScriptDebugServer.h:
2127
2128 2015-08-22  Filip Pizlo  <fpizlo@apple.com>
2129
2130         DFG string concatenation shouldn't be playing fast and loose with effects and OSR exit
2131         https://bugs.webkit.org/show_bug.cgi?id=148338
2132
2133         Reviewed by Michael Saboff and Saam Barati.
2134
2135         Prior to this change, DFG string concatenation appeared to have various different ways of
2136         creating an OSR exit right after a side effect. That's bad, because the exit will cause
2137         us to reexecute the side effect. The code appears to have some hacks for avoiding this,
2138         but some cases are basically unavoidable, like the OOM case of string concatenation: in
2139         trunk that could cause two executions of the toString operation.
2140
2141         This changes the string concatenation code to either be speculative or effectful but
2142         never both. It's already the case that when this code needs to be effectful, it also
2143         needs to be slow (it does int->string conversions, calls JS functions, etc). So, this is
2144         a small price to pay for sanity.
2145
2146         The biggest part of this change is the introduction of StrCat, which is like MakeRope but
2147         does toString conversions on its own instead of relying on separate nodes. StrCat can
2148         take either 2 or 3 children. It's the effectful but not speculative version of MakeRope.
2149
2150         * dfg/DFGAbstractInterpreterInlines.h:
2151         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2152         * dfg/DFGBackwardsPropagationPhase.cpp:
2153         (JSC::DFG::BackwardsPropagationPhase::propagate):
2154         * dfg/DFGByteCodeParser.cpp:
2155         (JSC::DFG::ByteCodeParser::parseBlock):
2156         * dfg/DFGClobberize.h:
2157         (JSC::DFG::clobberize):
2158         * dfg/DFGDoesGC.cpp:
2159         (JSC::DFG::doesGC):
2160         * dfg/DFGFixupPhase.cpp:
2161         (JSC::DFG::FixupPhase::fixupNode):
2162         (JSC::DFG::FixupPhase::convertStringAddUse):
2163         (JSC::DFG::FixupPhase::fixupToStringOrCallStringConstructor):
2164         (JSC::DFG::FixupPhase::attemptToMakeFastStringAdd):
2165         (JSC::DFG::FixupPhase::canOptimizeStringObjectAccess):
2166         * dfg/DFGNodeType.h:
2167         * dfg/DFGOperations.cpp:
2168         * dfg/DFGOperations.h:
2169         * dfg/DFGPredictionPropagationPhase.cpp:
2170         (JSC::DFG::PredictionPropagationPhase::propagate):
2171         * dfg/DFGSafeToExecute.h:
2172         (JSC::DFG::safeToExecute):
2173         * dfg/DFGSpeculativeJIT.h:
2174         (JSC::DFG::SpeculativeJIT::callOperation):
2175         (JSC::DFG::JSValueOperand::JSValueOperand):
2176         (JSC::DFG::JSValueOperand::~JSValueOperand):
2177         * dfg/DFGSpeculativeJIT32_64.cpp:
2178         (JSC::DFG::SpeculativeJIT::compile):
2179         * dfg/DFGSpeculativeJIT64.cpp:
2180         (JSC::DFG::SpeculativeJIT::compile):
2181         * dfg/DFGValidate.cpp:
2182         (JSC::DFG::Validate::validate):
2183         * ftl/FTLCapabilities.cpp:
2184         (JSC::FTL::canCompile):
2185         * ftl/FTLIntrinsicRepository.h:
2186         * ftl/FTLLowerDFGToLLVM.cpp:
2187         (JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
2188         (JSC::FTL::DFG::LowerDFGToLLVM::compileValueAdd):
2189         (JSC::FTL::DFG::LowerDFGToLLVM::compileStrCat):
2190         (JSC::FTL::DFG::LowerDFGToLLVM::compileArithAddOrSub):
2191         * jit/JITOperations.h:
2192         * tests/stress/exception-effect-strcat.js: Added. This test previously failed.
2193         * tests/stress/exception-in-strcat-string-overflow.js: Added. An earlier version of this patch made this fail.
2194         * tests/stress/exception-in-strcat.js: Added.
2195
2196 2015-08-22  Andreas Kling  <akling@apple.com>
2197
2198         [JSC] Static hash tables should be 100% compile-time constant.
2199         <https://webkit.org/b/148359>
2200
2201         Reviewed by Michael Saboff.
2202
2203         We were dirtying the memory pages containing static hash tables the
2204         first time they were used, when a dynamically allocated index-to-key
2205         table was built and cached in the HashTable struct.
2206
2207         It turns out that this "optimization" was completely useless, since
2208         we've long since decoupled static hash tables from the JSC::VM and
2209         we can get the key for an index via HashTable::values[index].m_key!
2210
2211         We also get rid of VM::keywords which was a little wrapper around
2212         a VM-specific copy of JSC::mainTable. There was nothing VM-specific
2213         about it at all, so clients now use JSC::mainTable directly.
2214
2215         After this change all fooHashTable structs end up in __DATA __const
2216         and no runtime initialization/allocation takes place.
2217
2218         * create_hash_table:
2219         * jsc.cpp:
2220         * parser/Lexer.cpp:
2221         (JSC::isLexerKeyword):
2222         (JSC::Lexer<LChar>::parseIdentifier):
2223         (JSC::Lexer<UChar>::parseIdentifier):
2224         (JSC::Lexer<CharacterType>::parseIdentifierSlowCase):
2225         (JSC::Keywords::Keywords): Deleted.
2226         * parser/Lexer.h:
2227         (JSC::Keywords::isKeyword): Deleted.
2228         (JSC::Keywords::getKeyword): Deleted.
2229         (JSC::Keywords::~Keywords): Deleted.
2230         * runtime/LiteralParser.cpp:
2231         (JSC::LiteralParser<CharType>::tryJSONPParse):
2232         * runtime/Lookup.cpp:
2233         (JSC::HashTable::createTable): Deleted.
2234         (JSC::HashTable::deleteTable): Deleted.
2235         * runtime/Lookup.h:
2236         (JSC::HashTable::entry):
2237         (JSC::HashTable::ConstIterator::key):
2238         (JSC::HashTable::ConstIterator::skipInvalidKeys):
2239         (JSC::HashTable::copy): Deleted.
2240         (JSC::HashTable::initializeIfNeeded): Deleted.
2241         (JSC::HashTable::begin): Deleted.
2242         (JSC::HashTable::end): Deleted.
2243         * runtime/VM.cpp:
2244         (JSC::VM::VM): Deleted.
2245         * runtime/VM.h:
2246         * testRegExp.cpp:
2247
2248 2015-08-21  Commit Queue  <commit-queue@webkit.org>
2249
2250         Unreviewed, rolling out r188792 and r188803.
2251         https://bugs.webkit.org/show_bug.cgi?id=148347
2252
2253         broke lots of tests, ggaren is going to investigate and reland
2254         (Requested by thorton on #webkit).
2255
2256         Reverted changesets:
2257
2258         "Unify code paths for manually deleting all code"
2259         https://bugs.webkit.org/show_bug.cgi?id=148280
2260         http://trac.webkit.org/changeset/188792
2261
2262         "Debugger's VM should never be null"
2263         https://bugs.webkit.org/show_bug.cgi?id=148341
2264         http://trac.webkit.org/changeset/188803
2265
2266 2015-08-21  Sukolsak Sakshuwong  <sukolsak@gmail.com>
2267
2268         Parse control flow statements in WebAssembly
2269         https://bugs.webkit.org/show_bug.cgi?id=148333
2270
2271         Reviewed by Geoffrey Garen.
2272
2273         Parse control flow statements in WebAssembly files generated by pack-asmjs
2274         <https://github.com/WebAssembly/polyfill-prototype-1>.
2275
2276         * wasm/WASMConstants.h:
2277         * wasm/WASMFunctionParser.cpp:
2278         (JSC::WASMFunctionParser::parseStatement):
2279         (JSC::WASMFunctionParser::parseIfStatement):
2280         (JSC::WASMFunctionParser::parseIfElseStatement):
2281         (JSC::WASMFunctionParser::parseWhileStatement):
2282         (JSC::WASMFunctionParser::parseDoStatement):
2283         (JSC::WASMFunctionParser::parseLabelStatement):
2284         (JSC::WASMFunctionParser::parseBreakStatement):
2285         (JSC::WASMFunctionParser::parseBreakLabelStatement):
2286         (JSC::WASMFunctionParser::parseContinueStatement):
2287         (JSC::WASMFunctionParser::parseContinueLabelStatement):
2288         (JSC::WASMFunctionParser::parseSwitchStatement):
2289         * wasm/WASMFunctionParser.h:
2290         (JSC::WASMFunctionParser::WASMFunctionParser):
2291         * wasm/WASMReader.cpp:
2292         (JSC::WASMReader::readCompactInt32):
2293         (JSC::WASMReader::readSwitchCase):
2294         * wasm/WASMReader.h:
2295
2296 2015-08-21  Geoffrey Garen  <ggaren@apple.com>
2297
2298         Debugger's VM should never be null
2299         https://bugs.webkit.org/show_bug.cgi?id=148341
2300
2301         Reviewed by Joseph Pecoraro.
2302
2303         It doesn't make sense for a Debugger's VM to be null, and code related
2304         to maintaining that illusion just caused the Web Inspector to crash on
2305         launch (https://bugs.webkit.org/show_bug.cgi?id=148312). So, let's stop
2306         doing that.
2307
2308         Now, Debugger requires its subclass to provide a never-null VM&.
2309
2310         Also took the opportunity, based on review feedback, to remove some
2311         confusion in the virtual recompileAllJSFunctions hierarchy, by eliminating
2312         the pure virtual in ScriptDebugServer and the unnecessary override in
2313         JSGlobalObjectScriptDebugServer.
2314
2315         * debugger/Debugger.cpp:
2316         (JSC::Debugger::Debugger):
2317         (JSC::Debugger::attach):
2318         (JSC::Debugger::detach):
2319         (JSC::Debugger::isAttached):
2320         (JSC::Debugger::setSteppingMode):
2321         (JSC::Debugger::registerCodeBlock):
2322         (JSC::Debugger::toggleBreakpoint):
2323         (JSC::Debugger::recompileAllJSFunctions):
2324         (JSC::Debugger::setBreakpoint):
2325         (JSC::Debugger::clearBreakpoints):
2326         (JSC::Debugger::clearDebuggerRequests):
2327         (JSC::Debugger::setBreakpointsActivated):
2328         (JSC::Debugger::breakProgram):
2329         (JSC::Debugger::stepOutOfFunction):
2330         (JSC::Debugger::returnEvent):
2331         (JSC::Debugger::didExecuteProgram):
2332         * debugger/Debugger.h:
2333         * inspector/JSGlobalObjectScriptDebugServer.cpp:
2334         (Inspector::JSGlobalObjectScriptDebugServer::JSGlobalObjectScriptDebugServer):
2335         (Inspector::JSGlobalObjectScriptDebugServer::recompileAllJSFunctions):
2336         (Inspector::JSGlobalObjectScriptDebugServer::runEventLoopWhilePaused):
2337         * inspector/ScriptDebugServer.cpp:
2338         (Inspector::ScriptDebugServer::ScriptDebugServer):
2339         * inspector/ScriptDebugServer.h:
2340
2341 2015-08-21  Basile Clement  <basile_clement@apple.com>
2342
2343         Remove unused code relative to allocation sinking
2344         https://bugs.webkit.org/show_bug.cgi?id=148342
2345
2346         Reviewed by Mark Lam.
2347
2348         This removes two things:
2349
2350          - The DFGPromoteHeapAccess.h file which is a relic of the old sinking
2351            phase and is no longer used (it has been subsumed by
2352            ObjectAllocationSinking::promoteLocalHeap)
2353
2354          - Code in the allocation sinking phase for sinking
2355            MaterializeCreateActivation and MaterializeNewObject. Handling those
2356            is no longer necessary since the phase no longer runs in a fixpoint
2357            and thus will never see those nodes, since no other phase creates
2358            them.
2359
2360         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2361         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2362         * JavaScriptCore.xcodeproj/project.pbxproj:
2363         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2364         * dfg/DFGPromoteHeapAccess.h: Removed.
2365
2366 2015-08-21  Geoffrey Garen  <ggaren@apple.com>
2367
2368         Unify code paths for manually deleting all code
2369         https://bugs.webkit.org/show_bug.cgi?id=148280
2370
2371         Reviewed by Saam Barati.
2372
2373         We used to have three paths for manually deleting all code. Now we have
2374         one shared path.
2375
2376         * debugger/Debugger.cpp:
2377         (JSC::Debugger::attach): Notify the debugger of all previous code when
2378         it attaches. We used to do this when recompiling, which was only correct
2379         by accident.
2380
2381         (JSC::Debugger::recompileAllJSFunctions): Switch to the shared path.
2382
2383         * heap/Heap.h:
2384         (JSC::Heap::compiledCode):
2385
2386         * inspector/agents/InspectorRuntimeAgent.cpp:
2387         (Inspector::InspectorRuntimeAgent::getRuntimeTypesForVariablesAtOffsets):
2388         (Inspector::InspectorRuntimeAgent::willDestroyFrontendAndBackend):
2389         (Inspector::InspectorRuntimeAgent::setTypeProfilerEnabledState):
2390         (Inspector::InspectorRuntimeAgent::getBasicBlocks):
2391         (Inspector::TypeRecompiler::visit): Deleted.
2392         (Inspector::TypeRecompiler::operator()): Deleted.
2393         (Inspector::recompileAllJSFunctionsForTypeProfiling): Deleted. Switch
2394         to the shared path.
2395
2396         * runtime/VM.cpp:
2397         (JSC::VM::afterVMExit): Added a helper for scheduling an activity after
2398         VM exit. We can't delete code while it's on the stack, and we can't
2399         delete auxiliary profiling data while profiling code is on the stack,
2400         so in those cases, we schedule the deletion for the next time we exit.
2401
2402         (JSC::VM::deleteAllCode): Use afterVMExit because we might have code
2403         on the stack when debugger, profiler, or watchdog state changes.
2404
2405         * runtime/VM.h:
2406
2407         * runtime/VMEntryScope.cpp:
2408         (JSC::VMEntryScope::VMEntryScope):
2409         (JSC::VMEntryScope::addDidPopListener):
2410         (JSC::VMEntryScope::~VMEntryScope):
2411         (JSC::VMEntryScope::setEntryScopeDidPopListener): Deleted.
2412         * runtime/VMEntryScope.h:
2413         (JSC::VMEntryScope::globalObject): Removed the uniquing feature from
2414         the scope pop listener list because we don't have a client that wants
2415         it, and it's not convenient to use correctly since you can't take
2416         the address of a member function, a lambda, or an std::function. We can
2417         add this feature back if we discover that we want it.
2418
2419 2015-08-21  Sukolsak Sakshuwong  <sukolsak@gmail.com>
2420
2421         Implement WebAssembly function parser
2422         https://bugs.webkit.org/show_bug.cgi?id=147738
2423
2424         Reviewed by Filip Pizlo.
2425
2426         Implement WebAssembly function parser for WebAssembly files produced by pack-asmjs
2427         <https://github.com/WebAssembly/polyfill-prototype-1>. This patch parses only
2428         some instructions on statements and int32 expressions. Parsing of the rest
2429         will be implemented in subsequent patches. The instruction lists in WASMConstants.h
2430         are slightly modified from
2431         <https://github.com/WebAssembly/polyfill-prototype-1/blob/master/src/shared.h>.
2432
2433         * CMakeLists.txt:
2434         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2435         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2436         * JavaScriptCore.xcodeproj/project.pbxproj:
2437         * wasm/WASMConstants.h: Added.
2438         * wasm/WASMFormat.h:
2439         * wasm/WASMFunctionParser.cpp: Added.
2440         (JSC::WASMFunctionParser::checkSyntax):
2441         (JSC::WASMFunctionParser::parseFunction):
2442         (JSC::WASMFunctionParser::parseLocalVariables):
2443         (JSC::WASMFunctionParser::parseStatement):
2444         (JSC::WASMFunctionParser::parseSetLocalStatement):
2445         (JSC::WASMFunctionParser::parseReturnStatement):
2446         (JSC::WASMFunctionParser::parseBlockStatement):
2447         (JSC::WASMFunctionParser::parseExpression):
2448         (JSC::WASMFunctionParser::parseExpressionI32):
2449         (JSC::WASMFunctionParser::parseImmediateExpressionI32):
2450         * wasm/WASMFunctionParser.h: Added.
2451         (JSC::WASMFunctionParser::WASMFunctionParser):
2452         * wasm/WASMFunctionSyntaxChecker.h: Renamed from Source/JavaScriptCore/wasm/WASMMagicNumber.h.
2453         * wasm/WASMModuleParser.cpp:
2454         (JSC::WASMModuleParser::WASMModuleParser):
2455         (JSC::WASMModuleParser::parseFunctionDefinitionSection):
2456         (JSC::WASMModuleParser::parseFunctionDefinition):
2457         * wasm/WASMModuleParser.h:
2458         * wasm/WASMReader.cpp:
2459         (JSC::WASMReader::readType):
2460         (JSC::WASMReader::readExpressionType):
2461         (JSC::WASMReader::readExportFormat):
2462         (JSC::WASMReader::readOpStatement):
2463         (JSC::WASMReader::readOpExpressionI32):
2464         (JSC::WASMReader::readVariableTypes):
2465         (JSC::WASMReader::readOp):
2466         * wasm/WASMReader.h:
2467         (JSC::WASMReader::offset):
2468         (JSC::WASMReader::setOffset):
2469
2470 2015-08-21  Filip Pizlo  <fpizlo@apple.com>
2471
2472         DFG::PutStackSinkingPhase doesn't need to emit KillStack nodes
2473         https://bugs.webkit.org/show_bug.cgi?id=148331
2474
2475         Reviewed by Geoffrey Garen.
2476
2477         PutStackSinkingPhase previously emitted a KillStack node when it sank a PutStack. This
2478         isn't necessary because KillStack is only interesting for OSR exit, and PutStack nodes
2479         that are relevant to OSR will already be preceded by a KillStack/MovHint pair.
2480
2481         * dfg/DFGPutStackSinkingPhase.cpp:
2482
2483 2015-08-21  Filip Pizlo  <fpizlo@apple.com>
2484
2485         DFG::NodeOrigin should have a flag determining if exiting is OK right now
2486         https://bugs.webkit.org/show_bug.cgi?id=148323
2487
2488         Reviewed by Saam Barati.
2489
2490         * dfg/DFGByteCodeParser.cpp:
2491         (JSC::DFG::ByteCodeParser::currentNodeOrigin):
2492         (JSC::DFG::ByteCodeParser::branchData):
2493         * dfg/DFGInsertionSet.h:
2494         (JSC::DFG::InsertionSet::insertConstant):
2495         (JSC::DFG::InsertionSet::insertConstantForUse):
2496         (JSC::DFG::InsertionSet::insertBottomConstantForUse):
2497         * dfg/DFGIntegerCheckCombiningPhase.cpp:
2498         (JSC::DFG::IntegerCheckCombiningPhase::handleBlock):
2499         * dfg/DFGLICMPhase.cpp:
2500         (JSC::DFG::LICMPhase::attemptHoist):
2501         * dfg/DFGNodeOrigin.h:
2502         (JSC::DFG::NodeOrigin::NodeOrigin):
2503         (JSC::DFG::NodeOrigin::isSet):
2504         (JSC::DFG::NodeOrigin::withSemantic):
2505         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2506
2507 2015-08-21  Saam barati  <sbarati@apple.com>
2508
2509         DFG callOperations should not implicitly emit an exception check. At callOperation call sites, we should explicitly emit exception checks
2510         https://bugs.webkit.org/show_bug.cgi?id=147988
2511
2512         Reviewed by Geoffrey Garen.
2513
2514         This is in preparation for the DFG being able to handle exceptions. 
2515         To do this, we need more control over when we emit exception checks.
2516         Specifically, we want to be able to silentFill before emitting an exception check.
2517         This patch does that. This patch also allows us to easily see which
2518         operations do and do not emit exception checks. Finding this information
2519         out before was a pain.
2520
2521         * assembler/AbortReason.h:
2522         * dfg/DFGArrayifySlowPathGenerator.h:
2523         * dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
2524         * dfg/DFGCallCreateDirectArgumentsSlowPathGenerator.h:
2525         * dfg/DFGJITCompiler.h:
2526         (JSC::DFG::JITCompiler::appendCall):
2527         (JSC::DFG::JITCompiler::exceptionCheck):
2528         * dfg/DFGSaneStringGetByValSlowPathGenerator.h:
2529         * dfg/DFGSlowPathGenerator.h:
2530         (JSC::DFG::CallSlowPathGenerator::CallSlowPathGenerator):
2531         (JSC::DFG::CallSlowPathGenerator::tearDown):
2532         (JSC::DFG::CallResultAndNoArgumentsSlowPathGenerator::CallResultAndNoArgumentsSlowPathGenerator):
2533         (JSC::DFG::CallResultAndOneArgumentSlowPathGenerator::CallResultAndOneArgumentSlowPathGenerator):
2534         (JSC::DFG::CallResultAndTwoArgumentsSlowPathGenerator::CallResultAndTwoArgumentsSlowPathGenerator):
2535         (JSC::DFG::CallResultAndThreeArgumentsSlowPathGenerator::CallResultAndThreeArgumentsSlowPathGenerator):
2536         (JSC::DFG::CallResultAndFourArgumentsSlowPathGenerator::CallResultAndFourArgumentsSlowPathGenerator):
2537         (JSC::DFG::CallResultAndFiveArgumentsSlowPathGenerator::CallResultAndFiveArgumentsSlowPathGenerator):
2538         (JSC::DFG::slowPathCall):
2539         * dfg/DFGSpeculativeJIT.cpp:
2540         (JSC::DFG::SpeculativeJIT::compileIn):
2541         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
2542         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
2543         (JSC::DFG::SpeculativeJIT::compileArithRound):
2544         (JSC::DFG::SpeculativeJIT::compileNewFunction):
2545         (JSC::DFG::SpeculativeJIT::compileCreateActivation):
2546         (JSC::DFG::SpeculativeJIT::compileCreateScopedArguments):
2547         (JSC::DFG::SpeculativeJIT::compileCreateClonedArguments):
2548         (JSC::DFG::SpeculativeJIT::compileNotifyWrite):
2549         (JSC::DFG::SpeculativeJIT::compileRegExpExec):
2550         (JSC::DFG::SpeculativeJIT::compileAllocatePropertyStorage):
2551         (JSC::DFG::SpeculativeJIT::compileReallocatePropertyStorage):
2552         (JSC::DFG::SpeculativeJIT::compileToStringOrCallStringConstructorOnCell):
2553         (JSC::DFG::SpeculativeJIT::emitSwitchImm):
2554         (JSC::DFG::SpeculativeJIT::emitSwitchStringOnString):
2555         * dfg/DFGSpeculativeJIT.h:
2556         (JSC::DFG::SpeculativeJIT::callOperation):
2557         (JSC::DFG::SpeculativeJIT::callOperationWithCallFrameRollbackOnException):
2558         (JSC::DFG::SpeculativeJIT::prepareForExternalCall):
2559         (JSC::DFG::SpeculativeJIT::appendCall):
2560         (JSC::DFG::SpeculativeJIT::appendCallWithCallFrameRollbackOnException):
2561         (JSC::DFG::SpeculativeJIT::appendCallWithCallFrameRollbackOnExceptionSetResult):
2562         (JSC::DFG::SpeculativeJIT::appendCallSetResult):
2563         (JSC::DFG::SpeculativeJIT::appendCallWithExceptionCheck): Deleted.
2564         (JSC::DFG::SpeculativeJIT::appendCallWithExceptionCheckSetResult): Deleted.
2565         * dfg/DFGSpeculativeJIT32_64.cpp:
2566         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
2567         (JSC::DFG::CompareAndBoxBooleanSlowPathGenerator::CompareAndBoxBooleanSlowPathGenerator):
2568         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare):
2569         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq):
2570         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq):
2571         (JSC::DFG::SpeculativeJIT::emitCall):
2572         (JSC::DFG::SpeculativeJIT::compileLogicalNot):
2573         (JSC::DFG::SpeculativeJIT::compile):
2574         * dfg/DFGSpeculativeJIT64.cpp:
2575         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
2576         (JSC::DFG::CompareAndBoxBooleanSlowPathGenerator::CompareAndBoxBooleanSlowPathGenerator):
2577         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare):
2578         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq):
2579         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq):
2580         (JSC::DFG::SpeculativeJIT::emitCall):
2581         (JSC::DFG::SpeculativeJIT::compileLogicalNot):
2582         (JSC::DFG::SpeculativeJIT::compile):
2583         * ftl/FTLIntrinsicRepository.h:
2584         * ftl/FTLLowerDFGToLLVM.cpp:
2585         (JSC::FTL::DFG::LowerDFGToLLVM::callCheck):
2586         * jit/AssemblyHelpers.cpp:
2587         (JSC::AssemblyHelpers::jitAssertArgumentCountSane):
2588         (JSC::AssemblyHelpers::jitAssertNoException):
2589         (JSC::AssemblyHelpers::callExceptionFuzz):
2590         (JSC::AssemblyHelpers::emitExceptionCheck):
2591         * jit/AssemblyHelpers.h:
2592         (JSC::AssemblyHelpers::jitAssertIsInt32):
2593         (JSC::AssemblyHelpers::jitAssertIsJSInt32):
2594         (JSC::AssemblyHelpers::jitAssertIsNull):
2595         (JSC::AssemblyHelpers::jitAssertTagsInPlace):
2596         (JSC::AssemblyHelpers::jitAssertArgumentCountSane):
2597         (JSC::AssemblyHelpers::jitAssertNoException):
2598         * jit/JITOperations.cpp:
2599         * jit/JITOperations.h:
2600         * runtime/VM.h:
2601         (JSC::VM::scratchBufferForSize):
2602         (JSC::VM::exceptionFuzzingBuffer):
2603
2604 2015-08-21  Geoffrey Garen  <ggaren@apple.com>
2605
2606         REGRESSION (r188714): RELEASE_ASSERT in JSC::Heap::incrementDeferralDepth() opening Web Inspector on daringfireball.net
2607         https://bugs.webkit.org/show_bug.cgi?id=148312
2608
2609         Reviewed by Mark Lam.
2610
2611         * debugger/Debugger.cpp:
2612         (JSC::Debugger::recompileAllJSFunctions): Use our vm argument instead of
2613         m_vm because sometimes they are different and m_vm is null. (This behavior
2614         is very strange, and we should probably eliminate it -- but we need a 
2615         fix for this serious regression right now.)
2616
2617 2015-08-20  Yusuke Suzuki  <utatane.tea@gmail.com>
2618
2619         [ES6] prototyping module loader in JSC shell
2620         https://bugs.webkit.org/show_bug.cgi?id=147876
2621
2622         Reviewed by Saam Barati.
2623
2624         This patch implements ES6 Module Loader part. The implementation is based on
2625         the latest draft[1, 2]. The naive implementation poses several problems.
2626         This patch attempts to solve the spec issues and proposes the fix[3, 4, 5].
2627
2628         We construct the JSC internal module loader based on the ES6 Promises.
2629         The chain of the promises represents the dependency graph of the modules and
2630         it automatically enables asynchronous module fetching.
2631         To leverage the Promises internally, we use the InternalPromise landed in r188681.
2632
2633         The loader has several platform-dependent hooks. The platform can implement
2634         these hooks to provide the functionality missing in the module loaders, like
2635         "how to fetch the resources". The method table of the JSGlobalObject is extended
2636         to accept these hooks from the platform.
2637
2638         This patch focus on the loading part. So we don't create the module environment
2639         and don't link the modules yet.
2640
2641         To test the current module progress easily, we add the `-m` option to the JSC shell.
2642         When this option is specified, we load the given script as the module. And to use
2643         the module loading inside the JSC shell, we added the simple loader hook for fetching.
2644         It fetches the module content from the file system.
2645
2646         And to use the ES6 Map in the Loader implementation, we added @get and @set methods to the Map.
2647         But it conflicts with the existing `getPrivateName` method. Rename it to `lookUpPrivateName`.
2648
2649         [1]: https://whatwg.github.io/loader/
2650         [2]: https://github.com/whatwg/loader/commit/214c7a6625b445bdf411c39984f36f01139a24be
2651         [3]: https://github.com/whatwg/loader/pull/66
2652         [4]: https://github.com/whatwg/loader/pull/67
2653         [5]: https://github.com/whatwg/loader/issues/68
2654         [6]: https://bugs.webkit.org/show_bug.cgi?id=148136
2655
2656         * CMakeLists.txt:
2657         * DerivedSources.make:
2658         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2659         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2660         * JavaScriptCore.xcodeproj/project.pbxproj:
2661         * builtins/BuiltinNames.h:
2662         (JSC::BuiltinNames::lookUpPrivateName):
2663         (JSC::BuiltinNames::lookUpPublicName):
2664         (JSC::BuiltinNames::getPrivateName): Deleted.
2665         (JSC::BuiltinNames::getPublicName): Deleted.
2666         * builtins/ModuleLoaderObject.js: Added.
2667         (setStateToMax):
2668         (newRegistryEntry):
2669         (forceFulfillPromise):
2670         (fulfillFetch):
2671         (fulfillTranslate):
2672         (fulfillInstantiate):
2673         (instantiation):
2674         (requestFetch):
2675         (requestTranslate):
2676         (requestInstantiate):
2677         (requestResolveDependencies.resolveDependenciesPromise.this.requestInstantiate.then.):
2678         (requestResolveDependencies.resolveDependenciesPromise.this.requestInstantiate.then):
2679         (requestResolveDependencies):
2680         (requestInstantiateAll):
2681         (provide):
2682         * jsc.cpp:
2683         (stringFromUTF):
2684         (jscSource):
2685         (GlobalObject::moduleLoaderFetch):
2686         (functionCheckModuleSyntax):
2687         (dumpException):
2688         (runWithScripts):
2689         (printUsageStatement):
2690         (CommandLine::parseArguments):
2691         (jscmain):
2692         (CommandLine::CommandLine): Deleted.
2693         * parser/Lexer.cpp:
2694         (JSC::Lexer<LChar>::parseIdentifier):
2695         (JSC::Lexer<UChar>::parseIdentifier):
2696         * parser/ModuleAnalyzer.cpp:
2697         (JSC::ModuleAnalyzer::ModuleAnalyzer):
2698         (JSC::ModuleAnalyzer::exportVariable):
2699         (JSC::ModuleAnalyzer::analyze):
2700         * parser/ModuleAnalyzer.h:
2701         (JSC::ModuleAnalyzer::moduleRecord):
2702         * parser/ModuleRecord.cpp:
2703         (JSC::printableName): Deleted.
2704         (JSC::ModuleRecord::dump): Deleted.
2705         * parser/ModuleRecord.h:
2706         (JSC::ModuleRecord::ImportEntry::isNamespace): Deleted.
2707         (JSC::ModuleRecord::create): Deleted.
2708         (JSC::ModuleRecord::appendRequestedModule): Deleted.
2709         (JSC::ModuleRecord::addImportEntry): Deleted.
2710         (JSC::ModuleRecord::addExportEntry): Deleted.
2711         (JSC::ModuleRecord::addStarExportEntry): Deleted.
2712         * parser/Nodes.h:
2713         * parser/NodesAnalyzeModule.cpp:
2714         (JSC::ImportDeclarationNode::analyzeModule):
2715         (JSC::ExportAllDeclarationNode::analyzeModule):
2716         (JSC::ExportNamedDeclarationNode::analyzeModule):
2717         * runtime/CommonIdentifiers.cpp:
2718         (JSC::CommonIdentifiers::lookUpPrivateName):
2719         (JSC::CommonIdentifiers::lookUpPublicName):
2720         (JSC::CommonIdentifiers::getPrivateName): Deleted.
2721         (JSC::CommonIdentifiers::getPublicName): Deleted.
2722         * runtime/CommonIdentifiers.h:
2723         * runtime/Completion.cpp:
2724         (JSC::checkModuleSyntax):
2725         (JSC::evaluateModule):
2726         * runtime/Completion.h:
2727         * runtime/ExceptionHelpers.cpp:
2728         (JSC::createUndefinedVariableError):
2729         * runtime/Identifier.h:
2730         * runtime/JSGlobalObject.cpp:
2731         (JSC::JSGlobalObject::init):
2732         (JSC::JSGlobalObject::visitChildren):
2733         * runtime/JSGlobalObject.h:
2734         (JSC::JSGlobalObject::moduleLoader):
2735         (JSC::JSGlobalObject::moduleRecordStructure):
2736         * runtime/JSModuleRecord.cpp: Renamed from Source/JavaScriptCore/parser/ModuleRecord.cpp.
2737         (JSC::JSModuleRecord::destroy):
2738         (JSC::JSModuleRecord::finishCreation):
2739         (JSC::printableName):
2740         (JSC::JSModuleRecord::dump):
2741         * runtime/JSModuleRecord.h: Renamed from Source/JavaScriptCore/parser/ModuleRecord.h.
2742         (JSC::JSModuleRecord::ImportEntry::isNamespace):
2743         (JSC::JSModuleRecord::createStructure):
2744         (JSC::JSModuleRecord::create):
2745         (JSC::JSModuleRecord::requestedModules):
2746         (JSC::JSModuleRecord::JSModuleRecord):
2747         (JSC::JSModuleRecord::appendRequestedModule):
2748         (JSC::JSModuleRecord::addImportEntry):
2749         (JSC::JSModuleRecord::addExportEntry):
2750         (JSC::JSModuleRecord::addStarExportEntry):
2751         * runtime/MapPrototype.cpp:
2752         (JSC::MapPrototype::finishCreation):
2753         * runtime/ModuleLoaderObject.cpp: Added.
2754         (JSC::ModuleLoaderObject::ModuleLoaderObject):
2755         (JSC::ModuleLoaderObject::finishCreation):
2756         (JSC::ModuleLoaderObject::getOwnPropertySlot):
2757         (JSC::printableModuleKey):
2758         (JSC::ModuleLoaderObject::provide):
2759         (JSC::ModuleLoaderObject::requestInstantiateAll):
2760         (JSC::ModuleLoaderObject::resolve):
2761         (JSC::ModuleLoaderObject::fetch):
2762         (JSC::ModuleLoaderObject::translate):
2763         (JSC::ModuleLoaderObject::instantiate):
2764         (JSC::moduleLoaderObjectParseModule):
2765         (JSC::moduleLoaderObjectRequestedModules):
2766         (JSC::moduleLoaderObjectResolve):
2767         (JSC::moduleLoaderObjectFetch):
2768         (JSC::moduleLoaderObjectTranslate):
2769         (JSC::moduleLoaderObjectInstantiate):
2770         * runtime/ModuleLoaderObject.h: Added.
2771         (JSC::ModuleLoaderObject::create):
2772         (JSC::ModuleLoaderObject::createStructure):
2773         * runtime/Options.h:
2774
2775 2015-08-20  Filip Pizlo  <fpizlo@apple.com>
2776
2777         DFG should have a KnownBooleanUse for cases where we are required to know that the child is a boolean and it's not OK to speculate
2778         https://bugs.webkit.org/show_bug.cgi?id=148286
2779
2780         Reviewed by Benjamin Poulain.
2781
2782         This enables us to ensure that the Branch or LogicalNot after an effectful CompareXYZ can
2783         be marked as !mayExit(). I need that for https://bugs.webkit.org/show_bug.cgi?id=145204.
2784
2785         * dfg/DFGFixupPhase.cpp:
2786         (JSC::DFG::FixupPhase::fixupNode):
2787         (JSC::DFG::FixupPhase::observeUseKindOnNode):
2788         * dfg/DFGSafeToExecute.h:
2789         (JSC::DFG::SafeToExecuteEdge::operator()):
2790         * dfg/DFGSpeculativeJIT.cpp:
2791         (JSC::DFG::SpeculativeJIT::speculate):
2792         * dfg/DFGSpeculativeJIT.h:
2793         (JSC::DFG::SpeculateBooleanOperand::SpeculateBooleanOperand):
2794         * dfg/DFGSpeculativeJIT32_64.cpp:
2795         (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
2796         (JSC::DFG::SpeculativeJIT::compileLogicalNot):
2797         (JSC::DFG::SpeculativeJIT::emitBranch):
2798         * dfg/DFGSpeculativeJIT64.cpp:
2799         (JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
2800         (JSC::DFG::SpeculativeJIT::compileLogicalNot):
2801         (JSC::DFG::SpeculativeJIT::emitBranch):
2802         * dfg/DFGUseKind.cpp:
2803         (WTF::printInternal):
2804         * dfg/DFGUseKind.h:
2805         (JSC::DFG::typeFilterFor):
2806         (JSC::DFG::shouldNotHaveTypeCheck):
2807         * ftl/FTLCapabilities.cpp:
2808         (JSC::FTL::canCompile):
2809         * ftl/FTLLowerDFGToLLVM.cpp:
2810         (JSC::FTL::DFG::LowerDFGToLLVM::boolify):
2811         (JSC::FTL::DFG::LowerDFGToLLVM::lowBoolean):
2812
2813 2015-08-20  Filip Pizlo  <fpizlo@apple.com>
2814
2815         Overflow check elimination fails for a simple test case
2816         https://bugs.webkit.org/show_bug.cgi?id=147387
2817
2818         Reviewed by Benjamin Poulain.
2819
2820         Overflow check elimination was having issues when things got constant-folded, because whereas an
2821         Add or LessThan operation teaches us about relationships between the things being added or
2822         compared, we don't do that when we see a JSConstant. We don't create a relationship between every
2823         JSConstant and every other JSConstant. So, if we constant-fold an Add, we forget the relationships
2824         that it would have had with its inputs.
2825
2826         One solution would be to have every JSConstant create a relationship with every other JSConstant.
2827         This is dangerous, since it would create O(n^2) explosion of relationships.
2828
2829         Instead, this patch teaches filtration and merging how to behave "as if" there were inter-constant
2830         relationships. Normally those operations only work on two relationships involving the same node
2831         pair. But now, if we have @x op @c and @x op @d, where @c and @d are different nodes but both are
2832         constants, we will do merging or filtering by grokking the constant values.
2833
2834         This speeds up lots of tests in JSRegress, because it enables overflow check elimination on things
2835         like:
2836
2837         for (var i = 0; i < 100; ++i)
2838
2839         Previously, the fact that this was all constants would throw off the analysis because the analysis
2840         wouldn't "know" that 0 < 100.
2841
2842         * dfg/DFGIntegerRangeOptimizationPhase.cpp:
2843
2844 2015-08-20  Geoffrey Garen  <ggaren@apple.com>
2845
2846         forEachCodeBlock should wait for all CodeBlocks automatically
2847         https://bugs.webkit.org/show_bug.cgi?id=148255
2848
2849         Add back a line of code I deleted by accident in my last patch due to
2850         incorrect merge.
2851
2852         Unreviewed.
2853
2854         * runtime/VM.cpp:
2855         (JSC::VM::deleteAllCode):
2856
2857 2015-08-20  Geoffrey Garen  <ggaren@apple.com>
2858
2859         forEachCodeBlock should wait for all CodeBlocks automatically
2860         https://bugs.webkit.org/show_bug.cgi?id=148255
2861
2862         Reviewed by Saam Barati.
2863
2864         Previously, all clients needed to wait manually before calling
2865         forEachCodeBlock. That's easy to get wrong, and at least one place
2866         got it wrong. Let's do this automatically instead.
2867
2868         * debugger/Debugger.cpp:
2869         (JSC::Debugger::Debugger):
2870         (JSC::Debugger::setSteppingMode):
2871         (JSC::Debugger::toggleBreakpoint): No need to wait manually;
2872         forEachCodeBlock will do it automatically now.
2873
2874         (JSC::Debugger::recompileAllJSFunctions): We still need to wait manually
2875         here because this is an iteration of the heap, which does not wait
2876         automatically. Use the new helper function for waiting.
2877
2878         (JSC::Debugger::clearBreakpoints):
2879         (JSC::Debugger::clearDebuggerRequests):
2880         (JSC::Debugger::setBreakpointsActivated):
2881         (JSC::Debugger::forEachCodeBlock): Deleted. No need to wait manually.
2882
2883         * debugger/Debugger.h:
2884
2885         * dfg/DFGWorklist.cpp:
2886         (JSC::DFG::completeAllPlansForVM):
2887         * dfg/DFGWorklist.h:
2888         (JSC::DFG::completeAllPlansForVM): Added a helper function that replaces
2889         vm.prepareToDeleteCode. This new function is clearer because we need
2890         to call it sometimes even if we are not going to delete code.
2891
2892         * heap/HeapInlines.h:
2893         (JSC::Heap::forEachCodeBlock): Moved.
2894
2895         * inspector/agents/InspectorRuntimeAgent.cpp:
2896         (Inspector::recompileAllJSFunctionsForTypeProfiling): Use the new helper
2897         function.
2898
2899         * runtime/JSCInlines.h:
2900         (JSC::Heap::forEachCodeBlock): Do the waiting automatically.
2901
2902         * runtime/VM.cpp:
2903         (JSC::VM::stopSampling):
2904         (JSC::VM::deleteAllCode):
2905         (JSC::VM::setEnabledProfiler):
2906         (JSC::VM::prepareToDeleteCode): Deleted.
2907         * runtime/VM.h: No need to wait manually.
2908
2909 2015-08-20  Commit Queue  <commit-queue@webkit.org>
2910
2911         Unreviewed, rolling out r188675.
2912         https://bugs.webkit.org/show_bug.cgi?id=148244
2913
2914         "caused a 17% Mac PLT regression" (Requested by ggaren on
2915         #webkit).
2916
2917         Reverted changeset:
2918
2919         "clearCode() should clear code"
2920         https://bugs.webkit.org/show_bug.cgi?id=148203
2921         http://trac.webkit.org/changeset/188675
2922
2923 2015-08-11  Yusuke Suzuki  <utatane.tea@gmail.com>
2924
2925         Introduce put_by_id like IC into put_by_val when the given name is String or Symbol
2926         https://bugs.webkit.org/show_bug.cgi?id=147760
2927
2928         Reviewed by Filip Pizlo.
2929
2930         This patch adds put_by_id IC to put_by_val by caching the one candidate id,
2931         it is the same thing to the get_by_val IC extension.
2932         It will encourage the use of ES6 Symbols and ES6 computed properties in the object literals.
2933
2934         In this patch, we leverage the existing CheckIdent and PutById / PutByVal in DFG,
2935         so this patch does not change FTL because the above operations are already supported in FTL.
2936
2937         And this patch also includes refactoring to leverage byValInfo->slowPathCount in the cached Id path.
2938
2939         Performance results report there's no regression in the existing tests. And in the synthetic
2940         benchmarks created by modifying put-by-id to put-by-val, we can see significant performance
2941         improvements up to 13.9x.
2942
2943         * bytecode/PutByIdStatus.cpp:
2944         (JSC::PutByIdStatus::computeForStubInfo):
2945         * bytecode/PutByIdStatus.h:
2946         * dfg/DFGByteCodeParser.cpp:
2947         (JSC::DFG::ByteCodeParser::parseBlock):
2948         * jit/JIT.h:
2949         (JSC::JIT::compilePutByValWithCachedId):
2950         * jit/JITOperations.cpp:
2951         (JSC::getByVal):
2952         (JSC::tryGetByValOptimize):
2953         * jit/JITOperations.h:
2954         * jit/JITPropertyAccess.cpp:
2955         (JSC::JIT::emitGetByValWithCachedId):
2956         (JSC::JIT::emit_op_put_by_val):
2957         (JSC::JIT::emitPutByValWithCachedId):
2958         (JSC::JIT::emitSlow_op_put_by_val):
2959         (JSC::JIT::emitIdentifierCheck):
2960         (JSC::JIT::privateCompilePutByValWithCachedId):
2961         * jit/JITPropertyAccess32_64.cpp:
2962         (JSC::JIT::emitGetByValWithCachedId):
2963         (JSC::JIT::emit_op_put_by_val):
2964         (JSC::JIT::emitPutByValWithCachedId):
2965         (JSC::JIT::emitSlow_op_put_by_val):
2966         * tests/stress/put-by-val-with-string-break.js: Added.
2967         (shouldBe):
2968         (assign):
2969         * tests/stress/put-by-val-with-string-generated.js: Added.
2970         (shouldBe):
2971         (gen1):
2972         (gen2):
2973         (assign):
2974         * tests/stress/put-by-val-with-string-generic.js: Added.
2975         (shouldBe):
2976         (assign):
2977         * tests/stress/put-by-val-with-symbol-break.js: Added.
2978         (shouldBe):
2979         (assign):
2980         * tests/stress/put-by-val-with-symbol-generic.js: Added.
2981         (shouldBe):
2982         (assign):
2983
2984 2015-08-20  Alex Christensen  <achristensen@webkit.org>
2985
2986         Clean up CMake build after r188673
2987         https://bugs.webkit.org/show_bug.cgi?id=148234
2988
2989         Reviewed by Tim Horton.
2990
2991         * shell/PlatformWin.cmake:
2992         Define WIN_CAIRO so the WinCairo jsc.exe can find the correct dlls.
2993
2994 2015-08-20  Mark Lam  <mark.lam@apple.com>
2995
2996         A watchdog tests is failing on Windows.
2997         https://bugs.webkit.org/show_bug.cgi?id=148228
2998
2999         Reviewed by Brent Fulgham.
3000
3001         The test just needed a little more time because Windows' timer resolution is low.
3002         After increasing the test deadlines, the test started passing.
3003
3004         * API/tests/ExecutionTimeLimitTest.cpp:
3005         (testExecutionTimeLimit):
3006
3007 2015-08-20  Mark Lam  <mark.lam@apple.com>
3008
3009         Fixed some warnings on Windows.
3010         https://bugs.webkit.org/show_bug.cgi?id=148224
3011
3012         Reviewed by Brent Fulgham.
3013
3014         The Windows build was complaining that function params were hiding a global variable.
3015         Since the function params were unused, I resolved this by removing the param names.
3016
3017         * API/tests/ExecutionTimeLimitTest.cpp:
3018         (currentCPUTimeAsJSFunctionCallback):
3019         (shouldTerminateCallback):
3020         (cancelTerminateCallback):
3021         (extendTerminateCallback):
3022
3023 2015-08-19  Yusuke Suzuki  <utatane.tea@gmail.com>
3024
3025         Add InternalPromise to use Promises safely in the internals
3026         https://bugs.webkit.org/show_bug.cgi?id=148136
3027
3028         Reviewed by Saam Barati.
3029
3030         This patch implements InternalPromise.
3031         It is completely different instance set (constructor, prototype, instance)
3032         but it has the same feature to the Promise.
3033
3034         In the Promise operations, when resolving the promise with the returned promise
3035         from the fulfill handler, we need to look up "then" method.
3036
3037         e.g.
3038             var p3 = p1.then(function handler(...) {
3039                 return p2;
3040             });
3041
3042         When handler is executed, we retrieve the returned `p2` promise. And to resolve
3043         the returned promise by "then" method (that is `p3`), we construct the chain by executing
3044         `p2.then(resolving function for p3)`. So if the user modify the Promise.prototype.then,
3045         we can observe the internal operations.
3046
3047         By using InternalPromise, we completely hide InternalPromise.prototype from the users.
3048         It allows JSC to use Promises internally; even if the user modify / override
3049         the Promise.prototype.then function, it does not effect on InternalPromise.
3050
3051         One limitation is that the implementation need to take care not to leak the InternalPromise instance
3052         to the user space.
3053
3054         * CMakeLists.txt:
3055         * DerivedSources.make:
3056         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
3057         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
3058         * JavaScriptCore.xcodeproj/project.pbxproj:
3059         * builtins/InternalPromiseConstructor.js: Added.
3060         (internalAll.newResolveElement):
3061         (internalAll):
3062         * builtins/Operations.Promise.js:
3063         (newPromiseDeferred): Deleted.
3064         * builtins/PromiseConstructor.js:
3065         (privateAll.newResolveElement): Deleted.
3066         (privateAll): Deleted.
3067         * runtime/CommonIdentifiers.h:
3068         * runtime/JSGlobalObject.cpp:
3069         (JSC::JSGlobalObject::init):
3070         (JSC::JSGlobalObject::visitChildren):
3071         * runtime/JSGlobalObject.h:
3072         (JSC::JSGlobalObject::promiseConstructor):
3073         (JSC::JSGlobalObject::internalPromiseConstructor):
3074         (JSC::JSGlobalObject::newPromiseCapabilityFunction):
3075         (JSC::JSGlobalObject::newPromiseDeferredFunction): Deleted.
3076         * runtime/JSInternalPromise.cpp: Copied from Source/JavaScriptCore/runtime/JSPromisePrototype.h.
3077         (JSC::JSInternalPromise::create):
3078         (JSC::JSInternalPromise::createStructure):
3079         (JSC::JSInternalPromise::JSInternalPromise):
3080         * runtime/JSInternalPromise.h: Copied from Source/JavaScriptCore/runtime/JSPromise.h.
3081         * runtime/JSInternalPromiseConstructor.cpp: Added.
3082         (JSC::JSInternalPromiseConstructor::create):
3083         (JSC::JSInternalPromiseConstructor::createStructure):
3084         (JSC::JSInternalPromiseConstructor::JSInternalPromiseConstructor):
3085         (JSC::constructPromise):
3086         (JSC::JSInternalPromiseConstructor::getConstructData):
3087         (JSC::JSInternalPromiseConstructor::getCallData):
3088         (JSC::JSInternalPromiseConstructor::getOwnPropertySlot):
3089         * runtime/JSInternalPromiseConstructor.h: Copied from Source/JavaScriptCore/runtime/JSPromiseConstructor.h.
3090         * runtime/JSInternalPromiseDeferred.cpp: Added.
3091         (JSC::JSInternalPromiseDeferred::create):
3092         (JSC::JSInternalPromiseDeferred::JSInternalPromiseDeferred):
3093         (JSC::JSInternalPromiseDeferred::promise):
3094         * runtime/JSInternalPromiseDeferred.h: Copied from Source/JavaScriptCore/runtime/JSPromisePrototype.h.
3095         * runtime/JSInternalPromisePrototype.cpp: Copied from Source/JavaScriptCore/runtime/JSPromisePrototype.cpp.
3096         (JSC::JSInternalPromisePrototype::create):
3097         (JSC::JSInternalPromisePrototype::createStructure):
3098         (JSC::JSInternalPromisePrototype::JSInternalPromisePrototype):
3099         * runtime/JSInternalPromisePrototype.h: Copied from Source/JavaScriptCore/runtime/JSPromise.h.
3100         * runtime/JSPromise.cpp:
3101         (JSC::JSPromise::create):
3102         (JSC::JSPromise::JSPromise):
3103         (JSC::JSPromise::initialize):
3104         * runtime/JSPromise.h:
3105         * runtime/JSPromiseConstructor.cpp:
3106         (JSC::JSPromiseConstructor::JSPromiseConstructor):
3107         (JSC::constructPromise):
3108         (JSC::JSPromiseConstructor::getOwnPropertySlot):
3109         (JSC::JSPromiseConstructor::finishCreation): Deleted.
3110         * runtime/JSPromiseConstructor.h:
3111         * runtime/JSPromiseDeferred.cpp:
3112         (JSC::newPromiseCapability):
3113         (JSC::JSPromiseDeferred::create):
3114         (JSC::JSPromiseDeferred::JSPromiseDeferred):
3115         * runtime/JSPromiseDeferred.h:
3116         * runtime/JSPromisePrototype.cpp:
3117         (JSC::JSPromisePrototype::getOwnPropertySlot):
3118         * runtime/JSPromisePrototype.h:
3119         * runtime/VM.cpp:
3120         (JSC::VM::VM):
3121         * runtime/VM.h:
3122
3123 2015-08-19  Filip Pizlo  <fpizlo@apple.com>
3124
3125         Remove WTF::SpinLock
3126         https://bugs.webkit.org/show_bug.cgi?id=148208
3127
3128         Reviewed by Geoffrey Garen.
3129
3130         Remove the one remaining use of SpinLock.
3131
3132         * API/JSValue.mm:
3133         (handerForStructTag):
3134
3135 2015-08-19  Geoffrey Garen  <ggaren@apple.com>
3136
3137         clearCode() should clear code
3138         https://bugs.webkit.org/show_bug.cgi?id=148203
3139
3140         Reviewed by Saam Barati.
3141
3142         Clearing code used to require two steps: clearCode() and
3143         clearUnlinkedCodeForRecompilation(). Unsurprisingly, clients sometimes
3144         did one or the other or both without much rhyme or reason.
3145
3146         This patch simplifies things by merging both functions into clearCode().
3147
3148         * bytecode/UnlinkedFunctionExecutable.h:
3149         * debugger/Debugger.cpp:
3150         * heap/Heap.cpp:
3151         (JSC::Heap::deleteAllCompiledCode):
3152         (JSC::Heap::clearUnmarkedExecutables):
3153         (JSC::Heap::deleteAllUnlinkedFunctionCode): Deleted. No need for this
3154         function anymore since it was only used by clients who already called
3155         clearCode() (and it would be terribly wrong to use without doing both.)
3156
3157         * heap/Heap.h:
3158         (JSC::Heap::sizeAfterLastFullCollection):
3159         * inspector/agents/InspectorRuntimeAgent.cpp:
3160         (Inspector::TypeRecompiler::visit):
3161         (Inspector::TypeRecompiler::operator()):
3162         * runtime/Executable.cpp:
3163         (JSC::FunctionExecutable::visitChildren):
3164         (JSC::FunctionExecutable::clearCode):
3165         (JSC::FunctionExecutable::clearUnlinkedCodeForRecompilation): Deleted.
3166         * runtime/Executable.h:
3167         * runtime/VM.cpp:
3168         (JSC::VM::deleteAllCode):
3169
3170 2015-08-19  Alex Christensen  <achristensen@webkit.org>
3171
3172         CMake Windows build should not include files directly from other Source directories
3173         https://bugs.webkit.org/show_bug.cgi?id=148198
3174
3175         Reviewed by Brent Fulgham.
3176
3177         * CMakeLists.txt:
3178         JavaScriptCore_FORWARDING_HEADERS_FILES is no longer necessary because all the headers
3179         that used to be in it are now in JavaScriptCore_FORWARDING_HEADERS_DIRECTORIES
3180         * PlatformEfl.cmake:
3181         * PlatformGTK.cmake:
3182         * PlatformMac.cmake:
3183         * PlatformWin.cmake:
3184
3185 2015-08-19  Eric Carlson  <eric.carlson@apple.com>
3186
3187         Remove ENABLE_WEBVTT_REGIONS
3188         https://bugs.webkit.org/show_bug.cgi?id=148184
3189
3190         Reviewed by Jer Noble.
3191
3192         * Configurations/FeatureDefines.xcconfig: Remove ENABLE_WEBVTT_REGIONS.
3193
3194 2015-08-19  Joseph Pecoraro  <pecoraro@apple.com>
3195
3196         Web Inspector: Unexpected node preview format for an element with newlines in className attribute
3197         https://bugs.webkit.org/show_bug.cgi?id=148192
3198
3199         Reviewed by Brian Burg.
3200
3201         * inspector/InjectedScriptSource.js:
3202         (InjectedScript.prototype._nodePreview):
3203         Replace whitespace blocks with single spaces to produce a simpler class string for previews.
3204
3205 2015-08-19  Mark Lam  <mark.lam@apple.com>
3206
3207         Add support for CheckWatchdogTimer as slow path in DFG and FTL.
3208         https://bugs.webkit.org/show_bug.cgi?id=147968
3209
3210         Reviewed by Michael Saboff.
3211
3212         Re-implement the DFG's CheckWatchdogTimer as a slow path instead of a speculation
3213         check.  Since the watchdog timer can fire spuriously, this allows the code to
3214         stay optimized if all we have are spurious fires.
3215
3216         Implement the equivalent slow path for CheckWatchdogTimer in the FTL. 
3217
3218         The watchdog tests in ExecutionTimeLimitTest.cpp has already been updated in
3219         https://bugs.webkit.org/show_bug.cgi?id=148125 to test for the FTL's watchdog
3220         implementation.
3221
3222         * dfg/DFGSpeculativeJIT32_64.cpp:
3223         (JSC::DFG::SpeculativeJIT::compile):
3224         * dfg/DFGSpeculativeJIT64.cpp:
3225         (JSC::DFG::SpeculativeJIT::compile):
3226         * ftl/FTLCapabilities.cpp:
3227         (JSC::FTL::canCompile):
3228         * ftl/FTLLowerDFGToLLVM.cpp:
3229         (JSC::FTL::DFG::LowerDFGToLLVM::compileNode):
3230         (JSC::FTL::DFG::LowerDFGToLLVM::compileMaterializeCreateActivation):
3231         (JSC::FTL::DFG::LowerDFGToLLVM::compileCheckWatchdogTimer):
3232         (JSC::FTL::DFG::LowerDFGToLLVM::isInlinableSize):
3233
3234         * jit/JIT.h:
3235         * jit/JITInlines.h:
3236         (JSC::JIT::callOperation):
3237         * jit/JITOperations.cpp:
3238         * jit/JITOperations.h:
3239         - Changed operationHandleWatchdogTimer() to return an unused nullptr.  This
3240           allows me to reuse the existing DFG slow path generator mechanism.  I didn't
3241           think that operationHandleWatchdogTimer() was worth introducing a whole new set
3242           of machinery just so we can have a slow path that returns void.
3243
3244 2015-08-19  Mark Lam  <mark.lam@apple.com>
3245
3246         Add ability to save and restore JSC options.
3247         https://bugs.webkit.org/show_bug.cgi?id=148125
3248
3249         Reviewed by Saam Barati.
3250
3251         * API/tests/ExecutionTimeLimitTest.cpp:
3252         (testExecutionTimeLimit):
3253         - Employ the new options getter/setter to run watchdog tests for each of the
3254           execution engine tiers.
3255         - Also altered the test scripts to be in a function instead of global code.
3256           This is one of 2 changes needed to give them an opportunity to be FTL compiled.
3257           The other is to add support for compiling CheckWatchdogTimer in the FTL (which
3258           will be addressed in a separate patch).
3259
3260         * jsc.cpp:
3261         (CommandLine::parseArguments):
3262         * runtime/Options.cpp:
3263         (JSC::parse):
3264         - Add the ability to clear a string option with a nullptr value.
3265           This is needed to restore a default string option value which may be null.
3266
3267         (JSC::OptionRange::init):
3268         - Add the ability to clear a range option with a null value.
3269           This is needed to restore a default range option value which may be null.
3270
3271         (JSC::Options::initialize):
3272         (JSC::Options::dumpOptionsIfNeeded):
3273         - Factor code to dump options out to dumpOptionsIfNeeded() since we will need
3274           that logic elsewhere.
3275
3276         (JSC::Options::setOptions):
3277         - Parse an options string and set each of the specified options.
3278
3279         (JSC::Options::dumpAllOptions):
3280         (JSC::Options::dumpAllOptionsInALine):
3281         (JSC::Options::dumpOption):
3282         (JSC::Option::dump):
3283         - Refactored so that the underlying dumper dumps to a StringBuilder instead of
3284           stderr.  This lets us reuse this code to serialize all the options into a
3285           single string for dumpAllOptionsInALine().
3286
3287         * runtime/Options.h:
3288         (JSC::OptionRange::rangeString):
3289
3290 2015-08-18  Filip Pizlo  <fpizlo@apple.com>
3291
3292         Replace all uses of std::mutex/std::condition_variable with WTF::Lock/WTF::Condition
3293         https://bugs.webkit.org/show_bug.cgi?id=148140
3294
3295         Reviewed by Geoffrey Garen.
3296
3297         * inspector/remote/RemoteInspector.h:
3298         * inspector/remote/RemoteInspector.mm:
3299         (Inspector::RemoteInspector::registerDebuggable):
3300         (Inspector::RemoteInspector::unregisterDebuggable):
3301         (Inspector::RemoteInspector::updateDebuggable):
3302         (Inspector::RemoteInspector::updateDebuggableAutomaticInspectCandidate):
3303         (Inspector::RemoteInspector::sendMessageToRemoteFrontend):
3304         (Inspector::RemoteInspector::setupFailed):
3305         (Inspector::RemoteInspector::setupCompleted):
3306         (Inspector::RemoteInspector::start):
3307         (Inspector::RemoteInspector::stop):
3308         (Inspector::RemoteInspector::setupXPCConnectionIfNeeded):
3309         (Inspector::RemoteInspector::setParentProcessInformation):
3310         (Inspector::RemoteInspector::xpcConnectionReceivedMessage):
3311         (Inspector::RemoteInspector::xpcConnectionFailed):
3312         (Inspector::RemoteInspector::pushListingSoon):
3313         (Inspector::RemoteInspector::receivedIndicateMessage):
3314         (Inspector::RemoteInspector::receivedProxyApplicationSetupMessage):
3315         * inspector/remote/RemoteInspectorXPCConnection.h:
3316         * inspector/remote/RemoteInspectorXPCConnection.mm: