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