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