79b15a7797d15908d93deab01247d1e2848323ac
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2017-05-04  Sam Weinig  <sam@webkit.org>
2
3         Remove support for legacy Notifications
4         https://bugs.webkit.org/show_bug.cgi?id=171487
5
6         Reviewed by Jon Lee.
7
8         * Configurations/FeatureDefines.xcconfig:
9         Remove definition of ENABLE_LEGACY_NOTIFICATIONS.
10
11 2017-05-04  Konstantin Tokarev  <annulen@yandex.ru>
12
13         Fix compilation with ICU 59.1
14         https://bugs.webkit.org/show_bug.cgi?id=171612
15
16         Reviewed by Mark Lam.
17
18         ICU 59.1 has broken source compatibility. Now it defines UChar as
19         char16_t, which does not allow automatic type conversion from unsigned
20         short in C++ code.
21
22         * API/JSStringRef.cpp:
23         (JSStringCreateWithCharacters):
24         (JSStringCreateWithCharactersNoCopy):
25         (JSStringGetCharactersPtr):
26         * runtime/DateConversion.cpp:
27         (JSC::formatDateTime):
28
29 2017-05-04  Saam Barati  <sbarati@apple.com>
30
31         stress/call-apply-exponential-bytecode-size.js.no-llint failing on 32-bit debug for OOM on executable memory
32         https://bugs.webkit.org/show_bug.cgi?id=171008
33
34         Reviewed by Yusuke Suzuki.
35
36         This patch lowers the threshold for .call/.apply recursion
37         in an attempt to emit less code and not impact perf.
38         We're currently failing tests on x86-32 by running out
39         of executable memory. If perf gets impacted because of this,
40         then I'll apply a stricter change just to 32-bit platforms.
41         However, if this doesn't negatively impact perf, it's all around
42         better than all platforms emit less bytecode.
43
44         * bytecompiler/NodesCodegen.cpp:
45
46 2017-05-04  Yusuke Suzuki  <utatane.tea@gmail.com>
47
48         [JSC] Math unary functions should be handled by DFG
49         https://bugs.webkit.org/show_bug.cgi?id=171269
50
51         Reviewed by Saam Barati.
52
53         ArithSin, ArithCos, and ArithLog are just calling a C runtime function.
54         While handling them in DFG is not very effective for performance, they
55         can drop some type checks & value conversions and mark them as pure
56         operations. It is effective if they are involved in some complex
57         optimization phase. Actually, ArithLog is effective in kraken.
58
59         While a few of Math functions have DFG nodes, basically math functions
60         are pure. And large part of these functions are just calling a C runtime
61         function. This patch generalizes these nodes in DFG as ArithUnary. And
62         we annotate many unary math functions with Intrinsics and convert them
63         to ArithUnary in DFG. It also cleans up duplicate code in ArithSin,
64         ArithCos, and ArithLog. If your math function has some good DFG / FTL
65         optimization rather than calling a C runtime function, you should add
66         a specialized DFG node, like ArithSqrt.
67
68         We also create a new namespace JSC::Math. Inside it, we collect math functions.
69
70         * dfg/DFGAbstractInterpreterInlines.h:
71         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
72         * dfg/DFGArithMode.cpp:
73         (JSC::DFG::arithUnaryFunction):
74         (JSC::DFG::arithUnaryOperation):
75         (WTF::printInternal):
76         * dfg/DFGArithMode.h:
77         * dfg/DFGBackwardsPropagationPhase.cpp:
78         (JSC::DFG::BackwardsPropagationPhase::propagate):
79         * dfg/DFGByteCodeParser.cpp:
80         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
81         * dfg/DFGClobberize.h:
82         (JSC::DFG::clobberize):
83         * dfg/DFGDoesGC.cpp:
84         (JSC::DFG::doesGC):
85         * dfg/DFGFixupPhase.cpp:
86         (JSC::DFG::FixupPhase::fixupNode):
87         * dfg/DFGGraph.cpp:
88         (JSC::DFG::Graph::dump):
89         * dfg/DFGNode.h:
90         (JSC::DFG::Node::hasArithUnaryType):
91         (JSC::DFG::Node::arithUnaryType):
92         * dfg/DFGNodeType.h:
93         * dfg/DFGOperations.cpp:
94         * dfg/DFGOperations.h:
95         * dfg/DFGPredictionPropagationPhase.cpp:
96         * dfg/DFGSafeToExecute.h:
97         (JSC::DFG::safeToExecute):
98         * dfg/DFGSpeculativeJIT.cpp:
99         (JSC::DFG::SpeculativeJIT::compileArithUnary):
100         (JSC::DFG::SpeculativeJIT::compileArithCos): Deleted.
101         (JSC::DFG::SpeculativeJIT::compileArithTan): Deleted.
102         (JSC::DFG::SpeculativeJIT::compileArithSin): Deleted.
103         (JSC::DFG::SpeculativeJIT::compileArithLog): Deleted.
104         * dfg/DFGSpeculativeJIT.h:
105         * dfg/DFGSpeculativeJIT32_64.cpp:
106         (JSC::DFG::SpeculativeJIT::compile):
107         * dfg/DFGSpeculativeJIT64.cpp:
108         (JSC::DFG::SpeculativeJIT::compile):
109         * ftl/FTLCapabilities.cpp:
110         (JSC::FTL::canCompile):
111         * ftl/FTLLowerDFGToB3.cpp:
112         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
113         (JSC::FTL::DFG::LowerDFGToB3::compileArithUnary):
114         (JSC::FTL::DFG::LowerDFGToB3::compileArithSin): Deleted.
115         (JSC::FTL::DFG::LowerDFGToB3::compileArithCos): Deleted.
116         (JSC::FTL::DFG::LowerDFGToB3::compileArithTan): Deleted.
117         (JSC::FTL::DFG::LowerDFGToB3::compileArithLog): Deleted.
118         * ftl/FTLOutput.cpp:
119         (JSC::FTL::Output::doubleUnary):
120         (JSC::FTL::Output::doubleSin): Deleted.
121         (JSC::FTL::Output::doubleCos): Deleted.
122         (JSC::FTL::Output::doubleTan): Deleted.
123         (JSC::FTL::Output::doubleLog): Deleted.
124         * ftl/FTLOutput.h:
125         * runtime/Intrinsic.h:
126         * runtime/MathCommon.cpp:
127         (JSC::Math::log1p):
128         * runtime/MathCommon.h:
129         * runtime/MathObject.cpp:
130         (JSC::MathObject::finishCreation):
131         (JSC::mathProtoFuncACos):
132         (JSC::mathProtoFuncASin):
133         (JSC::mathProtoFuncATan):
134         (JSC::mathProtoFuncCos):
135         (JSC::mathProtoFuncExp):
136         (JSC::mathProtoFuncLog):
137         (JSC::mathProtoFuncSin):
138         (JSC::mathProtoFuncTan):
139         (JSC::mathProtoFuncACosh):
140         (JSC::mathProtoFuncASinh):
141         (JSC::mathProtoFuncATanh):
142         (JSC::mathProtoFuncCbrt):
143         (JSC::mathProtoFuncCosh):
144         (JSC::mathProtoFuncExpm1):
145         (JSC::mathProtoFuncLog1p):
146         (JSC::mathProtoFuncLog10):
147         (JSC::mathProtoFuncLog2):
148         (JSC::mathProtoFuncSinh):
149         (JSC::mathProtoFuncTanh):
150
151 2017-05-03  Saam Barati  <sbarati@apple.com>
152
153         How we build polymorphic cases is wrong when making a call from Wasm
154         https://bugs.webkit.org/show_bug.cgi?id=171527
155
156         Reviewed by JF Bastien.
157
158         This patches fixes a bug when we emit a polymorphic call IC from
159         Wasm. We were incorrectly assuming that if we made a call *from wasm*,
160         then the thing we are *calling to* does not have a CodeBlock. This
161         is obviously wrong. This patch fixes the incorrect assumption.
162         
163         This patch also does two more things:
164         1. Add a new option that makes us make calls to JS using a
165         slow path instead of using a call IC.
166         2. Fixes a potential GC bug where we didn't populate JSWebAssemblyCodeBlock's
167         JSWebAssemblyModule pointer.
168
169         * jit/Repatch.cpp:
170         (JSC::linkPolymorphicCall):
171         * runtime/Options.h:
172         * wasm/WasmBinding.cpp:
173         (JSC::Wasm::wasmToJs):
174         * wasm/js/JSWebAssemblyCodeBlock.cpp:
175         (JSC::JSWebAssemblyCodeBlock::create):
176         (JSC::JSWebAssemblyCodeBlock::finishCreation):
177         * wasm/js/JSWebAssemblyCodeBlock.h:
178         * wasm/js/JSWebAssemblyInstance.cpp:
179         (JSC::JSWebAssemblyInstance::finalizeCreation):
180
181 2017-05-03  Keith Miller  <keith_miller@apple.com>
182
183         Array.prototype.sort should also allow a null comparator
184         https://bugs.webkit.org/show_bug.cgi?id=171621
185         <rdar://problem/30757933>
186
187         Reviewed by Michael Saboff.
188
189         It looks like sort not accepting a null comparator
190         causes some pages to stop working. Those pages work in
191         Chrome/Firefox so we should try to match them.
192
193         * builtins/ArrayPrototype.js:
194         (sort):
195
196 2017-05-03  Mark Lam  <mark.lam@apple.com>
197
198         Use the CLoop for CPU(ARM64E).
199         https://bugs.webkit.org/show_bug.cgi?id=171620
200         <rdar://problem/31973027>
201
202         Reviewed by Geoffrey Garen.
203
204         * llint/LLIntOfflineAsmConfig.h:
205         * tools/SigillCrashAnalyzer.cpp:
206         (JSC::SigillCrashAnalyzer::dumpCodeBlock):
207
208 2017-05-03  Keith Miller  <keith_miller@apple.com>
209
210         Different behaviour with the .sort(callback) method (unlike Firefox & Chrome)
211         https://bugs.webkit.org/show_bug.cgi?id=47825
212
213         Reviewed by Saam Barati.
214
215         This patch makes our sort function match the behavior of Firefox
216         and Chrome when the result of the comparison function is a
217         boolean. When we first switched to using merge sort, it regressed
218         JQuery sorting of DOM nodes by 30%. The regression was do to the
219         fact that JQuery was using compareDocumentPosition to compare the
220         locations of objects. Since one of the benchmarks would pass a
221         reverse sorted list to the sort function we would end up walking
222         the entire DOM to do comparisons. The solution to this was to
223         merge based on comparison(right, left) rather than
224         comparison(left, right). Although, in practice this does nothing
225         since sort could just as easily receive an already sorted list and
226         we're back in the same spot.
227
228         The downside of sorting with comparison(right, left) is that to
229         maintain stability when sorting, you only want to merge from right
230         when the comparison function returns a negative value. This is
231         where the problem with booleans comes in. Since booleans toNumber
232         false to 0 and true to 1 both values are "equal". This patch fixes
233         this by special casing boolean return values.
234
235
236         * builtins/ArrayPrototype.js:
237         (sort.merge):
238
239 2017-05-03  Andy VanWagoner  <thetalecrafter@gmail.com>
240
241         [INTL] Support dashed values in unicode locale extensions
242         https://bugs.webkit.org/show_bug.cgi?id=171480
243
244         Reviewed by JF Bastien.
245
246         Implements the UnicodeExtensionSubtags operation and updates the ResolveLocale operation to use it.
247         This fixes locale extensions with values that include '-'. The following calendars work now:
248         ethiopic-amete-alem
249         islamic-umalqura
250         islamic-tbla
251         islamic-civil
252         islamic-rgsa
253
254         While updating IntlObject, the comments containing spec text were replaced with a single url at the
255         top of each function pointing to the relevant part of ECMA-402.
256
257         * runtime/IntlObject.cpp:
258         (JSC::unicodeExtensionSubTags): Added.
259         (JSC::resolveLocale): Updated to latest standard.
260
261 2017-05-02  Don Olmstead  <don.olmstead@am.sony.com>
262
263         Build fix after r216078
264         https://bugs.webkit.org/show_bug.cgi?id=171554
265
266         Reviewed by Saam Barati.
267
268         * API/tests/testapi.c:
269
270 2017-05-02  Filip Pizlo  <fpizlo@apple.com>
271
272         Unreviewed, fix pedantic C compilers.
273
274         * API/tests/testapi.c:
275         (markingConstraint):
276         (testMarkingConstraints):
277
278 2017-05-02  Filip Pizlo  <fpizlo@apple.com>
279
280         Unreviewed, fix cmake build.
281
282         * CMakeLists.txt:
283
284 2017-05-02  Filip Pizlo  <fpizlo@apple.com>
285
286         JSC C API should expose GC marking constraints and weak references
287         https://bugs.webkit.org/show_bug.cgi?id=171554
288
289         Reviewed by Geoffrey Garen.
290         
291         This exposes an API that lets you participate in the GC's fixpoint. You can ask the GC
292         what is marked and you can tell the GC to mark things. The constraint callback cannot
293         do a whole lot, but it can query marking state and it can dereference weak references.
294         
295         Additionally, this exposes a very simple weak reference API in C.
296
297         * API/JSMarkingConstraintPrivate.cpp: Added.
298         (JSC::isMarked):
299         (JSC::mark):
300         (JSContextGroupRegisterMarkingConstraint):
301         * API/JSMarkingConstraintPrivate.h: Added.
302         * API/JSWeakPrivate.cpp: Added.
303         (OpaqueJSWeak::OpaqueJSWeak):
304         (JSWeakCreate):
305         (JSWeakRetain):
306         (JSWeakRelease):
307         (JSWeakGetObject):
308         * API/JSWeakPrivate.h: Added.
309         * API/tests/testapi.c:
310         (markingConstraint):
311         (testMarkingConstraints):
312         (main):
313         * JavaScriptCore.xcodeproj/project.pbxproj:
314         * heap/SlotVisitor.h:
315         * heap/SlotVisitorInlines.h:
316         (JSC::SlotVisitor::appendHiddenUnbarriered):
317         (JSC::SlotVisitor::appendHidden):
318
319 2017-05-02  Mark Lam  <mark.lam@apple.com>
320
321         JSFixedArray::allocationSize() should not allow for allocation failure.
322         https://bugs.webkit.org/show_bug.cgi?id=171516
323
324         Reviewed by Geoffrey Garen.
325
326         Since JSFixedArray::createFromArray() now handles allocation failures by throwing
327         OutOfMemoryErrors, its helper function allocationSize() (which computes the buffer
328         size to allocate) should also allow for allocation failure on overflow.
329
330         This issue is covered by the stress/js-fixed-array-out-of-memory.js test when
331         run on 32-bit builds.
332
333         * runtime/JSFixedArray.h:
334         (JSC::JSFixedArray::tryCreate):
335         (JSC::JSFixedArray::allocationSize):
336
337 2017-05-01  Zan Dobersek  <zdobersek@igalia.com>
338
339         [aarch64][Linux] m_allowScratchRegister assert hit in MacroAssemblerARM64 under B3::Air::CCallSpecial::generate()
340         https://bugs.webkit.org/show_bug.cgi?id=170672
341
342         Reviewed by Filip Pizlo.
343
344         In Air::CCallSpecial::admitsStack() we reject admitting the callee argument on
345         the stack for ARM64 because that can lead to disallowed usage of the scratch
346         register in MacroAssemblerARM64 when generating a call with an address Arg
347         in Air::CCallSpecial::generate().
348
349         The testLinearScanWithCalleeOnStack test is added to testb3. It reproduces the
350         original issue by force-spilling everything on the stack and enforcing the use
351         of the linear scan register allocation by using an optimization level of 1.
352
353         * b3/air/AirCCallSpecial.cpp:
354         (JSC::B3::Air::CCallSpecial::admitsStack):
355         * b3/testb3.cpp:
356         (JSC::B3::testLinearScanWithCalleeOnStack):
357         (JSC::B3::run):
358
359 2017-05-01  David Kilzer  <ddkilzer@apple.com>
360
361         Stop using sprintf() in JavaScriptCore debugger
362         <https://webkit.org/b/171512>
363
364         Reviewed by Keith Miller.
365
366         * disassembler/udis86/udis86.c:
367         (ud_insn_hex): Switch from sprintf() to snprintf().
368
369 2017-04-21  Filip Pizlo  <fpizlo@apple.com>
370
371         Air::fixObviousSpills should remove totally redundant instructions
372         https://bugs.webkit.org/show_bug.cgi?id=171131
373
374         Reviewed by Saam Barati.
375         
376         This is a modest compile-time-neutral improvement to fixObviousSpills. That phase
377         builds up a classic alias analysis data structure over spills and registers and then
378         uses it to remove the most common spill pathologies we encounter. For example, if you
379         use a spill but the spill is aliased to a register or constant, then we can replace the
380         use of the spill with a use of the register or constant.
381         
382         But that phase was missing perhaps one of the most obvious fixups that its analysis
383         allows us to do: if any instruction creates an alias we already know about, then the
384         instruction is redundant. This turned out to be super important for
385         https://bugs.webkit.org/show_bug.cgi?id=171075. That patch didn't work out, but this
386         kind of optimization might be a good clean-up for many other kinds of optimizations.
387
388         * b3/air/AirFixObviousSpills.cpp:
389
390 2017-04-30  Oleksandr Skachkov  <gskachkov@gmail.com>
391
392         We initialize functions too early in an eval
393         https://bugs.webkit.org/show_bug.cgi?id=161099
394
395         Reviewed by Saam Barati.
396
397         Current patch allow to fix problem with scope in function that is 
398         declared within eval. Before scope was set inside Interpretator.cpp and it
399         was scope where eval is executed, but in this case function would not 
400         see let/const variables and classes declated in eval.
401         This patch devide declaration and binding in two operation, first just declare
402         variable with function name, and second bind variable to function with correct 
403         scope
404
405         * bytecompiler/BytecodeGenerator.cpp:
406         (JSC::BytecodeGenerator::generate):
407         (JSC::BytecodeGenerator::BytecodeGenerator):
408         * bytecompiler/BytecodeGenerator.h:
409         * interpreter/Interpreter.cpp:
410         (JSC::Interpreter::execute):
411
412 2017-04-30  Oleksandr Skachkov  <gskachkov@gmail.com>
413
414         [ES6]. Implement Annex B.3.3 function hoisting rules for eval
415         https://bugs.webkit.org/show_bug.cgi?id=163208
416
417         Reviewed by Saam Barati.
418
419         Current patch implements Annex B.3.3 that is related to 
420         hoisting of function declaration in eval. 
421         https://tc39.github.io/ecma262/#sec-web-compat-evaldeclarationinstantiation
422         Function declaration in eval should create variable with 
423         function name in function scope where eval is invoked 
424         or bind to variable if it declared outside of the eval. 
425         If variable is created it can be removed by 'delete a;' command. 
426         If eval is invoke in block scope that contains let/const 
427         variable with the same name as function declaration 
428         we do not bind. This patch leads to the following behavior: 
429         '''
430         function foo() {
431            {
432              print(boo); // undefined
433              eval('{ function boo() {}}');
434              print(boo); // function boo() {}
435            }
436            print(boo); // function boo() {}
437         }
438
439         function foobar() {
440           { 
441             let boo = 10;
442             print(boo); // 10;
443             eval('{ function boo() {}}');
444             print(boo); // 10;
445           }
446           print(boo) // 10
447         }
448
449         function bar() {
450            {
451               var boo = 10;
452               print(boo); // 10
453               eval('{ function boo() {} }'); 
454               print(boo); // function boo() {}
455            }
456            print(boo); // function boo() {}
457         }       
458         
459         function bas() {
460             {
461                  let boo = 10;
462                  eval(' { function boo() {} } ');
463                  print(boo); // 10
464             }
465             print(boo); //Reference Error
466         }
467         '''
468
469         Current implementation relies on already implemented 
470         'hoist function in sloppy mode' feature, with small changes.
471         In short it works in following way: during hoisting of function 
472         with name S in eval, we are looking for first scope that 
473         contains space for variable with name S and if this scope 
474         has var type we bind function there
475
476         To implement this feature was added bytecode ops:
477         op_resolve_scope_for_hoisting_func_decl_in_eval - get variable scope 
478         or return undefined if variable can't be binded there.
479
480         There is a corner case, hoist function in eval within catch block,
481         that is not covered by this patch, and will be fixed in 
482         https://bugs.webkit.org/show_bug.cgi?id=168184
483
484         * bytecode/BytecodeDumper.cpp:
485         (JSC::BytecodeDumper<Block>::dumpBytecode):
486         * bytecode/BytecodeList.json:
487         * bytecode/BytecodeUseDef.h:
488         (JSC::computeUsesForBytecodeOffset):
489         (JSC::computeDefsForBytecodeOffset):
490         * bytecode/CodeBlock.cpp:
491         (JSC::CodeBlock::finalizeLLIntInlineCaches):
492         * bytecode/EvalCodeBlock.h:
493         (JSC::EvalCodeBlock::functionHoistingCandidate):
494         (JSC::EvalCodeBlock::numFunctionHoistingCandidates):
495         * bytecode/UnlinkedEvalCodeBlock.h:
496         * bytecompiler/BytecodeGenerator.cpp:
497         (JSC::BytecodeGenerator::BytecodeGenerator):
498         (JSC::BytecodeGenerator::hoistSloppyModeFunctionIfNecessary):
499         (JSC::BytecodeGenerator::emitResolveScopeForHoistingFuncDeclInEval):
500         * bytecompiler/BytecodeGenerator.h:
501         * dfg/DFGAbstractInterpreterInlines.h:
502         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
503         * dfg/DFGByteCodeParser.cpp:
504         (JSC::DFG::ByteCodeParser::parseBlock):
505         * dfg/DFGCapabilities.cpp:
506         (JSC::DFG::capabilityLevel):
507         * dfg/DFGClobberize.h:
508         (JSC::DFG::clobberize):
509         * dfg/DFGDoesGC.cpp:
510         (JSC::DFG::doesGC):
511         * dfg/DFGFixupPhase.cpp:
512         (JSC::DFG::FixupPhase::fixupNode):
513         * dfg/DFGNode.h:
514         (JSC::DFG::Node::hasIdentifier):
515         * dfg/DFGNodeType.h:
516         * dfg/DFGOperations.cpp:
517         * dfg/DFGOperations.h:
518         * dfg/DFGPredictionPropagationPhase.cpp:
519         * dfg/DFGSafeToExecute.h:
520         (JSC::DFG::safeToExecute):
521         * dfg/DFGSpeculativeJIT.cpp:
522         (JSC::DFG::SpeculativeJIT::compileResolveScopeForHoistingFuncDeclInEval):
523         * dfg/DFGSpeculativeJIT.h:
524         (JSC::DFG::SpeculativeJIT::callOperation):
525         * dfg/DFGSpeculativeJIT32_64.cpp:
526         (JSC::DFG::SpeculativeJIT::compile):
527         * dfg/DFGSpeculativeJIT64.cpp:
528         (JSC::DFG::SpeculativeJIT::compile):
529         * ftl/FTLCapabilities.cpp:
530         (JSC::FTL::canCompile):
531         * ftl/FTLLowerDFGToB3.cpp:
532         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
533         (JSC::FTL::DFG::LowerDFGToB3::compileResolveScopeForHoistingFuncDeclInEval):
534         * interpreter/Interpreter.cpp:
535         (JSC::Interpreter::execute):
536         * jit/JIT.cpp:
537         (JSC::JIT::privateCompileMainPass):
538         * jit/JIT.h:
539         * jit/JITOperations.h:
540         * jit/JITPropertyAccess.cpp:
541         (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval):
542         * jit/JITPropertyAccess32_64.cpp:
543         (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval):
544         * llint/LowLevelInterpreter.asm:
545         * parser/Parser.cpp:
546         (JSC::Parser<LexerType>::parseFunctionDeclarationStatement):
547         * parser/Parser.h:
548         (JSC::Scope::getSloppyModeHoistedFunctions):
549         (JSC::Parser::declareFunction):
550         * runtime/CommonSlowPaths.cpp:
551         (JSC::SLOW_PATH_DECL):
552         * runtime/CommonSlowPaths.h:
553         * runtime/EvalExecutable.h:
554         (JSC::EvalExecutable::numFunctionHoistingCandidates):
555         (JSC::EvalExecutable::numTopLevelFunctionDecls):
556         (JSC::EvalExecutable::numberOfFunctionDecls): Deleted.
557         * runtime/JSScope.cpp:
558         (JSC::JSScope::resolve):
559         (JSC::JSScope::resolveScopeForHoistingFuncDeclInEval):
560         * runtime/JSScope.h:
561
562 2017-04-29  Oleksandr Skachkov  <gskachkov@gmail.com>
563
564         Deep nesting is leading to ReferenceError for hoisted function
565         https://bugs.webkit.org/show_bug.cgi?id=171456
566
567         Reviewed by Yusuke Suzuki.
568
569         Current patch fix error that appears during hoisting of the function 
570         in block scope. Error happens only when exist some deep scope that lead
571         to increase scope stack, after which list of the hosted candidates do not 
572         copied to updated scope stack.
573
574         * parser/Parser.h:
575         (JSC::Scope::Scope):
576
577 2017-04-29  Yusuke Suzuki  <utatane.tea@gmail.com>
578
579         [JSC] LabelScopePtr is not necessary
580         https://bugs.webkit.org/show_bug.cgi?id=171474
581
582         Reviewed by Geoffrey Garen.
583
584         Originally, LabelScopePtr is introduced because LabelScopes uses Vector<> instead of SegmentedVector<>.
585         LabelScopePtr holds the pointer to the vector owner and index instead of the pointer to LabelScope directly
586         since Vector<> can relocate LocalScopes inside it.
587         The reason why LabelScopes use Vector instead is that there is code copying this vector. SegmentedVector<>
588         prohibits copying since it is so costly. So, we used Vector<> here instead of SegmentedVector<>.
589
590         But the latest code does not have copying code for LabelScopes. Thus, we can take the same design to Label and
591         RegisterID. Just use SegmentedVector<> and Ref<>/RefPtr<>. This patch removes LabelScopePtr since it is no
592         longer necessary. And use SegmentedVector for LabelScopes.
593
594         * bytecompiler/BytecodeGenerator.cpp:
595         (JSC::reclaim):
596         (JSC::BytecodeGenerator::reclaimFreeRegisters):
597         (JSC::BytecodeGenerator::newLabelScope):
598         (JSC::BytecodeGenerator::newLabel):
599         (JSC::BytecodeGenerator::pushFinallyControlFlowScope):
600         (JSC::BytecodeGenerator::breakTarget):
601         (JSC::BytecodeGenerator::continueTarget):
602         (JSC::BytecodeGenerator::emitEnumeration):
603         * bytecompiler/BytecodeGenerator.h:
604         * bytecompiler/LabelScope.h:
605         (JSC::LabelScope::LabelScope):
606         (JSC::LabelScope::breakTarget):
607         (JSC::LabelScope::continueTarget):
608         (JSC::LabelScope::type):
609         (JSC::LabelScope::name):
610         (JSC::LabelScope::scopeDepth):
611         (JSC::LabelScope::ref):
612         (JSC::LabelScope::deref):
613         (JSC::LabelScope::refCount):
614         (JSC::LabelScopePtr::LabelScopePtr): Deleted.
615         (JSC::LabelScopePtr::operator=): Deleted.
616         (JSC::LabelScopePtr::~LabelScopePtr): Deleted.
617         (JSC::LabelScopePtr::operator!): Deleted.
618         (JSC::LabelScopePtr::operator*): Deleted.
619         (JSC::LabelScopePtr::operator->): Deleted.
620         (JSC::LabelScopePtr::null): Deleted.
621         * bytecompiler/NodesCodegen.cpp:
622         (JSC::DoWhileNode::emitBytecode):
623         (JSC::WhileNode::emitBytecode):
624         (JSC::ForNode::emitBytecode):
625         (JSC::ForInNode::emitBytecode):
626         (JSC::ContinueNode::trivialTarget):
627         (JSC::ContinueNode::emitBytecode):
628         (JSC::BreakNode::trivialTarget):
629         (JSC::BreakNode::emitBytecode):
630         (JSC::SwitchNode::emitBytecode):
631         (JSC::LabelNode::emitBytecode):
632
633 2017-04-28  Mark Lam  <mark.lam@apple.com>
634
635         Revert instrumentation from https://bugs.webkit.org/show_bug.cgi?id=170086 that is no longer needed.
636         https://bugs.webkit.org/show_bug.cgi?id=170094
637
638         Reviewed by JF Bastien and Keith Miller.
639
640         * heap/Heap.cpp:
641         (JSC::Heap::resumeThePeriphery):
642
643 2017-04-27  Andy VanWagoner  <thetalecrafter@gmail.com>
644
645         [INTL] Implement the caseFirst option for Intl.Collator
646         https://bugs.webkit.org/show_bug.cgi?id=158188
647
648         Reviewed by Geoffrey Garen.
649
650         Implements the caseFirst option and unicode locale extension.
651         The caseFirst option explicitly determines whether upper or lower case comes first.
652
653         * runtime/IntlCollator.cpp:
654         (JSC::sortLocaleData): Added kf data.
655         (JSC::searchLocaleData): Added kf data.
656         (JSC::IntlCollator::initializeCollator): Set caseFirst option.
657         (JSC::IntlCollator::createCollator): Set new attributes on ICU collator.
658         (JSC::IntlCollator::caseFirstString): Added.
659         (JSC::IntlCollator::resolvedOptions): Added caseFirst property.
660         * runtime/IntlCollator.h:
661
662 2017-04-27  Mark Lam  <mark.lam@apple.com>
663
664         Fix some RELEASE_ASSERT failures caused by OutOfMemoryErrors.
665         https://bugs.webkit.org/show_bug.cgi?id=171404
666         <rdar://problem/31876178>
667
668         Reviewed by Saam Barati.
669
670         1. Added some tryAllocate() functions in JSCellInlines.h.
671         2. Consolidated the implementations of allocateCell() template functions into a
672            single tryAllocateCellHelper() to reduce redundancy and eliminate needing to
673            copy-paste for variations of allocateCell and tryAllocateCell.
674         3. Changed JSFixedArray::createFromArray() and constructEmptyArray() to check for
675            allocation failure and throw an OutOfMemoryError.  It was already possible to
676            throw errors from these functions for other reasons.  So, their clients are
677            already ready to handle OOMEs.
678
679         * ftl/FTLOperations.cpp:
680         (JSC::FTL::operationMaterializeObjectInOSR):
681         * runtime/JSCInlines.h:
682         * runtime/JSCell.h:
683         * runtime/JSCellInlines.h:
684         (JSC::tryAllocateCellHelper):
685         (JSC::allocateCell):
686         (JSC::tryAllocateCell):
687         * runtime/JSFixedArray.h:
688         (JSC::JSFixedArray::createFromArray):
689         (JSC::JSFixedArray::tryCreate):
690         (JSC::JSFixedArray::create): Deleted.
691         * runtime/JSGlobalObject.h:
692         (JSC::constructEmptyArray):
693
694 2017-04-27  Joseph Pecoraro  <pecoraro@apple.com>
695
696         Support for promise rejection events (unhandledrejection)
697         https://bugs.webkit.org/show_bug.cgi?id=150358
698         <rdar://problem/28441651>
699
700         Reviewed by Saam Barati.
701
702         Patch by Joseph Pecoraro and Yusuke Suzuki.
703
704         Implement support for promise.[[PromiseIsHandled]] and the
705         HostPromiseRejectionTracker hook for HTML to track promise rejections:
706         https://tc39.github.io/ecma262/#sec-host-promise-rejection-tracker
707         https://html.spec.whatwg.org/multipage/webappapis.html#unhandled-promise-rejections
708
709         * builtins/BuiltinNames.h:
710         New private symbols.
711
712         * builtins/PromiseOperations.js:
713         (globalPrivate.newHandledRejectedPromise):
714         Utility to create a rejected promise with [[PromiseIsHandled]] to true.
715
716         (globalPrivate.rejectPromise):
717         (globalPrivate.initializePromise):
718         * builtins/PromisePrototype.js:
719         (then):
720         Implement standard behavior of [[PromiseIsHandled]] and the host hook.
721
722         * runtime/JSPromise.cpp:
723         (JSC::JSPromise::isHandled):
724         * runtime/JSPromise.h:
725         C++ accessors for the [[PromiseIsHandled]] state.
726
727         * bytecode/BytecodeIntrinsicRegistry.cpp:
728         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
729         * bytecode/BytecodeIntrinsicRegistry.h:
730         Expose private values for the Reject / Handle enum values in built-ins.
731
732         * jsc.cpp:
733         * runtime/JSGlobalObject.h:
734         (JSC::JSGlobalObject::promiseResolveFunction):
735         Add a new GlobalObjectMethodTable hook matching the promise rejection hook.
736
737         * runtime/JSGlobalObject.cpp:
738         (JSC::JSGlobalObject::init):
739         (JSC::JSGlobalObject::visitChildren):
740         * runtime/JSGlobalObjectFunctions.cpp:
741         (JSC::globalFuncHostPromiseRejectionTracker):
742         * runtime/JSGlobalObjectFunctions.h:
743         Plumb the builtin hook through to the optional GlobalObjectMethodTable hook.
744
745         * inspector/InjectedScriptSource.js:
746         (InjectedScript.prototype.createFakeValueDescriptor):
747         Silence possible rejected promises created internally via Web Inspector.
748
749 2017-04-27  Saam Barati  <sbarati@apple.com>
750
751         B3::FoldPathConstants does not consider the fall through case for Switch
752         https://bugs.webkit.org/show_bug.cgi?id=171390
753
754         Reviewed by Filip Pizlo.
755
756         foldPathConstants was not taking into account a Switch's default
757         case when it tried to constant propagate the switch's operand value.
758         e.g, we incorrectly transformed this code:
759         
760         ```
761         x = argumentGPR0;
762         switch (x) {
763         case 10: return 20;
764         
765         case 0:
766         default: return x == 0;
767         }
768         ```
769         
770         into:
771         ```
772         x = argumentGPR0;
773         switch (x) {
774         case 10: return 20;
775         
776         case 0:
777         default: return 1;
778         }
779         ```
780         
781         Because we didn't take into account the default case, we incorrectly
782         optimized the code as if case 0's block was only reachable if x is
783         equal to zero. This is obviously not true, since it's the same block
784         as the default case.
785         
786         This fix ensures that we can run the WebAssembly Tanks demo even when
787         we set webAssemblyBBQOptimizationLevel=2.
788
789         * b3/B3FoldPathConstants.cpp:
790         * b3/B3SwitchValue.cpp:
791         (JSC::B3::SwitchValue::fallThrough):
792         (JSC::B3::SwitchValue::removeCase): Deleted.
793         * b3/B3SwitchValue.h:
794         * b3/testb3.cpp:
795         (JSC::B3::testCallFunctionWithHellaArguments):
796         (JSC::B3::testSwitchSameCaseAsDefault):
797         (JSC::B3::testWasmBoundsCheck):
798         (JSC::B3::run):
799
800 2017-04-27  Keith Miller  <keith_miller@apple.com>
801
802         WebAssembly: Don't tier up the same function twice
803         https://bugs.webkit.org/show_bug.cgi?id=171397
804
805         Reviewed by Filip Pizlo.
806
807         Because we don't CAS the tier up count on function entry/loop backedge and we use the least significant to indicate whether or not tier up has already started we could see the following:
808
809         Threads A and B are running count in memory is (0):
810
811         A: load tier up count (0)
812         B: load tier up count (0)
813         A: decrement count to -2 and see we need to check for tier up (0)
814         A: store -2 to count (-2)
815         A: exchangeOr(1) to tier up count (-1)
816         B: decrement count to -2 and see we need to check for tier up (-1)
817         B: store -2 to count (-2)
818         B: exchangeOr(1) to tier up count (-1)
819
820         This would cause us to tier up the same function twice, which we would rather avoid.
821
822         * wasm/WasmB3IRGenerator.cpp:
823         (JSC::Wasm::B3IRGenerator::emitTierUpCheck):
824         * wasm/WasmTierUpCount.h:
825         (JSC::Wasm::TierUpCount::TierUpCount):
826         (JSC::Wasm::TierUpCount::loopDecrement):
827         (JSC::Wasm::TierUpCount::functionEntryDecrement):
828         (JSC::Wasm::TierUpCount::shouldStartTierUp):
829
830 2017-04-27  Keith Miller  <keith_miller@apple.com>
831
832         REGRESSION (r215843): ASSERTION FAILED: !m_completionTasks[0].first in  JSC::Wasm::Plan::tryRemoveVMAndCancelIfLast(JSC::VM &)
833         https://bugs.webkit.org/show_bug.cgi?id=171380
834
835         Reviewed by JF Bastien.
836
837         This patch fixes the association of VMs to Wasm::Plans. For validation
838         we want all the completion tasks to be associate with a VM. For BBQ,
839         we want the main task to not be associated with any VM.
840
841         * jsc.cpp:
842         (functionTestWasmModuleFunctions):
843         * wasm/WasmBBQPlan.cpp:
844         (JSC::Wasm::BBQPlan::BBQPlan):
845         * wasm/WasmBBQPlan.h:
846         * wasm/WasmCodeBlock.cpp:
847         (JSC::Wasm::CodeBlock::CodeBlock):
848         (JSC::Wasm::CodeBlock::compileAsync):
849         * wasm/WasmCodeBlock.h:
850         (JSC::Wasm::CodeBlock::create):
851         * wasm/WasmModule.cpp:
852         (JSC::Wasm::makeValidationCallback):
853         (JSC::Wasm::Module::validateSync):
854         (JSC::Wasm::Module::validateAsync):
855         (JSC::Wasm::Module::getOrCreateCodeBlock):
856         (JSC::Wasm::Module::compileSync):
857         (JSC::Wasm::Module::compileAsync):
858         * wasm/WasmModule.h:
859         * wasm/WasmOMGPlan.cpp:
860         (JSC::Wasm::OMGPlan::OMGPlan):
861         (JSC::Wasm::runOMGPlanForIndex):
862         * wasm/WasmOMGPlan.h:
863         * wasm/WasmPlan.cpp:
864         (JSC::Wasm::Plan::Plan):
865         (JSC::Wasm::Plan::runCompletionTasks):
866         (JSC::Wasm::Plan::addCompletionTask):
867         (JSC::Wasm::Plan::tryRemoveVMAndCancelIfLast):
868         * wasm/WasmPlan.h:
869         (JSC::Wasm::Plan::dontFinalize):
870         * wasm/js/WebAssemblyInstanceConstructor.cpp:
871         (JSC::constructJSWebAssemblyInstance):
872         * wasm/js/WebAssemblyPrototype.cpp:
873         (JSC::webAssemblyValidateFunc):
874
875 2017-04-27  Saam Barati  <sbarati@apple.com>
876
877         Restore some caching functionality that got accidentally removed when doing Wasm PIC patches
878         https://bugs.webkit.org/show_bug.cgi?id=171382
879
880         Reviewed by Keith Miller.
881
882         When I created Wasm::CodeBlock, I accidentally removed caching
883         the creation of JSWebAssemblyCodeBlocks. This patch restores it.
884         It's worth keeping JSWebAssemblyModule's JSWebAssemblyCodeBlock
885         cache because creating a JSWebAssemblyCodeBlock does non trivial
886         work by creating the various IC call stubs.
887
888         * wasm/js/JSWebAssemblyCodeBlock.h:
889         (JSC::JSWebAssemblyCodeBlock::codeBlock):
890         * wasm/js/JSWebAssemblyInstance.cpp:
891         (JSC::JSWebAssemblyInstance::finalizeCreation):
892         (JSC::JSWebAssemblyInstance::create):
893         * wasm/js/JSWebAssemblyModule.h:
894
895 2017-04-27  Mark Lam  <mark.lam@apple.com>
896
897         Audit and fix incorrect uses of JSArray::tryCreateForInitializationPrivate().
898         https://bugs.webkit.org/show_bug.cgi?id=171344
899         <rdar://problem/31352667>
900
901         Reviewed by Filip Pizlo.
902
903         JSArray::tryCreateForInitializationPrivate() should only be used in performance
904         critical paths, and should always be used with care because it creates an
905         uninitialized object that needs to be initialized by its client before the object
906         can be released into the system.  Before the object is fully initialized:
907         a. the client should not re-enter the VM to execute JS code, and
908         b. GC should not run.
909
910         This is because until the object is fully initialized, it is an inconsistent
911         state that the GC and JS code will not be happy about.
912
913         In this patch, we do the following:
914
915         1. Renamed JSArray::tryCreateForInitializationPrivate() to
916            JSArray::tryCreateUninitializedRestricted() because "private" is a bit ambiguous
917            and can be confused with APIs that are called freely within WebKit but are
918            not meant for clients of WebKit.  In this case, we intend for use of this API
919            to be restricted to only a few carefully considered and crafted cases.
920
921         2. Introduce the ObjectInitializationScope RAII object which covers the period
922            when the uninitialized object is created and gets initialized.
923
924            ObjectInitializationScope will asserts that either the object is created
925            fully initialized (in the case where the object structure is not an "original"
926            structure) or if created uninitialized, is fully initialized at the end of
927            the scope.
928
929            If the object is created uninitialized, the ObjectInitializationScope also
930            ensures that we do not GC nor re-enter the VM to execute JS code.  This is
931            achieved by enabling DisallowGC and DisallowVMReentry scopes.
932
933            tryCreateUninitializedRestricted() and initializeIndex() now requires an
934            ObjectInitializationScope instance.  The ObjectInitializationScope replaces
935            the VM& argument because it can be used to pass the VM& itself.  This is a
936            small optimization that makes passing the ObjectInitializationScope free even
937            on release builds.
938
939         3. Factored a DisallowScope out of DisallowGC, and make DisallowGC extend it.
940            Introduce a DisallowVMReentry class that extends DisallowScope.
941
942         4. Fixed a bug found by the ObjectInitializationScope.  The bug is that there are
943            scenarios where the structure passed to tryCreateUninitializedRestricted()
944            that may not be an "original" structure.  As a result, initializeIndex() would
945            end up allocating new structures, and therefore trigger a GC.
946
947            The fix is to detect that the structure passed to tryCreateUninitializedRestricted()
948            is not an "original" one, and pre-initialize the array with 0s.
949
950            This bug was detected by existing tests. Hence, no new test needed.
951
952         5. Replaced all inappropriate uses of tryCreateUninitializedRestricted() with
953            tryCreate().  Inappropriate uses here means code that is not in performance
954            critical paths.
955
956            Similarly, replaced accompanying uses of initializeIndex() with putDirectIndex().
957
958            This patch is performance neutral (according to the JSC command line benchmarks).
959
960         * CMakeLists.txt:
961         * JavaScriptCore.xcodeproj/project.pbxproj:
962         * dfg/DFGOperations.cpp:
963         * ftl/FTLOperations.cpp:
964         (JSC::FTL::operationMaterializeObjectInOSR):
965         * heap/DeferGC.cpp:
966         * heap/DeferGC.h:
967         (JSC::DisallowGC::DisallowGC):
968         (JSC::DisallowGC::initialize):
969         (JSC::DisallowGC::scopeReentryCount):
970         (JSC::DisallowGC::setScopeReentryCount):
971         (JSC::DisallowGC::~DisallowGC): Deleted.
972         (JSC::DisallowGC::isGCDisallowedOnCurrentThread): Deleted.
973         * heap/GCDeferralContextInlines.h:
974         (JSC::GCDeferralContext::~GCDeferralContext):
975         * heap/Heap.cpp:
976         (JSC::Heap::collectIfNecessaryOrDefer):
977         * runtime/ArrayPrototype.cpp:
978         (JSC::arrayProtoPrivateFuncConcatMemcpy):
979         * runtime/ClonedArguments.cpp:
980         (JSC::ClonedArguments::createWithInlineFrame):
981         (JSC::ClonedArguments::createByCopyingFrom):
982         * runtime/CommonSlowPaths.cpp:
983         (JSC::SLOW_PATH_DECL):
984         * runtime/DisallowScope.h: Added.
985         (JSC::DisallowScope::DisallowScope):
986         (JSC::DisallowScope::~DisallowScope):
987         (JSC::DisallowScope::isInEffectOnCurrentThread):
988         (JSC::DisallowScope::enable):
989         (JSC::DisallowScope::enterScope):
990         (JSC::DisallowScope::exitScope):
991         * runtime/DisallowVMReentry.cpp: Added.
992         * runtime/DisallowVMReentry.h: Added.
993         (JSC::DisallowVMReentry::DisallowVMReentry):
994         (JSC::DisallowVMReentry::initialize):
995         (JSC::DisallowVMReentry::scopeReentryCount):
996         (JSC::DisallowVMReentry::setScopeReentryCount):
997         * runtime/InitializeThreading.cpp:
998         (JSC::initializeThreading):
999         * runtime/JSArray.cpp:
1000         (JSC::JSArray::tryCreateUninitializedRestricted):
1001         (JSC::JSArray::fastSlice):
1002         (JSC::JSArray::tryCreateForInitializationPrivate): Deleted.
1003         * runtime/JSArray.h:
1004         (JSC::JSArray::tryCreateUninitializedRestricted):
1005         (JSC::JSArray::tryCreate):
1006         (JSC::constructArray):
1007         (JSC::constructArrayNegativeIndexed):
1008         (JSC::JSArray::tryCreateForInitializationPrivate): Deleted.
1009         (JSC::createArrayButterfly): Deleted.
1010         * runtime/JSCellInlines.h:
1011         (JSC::allocateCell):
1012         * runtime/JSObject.h:
1013         (JSC::JSObject::initializeIndex):
1014         (JSC::JSObject::initializeIndexWithoutBarrier):
1015         * runtime/ObjectInitializationScope.cpp: Added.
1016         (JSC::ObjectInitializationScope::ObjectInitializationScope):
1017         (JSC::ObjectInitializationScope::~ObjectInitializationScope):
1018         (JSC::ObjectInitializationScope::notifyAllocated):
1019         (JSC::ObjectInitializationScope::verifyPropertiesAreInitialized):
1020         * runtime/ObjectInitializationScope.h: Added.
1021         (JSC::ObjectInitializationScope::ObjectInitializationScope):
1022         (JSC::ObjectInitializationScope::vm):
1023         (JSC::ObjectInitializationScope::notifyAllocated):
1024         * runtime/Operations.h:
1025         (JSC::isScribbledValue):
1026         (JSC::scribble):
1027         * runtime/RegExpMatchesArray.cpp:
1028         (JSC::createEmptyRegExpMatchesArray):
1029         * runtime/RegExpMatchesArray.h:
1030         (JSC::tryCreateUninitializedRegExpMatchesArray):
1031         (JSC::createRegExpMatchesArray):
1032         * runtime/VMEntryScope.cpp:
1033         (JSC::VMEntryScope::VMEntryScope):
1034
1035 2017-04-27  Carlos Garcia Campos  <cgarcia@igalia.com>
1036
1037         [GTK] Remote inspector should support inspecting targets with previous version of backend commands
1038         https://bugs.webkit.org/show_bug.cgi?id=171267
1039
1040         Reviewed by Michael Catanzaro.
1041
1042         Rename GetTargetList DBus method as SetupInspectorClient since this method is actually called only once by
1043         client right after connecting to the server. The method now receives the client backend commands hash as
1044         argument and returns the contents of the backend commands file in case the hash doesn't match with the local
1045         version.
1046
1047         * PlatformGTK.cmake: Add RemoteInspectorUtils to compilation.
1048         * inspector/remote/glib/RemoteInspectorServer.cpp:
1049         (Inspector::RemoteInspectorServer::setupInspectorClient):
1050         * inspector/remote/glib/RemoteInspectorServer.h:
1051         * inspector/remote/glib/RemoteInspectorUtils.cpp: Added.
1052         (Inspector::backendCommands):
1053         (Inspector::backendCommandsHash):
1054         * inspector/remote/glib/RemoteInspectorUtils.h: Added.
1055
1056 2017-04-27  Yusuke Suzuki  <utatane.tea@gmail.com>
1057
1058         [JSC] Handle PhantomSpread in LoadVarargs as the same to the others
1059         https://bugs.webkit.org/show_bug.cgi?id=171262
1060
1061         Reviewed by Saam Barati.
1062
1063         This is follow-up patch after r215720. In that patch, accidentally
1064         we did not apply the same change to LoadVarargs in argument elimination
1065         phase. This patch just does the same rewriting to handle PhantomSpread
1066         correctly.
1067
1068         * dfg/DFGArgumentsEliminationPhase.cpp:
1069
1070 2017-04-26  Joseph Pecoraro  <pecoraro@apple.com>
1071
1072         Web Inspector: Uint8ClampedArray should be treated like an array, not an object
1073         https://bugs.webkit.org/show_bug.cgi?id=171364
1074         <rdar://problem/10873037>
1075
1076         Reviewed by Sam Weinig.
1077
1078         * inspector/JSInjectedScriptHost.cpp:
1079         (Inspector::JSInjectedScriptHost::subtype):
1080         Treat Uint8ClampedArray (like other Typed Arrays) as an array.
1081
1082 2017-04-26  Saam Barati  <sbarati@apple.com>
1083
1084         Print Wasm function index in stack trace
1085         https://bugs.webkit.org/show_bug.cgi?id=171349
1086
1087         Reviewed by JF Bastien.
1088
1089         This patch prints a Callee's index in the function index
1090         space in Error.stack.
1091
1092         This will lead to stack traces that have lines of text like:
1093         wasm function index: 4@[wasm code]
1094
1095         We don't ascribe indices to everything in wasm. Specifically, the
1096         Wasm->JS call stub callee does not get a name, and neither does
1097         the JS -> Wasm entrypoint.
1098
1099         * interpreter/Interpreter.cpp:
1100         (JSC::GetStackTraceFunctor::operator()):
1101         * interpreter/StackVisitor.cpp:
1102         (JSC::StackVisitor::readNonInlinedFrame):
1103         (JSC::StackVisitor::Frame::functionName):
1104         * interpreter/StackVisitor.h:
1105         (JSC::StackVisitor::Frame::wasmFunctionIndex):
1106         * runtime/StackFrame.cpp:
1107         (JSC::StackFrame::functionName):
1108         * runtime/StackFrame.h:
1109         (JSC::StackFrame::StackFrame):
1110         (JSC::StackFrame::wasm):
1111         (JSC::StackFrame::hasBytecodeOffset):
1112         (JSC::StackFrame::bytecodeOffset):
1113         * wasm/WasmBBQPlanInlines.h:
1114         (JSC::Wasm::BBQPlan::initializeCallees):
1115         * wasm/WasmCallee.cpp:
1116         (JSC::Wasm::Callee::Callee):
1117         * wasm/WasmCallee.h:
1118         (JSC::Wasm::Callee::create):
1119         (JSC::Wasm::Callee::index):
1120         * wasm/WasmOMGPlan.cpp:
1121         (JSC::Wasm::OMGPlan::work):
1122
1123 2017-04-26  Keith Miller  <keith_miller@apple.com>
1124
1125         Follow up to r215843
1126         https://bugs.webkit.org/show_bug.cgi?id=171361
1127
1128         Reviewed by Saam Barati.
1129
1130         This patch fixes some style comments Saam didn't get a chance to
1131         request before I landed: https://bugs.webkit.org/show_bug.cgi?id=170134.
1132
1133         It renames Wasm::CodeBlock::m_wasmEntrypoints to
1134         m_wasmIndirectCallEntrypoints, as well as fixes some copyrights and
1135         indentation.
1136
1137         * wasm/WasmBBQPlan.cpp:
1138         * wasm/WasmCodeBlock.cpp:
1139         (JSC::Wasm::CodeBlock::CodeBlock):
1140         * wasm/WasmCodeBlock.h:
1141         (JSC::Wasm::CodeBlock::wasmEntrypointLoadLocationFromFunctionIndexSpace):
1142         * wasm/WasmOMGPlan.cpp:
1143         (JSC::Wasm::OMGPlan::work):
1144         * wasm/WasmTierUpCount.h:
1145         (JSC::Wasm::TierUpCount::TierUpCount):
1146         (JSC::Wasm::TierUpCount::loopDecrement):
1147         (JSC::Wasm::TierUpCount::functionEntryDecrement):
1148         (JSC::Wasm::TierUpCount::shouldStartTierUp):
1149         (JSC::Wasm::TierUpCount::count):
1150
1151 2017-04-26  Saam Barati  <sbarati@apple.com>
1152
1153         ASSERTION FAILED: inIndex != notFound in JSC::invalidParameterInSourceAppender()
1154         https://bugs.webkit.org/show_bug.cgi?id=170924
1155         <rdar://problem/31721052>
1156
1157         Reviewed by Mark Lam.
1158
1159         The error message handler for "in" was searching for the literal
1160         string "in". However, our parser incorrectly allows escaped characters
1161         to be part of keywords. So this is parsed as "in" in JSC: "i\u006E".
1162         It should not be parsed that way. I opened https://bugs.webkit.org/show_bug.cgi?id=171310
1163         to address this issue.
1164         
1165         Regardless, the error message handlers should handle unexpected text gracefully.
1166         All functions that try to augment error messages with the goal of
1167         providing a more textual context for the error message should use
1168         the original error message instead of crashing when they detect
1169         unexpected text.
1170         
1171         This patch also changes the already buggy code that tries to find
1172         the base of a function call. That could would fail for code like this:
1173         "zoo.bar("/abc\)*/");". See https://bugs.webkit.org/show_bug.cgi?id=146304
1174         It would think that the base is "z". However, the algorithm that tries
1175         to find the base can often tell when it fails, and when it does, it should
1176         happily return the approximate text error message instead of thinking
1177         that the base is "z".
1178
1179         * runtime/ExceptionHelpers.cpp:
1180         (JSC::functionCallBase):
1181         (JSC::notAFunctionSourceAppender):
1182         (JSC::invalidParameterInSourceAppender):
1183
1184 2017-04-26  Keith Miller  <keith_miller@apple.com>
1185
1186         WebAssembly: Implement tier up
1187         https://bugs.webkit.org/show_bug.cgi?id=170134
1188
1189         Reviewed by Filip Pizlo.
1190
1191         This patch implements tier up for wasm functions. Unlike with JS
1192         code, wasm code needs to be able to tier up concurrently with the
1193         running code.  Since JS code is synchronous we can always link on
1194         the running thread, wasm, however, can run the same code on more
1195         than one thread. In order to make patching work correctly, we need
1196         to ensure that all patches of callsites are aligned. On ARM we get
1197         this for free since every call is a near call. On X86 we ensure
1198         that the 32-bit relative offset is 32-bit aligned.
1199
1200         This patch also modifies how Wasm::Plan works. Now Plan is a
1201         abstract super class and there are two subclasses, which
1202         correspond to the different tiers of our wasm engine.  The first,
1203         Build Bytecode Quickly (BBQ) tier, roughly does what the old plan
1204         code did before.  The new tier, Optimized Machine code Generation
1205         (OMG), can be called at any point by BBQ code and compiles exactly
1206         one function. Once an OMGPlan finishes it will link it's code
1207         internally then reset the instruction cache of all running wasm
1208         threads, via, a ThreadMessage. Once the instruction caches have
1209         been reset all the other functions will be patched to call the new
1210         code.
1211
1212         * JavaScriptCore.xcodeproj/project.pbxproj:
1213         * assembler/AbstractMacroAssembler.h:
1214         (JSC::AbstractMacroAssembler::ensureCacheLineSpace):
1215         * assembler/CodeLocation.h:
1216         (JSC::CodeLocationThreadSafeNearCall::CodeLocationThreadSafeNearCall):
1217         * assembler/MacroAssemblerARM64.h:
1218         (JSC::MacroAssemblerARM64::threadSafePatchableNearCall):
1219         * assembler/MacroAssemblerX86Common.h:
1220         (JSC::MacroAssemblerX86Common::threadSafeNearCall):
1221         * assembler/MacroAssemblerX86_64.h:
1222         (JSC::MacroAssemblerX86_64::threadSafePatchableNearCall):
1223         * b3/air/AirEmitShuffle.cpp:
1224         (JSC::B3::Air::ShufflePair::inst):
1225         (JSC::B3::Air::ShufflePair::opcode): Deleted.
1226         * b3/air/AirEmitShuffle.h:
1227         * jsc.cpp:
1228         (functionTestWasmModuleFunctions):
1229         * runtime/JSLock.cpp:
1230         (JSC::JSLock::didAcquireLock):
1231         * runtime/Options.h:
1232         * wasm/WasmB3IRGenerator.cpp:
1233         (JSC::Wasm::B3IRGenerator::materializeWasmContext):
1234         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
1235         (JSC::Wasm::B3IRGenerator::constant):
1236         (JSC::Wasm::B3IRGenerator::emitTierUpCheck):
1237         (JSC::Wasm::B3IRGenerator::addLoop):
1238         (JSC::Wasm::B3IRGenerator::addTopLevel):
1239         (JSC::Wasm::B3IRGenerator::addBlock):
1240         (JSC::Wasm::createJSToWasmWrapper):
1241         (JSC::Wasm::parseAndCompile):
1242         * wasm/WasmB3IRGenerator.h:
1243         * wasm/WasmBBQPlan.cpp: Copied from Source/JavaScriptCore/wasm/WasmPlan.cpp.
1244         (JSC::Wasm::BBQPlan::BBQPlan):
1245         (JSC::Wasm::BBQPlan::stateString):
1246         (JSC::Wasm::BBQPlan::moveToState):
1247         (JSC::Wasm::BBQPlan::parseAndValidateModule):
1248         (JSC::Wasm::BBQPlan::prepare):
1249         (JSC::Wasm::BBQPlan::ThreadCountHolder::ThreadCountHolder):
1250         (JSC::Wasm::BBQPlan::ThreadCountHolder::~ThreadCountHolder):
1251         (JSC::Wasm::BBQPlan::compileFunctions):
1252         (JSC::Wasm::BBQPlan::complete):
1253         (JSC::Wasm::BBQPlan::work):
1254         * wasm/WasmBBQPlan.h: Copied from Source/JavaScriptCore/wasm/WasmPlan.h.
1255         * wasm/WasmBBQPlanInlines.h: Copied from Source/JavaScriptCore/wasm/WasmPlanInlines.h.
1256         (JSC::Wasm::BBQPlan::initializeCallees):
1257         * wasm/WasmBinding.cpp:
1258         (JSC::Wasm::wasmToWasm):
1259         * wasm/WasmCallee.h:
1260         (JSC::Wasm::Callee::entrypoint):
1261         * wasm/WasmCodeBlock.cpp:
1262         (JSC::Wasm::CodeBlock::CodeBlock):
1263         * wasm/WasmCodeBlock.h:
1264         (JSC::Wasm::CodeBlock::jsEntrypointCalleeFromFunctionIndexSpace):
1265         (JSC::Wasm::CodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace):
1266         (JSC::Wasm::CodeBlock::wasmEntrypointLoadLocationFromFunctionIndexSpace):
1267         (JSC::Wasm::CodeBlock::tierUpCount):
1268         (JSC::Wasm::CodeBlock::mode):
1269         * wasm/WasmFormat.h:
1270         (JSC::Wasm::CallableFunction::CallableFunction):
1271         (JSC::Wasm::CallableFunction::offsetOfWasmEntrypointLoadLocation):
1272         * wasm/WasmMachineThreads.cpp: Copied from Source/JavaScriptCore/wasm/WasmPlanInlines.h.
1273         (JSC::Wasm::wasmThreads):
1274         (JSC::Wasm::startTrackingCurrentThread):
1275         (JSC::Wasm::resetInstructionCacheOnAllThreads):
1276         * wasm/WasmMachineThreads.h: Copied from Source/JavaScriptCore/wasm/WasmCallee.h.
1277         * wasm/WasmModule.cpp:
1278         (JSC::Wasm::makeValidationResult):
1279         (JSC::Wasm::makeValidationCallback):
1280         (JSC::Wasm::Module::validateSync):
1281         (JSC::Wasm::Module::validateAsync):
1282         * wasm/WasmModule.h:
1283         (JSC::Wasm::Module::codeBlockFor):
1284         * wasm/WasmOMGPlan.cpp: Added.
1285         (JSC::Wasm::OMGPlan::OMGPlan):
1286         (JSC::Wasm::OMGPlan::work):
1287         (JSC::Wasm::runOMGPlanForIndex):
1288         * wasm/WasmOMGPlan.h: Copied from Source/JavaScriptCore/wasm/WasmPlanInlines.h.
1289         * wasm/WasmPlan.cpp:
1290         (JSC::Wasm::Plan::Plan):
1291         (JSC::Wasm::Plan::runCompletionTasks):
1292         (JSC::Wasm::Plan::addCompletionTask):
1293         (JSC::Wasm::Plan::waitForCompletion):
1294         (JSC::Wasm::Plan::tryRemoveVMAndCancelIfLast):
1295         (JSC::Wasm::Plan::fail):
1296         (JSC::Wasm::Plan::stateString): Deleted.
1297         (JSC::Wasm::Plan::moveToState): Deleted.
1298         (JSC::Wasm::Plan::parseAndValidateModule): Deleted.
1299         (JSC::Wasm::Plan::prepare): Deleted.
1300         (JSC::Wasm::Plan::ThreadCountHolder::ThreadCountHolder): Deleted.
1301         (JSC::Wasm::Plan::ThreadCountHolder::~ThreadCountHolder): Deleted.
1302         (JSC::Wasm::Plan::compileFunctions): Deleted.
1303         (JSC::Wasm::Plan::complete): Deleted.
1304         * wasm/WasmPlan.h:
1305         (JSC::Wasm::Plan::exports): Deleted.
1306         (JSC::Wasm::Plan::internalFunctionCount): Deleted.
1307         (JSC::Wasm::Plan::takeModuleInformation): Deleted.
1308         (JSC::Wasm::Plan::takeCallLinkInfos): Deleted.
1309         (JSC::Wasm::Plan::takeWasmToWasmExitStubs): Deleted.
1310         (JSC::Wasm::Plan::hasWork): Deleted.
1311         (JSC::Wasm::Plan::hasBeenPrepared): Deleted.
1312         * wasm/WasmTierUpCount.h: Renamed from Source/JavaScriptCore/wasm/WasmPlanInlines.h.
1313         (JSC::Wasm::TierUpCount::TierUpCount):
1314         (JSC::Wasm::TierUpCount::loopDecrement):
1315         (JSC::Wasm::TierUpCount::functionEntryDecrement):
1316         (JSC::Wasm::TierUpCount::shouldStartTierUp):
1317         (JSC::Wasm::TierUpCount::count):
1318         * wasm/WasmWorklist.cpp:
1319         * wasm/WasmWorklist.h:
1320         (JSC::Wasm::Worklist::nextTicket):
1321         * wasm/js/JSWebAssemblyCodeBlock.cpp:
1322         * wasm/js/JSWebAssemblyCodeBlock.h:
1323         (JSC::JSWebAssemblyCodeBlock::wasmEntrypointLoadLocationFromFunctionIndexSpace):
1324         (JSC::JSWebAssemblyCodeBlock::wasmToJsCallStubForImport):
1325         (JSC::JSWebAssemblyCodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace): Deleted.
1326         * wasm/js/JSWebAssemblyTable.cpp:
1327         (JSC::JSWebAssemblyTable::setFunction):
1328         * wasm/js/WebAssemblyFunction.cpp:
1329         (JSC::WebAssemblyFunction::create):
1330         (JSC::WebAssemblyFunction::WebAssemblyFunction):
1331         * wasm/js/WebAssemblyFunction.h:
1332         (JSC::WebAssemblyFunction::signatureIndex):
1333         (JSC::WebAssemblyFunction::wasmEntrypointLoadLocation):
1334         (JSC::WebAssemblyFunction::callableFunction):
1335         (JSC::WebAssemblyFunction::offsetOfWasmEntrypointLoadLocation):
1336         (JSC::WebAssemblyFunction::wasmEntrypoint): Deleted.
1337         (JSC::WebAssemblyFunction::offsetOfWasmEntrypoint): Deleted.
1338         * wasm/js/WebAssemblyModuleRecord.cpp:
1339         (JSC::WebAssemblyModuleRecord::link):
1340         (JSC::WebAssemblyModuleRecord::evaluate):
1341         * wasm/js/WebAssemblyPrototype.cpp:
1342         (JSC::webAssemblyValidateFunc):
1343         * wasm/js/WebAssemblyWrapperFunction.cpp:
1344         (JSC::WebAssemblyWrapperFunction::WebAssemblyWrapperFunction):
1345         (JSC::WebAssemblyWrapperFunction::create):
1346         * wasm/js/WebAssemblyWrapperFunction.h:
1347         (JSC::WebAssemblyWrapperFunction::signatureIndex):
1348         (JSC::WebAssemblyWrapperFunction::wasmEntrypointLoadLocation):
1349         (JSC::WebAssemblyWrapperFunction::callableFunction):
1350         (JSC::WebAssemblyWrapperFunction::wasmEntrypoint): Deleted.
1351
1352 2017-04-26  Caitlin Potter  <caitp@igalia.com>
1353
1354         [JSC] fix RETURN_IF_EXCEPTION() placement in ownPropertyKeys()
1355         https://bugs.webkit.org/show_bug.cgi?id=171330
1356
1357         Reviewed by Mark Lam.
1358
1359         Ensure RETURN_IF_EXCEPTION() following invokation of the
1360         filterPropertyIfNeeded() lambda.
1361
1362         * runtime/ObjectConstructor.cpp:
1363         (JSC::ownPropertyKeys):
1364
1365 2017-04-26  Caitlin Potter  <caitp@igalia.com>
1366
1367         [JSC] Object.keys() must discard property names with no PropertyDescriptor
1368         https://bugs.webkit.org/show_bug.cgi?id=171291
1369
1370         Reviewed by Yusuke Suzuki.
1371
1372         Proxy objects can produce an arbitrary list of property names from the
1373         "ownKeys" trap, however the Object.keys() algorithm is required to
1374         discard names which do not have a PropertyDescriptor. This also
1375         applies to other uses of the EnumerableOwnProperties() algorithm
1376         (https://tc39.github.io/ecma262/#sec-enumerableownproperties)
1377
1378         Related to https://bugs.chromium.org/p/v8/issues/detail?id=6290
1379
1380         * runtime/ObjectConstructor.cpp:
1381         (JSC::ownPropertyKeys):
1382
1383 2017-04-25  Andy VanWagoner  <thetalecrafter@gmail.com>
1384
1385         Unhandled enumeration values in IntlDateTimeFormat.cpp
1386         https://bugs.webkit.org/show_bug.cgi?id=171241
1387
1388         Reviewed by JF Bastien.
1389
1390         Added some missing cases of the UDateFormatField to partTypeString,
1391         and made them conditional to the ICU version that added them.
1392         This should remove the warnings that appear on platform builds using the
1393         newer system ICU headers.
1394
1395         * runtime/IntlDateTimeFormat.cpp:
1396         (JSC::IntlDateTimeFormat::partTypeString):
1397
1398 2017-04-25  Commit Queue  <commit-queue@webkit.org>
1399
1400         Unreviewed, rolling out r215476.
1401         https://bugs.webkit.org/show_bug.cgi?id=171304
1402
1403         "It broke JSBench" (Requested by saamyjoon on #webkit).
1404
1405         Reverted changeset:
1406
1407         "[ES6]. Implement Annex B.3.3 function hoisting rules for
1408         eval"
1409         https://bugs.webkit.org/show_bug.cgi?id=163208
1410         http://trac.webkit.org/changeset/215476
1411
1412 2017-04-25  Saam Barati  <sbarati@apple.com>
1413
1414         JSArray::isArrayPrototypeIteratorProtocolFastAndNonObservable is wrong because it does not do the necessary checks on the base object
1415         https://bugs.webkit.org/show_bug.cgi?id=171150
1416         <rdar://problem/31771880>
1417
1418         Reviewed by Sam Weinig.
1419
1420         This patch fixes a huge oversight from the patch that introduced
1421         op_spread/Spread. The original patch did not account for the
1422         base object having Symbol.iterator or getters that could
1423         change the iterator protocol. This patch fixes the oversight both
1424         in the C code, as well as the DFG/FTL backends. We only perform
1425         the memcpy version of spread if we've proven that it's guaranteed
1426         to be side-effect free (no indexed getters), and if the iterator
1427         protocol is guaranteed to be the original protocol. To do this, we
1428         must prove that:
1429         1. The protocol on Array.prototype hasn't changed (this is the same as the
1430         introductory patch for op_spread).
1431         2. The base object's __proto__ is Array.prototype
1432         3. The base object does not have indexed getters
1433         4. The base object does not have Symbol.iterator property.
1434
1435         * dfg/DFGGraph.cpp:
1436         (JSC::DFG::Graph::canDoFastSpread):
1437         * dfg/DFGGraph.h:
1438         * dfg/DFGSpeculativeJIT.cpp:
1439         (JSC::DFG::SpeculativeJIT::compileSpread):
1440         * ftl/FTLLowerDFGToB3.cpp:
1441         (JSC::FTL::DFG::LowerDFGToB3::compileSpread):
1442         * runtime/JSArray.cpp:
1443         (JSC::JSArray::isIteratorProtocolFastAndNonObservable):
1444         * runtime/JSArray.h:
1445         * runtime/JSArrayInlines.h:
1446         (JSC::JSArray::isIteratorProtocolFastAndNonObservable): Deleted.
1447         * runtime/JSGlobalObject.h:
1448         * runtime/JSGlobalObjectInlines.h:
1449         (JSC::JSGlobalObject::isArrayPrototypeIteratorProtocolFastAndNonObservable):
1450         (JSC::JSGlobalObject::isArrayIteratorProtocolFastAndNonObservable): Deleted.
1451
1452 2017-04-25  Mark Lam  <mark.lam@apple.com>
1453
1454         Array.prototype.slice() should ensure that end >= begin.
1455         https://bugs.webkit.org/show_bug.cgi?id=170989
1456         <rdar://problem/31705652>
1457
1458         Reviewed by Saam Barati.
1459
1460         * runtime/ArrayPrototype.cpp:
1461         (JSC::arrayProtoFuncSlice):
1462
1463 2017-04-25  Don Olmstead  <don.olmstead@am.sony.com>
1464
1465         [Win] Use Clang's __has_declspec_attribute for export macros
1466         https://bugs.webkit.org/show_bug.cgi?id=171240
1467
1468         Reviewed by Alex Christensen.
1469
1470         * runtime/JSExportMacros.h:
1471
1472 2017-04-25  Saam Barati  <sbarati@apple.com>
1473
1474         Unreviewed. Attempt armv7k build fix after r215720
1475
1476         I think we're just missing an include for the definition of ExecState::r().
1477
1478         * runtime/JSFixedArray.cpp:
1479
1480 2017-04-25  Daniel Bates  <dabates@apple.com>
1481
1482         [Cocoa][Win] Enable of X-Content-Type-Options: nosniff header
1483         https://bugs.webkit.org/show_bug.cgi?id=136452
1484         <rdar://problem/23412620>
1485
1486         Reviewed by Brent Fulgham.
1487
1488         Enable X-Content-Type-Options: nosniff on Mac, iOS and Windows platforms.
1489
1490         * Configurations/FeatureDefines.xcconfig:
1491
1492 2017-04-25  Mark Lam  <mark.lam@apple.com>
1493
1494         Local CSE wrongly CSEs array accesses with different result types.
1495         https://bugs.webkit.org/show_bug.cgi?id=170990
1496         <rdar://problem/31705945>
1497
1498         Reviewed by Saam Barati.
1499
1500         The fix is to use different LocationKind enums for the different type of array
1501         result types.  This makes the HeapLocation values different based on the result
1502         types, and allows CSE to discern between them.
1503
1504         * dfg/DFGCSEPhase.cpp:
1505         * dfg/DFGClobberize.h:
1506         (JSC::DFG::clobberize):
1507         * dfg/DFGHeapLocation.cpp:
1508         (WTF::printInternal):
1509         * dfg/DFGHeapLocation.h:
1510         (JSC::DFG::indexedPropertyLocForResultType):
1511
1512 2017-04-25  Mark Lam  <mark.lam@apple.com>
1513
1514         Make DFG SpeculatedType dumps easier to read.
1515         https://bugs.webkit.org/show_bug.cgi?id=171280
1516
1517         Reviewed by Saam Barati.
1518
1519         Adding a pretty printer to insert |s between each type string and changing the
1520         dumped strings to match the SpeculatedType names case-wise.
1521
1522         * bytecode/SpeculatedType.cpp:
1523         (JSC::PrettyPrinter::PrettyPrinter):
1524         (JSC::PrettyPrinter::print):
1525         (JSC::dumpSpeculation):
1526         * bytecode/SpeculatedType.h:
1527
1528 2017-04-25  JF Bastien  <jfbastien@apple.com>
1529
1530         lowerStackArgs: check Arg::addr.isValidForm when falling back to SP offsets
1531         https://bugs.webkit.org/show_bug.cgi?id=171278
1532
1533         Reviewed by Filip Pizlo.
1534
1535         lowerStackArgs checked that the FP offsets it tries to generate
1536         are valid form, but didn't check that the fallback was valid
1537         form. This lead to stackAddr's assertion being dead, and the
1538         MaroAssembler asserting way later on move / add when handed a huge
1539         immediate.
1540
1541         * b3/air/AirArg.cpp:
1542         (JSC::B3::Air::Arg::stackAddrImpl):
1543
1544 2017-04-25  Zan Dobersek  <zdobersek@igalia.com>
1545
1546         [aarch64] moveConditionally32(), moveConditionallyTest32() should move from/to 64-bit registers
1547         https://bugs.webkit.org/show_bug.cgi?id=170891
1548
1549         Reviewed by Saam Barati.
1550
1551         moveConditionally32() and moveConditionallyTest32() operations in
1552         MacroAssemblerARM64 properly perform comparisons and tests on 32-bit
1553         values, but end up performing the moves from and to 32-bit registers.
1554
1555         Move operations should instead be done on 64-bit registers, just like
1556         on the X86_64 platform. This is achieved by specifying 64 as the data
1557         size for the csel instructions.
1558
1559         * assembler/MacroAssemblerARM64.h:
1560         (JSC::MacroAssemblerARM64::moveConditionally32):
1561         (JSC::MacroAssemblerARM64::moveConditionallyTest32):
1562
1563 2017-04-24  Joseph Pecoraro  <pecoraro@apple.com>
1564
1565         test262: test262/test/language/expressions/object/method-definition/early-errors-object-method-duplicate-parameters.js
1566         https://bugs.webkit.org/show_bug.cgi?id=171190
1567
1568         Reviewed by Saam Barati.
1569
1570         * bytecompiler/BytecodeGenerator.cpp:
1571         (JSC::BytecodeGenerator::BytecodeGenerator):
1572         (JSC::BytecodeGenerator::emitNewFunctionExpressionCommon):
1573         (JSC::BytecodeGenerator::emitNewFunction):
1574         * bytecompiler/NodesCodegen.cpp:
1575         (JSC::FunctionNode::emitBytecode):
1576         (JSC::Scope::setSourceParseMode):
1577         * parser/ParserModes.h:
1578         (JSC::isFunctionParseMode):
1579         (JSC::isMethodParseMode):
1580         (JSC::isGeneratorOrAsyncFunctionWrapperParseMode):
1581         (JSC::isGeneratorParseMode):
1582         (JSC::isGeneratorWrapperParseMode):
1583         * runtime/FunctionExecutable.h:
1584         * runtime/JSFunction.cpp:
1585         (JSC::JSFunction::getOwnPropertySlot):
1586         Add a new GeneratorWrapperMethodMode parse mode. The other function types
1587         (async, arrow) already have a FunctionMode and a MethodMode. Give
1588         generators one as well. This lets isMethodParseMode actually be accurate.
1589
1590         * parser/Parser.cpp:
1591         (JSC::Parser<LexerType>::parseInner):
1592         (JSC::Parser<LexerType>::isArrowFunctionParameters):
1593         (JSC::Parser<LexerType>::parseFormalParameters):
1594         (JSC::stringForFunctionMode):
1595         (JSC::Parser<LexerType>::parseFunctionParameters):
1596         (JSC::Parser<LexerType>::parseFunctionInfo):
1597         (JSC::Parser<LexerType>::parseClass):
1598         (JSC::Parser<LexerType>::parsePropertyMethod):
1599         * parser/Parser.h:
1600         Add a duplicate parameter failure if there are duplicate parameters
1601         in method syntax.
1602
1603 2017-04-24  Andy VanWagoner  <thetalecrafter@gmail.com>
1604
1605         Clean up ICU headers
1606         https://bugs.webkit.org/show_bug.cgi?id=170997
1607
1608         Reviewed by JF Bastien.
1609
1610         Update all icu headers to 55.1
1611
1612         * icu/LICENSE: Update copyright
1613         * icu/README: Explain ICU headers for OS X better
1614         * icu/unicode/localpointer.h:
1615         (LocalPointer::LocalPointer):
1616         (LocalPointer::adoptInsteadAndCheckErrorCode):
1617         * icu/unicode/platform.h:
1618         * icu/unicode/putil.h:
1619         * icu/unicode/ucal.h:
1620         * icu/unicode/uchar.h:
1621         * icu/unicode/ucnv.h:
1622         * icu/unicode/ucol.h:
1623         * icu/unicode/uconfig.h:
1624         * icu/unicode/ucurr.h:
1625         * icu/unicode/udatpg.h:
1626         * icu/unicode/udisplaycontext.h:
1627         * icu/unicode/uformattable.h:
1628         * icu/unicode/uloc.h:
1629         * icu/unicode/umachine.h:
1630         * icu/unicode/unum.h:
1631         * icu/unicode/unumsys.h:
1632         * icu/unicode/urename.h:
1633         * icu/unicode/uscript.h:
1634         * icu/unicode/uset.h:
1635         * icu/unicode/ustring.h:
1636         * icu/unicode/utf8.h:
1637         * icu/unicode/utypes.h:
1638
1639 2017-04-24  Yusuke Suzuki  <utatane.tea@gmail.com>
1640
1641         [JSC] Use JSFixedArray directly when using call_varargs
1642         https://bugs.webkit.org/show_bug.cgi?id=171057
1643
1644         Reviewed by Saam Barati.
1645
1646         Previously we always emit new_array_with_spread when calling call(...args).
1647         But this array is unnecessary if varargs operation can handle Spread directly.
1648
1649         This patch implements a peep-hole optimization in the bytecode compiler layer
1650         to omit new_array_with_spread. This is very simple and effective because this
1651         peep-hole optimization is quite common when using (...args) style calls and
1652         this optimization works all the tiers. While we can implement the phase to
1653         omit this NewArrayWithSpread in argument elimination phase, it only works
1654         for FTL. While such an optimization can work with complex data flow, this
1655         peep-hole optimization can optimize a common case easily.
1656
1657         For now, Spread and PhantomSpread can be directly drained by CallVarargs
1658         and LoadVarargs related operations. We modify DFG and FTL to handle this correctly.
1659
1660         This shows six-speed improvement.
1661
1662             spread.es6                 89.4300+-2.0236     ^     69.6015+-1.7278        ^ definitely 1.2849x faster
1663             spread-generator.es6      344.7879+-5.9147     ^    331.2712+-6.8610        ^ definitely 1.0408x faster
1664
1665         * bytecompiler/BytecodeGenerator.cpp:
1666         (JSC::BytecodeGenerator::emitCall):
1667         (JSC::BytecodeGenerator::emitConstruct):
1668         * dfg/DFGArgumentsEliminationPhase.cpp:
1669         * dfg/DFGPreciseLocalClobberize.h:
1670         (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
1671         * ftl/FTLLowerDFGToB3.cpp:
1672         (JSC::FTL::DFG::LowerDFGToB3::compileSpread):
1673         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread):
1674         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
1675         (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargs):
1676         (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargsWithSpread):
1677         * interpreter/Interpreter.cpp:
1678         (JSC::sizeOfVarargs):
1679         (JSC::loadVarargs):
1680         * parser/Nodes.h:
1681         (JSC::ArrayNode::elements):
1682         * runtime/JSFixedArray.cpp:
1683         (JSC::JSFixedArray::copyToArguments):
1684         * runtime/JSFixedArray.h:
1685
1686 2017-04-24  Yusuke Suzuki  <utatane.tea@gmail.com>
1687
1688         [WTF] Move JSC tools/StackTrace to WTF and unify stack trace dump code
1689         https://bugs.webkit.org/show_bug.cgi?id=171199
1690
1691         Reviewed by Mark Lam.
1692
1693         This patch adds a utility method to produce demangled names with dladdr.
1694         It fixes several memory leaks because the result of abi::__cxa_demangle()
1695         needs to be `free`-ed.
1696
1697         * CMakeLists.txt:
1698         * JavaScriptCore.xcodeproj/project.pbxproj:
1699         * inspector/JSGlobalObjectInspectorController.cpp:
1700         (Inspector::JSGlobalObjectInspectorController::appendAPIBacktrace):
1701         * runtime/SamplingProfiler.cpp:
1702         (JSC::SamplingProfiler::StackFrame::displayName):
1703         * tools/CellProfile.h:
1704         * tools/CodeProfile.cpp:
1705         (JSC::CodeProfile::report):
1706         (JSC::symbolName): Deleted.
1707
1708 2017-04-24  Joseph Pecoraro  <pecoraro@apple.com>
1709
1710         Web Inspector: ObjC RWIProtocol codegen should better handle optional members
1711         https://bugs.webkit.org/show_bug.cgi?id=171251
1712         <rdar://problem/31697002>
1713
1714         Reviewed by Brian Burg.
1715
1716         * inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
1717         (ObjCProtocolTypesImplementationGenerator._generate_getter_for_member):
1718         * inspector/scripts/codegen/objc_generator.py:
1719         (ObjCGenerator.protocol_to_objc_expression_for_member):
1720         (ObjCGenerator.protocol_to_objc_code_block_for_object_member):
1721         Always be safe and nil check object property accesses, optional or not.
1722
1723         * inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result:
1724         * inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result:
1725         Rebaselined inspector generator tests.
1726
1727 2017-04-24  Saam Barati  <sbarati@apple.com>
1728
1729         ASSERTION FAILED: m_table seen with workers/wasm-hashset LayoutTests
1730         https://bugs.webkit.org/show_bug.cgi?id=171119
1731         <rdar://problem/31760635>
1732
1733         Reviewed by Keith Miller.
1734
1735         The HashSet of timer set notification callbacks can be accessed
1736         and augmented simultaneously from different threads. e.g, the worker
1737         thread can augment it while the wasm compilation thread will
1738         access it. Therefore, accesses must be guarded by a lock.
1739
1740         * runtime/JSRunLoopTimer.cpp:
1741         (JSC::JSRunLoopTimer::scheduleTimer):
1742         (JSC::JSRunLoopTimer::addTimerSetNotification):
1743         (JSC::JSRunLoopTimer::removeTimerSetNotification):
1744         * runtime/JSRunLoopTimer.h:
1745
1746 2017-04-24  Joseph Pecoraro  <pecoraro@apple.com>
1747
1748         test262: test262/test/language/computed-property-names/class/static/getter-prototype.js
1749         https://bugs.webkit.org/show_bug.cgi?id=170897
1750
1751         Reviewed by Saam Barati.
1752
1753         * parser/ASTBuilder.h:
1754         (JSC::ASTBuilder::createArguments):
1755         (JSC::ASTBuilder::createArgumentsList):
1756         Reorder so all the createProperty methods are grouped together.
1757
1758         * parser/Parser.h:
1759         * parser/Parser.cpp:
1760         (JSC::Parser<LexerType>::parseClass):
1761         (JSC::Parser<LexerType>::parseProperty):
1762         (JSC::Parser<LexerType>::parseGetterSetter):
1763         Refine the conditions for syntax errors for getter/setter
1764         properties names. "prototype" is not allowed as a static
1765         and "constructor" is not all when non-static.
1766
1767         * runtime/JSObject.cpp:
1768         (JSC::JSObject::putGetter):
1769         (JSC::JSObject::putSetter):
1770         Throw exceptions. These methods are only used by this path
1771         via op_put_getter_by_val / op_put_setter_by_val.
1772
1773 2017-04-24  Joseph Pecoraro  <pecoraro@apple.com>
1774
1775         test262: test262/test/language/statements/for-of/dstr-array-elem-init-fn-name-arrow.js
1776         https://bugs.webkit.org/show_bug.cgi?id=171160
1777
1778         Reviewed by JF Bastien.
1779
1780         * parser/ASTBuilder.h:
1781         (JSC::ASTBuilder::tryInferNameInPattern):
1782         (JSC::ASTBuilder::tryInferNameInPatternWithIdentifier):
1783         We supported getting the name from a BindingNode.
1784         We extend this to support getting the name from a
1785         ResolveNode inside of an AssignmentElementNode.
1786
1787         * parser/Nodes.h:
1788         (JSC::DestructuringPatternNode::isAssignmentElementNode):
1789         (JSC::AssignmentElementNode::isAssignmentElementNode):
1790         Make it possible to identify an assignment element node.
1791
1792 2017-04-24  Alex Christensen  <achristensen@webkit.org>
1793
1794         Reduce copies and allocations in SharedBuffer::append
1795         https://bugs.webkit.org/show_bug.cgi?id=170956
1796
1797         Reviewed by Andreas Kling.
1798
1799         * runtime/ArrayBuffer.h:
1800
1801 2017-04-24  Carlos Garcia Campos  <cgarcia@igalia.com>
1802
1803         [GTK] Switch to use ENABLE_REMOTE_INSPECTOR instead of ENABLE_INSPECTOR_SERVER for the remote inspector
1804         https://bugs.webkit.org/show_bug.cgi?id=166680
1805
1806         Reviewed by Michael Catanzaro.
1807
1808         Add GTK+ port implementation of RemoteInspector.
1809
1810         * PlatformGTK.cmake:
1811         * inspector/remote/RemoteConnectionToTarget.h:
1812         * inspector/remote/RemoteInspector.h:
1813         * inspector/remote/glib/RemoteConnectionToTargetGlib.cpp: Added.
1814         (Inspector::RemoteConnectionToTarget::RemoteConnectionToTarget):
1815         (Inspector::RemoteConnectionToTarget::~RemoteConnectionToTarget):
1816         (Inspector::RemoteConnectionToTarget::setup):
1817         (Inspector::RemoteConnectionToTarget::sendMessageToTarget):
1818         (Inspector::RemoteConnectionToTarget::close):
1819         (Inspector::RemoteConnectionToTarget::targetClosed):
1820         (Inspector::RemoteConnectionToTarget::targetIdentifier):
1821         (Inspector::RemoteConnectionToTarget::sendMessageToFrontend):
1822         * inspector/remote/glib/RemoteInspectorGlib.cpp: Added.
1823         (Inspector::RemoteInspector::singleton):
1824         (Inspector::RemoteInspector::RemoteInspector):
1825         (Inspector::RemoteInspector::start):
1826         (Inspector::RemoteInspector::stopInternal):
1827         (Inspector::RemoteInspector::setupConnection):
1828         (Inspector::dbusConnectionCallAsyncReadyCallback):
1829         (Inspector::RemoteInspector::listingForInspectionTarget):
1830         (Inspector::RemoteInspector::listingForAutomationTarget):
1831         (Inspector::RemoteInspector::pushListingsNow):
1832         (Inspector::RemoteInspector::pushListingsSoon):
1833         (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
1834         (Inspector::RemoteInspector::sendAutomaticInspectionCandidateMessage):
1835         (Inspector::RemoteInspector::sendMessageToRemote):
1836         (Inspector::RemoteInspector::receivedGetTargetListMessage):
1837         (Inspector::RemoteInspector::receivedSetupMessage):
1838         (Inspector::RemoteInspector::receivedDataMessage):
1839         (Inspector::RemoteInspector::receivedCloseMessage):
1840         (Inspector::RemoteInspector::setup):
1841         (Inspector::RemoteInspector::sendMessageToTarget):
1842         (Inspector::RemoteInspector::requestAutomationSession):
1843         * inspector/remote/glib/RemoteInspectorServer.cpp: Added.
1844         (Inspector::generateConnectionID):
1845         (Inspector::RemoteInspectorServer::singleton):
1846         (Inspector::RemoteInspectorServer::~RemoteInspectorServer):
1847         (Inspector::RemoteInspectorServer::interfaceInfo):
1848         (Inspector::RemoteInspectorServer::start):
1849         (Inspector::RemoteInspectorServer::newConnectionCallback):
1850         (Inspector::RemoteInspectorServer::connectionClosedCallback):
1851         (Inspector::RemoteInspectorServer::newConnection):
1852         (Inspector::dbusConnectionCallAsyncReadyCallback):
1853         (Inspector::RemoteInspectorServer::setTargetList):
1854         (Inspector::RemoteInspectorServer::clientConnectionClosedCallback):
1855         (Inspector::RemoteInspectorServer::getTargetList):
1856         (Inspector::RemoteInspectorServer::setup):
1857         (Inspector::RemoteInspectorServer::close):
1858         (Inspector::RemoteInspectorServer::clientConnectionClosed):
1859         (Inspector::RemoteInspectorServer::connectionClosed):
1860         (Inspector::RemoteInspectorServer::sendMessageToBackend):
1861         (Inspector::RemoteInspectorServer::sendMessageToFrontend):
1862         (Inspector::RemoteInspectorServer::startAutomationSession):
1863         * inspector/remote/glib/RemoteInspectorServer.h: Added.
1864         (Inspector::RemoteInspectorServer::isRunning):
1865
1866 2017-04-24  Joseph Pecoraro  <pecoraro@apple.com>
1867
1868         test262: test262/test/language/expressions/generators/yield-as-label.js
1869         https://bugs.webkit.org/show_bug.cgi?id=170979
1870
1871         Reviewed by Saam Barati.
1872
1873         * parser/Parser.cpp:
1874         (JSC::Parser<LexerType>::parseVariableDeclarationList):
1875         (JSC::Parser<LexerType>::parseDestructuringPattern):
1876         (JSC::Parser<LexerType>::parseFormalParameters):
1877         Converge on "Cannot" instead of "Can't" in error messages.
1878
1879         (JSC::Parser<LexerType>::parseFunctionInfo):
1880         Disallow "yield" as the generator function name in function expressions.
1881         This refers to the difference between Declaration and Expression, where
1882         only GeneratorExpression explicitly has [+Yield] disallowing yield for
1883         the generator name:
1884
1885             GeneratorDeclaration[Yield, Await, Default]:
1886                 function * BindingIdentifier[?Yield, ?Await] ...
1887
1888             GeneratorExpression:
1889                 function * BindingIdentifier[+Yield, ~Await]opt ...
1890
1891         (JSC::Parser<LexerType>::parseExpressionOrLabelStatement):
1892         Disallow "yield" as a label name in strict mode or inside a generator.
1893
1894         (JSC::Parser<LexerType>::parseProperty):
1895         Disallow "yield" or any keyword in object literal shorthands.
1896
1897         * parser/Parser.h:
1898         (JSC::Parser::getToken):
1899         (JSC::Parser::isDisallowedIdentifierLet):
1900         (JSC::Parser::isDisallowedIdentifierYield):
1901         (JSC::Parser::disallowedIdentifierLetReason):
1902         (JSC::Parser::disallowedIdentifierYieldReason):
1903         Follow pattern for improved error messages based on context.
1904
1905 2017-04-23  Commit Queue  <commit-queue@webkit.org>
1906
1907         Unreviewed, rolling out r215674.
1908         https://bugs.webkit.org/show_bug.cgi?id=171212
1909
1910         Possible unintended commit. This patch was on the wrong bug.
1911         (Requested by JoePeck on #webkit).
1912
1913         Reverted changeset:
1914
1915         "test262: test262/test/language/expressions/generators/yield-
1916         as-label.js"
1917         https://bugs.webkit.org/show_bug.cgi?id=170979
1918         http://trac.webkit.org/changeset/215674
1919
1920 2017-04-23  Joseph Pecoraro  <pecoraro@apple.com>
1921
1922         test262: test262/test/built-ins/Number/prototype/toPrecision/nan.js
1923         https://bugs.webkit.org/show_bug.cgi?id=171197
1924
1925         Reviewed by Saam Barati.
1926
1927         * runtime/NumberPrototype.cpp:
1928         (JSC::numberProtoFuncToExponential):
1929         (JSC::numberProtoFuncToFixed):
1930         (JSC::numberProtoFuncToPrecision):
1931         Refine the order of operations to match the spec.
1932
1933 2017-04-23  Joseph Pecoraro  <pecoraro@apple.com>
1934
1935         test262: test262/test/language/expressions/generators/yield-as-label.js
1936         https://bugs.webkit.org/show_bug.cgi?id=170979
1937
1938         Reviewed by Saam Barati.
1939
1940         * parser/Parser.cpp:
1941         (JSC::Parser<LexerType>::parseVariableDeclarationList):
1942         (JSC::Parser<LexerType>::parseDestructuringPattern):
1943         (JSC::Parser<LexerType>::parseFormalParameters):
1944         Converge on "Cannot" instead of "Can't" in error messages.
1945
1946         (JSC::Parser<LexerType>::parseFunctionInfo):
1947         Disallow "yield" as the generator function name in function expressions.
1948         This refers to the difference between Declaration and Expression, where
1949         only GeneratorExpression explicitly has [+Yield] disallowing yield for
1950         the generator name:
1951
1952             GeneratorDeclaration[Yield, Await, Default]:
1953                 function * BindingIdentifier[?Yield, ?Await] ...
1954
1955             GeneratorExpression:
1956                 function * BindingIdentifier[+Yield, ~Await]opt ...
1957
1958         (JSC::Parser<LexerType>::parseExpressionOrLabelStatement):
1959         Disallow "yield" as a label name in strict mode or inside a generator.
1960
1961         (JSC::Parser<LexerType>::parseProperty):
1962         Disallow "yield" or any keyword in object literal shorthands.
1963
1964         * parser/Parser.h:
1965         (JSC::Parser::getToken):
1966         (JSC::Parser::isDisallowedIdentifierLet):
1967         (JSC::Parser::isDisallowedIdentifierYield):
1968         (JSC::Parser::disallowedIdentifierLetReason):
1969         (JSC::Parser::disallowedIdentifierYieldReason):
1970         Follow pattern for improved error messages based on context.
1971
1972 2017-04-23  Joseph Pecoraro  <pecoraro@apple.com>
1973
1974         test262: test262/test/built-ins/Number/parseFloat.js
1975         https://bugs.webkit.org/show_bug.cgi?id=171193
1976
1977         Reviewed by Yusuke Suzuki.
1978
1979         * runtime/CommonIdentifiers.h:
1980         * runtime/JSGlobalObject.cpp:
1981         (JSC::JSGlobalObject::init):
1982         (JSC::JSGlobalObject::visitChildren):
1983         * runtime/JSGlobalObject.h:
1984         (JSC::JSGlobalObject::parseFloatFunction):
1985         Expose parseFloat on the global object to be shared with Number constructor.
1986
1987         * runtime/NumberConstructor.cpp:
1988         (JSC::NumberConstructor::finishCreation):
1989         parseFloat uses the same value as the global parseFloat.
1990
1991 2017-04-22  Yusuke Suzuki  <utatane.tea@gmail.com>
1992
1993         [JSC] Use DoublyLinkedList for MachineThread
1994         https://bugs.webkit.org/show_bug.cgi?id=171171
1995
1996         Reviewed by Mark Lam.
1997
1998         MachineThread can use WTF::DoublyLinkedList to simplify
1999         its implementation. We should not use Vector<> etc. since
2000         we do not want to call allocations during suspending and
2001         resuming threads.
2002
2003         * heap/MachineStackMarker.cpp:
2004         (JSC::MachineThreads::MachineThreads):
2005         (JSC::MachineThreads::~MachineThreads):
2006         (JSC::MachineThreads::addCurrentThread):
2007         (JSC::MachineThreads::removeThreadIfFound):
2008         (JSC::MachineThreads::MachineThread::MachineThread):
2009         (JSC::MachineThreads::tryCopyOtherThreadStacks):
2010         * heap/MachineStackMarker.h:
2011         (JSC::MachineThreads::threadsListHead):
2012         * runtime/SamplingProfiler.cpp:
2013         (JSC::FrameWalker::isValidFramePointer):
2014         * runtime/VMTraps.cpp:
2015         (JSC::findActiveVMAndStackBounds):
2016
2017 2017-04-22  JF Bastien  <jfbastien@apple.com>
2018
2019         WebAssembly: Module.exports, Module.imports, Module.customSections are wrong
2020         https://bugs.webkit.org/show_bug.cgi?id=171078
2021
2022         Reviewed by Saam Barati.
2023
2024         They're static properties of Module, not instance properties of a module.
2025         https://github.com/WebAssembly/design/blob/master/JS.md#webassemblymoduleexports
2026
2027         * wasm/js/WebAssemblyModuleConstructor.cpp:
2028         (JSC::webAssemblyModuleCustomSections):
2029         (JSC::webAssemblyModuleImports):
2030         (JSC::webAssemblyModuleExports):
2031         * wasm/js/WebAssemblyModulePrototype.cpp:
2032         (JSC::webAssemblyModuleProtoCustomSections): Deleted.
2033         (JSC::webAssemblyModuleProtoImports): Deleted.
2034         (JSC::webAssemblyModuleProtoExports): Deleted.
2035
2036 2017-04-21  Saam Barati  <sbarati@apple.com>
2037
2038         SharedArrayBuffer-opt.js fails with Briggs
2039         https://bugs.webkit.org/show_bug.cgi?id=170948
2040         <rdar://problem/31740568>
2041
2042         Reviewed by Michael Saboff.
2043
2044         The bug was not actually with Briggs, but instead was with
2045         our X86-64 MacroAssembler. Michael fixed the bug here:
2046         https://trac.webkit.org/changeset/215618/webkit
2047         
2048         The issue was we weren't adding the REX byte for AtomicXchg8,
2049         leading to the incorrect encoding for the result register depending
2050         on which register it was. If you look at this code, you'll see the issue:
2051
2052           Int32 @38 = AtomicXchg(@59, @64, width = 8, range = 0, fenceRange = 0, ControlDependent|Fence|Writes:0|Reads:0, DFG:@49)
2053               AtomicXchg8 %rsi, (%rax,%rdx), @38
2054                   0x2dcb5bc0015e: lock xchg %dh, (%rax,%rdx)
2055           Int32 @66 = Const32(255, DFG:@49)
2056           Int32 @67 = BitAnd(@38, $255(@66), DFG:@49)
2057               ZeroExtend8To32 %rsi, %rax, @67
2058                   0x2dcb5bc00162: movzx %sil, %eax
2059
2060         Air thought the result was in the lower 8 bits of %rsi,
2061         however, the code we emitted stored it in the [8-15] bits
2062         of %rdx. Since this issue is fixed, I'm turning Briggs back
2063         on.
2064
2065         * b3/air/AirAllocateRegistersByGraphColoring.h:
2066         (JSC::B3::Air::useIRC):
2067
2068 2017-04-20  Mark Lam  <mark.lam@apple.com>
2069
2070         Refactor MASM probe to allow printing of custom types.
2071         https://bugs.webkit.org/show_bug.cgi?id=171101
2072
2073         Reviewed by JF Bastien.
2074
2075         For example, this allows us to add MASM printing of CodeBlock* and Air::Args.
2076
2077         In general, MASM print can be used like dataLog, except that it generates JITted
2078         code for doing the dataLogging later when the JITted code runs.  MASM print can
2079         print any value type that a specialized Printer template or a setPrinter()
2080         function implemented for that type.
2081
2082         * CMakeLists.txt:
2083         * JavaScriptCore.xcodeproj/project.pbxproj:
2084         * assembler/MacroAssembler.h:
2085
2086         * assembler/MacroAssemblerPrinter.cpp:
2087         (JSC::Printer::printAllRegisters):
2088         (JSC::Printer::printPCRegister):
2089         (JSC::Printer::printRegisterID):
2090         (JSC::Printer::printFPRegisterID):
2091         (JSC::Printer::printAddress):
2092         (JSC::Printer::printMemory):
2093         (JSC::Printer::printCallback):
2094         (JSC::printIndent): Deleted.
2095         (JSC::printCPU): Deleted.
2096         (JSC::printCPURegisters): Deleted.
2097         (JSC::printPC): Deleted.
2098         (JSC::printRegister): Deleted.
2099         (JSC::printMemory): Deleted.
2100         (JSC::MacroAssemblerPrinter::printCallback): Deleted.
2101         * assembler/MacroAssemblerPrinter.h:
2102         (JSC::AllRegisters::AllRegisters):
2103         (JSC::Printer::Printer<AllRegisters>::Printer):
2104         (JSC::Printer::Printer<PCRegister>::Printer):
2105         (JSC::Printer::Printer<MacroAssembler::RegisterID>::Printer):
2106         (JSC::Printer::Printer<MacroAssembler::FPRegisterID>::Printer):
2107         (JSC::Printer::Printer<MacroAssembler::Address>::Printer):
2108         (JSC::Printer::Printer<Memory>::Printer):
2109         (JSC::Printer::Printer<MemWord<IntType>>::Printer):
2110         (JSC::MacroAssembler::print):
2111         (JSC::MacroAssemblerPrinter::print): Deleted.
2112         (JSC::MacroAssemblerPrinter::PrintArg::PrintArg): Deleted.
2113         (JSC::MacroAssemblerPrinter::appendPrintArg): Deleted.
2114         - Refactored to move the underlying PrintRecord (and associated data structures)
2115           out to Printer.cpp/h.
2116         - MacroAssemblerPrinter.cpp/h now only add custom Printers for MASM types like
2117           RegisterID and Memory.  It also defines the implementation of
2118           MacroAssembler::print().
2119
2120           As before, JIT code that wishes to use MacroAssembler::print() needs to
2121           #include "MacroAssemblerPrinter.h".
2122
2123         - Also added the ability to specify an optional indentation (in number of chars)
2124           when MASM printing AllRegisters.  This is useful because AllRegisters prints
2125           a block of data unlike other printers which print inline.
2126
2127         * assembler/Printer.cpp: Added.
2128         (JSC::Printer::printConstCharString):
2129         (JSC::Printer::printIntptr):
2130         (JSC::Printer::printUintptr):
2131         (JSC::Printer::printPointer):
2132         (JSC::Printer::setPrinter):
2133         * assembler/Printer.h: Added.
2134         (JSC::Printer::Context::Context):
2135         (JSC::Printer::PrintRecord::PrintRecord):
2136         (JSC::Printer::appendPrinter):
2137         (JSC::Printer::makePrintRecordList):
2138         (JSC::Printer::Printer<RawPointer>::Printer):
2139         (JSC::Printer::setPrinter):
2140         (JSC::Printer::Printer::Printer):
2141         - Data structures for creating a list of PrintRecords.  Classes which wish to
2142           add custom support for MASM printing can #include "Printer.h" and implement
2143           either:
2144           1. a specialized Printer template, or
2145           2. a setPrinter() function.
2146
2147           See Printer<Reg> and Printer<B3::Air::Tmp> in AirPrintSpecial.h for examples of
2148           (1).  See CodeBlock's setPrinter() for an example of (2).
2149
2150         * b3/B3LowerToAir.cpp:
2151         (JSC::B3::Air::LowerToAir::print):
2152         * b3/air/AirPrintSpecial.cpp: Added.
2153         (JSC::B3::Air::PrintSpecial::PrintSpecial):
2154         (JSC::B3::Air::PrintSpecial::~PrintSpecial):
2155         (JSC::B3::Air::PrintSpecial::forEachArg):
2156         (JSC::B3::Air::PrintSpecial::isValid):
2157         (JSC::B3::Air::PrintSpecial::admitsStack):
2158         (JSC::B3::Air::PrintSpecial::reportUsedRegisters):
2159         (JSC::B3::Air::PrintSpecial::generate):
2160         (JSC::B3::Air::PrintSpecial::extraEarlyClobberedRegs):
2161         (JSC::B3::Air::PrintSpecial::extraClobberedRegs):
2162         (JSC::B3::Air::PrintSpecial::dumpImpl):
2163         (JSC::B3::Air::PrintSpecial::deepDumpImpl):
2164         (JSC::Printer::printAirArg):
2165         * b3/air/AirPrintSpecial.h: Added.
2166         (JSC::Printer::appendAirArg):
2167         (JSC::Printer::appendAirArgs):
2168         (JSC::Printer::Printer<B3::Air::Tmp>::Printer):
2169         (JSC::Printer::Printer<Reg>::Printer):
2170         - Add the print() operation for use in LowerToAir.  print() will emit a
2171           PrintSpecial that will ultimately emit a MASM print to print what we want.
2172         - LowerToAir's print() adds the ability to print Air::Args.
2173         - Unlike in the baseline JIT and the DFG, LowerToAir's print() can perturb the
2174           usage of registers.  This is because PrintSpecial is a patch point, and it
2175           prevents certain optimizations.  If not used carefully, an attempt to print()
2176           an Arg by taking a Tmp, can force the B3 Value into a Tmp earlier than it would
2177           otherwise do so.  So, use LowerToAir's print() with care.
2178
2179         * bytecode/CodeBlock.cpp:
2180         (JSC::setPrinter):
2181         - Now we can MASM print CodeBlock*.
2182         (WTF::printInternal):
2183         - Now we can dataLog CodeBlock* (including null CodeBlock pointers).
2184
2185         * bytecode/CodeBlock.h:
2186
2187         * runtime/VM.cpp:
2188         (JSC::VM::throwException):
2189         - Use the new ability to dataLog CodeBlock*.  No need to do an explicit null
2190           check before printing anymore.
2191
2192 2017-04-21  Keith Miller  <keith_miller@apple.com>
2193
2194         Unreviewed, rolling out r215634.
2195
2196         underlying build issues should have been fixed
2197
2198         Reverted changeset:
2199
2200         "Unreviewed, rolling out r215620 and r215623."
2201         https://bugs.webkit.org/show_bug.cgi?id=171139
2202         http://trac.webkit.org/changeset/215634
2203
2204 2017-04-21  Commit Queue  <commit-queue@webkit.org>
2205
2206         Unreviewed, rolling out r215620 and r215623.
2207         https://bugs.webkit.org/show_bug.cgi?id=171139
2208
2209         broke arm64 build (Requested by keith_miller on #webkit).
2210
2211         Reverted changesets:
2212
2213         "Add signaling API"
2214         https://bugs.webkit.org/show_bug.cgi?id=170976
2215         http://trac.webkit.org/changeset/215620
2216
2217         "Unreviewed, fix Cloop build."
2218         http://trac.webkit.org/changeset/215623
2219
2220 2017-04-21  Keith Miller  <keith_miller@apple.com>
2221
2222         Remove LL/SC from Atomics
2223         https://bugs.webkit.org/show_bug.cgi?id=171141
2224
2225         Reviewed by Saam Barati.
2226
2227         Adding load link and store conditionally was not an actual progression
2228         and the existing code is causing problems for users of Atomics. So let's
2229         get rid of it.
2230
2231         * heap/LargeAllocation.h:
2232         (JSC::LargeAllocation::testAndSetMarked):
2233         * heap/MarkedBlock.h:
2234         (JSC::MarkedBlock::testAndSetMarked):
2235         * heap/SlotVisitor.cpp:
2236         (JSC::SlotVisitor::setMarkedAndAppendToMarkStack):
2237
2238 2017-04-21  Keith Miller  <keith_miller@apple.com>
2239
2240         Unreviewed, fix Cloop build.
2241
2242         * jit/ExecutableAllocator.h:
2243         (JSC::isJITPC):
2244
2245 2017-04-20  Keith Miller  <keith_miller@apple.com>
2246
2247         Add signaling API
2248         https://bugs.webkit.org/show_bug.cgi?id=170976
2249
2250         Reviewed by Filip Pizlo.
2251
2252         Update various uses of sigaction to use the new signaling API.
2253         Also switch VMTraps to use the thread message system instead of
2254         rolling it's own.
2255
2256         * jit/ExecutableAllocator.h:
2257         (JSC::isJITPC):
2258         * runtime/VMTraps.cpp:
2259         (JSC::installSignalHandler):
2260         (JSC::VMTraps::VMTraps):
2261         (JSC::VMTraps::SignalSender::send):
2262         (JSC::handleSigusr1): Deleted.
2263         (JSC::handleSigtrap): Deleted.
2264         (JSC::installSignalHandlers): Deleted.
2265         * runtime/VMTraps.h:
2266         * tools/SigillCrashAnalyzer.cpp:
2267         (JSC::installCrashHandler):
2268         (JSC::handleCrash): Deleted.
2269         * wasm/WasmFaultSignalHandler.cpp:
2270         (JSC::Wasm::trapHandler):
2271         (JSC::Wasm::enableFastMemory):
2272
2273 2017-04-21  Michael Saboff  <msaboff@apple.com>
2274
2275         X86-64 Assembler doesn't handle xchg with byte register src
2276         https://bugs.webkit.org/show_bug.cgi?id=171118
2277
2278         Reviewed by Saam Barati.
2279
2280         * assembler/X86Assembler.h:
2281         (JSC::X86Assembler::xchgb_rm): Use oneByteOp8() since these are 8 bit opcodes.
2282
2283 2017-04-21  Andy VanWagoner  <thetalecrafter@gmail.com>
2284
2285         [INTL] Implement Intl.DateTimeFormat.prototype.formatToParts
2286         https://bugs.webkit.org/show_bug.cgi?id=169458
2287
2288         Reviewed by JF Bastien.
2289
2290         Use udat_formatForFields to iterate through the parts of a formatted date string.
2291         Make formatToParts and related functions dependent on ICU version >= 55.
2292
2293         * icu/unicode/udat.h: Update to 55.1.
2294         * icu/unicode/ufieldpositer.h: Added from 55.1.
2295         * icu/unicode/uvernum.h: Update to 55.1
2296         * runtime/IntlDateTimeFormat.cpp:
2297         (JSC::IntlDateTimeFormat::partTypeString): Convert UDateFormatField to string.
2298         (JSC::IntlDateTimeFormat::formatToParts): Return parts of formatted date string.
2299         * runtime/IntlDateTimeFormat.h:
2300         * runtime/IntlDateTimeFormatPrototype.cpp:
2301         (JSC::IntlDateTimeFormatPrototypeFuncFormatToParts): Add prototype function formatToParts.
2302
2303 2017-04-20  Konstantin Tokarev  <annulen@yandex.ru>
2304
2305         [cmake] Define FORWARDING_HEADERS_DIR in WebKitFS and use it everywhere
2306         https://bugs.webkit.org/show_bug.cgi?id=171071
2307
2308         Reviewed by Michael Catanzaro.
2309
2310         "${DERIVED_SOURCES_DIR}/ForwardingHeaders" path occurs very often in the
2311         build system files. GTK-specifc FORWARDING_HEADERS_DIR variable should
2312         be available for all ports.
2313
2314         * CMakeLists.txt:
2315         * PlatformWin.cmake:
2316
2317 2017-04-20  Konstantin Tokarev  <annulen@yandex.ru>
2318
2319         Remove unused lamda captures
2320         https://bugs.webkit.org/show_bug.cgi?id=171098
2321
2322         Reviewed by Yusuke Suzuki.
2323
2324         * bytecompiler/NodesCodegen.cpp:
2325         (JSC::ArrayNode::emitBytecode):
2326         * ftl/FTLState.cpp:
2327         (JSC::FTL::State::State):
2328         * wasm/WasmB3IRGenerator.cpp:
2329
2330 2017-04-20  Yusuke Suzuki  <utatane.tea@gmail.com>
2331
2332         [JSC][FTL] FTL should support Arrayify
2333         https://bugs.webkit.org/show_bug.cgi?id=169596
2334
2335         Reviewed by Saam Barati.
2336
2337         This patch simply expands the coverage of FTL by supporting Arrayify.
2338         While ArrayifyToStructure is already supported, Arrayify is not supported
2339         in FTL. While supporting Arrayify in FTL itself does not offer so much
2340         performance difference from DFG's one, no FTL support for Arrayify
2341         prevents us applying FTL to the code including Arrayify.
2342
2343         * dfg/DFGArrayMode.cpp:
2344         (JSC::DFG::toIndexingShape):
2345         * dfg/DFGSpeculativeJIT.cpp:
2346         (JSC::DFG::SpeculativeJIT::jumpSlowForUnwantedArrayMode):
2347         * ftl/FTLCapabilities.cpp:
2348         (JSC::FTL::canCompile):
2349         * ftl/FTLLowerDFGToB3.cpp:
2350         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2351         (JSC::FTL::DFG::LowerDFGToB3::compileArrayify):
2352         (JSC::FTL::DFG::LowerDFGToB3::compileCheckArray):
2353         (JSC::FTL::DFG::LowerDFGToB3::isArrayTypeForArrayify):
2354         (JSC::FTL::DFG::LowerDFGToB3::isArrayTypeForCheckArray):
2355         (JSC::FTL::DFG::LowerDFGToB3::compileArrayifyToStructure): Deleted.
2356         (JSC::FTL::DFG::LowerDFGToB3::isArrayType): Deleted.
2357
2358 2017-04-20  Mark Lam  <mark.lam@apple.com>
2359
2360         virtualThunkFor() needs to materialize its of tagMaskRegister for tail calls.
2361         https://bugs.webkit.org/show_bug.cgi?id=171079
2362         <rdar://problem/31684756>
2363
2364         Reviewed by Saam Barati.
2365
2366         This is needed because tail calls would restore callee saved registers (and
2367         therefore, potentially clobber the tag registers) before jumping to the thunk.
2368
2369         * jit/ThunkGenerators.cpp:
2370         (JSC::virtualThunkFor):
2371
2372 2017-04-20  Mark Lam  <mark.lam@apple.com>
2373
2374         Build fix after r215592.
2375         https://bugs.webkit.org/show_bug.cgi?id=171088
2376
2377         Not reviewed.
2378
2379         * assembler/MacroAssemblerPrinter.h:
2380
2381 2017-04-20  Mark Lam  <mark.lam@apple.com>
2382
2383         Update the MASM probe to only take 1 arg instead of 2 (in addition to the callback function).
2384         https://bugs.webkit.org/show_bug.cgi?id=171088
2385
2386         Reviewed by Michael Saboff and Saam Barati.
2387
2388         Experience shows that we never use the 2nd arg.  So, let's remove it to reduce
2389         the footprint at each probe site.
2390
2391         Also fix the MacroAssembler::print() function so that it is a no-op when
2392         !ENABLE(MASM_PROBE).  This will allow us to have print() statements in JIT code
2393         without a lot of #if ENABLE(MASM_PROBE)s later.
2394
2395         * assembler/AbstractMacroAssembler.h:
2396         * assembler/MacroAssembler.cpp:
2397         (JSC::stdFunctionCallback):
2398         (JSC::MacroAssembler::probe):
2399         * assembler/MacroAssembler.h:
2400         * assembler/MacroAssemblerARM.cpp:
2401         (JSC::MacroAssemblerARM::probe):
2402         * assembler/MacroAssemblerARM.h:
2403         * assembler/MacroAssemblerARM64.cpp:
2404         (JSC::MacroAssemblerARM64::probe):
2405         * assembler/MacroAssemblerARM64.h:
2406         * assembler/MacroAssemblerARMv7.cpp:
2407         (JSC::MacroAssemblerARMv7::probe):
2408         * assembler/MacroAssemblerARMv7.h:
2409         * assembler/MacroAssemblerPrinter.cpp:
2410         (JSC::MacroAssemblerPrinter::printCallback):
2411         * assembler/MacroAssemblerPrinter.h:
2412         (JSC::MacroAssemblerPrinter::print):
2413         (JSC::MacroAssembler::print):
2414         * assembler/MacroAssemblerX86Common.cpp:
2415         (JSC::MacroAssemblerX86Common::probe):
2416         * assembler/MacroAssemblerX86Common.h:
2417
2418 2017-04-20  Matt Baker  <mattbaker@apple.com>
2419
2420         Web Inspector: Add regular expression support to XHR breakpoints
2421         https://bugs.webkit.org/show_bug.cgi?id=170099
2422         <rdar://problem/31558082>
2423
2424         Reviewed by Joseph Pecoraro.
2425
2426         * inspector/protocol/DOMDebugger.json:
2427         New optional `isRegex` parameter denotes whether `url` contains
2428         a regular expression.
2429
2430 2017-04-15  Filip Pizlo  <fpizlo@apple.com>
2431
2432         Optimize SharedArrayBuffer in the DFG+FTL
2433         https://bugs.webkit.org/show_bug.cgi?id=164108
2434
2435         Reviewed by Saam Barati.
2436         
2437         This adds atomics intrinsics to the DFG and wires them through to the DFG and FTL backends. This
2438         was super easy in the FTL since B3 already has comprehensive atomic intrinsics, which are more
2439         powerful than what we need right now. In the DFG backend, I went with an easy-to-write
2440         implementation that just reduces everything to a weak CAS loop. It's very inefficient with
2441         registers (it needs ~8) but it's the DFG backend, so it's not obvious how much we care.
2442         
2443         To make the rare cases easy to handle, I refactored AtomicsObject.cpp so that the operations for
2444         the slow paths can share code with the native functions.
2445         
2446         This also fixes register handling in the X86 implementations of CAS, in the case that
2447         expectedAndResult is not %rax. This also fixes the ARM64 implementation of branchWeakCAS.
2448         
2449         I adapted the CascadeLock from WTF/benchmarks/ToyLocks.h as a microbenchmark of lock performance.
2450         This benchmark performs 2.5x faster, in both the contended and uncontended case, thanks to this
2451         change. It's still about 3x slower than native. I investigated this only a bit. I suspect that
2452         the story will be different in asm.js code, which will get constant-folding of the typed array
2453         backing store by virtue of how it uses lexically scoped variables as pointers to the heap arrays.
2454         It's worth noting that the native lock I was comparing against, the very nicely-tuned
2455         CascadeLock, is at the very high end of lock throughput under virtually all conditions
2456         (uncontended, microcontended, held for a long time). I also compared to WTF::Lock and others, and
2457         the only ones that performed better in this microbenchmark were spinlocks. I don't recommend
2458         using those. So, when I say this is 3x slower than native, I really mean that it's 3x slower than
2459         the fastest native lock that I have in my arsenal.
2460         
2461         Also worth noting is that I experimented with exposing Atomics.yield(), which uses sched_yield,
2462         as a way of testing if adding a yield loop to the JS cascadeLock would help. It does not help. I
2463         did not investigate why.
2464
2465         * assembler/AbstractMacroAssembler.h:
2466         (JSC::AbstractMacroAssembler::JumpList::append):
2467         * assembler/CPU.h:
2468         (JSC::is64Bit):
2469         (JSC::is32Bit):
2470         * b3/B3Common.h:
2471         (JSC::B3::is64Bit): Deleted.
2472         (JSC::B3::is32Bit): Deleted.
2473         * b3/B3LowerToAir.cpp:
2474         (JSC::B3::Air::LowerToAir::appendTrapping):
2475         (JSC::B3::Air::LowerToAir::appendCAS):
2476         (JSC::B3::Air::LowerToAir::appendGeneralAtomic):
2477         * dfg/DFGAbstractInterpreterInlines.h:
2478         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2479         * dfg/DFGByteCodeParser.cpp:
2480         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
2481         * dfg/DFGClobberize.h:
2482         (JSC::DFG::clobberize):
2483         * dfg/DFGDoesGC.cpp:
2484         (JSC::DFG::doesGC):
2485         * dfg/DFGFixupPhase.cpp:
2486         (JSC::DFG::FixupPhase::fixupNode):
2487         * dfg/DFGNode.h:
2488         (JSC::DFG::Node::hasHeapPrediction):
2489         (JSC::DFG::Node::hasArrayMode):
2490         * dfg/DFGNodeType.h:
2491         (JSC::DFG::isAtomicsIntrinsic):
2492         (JSC::DFG::numExtraAtomicsArgs):
2493         * dfg/DFGPredictionPropagationPhase.cpp:
2494         * dfg/DFGSSALoweringPhase.cpp:
2495         (JSC::DFG::SSALoweringPhase::handleNode):
2496         * dfg/DFGSafeToExecute.h:
2497         (JSC::DFG::safeToExecute):
2498         * dfg/DFGSpeculativeJIT.cpp:
2499         (JSC::DFG::SpeculativeJIT::loadFromIntTypedArray):
2500         (JSC::DFG::SpeculativeJIT::setIntTypedArrayLoadResult):
2501         (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray):
2502         (JSC::DFG::SpeculativeJIT::getIntTypedArrayStoreOperand):
2503         (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
2504         * dfg/DFGSpeculativeJIT.h:
2505         (JSC::DFG::SpeculativeJIT::callOperation):
2506         * dfg/DFGSpeculativeJIT32_64.cpp:
2507         (JSC::DFG::SpeculativeJIT::compile):
2508         * dfg/DFGSpeculativeJIT64.cpp:
2509         (JSC::DFG::SpeculativeJIT::compile):
2510         * ftl/FTLAbstractHeapRepository.cpp:
2511         (JSC::FTL::AbstractHeapRepository::decorateFencedAccess):
2512         (JSC::FTL::AbstractHeapRepository::computeRangesAndDecorateInstructions):
2513         * ftl/FTLAbstractHeapRepository.h:
2514         * ftl/FTLCapabilities.cpp:
2515         (JSC::FTL::canCompile):
2516         * ftl/FTLLowerDFGToB3.cpp:
2517         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2518         (JSC::FTL::DFG::LowerDFGToB3::compileAtomicsReadModifyWrite):
2519         (JSC::FTL::DFG::LowerDFGToB3::compileAtomicsIsLockFree):
2520         (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
2521         (JSC::FTL::DFG::LowerDFGToB3::compilePutByVal):
2522         (JSC::FTL::DFG::LowerDFGToB3::pointerIntoTypedArray):
2523         (JSC::FTL::DFG::LowerDFGToB3::loadFromIntTypedArray):
2524         (JSC::FTL::DFG::LowerDFGToB3::storeType):
2525         (JSC::FTL::DFG::LowerDFGToB3::setIntTypedArrayLoadResult):
2526         (JSC::FTL::DFG::LowerDFGToB3::getIntTypedArrayStoreOperand):
2527         (JSC::FTL::DFG::LowerDFGToB3::vmCall):
2528         * ftl/FTLOutput.cpp:
2529         (JSC::FTL::Output::store):
2530         (JSC::FTL::Output::store32As8):
2531         (JSC::FTL::Output::store32As16):
2532         (JSC::FTL::Output::atomicXchgAdd):
2533         (JSC::FTL::Output::atomicXchgAnd):
2534         (JSC::FTL::Output::atomicXchgOr):
2535         (JSC::FTL::Output::atomicXchgSub):
2536         (JSC::FTL::Output::atomicXchgXor):
2537         (JSC::FTL::Output::atomicXchg):
2538         (JSC::FTL::Output::atomicStrongCAS):
2539         * ftl/FTLOutput.h:
2540         (JSC::FTL::Output::store32):
2541         (JSC::FTL::Output::store64):
2542         (JSC::FTL::Output::storePtr):
2543         (JSC::FTL::Output::storeFloat):
2544         (JSC::FTL::Output::storeDouble):
2545         * jit/JITOperations.h:
2546         * runtime/AtomicsObject.cpp:
2547         (JSC::atomicsFuncAdd):
2548         (JSC::atomicsFuncAnd):
2549         (JSC::atomicsFuncCompareExchange):
2550         (JSC::atomicsFuncExchange):
2551         (JSC::atomicsFuncIsLockFree):
2552         (JSC::atomicsFuncLoad):
2553         (JSC::atomicsFuncOr):
2554         (JSC::atomicsFuncStore):
2555         (JSC::atomicsFuncSub):
2556         (JSC::atomicsFuncWait):
2557         (JSC::atomicsFuncWake):
2558         (JSC::atomicsFuncXor):
2559         (JSC::operationAtomicsAdd):
2560         (JSC::operationAtomicsAnd):
2561         (JSC::operationAtomicsCompareExchange):
2562         (JSC::operationAtomicsExchange):
2563         (JSC::operationAtomicsIsLockFree):
2564         (JSC::operationAtomicsLoad):
2565         (JSC::operationAtomicsOr):
2566         (JSC::operationAtomicsStore):
2567         (JSC::operationAtomicsSub):
2568         (JSC::operationAtomicsXor):
2569         * runtime/AtomicsObject.h:
2570
2571 2017-04-19  Youenn Fablet  <youenn@apple.com>
2572
2573         [Mac] Allow customizing H264 encoder
2574         https://bugs.webkit.org/show_bug.cgi?id=170829
2575
2576         Reviewed by Alex Christensen.
2577
2578         * Configurations/FeatureDefines.xcconfig:
2579
2580 2017-04-19  Michael Saboff  <msaboff@apple.com>
2581
2582         Tune GC related JSC options for iOS
2583         https://bugs.webkit.org/show_bug.cgi?id=171019
2584
2585         Reviewed by Mark Lam.
2586
2587         Always set these GC options on iOS.
2588
2589         * runtime/Options.cpp:
2590         (JSC::overrideDefaults):
2591
2592 2017-04-19  JF Bastien  <jfbastien@apple.com>
2593
2594         WebAssembly: fast memory cleanups
2595         https://bugs.webkit.org/show_bug.cgi?id=170909
2596
2597         Reviewed by Saam Barati.
2598
2599         * b3/B3LowerToAir.cpp: correct comment, and make wasm-independent
2600         (JSC::B3::Air::LowerToAir::lower):
2601         * b3/B3Procedure.h:
2602         * b3/B3Validate.cpp:
2603         * b3/B3Value.cpp:
2604         (JSC::B3::Value::effects):
2605         * b3/B3WasmBoundsCheckValue.cpp: have the creator pass in a
2606         maximum, so we don't have to know so much about wasm here
2607         (JSC::B3::WasmBoundsCheckValue::WasmBoundsCheckValue):
2608         (JSC::B3::WasmBoundsCheckValue::cloneImpl):
2609         (JSC::B3::WasmBoundsCheckValue::dumpMeta):
2610         * b3/B3WasmBoundsCheckValue.h:
2611         (JSC::B3::WasmBoundsCheckValue::boundsType):
2612         (JSC::B3::WasmBoundsCheckValue::bounds):
2613         * b3/air/AirCode.h:
2614         * b3/air/AirCustom.h:
2615         (JSC::B3::Air::WasmBoundsCheckCustom::generate):
2616         * b3/testb3.cpp:
2617         (JSC::B3::testWasmBoundsCheck):
2618         * wasm/WasmB3IRGenerator.cpp:
2619         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
2620         (JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer):
2621         (JSC::Wasm::createJSToWasmWrapper): remove dead code
2622         * wasm/WasmMemory.cpp: don't GC if no memory could possibly be free'd
2623         (JSC::Wasm::Memory::initializePreallocations): verbose-only code,
2624         and copy-pasta bug
2625
2626 2017-04-19  Mark Lam  <mark.lam@apple.com>
2627
2628         B3StackmapSpecial should handle when stackmap values are not recoverable from a Def'ed arg.
2629         https://bugs.webkit.org/show_bug.cgi?id=170973
2630         <rdar://problem/30318657>
2631
2632         Reviewed by Filip Pizlo.
2633
2634         In the event of an arithmetic overflow on a binary sub instruction (where the
2635         result register is same as one of the operand registers), the CheckSub FTL
2636         operation will try to recover the original value in the clobbered result register.
2637
2638         This recover is done by adding the other operand value to the result register.
2639         However, this recovery method only works if the width of the original value in
2640         the result register is less or equal to the width of the expected result.  If the
2641         width of the original operand value (e.g. a JSInt32) is wider than the result
2642         (e.g. a machine Int32), then the sub operation would have zero extended the
2643         result and cleared the upper 32-bits of the result register.  Recovery by adding
2644         back the other operand will not restore the JSValue tag in the upper word.
2645
2646         This poses a problem if the stackmap value for the operand relies on that same
2647         clobbered register.
2648
2649         The fix is to detect this potential scenario (i.e. width of the Def's arg < width
2650         of a stackmap value).  If this condition is detected, we'll declare the stackmap
2651         value to be LateColdUse to ensure that the register allocator gives it a
2652         different register if needed so that it's not dependent on the clobbered register.
2653
2654         * b3/B3CheckSpecial.cpp:
2655         (JSC::B3::CheckSpecial::forEachArg):
2656         * b3/B3PatchpointSpecial.cpp:
2657         (JSC::B3::PatchpointSpecial::forEachArg):
2658         * b3/B3StackmapSpecial.cpp:
2659         (JSC::B3::StackmapSpecial::forEachArgImpl):
2660         * b3/B3StackmapSpecial.h:
2661
2662 2017-04-19  JF Bastien  <jfbastien@apple.com>
2663
2664         Unreviewed, rolling out r215520.
2665
2666         Broke Debian 8
2667
2668         Reverted changeset:
2669
2670         "[INTL] Implement Intl.DateTimeFormat.prototype.formatToParts"
2671         https://bugs.webkit.org/show_bug.cgi?id=169458
2672         http://trac.webkit.org/changeset/215520
2673
2674 2017-04-19  JF Bastien  <jfbastien@apple.com>
2675
2676         WebAssembly: limit slow memories
2677         https://bugs.webkit.org/show_bug.cgi?id=170825
2678
2679         Reviewed by Saam Barati.
2680
2681         We limits the number of fast memories, partly because ASLR. The
2682         code then falls back to slow memories. It first tries to virtually
2683         allocated any declared maximum (and in there, physically the
2684         initial), and if that fails it tries to physically allocate the
2685         initial without any extra.
2686
2687         This can still be used to cause a bunch of virtual
2688         allocation. This patch imposes soft limit on slow memories as
2689         well. The total virtual maximum for slow memories is set at the
2690         same (theoretical) value as that for fast memories.
2691
2692         Anything exceeding that limit causes allocation/grow to fail.
2693
2694         * wasm/WasmMemory.cpp:
2695
2696 2017-04-19  JF Bastien  <jfbastien@apple.com>
2697
2698         Cannot compile JavaScriptCore/runtime/VMTraps.cpp on FreeBSD because std::pair has a non-trivial copy constructor
2699         https://bugs.webkit.org/show_bug.cgi?id=170875
2700
2701         Reviewed by Mark Lam.
2702
2703         WTF::ExpectedDetail::ConstexprBase doesn't have a user-defined
2704         copy constructor, and its implicitly-defined copy constructor is
2705         deleted because the default std::pair implementation on FreeBSD
2706         has a non-trivial copy constructor. /usr/include/c++/v1/__config
2707         says _LIBCPP_TRIVIAL_PAIR_COPY_CTOR is disabled in order to keep
2708         ABI compatibility:
2709         https://svnweb.freebsd.org/changeset/base/261801.
2710
2711         That's a huge bummer, and I'm not a fan of broken stdlibs, but in
2712         this case it's pretty nice to have a custom named type anyways and
2713         costs nothing.
2714
2715         * runtime/VMTraps.cpp:
2716         (JSC::findActiveVMAndStackBounds):
2717         (JSC::handleSigusr1):
2718         (JSC::handleSigtrap):
2719
2720 2017-04-19  Andy VanWagoner  <thetalecrafter@gmail.com>
2721
2722         [INTL] Implement Intl.DateTimeFormat.prototype.formatToParts
2723         https://bugs.webkit.org/show_bug.cgi?id=169458
2724
2725         Reviewed by JF Bastien.
2726
2727         Use udat_formatForFields to iterate through the parts of a formatted date string.
2728
2729         * icu/unicode/udat.h: Update to 55.1.
2730         * icu/unicode/ufieldpositer.h: Added from 55.1.
2731         * runtime/IntlDateTimeFormat.cpp:
2732         (JSC::IntlDateTimeFormat::partTypeString): Convert UDateFormatField to string.
2733         (JSC::IntlDateTimeFormat::formatToParts): Return parts of formatted date string.
2734         * runtime/IntlDateTimeFormat.h:
2735         * runtime/IntlDateTimeFormatPrototype.cpp:
2736         (JSC::IntlDateTimeFormatPrototypeFuncFormatToParts): Add prototype function formatToParts.
2737
2738 2017-04-19  JF Bastien  <jfbastien@apple.com>
2739
2740         WebAssembly: don't expose any WebAssembly JS object if JIT is off
2741         https://bugs.webkit.org/show_bug.cgi?id=170782
2742
2743         Reviewed by Saam Barati.
2744
2745         It's unexpected that we expose the global WebAssembly object if no
2746         JIT is present because it can't be used to compile or
2747         instantiate. Other APIs such as Memory should also be Inaccessible
2748         in those circumstances.
2749
2750         Also ensure that we don't pre-allocate fast memories if
2751         WebAssembly won't be used, and don't mark our intention to use a
2752         fast TLS slot for WebAssembly.
2753
2754         * runtime/Options.cpp:
2755         (JSC::recomputeDependentOptions):
2756
2757 2017-04-19  Yusuke Suzuki  <utatane.tea@gmail.com>
2758
2759         r211670 broke double to int conversion.
2760         https://bugs.webkit.org/show_bug.cgi?id=170961
2761
2762         Reviewed by Mark Lam.
2763
2764         In this patch, we take a template parameter way.
2765         While it reduces duplicate code, it effectively produces
2766         optimized code for operationToInt32SensibleSlow,
2767         and fixes kraken pbkdf2 regression on Linux.
2768
2769         And this patch also fixes undefined behavior by changing
2770         int32_t to uint32_t. If exp is 31, missingOne is 1 << 31,
2771         INT32_MIN. Thus missingOne - 1 will cause int32_t overflow,
2772         and it is an undefined behavior.
2773
2774         * runtime/MathCommon.cpp:
2775         (JSC::operationToInt32SensibleSlow):
2776         * runtime/MathCommon.h:
2777         (JSC::toInt32Internal):
2778         (JSC::toInt32):
2779
2780 2017-04-18  Mark Lam  <mark.lam@apple.com>
2781
2782         r211670 broke double to int conversion.
2783         https://bugs.webkit.org/show_bug.cgi?id=170961
2784         <rdar://problem/31687696>
2785
2786         Reviewed by Yusuke Suzuki.
2787
2788         This is because operationToInt32SensibleSlow() assumes that left shifts of greater
2789         than 31 bits on an 31-bit value will produce a 0.  However, the spec says that
2790         "if the value of the right operand is negative or is greater or equal to the
2791         number of bits in the promoted left operand, the behavior is undefined."
2792         See http://en.cppreference.com/w/cpp/language/operator_arithmetic#Bitwise_shift_operators.
2793
2794         This patch fixes this by restoring the check to prevent a shift of greater than
2795         31 bits.  It also consolidates the optimization in operationToInt32SensibleSlow()
2796         back into toInt32() so that we don't have 2 copies of the same code with only a
2797         slight variation.
2798
2799         JSC benchmarks shows that performance is neutral with this patch.
2800
2801         * dfg/DFGSpeculativeJIT.cpp:
2802         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
2803         * ftl/FTLLowerDFGToB3.cpp:
2804         (JSC::FTL::DFG::LowerDFGToB3::sensibleDoubleToInt32):
2805         * runtime/MathCommon.cpp:
2806         (JSC::operationToInt32SensibleSlow): Deleted.
2807         * runtime/MathCommon.h:
2808         (JSC::toInt32):
2809
2810 2017-04-18  Oleksandr Skachkov  <gskachkov@gmail.com>
2811
2812         [ES6]. Implement Annex B.3.3 function hoisting rules for eval
2813         https://bugs.webkit.org/show_bug.cgi?id=163208
2814
2815         Reviewed by Saam Barati.
2816
2817         Current patch implements Annex B.3.3 that is related to 
2818         hoisting of function declaration in eval. 
2819         https://tc39.github.io/ecma262/#sec-web-compat-evaldeclarationinstantiation
2820         Function declaration in eval should create variable with 
2821         function name in function scope where eval is invoked 
2822         or bind to variable if it declared outside of the eval. 
2823         If variable is created it can be removed by 'delete a;' command. 
2824         If eval is invoke in block scope that contains let/const 
2825         variable with the same name as function declaration 
2826         we do not bind. This patch leads to the following behavior: 
2827         '''
2828         function foo() {
2829            {
2830              print(boo); // undefined
2831              eval('{ function boo() {}}');
2832              print(boo); // function boo() {}
2833            }
2834            print(boo); // function boo() {}
2835         }
2836
2837         function foobar() {
2838           { 
2839             let boo = 10;
2840             print(boo); // 10;
2841             eval('{ function boo() {}}');
2842             print(boo); // 10;
2843           }
2844           print(boo) // 10
2845         }
2846
2847         function bar() {
2848            {
2849               var boo = 10;
2850               print(boo); // 10
2851               eval('{ function boo() {} }'); 
2852               print(boo); // function boo() {}
2853            }
2854            print(boo); // function boo() {}
2855         }       
2856         
2857         function bas() {
2858             {
2859                  let boo = 10;
2860                  eval(' { function boo() {} } ');
2861                  print(boo); // 10
2862             }
2863             print(boo); //Reference Error
2864         }
2865         '''
2866
2867         Current implementation relies on already implemented 
2868         'hoist function in sloppy mode' feature, with small changes.
2869         In short it works in following way: during hoisting of function 
2870         with name S in eval, we are looking for first scope that 
2871         contains space for variable with name S and if this scope 
2872         has var type we bind function there
2873
2874         To implement this feature was added bytecode ops:
2875         op_resolve_scope_for_hoisting_func_decl_in_eval - get variable scope 
2876         or return undefined if variable can't be binded there.
2877
2878         There is a corner case, hoist function in eval within catch block,
2879         that is not covered by this patch, and will be fixed in 
2880         https://bugs.webkit.org/show_bug.cgi?id=168184
2881
2882         * bytecode/BytecodeDumper.cpp:
2883         (JSC::BytecodeDumper<Block>::dumpBytecode):
2884         * bytecode/BytecodeList.json:
2885         * bytecode/BytecodeUseDef.h:
2886         (JSC::computeUsesForBytecodeOffset):
2887         (JSC::computeDefsForBytecodeOffset):
2888         * bytecode/CodeBlock.cpp:
2889         (JSC::CodeBlock::finalizeLLIntInlineCaches):
2890         * bytecode/EvalCodeBlock.h:
2891         (JSC::EvalCodeBlock::functionHoistingCandidate):
2892         (JSC::EvalCodeBlock::numFunctionHoistingCandidates):
2893         * bytecode/UnlinkedEvalCodeBlock.h:
2894         * bytecompiler/BytecodeGenerator.cpp:
2895         (JSC::BytecodeGenerator::BytecodeGenerator):
2896         (JSC::BytecodeGenerator::hoistSloppyModeFunctionIfNecessary):
2897         (JSC::BytecodeGenerator::emitResolveScopeForHoistingFuncDeclInEval):
2898         * bytecompiler/BytecodeGenerator.h:
2899         * dfg/DFGAbstractInterpreterInlines.h:
2900         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2901         * dfg/DFGByteCodeParser.cpp:
2902         (JSC::DFG::ByteCodeParser::parseBlock):
2903         * dfg/DFGCapabilities.cpp:
2904         (JSC::DFG::capabilityLevel):
2905         * dfg/DFGClobberize.h:
2906         (JSC::DFG::clobberize):
2907         * dfg/DFGDoesGC.cpp:
2908         (JSC::DFG::doesGC):
2909         * dfg/DFGFixupPhase.cpp:
2910         (JSC::DFG::FixupPhase::fixupNode):
2911         * dfg/DFGNode.h:
2912         (JSC::DFG::Node::hasIdentifier):
2913         * dfg/DFGNodeType.h:
2914         * dfg/DFGOperations.cpp:
2915         * dfg/DFGOperations.h:
2916         * dfg/DFGPredictionPropagationPhase.cpp:
2917         * dfg/DFGSafeToExecute.h:
2918         (JSC::DFG::safeToExecute):
2919         * dfg/DFGSpeculativeJIT.cpp:
2920         (JSC::DFG::SpeculativeJIT::compileResolveScopeForHoistingFuncDeclInEval):
2921         * dfg/DFGSpeculativeJIT.h:
2922         (JSC::DFG::SpeculativeJIT::callOperation):
2923         * dfg/DFGSpeculativeJIT32_64.cpp:
2924         (JSC::DFG::SpeculativeJIT::compile):
2925         * dfg/DFGSpeculativeJIT64.cpp:
2926         (JSC::DFG::SpeculativeJIT::compile):
2927         * ftl/FTLCapabilities.cpp:
2928         (JSC::FTL::canCompile):
2929         * ftl/FTLLowerDFGToB3.cpp:
2930         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2931         (JSC::FTL::DFG::LowerDFGToB3::compileResolveScopeForHoistingFuncDeclInEval):
2932         * interpreter/Interpreter.cpp:
2933         (JSC::Interpreter::execute):
2934         * jit/JIT.cpp:
2935         (JSC::JIT::privateCompileMainPass):
2936         * jit/JIT.h:
2937         * jit/JITOperations.h:
2938         * jit/JITPropertyAccess.cpp:
2939         (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval):
2940         * jit/JITPropertyAccess32_64.cpp:
2941         (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval):
2942         * llint/LowLevelInterpreter.asm:
2943         * parser/Parser.cpp:
2944         (JSC::Parser<LexerType>::parseFunctionDeclarationStatement):
2945         * parser/Parser.h:
2946         (JSC::Scope::getSloppyModeHoistedFunctions):
2947         (JSC::Parser::declareFunction):
2948         * runtime/CommonSlowPaths.cpp:
2949         (JSC::SLOW_PATH_DECL):
2950         * runtime/CommonSlowPaths.h:
2951         * runtime/EvalExecutable.h:
2952         (JSC::EvalExecutable::numFunctionHoistingCandidates):
2953         (JSC::EvalExecutable::numTopLevelFunctionDecls):
2954         (JSC::EvalExecutable::numberOfFunctionDecls): Deleted.
2955         * runtime/JSScope.cpp:
2956         (JSC::JSScope::resolve):
2957         (JSC::JSScope::resolveScopeForHoistingFuncDeclInEval):
2958         * runtime/JSScope.h:
2959
2960 2017-04-18  Saam Barati  <sbarati@apple.com>
2961
2962         Follow up to address Mark's comments after r215453
2963
2964         Rubber stamped by Mark Lam.
2965
2966         This patch chooses better names for things, adhering to Mark's suggestions
2967         in https://bugs.webkit.org/show_bug.cgi?id=139847
2968
2969         * bytecompiler/NodesCodegen.cpp:
2970         (JSC::CallFunctionCallDotNode::emitBytecode):
2971         (JSC::ApplyFunctionCallDotNode::emitBytecode):
2972         * parser/NodeConstructors.h:
2973         (JSC::CallFunctionCallDotNode::CallFunctionCallDotNode):
2974         (JSC::ApplyFunctionCallDotNode::ApplyFunctionCallDotNode):
2975         * parser/Nodes.h:
2976         * parser/Parser.cpp:
2977         (JSC::recordCallOrApplyDepth):
2978         (JSC::Parser<LexerType>::parseMemberExpression):
2979         * parser/Parser.h:
2980         (JSC::Parser::CallOrApplyDepthScope::CallOrApplyDepthScope):
2981         (JSC::Parser::CallOrApplyDepthScope::distanceToInnermostChild):
2982         (JSC::Parser::CallOrApplyDepthScope::~CallOrApplyDepthScope):
2983         (JSC::Parser::CallOrApplyDepth::CallOrApplyDepth): Deleted.
2984         (JSC::Parser::CallOrApplyDepth::maxChildDepth): Deleted.
2985         (JSC::Parser::CallOrApplyDepth::~CallOrApplyDepth): Deleted.
2986
2987 2017-04-18  Yusuke Suzuki  <utatane.tea@gmail.com>
2988
2989         [DFG] Convert ValueAdd(Int32, String) => MakeRope(ToString(Int32), String)
2990         https://bugs.webkit.org/show_bug.cgi?id=170943
2991
2992         Reviewed by Geoffrey Garen.
2993
2994         This patch converts ValueAdd(Int32, String) to MakeRope(ToString(Int32), String).
2995         This has 2 great features.
2996
2997         1. MakeRope(ToString(Int32), String) is less clobbering.
2998
2999         While ValueAdd ends up calling functions, VM knows much about MakeRope(ToString(Int32), String)
3000         and VM knows it is less clobbering. It encourages LICM and other operations that is conservatively
3001         executed because of ValueAdd's clobbering.
3002
3003         2. Simply, MakeRope(ToString(Int32), String) is faster than ValueAdd.
3004
3005         While ValueAdd ends up calling a generic function, our ToString(Int32) calls well-optimized toString
3006         operation. And later, MakeRope can fall into the fast path that just takes a string from a free list.
3007         It is simply faster than ValueAdd.
3008
3009         We ensure that this patch shows performance improvement in attached benchmarks.
3010
3011                                                         baseline                  patched
3012
3013             number-to-string-with-add-empty         16.2763+-3.3930     ^     10.3142+-1.0967        ^ definitely 1.5780x faster
3014             number-to-string-with-add-in-loop      168.7621+-10.9738    ^     15.5307+-3.3179        ^ definitely 10.8664x faster
3015             number-to-string-with-add               18.8557+-4.8292           11.6901+-2.5650          might be 1.6130x faster
3016
3017         In SixSpeed,
3018
3019                                                baseline                  patched
3020
3021             template_string_tag.es5       200.1027+-20.6871    ^     25.7925+-11.4052       ^ definitely 7.7582x faster
3022             template_string_tag.es6       331.3913+-12.1750    ^    286.6958+-26.0441       ^ definitely 1.1559x faster
3023             for-of-array.es5              412.4344+-23.2517    ^    272.8707+-47.2118       ^ definitely 1.5115x faster
3024             for-of-array.es6              504.0082+-65.5045    ^    300.3277+-12.8193       ^ definitely 1.6782x faster
3025
3026         * dfg/DFGFixupPhase.cpp:
3027         (JSC::DFG::FixupPhase::fixupNode):
3028         (JSC::DFG::FixupPhase::createToString):
3029         * dfg/DFGPredictionPropagationPhase.cpp:
3030
3031 2017-04-18  Michael Saboff  <msaboff@apple.com>
3032
3033         REGRESSION(215272): microbenchmark/seal-and-do-work and microbenchmark/freeze-and-do-work are 27x slower
3034         https://bugs.webkit.org/show_bug.cgi?id=170881
3035
3036         Reviewed by Saam Barati.
3037
3038         * runtime/ObjectConstructor.cpp:
3039         (JSC::objectConstructorSeal):
3040         (JSC::objectConstructorFreeze):
3041         Restored fast paths for final objects that don't have indexed properties.
3042
3043 2017-04-18  Yusuke Suzuki  <utatane.tea@gmail.com>
3044
3045         [DFG] Use Phantom for base instead of getter when inlining intrinsic getter
3046         https://bugs.webkit.org/show_bug.cgi?id=170947
3047
3048         Reviewed by Saam Barati.
3049
3050         getter does not need to be live after OSR Exit.
3051
3052         * dfg/DFGByteCodeParser.cpp:
3053         (JSC::DFG::ByteCodeParser::handleGetById):
3054
3055 2017-04-18  Yusuke Suzuki  <utatane.tea@gmail.com>
3056
3057         Unreviewed, follow-up patch after r215459
3058         https://bugs.webkit.org/show_bug.cgi?id=170940
3059
3060         Reviewed by Filip Pizlo.
3061
3062         CheckCell can cause OSRExit. Thus Phantom should be placed after CheckCell.
3063
3064         * dfg/DFGByteCodeParser.cpp:
3065         (JSC::DFG::ByteCodeParser::emitFunctionChecks):
3066         (JSC::DFG::ByteCodeParser::handleGetById):
3067
3068 2017-04-18  Yusuke Suzuki  <utatane.tea@gmail.com>
3069
3070         [DFG] Drop unknown use of CheckCell's child2 to work ObjectAllocationSinking for Array iterator object
3071         https://bugs.webkit.org/show_bug.cgi?id=170940
3072
3073         Reviewed by Filip Pizlo.
3074
3075         The second argument of CheckCell is not used in meaningful way. It is just *use* the node.
3076         The problem is that it effectively *use* the child2 in ObjectAllocationSinking phase, and
3077         prevent us from eliminating object allocations. Actually, it materializes Array iterator
3078         when inlining `next()`. Instead, we should use Phantom in such a case.
3079
3080         It improves destructuring.es6 in SixSpeed 2.5x.
3081
3082         destructuring.es6      308.5184+-25.3490    ^    119.5680+-15.0520       ^ definitely 2.5803x faster
3083
3084         Note that SixSpeed tested in arewefastyet executes all the tests in one process while our SixSpeed
3085         tests each one in isolated way.
3086
3087         * dfg/DFGByteCodeParser.cpp:
3088         (JSC::DFG::ByteCodeParser::emitFunctionChecks):
3089         (JSC::DFG::ByteCodeParser::handleGetById):
3090
3091 2017-04-18  Yusuke Suzuki  <utatane.tea@gmail.com>
3092
3093         [JSC][GTK] glib RunLoop does not accept negative start interval
3094         https://bugs.webkit.org/show_bug.cgi?id=170775
3095
3096         Reviewed by Saam Barati.
3097
3098         * heap/GCActivityCallback.cpp:
3099         (JSC::GCActivityCallback::scheduleTimer):
3100
3101 2017-04-17  Saam Barati  <sbarati@apple.com>
3102
3103         BytecodeGenerator ".call" and ".apply" is exponential in nesting depth
3104         https://bugs.webkit.org/show_bug.cgi?id=139847
3105         <rdar://problem/19321122>
3106
3107         Reviewed by Oliver Hunt.
3108
3109         The BytecodeGenerator's .apply(...) and .call(...) code would
3110         emit bytecode for the evaluation of its arguments twice. This
3111         is exponential, specifically, 2^n, where n is the nesting depth of
3112         .call(...) or .apply(...) inside other .call(...) or .apply(...).
3113         
3114         The reason we emit code for the arguments twice is that we try
3115         to emit efficient code for when .call or .apply is Function.prototype.call
3116         or Function.prototype.apply. Because of this, we compare .call/.apply to
3117         Function.prototype.call/.apply, and if they're the same, we emit a specialized
3118         function call in bytecode. Otherwise, we emit the generalized version.
3119         
3120         This patch makes it so that each .call(...) and .apply(...) records
3121         its max inner nesting depth. Then, we only perform the optimization
3122         for the bottom k (where k = 6) layers of the nesting tree. The reason we
3123         apply the optimization to the bottom k layers instead of top k layers
3124         is that we'll produce less code this way.
3125
3126         * bytecompiler/NodesCodegen.cpp:
3127         (JSC::CallFunctionCallDotNode::emitBytecode):
3128         (JSC::ApplyFunctionCallDotNode::emitBytecode):
3129         * parser/ASTBuilder.h:
3130         (JSC::ASTBuilder::makeFunctionCallNode):
3131         * parser/NodeConstructors.h:
3132         (JSC::CallFunctionCallDotNode::CallFunctionCallDotNode):
3133         (JSC::ApplyFunctionCallDotNode::ApplyFunctionCallDotNode):
3134         * parser/Nodes.h:
3135         * parser/Parser.cpp:
3136         (JSC::recordCallOrApplyDepth):
3137         (JSC::Parser<LexerType>::parseMemberExpression):
3138         * parser/Parser.h:
3139         (JSC::Parser::CallOrApplyDepth::CallOrApplyDepth):
3140         (JSC::Parser::CallOrApplyDepth::maxChildDepth):
3141         (JSC::Parser::CallOrApplyDepth::~CallOrApplyDepth):
3142         * parser/SyntaxChecker.h:
3143         (JSC::SyntaxChecker::makeFunctionCallNode):
3144
3145 2017-04-17  Mark Lam  <mark.lam@apple.com>
3146
3147         JSArray::appendMemcpy() needs to handle copying from Undecided indexing type too.
3148         https://bugs.webkit.org/show_bug.cgi?id=170896
3149         <rdar://problem/31651319>
3150
3151         Reviewed by JF Bastien and Keith Miller.
3152
3153         * runtime/JSArray.cpp:
3154         (JSC::JSArray::appendMemcpy):
3155
3156 2017-04-17  Joseph Pecoraro  <pecoraro@apple.com>
3157
3158         Web Inspector: Doesn't show size of compressed content correctly
3159         https://bugs.webkit.org/show_bug.cgi?id=155112
3160         <rdar://problem/25006728>
3161
3162         Reviewed by Alex Christensen and Timothy Hatcher.
3163
3164         * inspector/protocol/Network.json:
3165         New, exact size metrics, available after the load completes.
3166
3167 2017-04-17  Youenn Fablet  <youenn@apple.com>
3168
3169         Disable outdated WritableStream API
3170         https://bugs.webkit.org/show_bug.cgi?id=170749
3171         <rdar://problem/31446233>
3172
3173         Reviewed by Alex Christensen.
3174
3175         * Configurations/FeatureDefines.xcconfig:
3176
3177 2017-04-17  Yusuke Suzuki  <utatane.tea@gmail.com>
3178
3179         [JSCOnly] Fix build failures in macOS
3180         https://bugs.webkit.org/show_bug.cgi?id=170887
3181
3182         Reviewed by Alex Christensen.
3183
3184         Align ICU header configuration to MacCMake port.
3185
3186         * PlatformJSCOnly.cmake:
3187
3188 2017-04-17  JF Bastien  <jfbastien@apple.com>
3189
3190         B3: don't allow unsigned offsets in Value
3191         https://bugs.webkit.org/show_bug.cgi?id=170692
3192
3193         Reviewed by Filip Pizlo.
3194
3195         MemoryValue and similar B3 opcode classes always expects a signed
3196         offset. Giving it an out-of-bounds unsigned offset causes
3197         implementation-defined behavior, which can cause badness as I just
3198         fixed in WebAssembly.  This patch makes it impossible to create a
3199         Value opcodes with an unsigned value, or with an overly-large
3200         value.
3201
3202         * b3/B3AtomicValue.cpp:
3203         (JSC::B3::AtomicValue::AtomicValue):
3204         * b3/B3AtomicValue.h:
3205         * b3/B3Common.h:
3206         (JSC::B3::isRepresentableAs):
3207         * b3/B3EliminateCommonSubexpressions.cpp:
3208         * b3/B3LowerToAir.cpp:
3209         (JSC::B3::Air::LowerToAir::scaleForShl):
3210         (JSC::B3::Air::LowerToAir::effectiveAddr):
3211         (JSC::B3::Air::LowerToAir::addr):
3212         (JSC::B3::Air::LowerToAir::tryAppendLea):
3213         * b3/B3MemoryValue.cpp:
3214         (JSC::B3::MemoryValue::isLegalOffsetImpl):
3215         (JSC::B3::MemoryValue::MemoryValue):
3216         * b3/B3MemoryValue.h:
3217         * b3/B3MemoryValueInlines.h:
3218         (JSC::B3::MemoryValue::isLegalOffsetImpl):
3219         * b3/B3MoveConstants.cpp:
3220         * b3/B3ReduceStrength.cpp:
3221         * b3/B3StackmapSpecial.cpp:
3222         (JSC::B3::StackmapSpecial::repForArg):
3223         * b3/B3Value.h:
3224         * b3/air/AirArg.cpp:
3225         (JSC::B3::Air::Arg::stackAddrImpl):
3226         * b3/air/AirArg.h:
3227         (JSC::B3::Air::Arg::addr):
3228         (JSC::B3::Air::Arg::stack):
3229         (JSC::B3::Air::Arg::callArg):
3230         (JSC::B3::Air::Arg::stackAddr):
3231         (JSC::B3::Air::Arg::index):
3232         (JSC::B3::Air::Arg::offset):
3233         (JSC::B3::Air::Arg::isValidAddrForm):
3234         (JSC::B3::Air::Arg::isValidIndexForm):
3235         (JSC::B3::Air::Arg::asTrustedImm32):
3236         (JSC::B3::Air::Arg::asAddress):
3237         (JSC::B3::Air::Arg::asBaseIndex):
3238         * b3/air/AirLowerStackArgs.cpp:
3239         (JSC::B3::Air::lowerStackArgs):
3240         * b3/testb3.cpp:
3241         (JSC::B3::testMulArgStore):
3242         (JSC::B3::testStore32):
3243         (JSC::B3::testStoreConstant):
3244         (JSC::B3::testStoreConstantPtr):
3245         (JSC::B3::testStoreAddLoad32):
3246         (JSC::B3::testStoreAddLoadImm32):
3247         (JSC::B3::testStoreAddLoad8):
3248         (JSC::B3::testStoreAddLoadImm8):
3249         (JSC::B3::testStoreAddLoad16):
3250         (JSC::B3::testStoreAddLoadImm16):
3251         (JSC::B3::testStoreAddLoad64):
3252         (JSC::B3::testStoreAddLoadImm64):
3253         (JSC::B3::testStoreAddLoad32Index):
3254         (JSC::B3::testStoreAddLoadImm32Index):
3255         (JSC::B3::testStoreAddLoad64Index):
3256         (JSC::B3::testStoreAddLoadImm64Index):
3257         (JSC::B3::testStoreSubLoad):
3258         (JSC::B3::testStoreAddLoadInterference):
3259         (JSC::B3::testStoreAddAndLoad):
3260         (JSC::B3::testStoreNegLoad32):
3261         (JSC::B3::testStoreNegLoadPtr):
3262         (JSC::B3::testLoadOffset):
3263         (JSC::B3::testLoadOffsetNotConstant):
3264         (JSC::B3::testLoadOffsetUsingAdd):
3265         (JSC::B3::testLoadOffsetUsingAddInterference):
3266         (JSC::B3::testLoadOffsetUsingAddNotConstant):
3267         (JSC::B3::testStoreLoadStackSlot):
3268         (JSC::B3::testLoad):
3269         (JSC::B3::testInterpreter):
3270         (JSC::B3::testTrappingStore):
3271         (JSC::B3::testTrappingLoadAddStore):
3272         (JSC::B3::testWasmAddress):
3273         * wasm/WasmB3IRGenerator.cpp:
3274         (JSC::Wasm::B3IRGenerator::fixupPointerPlusOffset):
3275         (JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer):
3276         (JSC::Wasm::B3IRGenerator::emitLoadOp):
3277         (JSC::Wasm::B3IRGenerator::emitStoreOp):
3278
3279 2017-04-16  Joseph Pecoraro  <pecoraro@apple.com>
3280
3281         test262: test262/test/built-ins/Object/prototype/toLocaleString/primitive_this_value.js
3282         https://bugs.webkit.org/show_bug.cgi?id=170882
3283
3284         Reviewed by Saam Barati.
3285
3286         * runtime/ObjectPrototype.cpp:
3287         (JSC::objectProtoFuncToLocaleString):
3288         We should be using the this value without ToObject conversion both when
3289         getting the potential accessor and calling it. In strict mode, the this
3290         value will remain its simple value, in non-strict it is still converted.
3291
3292 2017-04-16  Joseph Pecoraro  <pecoraro@apple.com>
3293
3294         test262: test262/test/built-ins/isNaN/toprimitive-not-callable-throws.js
3295         https://bugs.webkit.org/show_bug.cgi?id=170888
3296
3297         Reviewed by Saam Barati.
3298
3299         * runtime/ExceptionHelpers.h:
3300         * runtime/ExceptionHelpers.cpp:
3301         (JSC::createInvalidInstanceofParameterErrorHasInstanceValueNotFunction):
3302         Fix up this function name.
3303
3304         * runtime/JSObject.cpp:
3305         (JSC::callToPrimitiveFunction):
3306         When called with @@isPrimitive, bail on undefined or null and
3307         throw a type error if the value is not callable.
3308
3309         (JSC::JSObject::toPrimitive):
3310         Use throw scope to check for exception.
3311
3312 2017-04-16  Joseph Pecoraro  <pecoraro@apple.com>
3313
3314         test262: test262/test/language/expressions/tagged-template/template-object.js
3315         https://bugs.webkit.org/show_bug.cgi?id=170878
3316
3317         Reviewed by Saam Barati.
3318
3319         * runtime/JSArray.cpp:
3320         (JSC::JSArray::put):
3321         The fast path for setting an Array's length should check if length is
3322         writable before checking for and possibly throwing a RangeError.
3323
3324 2017-04-16  Joseph Pecoraro  <pecoraro@apple.com>
3325
3326         test262: test262/test/built-ins/Object/getOwnPropertyNames/15.2.3.4-4-44.js
3327         https://bugs.webkit.org/show_bug.cgi?id=170879
3328
3329         Reviewed by Saam Barati.
3330
3331         * runtime/StringObject.h:
3332         * runtime/StringObject.cpp:
3333         (JSC::StringObject::getOwnPropertyNames):
3334         (JSC::StringObject::getOwnNonIndexPropertyNames):
3335         Ensure 'length' comes after all indexed properties by moving
3336         it out to the getOwnNonIndexPropertyNames method which is called
3337         inside of getOwnPropertyNames after JSObject handles indices.
3338
3339 2017-04-16  Joseph Pecoraro  <pecoraro@apple.com>
3340
3341         test262: test262/test/built-ins/Date/prototype/Symbol.toPrimitive/name.js
3342         https://bugs.webkit.org/show_bug.cgi?id=170884
3343
3344         Reviewed by Yusuke Suzuki.
3345
3346         * runtime/DatePrototype.cpp:
3347         (JSC::DatePrototype::finishCreation):
3348         * runtime/FunctionPrototype.cpp:
3349         (JSC::FunctionPrototype::addFunctionProperties):
3350         * runtime/RegExpPrototype.cpp:
3351         (JSC::RegExpPrototype::finishCreation):
3352         * runtime/SymbolPrototype.cpp:
3353         (JSC::SymbolPrototype::finishCreation):
3354         Give symbol property functions proper function names.
3355         This addresses function.name but not function.toString().
3356
3357 2017-04-15  Joseph Pecoraro  <pecoraro@apple.com>
3358
3359         test262: test262/test/language/global-code/new.target-arrow.js
3360         https://bugs.webkit.org/show_bug.cgi?id=170872
3361
3362         Reviewed by Saam Barati.
3363
3364         * parser/Parser.cpp:
3365         (JSC::Parser<LexerType>::Parser):
3366         Mark the global code scope.
3367
3368         (JSC::Parser<LexerType>::parseMemberExpression):
3369         If new.target is detected in an arrow function defined in global scope
3370         throw a SyntaxError.
3371
3372         * parser/Parser.h:
3373         (JSC::Scope::Scope):
3374         (JSC::Scope::setIsGlobalCodeScope):
3375         (JSC::Scope::isGlobalCodeScope):
3376         Marker for a global code scope.
3377
3378         * parser/ParserModes.h:
3379         (JSC::isModuleParseMode):
3380         (JSC::isProgramParseMode):
3381         (JSC::isProgramOrModuleParseMode):
3382         Helper for detecting global code based on parse mode.
3383
3384 2017-04-14  Nikita Vasilyev  <nvasilyev@apple.com>
3385
3386         Web Inspector: WebSockets: messages with non-latin letters are displayed incorrectly
3387         https://bugs.webkit.org/show_bug.cgi?id=170760
3388
3389         Reviewed by Joseph Pecoraro.
3390
3391         Add payloadLength property, which is used to display size. When payloadLength is unavailable,
3392         it is calculated from payloadData by Web Inspector frontend.
3393
3394         This fixes <webkit.org/b/170609> Web Inspector: WebSockets: Transferred size is incorrect.
3395
3396         * inspector/protocol/Network.json:
3397
3398 2017-04-14  Saam Barati  <sbarati@apple.com>
3399
3400         ParseInt intrinsic in DFG backend doesn't properly flush its operands
3401         https://bugs.webkit.org/show_bug.cgi?id=170865
3402
3403         Reviewed by Mark Lam and Geoffrey Garen.
3404
3405         The DFG backend code needed to first call .gpr()/.jsValueRegs()
3406         before calling flushRegisters(), or the input JSValueOperand would
3407         not be flushed.
3408
3409         * dfg/DFGSpeculativeJIT.cpp:
3410         (JSC::DFG::SpeculativeJIT::compileParseInt):
3411
3412 2017-04-14  Mark Lam  <mark.lam@apple.com>
3413
3414         Update architectures in xcconfig files.
3415         https://bugs.webkit.org/show_bug.cgi?id=170867
3416         <rdar://problem/31628104>
3417
3418         Reviewed by Joseph Pecoraro.
3419
3420         * Configurations/Base.xcconfig:
3421         * Configurations/FeatureDefines.xcconfig:
3422         * Configurations/JavaScriptCore.xcconfig:
3423         * Configurations/ToolExecutable.xcconfig:
3424
3425 2017-04-14  Keith Miller  <keith_miller@apple.com>
3426
3427         WebAssembly: B3IRGenerator should use phis for result types
3428         https://bugs.webkit.org/show_bug.cgi?id=170863
3429
3430         Reviewed by Filip Pizlo.
3431
3432         Currently, we use variables for the result types of control flow in
3433         Wasm. We did this originally since we weren't sure that the phis we
3434         generated would be optimal. Since then, we have verified that the edges
3435         in wasm control flow ensure that each upsilon will dominate its phi
3436         so we don't need to use variables.
3437
3438         * wasm/WasmB3IRGenerator.cpp:
3439         (JSC::Wasm::B3IRGenerator::ControlData::ControlData):
3440         (JSC::Wasm::B3IRGenerator::addTopLevel):
3441         (JSC::Wasm::B3IRGenerator::addBlock):
3442         (JSC::Wasm::B3IRGenerator::addLoop):
3443         (JSC::Wasm::B3IRGenerator::unify):
3444
3445 2017-04-14  Alex Christensen  <achristensen@webkit.org>
3446
3447         Fix Windows build after r215368.
3448         https://bugs.webkit.org/show_bug.cgi?id=170641
3449
3450         * CMakeLists.txt:
3451         Add new directory containing files needed in WebCore.
3452
3453 2017-04-14  Caitlin Potter  <caitp@igalia.com>
3454
3455         [JSC] use ExpressionErrorClassifier for AwaitExpression operand
3456         https://bugs.webkit.org/show_bug.cgi?id=170844
3457
3458         Reviewed by Saam Barati.
3459
3460         In parseAssignmentExpression(), several cover grammars are handled, and
3461         use ExpressionErrorClassifier to record hints about which grammars to
3462         try.
3463
3464         In parseAwaitExpression(), the hints recorded during parsing of the
3465         operand need to be discarded, because if they propagate to the outer
3466         parseAssignmentExpression(), the hints will lead the parser down invalid
3467         branches that should be skipped.
3468
3469         This change adds an additional ExpressionErrorClassifier to
3470         parseAwaitExpression(), in order to discard hints recorded trying to
3471         parse the operand.
3472
3473         * parser/Parser.cpp:
3474         (JSC::Parser<LexerType>::parseAwaitExpression):
3475
3476 2017-04-14  Saam Barati  <sbarati@apple.com>
3477
3478         WebAssembly: There is a short window of time where a CodeBlock could be destroyed before all of its async compilation callbacks are called
3479         https://bugs.webkit.org/show_bug.cgi?id=170641
3480
3481         Reviewed by Keith Miller.
3482
3483         There is an unlikely race when a CodeBlock compilation fails,
3484         the module compiles a new CodeBlock for that memory mode, all while
3485         the CodeBlock is notifying its callbacks that it has finished.
3486         There is a chance that the Module could deref its failed CodeBlock 
3487         at that point, destroying it, before the callbacks were able to
3488         grab a Ref to the CodeBlock. This patch fixes the race by having the
3489         callbacks ref the CodeBlock.
3490
3491         This patch also has the Plan clear out all of its callbacks
3492         once it gets completed. This adds an extra defense to anybody
3493         that grabs refs to the Plan in the callback.
3494
3495         * wasm/WasmCodeBlock.cpp:
3496         (JSC::Wasm::CodeBlock::CodeBlock):
3497         (JSC::Wasm::CodeBlock::compileAsync):
3498         * wasm/WasmPlan.cpp:
3499         (JSC::Wasm::Plan::complete):
3500
3501 2017-04-13  Filip Pizlo  <fpizlo@apple.com>
3502
3503         Air::RegLiveness should be constraint-based
3504         https://bugs.webkit.org/show_bug.cgi?id=170817
3505
3506         Reviewed by Saam Barati.
3507         
3508         Previously, I changed the Air liveness analyses based on Air::Liveness<> to be
3509         constraint-based and this was a significant speed-up. Now I'm adding the same
3510         functionality to RegLiveness.
3511         
3512         This is a 1% speed-up on wasm B3 -O1 compile times.
3513         
3514         * b3/air/AirAllocateRegistersAndStackByLinearScan.cpp:
3515         * b3/air/AirLivenessAdapter.h:
3516         (JSC::B3::Air::LivenessAdapter::LivenessAdapter):
3517         (JSC::B3::Air::LivenessAdapter::prepareToCompute):
3518         (JSC::B3::Air::LivenessAdapter::actionsAt):
3519         * b3/air/AirRegLiveness.cpp:
3520         (JSC::B3::Air::RegLiveness::RegLiveness):
3521         (JSC::B3::Air::RegLiveness::LocalCalcForUnifiedTmpLiveness::LocalCalcForUnifiedTmpLiveness):
3522         (JSC::B3::Air::RegLiveness::LocalCalcForUnifiedTmpLiveness::execute):
3523         (JSC::B3::Air::RegLiveness::LocalCalc::execute): Deleted.
3524         * b3/air/AirRegLiveness.h:
3525         (JSC::B3::Air::RegLiveness::Actions::Actions):
3526         (JSC::B3::Air::RegLiveness::LocalCalcBase::LocalCalcBase):
3527         (JSC::B3::Air::RegLiveness::LocalCalcBase::live):
3528         (JSC::B3::Air::RegLiveness::LocalCalcBase::isLive):
3529         (JSC::B3::Air::RegLiveness::LocalCalc::LocalCalc):
3530         (JSC::B3::Air::RegLiveness::LocalCalc::execute):
3531         (JSC::B3::Air::RegLiveness::LocalCalc::live): Deleted.
3532         (JSC::B3::Air::RegLiveness::LocalCalc::isLive): Deleted.
3533
3534 2017-04-13  JF Bastien  <jfbastien@apple.com>
3535
3536         WebAssembly: fix windows build
3537         https://bugs.webkit.org/show_bug.cgi?id=170832
3538
3539         Reviewed by Mark Lam.
3540
3541         My previous patch re-declared isIOS which AssemblerCommon.h
3542         already provided, and which was already included by Options.cpp.
3543
3544         * runtime/Options.cpp:
3545
3546 2017-04-13  Saam Barati  <sbarati@apple.com>
3547
3548         WebAssembly: We should be able to postMessage a JSWebAssemblyModule
3549         https://bugs.webkit.org/show_bug.cgi?id=170573
3550
3551         Reviewed by Filip Pizlo.
3552
3553         This patch adds a callback to JSRunLoopTimer to notify
3554         clients that a timer has been set. This is used inside
3555         WorkerRunLoop in WebCore so that its RunLoop can perform
3556         an iteration when it sees that a timer got set.
3557
3558         * JavaScriptCore.xcodeproj/project.pbxproj:
3559         * runtime/JSRunLoopTimer.cpp:
3560         (JSC::JSRunLoopTimer::scheduleTimer):
3561         (JSC::JSRunLoopTimer::addTimerSetNotification):
3562         (JSC::JSRunLoopTimer::removeTimerSetNotification):
3563         * runtime/JSRunLoopTimer.h:
3564         * wasm/WasmCodeBlock.cpp:
3565         (JSC::Wasm::CodeBlock::~CodeBlock):
3566         * wasm/WasmCodeBlock.h:
3567         * wasm/WasmModule.cpp:
3568         (JSC::Wasm::Module::~Module):
3569         (JSC::Wasm::Module::signatureIndexFromFunctionIndexSpace):
3570         (JSC::Wasm::makeValidationCallback):
3571         (JSC::Wasm::Module::validateSync):
3572         (JSC::Wasm::Module::validateAsync):
3573         (JSC::Wasm::Module::validateSyncImpl): Deleted.
3574         (JSC::Wasm::Module::makeValidationCallback): Deleted.
3575         * wasm/WasmModule.h:
3576         (JSC::Wasm::Module::validateSync): Deleted.
3577         (JSC::Wasm::Module::validateAsync): Deleted.
3578         (JSC::Wasm::Module::signatureIndexFromFunctionIndexSpace): Deleted.
3579         (JSC::Wasm::Module::nonNullCodeBlock): Deleted.
3580         * wasm/js/JSWebAssemblyCodeBlock.cpp:
3581         (JSC::JSWebAssemblyCodeBlock::create):
3582         * wasm/js/JSWebAssemblyCodeBlock.h:
3583         (JSC::JSWebAssemblyCodeBlock::create): Deleted.
3584         * wasm/js/JSWebAssemblyModule.cpp:
3585         (JSC::JSWebAssemblyModule::source):
3586         * wasm/js/JSWebAssemblyModule.h:
3587         (JSC::JSWebAssemblyModule::source): Deleted.
3588         * wasm/js/WebAssemblyFunction.cpp:
3589         (JSC::callWebAssemblyFunction):
3590         * wasm/js/WebAssemblyModulePrototype.cpp:
3591
3592 2017-04-13  Mark Lam  <mark.lam@apple.com>
3593
3594         Should use flushDirect() when flushing the scopeRegister due to needsScopeRegister().
3595         https://bugs.webkit.org/show_bug.cgi?id=170661
3596         <rdar://problem/31579046>
3597
3598         Reviewed by Filip Pizlo.
3599
3600         Previously, we were using flush() to flush the outermost frame's scopeRegister.
3601         This is incorrect because flush() expects the VirtualRegister value passed to
3602         it to be that of the top most inlined frame.  In the event that we reach a
3603         terminal condition while inside an inlined frame, flush() will end up flushing
3604         the wrong register.  The fix is simply to use flushDirect() instead.
3605
3606         * dfg/DFGByteCodeParser.cpp:
3607         (JSC::DFG::ByteCodeParser::flush):
3608
3609 2017-04-13  Andy VanWagoner  <thetalecrafter@gmail.com>
3610
3611         Change Intl prototypes to plain objects
3612         https://bugs.webkit.org/show_bug.cgi?id=168178
3613
3614         Reviewed by JF Bastien.
3615
3616         * builtins/StringPrototype.js:
3617         (localeCompare): Create default Collator once instead of using prototype.
3618         * runtime/IntlCollatorPrototype.cpp:
3619         (JSC::IntlCollatorPrototype::IntlCollatorPrototype):
3620         * runtime/IntlCollatorPrototype.h:
3621         * runtime/IntlDateTimeFormatPrototype.cpp:
3622         (JSC::IntlDateTimeFormatPrototype::IntlDateTimeFormatPrototype):
3623         * runtime/IntlDateTimeFormatPrototype.h:
3624         * runtime/IntlNumberFormatPrototype.cpp:
3625         (JSC::IntlNumberFormatPrototype::IntlNumberFormatPrototype):
3626         * runtime/IntlNumberFormatPrototype.h:
3627         * runtime/IntlObject.cpp:
3628         (JSC::IntlObject::finishCreation): Don't set constructor on each prototype.
3629
3630 2017-04-13  Oliver Hunt  <oliver@apple.com>
3631
3632         allocationSize should use safe arithmetic by default
3633         https://bugs.webkit.org/show_bug.cgi?id=170804
3634
3635         Reviewed by JF Bastien.
3636
3637         Make all allocationSize() functions work in terms
3638         of Checked<size_t>
3639
3640         * runtime/DirectArguments.h:
3641         (JSC::DirectArguments::offsetOfSlot):
3642         (JSC::DirectArguments::allocationSize):
3643         * runtime/HashMapImpl.h:
3644         (JSC::HashMapBuffer::allocationSize):
3645         * runtime/JSArray.h:
3646         (JSC::JSArray::allocationSize):
3647         * runtime/JSArrayBufferView.h:
3648         (JSC::JSArrayBufferView::allocationSize):
3649         * runtime/JSAsyncFunction.h:
3650         (JSC::JSAsyncFunction::allocationSize):
3651         * runtime/JSFixedArray.h:
3652         (JSC::JSFixedArray::allocationSize):
3653         * runtime/JSFunction.h:
3654         (JSC::JSFunction::allocationSize):
3655         * runtime/JSGeneratorFunction.h:
3656         (JSC::JSGeneratorFunction::allocationSize):
3657         * runtime/JSModuleNamespaceObject.h:
3658         * runtime/JSObject.h:
3659         (JSC::JSFinalObject::allocationSize):
3660         * runtime/JSWrapperObject.h:
3661         (JSC::JSWrapperObject::allocationSize):
3662         * runtime/ScopedArguments.h:
3663         (JSC::ScopedArguments::allocationSize):
3664         * runtime/VM.h:
3665         (JSC::ScratchBuffer::allocationSize):
3666         * wasm/js/JSWebAssemblyCodeBlock.h:
3667         (JSC::JSWebAssemblyCodeBlock::offsetOfImportStubs):
3668         (JSC::JSWebAssemblyCodeBlock::allocationSize):
3669         * wasm/js/JSWebAssemblyInstance.h:
3670         (JSC::JSWebAssemblyInstance::allocationSize):
3671
3672 2017-04-13  JF Bastien  <jfbastien@apple.com>
3673
3674         WebAssembly: manage memory better
3675         https://bugs.webkit.org/show_bug.cgi?id=170628
3676
3677         Reviewed by Keith Miller, Michael Saboff.
3678
3679         WebAssembly fast memories weren't managed very well. This patch
3680         refactors it and puts us in a good position to further improve our
3681         fast memory handling in the future.
3682
3683         We now cache fast memories at a process granularity, but make sure
3684         that they don't consume dirty pages. We add a cap to the total
3685         number of allocated fast memories to avoid ASLR degradation.
3686
3687         We teach the GC about memories as a kind of resource it should
3688         care about because it didn't have visibility into the amount of
3689         memory each represented. This allows benchmarks which allocate
3690         memories back-to-back to reliably get fast memories 100% of the
3691         time, even on a system under load, which wasn't the case
3692         before. This reliability yields roughly 8% perf bump on x86-64
3693         WasmBench.
3694
3695         The GC heuristic is as follows: each time we allocate a fast
3696         memory we notify the GC, which then keeps track of the total
3697         number of fast memories allocated since it last GC'd. We
3698         separately keep track of the total number of fast memories which
3699         have ever existed at any point in time (cached + allocated). This
3700         is a monotonically-increasing high watermark. The GC will force a
3701         full collection if, since it last ran, half or more of the high
3702         watermark of fast memories was allocated.
3703
3704         At the same time, if we fail obtaining a fast memory from the
3705         cache we do a GC to try to find one. If that fails we'll allocate
3706         a new one (this can also fail, then we go to slow memory). This
3707         can also be improved, but it's a good start.
3708
3709         This currently disables fast memories on iOS because getting fast
3710         memories isn't a guaranteed thing. Rather, we get quite a few of
3711         them and achieve significant speedups, but benchmarks which
3712         allocate memories back-to-back end up falling behind because the
3713         GC can conservatively hold onto memories, which then yields a perf
3714         cliff. That cliff isn't reliable, WasmBench gets roughly 10 of 18
3715         fast memories when in theory it should get all of them fast (as
3716         MacOS does). The patch significantly improves the state of iOS
3717         though, and in a follow-up we could re-enable fast memories.
3718
3719         Part of this good positioning is a facility to pre-allocate fast
3720         memories very early at startup, before any fragmentation
3721         occurs. This is currently disabled but worked extremely reliably
3722         on iOS. Once we fix the above issues we'll want to re-visit and
3723         turn on pre-allocation.
3724
3725         We also avoid locking for fast memory identification when
3726         performing signal handling. I'm very nervous about acquiring locks
3727         in a signal handler because in general signals can happen when
3728         we've messed up. This isn't the case with fast memories: we're
3729         raising a signal on purpose and handling it. However this doesn't
3730         mean we won't mess up elsewhere! This will get more complicated
3731         once we add support for multiple threads sharing memories and
3732         being able to grow their memories. One example: the code calls
3733         CRASH(), which executes the following code in release:
3734
3735             *(int *)(uintptr_t)0xbbadbeef = 0;
3736
3737         This is a segfault, which our fast memory signal handler tries to
3738         handle. It does so by first figuring out whether 0xbbadbeef is in
3739         a fast memory region, reqiring a lock. If we CRASH() while holding
3740         the lock then our thread self-deadlocks, giving us no crash report
3741         and a bad user experience.
3742
3743         Avoiding a lock therefore it's not about speed or reduced
3744         contention. In fact, I'd use something else than a FIFO if these
3745         were a concern. We're also doing syscalls, which dwarf any locking
3746         cost.
3747
3748         We now only allocate 4GiB + redzone of 64k * 128 for fast memories
3749         instead of 8GiB. This patch reuses the logic from
3750         B3::WasmBoundsCheck to perform bounds checks when accesses could
3751         exceed the redzone. We'll therefore benefit from CSE goodness when
3752         it reaches WasmBoundsCheck. See bug #163469.
3753
3754         * b3/B3LowerToAir.cpp: fix a baaaaddd bug where unsigned->signed
3755         conversion allowed out-of-bounds reads by -2GiB. I'll follow-up in
3756         bug #170692 to prevent this type of bug once and for all.
3757         (JSC::B3::Air::LowerToAir::lower):
3758         * b3/B3Validate.cpp: update WasmBoundsCheck validation.
3759         * b3/B3Value.cpp:
3760         (JSC::B3::Value::effects): update WasmBoundsCheck effects.
3761         * b3/B3WasmBoundsCheckValue.cpp:
3762         (JSC::B3::WasmBoundsCheckValue::WasmBoundsCheckValue):
3763         (JSC::B3::WasmBoundsCheckValue::redzoneLimit):
3764         (JSC::B3::WasmBoundsCheckValue::dumpMeta):
3765         * b3/B3WasmBoundsCheckValue.h:
3766         (JSC::B3::WasmBoundsCheckValue::maximum):
3767         * b3/air/AirCustom.cpp:
3768         (JSC::B3::Air::WasmBoundsCheckCustom::isValidForm):
3769         * b3/testb3.cpp:
3770         (JSC::B3::testWasmBoundsCheck):
3771         * heap/Heap.cpp:
3772         (JSC::Heap::Heap):
3773         (JSC::Heap::reportWebAssemblyFastMemoriesAllocated):
3774         (JSC::Heap::webAssemblyFastMemoriesThisCycleAtThreshold):
3775         (JSC::Heap::updateAllocationLimits):
3776         (JSC::Heap::didAllocateWebAssemblyFastMemories):
3777         (JSC::Heap::shouldDoFullCollection):
3778         (JSC::Heap::collectIfNecessaryOrDefer):
3779         * heap/Heap.h:
3780         * runtime/InitializeThreading.cpp:
3781         (JSC::initializeThreading):
3782         * runtime/Options.cpp:
3783         * runtime/Options.h:
3784         * wasm/WasmB3IRGenerator.cpp:
3785         (JSC::Wasm::B3IRGenerator::fixupPointerPlusOffset):
3786         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
3787         (JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer):
3788         (JSC::Wasm::B3IRGenerator::emitLoadOp):
3789         (JSC::Wasm::B3IRGenerator::emitStoreOp):
3790         (JSC::Wasm::createJSToWasmWrapper):
3791         * wasm/WasmFaultSignalHandler.cpp:
3792         (JSC::Wasm::trapHandler):
3793         * wasm/WasmMemory.cpp: Rewrite.
3794         (JSC::Wasm::makeString):
3795         (JSC::Wasm::Memory::initializePreallocations):
3796         (JSC::Wasm::Memory::createImpl):
3797         (JSC::Wasm::Memory::create):
3798         (JSC::Wasm::Memory::~Memory):
3799         (JSC::Wasm::Memory::fastMappedRedzoneBytes):
3800         (JSC::Wasm::Memory::fastMappedBytes):
3801         (JSC::Wasm::Memory::maxFastMemoryCount):
3802         (JSC::Wasm::Memory::addressIsInActiveFastMemory):
3803         (JSC::Wasm::Memory::grow):
3804         * wasm/WasmMemory.h:
3805         (Memory::maxFastMemoryCount):
3806         (Memory::addressIsInActiveFastMemory):
3807         * wasm/js/JSWebAssemblyInstance.cpp:
3808         (JSC::JSWebAssemblyInstance::finishCreation):
3809         (JSC::JSWebAssemblyInstance::visitChildren):
3810         (JSC::JSWebAssemblyInstance::globalMemoryByteSize):
3811         * wasm/js/JSWebAssemblyInstance.h:
3812         * wasm/js/JSWebAssemblyMemory.cpp:
3813         (JSC::JSWebAssemblyMemory::grow):
3814         (JSC::JSWebAssemblyMemory::finishCreation):
3815         (JSC::JSWebAssemblyMemory::visitChildren):
3816
3817 2017-04-13  Yusuke Suzuki  <utatane.tea@gmail.com>
3818
3819         [JSC] Use proper ifdef guard for code using MachineContext
3820         https://bugs.webkit.org/show_bug.cgi?id=170800
3821
3822         Reviewed by Carlos Alberto Lopez Perez.
3823
3824         This patch drops MachineContext use if it is not available.
3825         This situation can be considered like, building WebKit with musl.
3826         In that case, we simply disable features that rely on MachineContext.
3827         Examples are wasm fast memory, sampling profiler, and code profiling.
3828
3829         * runtime/Options.cpp:
3830         (JSC::overrideDefaults):
3831         * tools/CodeProfiling.cpp:
3832         (JSC::CodeProfiling::begin):
3833         (JSC::CodeProfiling::end):
3834         Previously, PLATFORM(GTK) is excluded. But it is not obvious why it is excluded.
3835         This patch just includes such platforms.
3836
3837         * wasm/WasmFaultSignalHandler.cpp:
3838         (JSC::Wasm::enableFastMemory):
3839
3840 2017-04-12  Dan Bernstein  <mitz@apple.com>
3841
3842         [Mac] Future-proof .xcconfig files
3843         https://bugs.webkit.org/show_bug.cgi?id=170802
3844
3845         Reviewed by Tim Horton.
3846
3847         * Configurations/Base.xcconfig:
3848         * Configurations/DebugRelease.xcconfig:
3849         * Configurations/FeatureDefines.xcconfig:
3850         * Configurations/Version.xcconfig:
3851
3852 2017-04-12  Joseph Pecoraro  <pecoraro@apple.com>
3853
3854         test262: test262/test/built-ins/NativeErrors/EvalError/proto.js
3855         https://bugs.webkit.org/show_bug.cgi?id=170668
3856
3857         Reviewed by Keith Miller.
3858
3859         * runtime/JSGlobalObject.cpp:
3860         (JSC::JSGlobalObject::init):
3861         The [[Prototype]] of NativeError Constructor's should be the %Error%.
3862         https://tc39.github.io/ecma262/#sec-properties-of-the-nativeerror-constructors
3863
3864 2017-04-12  Joseph Pecoraro  <pecoraro@apple.com>
3865
3866         test262: test262/test/language/literals/regexp/u-dec-esc.js
3867         https://bugs.webkit.org/show_bug.cgi?id=170687
3868
3869         Reviewed by Michael Saboff.
3870
3871         * yarr/YarrParser.h:
3872         (JSC::Yarr::Parser::parseEscape):
3873         * yarr/YarrPattern.cpp:
3874         (JSC::Yarr::YarrPattern::errorMessage):
3875         (JSC::Yarr::YarrPattern::compile):
3876         * yarr/YarrPattern.h:
3877         In unicoe patterns, invalid backreferences are an error.
3878
3879 2017-04-12  Filip Pizlo  <fpizlo@apple.com>
3880
3881         Move common stack allocation utilities out of AirAllocateStackByGraphColoring.cpp
3882         https://bugs.webkit.org/show_bug.cgi?id=170799
3883
3884         Reviewed by Michael Saboff and Keith Miller.
3885         
3886         When I added stack allocation to allocateRegistersByLinearScan, I reused a handful of
3887         utility functions from AirAllocateStackByGraphColoring.cpp. I accomplished this by
3888         putting their declarations in AirAllocateStackByGraphColoring.h.
3889         
3890         That was pretty weird.
3891         
3892         This patch moves a family of stack allocation helper functions out of
3893         AirAllocateStackByGraphColoring.cpp and into the new AirStackAllocation.h|cpp. The
3894         linear scan stack allocator no longer has to include the other stack allocator's
3895         header, which addresses my OCD.
3896         
3897         I moved the functions transitively reachable from the two functions that the linear
3898         scan allocator needed. This forced me to give them better names (i.e. no "fooBarImpl")
3899         and short descriptive comments. I think that such comments are useful in code that is
3900         doing a convoluted version of some theoretical concept.
3901         
3902         No behavior change.
3903
3904         * CMakeLists.txt:
3905         * JavaScriptCore.xcodeproj/project.pbxproj:
3906         * b3/air/AirAllocateRegistersAndStackByLinearScan.cpp:
3907         * b3/air/AirAllocateStackByGraphColoring.cpp:
3908         (JSC::B3::Air::allocateStackByGraphColoring):
3909         (JSC::B3::Air::allocateEscapedStackSlots): Deleted.
3910         (JSC::B3::Air::updateFrameSizeBasedOnStackSlots): Deleted.
3911         * b3/air/AirAllocateStackByGraphColoring.h:
3912         * b3/air/AirStackAllocation.cpp: Added.
3913         (JSC::B3::Air::attemptAssignment):
3914         (JSC::B3::Air::assign):
3915         (JSC::B3::Air::allocateAndGetEscapedStackSlotsWithoutChangingFrameSize):
3916         (JSC::B3::Air::allocateEscapedStackSlots):
3917         (JSC::B3::Air::updateFrameSizeBasedOnStackSlots):
3918         * b3/air/AirStackAllocation.h: Added.
3919
3920 2017-04-12  Filip Pizlo  <fpizlo@apple.com>
3921
3922         B3 -O1 should not allocateStackByGraphColoring
3923         https://bugs.webkit.org/show_bug.cgi?id=170742
3924
3925         Reviewed by Keith Miller.
3926         
3927         One of B3 -O1's longest running phases is allocateStackByGraphColoring. One approach to
3928         this would be to make that phase cheaper. But it's weird that this phase reruns
3929         liveness after register allocation already ran liveness. If only it could reuse the
3930         liveness computed by register allocation then it would run a lot faster. At -O2, we do
3931         not want this, since we run phases between register allocation and stack allocation,
3932         and those phases are free to change the liveness of spill slots (in fact,
3933         fixObviousSpills will both shorten and lengthen live&nbs