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