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