DFG LICM needs to go all-in on the idea that some loops can't be LICMed
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2016-07-02  Filip Pizlo  <fpizlo@apple.com>
2
3         DFG LICM needs to go all-in on the idea that some loops can't be LICMed
4         https://bugs.webkit.org/show_bug.cgi?id=159388
5
6         Reviewed by Mark Lam.
7         
8         Some time ago I acknowledged that LICM required loops to meet certain requirements that
9         may get broken by the time we do LICM, like that the terminal of the pre-header is ExitOK.
10         It used to be that we just ignored that requirement and would hoist anyway, but since
11         r189126 we've stopped hoisting out of loops that don't have ExitOK.  We also added tests
12         for the case that the pre-header doesn't exist or is invalid.
13
14         It turns out that this patch didn't go far enough: even though it made LICM avoid loops
15         that had an invalid pre-header, the part that updated the AI state in nested loops still
16         assumed that these loops had valid pre-headers.  We would crash in null dereference in
17         that loop if a nested loop had an invalid pre-header.
18
19         The fix is simple: don't update the AI state of nested loops that don't have pre-headers,
20         since we won't try to hoist out of those loops anyway.
21
22         * dfg/DFGLICMPhase.cpp:
23         (JSC::DFG::LICMPhase::attemptHoist):
24         * tests/stress/licm-no-pre-header-nested.js: Added. This would always crash before this fix.
25         (foo):
26         * tests/stress/licm-pre-header-cannot-exit-nested.js: Added. This was a failed attempt at a test, but I figure it's good to have weird code anyway.
27         (foo):
28         (valueOf):
29
30 2016-06-30  Filip Pizlo  <fpizlo@apple.com>
31
32         Scopes that are not under TDZ should still push their variables onto the TDZ stack so that lifting TDZ doesn't bypass that scope
33         https://bugs.webkit.org/show_bug.cgi?id=159332
34         rdar://problem/27018958
35
36         Reviewed by Saam Barati.
37         
38         This fixes an instacrash in this code:
39         
40             try{}catch(e){}print(e);let e;
41         
42         We lift TDZ for "e" in "catch (e){}", but since that scope doesn't push anything onto the
43         TDZ stack, we lift TDZ from "let e".
44         
45         The problem is that we weren't tracking the set of variables that do not have TDZ. We need
46         to track them to "block" the traversal that lifts TDZ. This change fixes this issue by
47         using a map that tracks all known variables, and tells you if they are under TDZ or not.
48
49         * bytecode/CodeBlock.h:
50         (JSC::CodeBlock::numParameters):
51         * bytecode/CodeOrigin.h:
52         * bytecompiler/BytecodeGenerator.cpp:
53         (JSC::Label::setLocation):
54         (JSC::Variable::dump):
55         (JSC::BytecodeGenerator::generate):
56         (JSC::BytecodeGenerator::BytecodeGenerator):
57         (JSC::BytecodeGenerator::pushLexicalScopeInternal):
58         (JSC::BytecodeGenerator::popLexicalScope):
59         (JSC::BytecodeGenerator::popLexicalScopeInternal):
60         (JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
61         (JSC::BytecodeGenerator::variable):
62         (JSC::BytecodeGenerator::needsTDZCheck):
63         (JSC::BytecodeGenerator::liftTDZCheckIfPossible):
64         (JSC::BytecodeGenerator::pushTDZVariables):
65         (JSC::BytecodeGenerator::getVariablesUnderTDZ):
66         (JSC::BytecodeGenerator::endGenerator):
67         (WTF::printInternal):
68         * bytecompiler/BytecodeGenerator.h:
69         (JSC::Variable::isConst):
70         (JSC::Variable::setIsReadOnly):
71         * interpreter/CallFrame.h:
72         (JSC::ExecState::topOfFrame):
73         * tests/stress/lift-tdz-bypass-catch.js: Added.
74         (foo):
75         (catch):
76
77 2016-07-01  Benjamin Poulain  <bpoulain@apple.com>
78
79         [JSC] RegExp.compile is not returning the regexp when it succeed
80         https://bugs.webkit.org/show_bug.cgi?id=159381
81
82         Reviewed by Mark Lam.
83
84         Spec:
85         -https://tc39.github.io/ecma262/#sec-regexp.prototype.compile
86         -https://tc39.github.io/ecma262/#sec-regexpinitialize
87
88         * runtime/RegExpPrototype.cpp:
89         (JSC::regExpProtoFuncCompile):
90
91 2016-07-01  Saam Barati  <sbarati@apple.com>
92
93         fix "ASSERTION FAILED: currentOffset() >= currentLineStartOffset()"
94         https://bugs.webkit.org/show_bug.cgi?id=158572
95         <rdar://problem/26884092>
96
97         Reviewed by Mark Lam.
98
99         There is a bug in our lexer when we notice the pattern:
100         ```<return|continue|break|...etc> // some comment here```
101         Our code will say that the token for the comment is a semicolon.
102         This is the correct semantics, however, it would give the semicolon
103         a start offset of the comment, but it will give its line start offset
104         the newline after the comment.  This breaks the invariant in the lexer/parser
105         that the offset for the current line starting point must be less than or equal to
106         than the start offset of any token on that line. This invariant was broken because
107         the line start offset was greater than the token start offset. To maintain this
108         invariant, we claim that the semicolon token is located where the comment starts,
109         and that its line start offset is the line start offset for the line with the
110         comment on it.  There are other solutions that maintain this invariant, but this
111         solution provides the best error messages.
112
113         * parser/Lexer.cpp:
114         (JSC::Lexer<T>::lex):
115         * parser/Parser.h:
116         (JSC::Parser::internalSaveLexerState):
117         * tests/stress/obscure-error-message-dont-crash.js: Added.
118         (try.eval.or.catch):
119
120 2016-07-01  Benjamin Poulain  <bpoulain@apple.com>
121
122         __defineGetter__/__defineSetter__ should throw exceptions
123         https://bugs.webkit.org/show_bug.cgi?id=142934
124
125         Reviewed by Mark Lam.
126
127         * runtime/ObjectPrototype.cpp:
128         (JSC::objectProtoFuncDefineGetter):
129         (JSC::objectProtoFuncDefineSetter):
130
131 2016-07-01  Jon Davis  <jond@apple.com>
132
133         Moved Web Animations and Resource Timing feature entries to WebCore.
134         https://bugs.webkit.org/show_bug.cgi?id=159356
135
136         Reviewed by Timothy Hatcher.
137
138         * features.json:
139
140 2016-07-01  Benjamin Poulain  <bpoulain@apple.com>
141
142         [JSC] Date.toGMTString should be the Date.toUTCString function
143         https://bugs.webkit.org/show_bug.cgi?id=159318
144
145         Reviewed by Mark Lam.
146
147         See https://tc39.github.io/ecma262/#sec-date.prototype.togmtstring
148
149         * runtime/DatePrototype.cpp:
150         (JSC::DatePrototype::finishCreation):
151         (JSC::dateProtoFuncToGMTString): Deleted.
152
153 2016-07-01  Mark Lam  <mark.lam@apple.com>
154
155         Update JSC_functionOverrides to handle the new SourceCode strings that have params.
156         https://bugs.webkit.org/show_bug.cgi?id=159321
157
158         Reviewed by Geoffrey Garen.
159
160         And add tests so that this won't fail silently and bit rot anymore.
161
162         * API/tests/FunctionOverridesTest.cpp: Added.
163         (testFunctionOverrides):
164         * API/tests/FunctionOverridesTest.h: Added.
165         * API/tests/testapi-function-overrides.js: Added.
166         * API/tests/testapi.c:
167         (main):
168         * JavaScriptCore.xcodeproj/project.pbxproj:
169         * bytecode/UnlinkedFunctionExecutable.cpp:
170         (JSC::UnlinkedFunctionExecutable::link):
171         * shell/PlatformWin.cmake:
172         * tools/FunctionOverrides.cpp:
173         (JSC::FunctionOverrides::FunctionOverrides):
174         (JSC::FunctionOverrides::reinstallOverrides):
175         (JSC::initializeOverrideInfo):
176         (JSC::FunctionOverrides::initializeOverrideFor):
177         * tools/FunctionOverrides.h:
178         (JSC::FunctionOverrides::clear):
179
180 2016-07-01  Caio Lima  <ticaiolima@gmail.com>
181
182         ES6: Implement HasRestrictedGlobalProperty when checking for global lexical tier conflicts
183         https://bugs.webkit.org/show_bug.cgi?id=148763
184
185         Reviewed by Saam Barati
186
187         I've implemented the ES6 spec 8.1.1.4.14
188         (http://www.ecma-international.org/ecma-262/6.0/index.html#sec-hasrestrictedglobalproperty)
189         that defines when a global property can be shadowed.
190
191         Added some test cases into global-lexical-redeclare-variable.js
192
193         * runtime/Executable.cpp:
194         (JSC::ProgramExecutable::initializeGlobalProperties):
195         * tests/stress/global-lexical-redeclare-variable.js:
196         (catch):
197         * tests/stress/multiple-files-tests/global-lexical-redeclare-variable/eighth.js: Added.
198         * tests/stress/multiple-files-tests/global-lexical-redeclare-variable/nineth.js: Added.
199         * tests/stress/multiple-files-tests/global-lexical-redeclare-variable/seventh.js: Added.
200         * tests/stress/multiple-files-tests/global-lexical-redeclare-variable/sixth.js:
201         * tests/stress/multiple-files-tests/global-lexical-redeclare-variable/tenth.js: Added.
202
203 2016-07-01  Youenn Fablet  <youennf@gmail.com>
204
205         Add a runtime flag for DOM iterators
206         https://bugs.webkit.org/show_bug.cgi?id=159300
207
208         Reviewed by Alex Christensen.
209
210         * runtime/CommonIdentifiers.h:
211
212 2016-06-30  Joseph Pecoraro  <pecoraro@apple.com>
213
214         Web Inspector: Wrong function name next to scope
215         https://bugs.webkit.org/show_bug.cgi?id=158210
216         <rdar://problem/26543093>
217
218         Reviewed by Timothy Hatcher.
219
220         * CMakeLists.txt:
221         * JavaScriptCore.xcodeproj/project.pbxproj:
222         Add DebuggerLocation. A helper for describing a unique location.
223
224         * bytecode/CodeBlock.cpp:
225         (JSC::CodeBlock::setConstantRegisters):
226         When compiled with debug info, add a SymbolTable rare data pointer
227         back to the CodeBlock. This will be used later to get JSScope debug
228         info if Web Inspector pauses.
229
230         * runtime/SymbolTable.h:
231         * runtime/SymbolTable.cpp:
232         (JSC::SymbolTable::cloneScopePart):
233         (JSC::SymbolTable::prepareForTypeProfiling):
234         (JSC::SymbolTable::uniqueIDForVariable):
235         (JSC::SymbolTable::uniqueIDForOffset):
236         (JSC::SymbolTable::globalTypeSetForOffset):
237         (JSC::SymbolTable::globalTypeSetForVariable):
238         Rename rareData and include a CodeBlock pointer.
239
240         (JSC::SymbolTable::rareDataCodeBlock):
241         (JSC::SymbolTable::setRareDataCodeBlock):
242         Setter and getter for the rare data. It should only be set once.
243
244         (JSC::SymbolTable::visitChildren):
245         Visit the rare data code block if we have one.
246
247         * runtime/JSSymbolTableObject.h:
248         * runtime/JSSymbolTableObject.cpp:
249         (JSC::JSSymbolTableObject::deleteProperty):
250         (JSC::JSSymbolTableObject::getOwnNonIndexPropertyNames):
251         Give JSSymbolTable its own class info. JSWithScope was unexpectedly
252         inheriting from JSSymbolTable since it did not have its own and
253         was using JSScope's class info. Also do a bit of cleanup.
254
255         * debugger/DebuggerLocation.cpp: Added.
256         (JSC::DebuggerLocation::DebuggerLocation):
257         * debugger/DebuggerLocation.h: Added.
258         (JSC::DebuggerLocation::DebuggerLocation):
259         Construction from a ScriptExecutable.
260
261         * runtime/JSScope.cpp:
262         (JSC::JSScope::symbolTable):
263         * runtime/JSScope.h:
264         * debugger/DebuggerScope.h:
265         * debugger/DebuggerScope.cpp:
266         (JSC::DebuggerScope::name):
267         (JSC::DebuggerScope::location):
268         Name and location for a scope. This uses:
269         JSScope -> SymbolTable -> CodeBlock -> Executable
270
271         * inspector/protocol/Debugger.json:
272         * inspector/InjectedScriptSource.js:
273         (InjectedScript.CallFrameProxy.prototype._wrapScopeChain):
274         (InjectedScript.CallFrameProxy._createScopeJson):
275         * inspector/JSJavaScriptCallFrame.cpp:
276         (Inspector::valueForScopeType):
277         (Inspector::valueForScopeLocation):
278         (Inspector::JSJavaScriptCallFrame::scopeDescriptions):
279         (Inspector::JSJavaScriptCallFrame::scopeType): Deleted.
280         * inspector/JSJavaScriptCallFrame.h:
281         * inspector/JSJavaScriptCallFramePrototype.cpp:
282         (Inspector::JSJavaScriptCallFramePrototype::finishCreation):
283         (Inspector::jsJavaScriptCallFramePrototypeFunctionScopeDescriptions):
284         (Inspector::jsJavaScriptCallFramePrototypeFunctionScopeType): Deleted.
285         Simplify this code to build the objects we will send across the protocol
286         to descript a Scope.
287
288 2016-06-30  Saam Barati  <sbarati@apple.com>
289
290         missing exception checks in arrayProtoFuncReverse
291         https://bugs.webkit.org/show_bug.cgi?id=159319
292         <rdar://problem/27083696>
293
294         Reviewed by Filip Pizlo.
295
296         * runtime/ArrayPrototype.cpp:
297         (JSC::arrayProtoFuncToString):
298         (JSC::arrayProtoFuncReverse):
299
300 2016-06-30  Saam Barati  <sbarati@apple.com>
301
302         get_by_id_with_this does not trigger a to_this in caller.
303         https://bugs.webkit.org/show_bug.cgi?id=159226
304
305         Reviewed by Keith Miller.
306
307         This is a bug if the caller is in sloppy mode and the callee is in strict
308         mode. This can't happen with ES6 classes because they're all in strict mode,
309         but it can happen with method syntax on an object literal. The caller must
310         to_this on |this| when it knows that it performs super property accesses.
311
312         * bytecompiler/BytecodeGenerator.cpp:
313         (JSC::BytecodeGenerator::BytecodeGenerator):
314         * tests/stress/super-property-access-object-literal-to-this-2.js: Added.
315         (assert):
316         (test):
317         (let.o1.get foo):
318         (let.o2.a):
319         (let.o2.aa):
320         * tests/stress/super-property-access-object-literal-to-this.js: Added.
321         (assert):
322         (test):
323         (let.o1.get foo):
324         (let.o2.a):
325         (let.o2.aa):
326         (let.o2.b):
327         (let.o2.bb):
328         * tests/stress/super-property-access-to-this.js: Added.
329         (assert):
330         (test):
331         (Base.prototype.get foo):
332         (Base):
333         (Child.prototype.a):
334         (Child.prototype.b):
335         (Child):
336
337 2016-06-30  Saam Barati  <sbarati@apple.com>
338
339         We need to to_this when an inner arrow function uses 'this'
340         https://bugs.webkit.org/show_bug.cgi?id=159290
341         <rdar://problem/27058322>
342
343         Reviewed by Geoffrey Garen.
344
345         We put the |this| value into the closure object when there
346         is an arrow function that uses |this|. However, an arrow function
347         using |this| wasn't causing the creator of the closure that
348         holds |this| to to_this its value before putting it in the
349         closure. That's a huge bug because it means some arrow functions
350         can capture the raw |this| value, which might be a JSLexicalEnvironment.
351         This patch fixes this by adding an easy to check to see if any
352         inner arrow functions use |this|, and if any do, it will to_this
353         the |this| value.
354
355         * bytecompiler/BytecodeGenerator.cpp:
356         (JSC::BytecodeGenerator::BytecodeGenerator):
357         * tests/stress/to-this-before-arrow-function-closes-over-this-that-starts-as-lexical-environment.js: Added.
358         (assert):
359         (obj):
360         (foo.capture):
361         (foo.wrapper.let.x.):
362         (foo2.capture):
363         (foo2.wrapper.let.x.):
364         (foo2.wrapper.bar):
365
366 2016-06-29  Filip Pizlo  <fpizlo@apple.com>
367
368         Generators violate bytecode liveness validation
369         https://bugs.webkit.org/show_bug.cgi?id=159279
370
371         Reviewed by Yusuke Suzuki.
372         
373         Fix a liveness bug found by Basic. The problem is that resume's intended liveness rule is:
374         "live-in is just the token argument", but the liveness analysis thought that the rule was
375         "live-in is live-out minus defs plus live-at-catch". Clearly these two rules are quite
376         different. The way this sort of worked before is that we would define the defs of resume
377         as being equal to our prediction of what the live-outs would be. We did this in the hope
378         that we would subtract all live-outs. But, this misses the live-at-catch part. So, this
379         change adds another hack to neutralize live-at-catch.
380         
381         This would make a lot more sense if we wrote a new liveness analysis that was just for
382         generator conversion. It could reuse BytecodeUseDef but otherwise it would be a new thing.
383         It would be easy to write crazy rules for save/resume in such an analysis, especially if
384         that analysis rewrote the bytecode. We could then just have an op_yield that is a no-op.
385         We would just record the live-outs of op_yield and use that for rewriting the code in terms
386         of a switch statement.
387
388         * bytecode/BytecodeLivenessAnalysis.cpp:
389         (JSC::stepOverInstruction):
390         (JSC::BytecodeLivenessAnalysis::dumpResults):
391         * bytecode/CodeBlock.cpp:
392         (JSC::CodeBlock::dumpBytecode):
393
394 2016-06-30  Commit Queue  <commit-queue@webkit.org>
395
396         Unreviewed, rolling out r202659.
397         https://bugs.webkit.org/show_bug.cgi?id=159305
398
399         The test for this change times out on mac-wk2 debug and caused
400         an existing test to crash. (Requested by ryanhaddad on
401         #webkit).
402
403         Reverted changeset:
404
405         "Web Inspector: Wrong function name next to scope"
406         https://bugs.webkit.org/show_bug.cgi?id=158210
407         http://trac.webkit.org/changeset/202659
408
409 2016-06-30  Benjamin Poulain  <bpoulain@apple.com>
410
411         [JSC] Date.setYear() misses timeClip()
412         https://bugs.webkit.org/show_bug.cgi?id=159289
413
414         Reviewed by Geoffrey Garen.
415
416         * runtime/DatePrototype.cpp:
417         (JSC::dateProtoFuncSetYear):
418
419 2016-06-30  Joseph Pecoraro  <pecoraro@apple.com> and Yusuke Suzuki  <utatane.tea@gmail.com>
420
421         [JSC] Implement isFinite / isNaN in JS and make DFG ToNumber accept non number values
422         https://bugs.webkit.org/show_bug.cgi?id=154022
423
424         Reviewed by Filip Pizlo.
425
426         We aim at optimizing @toInteger operation.
427         While it still has an unoptimized part[1], this patch should be a first step.
428
429         We introduce the @toNumber builtin intrinsic operation.
430         This converts the given value to the JS number by emitting op_to_number bytecode.
431         Previously @toInteger called C++ @Number constructor for that purpose.
432
433         And in DFG, op_to_number is converted to DFG ToNumber node.
434         During DFG, we attempt to convert this to edge filtering and Identity, but if we fail,
435         we just fall back to calling the C++ function.
436
437         To utilize ToNumber in user-land side, we add a path attempting to convert Number constructor calls
438         to ToNumber DFG nodes. This conversion is useful because `Number(value)` is used to convert a value to a number in JS.
439
440         Before this patch, we emit simple edge filtering (NumberUse) instead of emitting DFG node like ToNumber for op_to_number.
441         But emitting ToNumber is useful, because in the case of `Number(value)`, considering `value` may not be a number is reasonable.
442
443         By leveraging @toNumber operation, we rewrite Number.{isFinite, isNaN}, global.{isFinite, isNaN} and @toInteger.
444
445         ToNumber DFG node has a value profiling. This profiling is leveraged to determine the result number type of the ToNumber operation.
446         This value profiling is provided from either NumberConstructor's call operation or op_to_number.
447
448         The results (with the added performance tests) show that, while existing cases are performance neutral, the newly added cases gain the performance benefit.
449         And ASMBench/n-body.c also shows stable ~2% progression.
450
451         [1]: https://bugs.webkit.org/show_bug.cgi?id=153738
452
453         * CMakeLists.txt:
454         * DerivedSources.make:
455         * JavaScriptCore.xcodeproj/project.pbxproj:
456         * builtins/BuiltinNames.h:
457         * builtins/GlobalObject.js:
458         (globalPrivate.isFinite):
459         (globalPrivate.isNaN):
460         (globalPrivate.toInteger): Deleted.
461         (globalPrivate.toLength): Deleted.
462         (globalPrivate.isDictionary): Deleted.
463         (globalPrivate.speciesGetter): Deleted.
464         (globalPrivate.speciesConstructor): Deleted.
465         * builtins/GlobalOperations.js: Copied from Source/JavaScriptCore/builtins/GlobalObject.js.
466         (globalPrivate.toInteger):
467         (globalPrivate.toLength):
468         (globalPrivate.isDictionary):
469         (globalPrivate.speciesGetter):
470         (globalPrivate.speciesConstructor):
471         * builtins/NumberConstructor.js: Added.
472         (isFinite):
473         (isNaN):
474         * bytecode/BytecodeIntrinsicRegistry.cpp:
475         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
476         * bytecode/BytecodeIntrinsicRegistry.h:
477         * bytecode/BytecodeList.json:
478         * bytecode/CodeBlock.cpp:
479         (JSC::CodeBlock::dumpBytecode):
480         (JSC::CodeBlock::finishCreation):
481         * bytecompiler/BytecodeGenerator.cpp:
482         (JSC::BytecodeGenerator::emitUnaryOp):
483         (JSC::BytecodeGenerator::emitUnaryOpProfiled):
484         * bytecompiler/BytecodeGenerator.h:
485         (JSC::BytecodeGenerator::emitToNumber):
486         * bytecompiler/NodesCodegen.cpp:
487         (JSC::BytecodeIntrinsicNode::emit_intrinsic_toNumber):
488         (JSC::UnaryPlusNode::emitBytecode):
489         * dfg/DFGAbstractInterpreterInlines.h:
490         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
491         * dfg/DFGBackwardsPropagationPhase.cpp:
492         (JSC::DFG::BackwardsPropagationPhase::propagate):
493         * dfg/DFGByteCodeParser.cpp:
494         (JSC::DFG::ByteCodeParser::attemptToInlineCall):
495         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
496         (JSC::DFG::ByteCodeParser::parseBlock):
497         We use `getPrediction()` to retrieve the heap prediction from the to_number bytecode.
498         According to the benchmark results, choosing `getPredictionWithoutOSRExit()` causes performance regression (1.5%) in kraken stanford-crypto-aes.
499
500         * dfg/DFGClobberize.h:
501         (JSC::DFG::clobberize):
502         * dfg/DFGConstantFoldingPhase.cpp:
503         (JSC::DFG::ConstantFoldingPhase::foldConstants):
504         * dfg/DFGDoesGC.cpp:
505         (JSC::DFG::doesGC):
506         * dfg/DFGFixupPhase.cpp:
507         (JSC::DFG::FixupPhase::fixupNode):
508         (JSC::DFG::FixupPhase::fixupToNumber):
509         * dfg/DFGNode.h:
510         (JSC::DFG::Node::hasHeapPrediction):
511         * dfg/DFGNodeType.h:
512         * dfg/DFGOperations.cpp:
513         * dfg/DFGOperations.h:
514         * dfg/DFGPredictionPropagationPhase.cpp:
515         Always on the heap prediction.
516
517         * dfg/DFGSafeToExecute.h:
518         (JSC::DFG::safeToExecute):
519         * dfg/DFGSpeculativeJIT32_64.cpp:
520         (JSC::DFG::SpeculativeJIT::compile):
521         As of 64bit version, we carefully manage the register reuse. The largest difference between 32bit and 64bit is
522         `branchIfNotNumber()` requires the temporary register. We should not use the result registers for that since
523         it may be reuse the argument registers and it can break the argument registers before using them to call the operation.
524         Currently, we allocate the additional temporary register for that scratch register.
525
526         * dfg/DFGSpeculativeJIT64.cpp:
527         (JSC::DFG::SpeculativeJIT::compile):
528         Reuse the argument register for the result if possible. And manually decrement the use count in the middle of the node.
529         This is similar technique used in ToPrimitive. Typically, the child of ToNumber is only used by this ToNumber node since
530         we would like to perform the type conversion onto this child node here. So this careful register reuse effectively removes
531         the spills to call the operation. The example of the actually emitted code is the following.
532
533         76:<!2:loc11>     ToNumber(Untyped:@68, JS|MustGen|UseAsOther, DoubleimpurenanTopEmpty, R:World, W:Heap, Exits, ClobbersExit, bc#48)  predicting DoubleimpurenanTopEmpty
534             0x7f986d5fe693: test %rax, %r14
535             0x7f986d5fe696: jz 0x7f986d5fe6a1
536             0x7f986d5fe69c: jmp 0x7f986d5fe6d1
537             0x7f986d5fe6a1: mov %rax, %rsi
538             0x7f986d5fe6a4: mov %rbp, %rdi
539             0x7f986d5fe6a7: mov $0x2, 0x24(%rbp)
540             0x7f986d5fe6ae: mov $0x7f98711ea5f0, %r11
541             0x7f986d5fe6b8: call *%r11
542             0x7f986d5fe6bb: mov $0x7f982d3f72d0, %r11
543             0x7f986d5fe6c5: mov (%r11), %r11
544             0x7f986d5fe6c8: test %r11, %r11
545             0x7f986d5fe6cb: jnz 0x7f986d5fe88c
546
547         It effectively removes the unnecessary spill to call the operation!
548
549         * ftl/FTLCapabilities.cpp:
550         (JSC::FTL::canCompile):
551         * ftl/FTLLowerDFGToB3.cpp:
552         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
553         (JSC::FTL::DFG::LowerDFGToB3::compileToNumber):
554         (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
555         * jit/AssemblyHelpers.h:
556         (JSC::AssemblyHelpers::branchIfNumber):
557         (JSC::AssemblyHelpers::branchIfNotNumber):
558         * jit/JITOpcodes.cpp:
559         (JSC::JIT::emit_op_to_number):
560         * jit/JITOpcodes32_64.cpp:
561         (JSC::JIT::emit_op_to_number):
562         * llint/LowLevelInterpreter32_64.asm:
563         * llint/LowLevelInterpreter64.asm:
564         * parser/Nodes.h:
565         (JSC::UnaryOpNode::opcodeID):
566         * runtime/CommonSlowPaths.cpp:
567         (JSC::SLOW_PATH_DECL):
568         * runtime/JSGlobalObject.cpp:
569         (JSC::JSGlobalObject::init):
570         * runtime/JSGlobalObjectFunctions.cpp:
571         (JSC::globalFuncIsNaN): Deleted.
572         (JSC::globalFuncIsFinite): Deleted.
573         * runtime/JSGlobalObjectFunctions.h:
574         * runtime/MathCommon.h:
575         (JSC::maxSafeInteger):
576         (JSC::minSafeInteger):
577         * runtime/NumberConstructor.cpp:
578         (JSC::NumberConstructor::finishCreation):
579         (JSC::numberConstructorFuncIsFinite): Deleted.
580         (JSC::numberConstructorFuncIsNaN): Deleted.
581         * runtime/NumberConstructor.h:
582         * tests/stress/Number-isNaN-basics.js: Added.
583         (numberIsNaNOnInteger):
584         (testNumberIsNaNOnIntegers):
585         (verifyNumberIsNaNOnIntegerWithOtherTypes):
586         (numberIsNaNOnDouble):
587         (testNumberIsNaNOnDoubles):
588         (verifyNumberIsNaNOnDoublesWithOtherTypes):
589         (numberIsNaNNoArguments):
590         (numberIsNaNTooManyArguments):
591         (testNumberIsNaNOnConstants):
592         (numberIsNaNStructTransition):
593         (Number.isNaN):
594         * tests/stress/global-is-finite.js: Added.
595         (shouldBe):
596         * tests/stress/global-is-nan.js: Added.
597         (shouldBe):
598         * tests/stress/global-isNaN-basics.js: Added.
599         (isNaNOnInteger):
600         (testIsNaNOnIntegers):
601         (verifyIsNaNOnIntegerWithOtherTypes):
602         (isNaNOnDouble):
603         (testIsNaNOnDoubles):
604         (verifyIsNaNOnDoublesWithOtherTypes):
605         (verifyIsNaNOnCoercedTypes):
606         (isNaNNoArguments):
607         (isNaNTooManyArguments):
608         (testIsNaNOnConstants):
609         (isNaNTypeCoercionSideEffects):
610         (i.value.isNaNTypeCoercionSideEffects.valueOf):
611         (isNaNStructTransition):
612         (isNaN):
613         * tests/stress/number-is-finite.js: Added.
614         (shouldBe):
615         (test2):
616         (test3):
617         * tests/stress/number-is-nan.js: Added.
618         (shouldBe):
619         (test2):
620         (test3):
621         * tests/stress/to-number-basics.js: Added.
622         (shouldBe):
623         * tests/stress/to-number-convert-identity-without-execution.js: Added.
624         (shouldBe):
625         (object.valueOf):
626         (valueOf):
627         * tests/stress/to-number-int52.js: Added.
628         (shouldBe):
629         (object.valueOf):
630         * tests/stress/to-number-intrinsic-convert-to-identity-without-execution.js: Added.
631         (shouldBe):
632         (object.valueOf):
633         (valueOf):
634         * tests/stress/to-number-intrinsic-int52.js: Added.
635         (shouldBe):
636         (object.valueOf):
637         * tests/stress/to-number-intrinsic-object-without-execution.js: Added.
638         (shouldBe):
639         (object.valueOf):
640         * tests/stress/to-number-intrinsic-value-profiling.js: Added.
641         (shouldBe):
642         (object.valueOf):
643         * tests/stress/to-number-object-without-execution.js: Added.
644         (shouldBe):
645         (object.valueOf):
646         * tests/stress/to-number-object.js: Added.
647         (shouldBe):
648         (test12):
649         (object1.valueOf):
650         (test2):
651         (test22):
652         (object2.valueOf):
653         (test3):
654         (test32):
655         (object3.valueOf):
656         * tests/stress/to-number-value-profiling.js: Added.
657         (shouldBe):
658         (object.valueOf):
659
660 2016-06-29  Benjamin Poulain  <benjamin@webkit.org>
661
662         Fix the debug build after r202667
663
664         * runtime/JSTypedArrayViewPrototype.cpp:
665         (JSC::JSTypedArrayViewPrototype::finishCreation):
666         The putDirect was missing the Accessor flag for the GetterSetter.
667
668 2016-06-29  Michael Saboff  <msaboff@apple.com>
669
670         REGRESSION(200114): Netflix app does not see ChromeCast
671         https://bugs.webkit.org/show_bug.cgi?id=159287
672
673         Reviewed by Benjamin Poulain.
674
675         Change set 200114 changed the behavior of how we check for whether or not we
676         wrap Objective C init methods in JavaScript constructors.  The prior method
677         checked the version of JavaScriptCore that was linked with the application.
678         If the application was not directly linked with JavaScriptCore the prior
679         method indicated that we shouldn't create constructors.  The new method uses
680         the SDK the application was compiled with.  Using the new method, an
681         application compiled with iOS SDK 8.0 or greater would create constructors
682         and not export init methods to JavaScript.  The problem is that an existing
683         application that hasn't been recompiled will get a different answer using
684         the new method.  We need to come up with a method that works in a compatible
685         way with existing programs, but provides a newly compiled program with the
686         "is built with SDK N or greater" check.
687         
688         Added back the prior check of the version of JavaScriptCore the program was
689         directly linked against.  However we only use this check if we directly linked
690         with JavaScriptCore.  Otherwise we fall through to check against the SDK the
691         program was built with.  Changed the iOS SDK version we check
692         against to be the new version of iOS, iOS 10.
693
694         This provides compatible behavior for existing programs.  It may be the case
695         that some of those programs may require changes when they are rebuilt with the
696         iOS 10 SDK or later.
697
698         * API/JSWrapperMap.mm:
699         (supportsInitMethodConstructors):
700
701 2016-06-29  Benjamin Poulain  <bpoulain@apple.com>
702
703         [JSC] Minor TypedArray fixes
704         https://bugs.webkit.org/show_bug.cgi?id=159286
705
706         Reviewed by Keith Miller.
707
708         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
709         (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::finishCreation):
710         See https://tc39.github.io/ecma262/#sec-%typedarray%
711
712         * runtime/JSTypedArrayViewPrototype.cpp:
713         (JSC::typedArrayViewPrivateFuncLength):
714         See https://tc39.github.io/ecma262/#sec-get-%typedarray%.prototype.length
715
716         (JSC::typedArrayViewProtoGetterFuncToStringTag):
717         Yep, that's odd.
718         See https://tc39.github.io/ecma262/#sec-get-%typedarray%.prototype-@@tostringtag
719
720         (JSC::JSTypedArrayViewPrototype::finishCreation):
721         See the last paragraph of https://tc39.github.io/ecma262/#sec-ecmascript-standard-built-in-objects
722
723 2016-06-29  Joseph Pecoraro  <pecoraro@apple.com>
724
725         Web Inspector: API View of Native DOM APIs looks poor (TypeErrors for native getters)
726         https://bugs.webkit.org/show_bug.cgi?id=158334
727         <rdar://problem/26615366>
728
729         Reviewed by Timothy Hatcher.
730
731         * inspector/InjectedScriptSource.js:
732         (InjectedScript.prototype._getProperties):
733         (InjectedScript.prototype._propertyDescriptors):
734         Do not create fake value property descriptors for native accessors
735         unless requested. This means, getProperties for a native prototype
736         should return  accessors for native accessors just like it does
737         for normal non-native accessors (getters/setters).
738
739         (InjectedScript.prototype.getProperties):
740         Do not produce fake value accessors for native accessors.
741
742         (InjectedScript.prototype.getDisplayableProperties):
743         (InjectedScript.RemoteObject.prototype._generatePreview):
744         Do produce fake value accessors for native accessors.
745
746 2016-06-29  Saam barati  <sbarati@apple.com>
747
748         JSGlobalLexicalEnvironment needs a toThis implementation
749         https://bugs.webkit.org/show_bug.cgi?id=159285
750
751         Reviewed by Mark Lam.
752
753         This was a huge oversight of my original implementation. It gave users
754         of the language direct access to the JSGlobalLexicalEnvironment object.
755
756         * runtime/JSGlobalLexicalEnvironment.cpp:
757         (JSC::JSGlobalLexicalEnvironment::isConstVariable):
758         (JSC::JSGlobalLexicalEnvironment::toThis):
759         * runtime/JSGlobalLexicalEnvironment.h:
760         (JSC::JSGlobalLexicalEnvironment::isEmpty):
761         * tests/stress/global-lexical-environment-to-this.js: Added.
762         (assert):
763         (let.f):
764         (let.fStrict):
765
766 2016-06-29  Joseph Pecoraro  <pecoraro@apple.com>
767
768         Web Inspector: Wrong function name next to scope
769         https://bugs.webkit.org/show_bug.cgi?id=158210
770         <rdar://problem/26543093>
771
772         Reviewed by Brian Burg.
773
774         * CMakeLists.txt:
775         * JavaScriptCore.xcodeproj/project.pbxproj:
776         Add DebuggerLocation. A helper for describing a unique location.
777
778         * bytecode/CodeBlock.cpp:
779         (JSC::CodeBlock::setConstantRegisters):
780         When compiled with debug info, add a SymbolTable rare data pointer
781         back to the CodeBlock. This will be used later to get JSScope debug
782         info if Web Inspector pauses.
783
784         * runtime/SymbolTable.h:
785         * runtime/SymbolTable.cpp:
786         (JSC::SymbolTable::cloneScopePart):
787         (JSC::SymbolTable::prepareForTypeProfiling):
788         (JSC::SymbolTable::uniqueIDForVariable):
789         (JSC::SymbolTable::uniqueIDForOffset):
790         (JSC::SymbolTable::globalTypeSetForOffset):
791         (JSC::SymbolTable::globalTypeSetForVariable):
792         Rename rareData and include a CodeBlock pointer.
793
794         (JSC::SymbolTable::rareDataCodeBlock):
795         (JSC::SymbolTable::setRareDataCodeBlock):
796         Setter and getter for the rare data. It should only be set once.
797
798         (JSC::SymbolTable::visitChildren):
799         Visit the rare data code block if we have one.
800
801         * debugger/DebuggerLocation.cpp: Added.
802         (JSC::DebuggerLocation::DebuggerLocation):
803         * debugger/DebuggerLocation.h: Added.
804         (JSC::DebuggerLocation::DebuggerLocation):
805         Construction from a ScriptExecutable.
806
807         * runtime/JSScope.cpp:
808         (JSC::JSScope::symbolTable):
809         * runtime/JSScope.h:
810         * debugger/DebuggerScope.h:
811         * debugger/DebuggerScope.cpp:
812         (JSC::DebuggerScope::name):
813         (JSC::DebuggerScope::location):
814         Name and location for a scope. This uses:
815         JSScope -> SymbolTable -> CodeBlock -> Executable
816
817         * inspector/protocol/Debugger.json:
818         * inspector/InjectedScriptSource.js:
819         (InjectedScript.CallFrameProxy.prototype._wrapScopeChain):
820         (InjectedScript.CallFrameProxy._createScopeJson):
821         * inspector/JSJavaScriptCallFrame.cpp:
822         (Inspector::valueForScopeType):
823         (Inspector::valueForScopeLocation):
824         (Inspector::JSJavaScriptCallFrame::scopeDescriptions):
825         (Inspector::JSJavaScriptCallFrame::scopeType): Deleted.
826         * inspector/JSJavaScriptCallFrame.h:
827         * inspector/JSJavaScriptCallFramePrototype.cpp:
828         (Inspector::JSJavaScriptCallFramePrototype::finishCreation):
829         (Inspector::jsJavaScriptCallFramePrototypeFunctionScopeDescriptions):
830         (Inspector::jsJavaScriptCallFramePrototypeFunctionScopeType): Deleted.
831         Simplify this code to build the objects we will send across the protocol
832         to descript a Scope.
833
834 2016-06-29  Saam barati  <sbarati@apple.com>
835
836         We don't emit TDZ checks for call_eval
837         https://bugs.webkit.org/show_bug.cgi?id=159277
838         <rdar://problem/27018801>
839
840         Reviewed by Benjamin Poulain.
841
842         This is a problem if you're trying to call a TDZ variable
843         that is named 'eval'.
844
845         * bytecompiler/NodesCodegen.cpp:
846         (JSC::EvalFunctionCallNode::emitBytecode):
847         * tests/stress/variable-named-eval-under-tdz.js: Added.
848         (shouldThrowTDZ):
849         (test):
850         (test.foo):
851         (throw.new.Error):
852
853 2016-06-29  Mark Lam  <mark.lam@apple.com>
854
855         Add support for collecting cumulative LLINT stats via a JSC_llintStatsFile option.
856         https://bugs.webkit.org/show_bug.cgi?id=159274
857
858         Reviewed by Keith Miller.
859
860         * jsc.cpp:
861         (main):
862         * llint/LLIntData.cpp:
863         (JSC::LLInt::initialize):
864         (JSC::LLInt::Data::finalizeStats):
865         (JSC::LLInt::compareStats):
866         (JSC::LLInt::Data::dumpStats):
867         (JSC::LLInt::Data::ensureStats):
868         (JSC::LLInt::Data::loadStats):
869         (JSC::LLInt::Data::resetStats):
870         (JSC::LLInt::Data::saveStats):
871         * llint/LLIntData.h:
872         (JSC::LLInt::Data::opcodeStats):
873         * runtime/Options.cpp:
874         (JSC::Options::isAvailable):
875         (JSC::recomputeDependentOptions):
876         (JSC::Options::initialize):
877         * runtime/Options.h:
878
879 2016-06-29  Saam barati  <sbarati@apple.com>
880
881         Destructuring variable declaration is missing a validation of the syntax of a sub production when there is a rhs
882         https://bugs.webkit.org/show_bug.cgi?id=159267
883
884         Reviewed by Mark Lam.
885
886         We were parsing something without checking if it had a syntax error.
887         This is wrong for many reasons, but it could actually cause a crash
888         in a debug build if you parsed particular programs.
889
890         * parser/Parser.cpp:
891         (JSC::Parser<LexerType>::parseVariableDeclarationList):
892
893 2016-06-29  Joseph Pecoraro  <pecoraro@apple.com>
894
895         Web Inspector: Show Shadow Root type in DOM Tree
896         https://bugs.webkit.org/show_bug.cgi?id=159236
897         <rdar://problem/27068521>
898
899         Reviewed by Timothy Hatcher.
900
901         * inspector/protocol/DOM.json:
902         Include optional shadowRootType property for DOMNodes.
903
904 2016-06-29  Commit Queue  <commit-queue@webkit.org>
905
906         Unreviewed, rolling out r202627.
907         https://bugs.webkit.org/show_bug.cgi?id=159266
908
909         patch is broken on arm (Requested by keith_miller on #webkit).
910
911         Reverted changeset:
912
913         "LLInt should support other types of prototype GetById
914         caching."
915         https://bugs.webkit.org/show_bug.cgi?id=158083
916         http://trac.webkit.org/changeset/202627
917
918 2016-06-29  Benjamin Poulain  <bpoulain@apple.com>
919
920         [JSC] Fix small issues of TypedArray prototype
921         https://bugs.webkit.org/show_bug.cgi?id=159248
922
923         Reviewed by Saam Barati.
924
925         First, TypedArray's toString and Array's toString
926         should be the same function.
927         I moved the function to GlobalObject and each array type
928         gets it as needed.
929
930         Then TypedArray length was supposed to be configurable.
931         I removed the "DontDelete" flag accordingly.
932
933         * runtime/ArrayPrototype.cpp:
934         (JSC::ArrayPrototype::finishCreation):
935         * runtime/JSGlobalObject.cpp:
936         (JSC::JSGlobalObject::init):
937         (JSC::JSGlobalObject::visitChildren):
938         * runtime/JSGlobalObject.h:
939         (JSC::JSGlobalObject::arrayProtoToStringFunction):
940         * runtime/JSTypedArrayViewPrototype.cpp:
941         (JSC::JSTypedArrayViewPrototype::finishCreation):
942
943 2016-06-29  Caio Lima  <ticaiolima@gmail.com>
944
945         LLInt should support other types of prototype GetById caching.
946         https://bugs.webkit.org/show_bug.cgi?id=158083
947
948         Recently, we started supporting prototype load caching for get_by_id
949         in the LLInt. This patch is expading the caching strategy to enable
950         cache the prototype accessor and custom acessors.
951
952         Similarly to the get_by_id_proto_load bytecode, we are adding new
953         bytecodes called get_by_id_proto_accessor that uses the calculated
954         offset of a object to call a getter function and get_by_id_proto_custom
955         that stores the pointer to the custom function and call them directly
956         from LowLevelInterpreter.
957
958         Reviewed by Keith Miller
959
960         * bytecode/BytecodeList.json:
961         * bytecode/BytecodeUseDef.h:
962         (JSC::computeUsesForBytecodeOffset):
963         (JSC::computeDefsForBytecodeOffset):
964         * bytecode/CodeBlock.cpp:
965         (JSC::CodeBlock::printGetByIdOp):
966         (JSC::CodeBlock::dumpBytecode):
967         (JSC::CodeBlock::finalizeLLIntInlineCaches):
968         * bytecode/GetByIdStatus.cpp:
969         (JSC::GetByIdStatus::computeFromLLInt):
970         * dfg/DFGByteCodeParser.cpp:
971         (JSC::DFG::ByteCodeParser::parseBlock):
972         * dfg/DFGCapabilities.cpp:
973         (JSC::DFG::capabilityLevel):
974         * jit/JIT.cpp:
975         (JSC::JIT::privateCompileMainPass):
976         (JSC::JIT::privateCompileSlowCases):
977         * llint/LLIntSlowPaths.cpp:
978         (JSC::LLInt::setupGetByIdPrototypeCache):
979         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
980         * llint/LLIntSlowPaths.h:
981         * llint/LowLevelInterpreter32_64.asm:
982         * llint/LowLevelInterpreter64.asm:
983
984 2016-06-28  Commit Queue  <commit-queue@webkit.org>
985
986         Unreviewed, rolling out r202580.
987         https://bugs.webkit.org/show_bug.cgi?id=159245
988
989         Caused all WKTR tests to fail on GuardMalloc and Production
990         only for unknown reasons, investigating offline. (Requested by
991         brrian on #webkit).
992
993         Reverted changeset:
994
995         "RunLoop::Timer should use constructor templates instead of
996         class templates"
997         https://bugs.webkit.org/show_bug.cgi?id=159153
998         http://trac.webkit.org/changeset/202580
999
1000 2016-06-28  Keith Miller  <keith_miller@apple.com>
1001
1002         We should not crash there is a finally inside a for-in loop
1003         https://bugs.webkit.org/show_bug.cgi?id=159243
1004         <rdar://problem/27018910>
1005
1006         Reviewed by Benjamin Poulain.
1007
1008         Previously we would swap the m_forInContext with an empty vector
1009         then attempt to shrink the size of m_forInContext by the amount
1010         we expected. This meant that if there was more than one ForInContext
1011         on the stack and we wanted to pop exactly one off we would crash.
1012         This patch makes ForInContexts RefCounted so they can be duplicated
1013         into other vectors. It also has ForInContexts copy the entire stack
1014         rather than do the swap that we did before. This makes ForInContexts
1015         work the same as the other contexts.
1016
1017         * bytecompiler/BytecodeGenerator.cpp:
1018         (JSC::BytecodeGenerator::emitComplexPopScopes):
1019         (JSC::BytecodeGenerator::pushIndexedForInScope):
1020         (JSC::BytecodeGenerator::pushStructureForInScope):
1021         * bytecompiler/BytecodeGenerator.h:
1022         * tests/stress/finally-for-in.js: Added.
1023         (repeat):
1024         (createSimple):
1025
1026 2016-06-28  Saam Barati  <sbarati@apple.com>
1027
1028         Assertion failure or crash when accessing let-variable in TDZ with eval with a function in it that returns let variable
1029         https://bugs.webkit.org/show_bug.cgi?id=158796
1030         <rdar://problem/26984659>
1031
1032         Reviewed by Michael Saboff.
1033
1034         There was a bug where some functions inside of an eval were
1035         omitting a necessary TDZ check. This obviously leads to bad
1036         things because a variable under TDZ is the null pointer.
1037         The eval's bytecode was generated with the correct TDZ set, but 
1038         it created all its functions before pushing that TDZ set onto
1039         the stack. That's a mistake. Those functions need to be created with
1040         that TDZ set. The solution is simple, the TDZ set that the eval
1041         is created with needs to be pushed onto the TDZ stack before
1042         the eval creates any functions.
1043
1044         * bytecompiler/BytecodeGenerator.cpp:
1045         (JSC::BytecodeGenerator::BytecodeGenerator):
1046         * tests/stress/variable-under-tdz-eval-tricky.js: Added.
1047         (assert):
1048         (throw.new.Error):
1049         (assert.try.underTDZ):
1050
1051 2016-06-28  Michael Saboff  <msaboff@apple.com>
1052
1053         REGRESSION (r200946): Improper backtracking from last alternative in sticky patterns
1054         https://bugs.webkit.org/show_bug.cgi?id=159233
1055
1056         Reviewed by Mark Lam.
1057
1058         Jump to fail exit code when the last alternative of a sticky pattern fails.
1059
1060         * yarr/YarrJIT.cpp:
1061         (JSC::Yarr::YarrGenerator::backtrack):
1062
1063 2016-06-28  Saam Barati  <sbarati@apple.com>
1064
1065         some Watchpoints' ::fireInternal method will call operations that might GC where the GC will cause the watchpoint itself to destruct
1066         https://bugs.webkit.org/show_bug.cgi?id=159198
1067         <rdar://problem/26302360>
1068
1069         Reviewed by Filip Pizlo.
1070
1071         Firing a watchpoint may cause a GC to happen. This GC could destroy various
1072         Watchpoints themselves while they're in the process of firing. It's not safe
1073         for most Watchpoints to be destructed while they're in the middle of firing.
1074         This GC could also destroy the WatchpointSet itself, and it's not in a safe
1075         state to be destroyed. WatchpointSet::fireAllWatchpoints now defers gc for a
1076         while. This prevents a GC from destructing any Watchpoints while they're
1077         in the process of firing. This bug was being hit by the stress GC bots
1078         because we would destruct a particular Watchpoint while it was firing,
1079         and then we would access its field after it had already been destroyed.
1080         This was causing all kinds of weird symptoms. Also, this was easier to
1081         catch when running with guard malloc because the first access after
1082         destruction would lead to a crash.
1083
1084         * bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp:
1085         (JSC::AdaptiveInferredPropertyValueWatchpointBase::fire):
1086         * bytecode/CodeBlock.cpp:
1087         (JSC::CodeBlock::finishCreation):
1088         * bytecode/VariableWriteFireDetail.cpp:
1089         (JSC::VariableWriteFireDetail::dump):
1090         (JSC::VariableWriteFireDetail::touch):
1091         * bytecode/VariableWriteFireDetail.h:
1092         * bytecode/Watchpoint.cpp:
1093         (JSC::WatchpointSet::add):
1094         (JSC::WatchpointSet::fireAllSlow):
1095         (JSC::WatchpointSet::fireAllWatchpoints):
1096         (JSC::InlineWatchpointSet::add):
1097         (JSC::InlineWatchpointSet::fireAll):
1098         (JSC::InlineWatchpointSet::inflateSlow):
1099         * bytecode/Watchpoint.h:
1100         (JSC::WatchpointSet::startWatching):
1101         (JSC::WatchpointSet::fireAll):
1102         (JSC::WatchpointSet::touch):
1103         (JSC::WatchpointSet::invalidate):
1104         (JSC::WatchpointSet::isBeingWatched):
1105         (JSC::WatchpointSet::offsetOfState):
1106         (JSC::WatchpointSet::addressOfSetIsNotEmpty):
1107         (JSC::InlineWatchpointSet::startWatching):
1108         (JSC::InlineWatchpointSet::fireAll):
1109         (JSC::InlineWatchpointSet::invalidate):
1110         (JSC::InlineWatchpointSet::touch):
1111         * bytecompiler/BytecodeGenerator.cpp:
1112         (JSC::BytecodeGenerator::BytecodeGenerator):
1113         * dfg/DFGOperations.cpp:
1114         * interpreter/Interpreter.cpp:
1115         (JSC::Interpreter::execute):
1116         * jit/JITOperations.cpp:
1117         * jsc.cpp:
1118         (WTF::Masquerader::create):
1119         * llint/LLIntSlowPaths.cpp:
1120         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1121         * runtime/ArrayBufferNeuteringWatchpoint.cpp:
1122         (JSC::ArrayBufferNeuteringWatchpoint::fireAll):
1123         * runtime/FunctionRareData.cpp:
1124         (JSC::FunctionRareData::clear):
1125         * runtime/InferredType.cpp:
1126         (JSC::InferredType::willStoreValueSlow):
1127         (JSC::InferredType::makeTopSlow):
1128         (JSC::InferredType::set):
1129         (JSC::InferredType::removeStructure):
1130         (JSC::InferredType::InferredStructureWatchpoint::fireInternal):
1131         * runtime/InferredValue.cpp:
1132         (JSC::InferredValue::notifyWriteSlow):
1133         (JSC::InferredValue::ValueCleanup::finalizeUnconditionally):
1134         * runtime/InferredValue.h:
1135         (JSC::InferredValue::notifyWrite):
1136         (JSC::InferredValue::invalidate):
1137         * runtime/JSGlobalObject.cpp:
1138         (JSC::JSGlobalObject::haveABadTime):
1139         * runtime/JSSymbolTableObject.h:
1140         (JSC::symbolTablePutTouchWatchpointSet):
1141         (JSC::symbolTablePutInvalidateWatchpointSet):
1142         * runtime/Structure.cpp:
1143         (JSC::Structure::didCachePropertyReplacement):
1144         (JSC::Structure::startWatchingInternalProperties):
1145         (JSC::DeferredStructureTransitionWatchpointFire::~DeferredStructureTransitionWatchpointFire):
1146         (JSC::DeferredStructureTransitionWatchpointFire::add):
1147         (JSC::Structure::didTransitionFromThisStructure):
1148         (JSC::Structure::prototypeForLookup):
1149         * runtime/StructureInlines.h:
1150         (JSC::Structure::didReplaceProperty):
1151         (JSC::Structure::propertyReplacementWatchpointSet):
1152         * runtime/SymbolTable.h:
1153         (JSC::SymbolTableEntry::isDontEnum):
1154         (JSC::SymbolTableEntry::disableWatching):
1155         * runtime/VM.cpp:
1156         (JSC::VM::addImpureProperty):
1157         (JSC::enableProfilerWithRespectToCount):
1158
1159 2016-06-28  Filip Pizlo  <fpizlo@apple.com>
1160
1161         JSRopeString should use release asserts, not debug asserts, about substring bounds
1162         https://bugs.webkit.org/show_bug.cgi?id=159227
1163
1164         Reviewed by Saam Barati.
1165         
1166         According to my experiments this change costs nothing.  That's not surprising since the
1167         most common way to construct a rope these days is inlined into the JIT, which does its own
1168         safety checks.  This makes us crash sooner rather than corrupting memory.
1169
1170         * runtime/JSString.h:
1171
1172 2016-06-28  Brian Burg  <bburg@apple.com>
1173
1174         RunLoop::Timer should use constructor templates instead of class templates
1175         https://bugs.webkit.org/show_bug.cgi?id=159153
1176
1177         Reviewed by Alex Christensen.
1178
1179         Remove the RunLoop::Timer class template argument, and pass its constructor
1180         a reference to `this` instead of a pointer to `this`.
1181
1182         * inspector/agents/InspectorHeapAgent.cpp:
1183         (Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask):
1184
1185 2016-06-28  Joseph Pecoraro  <pecoraro@apple.com>
1186
1187         Web Inspector: selectElement.options shows unexpected entries in console (named indexes beyond collection length)
1188         https://bugs.webkit.org/show_bug.cgi?id=159192
1189
1190         Reviewed by Timothy Hatcher.
1191
1192         * inspector/InjectedScriptSource.js:
1193         (InjectedScript.prototype.arrayIndexPropertyNames):
1194         Start with an empty array because we just push valid indexes.
1195
1196         (InjectedScript.prototype._propertyDescriptors):
1197         Avoid the >100 length requirement, and always treat the
1198         array-like objects the same. The frontend currently
1199         doesn't show named indexes for arrays anyways, so they
1200         would have been unused.
1201
1202 2016-06-28  Per Arne Vollan  <pvollan@apple.com>
1203
1204         [Win] Skip failing INTL test.
1205         https://bugs.webkit.org/show_bug.cgi?id=159141
1206
1207         Reviewed by Brent Fulgham.
1208
1209         INTL is not enabled on Windows.
1210
1211         * tests/stress/intl-constructors-with-proxy.js:
1212         (shouldBe):
1213
1214 2016-06-28  Joonghun Park  <jh718.park@samsung.com>
1215
1216         [JSC] Fix build break since r202502 - 2
1217         https://bugs.webkit.org/show_bug.cgi?id=159194
1218
1219         Reviewed by Gyuyoung Kim.
1220
1221         Fix about the error message below.
1222         error: control reaches end of non-void function [-Werror=return-type]
1223
1224         * b3/B3TypeMap.h: add #pragma GCC diagnostic ignored "-Wreturn-type".
1225
1226 2016-06-28  Joonghun Park  <jh718.park@samsung.com>
1227
1228         [JSC] Fix build break since r202502
1229         https://bugs.webkit.org/show_bug.cgi?id=159194
1230
1231         Reviewed by Alex Christensen.
1232
1233         Fix about the error message below.
1234         error: control reaches end of non-void function [-Werror=return-type]
1235
1236         * b3/B3TypeMap.h:
1237         (JSC::B3::TypeMap::at): add missing ASSERT_NOT_REACHED().
1238
1239 2016-06-27  Keith Miller  <keith_miller@apple.com>
1240
1241         Fix bad assert in StructureRareData::setObjectToStringValue
1242         https://bugs.webkit.org/show_bug.cgi?id=159171
1243         <rdar://problem/26987355>
1244
1245         Reviewed by Mark Lam.
1246
1247         We should not have expected the generateConditionsForPrototypePropertyHit would succeed.
1248         There are many reasons it might fail including that there is a proxy somewhere on the
1249         prototype chain of the object.
1250
1251         * runtime/StructureRareData.cpp:
1252         (JSC::StructureRareData::setObjectToStringValue):
1253         * tests/stress/object-toString-with-proxy.js: Added.
1254         (get target):
1255
1256 2016-06-27  Filip Pizlo  <fpizlo@apple.com>
1257
1258         Crashing at an unreachable code trap in FTL should give more information
1259         https://bugs.webkit.org/show_bug.cgi?id=159177
1260
1261         Reviewed by Saam Barati.
1262         
1263         This stuffs information into registers so that we have some chance of seeing what happened
1264         by looking at the register dumps.
1265
1266         * assembler/AbortReason.h:
1267         * ftl/FTLLowerDFGToB3.cpp:
1268         (JSC::FTL::DFG::ftlUnreachable):
1269         (JSC::FTL::DFG::LowerDFGToB3::compileBlock):
1270         (JSC::FTL::DFG::LowerDFGToB3::crash):
1271
1272 2016-06-27  Filip Pizlo  <fpizlo@apple.com>
1273
1274         Clean up resetting reachability in B3/Air
1275         https://bugs.webkit.org/show_bug.cgi?id=159170
1276
1277         Reviewed by Geoffrey Garen.
1278         
1279         When I fixed bug 159165, I took the brute force approach. I still used the
1280         B3::resetReachability() method, and changed the callback to record the set of deleted values
1281         instead of deleting them eagerly. But this means tracking the set of deleted values, even
1282         though resetReachability() already internally tracks the set of deleted blocks. You can find
1283         out if a value is deleted by asking if its owning block was deleted.
1284         
1285         So, this change refactors B3::resetReachability() into a new helper called
1286         B3::recomputePredecessors(). This new helper skips the block deletion step, and lets the
1287         client delete blocks. This lets Air delete blocks the same way that it did before, and it
1288         lets B3 use the isBlockDead() method (which is a glorified proxy for
1289         block->predecessors().isEmpty()) to track which values are deleted. This allows B3 to turn
1290         Upsilons that point to dead Phis into Nops before deleting the blocks.
1291         
1292         This shouldn't affect performance or anything real. It just makes the code cleaner.
1293
1294         * b3/B3BasicBlockUtils.h:
1295         (JSC::B3::updatePredecessorsAfter):
1296         (JSC::B3::recomputePredecessors):
1297         (JSC::B3::isBlockDead):
1298         (JSC::B3::resetReachability): Deleted.
1299         * b3/B3Procedure.cpp:
1300         (JSC::B3::Procedure::resetReachability):
1301         (JSC::B3::Procedure::invalidateCFG):
1302         * b3/air/AirCode.cpp:
1303         (JSC::B3::Air::Code::resetReachability):
1304         (JSC::B3::Air::Code::dump):
1305
1306 2016-06-27  Brian Burg  <bburg@apple.com>
1307
1308         Web Inspector: CRASH in backend at Inspector::HeapFrontendDispatcher::garbageCollected + 552 when closing frontend/inspected page
1309         https://bugs.webkit.org/show_bug.cgi?id=159075
1310         <rdar://problem/26094341>
1311
1312         Reviewed by Filip Pizlo.
1313
1314         This change caused JSC stress tests to all hit an assertion in RunLoop.
1315         We should use RunLoop::current() to create the RunLoop::Timer since JSC-only
1316         clients like testapi and jsc don't ever call initializeMainRunLoop().
1317
1318         * inspector/agents/InspectorHeapAgent.cpp:
1319         (Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask):
1320
1321 2016-06-27  Filip Pizlo  <fpizlo@apple.com>
1322
1323         B3::Procedure::resetReachability() can create dangling references from Upsilons to Phis
1324         https://bugs.webkit.org/show_bug.cgi?id=159165
1325
1326         Reviewed by Mark Lam.
1327         
1328         You can delete an unreachable block that has a Phi but some prior block may still have an
1329         Upsilon pointing to that Phi. This can happen if the Upsilon precedes a Check that always
1330         exits or it can happen if we remove some successor of a block and this block had an Upsilon
1331         for one of the removed successors. These things are valid IR even if they are not canonical.
1332         Our policy for not-canonical-but-valid IR is that the compiler should still emit valid code
1333         in the end.
1334         
1335         The solution is to have Procedure::resetReachability() turn those Upsilons into Nops.
1336
1337         * b3/B3Procedure.cpp:
1338         (JSC::B3::Procedure::resetReachability): Fix the bug.
1339         * b3/B3Validate.h:
1340         * b3/testb3.cpp:
1341         (JSC::B3::testResetReachabilityDanglingReference): Add a test. This always crashes prior to this change.
1342         * dfg/DFGGraph.cpp:
1343         (JSC::DFG::Graph::killUnreachableBlocks): Add a FIXME about a possible similar bug.
1344
1345 2016-06-27  Keith Miller  <keith_miller@apple.com>
1346
1347         Add comment to Module feature in features.json
1348         https://bugs.webkit.org/show_bug.cgi?id=159159
1349
1350         Reviewed by Saam Barati.
1351
1352         * features.json:
1353
1354 2016-06-27  Keith Miller  <keith_miller@apple.com>
1355
1356         Update features.json for ES6 completed features.
1357         https://bugs.webkit.org/show_bug.cgi?id=159152
1358
1359         Reviewed by Mark Lam.
1360
1361         * features.json:
1362
1363 2016-06-25  Filip Pizlo  <fpizlo@apple.com>
1364
1365         B3 should not use Nops when deleting unreachable code
1366         https://bugs.webkit.org/show_bug.cgi?id=159120
1367         rdar://problem/26500743
1368
1369         Reviewed by Michael Saboff.
1370         
1371         Prior to this change, transformations that obviated the need for some value could choose
1372         from these ways to kill it:
1373         
1374         - replaceWithIdentity() if we're replacing with another value.
1375         - replaceWithNop() if the type is Void or if we know that we'll fix any users of this
1376           value.
1377         - deleteValue() if the code is unreachable.
1378         
1379         The bug here is that reduceStrength() was being clever about how to get rid of a value.
1380         reduceStrength() may find a Check that must always exit. The goal is to remove any code
1381         dominated by the Check. But it would be awkward to eagerly delete all of the blocks
1382         dominated by this one. So this code took a much simpler approach: it would
1383         replaceWithNop() for all of the values in this block after the Check and it would replace
1384         the terminal with Oops.
1385         
1386         But this corrupts the IR in a subtle way: some of those values may have been non-Void but
1387         now they are Nops so they are Void. reduceStrength() will not yet realize that the blocks
1388         dominated by the one with the Check are unreachable, so it will run all sorts of
1389         optimizations on those blocks. This could have probably manifested as many different kinds
1390         of badness, but the way I found out about this issue was through a crash in
1391         IntRange::top(Type) when inlined into ReduceStrength::rangeFor(). We'd die in a switch
1392         statement over a child's type.
1393         
1394         We could fix this by making rangeFor() tolerate Void. But I think that this would be
1395         dangerous. There could easily be other places in reduceStrength() that assume that value's
1396         children are non-Void. So, this change fixes the Check optimization and adds mechanisms to
1397         prevent other optimizations from breaking the children-are-not-Void rule.
1398         
1399         This introduces two high-level changes:
1400         
1401         - It's no longer legal to replaceWithNop() if the value is not Void. This change alone
1402           would cause reduceStrength() to instacrash in its Check optimization. Almost all other
1403           uses of replaceWithNop() were already following this rule, so they were fine. One other
1404           place was using replaceWithNop() on non-Void values after arranging for them to no
1405           longer have any parents. That was changed to call replaceWithNopIgnoringType(), which
1406           doesn't have any type assertions.
1407         
1408         - For reduceStrength() there is a new Value::replaceWithBottom() method that works with
1409           Void or non-Void and behaves like you would want replaceWithNop() to behave: if you know
1410           that the code is unreachable then it produces something that is guaranteed to be deleted
1411           by later optimizations, and if it's not unreachable, then it's guaranteed to be compiled
1412           to something harmless and cheap. This means replacing the value with an identity that
1413           points to a bottom constant (the 0 for whatever type we have), or just replacing it with
1414           Nop if it's Void.
1415         
1416         This also adds a test case for the reason why we do this: we may have two blocks, where
1417         the first block unconditionally exits while dominating the second block. The second block
1418         references values in the part of the first block that is unreachable. In trunk, this test
1419         would assert in ReduceStrength::rangeFor() because the CheckAdd in the second block would
1420         reference a Nop in the first block.
1421         
1422         This fixes a high volume crash in ReduceStrength::rangeFor(). This crash was very
1423         confusing. Even though we were crashing at a RELEASE_ASSERT_NOT_REACHED() in a switch
1424         statement in IntRange::top(Type), clang was merging that trap with the trap it used for
1425         Vector OOB. The top of the stack in crash dumps looked like:
1426         
1427             JSC::B3::(anonymous namespace)::ReduceStrength::rangeFor(JSC::B3::Value*, unsigned int) + 4477 (Vector.h:655)
1428         
1429         Where Vector.h:655 is:
1430         
1431             OverflowHandler::overflowed();
1432
1433         But this crash was not at Vector.h:655. It was at B3ReduceStrength.cpp:121. The two lines
1434         are both traps, so they got merged despite differences in debug info. This bug would have
1435         been so much easier to fix if I had the right line number.
1436
1437         * b3/B3BottomProvider.h: Added. This is a utility for creating bottom values.
1438         (JSC::B3::BottomProvider::BottomProvider):
1439         (JSC::B3::BottomProvider::operator()):
1440         * b3/B3InsertionSet.cpp: Optimized adding bottom values a bit. We will no longer create pointless duplicates.
1441         (JSC::B3::InsertionSet::insertBottom):
1442         (JSC::B3::InsertionSet::execute):
1443         (JSC::B3::InsertionSet::bottomForType):
1444         * b3/B3InsertionSet.h:
1445         * b3/B3MoveConstants.cpp: Use replaceWithNopIgnoringType() because we *know* that we can replaceWithNop even for non-Void.
1446         * b3/B3Procedure.h:
1447         * b3/B3ReduceStrength.cpp: Use replaceWithBottom().
1448         * b3/B3ReduceStrength.h:
1449         * b3/B3TypeMap.h: I figured if I wrote type-casing code like this once then I'd never want to write it again.
1450         * b3/B3Value.cpp:
1451         (JSC::B3::Value::replaceWithIdentity):
1452         (JSC::B3::Value::replaceWithNop):
1453         (JSC::B3::Value::replaceWithNopIgnoringType):
1454         * b3/B3Value.h:
1455         * b3/B3ValueInlines.h:
1456         (JSC::B3::Value::replaceWithBottom): This is the new method of killing unreachable code.
1457         (JSC::B3::Value::as):
1458         * b3/testb3.cpp: Add new tests!
1459         (JSC::B3::testLateRegister):
1460         (JSC::B3::testReduceStrengthCheckBottomUseInAnotherBlock):
1461         (JSC::B3::zero):
1462         (JSC::B3::run):
1463
1464 2016-06-27  Joseph Pecoraro  <pecoraro@apple.com>
1465
1466         REGRESSION: Web Inspector: Text search broken in resources with <CR>
1467         https://bugs.webkit.org/show_bug.cgi?id=159110
1468         <rdar://problem/27008485>
1469
1470         Reviewed by Brian Burg.
1471
1472         * inspector/ContentSearchUtilities.cpp:
1473         (Inspector::ContentSearchUtilities::lineEndings):
1474         The frontend moved to only treated newlines as line endings in
1475         the TextEditor. The backend however was looking for many
1476         different types of line endings (\r\n, \r, \n). This caused
1477         the line endings to ultimately differ between the frontend
1478         and the backend, so the frontend couldn't find the lines that
1479         the backend was claiming search results were on. Change the
1480         backend to only look for \n line endings.
1481
1482 2016-06-27  Brian Burg  <bburg@apple.com>
1483
1484         Web Inspector: CRASH in backend at Inspector::HeapFrontendDispatcher::garbageCollected + 552 when closing frontend/inspected page
1485         https://bugs.webkit.org/show_bug.cgi?id=159075
1486         <rdar://problem/26094341>
1487
1488         Reviewed by Timothy Hatcher.
1489
1490         Move the asynchronous work to a task class that can be cancelled when the
1491         heap agent is reset, disabled or destroyed.
1492
1493         * inspector/agents/InspectorHeapAgent.cpp:
1494         (Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask):
1495         (Inspector::SendGarbageCollectionEventsTask::addGarbageCollection):
1496         (Inspector::SendGarbageCollectionEventsTask::reset):
1497         (Inspector::SendGarbageCollectionEventsTask::timerFired):
1498         Added. This holds onto GarbageCollectionData that needs to be sent asynchronously.
1499         It uses the RunLoop variant of Timer and can queue multiple collections to be sent.
1500         The data vector is guarded with a lock so that garbageCollected() can safely add
1501         collection data from a non-main thread while the main thread sends out events.
1502
1503         (Inspector::InspectorHeapAgent::InspectorHeapAgent):
1504         (Inspector::InspectorHeapAgent::~InspectorHeapAgent):
1505         (Inspector::InspectorHeapAgent::disable):
1506         Reset the task when disabling or tearing down the agent so the timer doesn't fire after destruction.
1507
1508         (Inspector::InspectorHeapAgent::didGarbageCollect):
1509         Add the collection data to the task, which will dispatch an event for it asynchronously.
1510
1511         * inspector/agents/InspectorHeapAgent.h:
1512
1513 2016-06-27  Michael Saboff  <msaboff@apple.com>
1514
1515         ES6 Change: Unify handling of RegExp CharacterClassEscapes \w and \W and Word Asserts \b and \B
1516         https://bugs.webkit.org/show_bug.cgi?id=158505
1517
1518         Reviewed by Geoffrey Garen.
1519
1520         This change makes it so that the CharacterClassEscape \w matches the inverse of
1521         \W and vice versa for unicode, ignore case RegExp's.
1522
1523         Before this change, both /\w/ui and /\W/ui RegExp's would match the characters
1524         k, K, s, S, \u017f (Latin Small Letter Long S) and \u212a (Kelvin Sign).
1525         This was due to how the ES6 standard defined matching of character classes
1526         specifically that the abstract operation "Canonicalize()" is called for the
1527         character to be matched AND for the characters in the character class we are
1528         matching against.  This change is to make \W always be the inverse of \w.
1529         It is still the case that the characters that match against \w changes
1530         depending on a regular expression's flags.
1531
1532         The only real changes occur for regular expressions with both the unicode and
1533         ignore case flags set.  Updated the character class generator to make 
1534         nonwordUnicodeIgnoreCaseChar not include k, K, s, S, \u017f and \u212a.
1535         Changed BytecodePattern.wordcharCharacterClass to use the correct
1536         word character class for the flags.  Simplfied character class set up in
1537         in the pattern to use m_pattern.wordUnicodeIgnoreCaseCharCharacterClass and
1538         invert as appropriate when unicode and ignore case are both set.
1539
1540         * create_regex_tables:
1541         * yarr/YarrInterpreter.h:
1542         (JSC::Yarr::BytecodePattern::BytecodePattern):
1543         * yarr/YarrPattern.cpp:
1544         (JSC::Yarr::YarrPatternConstructor::atomBuiltInCharacterClass):
1545
1546 2016-06-25  Keith Miller  <keith_miller@apple.com>
1547
1548         DFGByteCodeParsing does not handle calling the Object constructor with no arguments correctly
1549         https://bugs.webkit.org/show_bug.cgi?id=159117
1550         <rdar://problem/26996781>
1551
1552         Reviewed by Saam Barati.
1553
1554         DFGByteCodeParsing always assumed there would be an argument to the Object constructor.
1555         This is clearly not always the case and we should be able to handle it.
1556
1557         * dfg/DFGByteCodeParser.cpp:
1558         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
1559         * tests/stress/indirect-call-object-constructor-with-no-arguments.js: Added.
1560         (let.foo.Object.test):
1561
1562 2016-06-24  Filip Pizlo  <fpizlo@apple.com>
1563
1564         B3 should die sooner if a Value has the wrong number of children
1565         https://bugs.webkit.org/show_bug.cgi?id=159108
1566
1567         Reviewed by Mark Lam.
1568         
1569         I've been looking at a bug (rdar://problem/26500743) that's about a Vector OOB crash in
1570         ReduceStrength::rangeFor(). The only Vector accesses are to Value::m_children, and all of
1571         the accesses in rangeFor() are for child(0) or child(1) of binary arithmetic opcodes.
1572         Clearly those should never go out-of-bounds.
1573         
1574         Maybe we have horrible memory corruption. Or maybe some path creates a Value with the
1575         wrong number of children, and that path is not tested by any of our tests. This patch adds
1576         release assertions that will catch the latter.
1577         
1578         I've tested this a lot. It's not a regression on our benchmarks.
1579
1580         * b3/B3Opcode.h:
1581         * b3/B3Value.cpp:
1582         (JSC::B3::Value::dumpMeta):
1583         (JSC::B3::Value::typeFor):
1584         (JSC::B3::Value::badOpcode):
1585         (JSC::B3::Value::checkOpcode): Deleted.
1586         * b3/B3Value.h:
1587
1588 2016-06-24  Mark Lam  <mark.lam@apple.com>
1589
1590         [JSC] Error prototypes are called on remote scripts.
1591         https://bugs.webkit.org/show_bug.cgi?id=52192
1592
1593         Reviewed by Keith Miller.
1594
1595         Added a sanitizedToString() to the Error instance object so that it can be used
1596         to get an error string without invoking getters and proxies.
1597
1598         * runtime/ErrorInstance.cpp:
1599         (JSC::ErrorInstance::finishCreation):
1600         (JSC::ErrorInstance::sanitizedToString):
1601         * runtime/ErrorInstance.h:
1602         (JSC::ErrorInstance::createStructure):
1603         (JSC::ErrorInstance::runtimeTypeForCause):
1604         (JSC::ErrorInstance::clearRuntimeTypeForCause):
1605
1606 2016-06-24  Commit Queue  <commit-queue@webkit.org>
1607
1608         Unreviewed, rolling out r202443.
1609         https://bugs.webkit.org/show_bug.cgi?id=159105
1610
1611         Introduced memory corruption crashes (Requested by ap on
1612         #webkit).
1613
1614         Reverted changeset:
1615
1616         "Web Inspector: CRASH in backend at
1617         Inspector::HeapFrontendDispatcher::garbageCollected + 552 when
1618         closing frontend/inspected page"
1619         https://bugs.webkit.org/show_bug.cgi?id=159075
1620         http://trac.webkit.org/changeset/202443
1621
1622 2016-06-24  Brian Burg  <bburg@apple.com>
1623
1624         Web Inspector: CRASH in backend at Inspector::HeapFrontendDispatcher::garbageCollected + 552 when closing frontend/inspected page
1625         https://bugs.webkit.org/show_bug.cgi?id=159075
1626         <rdar://problem/26094341>
1627
1628         Reviewed by Joseph Pecoraro.
1629
1630         Move the asynchronous work to a task class that can be cancelled when the
1631         heap agent is reset, disabled or destroyed.
1632
1633         * inspector/agents/InspectorHeapAgent.cpp:
1634         (Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask):
1635         (Inspector::SendGarbageCollectionEventsTask::addGarbageCollection):
1636         (Inspector::SendGarbageCollectionEventsTask::reset):
1637         (Inspector::SendGarbageCollectionEventsTask::timerFired):
1638         Added. This holds onto GarbageCollection objects that need to be sent asynchronously.
1639         It uses the RunLoop variant of Timer and can queue multiple pending objects to be sent.
1640
1641         (Inspector::InspectorHeapAgent::InspectorHeapAgent):
1642         (Inspector::InspectorHeapAgent::~InspectorHeapAgent):
1643         (Inspector::InspectorHeapAgent::disable):
1644         Reset the task when disabling or tearing down the agent so the timer doesn't fire after destruction.
1645
1646         (Inspector::InspectorHeapAgent::didGarbageCollect):
1647         Send the object to the task to be dispatched asynchronously.
1648
1649         * inspector/agents/InspectorHeapAgent.h:
1650
1651 2016-06-24  Commit Queue  <commit-queue@webkit.org>
1652
1653         Unreviewed, rolling out r202413.
1654         https://bugs.webkit.org/show_bug.cgi?id=159097
1655
1656         Broke many JSC tests (Requested by ap on #webkit).
1657
1658         Reverted changeset:
1659
1660         "[JSC] Implement isFinite / isNaN in JS and make DFG ToNumber
1661         accept non number values"
1662         https://bugs.webkit.org/show_bug.cgi?id=154022
1663         http://trac.webkit.org/changeset/202413
1664
1665 2016-06-23  Benjamin Poulain  <bpoulain@apple.com>
1666
1667         OOM Assertion failure in Array.prototype.toString
1668         https://bugs.webkit.org/show_bug.cgi?id=158793
1669
1670         Reviewed by Saam Barati.
1671
1672         JSString::create() taking a StringImpl was using a signed integer
1673         for the length of the string.
1674         The problem is StringImpl uses an unsigned integer. When a large string
1675         was passed to JSString, the signed integer would be negative and crash
1676         JSString.
1677
1678         * runtime/JSString.h:
1679         (JSC::JSString::create):
1680
1681 2016-06-23  Joseph Pecoraro  <pecoraro@apple.com> and Yusuke Suzuki  <utatane.tea@gmail.com>
1682
1683         [JSC] Implement isFinite / isNaN in JS and make DFG ToNumber accept non number values
1684         https://bugs.webkit.org/show_bug.cgi?id=154022
1685
1686         Reviewed by Filip Pizlo.
1687
1688         We aim at optimizing @toInteger operation.
1689         While it still has an unoptimized part[1], this patch should be a first step.
1690
1691         We introduce the @toNumber builtin intrinsic operation.
1692         This converts the given value to the JS number by emitting op_to_number bytecode.
1693         Previously @toInteger called C++ @Number constructor for that purpose.
1694
1695         And in DFG, op_to_number is converted to DFG ToNumber node.
1696         During DFG, we attempt to convert this to edge filtering and Identity, but if we fail,
1697         we just fall back to calling the C++ function.
1698
1699         To utilize ToNumber in user-land side, we add a path attempting to convert Number constructor calls
1700         to ToNumber DFG nodes. This conversion is useful because `Number(value)` is used to convert a value to a number in JS.
1701
1702         Before this patch, we emit simple edge filtering (NumberUse) instead of emitting DFG node like ToNumber for op_to_number.
1703         But emitting ToNumber is useful, because in the case of `Number(value)`, considering `value` may not be a number is reasonable.
1704
1705         By leveraging @toNumber operation, we rewrite Number.{isFinite, isNaN}, global.{isFinite, isNaN} and @toInteger.
1706
1707         ToNumber DFG node has a value profiling. This profiling is leveraged to determine the result number type of the ToNumber operation.
1708         This value profiling is provided from either NumberConstructor's call operation or op_to_number.
1709
1710         The results (with the added performance tests) show that, while existing cases are performance neutral, the newly added cases gain the performance benefit.
1711         And ASMBench/n-body.c also shows stable ~2% progression.
1712
1713         [1]: https://bugs.webkit.org/show_bug.cgi?id=153738
1714
1715         * CMakeLists.txt:
1716         * DerivedSources.make:
1717         * JavaScriptCore.xcodeproj/project.pbxproj:
1718         * builtins/BuiltinNames.h:
1719         * builtins/GlobalObject.js:
1720         (globalPrivate.isFinite):
1721         (globalPrivate.isNaN):
1722         (globalPrivate.toInteger): Deleted.
1723         (globalPrivate.toLength): Deleted.
1724         (globalPrivate.isDictionary): Deleted.
1725         (globalPrivate.speciesGetter): Deleted.
1726         (globalPrivate.speciesConstructor): Deleted.
1727         * builtins/GlobalOperations.js: Copied from Source/JavaScriptCore/builtins/GlobalObject.js.
1728         (globalPrivate.toInteger):
1729         (globalPrivate.toLength):
1730         (globalPrivate.isDictionary):
1731         (globalPrivate.speciesGetter):
1732         (globalPrivate.speciesConstructor):
1733         * builtins/NumberConstructor.js: Added.
1734         (isFinite):
1735         (isNaN):
1736         * bytecode/BytecodeIntrinsicRegistry.cpp:
1737         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
1738         * bytecode/BytecodeIntrinsicRegistry.h:
1739         * bytecode/BytecodeList.json:
1740         * bytecode/CodeBlock.cpp:
1741         (JSC::CodeBlock::dumpBytecode):
1742         (JSC::CodeBlock::finishCreation):
1743         * bytecompiler/BytecodeGenerator.cpp:
1744         (JSC::BytecodeGenerator::emitUnaryOp):
1745         (JSC::BytecodeGenerator::emitUnaryOpProfiled):
1746         * bytecompiler/BytecodeGenerator.h:
1747         (JSC::BytecodeGenerator::emitToNumber):
1748         * bytecompiler/NodesCodegen.cpp:
1749         (JSC::BytecodeIntrinsicNode::emit_intrinsic_toNumber):
1750         (JSC::UnaryPlusNode::emitBytecode):
1751         * dfg/DFGAbstractInterpreterInlines.h:
1752         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1753         * dfg/DFGByteCodeParser.cpp:
1754         (JSC::DFG::ByteCodeParser::attemptToInlineCall):
1755         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
1756         (JSC::DFG::ByteCodeParser::parseBlock):
1757         We use `getPrediction()` to retrieve the heap prediction from the to_number bytecode.
1758         According to the benchmark results, choosing `getPredictionWithoutOSRExit()` causes performance regression (1.5%) in kraken stanford-crypto-aes.
1759
1760         * dfg/DFGClobberize.h:
1761         (JSC::DFG::clobberize):
1762         * dfg/DFGConstantFoldingPhase.cpp:
1763         (JSC::DFG::ConstantFoldingPhase::foldConstants):
1764         * dfg/DFGDoesGC.cpp:
1765         (JSC::DFG::doesGC):
1766         * dfg/DFGFixupPhase.cpp:
1767         (JSC::DFG::FixupPhase::fixupNode):
1768         (JSC::DFG::FixupPhase::fixupToNumber):
1769         ToNumber tells its predicted type by its heap prediction. So the fixup phase need to consider about it.
1770         If the heap prediction is Int32, we should attempt to convert the child value to Int32.
1771         Without this, misc-bugs-847389-jpeg2000 in assorted tests poses 53% regression.
1772
1773         * dfg/DFGNode.h:
1774         (JSC::DFG::Node::hasHeapPrediction):
1775         * dfg/DFGNodeType.h:
1776         * dfg/DFGOperations.cpp:
1777         * dfg/DFGOperations.h:
1778         * dfg/DFGPredictionPropagationPhase.cpp:
1779         Alway rely on the heap prediction.
1780
1781         * dfg/DFGSafeToExecute.h:
1782         (JSC::DFG::safeToExecute):
1783         * dfg/DFGSpeculativeJIT32_64.cpp:
1784         (JSC::DFG::SpeculativeJIT::compile):
1785         As of 64bit version, we carefully manage the register reuse. The largest difference between 32bit and 64bit is
1786         `branchIfNotNumber()` requires the temporary register. We should not use the result registers for that since
1787         it may be reuse the argument registers and it can break the argument registers before using them to call the operation.
1788         Currently, we allocate the additional temporary register for that scratch register.
1789
1790         * dfg/DFGSpeculativeJIT64.cpp:
1791         (JSC::DFG::SpeculativeJIT::compile):
1792         Reuse the argument register for the result if possible. And manually decrement the use count in the middle of the node.
1793         This is similar technique used in ToPrimitive. Typically, the child of ToNumber is only used by this ToNumber node since
1794         we would like to perform the type conversion onto this child node here. So this careful register reuse effectively removes
1795         the spills to call the operation. The example of the actually emitted code is the following.
1796
1797         76:<!2:loc11>     ToNumber(Untyped:@68, JS|MustGen|UseAsOther, DoubleimpurenanTopEmpty, R:World, W:Heap, Exits, ClobbersExit, bc#48)  predicting DoubleimpurenanTopEmpty
1798             0x7f986d5fe693: test %rax, %r14
1799             0x7f986d5fe696: jz 0x7f986d5fe6a1
1800             0x7f986d5fe69c: jmp 0x7f986d5fe6d1
1801             0x7f986d5fe6a1: mov %rax, %rsi
1802             0x7f986d5fe6a4: mov %rbp, %rdi
1803             0x7f986d5fe6a7: mov $0x2, 0x24(%rbp)
1804             0x7f986d5fe6ae: mov $0x7f98711ea5f0, %r11
1805             0x7f986d5fe6b8: call *%r11
1806             0x7f986d5fe6bb: mov $0x7f982d3f72d0, %r11
1807             0x7f986d5fe6c5: mov (%r11), %r11
1808             0x7f986d5fe6c8: test %r11, %r11
1809             0x7f986d5fe6cb: jnz 0x7f986d5fe88c
1810
1811         It effectively removes the unnecessary spill to call the operation!
1812
1813         * ftl/FTLCapabilities.cpp:
1814         (JSC::FTL::canCompile):
1815         * ftl/FTLLowerDFGToB3.cpp:
1816         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1817         (JSC::FTL::DFG::LowerDFGToB3::compileToNumber):
1818         (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
1819         * jit/AssemblyHelpers.h:
1820         (JSC::AssemblyHelpers::branchIfNumber):
1821         (JSC::AssemblyHelpers::branchIfNotNumber):
1822         * jit/JITOpcodes.cpp:
1823         (JSC::JIT::emit_op_to_number):
1824         * jit/JITOpcodes32_64.cpp:
1825         (JSC::JIT::emit_op_to_number):
1826         * llint/LowLevelInterpreter32_64.asm:
1827         * llint/LowLevelInterpreter64.asm:
1828         * parser/Nodes.h:
1829         (JSC::UnaryOpNode::opcodeID):
1830         * runtime/CommonSlowPaths.cpp:
1831         (JSC::SLOW_PATH_DECL):
1832         * runtime/JSGlobalObject.cpp:
1833         (JSC::JSGlobalObject::init):
1834         * runtime/JSGlobalObjectFunctions.cpp:
1835         (JSC::globalFuncIsNaN): Deleted.
1836         (JSC::globalFuncIsFinite): Deleted.
1837         * runtime/JSGlobalObjectFunctions.h:
1838         * runtime/MathCommon.h:
1839         (JSC::maxSafeInteger):
1840         (JSC::minSafeInteger):
1841         * runtime/NumberConstructor.cpp:
1842         (JSC::NumberConstructor::finishCreation):
1843         (JSC::numberConstructorFuncIsFinite): Deleted.
1844         (JSC::numberConstructorFuncIsNaN): Deleted.
1845         * runtime/NumberConstructor.h:
1846         * tests/stress/Number-isNaN-basics.js: Added.
1847         (numberIsNaNOnInteger):
1848         (testNumberIsNaNOnIntegers):
1849         (verifyNumberIsNaNOnIntegerWithOtherTypes):
1850         (numberIsNaNOnDouble):
1851         (testNumberIsNaNOnDoubles):
1852         (verifyNumberIsNaNOnDoublesWithOtherTypes):
1853         (numberIsNaNNoArguments):
1854         (numberIsNaNTooManyArguments):
1855         (testNumberIsNaNOnConstants):
1856         (numberIsNaNStructTransition):
1857         (Number.isNaN):
1858         * tests/stress/global-is-finite.js: Added.
1859         (shouldBe):
1860         * tests/stress/global-is-nan.js: Added.
1861         (shouldBe):
1862         * tests/stress/global-isNaN-basics.js: Added.
1863         (isNaNOnInteger):
1864         (testIsNaNOnIntegers):
1865         (verifyIsNaNOnIntegerWithOtherTypes):
1866         (isNaNOnDouble):
1867         (testIsNaNOnDoubles):
1868         (verifyIsNaNOnDoublesWithOtherTypes):
1869         (verifyIsNaNOnCoercedTypes):
1870         (isNaNNoArguments):
1871         (isNaNTooManyArguments):
1872         (testIsNaNOnConstants):
1873         (isNaNTypeCoercionSideEffects):
1874         (i.value.isNaNTypeCoercionSideEffects.valueOf):
1875         (isNaNStructTransition):
1876         (isNaN):
1877         * tests/stress/number-is-finite.js: Added.
1878         (shouldBe):
1879         (test2):
1880         (test3):
1881         * tests/stress/number-is-nan.js: Added.
1882         (shouldBe):
1883         (test2):
1884         (test3):
1885         * tests/stress/to-number-basics.js: Added.
1886         (shouldBe):
1887         * tests/stress/to-number-convert-identity-without-execution.js: Added.
1888         (shouldBe):
1889         (object.valueOf):
1890         (valueOf):
1891         * tests/stress/to-number-int52.js: Added.
1892         (shouldBe):
1893         (object.valueOf):
1894         * tests/stress/to-number-intrinsic-convert-to-identity-without-execution.js: Added.
1895         (shouldBe):
1896         (object.valueOf):
1897         (valueOf):
1898         * tests/stress/to-number-intrinsic-int52.js: Added.
1899         (shouldBe):
1900         (object.valueOf):
1901         * tests/stress/to-number-intrinsic-object-without-execution.js: Added.
1902         (shouldBe):
1903         (object.valueOf):
1904         * tests/stress/to-number-intrinsic-value-profiling.js: Added.
1905         (shouldBe):
1906         (object.valueOf):
1907         * tests/stress/to-number-object-without-execution.js: Added.
1908         (shouldBe):
1909         (object.valueOf):
1910         * tests/stress/to-number-object.js: Added.
1911         (shouldBe):
1912         (test12):
1913         (object1.valueOf):
1914         (test2):
1915         (test22):
1916         (object2.valueOf):
1917         (test3):
1918         (test32):
1919         (object3.valueOf):
1920         * tests/stress/to-number-value-profiling.js: Added.
1921         (shouldBe):
1922         (object.valueOf):
1923
1924 2016-06-23  Saam Barati  <sbarati@apple.com>
1925
1926         DFGSpeculativeJIT's m_slowPathLambdas should restore the current node field and DFG OSR entry functions should use DeferGCForAWhile instead of DeferGC
1927         https://bugs.webkit.org/show_bug.cgi?id=159064
1928         <rdar://problem/26599119>
1929
1930         Reviewed by Filip Pizlo.
1931
1932         The DFG has a list of m_slowPathLambdas that are code generators it emits
1933         amongst its slow paths. These lambdas, however, did not update the m_currentNode field.
1934         This caused us to use whatever Node happened to be used as the currentNode at the time
1935         we call the slowPathLambda. This means the wrong CallSiteIndex was stored into the call
1936         frame when we made a call. This may lead to a crash if the CallSiteIndex corresponds to
1937         the wrong CodeOrigin. For example, the wrong CodeOrigin could have an InlineCallFrame with
1938         a calleeRecovery that will not be in sync with the current stack state. Trying
1939         to recover that callee will often lead to a crash. The solution is to update
1940         m_currentNode to the DFG::Node* it corresponds to when emitting these slowPathLambdas.
1941
1942         I found this bug because we were inside this bad state when calling an operation
1943         that happened to have a DeferGC. When this DeferGC actually GCed, it would
1944         take a StackTrace, which would lead to a crash because we were updating
1945         ShadowChicken with vm.topCallFrame. It just so happened that the CallSiteIndex
1946         in the call frame in this program corresponded to an InlineCallFrame with a calleeRecover.
1947         However, this CallSiteIndex didn't correspond to the actual state of execution
1948         of the program. I'm adding new options to make reproducing DeferGC related
1949         bugs easier by making DeferGC force a GC according to some probability. To
1950         always have DeferGC force a GC, you can set that probability to 1.
1951
1952         There is a second bug that I discovered after solving the above bug. We were
1953         using DeferGC instead of DeferGCForAWhile in the OSR entry related functions
1954         in the DFG. This would cause us to take a stack trace when the call frame was
1955         in an inconsistent state. For example, the operation would call FTL::prepareOSREntry,
1956         which would replace the DFG CodeBlock in the call frame with the FTL CodeBlock.
1957         However, we wouldn't update the CallSiteIndex to correspond to an FTL CallSiteIndex.
1958         This would lead to a crash when taking a stack trace. The solution is to prevent
1959         stack traces from being taken when the program is in this state by using
1960         DeferGCForAWhie instead of DeferGC.
1961
1962         * dfg/DFGOperations.cpp:
1963         * dfg/DFGSpeculativeJIT.cpp:
1964         (JSC::DFG::SpeculativeJIT::addSlowPathGenerator):
1965         (JSC::DFG::SpeculativeJIT::runSlowPathGenerators):
1966         * dfg/DFGSpeculativeJIT.h:
1967         * heap/Heap.h:
1968         * heap/HeapInlines.h:
1969         (JSC::Heap::collectIfNecessaryOrDefer):
1970         (JSC::Heap::collectAccordingToDeferGCProbability):
1971         (JSC::Heap::decrementDeferralDepthAndGCIfNeeded):
1972         (JSC::Heap::markListSet):
1973         * runtime/Options.cpp:
1974         (JSC::recomputeDependentOptions):
1975         (JSC::Options::initialize):
1976         * runtime/Options.h:
1977         * tests/stress/slow-path-generator-updating-current-node-dfg.js: Added.
1978         (foo):
1979         (bar):
1980
1981 2016-06-23  Filip Pizlo  <fpizlo@apple.com>
1982
1983         Failing baseline JIT compilation of a code block and then trying to compile it from OSR from DFG/FTL will corrupt the CodeBlock
1984         https://bugs.webkit.org/show_bug.cgi?id=158806
1985
1986         Reviewed by Saam Barati.
1987         
1988         If we try to compile a CodeBlock that we already tried compiling in the past then we need
1989         to clean up the data structures that were partly filled in by the failed compile. That
1990         causes some races, since the DFG may be trying to parse those data structures while we are
1991         clearing them. This patch introduces such a clean-up (CodeBlock::resetJITData()) and fixes
1992         the races.
1993
1994         * bytecode/CodeBlock.cpp:
1995         (JSC::CodeBlock::dumpBytecode):
1996         (JSC::CodeBlock::getStubInfoMap):
1997         (JSC::CodeBlock::getCallLinkInfoMap):
1998         (JSC::CodeBlock::getByValInfoMap):
1999         (JSC::CodeBlock::getCallLinkInfoForBytecodeIndex):
2000         (JSC::CodeBlock::resetJITData):
2001         (JSC::CodeBlock::visitOSRExitTargets):
2002         (JSC::CodeBlock::setSteppingMode):
2003         (JSC::CodeBlock::addRareCaseProfile):
2004         (JSC::CodeBlock::rareCaseProfileForBytecodeOffset):
2005         (JSC::CodeBlock::rareCaseProfileCountForBytecodeOffset):
2006         (JSC::CodeBlock::resultProfileForBytecodeOffset):
2007         (JSC::CodeBlock::specialFastCaseProfileCountForBytecodeOffset):
2008         (JSC::CodeBlock::couldTakeSpecialFastCase):
2009         (JSC::CodeBlock::ensureResultProfile):
2010         * bytecode/CodeBlock.h:
2011         (JSC::CodeBlock::getFromAllValueProfiles):
2012         (JSC::CodeBlock::numberOfRareCaseProfiles):
2013         (JSC::CodeBlock::numberOfResultProfiles):
2014         (JSC::CodeBlock::numberOfArrayProfiles):
2015         (JSC::CodeBlock::arrayProfiles):
2016         (JSC::CodeBlock::addRareCaseProfile): Deleted.
2017         (JSC::CodeBlock::specialFastCaseProfileCountForBytecodeOffset): Deleted.
2018         (JSC::CodeBlock::couldTakeSpecialFastCase): Deleted.
2019         * dfg/DFGByteCodeParser.cpp:
2020         (JSC::DFG::ByteCodeParser::makeSafe):
2021         * dfg/DFGGraph.cpp:
2022         (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
2023         * jit/JIT.cpp:
2024         (JSC::JIT::link):
2025         * jit/JITWorklist.cpp:
2026         (JSC::JITWorklist::compileNow):
2027
2028 2016-06-23  Joseph Pecoraro  <pecoraro@apple.com>
2029
2030         Web Inspector: Memory Timeline sometimes shows impossible value for bmalloc size (underflowed)
2031         https://bugs.webkit.org/show_bug.cgi?id=158110
2032         <rdar://problem/26498584>
2033
2034         Reviewed by Andreas Kling.
2035
2036         * heap/Heap.cpp:
2037         (JSC::Heap::willStartCollection):
2038         (JSC::Heap::didFinishCollection):
2039         * heap/Heap.h:
2040         (JSC::Heap::externalMemorySize):
2041         * heap/HeapInlines.h:
2042         (JSC::Heap::reportExternalMemoryVisited):
2043         Keep count of external memory we visit.
2044
2045         * heap/SlotVisitor.h:
2046         * heap/SlotVisitorInlines.h:
2047         (JSC::SlotVisitor::reportExternalMemoryVisited):
2048         Report external memory visited like we do extra memory, since
2049         it will be some subset of extra memory that is external.
2050
2051 2016-06-23  Joseph Pecoraro  <pecoraro@apple.com>
2052
2053         Web Inspector: Snapshots should be cleared at some point
2054         https://bugs.webkit.org/show_bug.cgi?id=157907
2055         <rdar://problem/26373610>
2056
2057         Reviewed by Timothy Hatcher.
2058
2059         * heap/HeapSnapshotBuilder.h:
2060         * heap/HeapSnapshotBuilder.cpp:
2061         (JSC::HeapSnapshotBuilder::resetNextAvailableObjectIdentifier):
2062         Provide a way to reset the object identifier counter.
2063
2064         * inspector/agents/InspectorHeapAgent.h:
2065         * inspector/agents/InspectorHeapAgent.cpp:
2066         (Inspector::InspectorHeapAgent::clearHeapSnapshots):
2067         Make clearHeapSnapshots protected, so it can be called from a
2068         a PageHeapAgent on page navigations.
2069
2070 2016-06-22  Saam barati  <sbarati@apple.com>
2071
2072         TypeProfiler and TypeProfilerLog don't play nicely with the concurrent JIT
2073         https://bugs.webkit.org/show_bug.cgi?id=159037
2074         <rdar://problem/26935349>
2075
2076         Reviewed by Benjamin Poulain.
2077
2078         The primary focus of this patch is to make the concurrent
2079         baseline JIT work with the type profiler. We were clearing
2080         the type profiler log on the background baseline compiler
2081         thread which lead to bad things happening. This patch fixes
2082         this by processing the log before we launch the compile on
2083         a background thread.
2084
2085         Secondly, I audited the type profiler code inside the DFG,
2086         and found that we were doing some racy things. I haven't
2087         seen any crashes because of these things, but it is possible
2088         that they exist. We were grabbing a RefPtr to a TypeSet,
2089         even though TypeSet was RefCounted and not ThreadSafeRefCounted.
2090         This patch makes TypeSet ThreadSafeRefCounted. We were
2091         also copying a StructureSet while the execution thread could
2092         be augmenting the StructureSet. This patch puts changes to 
2093         TypeSet's StructureSet behind a ConcurrentJITLock.
2094
2095         I've also added two more large running tests that run with the
2096         type profiler enabled. These are here just to catch any major bugs
2097         in the type profiler implementation.
2098
2099         * jit/JIT.cpp:
2100         (JSC::JIT::compileWithoutLinking):
2101         (JSC::JIT::privateCompile):
2102         (JSC::JIT::privateCompileExceptionHandlers):
2103         (JSC::JIT::doMainThreadPreparationBeforeCompile):
2104         (JSC::JIT::frameRegisterCountFor):
2105         * jit/JIT.h:
2106         (JSC::JIT::compile):
2107         * jit/JITWorklist.cpp:
2108         (JSC::JITWorklist::Plan::Plan):
2109         (JSC::JITWorklist::Plan::compileInThread):
2110         * runtime/TypeSet.cpp:
2111         (JSC::TypeSet::addTypeInformation):
2112         (JSC::TypeSet::invalidateCache):
2113         * runtime/TypeSet.h:
2114         (JSC::TypeSet::create):
2115         (JSC::TypeSet::isEmpty):
2116         (JSC::TypeSet::seenTypes):
2117         (JSC::TypeSet::structureSet):
2118         * tests/typeProfiler/deltablue-for-of.js: Added.
2119         * tests/typeProfiler/getter-richards.js: Added.
2120
2121 2016-06-22  Keith Miller  <keith_miller@apple.com>
2122
2123         We should have a DFG intrinsic that checks if a value is a TypedArrayView
2124         https://bugs.webkit.org/show_bug.cgi?id=159048
2125
2126         Reviewed by Saam Barati.
2127
2128         This patch adds a new DFG Intrinsic that checks if a value is a TypedArrayView.
2129         The intrinsic, IsTypedArrayView, works in the same way that the other Is<insert-type>
2130         DFG nodes work. Additionally, a new builtin function isTypedArrayView has been added.
2131         These changes are needed to fix regressions in %TypedArray%.prototype.subarray.
2132
2133         * builtins/BuiltinNames.h:
2134         * dfg/DFGAbstractInterpreterInlines.h:
2135         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2136         * dfg/DFGByteCodeParser.cpp:
2137         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
2138         * dfg/DFGClobberize.h:
2139         (JSC::DFG::clobberize):
2140         * dfg/DFGDoesGC.cpp:
2141         (JSC::DFG::doesGC):
2142         * dfg/DFGFixupPhase.cpp:
2143         (JSC::DFG::FixupPhase::fixupNode):
2144         * dfg/DFGNodeType.h:
2145         * dfg/DFGPredictionPropagationPhase.cpp:
2146         * dfg/DFGSafeToExecute.h:
2147         (JSC::DFG::safeToExecute):
2148         * dfg/DFGSpeculativeJIT.cpp:
2149         (JSC::DFG::SpeculativeJIT::compileIsTypedArrayView):
2150         * dfg/DFGSpeculativeJIT.h:
2151         * dfg/DFGSpeculativeJIT32_64.cpp:
2152         (JSC::DFG::SpeculativeJIT::compile):
2153         * dfg/DFGSpeculativeJIT64.cpp:
2154         (JSC::DFG::SpeculativeJIT::compile):
2155         * ftl/FTLCapabilities.cpp:
2156         (JSC::FTL::canCompile):
2157         * ftl/FTLLowerDFGToB3.cpp:
2158         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2159         (JSC::FTL::DFG::LowerDFGToB3::compileIsTypedArrayView):
2160         (JSC::FTL::DFG::LowerDFGToB3::isTypedArrayView):
2161         * runtime/Intrinsic.h:
2162         * runtime/JSGlobalObject.cpp:
2163         (JSC::JSGlobalObject::init):
2164         * runtime/JSTypedArrayViewPrototype.cpp:
2165         (JSC::typedArrayViewPrivateFuncIsTypedArrayView):
2166         * runtime/JSTypedArrayViewPrototype.h:
2167         * tests/stress/istypedarrayview-intrinsic.js: Added.
2168         (makeFn):
2169         (typedArrays.forEach):
2170         (let.test):
2171         (test):
2172
2173 2016-06-21  Anders Carlsson  <andersca@apple.com>
2174
2175         Fix build.
2176
2177         * Configurations/FeatureDefines.xcconfig:
2178
2179 2016-06-21  Geoffrey Garen  <ggaren@apple.com>
2180
2181         Options::useImmortalObjects is not safe for conservative GC
2182         https://bugs.webkit.org/show_bug.cgi?id=158999
2183
2184         Reviewed by Geoffrey Garen.
2185
2186         useImmortalObjects set the mark bit to keep an object from being
2187         reallocated. This had the negative side-effect of convincing the
2188         conservative marker that the object was a valid and live cell, which
2189         would cause us to visit garbage.
2190
2191         * heap/Heap.cpp:
2192         (JSC::Heap::didFinishCollection):
2193         (JSC::Heap::resumeCompilerThreads):
2194         (JSC::Heap::setFullActivityCallback):
2195         (JSC::Heap::markDeadObjects): Deleted.
2196         * heap/Heap.h: Don't set the mark bit on a dead object. That's a bug in
2197         a conservative GC.
2198
2199         * heap/MarkedAllocator.cpp:
2200         (JSC::MarkedAllocator::retire): New helper.
2201
2202         (JSC::MarkedAllocator::reset): Automatically retire old blocks when
2203         we're doing the immortal objects thing. This has the effect of
2204         preserving memory for debugging because we never recycle a previously
2205         allocated block.
2206
2207 2016-06-21  Anders Carlsson  <andersca@apple.com>
2208
2209         Begin moving the Apple Pay code to the open source repository
2210         https://bugs.webkit.org/show_bug.cgi?id=158998
2211
2212         Reviewed by Tim Horton.
2213
2214         * Configurations/FeatureDefines.xcconfig:
2215         Add ENABLE_APPLE_PAY.
2216
2217 2016-06-21  Saam Barati  <sbarati@apple.com>
2218
2219         CodeBlock::shrinkToFit is racy
2220         https://bugs.webkit.org/show_bug.cgi?id=158994
2221         <rdar://problem/26920212>
2222
2223         Reviewed by Filip Pizlo.
2224
2225         To see why this is racy, consider the following scenario:
2226         - CodeBlock A is link()ing its baseline compile.
2227         - CodeBlock B is inlining A, and asks A for a result profile in DFGBytecodeParser.
2228         - The race occurs when the link() step of the baseline compile calls shrinkToFit
2229           on its m_resultProfiles field without grabbing a lock. This leads to a bad
2230           time because the DFG compile will be reading from that vector as it's getting
2231           changed by the baseline link() method.
2232
2233         This race has always existed, though the move to a concurrent baseline
2234         JIT has made it more likely to occur. The solution is to have CodeBlock::shrinkToFit
2235         grab its lock before shrinking the vector.
2236
2237         * bytecode/CodeBlock.cpp:
2238         (JSC::CodeBlock::shrinkToFit):
2239
2240 2016-06-21  David Kilzer  <ddkilzer@apple.com>
2241
2242         Migrate testair & testb3 settings from Xcode project to ToolExecutable.xcconfig
2243         <https://webkit.org/b/158989>
2244
2245         Reviewed by Andy Estes.
2246
2247         * Configurations/ToolExecutable.xcconfig:
2248         (CODE_SIGN_ENTITLEMENTS_ios_testair): Add from Xcode project.
2249         * JavaScriptCore.xcodeproj/project.pbxproj:
2250         (CODE_SIGN_ENTITLEMENTS_ios_testair): Move to
2251         ToolExecutable.xcconfig.
2252         (PRODUCT_NAME): Remove.  This variable is already set for both
2253         testair and testb3 since those build configurations use
2254         ToolExecutable.xcconfig as a base.
2255
2256 2016-06-21  Saam Barati  <sbarati@apple.com>
2257
2258         LLInt doesn't throw stack exception overflow from parent frame
2259         https://bugs.webkit.org/show_bug.cgi?id=158962
2260         <rdar://problem/26902188>
2261
2262         Reviewed by Filip Pizlo.
2263
2264         All JIT tiers will throw stack overflow exceptions from the parent frame.
2265         The LLInt, on the other hand, did not use to. I've changed the LLInt to be
2266         consistent with the JITs. The reason I found this bug is because we had a
2267         test that would give different results depending on if the function was compiled
2268         in the baseline or the LLInt. Since Filip recently landed the concurrent baseline
2269         JIT patch, this otherwise deterministic test became dependent on it being compiled
2270         in the LLInt or one of the JIT tiers. I've added a new test that is deterministic
2271         because it runs the test with --useJIT=false.
2272
2273         * llint/LLIntSlowPaths.cpp:
2274         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2275         * tests/stress/llint-stack-overflow-location.js: Added.
2276         (stackTraceDescription):
2277         (foo):
2278         (catch):
2279
2280 2016-06-21  David Kilzer  <ddkilzer@apple.com>
2281
2282         CODE_SIGN_ENTITLEMENTS should be applied to iOS Simulator builds
2283         <https://webkit.org/b/158990>
2284         <rdar://problem/26906273>
2285
2286         Reviewed by Dan Bernstein.
2287
2288         * Configurations/JSC.xcconfig:
2289         (CODE_SIGN_ENTITLEMENTS): Change [sdk=iphoneos*] to
2290         [sdk=iphone*] to apply setting to iOS Simulator as well.
2291         * Configurations/ToolExecutable.xcconfig:
2292         (CODE_SIGN_ENTITLEMENTS): Ditto.
2293
2294 2016-06-21  Keith Miller  <keith_miller@apple.com>
2295
2296         It should be easy to add a private global helper function for builtins
2297         https://bugs.webkit.org/show_bug.cgi?id=158893
2298
2299         Reviewed by Mark Lam.
2300
2301         This patch does two things. First it moves all the builtin names
2302         out of CommonIdentifiers and into BuiltinNames. This means that
2303         adding a new function to the Builtins does not require rebuilding
2304         all of JavaScriptCore. This patch also adds a new decorator to our
2305         builtins @privateGlobal that will automatically put the function
2306         on the global object. The name of the property will be the same as
2307         the private name of the function.
2308
2309         This patch, also, removes the JSArrayIterator.h/.cpp files
2310         as they no longer appear to be used in any real way. Finally,
2311         the builtins tests have been rebaselined. It appears this has
2312         not been done for a while so the expected files contain other
2313         changes.
2314
2315         * CMakeLists.txt:
2316         * JavaScriptCore.xcodeproj/project.pbxproj:
2317         * Scripts/builtins/builtins_generate_combined_header.py:
2318         (BuiltinsCombinedHeaderGenerator.generate_output):
2319         (generate_section_for_code_name_macro):
2320         (generate_section_for_global_private_code_name_macro):
2321         * Scripts/builtins/builtins_model.py:
2322         (BuiltinFunction.__init__):
2323         (BuiltinFunction.fromString):
2324         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
2325         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
2326         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
2327         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
2328         * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
2329         * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
2330         * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
2331         * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
2332         * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
2333         * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
2334         * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
2335         * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
2336         * builtins/ArrayIteratorPrototype.js:
2337         * builtins/ArrayPrototype.js:
2338         * builtins/BuiltinNames.h:
2339         * builtins/GeneratorPrototype.js:
2340         * builtins/GlobalObject.js:
2341         * builtins/PromiseOperations.js:
2342         * builtins/RegExpPrototype.js:
2343         * builtins/StringPrototype.js:
2344         * bytecode/BytecodeIntrinsicRegistry.cpp:
2345         * bytecompiler/BytecodeGenerator.cpp:
2346         (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
2347         (JSC::BytecodeGenerator::expectedFunctionForIdentifier):
2348         (JSC::BytecodeGenerator::emitGetTemplateObject):
2349         (JSC::BytecodeGenerator::emitLoadNewTargetFromArrowFunctionLexicalEnvironment):
2350         (JSC::BytecodeGenerator::emitLoadDerivedConstructorFromArrowFunctionLexicalEnvironment):
2351         (JSC::BytecodeGenerator::emitPutNewTargetToArrowFunctionContextScope):
2352         (JSC::BytecodeGenerator::emitPutDerivedConstructorToArrowFunctionContextScope):
2353         (JSC::BytecodeGenerator::emitGeneratorStateChange):
2354         * bytecompiler/NodesCodegen.cpp:
2355         (JSC::emitHomeObjectForCallee):
2356         (JSC::emitPutHomeObject):
2357         (JSC::FunctionNode::emitBytecode):
2358         * dfg/DFGOperations.cpp:
2359         * inspector/JSInjectedScriptHost.cpp:
2360         (Inspector::JSInjectedScriptHost::subtype):
2361         (Inspector::JSInjectedScriptHost::getInternalProperties): Deleted.
2362         * parser/Lexer.cpp:
2363         (JSC::Lexer<LChar>::parseIdentifier):
2364         (JSC::Lexer<UChar>::parseIdentifier):
2365         * parser/Nodes.h:
2366         * parser/Parser.cpp:
2367         (JSC::Parser<LexerType>::createGeneratorParameters):
2368         (JSC::Parser<LexerType>::parseExportDeclaration):
2369         * runtime/ArrayIteratorPrototype.cpp:
2370         * runtime/ArrayIteratorPrototype.h:
2371         * runtime/ArrayPrototype.cpp:
2372         * runtime/CommonIdentifiers.cpp:
2373         (JSC::CommonIdentifiers::CommonIdentifiers): Deleted.
2374         * runtime/CommonIdentifiers.h:
2375         * runtime/CommonSlowPaths.cpp:
2376         (JSC::SLOW_PATH_DECL):
2377         * runtime/IntlDateTimeFormat.cpp:
2378         * runtime/IntlDateTimeFormatPrototype.cpp:
2379         (JSC::IntlDateTimeFormatPrototypeGetterFormat):
2380         (JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions):
2381         * runtime/IntlNumberFormatPrototype.cpp:
2382         (JSC::IntlNumberFormatPrototypeGetterFormat):
2383         (JSC::IntlNumberFormatPrototypeFuncResolvedOptions):
2384         * runtime/IntlObjectInlines.h:
2385         (JSC::constructIntlInstanceWithWorkaroundForLegacyIntlConstructor):
2386         * runtime/JSArrayIterator.cpp: Removed.
2387         (JSC::JSArrayIterator::finishCreation): Deleted.
2388         (JSC::JSArrayIterator::kind): Deleted.
2389         (JSC::JSArrayIterator::iteratedValue): Deleted.
2390         * runtime/JSArrayIterator.h: Removed.
2391         (JSC::JSArrayIterator::createStructure): Deleted.
2392         (JSC::JSArrayIterator::create): Deleted.
2393         (JSC::JSArrayIterator::JSArrayIterator): Deleted.
2394         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
2395         (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::finishCreation):
2396         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
2397         * runtime/JSGlobalObject.cpp:
2398         (JSC::JSGlobalObject::init):
2399         * runtime/JSInternalPromise.cpp:
2400         * runtime/JSInternalPromiseDeferred.cpp:
2401         (JSC::JSInternalPromiseDeferred::create):
2402         * runtime/JSPromise.cpp:
2403         (JSC::JSPromise::finishCreation):
2404         (JSC::JSPromise::result):
2405         * runtime/JSPromiseDeferred.cpp:
2406         (JSC::JSPromiseDeferred::create):
2407         * runtime/JSStringIterator.cpp:
2408         (JSC::JSStringIterator::finishCreation):
2409         (JSC::JSStringIterator::iteratedValue):
2410         (JSC::JSStringIterator::clone):
2411         * runtime/MapPrototype.cpp:
2412         (JSC::MapPrototype::finishCreation):
2413         * runtime/ObjectConstructor.cpp:
2414         (JSC::ObjectConstructor::finishCreation):
2415         * runtime/ReflectObject.cpp:
2416         (JSC::ReflectObject::finishCreation):
2417         * runtime/StringPrototype.cpp:
2418         (JSC::StringPrototype::finishCreation):
2419         * runtime/TypedArrayInlines.h:
2420
2421 2016-06-20  Yusuke Suzuki  <utatane.tea@gmail.com>
2422
2423         [JSC] Use bytecode intrinsic to expose Module's loading status to builtin JS
2424         https://bugs.webkit.org/show_bug.cgi?id=158871
2425
2426         Reviewed by Sam Weinig.
2427
2428         Now JSC has bytecode intrinsic system. Use it instead of exposing status values through the loader's properties.
2429
2430         * builtins/ModuleLoaderObject.js:
2431         (newRegistryEntry):
2432         (fulfillFetch):
2433         (fulfillTranslate):
2434         (commitInstantiated):
2435         (requestFetch):
2436         (requestTranslate):
2437         (requestInstantiate):
2438         (requestResolveDependencies.):
2439         (requestResolveDependencies):
2440         (requestLink):
2441         (link):
2442         (provide):
2443         * bytecode/BytecodeIntrinsicRegistry.cpp:
2444         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
2445         * bytecode/BytecodeIntrinsicRegistry.h:
2446         * runtime/ModuleLoaderObject.cpp:
2447         (JSC::ModuleLoaderObject::finishCreation): Deleted.
2448
2449 2016-06-20  Commit Queue  <commit-queue@webkit.org>
2450
2451         Unreviewed, rolling out r202248.
2452         https://bugs.webkit.org/show_bug.cgi?id=158960
2453
2454         breaks builds on the simulator (Requested by keith_mi_ on
2455         #webkit).
2456
2457         Reverted changeset:
2458
2459         "It should be easy to add a private global helper function for
2460         builtins"
2461         https://bugs.webkit.org/show_bug.cgi?id=158893
2462         http://trac.webkit.org/changeset/202248
2463
2464 2016-06-20  Keith Miller  <keith_miller@apple.com>
2465
2466         It should be easy to add a private global helper function for builtins
2467         https://bugs.webkit.org/show_bug.cgi?id=158893
2468
2469         Reviewed by Mark Lam.
2470
2471         This patch does two things. First it moves all the builtin names
2472         out of CommonIdentifiers and into BuiltinNames. This means that
2473         adding a new function to the Builtins does not require rebuilding
2474         all of JavaScriptCore. This patch also adds a new decorator to our
2475         builtins @privateGlobal that will automatically put the function
2476         on the global object. The name of the property will be the same as
2477         the private name of the function.
2478
2479         This patch, also, removes the JSArrayIterator.h/.cpp files
2480         as they no longer appear to be used in any real way. Finally,
2481         the builtins tests have been rebaselined. It appears this has
2482         not been done for a while so the expected files contain other
2483         changes.
2484
2485         * CMakeLists.txt:
2486         * JavaScriptCore.xcodeproj/project.pbxproj:
2487         * Scripts/builtins/builtins_generate_combined_header.py:
2488         (BuiltinsCombinedHeaderGenerator.generate_output):
2489         (generate_section_for_code_name_macro):
2490         (generate_section_for_global_private_code_name_macro):
2491         * Scripts/builtins/builtins_model.py:
2492         (BuiltinFunction.__init__):
2493         (BuiltinFunction.fromString):
2494         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
2495         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
2496         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
2497         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
2498         * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
2499         * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
2500         * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
2501         * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
2502         * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
2503         * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
2504         * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
2505         * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
2506         * builtins/ArrayIteratorPrototype.js:
2507         * builtins/ArrayPrototype.js:
2508         * builtins/BuiltinNames.h:
2509         * builtins/GeneratorPrototype.js:
2510         * builtins/GlobalObject.js:
2511         * builtins/PromiseOperations.js:
2512         * builtins/RegExpPrototype.js:
2513         * builtins/StringPrototype.js:
2514         * bytecode/BytecodeIntrinsicRegistry.cpp:
2515         * bytecompiler/BytecodeGenerator.cpp:
2516         (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
2517         (JSC::BytecodeGenerator::expectedFunctionForIdentifier):
2518         (JSC::BytecodeGenerator::emitGetTemplateObject):
2519         (JSC::BytecodeGenerator::emitLoadNewTargetFromArrowFunctionLexicalEnvironment):
2520         (JSC::BytecodeGenerator::emitLoadDerivedConstructorFromArrowFunctionLexicalEnvironment):
2521         (JSC::BytecodeGenerator::emitPutNewTargetToArrowFunctionContextScope):
2522         (JSC::BytecodeGenerator::emitPutDerivedConstructorToArrowFunctionContextScope):
2523         (JSC::BytecodeGenerator::emitGeneratorStateChange):
2524         * bytecompiler/NodesCodegen.cpp:
2525         (JSC::emitHomeObjectForCallee):
2526         (JSC::emitPutHomeObject):
2527         (JSC::FunctionNode::emitBytecode):
2528         * dfg/DFGOperations.cpp:
2529         * inspector/JSInjectedScriptHost.cpp:
2530         (Inspector::JSInjectedScriptHost::subtype):
2531         (Inspector::JSInjectedScriptHost::getInternalProperties): Deleted.
2532         * parser/Lexer.cpp:
2533         (JSC::Lexer<LChar>::parseIdentifier):
2534         (JSC::Lexer<UChar>::parseIdentifier):
2535         * parser/Nodes.h:
2536         * parser/Parser.cpp:
2537         (JSC::Parser<LexerType>::createGeneratorParameters):
2538         (JSC::Parser<LexerType>::parseExportDeclaration):
2539         * runtime/ArrayIteratorPrototype.cpp:
2540         * runtime/ArrayIteratorPrototype.h:
2541         * runtime/ArrayPrototype.cpp:
2542         * runtime/CommonIdentifiers.cpp:
2543         (JSC::CommonIdentifiers::CommonIdentifiers): Deleted.
2544         * runtime/CommonIdentifiers.h:
2545         * runtime/CommonSlowPaths.cpp:
2546         (JSC::SLOW_PATH_DECL):
2547         * runtime/IntlDateTimeFormat.cpp:
2548         * runtime/IntlDateTimeFormatPrototype.cpp:
2549         (JSC::IntlDateTimeFormatPrototypeGetterFormat):
2550         (JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions):
2551         * runtime/IntlNumberFormatPrototype.cpp:
2552         (JSC::IntlNumberFormatPrototypeGetterFormat):
2553         (JSC::IntlNumberFormatPrototypeFuncResolvedOptions):
2554         * runtime/IntlObjectInlines.h:
2555         (JSC::constructIntlInstanceWithWorkaroundForLegacyIntlConstructor):
2556         * runtime/JSArrayIterator.cpp: Removed.
2557         (JSC::JSArrayIterator::finishCreation): Deleted.
2558         (JSC::JSArrayIterator::kind): Deleted.
2559         (JSC::JSArrayIterator::iteratedValue): Deleted.
2560         * runtime/JSArrayIterator.h: Removed.
2561         (JSC::JSArrayIterator::createStructure): Deleted.
2562         (JSC::JSArrayIterator::create): Deleted.
2563         (JSC::JSArrayIterator::JSArrayIterator): Deleted.
2564         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
2565         (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::finishCreation):
2566         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
2567         * runtime/JSGlobalObject.cpp:
2568         (JSC::JSGlobalObject::init):
2569         * runtime/JSInternalPromise.cpp:
2570         * runtime/JSInternalPromiseDeferred.cpp:
2571         (JSC::JSInternalPromiseDeferred::create):
2572         * runtime/JSPromise.cpp:
2573         (JSC::JSPromise::finishCreation):
2574         (JSC::JSPromise::result):
2575         * runtime/JSPromiseDeferred.cpp:
2576         (JSC::JSPromiseDeferred::create):
2577         * runtime/JSStringIterator.cpp:
2578         (JSC::JSStringIterator::finishCreation):
2579         (JSC::JSStringIterator::iteratedValue):
2580         (JSC::JSStringIterator::clone):
2581         * runtime/MapPrototype.cpp:
2582         (JSC::MapPrototype::finishCreation):
2583         * runtime/ObjectConstructor.cpp:
2584         (JSC::ObjectConstructor::finishCreation):
2585         * runtime/ReflectObject.cpp:
2586         (JSC::ReflectObject::finishCreation):
2587         * runtime/StringPrototype.cpp:
2588         (JSC::StringPrototype::finishCreation):
2589         * runtime/TypedArrayInlines.h:
2590
2591 2016-06-20  Filip Pizlo  <fpizlo@apple.com>
2592
2593         LLInt64 Float64 get_by_val doesn't purify NaN
2594         https://bugs.webkit.org/show_bug.cgi?id=158956
2595
2596         Reviewed by Michael Saboff.
2597
2598         * llint/LowLevelInterpreter64.asm: Fix the bug.
2599         * tests/stress/float64-array-nan-inlined.js: Make this test also run in LLInt-only mode to catch this bug.
2600
2601 2016-06-20  Keith Rollin  <krollin@apple.com>
2602
2603         Remove RefPtr::release() and change calls sites to use WTFMove()
2604         https://bugs.webkit.org/show_bug.cgi?id=158369
2605
2606         Reviewed by Chris Dumez.
2607
2608         RefPtr::release() releases its managed pointer awkwardly. It's more
2609         direct and clearer to use WTFMove to transfer ownership of the managed
2610         pointer.
2611
2612         As part of this cleanup, also change a lot of explicit data types to
2613         'auto'.
2614
2615         * API/JSObjectRef.cpp:
2616         (JSClassCreate):
2617         * API/JSScriptRef.cpp:
2618         * API/JSValueRef.cpp:
2619         (JSValueToStringCopy):
2620         * bytecompiler/StaticPropertyAnalyzer.h:
2621         (JSC::StaticPropertyAnalyzer::newObject):
2622         (JSC::StaticPropertyAnalyzer::mov):
2623         * debugger/DebuggerCallFrame.cpp:
2624         (JSC::DebuggerCallFrame::invalidate):
2625         * dfg/DFGJITCompiler.cpp:
2626         (JSC::DFG::JITCompiler::compile):
2627         (JSC::DFG::JITCompiler::compileFunction):
2628         * inspector/InspectorValues.cpp:
2629         (Inspector::InspectorValue::parseJSON):
2630         * inspector/agents/InspectorAgent.cpp:
2631         (Inspector::InspectorAgent::activateExtraDomain):
2632         (Inspector::InspectorAgent::activateExtraDomains):
2633         * inspector/agents/InspectorDebuggerAgent.cpp:
2634         (Inspector::InspectorDebuggerAgent::breakpointActionProbe):
2635         * inspector/remote/RemoteInspector.mm:
2636         (Inspector::RemoteInspector::receivedSetupMessage):
2637         * jit/Repatch.cpp:
2638         (JSC::linkPolymorphicCall):
2639         * runtime/GenericTypedArrayViewInlines.h:
2640         (JSC::GenericTypedArrayView<Adaptor>::create):
2641         (JSC::GenericTypedArrayView<Adaptor>::createUninitialized):
2642         * runtime/JSArrayBufferConstructor.cpp:
2643         (JSC::constructArrayBuffer):
2644         * runtime/PropertyNameArray.h:
2645         (JSC::PropertyNameArray::releaseData):
2646         * runtime/Structure.cpp:
2647         (JSC::Structure::toStructureShape):
2648         * runtime/TypeSet.cpp:
2649         (JSC::StructureShape::merge):
2650         * tools/FunctionOverrides.cpp:
2651         (JSC::initializeOverrideInfo):
2652
2653 2016-06-20  Joseph Pecoraro  <pecoraro@apple.com>
2654
2655         Web Inspector: console.profile should use the new Sampling Profiler
2656         https://bugs.webkit.org/show_bug.cgi?id=153499
2657         <rdar://problem/24352431>
2658
2659         Reviewed by Timothy Hatcher.
2660
2661         Currently console.profile/profileEnd behave slightly differently
2662         between JSContext and Web inspection. Unifying will be part of:
2663         <https://webkit.org/b/158753> Generalize the concept of Instruments on the backend
2664
2665         Both JSContext and Web inspection keep track of active
2666         profiles started and stopped via console.profile/profileEnd.
2667
2668         JSContext inspection sends its programmatic start/stop
2669         via the ScriptProfiler domain.
2670
2671         Web inspection sends its programmatic start/stop
2672         via the Timeline domain, and also will start/stop backend
2673         list of Instruments.
2674
2675         The functional differences between these is that for JSContext
2676         inspection, console.profile only starts/stops the ScriptProfiler
2677         domain, and does not auto-start other instruments. This isn't really
2678         a problem right now given the instruments available for JSContext
2679         inspection; but it will be nice to unify as we add more instruments.
2680         Also, JSContext inspection won't have "Profile (name)" records in
2681         its Events view, since those are currently generated only by the
2682         Web's Timeline domain.
2683
2684         * inspector/protocol/ScriptProfiler.json:
2685         * inspector/protocol/Timeline.json:
2686         Events to inform the frontend of programmatic start/stop.
2687
2688         * debugger/Debugger.h:
2689         * inspector/agents/InspectorDebuggerAgent.cpp:
2690         (Inspector::InspectorDebuggerAgent::breakpointsActive):
2691         (Inspector::InspectorDebuggerAgent::isPaused):
2692         * inspector/agents/InspectorDebuggerAgent.h:
2693         Expose breakpoints active state, since programmatic recording
2694         will temporarily disabled breakpoints if needed.
2695
2696         * inspector/JSGlobalObjectConsoleClient.cpp:
2697         (Inspector::JSGlobalObjectConsoleClient::JSGlobalObjectConsoleClient):
2698         (Inspector::JSGlobalObjectConsoleClient::profile):
2699         (Inspector::JSGlobalObjectConsoleClient::profileEnd):
2700         (Inspector::JSGlobalObjectConsoleClient::startConsoleProfile):
2701         (Inspector::JSGlobalObjectConsoleClient::stopConsoleProfile):
2702         * inspector/JSGlobalObjectConsoleClient.h:
2703         * inspector/JSGlobalObjectInspectorController.cpp:
2704         (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
2705         * inspector/agents/InspectorScriptProfilerAgent.cpp:
2706         (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStarted):
2707         (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStopped):
2708         * inspector/agents/InspectorScriptProfilerAgent.h:
2709         JSContext implementation of console.profile/profileEnd.
2710
2711 2016-06-19  Saam Barati  <sbarati@apple.com>
2712
2713         We should be able to generate more types of ICs inline
2714         https://bugs.webkit.org/show_bug.cgi?id=158719
2715         <rdar://problem/26825641>
2716
2717         Reviewed by Filip Pizlo.
2718
2719         This patch changes how we emit code for *byId ICs inline.
2720         We no longer keep data labels to patch structure checks, etc.
2721         Instead, we just regenerate the entire IC into a designated
2722         region of code that the Baseline/DFG/FTL JIT will emit inline.
2723         This makes it much simpler to patch inline ICs. All that's
2724         needed to patch an inline IC is to memcpy the code from
2725         a macro assembler inline using LinkBuffer. This architecture
2726         will be easy to extend into other forms of ICs, such as one
2727         for add, in the future.
2728
2729         To support this change, I've reworked the fields inside
2730         StructureStubInfo. It now has one field that is the CodeLocationLabel 
2731         of the start of the inline IC. Then it has a few ints that track deltas
2732         to other locations in the IC such as the slow path start, slow path call, the
2733         ICs 'done' location. We used to perform math on these ints in a bunch of different
2734         places. I've consolidated that math into methods inside StructureStubInfo.
2735
2736         To generate inline ICs, I've implemented a new class called InlineAccess.
2737         InlineAccess is stateless: it just has a bunch of static methods for
2738         generating code into the inline region specified by StructureStubInfo.
2739         Repatch will now decide when it wants to generate such an inline
2740         IC, and it will ask InlineAccess to do so.
2741
2742         I've implemented three types of inline ICs to begin with (extending
2743         this in the future should be easy):
2744         - Self property loads (both inline and out of line offsets).
2745         - Self property replace (both inline and out of line offsets).
2746         - Array length on specific array types.
2747         (An easy extension would be to implement JSString length.)
2748
2749         To know how much inline space to reserve, I've implemented a
2750         method that stubs out the various inline cache shapes and 
2751         dumps their size. This is used to determine how much space
2752         to save inline. When InlineAccess ends up generating more
2753         code than can fit inline, we will fall back to generating
2754         code with PolymorphicAccess instead.
2755
2756         To make generating code into already allocated executable memory
2757         efficient, I've made AssemblerData have 128 bytes of inline storage.
2758         This saves us a malloc when splatting code into the inline region.
2759
2760         This patch also tidies up LinkBuffer's API for generating
2761         into already allocated executable memory. Now, when generating
2762         code that has less size than the already allocated space, LinkBuffer
2763         will fill the extra space with nops. Also, if branch compaction shrinks
2764         the code, LinkBuffer will add a nop sled at the end of the shrunken
2765         code to take up the entire allocated size.
2766
2767         This looks like it could be a 1% octane progression.
2768
2769         * CMakeLists.txt:
2770         * JavaScriptCore.xcodeproj/project.pbxproj:
2771         * assembler/ARM64Assembler.h:
2772         (JSC::ARM64Assembler::nop):
2773         (JSC::ARM64Assembler::fillNops):
2774         * assembler/ARMv7Assembler.h:
2775         (JSC::ARMv7Assembler::nopw):
2776         (JSC::ARMv7Assembler::nopPseudo16):
2777         (JSC::ARMv7Assembler::nopPseudo32):
2778         (JSC::ARMv7Assembler::fillNops):
2779         (JSC::ARMv7Assembler::dmbSY):
2780         * assembler/AbstractMacroAssembler.h:
2781         (JSC::AbstractMacroAssembler::addLinkTask):
2782         (JSC::AbstractMacroAssembler::emitNops):
2783         (JSC::AbstractMacroAssembler::AbstractMacroAssembler):
2784         * assembler/AssemblerBuffer.h:
2785         (JSC::AssemblerData::AssemblerData):
2786         (JSC::AssemblerData::operator=):
2787         (JSC::AssemblerData::~AssemblerData):
2788         (JSC::AssemblerData::buffer):
2789         (JSC::AssemblerData::grow):
2790         (JSC::AssemblerData::isInlineBuffer):
2791         (JSC::AssemblerBuffer::AssemblerBuffer):
2792         (JSC::AssemblerBuffer::ensureSpace):
2793         (JSC::AssemblerBuffer::codeSize):
2794         (JSC::AssemblerBuffer::setCodeSize):
2795         (JSC::AssemblerBuffer::label):
2796         (JSC::AssemblerBuffer::debugOffset):
2797         (JSC::AssemblerBuffer::releaseAssemblerData):
2798         * assembler/LinkBuffer.cpp:
2799         (JSC::LinkBuffer::copyCompactAndLinkCode):
2800         (JSC::LinkBuffer::linkCode):
2801         (JSC::LinkBuffer::allocate):
2802         (JSC::LinkBuffer::performFinalization):
2803         (JSC::LinkBuffer::shrink): Deleted.
2804         * assembler/LinkBuffer.h:
2805         (JSC::LinkBuffer::LinkBuffer):
2806         (JSC::LinkBuffer::debugAddress):
2807         (JSC::LinkBuffer::size):
2808         (JSC::LinkBuffer::wasAlreadyDisassembled):
2809         (JSC::LinkBuffer::didAlreadyDisassemble):
2810         (JSC::LinkBuffer::applyOffset):
2811         (JSC::LinkBuffer::code):
2812         * assembler/MacroAssemblerARM64.h:
2813         (JSC::MacroAssemblerARM64::patchableBranch32):
2814         (JSC::MacroAssemblerARM64::patchableBranch64):
2815         * assembler/MacroAssemblerARMv7.h:
2816         (JSC::MacroAssemblerARMv7::patchableBranch32):
2817         (JSC::MacroAssemblerARMv7::patchableBranchPtrWithPatch):
2818         * assembler/X86Assembler.h:
2819         (JSC::X86Assembler::nop):
2820         (JSC::X86Assembler::fillNops):
2821         * bytecode/CodeBlock.cpp:
2822         (JSC::CodeBlock::printGetByIdCacheStatus):
2823         * bytecode/InlineAccess.cpp: Added.
2824         (JSC::InlineAccess::dumpCacheSizesAndCrash):
2825         (JSC::linkCodeInline):
2826         (JSC::InlineAccess::generateSelfPropertyAccess):
2827         (JSC::getScratchRegister):
2828         (JSC::hasFreeRegister):
2829         (JSC::InlineAccess::canGenerateSelfPropertyReplace):
2830         (JSC::InlineAccess::generateSelfPropertyReplace):
2831         (JSC::InlineAccess::isCacheableArrayLength):
2832         (JSC::InlineAccess::generateArrayLength):
2833         (JSC::InlineAccess::rewireStubAsJump):
2834         * bytecode/InlineAccess.h: Added.
2835         (JSC::InlineAccess::sizeForPropertyAccess):
2836         (JSC::InlineAccess::sizeForPropertyReplace):
2837         (JSC::InlineAccess::sizeForLengthAccess):
2838         * bytecode/PolymorphicAccess.cpp:
2839         (JSC::PolymorphicAccess::regenerate):
2840         * bytecode/StructureStubInfo.cpp:
2841         (JSC::StructureStubInfo::initGetByIdSelf):
2842         (JSC::StructureStubInfo::initArrayLength):
2843         (JSC::StructureStubInfo::initPutByIdReplace):
2844         (JSC::StructureStubInfo::deref):
2845         (JSC::StructureStubInfo::aboutToDie):
2846         (JSC::StructureStubInfo::propagateTransitions):
2847         (JSC::StructureStubInfo::containsPC):
2848         * bytecode/StructureStubInfo.h:
2849         (JSC::StructureStubInfo::considerCaching):
2850         (JSC::StructureStubInfo::slowPathCallLocation):
2851         (JSC::StructureStubInfo::doneLocation):
2852         (JSC::StructureStubInfo::slowPathStartLocation):
2853         (JSC::StructureStubInfo::patchableJumpForIn):
2854         (JSC::StructureStubInfo::valueRegs):
2855         * dfg/DFGJITCompiler.cpp:
2856         (JSC::DFG::JITCompiler::link):
2857         * dfg/DFGOSRExitCompilerCommon.cpp:
2858         (JSC::DFG::reifyInlinedCallFrames):
2859         * dfg/DFGSpeculativeJIT32_64.cpp:
2860         (JSC::DFG::SpeculativeJIT::cachedGetById):
2861         * dfg/DFGSpeculativeJIT64.cpp:
2862         (JSC::DFG::SpeculativeJIT::cachedGetById):
2863         * ftl/FTLLowerDFGToB3.cpp:
2864         (JSC::FTL::DFG::LowerDFGToB3::compileIn):
2865         (JSC::FTL::DFG::LowerDFGToB3::getById):
2866         * jit/JITInlineCacheGenerator.cpp:
2867         (JSC::JITByIdGenerator::finalize):
2868         (JSC::JITByIdGenerator::generateFastCommon):
2869         (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
2870         (JSC::JITGetByIdGenerator::generateFastPath):
2871         (JSC::JITPutByIdGenerator::JITPutByIdGenerator):
2872         (JSC::JITPutByIdGenerator::generateFastPath):
2873         (JSC::JITPutByIdGenerator::slowPathFunction):
2874         (JSC::JITByIdGenerator::generateFastPathChecks): Deleted.
2875         * jit/JITInlineCacheGenerator.h:
2876         (JSC::JITByIdGenerator::reportSlowPathCall):
2877         (JSC::JITByIdGenerator::slowPathBegin):
2878         (JSC::JITByIdGenerator::slowPathJump):
2879         (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
2880         * jit/JITPropertyAccess.cpp:
2881         (JSC::JIT::emitGetByValWithCachedId):
2882         (JSC::JIT::emit_op_try_get_by_id):
2883         (JSC::JIT::emit_op_get_by_id):
2884         * jit/JITPropertyAccess32_64.cpp:
2885         (JSC::JIT::emitGetByValWithCachedId):
2886         (JSC::JIT::emit_op_try_get_by_id):
2887         (JSC::JIT::emit_op_get_by_id):
2888         * jit/Repatch.cpp:
2889         (JSC::repatchCall):
2890         (JSC::tryCacheGetByID):
2891         (JSC::repatchGetByID):
2892         (JSC::appropriateGenericPutByIdFunction):
2893         (JSC::tryCachePutByID):
2894         (JSC::repatchPutByID):
2895         (JSC::tryRepatchIn):
2896         (JSC::repatchIn):
2897         (JSC::linkSlowFor):
2898         (JSC::resetGetByID):
2899         (JSC::resetPutByID):
2900         (JSC::resetIn):
2901         (JSC::repatchByIdSelfAccess): Deleted.
2902         (JSC::resetGetByIDCheckAndLoad): Deleted.
2903         (JSC::resetPutByIDCheckAndLoad): Deleted.
2904         (JSC::replaceWithJump): Deleted.
2905
2906 2016-06-19  Filip Pizlo  <fpizlo@apple.com>
2907
2908         REGRESSION(concurrent baseline JIT): Kraken/ai-astar runs 20% slower
2909         https://bugs.webkit.org/show_bug.cgi?id=158906
2910
2911         Reviewed by Benjamin Poulain.
2912         
2913         The concurrent baseline JIT was a 2-3% progression on JSBench, possibly a 1% progression
2914         on PLT3, but a 2-5% regression on Kraken. This patch fixes the Kraken regression without
2915         affecting the other tests.
2916         
2917         The problem is that Kraken/ai-astar's initialization code had a ginormous piece of init
2918         code that took about 16ms to compile in baseline. There's no good way to avoid letting it
2919         tier-up into baseline since it has a compute loop. The time it takes to run this code is
2920         never measured. The concurrent baseline JIT caused us to schedule the compilation of this
2921         huge code rather than doing it eagerly. This meant that after initialization was done and
2922         we started actually running real stuff, all of the real stuff's compiles would be convoyed
2923         behind this super-expensive baseline compile. Note that DFG and FTL compiles convoy behind
2924         baseline compiles, since you can't schedule a DFG compile for a code block until that code
2925         block is in baseline.
2926         
2927         This uses the simplest fix: if we are thinking about scheduling some compile and the
2928         thread is busy, do the compile on the main thread instead. This doesn't completely
2929         eliminate the ai-astar regression (we still have a 4% regression on that test) but it now
2930         results in concurrent baseline JIT being an overall progression on Kraken as a whole (1%
2931         on my machine). This is because concurrent baseline appears to help on other tests.
2932
2933         In the future, we could fix this even better by allowing the JITWorklist to spawn more
2934         threads or by being smarter about baseline compilation. I think it's nasty that if a giant
2935         piece of initialization code ends in a compute loop, we compile all of the code instead of
2936         just the loop. It's also gross that a constant-like object creation expression will result
2937         in so much code. It would result in less code if we allowed ourselves to do a bit more
2938         static reasoning about object literals.
2939         
2940         But for now, I think that this is a great way to recover the Kraken regression while still
2941         keeping the other progressions from concurrent baseline.
2942
2943         * jit/JITWorklist.cpp:
2944         (JSC::JITWorklist::Plan::Plan):
2945         (JSC::JITWorklist::Plan::compileInThread):
2946         (JSC::JITWorklist::Plan::finalize):
2947         (JSC::JITWorklist::Plan::codeBlock):
2948         (JSC::JITWorklist::Plan::isFinishedCompiling):
2949         (JSC::JITWorklist::Plan::compileNow):
2950         (JSC::JITWorklist::JITWorklist):
2951         (JSC::JITWorklist::compileLater):
2952         (JSC::JITWorklist::compileNow):
2953         (JSC::JITWorklist::runThread):
2954         (JSC::JITWorklist::Plan::isFinalized): Deleted.
2955         * jit/JITWorklist.h:
2956
2957 2016-06-17  Commit Queue  <commit-queue@webkit.org>
2958
2959         Unreviewed, rolling out r202152.
2960         https://bugs.webkit.org/show_bug.cgi?id=158897
2961
2962         The new test is very unstable, timing out frequently
2963         (Requested by ap on #webkit).
2964
2965         Reverted changeset:
2966
2967         "Web Inspector: console.profile should use the new Sampling
2968         Profiler"
2969         https://bugs.webkit.org/show_bug.cgi?id=153499
2970         http://trac.webkit.org/changeset/202152
2971
2972 2016-06-14  Filip Pizlo  <fpizlo@apple.com>
2973
2974         Baseline JIT should be concurrent
2975         https://bugs.webkit.org/show_bug.cgi?id=158755
2976
2977         Reviewed by Geoffrey Garen.
2978         
2979         This makes the baseline JIT concurrent. We want it to be concurrent because it takes up
2980         about 1% of PLT3 and 10% of JSBench (though the JSBench number might be down from recent
2981         optimizations).
2982         
2983         The idea is really simple: I separated the compile and link phases of JIT::privateCompile(),
2984         and arranged to call the compile phase from another thread. This doesn't reuse the old
2985         DFG::Worklist code, because that code does things we don't need (like compilation plan
2986         cancellation to allow GC to interleave with compilations) and is structured in a way that
2987         would have required more changes to the baseline JIT. Also, I think that code uses the wrong
2988         API, and as a result, clients of that API have a bad time. For example, it's never clear who
2989         has the responsibility of setting the JIT thresholds and the DFG::Worklist goes to great
2990         lengths to try to help its client set those things correctly, but since it doesn't set them
2991         directly, the client then has to have additional complex logic to combine what it learned
2992         from the Worklist and what it knows to set the thresholds. This patch takes a simpler
2993         approach: the JITWorklist takes complete control over scheduling compilations. It's like a
2994         combination of DFG::Worklist and operationOptimize().
2995         
2996         Because the baseline JIT runs quickly, we can take some shortcuts. The JITWorklist requires
2997         that all of its plans complete before a GC begins. This ensures that we don't have to worry
2998         about interactions between the concurrent baseline JIT and the GC.
2999         
3000         I needed to do a bunch of minor changes to the JIT to handle the races that emerged. For
3001         example, I needed to do things to opcodes that read profiling both in the main path code
3002         generator and the slow path one. One trick I used was to create a copy of the instruction
3003         stream and provide that for anyone interested in the original value of the profiles. Most
3004         code still uses the CodeBlock's instruction stream because it may emit JIT code that points
3005         at the stream.
3006         
3007         This also fixes a LLInt bug in prototype caching. This bug was revealed by this change
3008         because more of our LayoutTests now run in LLInt.
3009         
3010         This looks like it might be a ~1% Octane speed-up (on command line) and a ~0.7% PLT3
3011         speed-up. This also looks like a ~2% JSBench speed-up.
3012
3013         * CMakeLists.txt:
3014         * JavaScriptCore.xcodeproj/project.pbxproj:
3015         * debugger/Debugger.cpp:
3016         (JSC::Debugger::setSteppingMode):
3017         (JSC::Debugger::toggleBreakpoint):
3018         (JSC::Debugger::clearBreakpoints):
3019         (JSC::Debugger::clearDebuggerRequests):
3020         * dfg/DFGOSRExitPreparation.cpp:
3021         (JSC::DFG::prepareCodeOriginForOSRExit):
3022         * heap/Heap.cpp:
3023         (JSC::Heap::didFinishIterating):
3024         (JSC::Heap::completeAllJITPlans):
3025         (JSC::Heap::deleteAllCodeBlocks):
3026         (JSC::Heap::collectImpl):
3027         (JSC::Heap::completeAllDFGPlans): Deleted.
3028         * heap/Heap.h:
3029         * heap/HeapInlines.h:
3030         (JSC::Heap::forEachCodeBlock):
3031         * jit/JIT.cpp:
3032         (JSC::JIT::emitNotifyWrite):
3033         (JSC::JIT::privateCompileMainPass):
3034         (JSC::JIT::privateCompileSlowCases):
3035         (JSC::JIT::compileWithoutLinking):
3036         (JSC::JIT::link):
3037         (JSC::JIT::privateCompile):
3038         (JSC::JIT::privateCompileExceptionHandlers):
3039         * jit/JIT.h:
3040         (JSC::JIT::compile):
3041         (JSC::JIT::getSlowCase):
3042         (JSC::JIT::linkSlowCase):
3043         (JSC::JIT::linkDummySlowCase):
3044         * jit/JITInlines.h:
3045         (JSC::JIT::emitTagBool):
3046         (JSC::JIT::originalInstruction):
3047         * jit/JITPropertyAccess32_64.cpp:
3048         (JSC::JIT::emitSlow_op_put_to_scope):
3049         * jit/JITPropertyAccess.cpp:
3050         (JSC::JIT::emitSlow_op_put_by_val):
3051         (JSC::JIT::emit_op_resolve_scope):
3052         (JSC::JIT::emitSlow_op_resolve_scope):
3053         (JSC::JIT::emit_op_get_from_scope):
3054         (JSC::JIT::emitSlow_op_get_from_scope):
3055         (JSC::JIT::emit_op_put_to_scope):
3056         (JSC::JIT::emitSlow_op_put_to_scope):
3057         * jit/JITWorklist.cpp: Added.
3058         (JSC::JITWorklist::Plan::Plan):
3059         (JSC::JITWorklist::Plan::compileInThread):
3060         (JSC::JITWorklist::Plan::finalize):
3061         (JSC::JITWorklist::Plan::codeBlock):
3062         (JSC::JITWorklist::Plan::vm):
3063         (JSC::JITWorklist::Plan::isFinishedCompiling):
3064         (JSC::JITWorklist::Plan::isFinalized):
3065         (JSC::JITWorklist::JITWorklist):
3066         (JSC::JITWorklist::~JITWorklist):
3067         (JSC::JITWorklist::completeAllForVM):
3068         (JSC::JITWorklist::poll):
3069         (JSC::JITWorklist::compileLater):
3070         (JSC::JITWorklist::compileNow):
3071         (JSC::JITWorklist::runThread):
3072         (JSC::JITWorklist::finalizePlans):
3073         (JSC::JITWorklist::instance):
3074         * jit/JITWorklist.h: Added.
3075         * llint/LLIntSlowPaths.cpp:
3076         (JSC::LLInt::jitCompileAndSetHeuristics):
3077         * runtime/CommonSlowPaths.cpp:
3078         (JSC::SLOW_PATH_DECL):
3079         * runtime/CommonSlowPaths.h:
3080         (JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
3081         (JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal):
3082         * runtime/VM.cpp:
3083         (JSC::VM::~VM):
3084
3085 2016-06-16  Joseph Pecoraro  <pecoraro@apple.com>
3086
3087         Web Inspector: console.profile should use the new Sampling Profiler
3088         https://bugs.webkit.org/show_bug.cgi?id=153499
3089         <rdar://problem/24352431>
3090
3091         Reviewed by Timothy Hatcher.
3092
3093         Currently console.profile/profileEnd behave slightly differently
3094         between JSContext and Web inspection. Unifying will be part of:
3095         <https://webkit.org/b/158753> Generalize the concept of Instruments on the backend
3096
3097         Both JSContext and Web inspection keep track of active
3098         profiles started and stopped via console.profile/profileEnd.
3099
3100         JSContext inspection sends its programmatic start/stop
3101         via the ScriptProfiler domain.
3102
3103         Web inspection sends its programmatic start/stop
3104         via the Timeline domain, and also will start/stop backend
3105         list of Instruments.
3106
3107         The functional differences between these is that for JSContext
3108         inspection, console.profile only starts/stops the ScriptProfiler
3109         domain, and does not auto-start other instruments. This isn't really
3110         a problem right now given the instruments available for JSContext
3111         inspection; but it will be nice to unify as we add more instruments.
3112         Also, JSContext inspection won't have "Profile (name)" records in
3113         its Events view, since those are currently generated only by the
3114         Web's Timeline domain.
3115
3116         * inspector/protocol/ScriptProfiler.json:
3117         * inspector/protocol/Timeline.json:
3118         Events to inform the frontend of programmatic start/stop.
3119
3120         * debugger/Debugger.h:
3121         * inspector/agents/InspectorDebuggerAgent.cpp:
3122         (Inspector::InspectorDebuggerAgent::breakpointsActive):
3123         (Inspector::InspectorDebuggerAgent::isPaused):
3124         * inspector/agents/InspectorDebuggerAgent.h:
3125         Expose breakpoints active state, since programmatic recording
3126         will temporarily disabled breakpoints if needed.
3127
3128         * inspector/JSGlobalObjectConsoleClient.cpp:
3129         (Inspector::JSGlobalObjectConsoleClient::JSGlobalObjectConsoleClient):
3130         (Inspector::JSGlobalObjectConsoleClient::profile):
3131         (Inspector::JSGlobalObjectConsoleClient::profileEnd):
3132         (Inspector::JSGlobalObjectConsoleClient::startConsoleProfile):
3133         (Inspector::JSGlobalObjectConsoleClient::stopConsoleProfile):
3134         * inspector/JSGlobalObjectConsoleClient.h:
3135         * inspector/JSGlobalObjectInspectorController.cpp:
3136         (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
3137         * inspector/agents/InspectorScriptProfilerAgent.cpp:
3138         (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStarted):
3139         (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStopped):
3140         * inspector/agents/InspectorScriptProfilerAgent.h:
3141         JSContext implementation of console.profile/profileEnd.
3142
3143 2016-06-16  Filip Pizlo  <fpizlo@apple.com>
3144
3145         Kraken/stanford-crypto-pbkdf2.js sometimes crashes with an OSR assertion in FTL
3146         https://bugs.webkit.org/show_bug.cgi?id=158850
3147
3148         Reviewed by Keith Miller.
3149         
3150         Bytecode liveness was incorrectly claiming that all tail-deleted locals are live! That's
3151         crazy! We never noticed this because extending OSR liveness is usually not a showstopper and
3152         until recently we didn't have a lot of tail-call test cases to play with. Well, we do now,
3153         thanks to the increasing reliance on tail calls in our builtins.
3154
3155         * dfg/DFGGraph.cpp:
3156         (JSC::DFG::Graph::localsLiveInBytecode): Fix the bug and add some optional tracing. Also restructure the code so that we don't break to return true, since that's counterintuitive.
3157         * ftl/FTLLowerDFGToB3.cpp:
3158         (JSC::FTL::DFG::LowerDFGToB3::buildExitArguments): Make this assertion print more useful information.
3159
3160 2016-06-16  Mark Lam  <mark.lam@apple.com>
3161
3162         Add collecting of LLINT slow path stats.
3163         https://bugs.webkit.org/show_bug.cgi?id=158829
3164
3165         Reviewed by Keith Miller.
3166
3167         * llint/LLIntData.cpp:
3168         (JSC::LLInt::Data::dumpStats):
3169         * llint/LLIntData.h:
3170         * llint/LLIntSlowPaths.cpp:
3171         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
3172         * llint/LLIntSlowPaths.h:
3173         * llint/LowLevelInterpreter.asm:
3174         * llint/LowLevelInterpreter32_64.asm:
3175         * llint/LowLevelInterpreter64.asm:
3176
3177 2016-06-15  Keith Miller  <keith_miller@apple.com>
3178
3179         Add support for Symbol.isConcatSpreadable (round 2)
3180         https://bugs.webkit.org/show_bug.cgi?id=158769
3181
3182         Reviewed by Mark Lam.
3183
3184         This patch adds support for Symbol.isConcatSpreadable. In order to
3185         do so, it was necessary to move the Array.prototype.concat function
3186         to JS. A number of different optimizations were needed to make
3187         such the move to a builtin performant. First, this patch adds a
3188         new Bytecode intrinsic, isJSArray, that checks if the value is a
3189         JSArray object. Specifically, isJSArray checks that the array
3190         object is a normal instance of JSArray and not a RuntimeArray or
3191         Array.prototype. isJSArray can also be converted into a constant
3192         by the DFG if we are able to prove that the incomming value is
3193         already a JSArray.
3194
3195         In order to further improve the perfomance we also now cover more
3196         indexing types in our fast path memcpy code. Before we would only
3197         memcpy Arrays if they had the same indexing type and did not have
3198         Array storage or were undecided. Now the memcpy code covers the
3199         following additional three cases:
3200
3201         1) One array is undecided and the other does not have array storage
3202
3203         2) One array is Int32 and the other is contiguous (we map this
3204         into a contiguous array).
3205
3206         3) The this value is an array and first argument is a non-array
3207         that does not have Symbol.isConcatSpreadable set.
3208
3209         This patch also adds a new fast path for concat with more than one
3210         array argument by using memcpy to append values onto the result
3211         array. This works roughly the same as the two array fast path
3212         using the same methodology to decide if we can memcpy the other
3213         butterfly into the result butterfly.
3214
3215         * JavaScriptCore.xcodeproj/project.pbxproj:
3216         * builtins/ArrayPrototype.js:
3217         (concatSlowPath):
3218         (concat):
3219         * bytecode/BytecodeIntrinsicRegistry.cpp:
3220         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
3221         * bytecode/BytecodeIntrinsicRegistry.h:
3222         * bytecode/BytecodeList.json:
3223         * bytecode/BytecodeUseDef.h:
3224         (JSC::computeUsesForBytecodeOffset):
3225         (JSC::computeDefsForBytecodeOffset):
3226         * bytecode/CodeBlock.cpp:
3227         (JSC::CodeBlock::dumpBytecode):
3228         * bytecompiler/BytecodeGenerator.h:
3229         (JSC::BytecodeGenerator::emitIsJSArray):
3230         * bytecompiler/NodesCodegen.cpp:
3231         (JSC::BytecodeIntrinsicNode::emit_intrinsic_isJSArray):
3232         * dfg/DFGAbstractInterpreterInlines.h:
3233         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3234         * dfg/DFGByteCodeParser.cpp:
3235         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
3236         (JSC::DFG::ByteCodeParser::parseBlock):
3237         * dfg/DFGCapabilities.cpp:
3238         (JSC::DFG::capabilityLevel):
3239         * dfg/DFGClobberize.h:
3240         (JSC::DFG::clobberize):
3241         * dfg/DFGDoesGC.cpp:
3242         (JSC::DFG::doesGC):
3243         * dfg/DFGFixupPhase.cpp:
3244         (JSC::DFG::FixupPhase::fixupNode):
3245         * dfg/DFGNodeType.h:
3246         * dfg/DFGOperations.cpp:
3247         * dfg/DFGOperations.h:
3248         * dfg/DFGPredictionPropagationPhase.cpp:
3249         * dfg/DFGSafeToExecute.h:
3250         (JSC::DFG::safeToExecute):
3251         * dfg/DFGSpeculativeJIT.cpp:
3252         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
3253         (JSC::DFG::SpeculativeJIT::compileIsJSArray):
3254         (JSC::DFG::SpeculativeJIT::compileCallObjectConstructor):
3255         * dfg/DFGSpeculativeJIT.h:
3256         (JSC::DFG::SpeculativeJIT::callOperation):
3257         * dfg/DFGSpeculativeJIT32_64.cpp:
3258         (JSC::DFG::SpeculativeJIT::compile):
3259         * dfg/DFGSpeculativeJIT64.cpp:
3260         (JSC::DFG::SpeculativeJIT::compile):
3261         * ftl/FTLCapabilities.cpp:
3262         (JSC::FTL::canCompile):
3263         * ftl/FTLLowerDFGToB3.cpp:
3264         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
3265         (JSC::FTL::DFG::LowerDFGToB3::compileCallObjectConstructor):
3266         (JSC::FTL::DFG::LowerDFGToB3::compileIsJSArray):
3267         (JSC::FTL::DFG::LowerDFGToB3::isArray):
3268         * jit/JIT.cpp:
3269         (JSC::JIT::privateCompileMainPass):
3270         * jit/JIT.h:
3271         * jit/JITOpcodes.cpp:
3272         (JSC::JIT::emit_op_is_jsarray):
3273         * jit/JITOpcodes32_64.cpp:
3274         (JSC::JIT::emit_op_is_jsarray):
3275         * jit/JITOperations.h:
3276         * llint/LLIntData.cpp:
3277         (JSC::LLInt::Data::performAssertions):
3278         * llint/LowLevelInterpreter.asm:
3279         * llint/LowLevelInterpreter32_64.asm:
3280         * llint/LowLevelInterpreter64.asm:
3281         * runtime/ArrayConstructor.h:
3282         (JSC::isArrayConstructor):
3283         * runtime/ArrayPrototype.cpp:
3284         (JSC::ArrayPrototype::finishCreation):
3285         (JSC::speciesWatchpointsValid):
3286         (JSC::speciesConstructArray):
3287         (JSC::moveElements):
3288         (JSC::concatAppendOne):
3289         (JSC::arrayProtoFuncConcat): Deleted.
3290         * runtime/ArrayPrototype.h:
3291         * runtime/CommonIdentifiers.h:
3292         * runtime/CommonSlowPaths.cpp:
3293         (JSC::SLOW_PATH_DECL):
3294         * runtime/IndexingType.h:
3295         (JSC::indexingTypeForValue):
3296         * runtime/JSArray.cpp:
3297         (JSC::JSArray::appendMemcpy):
3298         (JSC::JSArray::fastConcatWith): Deleted.
3299         * runtime/JSArray.h:
3300         (JSC::JSArray::createStructure):
3301         (JSC::isJSArray):
3302         (JSC::JSArray::fastConcatType): Deleted.
3303         * runtime/JSArrayInlines.h: Added.
3304         (JSC::JSArray::mergeIndexingTypeForCopying):
3305         (JSC::JSArray::canFastCopy):
3306         * runtime/JSGlobalObject.cpp:
3307         (JSC::JSGlobalObject::init):
3308         * runtime/JSObject.cpp:
3309         (JSC::JSObject::convertUndecidedForValue):
3310         * runtime/JSType.h:
3311         * runtime/ObjectConstructor.h:
3312         (JSC::constructObject):
3313         * tests/es6.yaml: