053da75e97b085cfae9cfe66ad9c5474aa89a796
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2016-06-29  Saam barati  <sbarati@apple.com>
2
3         JSGlobalLexicalEnvironment needs a toThis implementation
4         https://bugs.webkit.org/show_bug.cgi?id=159285
5
6         Reviewed by Mark Lam.
7
8         This was a huge oversight of my original implementation. It gave users
9         of the language direct access to the JSGlobalLexicalEnvironment object.
10
11         * runtime/JSGlobalLexicalEnvironment.cpp:
12         (JSC::JSGlobalLexicalEnvironment::isConstVariable):
13         (JSC::JSGlobalLexicalEnvironment::toThis):
14         * runtime/JSGlobalLexicalEnvironment.h:
15         (JSC::JSGlobalLexicalEnvironment::isEmpty):
16         * tests/stress/global-lexical-environment-to-this.js: Added.
17         (assert):
18         (let.f):
19         (let.fStrict):
20
21 2016-06-29  Joseph Pecoraro  <pecoraro@apple.com>
22
23         Web Inspector: Wrong function name next to scope
24         https://bugs.webkit.org/show_bug.cgi?id=158210
25         <rdar://problem/26543093>
26
27         Reviewed by Brian Burg.
28
29         * CMakeLists.txt:
30         * JavaScriptCore.xcodeproj/project.pbxproj:
31         Add DebuggerLocation. A helper for describing a unique location.
32
33         * bytecode/CodeBlock.cpp:
34         (JSC::CodeBlock::setConstantRegisters):
35         When compiled with debug info, add a SymbolTable rare data pointer
36         back to the CodeBlock. This will be used later to get JSScope debug
37         info if Web Inspector pauses.
38
39         * runtime/SymbolTable.h:
40         * runtime/SymbolTable.cpp:
41         (JSC::SymbolTable::cloneScopePart):
42         (JSC::SymbolTable::prepareForTypeProfiling):
43         (JSC::SymbolTable::uniqueIDForVariable):
44         (JSC::SymbolTable::uniqueIDForOffset):
45         (JSC::SymbolTable::globalTypeSetForOffset):
46         (JSC::SymbolTable::globalTypeSetForVariable):
47         Rename rareData and include a CodeBlock pointer.
48
49         (JSC::SymbolTable::rareDataCodeBlock):
50         (JSC::SymbolTable::setRareDataCodeBlock):
51         Setter and getter for the rare data. It should only be set once.
52
53         (JSC::SymbolTable::visitChildren):
54         Visit the rare data code block if we have one.
55
56         * debugger/DebuggerLocation.cpp: Added.
57         (JSC::DebuggerLocation::DebuggerLocation):
58         * debugger/DebuggerLocation.h: Added.
59         (JSC::DebuggerLocation::DebuggerLocation):
60         Construction from a ScriptExecutable.
61
62         * runtime/JSScope.cpp:
63         (JSC::JSScope::symbolTable):
64         * runtime/JSScope.h:
65         * debugger/DebuggerScope.h:
66         * debugger/DebuggerScope.cpp:
67         (JSC::DebuggerScope::name):
68         (JSC::DebuggerScope::location):
69         Name and location for a scope. This uses:
70         JSScope -> SymbolTable -> CodeBlock -> Executable
71
72         * inspector/protocol/Debugger.json:
73         * inspector/InjectedScriptSource.js:
74         (InjectedScript.CallFrameProxy.prototype._wrapScopeChain):
75         (InjectedScript.CallFrameProxy._createScopeJson):
76         * inspector/JSJavaScriptCallFrame.cpp:
77         (Inspector::valueForScopeType):
78         (Inspector::valueForScopeLocation):
79         (Inspector::JSJavaScriptCallFrame::scopeDescriptions):
80         (Inspector::JSJavaScriptCallFrame::scopeType): Deleted.
81         * inspector/JSJavaScriptCallFrame.h:
82         * inspector/JSJavaScriptCallFramePrototype.cpp:
83         (Inspector::JSJavaScriptCallFramePrototype::finishCreation):
84         (Inspector::jsJavaScriptCallFramePrototypeFunctionScopeDescriptions):
85         (Inspector::jsJavaScriptCallFramePrototypeFunctionScopeType): Deleted.
86         Simplify this code to build the objects we will send across the protocol
87         to descript a Scope.
88
89 2016-06-29  Saam barati  <sbarati@apple.com>
90
91         We don't emit TDZ checks for call_eval
92         https://bugs.webkit.org/show_bug.cgi?id=159277
93         <rdar://problem/27018801>
94
95         Reviewed by Benjamin Poulain.
96
97         This is a problem if you're trying to call a TDZ variable
98         that is named 'eval'.
99
100         * bytecompiler/NodesCodegen.cpp:
101         (JSC::EvalFunctionCallNode::emitBytecode):
102         * tests/stress/variable-named-eval-under-tdz.js: Added.
103         (shouldThrowTDZ):
104         (test):
105         (test.foo):
106         (throw.new.Error):
107
108 2016-06-29  Mark Lam  <mark.lam@apple.com>
109
110         Add support for collecting cumulative LLINT stats via a JSC_llintStatsFile option.
111         https://bugs.webkit.org/show_bug.cgi?id=159274
112
113         Reviewed by Keith Miller.
114
115         * jsc.cpp:
116         (main):
117         * llint/LLIntData.cpp:
118         (JSC::LLInt::initialize):
119         (JSC::LLInt::Data::finalizeStats):
120         (JSC::LLInt::compareStats):
121         (JSC::LLInt::Data::dumpStats):
122         (JSC::LLInt::Data::ensureStats):
123         (JSC::LLInt::Data::loadStats):
124         (JSC::LLInt::Data::resetStats):
125         (JSC::LLInt::Data::saveStats):
126         * llint/LLIntData.h:
127         (JSC::LLInt::Data::opcodeStats):
128         * runtime/Options.cpp:
129         (JSC::Options::isAvailable):
130         (JSC::recomputeDependentOptions):
131         (JSC::Options::initialize):
132         * runtime/Options.h:
133
134 2016-06-29  Saam barati  <sbarati@apple.com>
135
136         Destructuring variable declaration is missing a validation of the syntax of a sub production when there is a rhs
137         https://bugs.webkit.org/show_bug.cgi?id=159267
138
139         Reviewed by Mark Lam.
140
141         We were parsing something without checking if it had a syntax error.
142         This is wrong for many reasons, but it could actually cause a crash
143         in a debug build if you parsed particular programs.
144
145         * parser/Parser.cpp:
146         (JSC::Parser<LexerType>::parseVariableDeclarationList):
147
148 2016-06-29  Joseph Pecoraro  <pecoraro@apple.com>
149
150         Web Inspector: Show Shadow Root type in DOM Tree
151         https://bugs.webkit.org/show_bug.cgi?id=159236
152         <rdar://problem/27068521>
153
154         Reviewed by Timothy Hatcher.
155
156         * inspector/protocol/DOM.json:
157         Include optional shadowRootType property for DOMNodes.
158
159 2016-06-29  Commit Queue  <commit-queue@webkit.org>
160
161         Unreviewed, rolling out r202627.
162         https://bugs.webkit.org/show_bug.cgi?id=159266
163
164         patch is broken on arm (Requested by keith_miller on #webkit).
165
166         Reverted changeset:
167
168         "LLInt should support other types of prototype GetById
169         caching."
170         https://bugs.webkit.org/show_bug.cgi?id=158083
171         http://trac.webkit.org/changeset/202627
172
173 2016-06-29  Benjamin Poulain  <bpoulain@apple.com>
174
175         [JSC] Fix small issues of TypedArray prototype
176         https://bugs.webkit.org/show_bug.cgi?id=159248
177
178         Reviewed by Saam Barati.
179
180         First, TypedArray's toString and Array's toString
181         should be the same function.
182         I moved the function to GlobalObject and each array type
183         gets it as needed.
184
185         Then TypedArray length was supposed to be configurable.
186         I removed the "DontDelete" flag accordingly.
187
188         * runtime/ArrayPrototype.cpp:
189         (JSC::ArrayPrototype::finishCreation):
190         * runtime/JSGlobalObject.cpp:
191         (JSC::JSGlobalObject::init):
192         (JSC::JSGlobalObject::visitChildren):
193         * runtime/JSGlobalObject.h:
194         (JSC::JSGlobalObject::arrayProtoToStringFunction):
195         * runtime/JSTypedArrayViewPrototype.cpp:
196         (JSC::JSTypedArrayViewPrototype::finishCreation):
197
198 2016-06-29  Caio Lima  <ticaiolima@gmail.com>
199
200         LLInt should support other types of prototype GetById caching.
201         https://bugs.webkit.org/show_bug.cgi?id=158083
202
203         Recently, we started supporting prototype load caching for get_by_id
204         in the LLInt. This patch is expading the caching strategy to enable
205         cache the prototype accessor and custom acessors.
206
207         Similarly to the get_by_id_proto_load bytecode, we are adding new
208         bytecodes called get_by_id_proto_accessor that uses the calculated
209         offset of a object to call a getter function and get_by_id_proto_custom
210         that stores the pointer to the custom function and call them directly
211         from LowLevelInterpreter.
212
213         Reviewed by Keith Miller
214
215         * bytecode/BytecodeList.json:
216         * bytecode/BytecodeUseDef.h:
217         (JSC::computeUsesForBytecodeOffset):
218         (JSC::computeDefsForBytecodeOffset):
219         * bytecode/CodeBlock.cpp:
220         (JSC::CodeBlock::printGetByIdOp):
221         (JSC::CodeBlock::dumpBytecode):
222         (JSC::CodeBlock::finalizeLLIntInlineCaches):
223         * bytecode/GetByIdStatus.cpp:
224         (JSC::GetByIdStatus::computeFromLLInt):
225         * dfg/DFGByteCodeParser.cpp:
226         (JSC::DFG::ByteCodeParser::parseBlock):
227         * dfg/DFGCapabilities.cpp:
228         (JSC::DFG::capabilityLevel):
229         * jit/JIT.cpp:
230         (JSC::JIT::privateCompileMainPass):
231         (JSC::JIT::privateCompileSlowCases):
232         * llint/LLIntSlowPaths.cpp:
233         (JSC::LLInt::setupGetByIdPrototypeCache):
234         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
235         * llint/LLIntSlowPaths.h:
236         * llint/LowLevelInterpreter32_64.asm:
237         * llint/LowLevelInterpreter64.asm:
238
239 2016-06-28  Commit Queue  <commit-queue@webkit.org>
240
241         Unreviewed, rolling out r202580.
242         https://bugs.webkit.org/show_bug.cgi?id=159245
243
244         Caused all WKTR tests to fail on GuardMalloc and Production
245         only for unknown reasons, investigating offline. (Requested by
246         brrian on #webkit).
247
248         Reverted changeset:
249
250         "RunLoop::Timer should use constructor templates instead of
251         class templates"
252         https://bugs.webkit.org/show_bug.cgi?id=159153
253         http://trac.webkit.org/changeset/202580
254
255 2016-06-28  Keith Miller  <keith_miller@apple.com>
256
257         We should not crash there is a finally inside a for-in loop
258         https://bugs.webkit.org/show_bug.cgi?id=159243
259         <rdar://problem/27018910>
260
261         Reviewed by Benjamin Poulain.
262
263         Previously we would swap the m_forInContext with an empty vector
264         then attempt to shrink the size of m_forInContext by the amount
265         we expected. This meant that if there was more than one ForInContext
266         on the stack and we wanted to pop exactly one off we would crash.
267         This patch makes ForInContexts RefCounted so they can be duplicated
268         into other vectors. It also has ForInContexts copy the entire stack
269         rather than do the swap that we did before. This makes ForInContexts
270         work the same as the other contexts.
271
272         * bytecompiler/BytecodeGenerator.cpp:
273         (JSC::BytecodeGenerator::emitComplexPopScopes):
274         (JSC::BytecodeGenerator::pushIndexedForInScope):
275         (JSC::BytecodeGenerator::pushStructureForInScope):
276         * bytecompiler/BytecodeGenerator.h:
277         * tests/stress/finally-for-in.js: Added.
278         (repeat):
279         (createSimple):
280
281 2016-06-28  Saam Barati  <sbarati@apple.com>
282
283         Assertion failure or crash when accessing let-variable in TDZ with eval with a function in it that returns let variable
284         https://bugs.webkit.org/show_bug.cgi?id=158796
285         <rdar://problem/26984659>
286
287         Reviewed by Michael Saboff.
288
289         There was a bug where some functions inside of an eval were
290         omitting a necessary TDZ check. This obviously leads to bad
291         things because a variable under TDZ is the null pointer.
292         The eval's bytecode was generated with the correct TDZ set, but 
293         it created all its functions before pushing that TDZ set onto
294         the stack. That's a mistake. Those functions need to be created with
295         that TDZ set. The solution is simple, the TDZ set that the eval
296         is created with needs to be pushed onto the TDZ stack before
297         the eval creates any functions.
298
299         * bytecompiler/BytecodeGenerator.cpp:
300         (JSC::BytecodeGenerator::BytecodeGenerator):
301         * tests/stress/variable-under-tdz-eval-tricky.js: Added.
302         (assert):
303         (throw.new.Error):
304         (assert.try.underTDZ):
305
306 2016-06-28  Michael Saboff  <msaboff@apple.com>
307
308         REGRESSION (r200946): Improper backtracking from last alternative in sticky patterns
309         https://bugs.webkit.org/show_bug.cgi?id=159233
310
311         Reviewed by Mark Lam.
312
313         Jump to fail exit code when the last alternative of a sticky pattern fails.
314
315         * yarr/YarrJIT.cpp:
316         (JSC::Yarr::YarrGenerator::backtrack):
317
318 2016-06-28  Saam Barati  <sbarati@apple.com>
319
320         some Watchpoints' ::fireInternal method will call operations that might GC where the GC will cause the watchpoint itself to destruct
321         https://bugs.webkit.org/show_bug.cgi?id=159198
322         <rdar://problem/26302360>
323
324         Reviewed by Filip Pizlo.
325
326         Firing a watchpoint may cause a GC to happen. This GC could destroy various
327         Watchpoints themselves while they're in the process of firing. It's not safe
328         for most Watchpoints to be destructed while they're in the middle of firing.
329         This GC could also destroy the WatchpointSet itself, and it's not in a safe
330         state to be destroyed. WatchpointSet::fireAllWatchpoints now defers gc for a
331         while. This prevents a GC from destructing any Watchpoints while they're
332         in the process of firing. This bug was being hit by the stress GC bots
333         because we would destruct a particular Watchpoint while it was firing,
334         and then we would access its field after it had already been destroyed.
335         This was causing all kinds of weird symptoms. Also, this was easier to
336         catch when running with guard malloc because the first access after
337         destruction would lead to a crash.
338
339         * bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp:
340         (JSC::AdaptiveInferredPropertyValueWatchpointBase::fire):
341         * bytecode/CodeBlock.cpp:
342         (JSC::CodeBlock::finishCreation):
343         * bytecode/VariableWriteFireDetail.cpp:
344         (JSC::VariableWriteFireDetail::dump):
345         (JSC::VariableWriteFireDetail::touch):
346         * bytecode/VariableWriteFireDetail.h:
347         * bytecode/Watchpoint.cpp:
348         (JSC::WatchpointSet::add):
349         (JSC::WatchpointSet::fireAllSlow):
350         (JSC::WatchpointSet::fireAllWatchpoints):
351         (JSC::InlineWatchpointSet::add):
352         (JSC::InlineWatchpointSet::fireAll):
353         (JSC::InlineWatchpointSet::inflateSlow):
354         * bytecode/Watchpoint.h:
355         (JSC::WatchpointSet::startWatching):
356         (JSC::WatchpointSet::fireAll):
357         (JSC::WatchpointSet::touch):
358         (JSC::WatchpointSet::invalidate):
359         (JSC::WatchpointSet::isBeingWatched):
360         (JSC::WatchpointSet::offsetOfState):
361         (JSC::WatchpointSet::addressOfSetIsNotEmpty):
362         (JSC::InlineWatchpointSet::startWatching):
363         (JSC::InlineWatchpointSet::fireAll):
364         (JSC::InlineWatchpointSet::invalidate):
365         (JSC::InlineWatchpointSet::touch):
366         * bytecompiler/BytecodeGenerator.cpp:
367         (JSC::BytecodeGenerator::BytecodeGenerator):
368         * dfg/DFGOperations.cpp:
369         * interpreter/Interpreter.cpp:
370         (JSC::Interpreter::execute):
371         * jit/JITOperations.cpp:
372         * jsc.cpp:
373         (WTF::Masquerader::create):
374         * llint/LLIntSlowPaths.cpp:
375         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
376         * runtime/ArrayBufferNeuteringWatchpoint.cpp:
377         (JSC::ArrayBufferNeuteringWatchpoint::fireAll):
378         * runtime/FunctionRareData.cpp:
379         (JSC::FunctionRareData::clear):
380         * runtime/InferredType.cpp:
381         (JSC::InferredType::willStoreValueSlow):
382         (JSC::InferredType::makeTopSlow):
383         (JSC::InferredType::set):
384         (JSC::InferredType::removeStructure):
385         (JSC::InferredType::InferredStructureWatchpoint::fireInternal):
386         * runtime/InferredValue.cpp:
387         (JSC::InferredValue::notifyWriteSlow):
388         (JSC::InferredValue::ValueCleanup::finalizeUnconditionally):
389         * runtime/InferredValue.h:
390         (JSC::InferredValue::notifyWrite):
391         (JSC::InferredValue::invalidate):
392         * runtime/JSGlobalObject.cpp:
393         (JSC::JSGlobalObject::haveABadTime):
394         * runtime/JSSymbolTableObject.h:
395         (JSC::symbolTablePutTouchWatchpointSet):
396         (JSC::symbolTablePutInvalidateWatchpointSet):
397         * runtime/Structure.cpp:
398         (JSC::Structure::didCachePropertyReplacement):
399         (JSC::Structure::startWatchingInternalProperties):
400         (JSC::DeferredStructureTransitionWatchpointFire::~DeferredStructureTransitionWatchpointFire):
401         (JSC::DeferredStructureTransitionWatchpointFire::add):
402         (JSC::Structure::didTransitionFromThisStructure):
403         (JSC::Structure::prototypeForLookup):
404         * runtime/StructureInlines.h:
405         (JSC::Structure::didReplaceProperty):
406         (JSC::Structure::propertyReplacementWatchpointSet):
407         * runtime/SymbolTable.h:
408         (JSC::SymbolTableEntry::isDontEnum):
409         (JSC::SymbolTableEntry::disableWatching):
410         * runtime/VM.cpp:
411         (JSC::VM::addImpureProperty):
412         (JSC::enableProfilerWithRespectToCount):
413
414 2016-06-28  Filip Pizlo  <fpizlo@apple.com>
415
416         JSRopeString should use release asserts, not debug asserts, about substring bounds
417         https://bugs.webkit.org/show_bug.cgi?id=159227
418
419         Reviewed by Saam Barati.
420         
421         According to my experiments this change costs nothing.  That's not surprising since the
422         most common way to construct a rope these days is inlined into the JIT, which does its own
423         safety checks.  This makes us crash sooner rather than corrupting memory.
424
425         * runtime/JSString.h:
426
427 2016-06-28  Brian Burg  <bburg@apple.com>
428
429         RunLoop::Timer should use constructor templates instead of class templates
430         https://bugs.webkit.org/show_bug.cgi?id=159153
431
432         Reviewed by Alex Christensen.
433
434         Remove the RunLoop::Timer class template argument, and pass its constructor
435         a reference to `this` instead of a pointer to `this`.
436
437         * inspector/agents/InspectorHeapAgent.cpp:
438         (Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask):
439
440 2016-06-28  Joseph Pecoraro  <pecoraro@apple.com>
441
442         Web Inspector: selectElement.options shows unexpected entries in console (named indexes beyond collection length)
443         https://bugs.webkit.org/show_bug.cgi?id=159192
444
445         Reviewed by Timothy Hatcher.
446
447         * inspector/InjectedScriptSource.js:
448         (InjectedScript.prototype.arrayIndexPropertyNames):
449         Start with an empty array because we just push valid indexes.
450
451         (InjectedScript.prototype._propertyDescriptors):
452         Avoid the >100 length requirement, and always treat the
453         array-like objects the same. The frontend currently
454         doesn't show named indexes for arrays anyways, so they
455         would have been unused.
456
457 2016-06-28  Per Arne Vollan  <pvollan@apple.com>
458
459         [Win] Skip failing INTL test.
460         https://bugs.webkit.org/show_bug.cgi?id=159141
461
462         Reviewed by Brent Fulgham.
463
464         INTL is not enabled on Windows.
465
466         * tests/stress/intl-constructors-with-proxy.js:
467         (shouldBe):
468
469 2016-06-28  Joonghun Park  <jh718.park@samsung.com>
470
471         [JSC] Fix build break since r202502 - 2
472         https://bugs.webkit.org/show_bug.cgi?id=159194
473
474         Reviewed by Gyuyoung Kim.
475
476         Fix about the error message below.
477         error: control reaches end of non-void function [-Werror=return-type]
478
479         * b3/B3TypeMap.h: add #pragma GCC diagnostic ignored "-Wreturn-type".
480
481 2016-06-28  Joonghun Park  <jh718.park@samsung.com>
482
483         [JSC] Fix build break since r202502
484         https://bugs.webkit.org/show_bug.cgi?id=159194
485
486         Reviewed by Alex Christensen.
487
488         Fix about the error message below.
489         error: control reaches end of non-void function [-Werror=return-type]
490
491         * b3/B3TypeMap.h:
492         (JSC::B3::TypeMap::at): add missing ASSERT_NOT_REACHED().
493
494 2016-06-27  Keith Miller  <keith_miller@apple.com>
495
496         Fix bad assert in StructureRareData::setObjectToStringValue
497         https://bugs.webkit.org/show_bug.cgi?id=159171
498         <rdar://problem/26987355>
499
500         Reviewed by Mark Lam.
501
502         We should not have expected the generateConditionsForPrototypePropertyHit would succeed.
503         There are many reasons it might fail including that there is a proxy somewhere on the
504         prototype chain of the object.
505
506         * runtime/StructureRareData.cpp:
507         (JSC::StructureRareData::setObjectToStringValue):
508         * tests/stress/object-toString-with-proxy.js: Added.
509         (get target):
510
511 2016-06-27  Filip Pizlo  <fpizlo@apple.com>
512
513         Crashing at an unreachable code trap in FTL should give more information
514         https://bugs.webkit.org/show_bug.cgi?id=159177
515
516         Reviewed by Saam Barati.
517         
518         This stuffs information into registers so that we have some chance of seeing what happened
519         by looking at the register dumps.
520
521         * assembler/AbortReason.h:
522         * ftl/FTLLowerDFGToB3.cpp:
523         (JSC::FTL::DFG::ftlUnreachable):
524         (JSC::FTL::DFG::LowerDFGToB3::compileBlock):
525         (JSC::FTL::DFG::LowerDFGToB3::crash):
526
527 2016-06-27  Filip Pizlo  <fpizlo@apple.com>
528
529         Clean up resetting reachability in B3/Air
530         https://bugs.webkit.org/show_bug.cgi?id=159170
531
532         Reviewed by Geoffrey Garen.
533         
534         When I fixed bug 159165, I took the brute force approach. I still used the
535         B3::resetReachability() method, and changed the callback to record the set of deleted values
536         instead of deleting them eagerly. But this means tracking the set of deleted values, even
537         though resetReachability() already internally tracks the set of deleted blocks. You can find
538         out if a value is deleted by asking if its owning block was deleted.
539         
540         So, this change refactors B3::resetReachability() into a new helper called
541         B3::recomputePredecessors(). This new helper skips the block deletion step, and lets the
542         client delete blocks. This lets Air delete blocks the same way that it did before, and it
543         lets B3 use the isBlockDead() method (which is a glorified proxy for
544         block->predecessors().isEmpty()) to track which values are deleted. This allows B3 to turn
545         Upsilons that point to dead Phis into Nops before deleting the blocks.
546         
547         This shouldn't affect performance or anything real. It just makes the code cleaner.
548
549         * b3/B3BasicBlockUtils.h:
550         (JSC::B3::updatePredecessorsAfter):
551         (JSC::B3::recomputePredecessors):
552         (JSC::B3::isBlockDead):
553         (JSC::B3::resetReachability): Deleted.
554         * b3/B3Procedure.cpp:
555         (JSC::B3::Procedure::resetReachability):
556         (JSC::B3::Procedure::invalidateCFG):
557         * b3/air/AirCode.cpp:
558         (JSC::B3::Air::Code::resetReachability):
559         (JSC::B3::Air::Code::dump):
560
561 2016-06-27  Brian Burg  <bburg@apple.com>
562
563         Web Inspector: CRASH in backend at Inspector::HeapFrontendDispatcher::garbageCollected + 552 when closing frontend/inspected page
564         https://bugs.webkit.org/show_bug.cgi?id=159075
565         <rdar://problem/26094341>
566
567         Reviewed by Filip Pizlo.
568
569         This change caused JSC stress tests to all hit an assertion in RunLoop.
570         We should use RunLoop::current() to create the RunLoop::Timer since JSC-only
571         clients like testapi and jsc don't ever call initializeMainRunLoop().
572
573         * inspector/agents/InspectorHeapAgent.cpp:
574         (Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask):
575
576 2016-06-27  Filip Pizlo  <fpizlo@apple.com>
577
578         B3::Procedure::resetReachability() can create dangling references from Upsilons to Phis
579         https://bugs.webkit.org/show_bug.cgi?id=159165
580
581         Reviewed by Mark Lam.
582         
583         You can delete an unreachable block that has a Phi but some prior block may still have an
584         Upsilon pointing to that Phi. This can happen if the Upsilon precedes a Check that always
585         exits or it can happen if we remove some successor of a block and this block had an Upsilon
586         for one of the removed successors. These things are valid IR even if they are not canonical.
587         Our policy for not-canonical-but-valid IR is that the compiler should still emit valid code
588         in the end.
589         
590         The solution is to have Procedure::resetReachability() turn those Upsilons into Nops.
591
592         * b3/B3Procedure.cpp:
593         (JSC::B3::Procedure::resetReachability): Fix the bug.
594         * b3/B3Validate.h:
595         * b3/testb3.cpp:
596         (JSC::B3::testResetReachabilityDanglingReference): Add a test. This always crashes prior to this change.
597         * dfg/DFGGraph.cpp:
598         (JSC::DFG::Graph::killUnreachableBlocks): Add a FIXME about a possible similar bug.
599
600 2016-06-27  Keith Miller  <keith_miller@apple.com>
601
602         Add comment to Module feature in features.json
603         https://bugs.webkit.org/show_bug.cgi?id=159159
604
605         Reviewed by Saam Barati.
606
607         * features.json:
608
609 2016-06-27  Keith Miller  <keith_miller@apple.com>
610
611         Update features.json for ES6 completed features.
612         https://bugs.webkit.org/show_bug.cgi?id=159152
613
614         Reviewed by Mark Lam.
615
616         * features.json:
617
618 2016-06-25  Filip Pizlo  <fpizlo@apple.com>
619
620         B3 should not use Nops when deleting unreachable code
621         https://bugs.webkit.org/show_bug.cgi?id=159120
622         rdar://problem/26500743
623
624         Reviewed by Michael Saboff.
625         
626         Prior to this change, transformations that obviated the need for some value could choose
627         from these ways to kill it:
628         
629         - replaceWithIdentity() if we're replacing with another value.
630         - replaceWithNop() if the type is Void or if we know that we'll fix any users of this
631           value.
632         - deleteValue() if the code is unreachable.
633         
634         The bug here is that reduceStrength() was being clever about how to get rid of a value.
635         reduceStrength() may find a Check that must always exit. The goal is to remove any code
636         dominated by the Check. But it would be awkward to eagerly delete all of the blocks
637         dominated by this one. So this code took a much simpler approach: it would
638         replaceWithNop() for all of the values in this block after the Check and it would replace
639         the terminal with Oops.
640         
641         But this corrupts the IR in a subtle way: some of those values may have been non-Void but
642         now they are Nops so they are Void. reduceStrength() will not yet realize that the blocks
643         dominated by the one with the Check are unreachable, so it will run all sorts of
644         optimizations on those blocks. This could have probably manifested as many different kinds
645         of badness, but the way I found out about this issue was through a crash in
646         IntRange::top(Type) when inlined into ReduceStrength::rangeFor(). We'd die in a switch
647         statement over a child's type.
648         
649         We could fix this by making rangeFor() tolerate Void. But I think that this would be
650         dangerous. There could easily be other places in reduceStrength() that assume that value's
651         children are non-Void. So, this change fixes the Check optimization and adds mechanisms to
652         prevent other optimizations from breaking the children-are-not-Void rule.
653         
654         This introduces two high-level changes:
655         
656         - It's no longer legal to replaceWithNop() if the value is not Void. This change alone
657           would cause reduceStrength() to instacrash in its Check optimization. Almost all other
658           uses of replaceWithNop() were already following this rule, so they were fine. One other
659           place was using replaceWithNop() on non-Void values after arranging for them to no
660           longer have any parents. That was changed to call replaceWithNopIgnoringType(), which
661           doesn't have any type assertions.
662         
663         - For reduceStrength() there is a new Value::replaceWithBottom() method that works with
664           Void or non-Void and behaves like you would want replaceWithNop() to behave: if you know
665           that the code is unreachable then it produces something that is guaranteed to be deleted
666           by later optimizations, and if it's not unreachable, then it's guaranteed to be compiled
667           to something harmless and cheap. This means replacing the value with an identity that
668           points to a bottom constant (the 0 for whatever type we have), or just replacing it with
669           Nop if it's Void.
670         
671         This also adds a test case for the reason why we do this: we may have two blocks, where
672         the first block unconditionally exits while dominating the second block. The second block
673         references values in the part of the first block that is unreachable. In trunk, this test
674         would assert in ReduceStrength::rangeFor() because the CheckAdd in the second block would
675         reference a Nop in the first block.
676         
677         This fixes a high volume crash in ReduceStrength::rangeFor(). This crash was very
678         confusing. Even though we were crashing at a RELEASE_ASSERT_NOT_REACHED() in a switch
679         statement in IntRange::top(Type), clang was merging that trap with the trap it used for
680         Vector OOB. The top of the stack in crash dumps looked like:
681         
682             JSC::B3::(anonymous namespace)::ReduceStrength::rangeFor(JSC::B3::Value*, unsigned int) + 4477 (Vector.h:655)
683         
684         Where Vector.h:655 is:
685         
686             OverflowHandler::overflowed();
687
688         But this crash was not at Vector.h:655. It was at B3ReduceStrength.cpp:121. The two lines
689         are both traps, so they got merged despite differences in debug info. This bug would have
690         been so much easier to fix if I had the right line number.
691
692         * b3/B3BottomProvider.h: Added. This is a utility for creating bottom values.
693         (JSC::B3::BottomProvider::BottomProvider):
694         (JSC::B3::BottomProvider::operator()):
695         * b3/B3InsertionSet.cpp: Optimized adding bottom values a bit. We will no longer create pointless duplicates.
696         (JSC::B3::InsertionSet::insertBottom):
697         (JSC::B3::InsertionSet::execute):
698         (JSC::B3::InsertionSet::bottomForType):
699         * b3/B3InsertionSet.h:
700         * b3/B3MoveConstants.cpp: Use replaceWithNopIgnoringType() because we *know* that we can replaceWithNop even for non-Void.
701         * b3/B3Procedure.h:
702         * b3/B3ReduceStrength.cpp: Use replaceWithBottom().
703         * b3/B3ReduceStrength.h:
704         * b3/B3TypeMap.h: I figured if I wrote type-casing code like this once then I'd never want to write it again.
705         * b3/B3Value.cpp:
706         (JSC::B3::Value::replaceWithIdentity):
707         (JSC::B3::Value::replaceWithNop):
708         (JSC::B3::Value::replaceWithNopIgnoringType):
709         * b3/B3Value.h:
710         * b3/B3ValueInlines.h:
711         (JSC::B3::Value::replaceWithBottom): This is the new method of killing unreachable code.
712         (JSC::B3::Value::as):
713         * b3/testb3.cpp: Add new tests!
714         (JSC::B3::testLateRegister):
715         (JSC::B3::testReduceStrengthCheckBottomUseInAnotherBlock):
716         (JSC::B3::zero):
717         (JSC::B3::run):
718
719 2016-06-27  Joseph Pecoraro  <pecoraro@apple.com>
720
721         REGRESSION: Web Inspector: Text search broken in resources with <CR>
722         https://bugs.webkit.org/show_bug.cgi?id=159110
723         <rdar://problem/27008485>
724
725         Reviewed by Brian Burg.
726
727         * inspector/ContentSearchUtilities.cpp:
728         (Inspector::ContentSearchUtilities::lineEndings):
729         The frontend moved to only treated newlines as line endings in
730         the TextEditor. The backend however was looking for many
731         different types of line endings (\r\n, \r, \n). This caused
732         the line endings to ultimately differ between the frontend
733         and the backend, so the frontend couldn't find the lines that
734         the backend was claiming search results were on. Change the
735         backend to only look for \n line endings.
736
737 2016-06-27  Brian Burg  <bburg@apple.com>
738
739         Web Inspector: CRASH in backend at Inspector::HeapFrontendDispatcher::garbageCollected + 552 when closing frontend/inspected page
740         https://bugs.webkit.org/show_bug.cgi?id=159075
741         <rdar://problem/26094341>
742
743         Reviewed by Timothy Hatcher.
744
745         Move the asynchronous work to a task class that can be cancelled when the
746         heap agent is reset, disabled or destroyed.
747
748         * inspector/agents/InspectorHeapAgent.cpp:
749         (Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask):
750         (Inspector::SendGarbageCollectionEventsTask::addGarbageCollection):
751         (Inspector::SendGarbageCollectionEventsTask::reset):
752         (Inspector::SendGarbageCollectionEventsTask::timerFired):
753         Added. This holds onto GarbageCollectionData that needs to be sent asynchronously.
754         It uses the RunLoop variant of Timer and can queue multiple collections to be sent.
755         The data vector is guarded with a lock so that garbageCollected() can safely add
756         collection data from a non-main thread while the main thread sends out events.
757
758         (Inspector::InspectorHeapAgent::InspectorHeapAgent):
759         (Inspector::InspectorHeapAgent::~InspectorHeapAgent):
760         (Inspector::InspectorHeapAgent::disable):
761         Reset the task when disabling or tearing down the agent so the timer doesn't fire after destruction.
762
763         (Inspector::InspectorHeapAgent::didGarbageCollect):
764         Add the collection data to the task, which will dispatch an event for it asynchronously.
765
766         * inspector/agents/InspectorHeapAgent.h:
767
768 2016-06-27  Michael Saboff  <msaboff@apple.com>
769
770         ES6 Change: Unify handling of RegExp CharacterClassEscapes \w and \W and Word Asserts \b and \B
771         https://bugs.webkit.org/show_bug.cgi?id=158505
772
773         Reviewed by Geoffrey Garen.
774
775         This change makes it so that the CharacterClassEscape \w matches the inverse of
776         \W and vice versa for unicode, ignore case RegExp's.
777
778         Before this change, both /\w/ui and /\W/ui RegExp's would match the characters
779         k, K, s, S, \u017f (Latin Small Letter Long S) and \u212a (Kelvin Sign).
780         This was due to how the ES6 standard defined matching of character classes
781         specifically that the abstract operation "Canonicalize()" is called for the
782         character to be matched AND for the characters in the character class we are
783         matching against.  This change is to make \W always be the inverse of \w.
784         It is still the case that the characters that match against \w changes
785         depending on a regular expression's flags.
786
787         The only real changes occur for regular expressions with both the unicode and
788         ignore case flags set.  Updated the character class generator to make 
789         nonwordUnicodeIgnoreCaseChar not include k, K, s, S, \u017f and \u212a.
790         Changed BytecodePattern.wordcharCharacterClass to use the correct
791         word character class for the flags.  Simplfied character class set up in
792         in the pattern to use m_pattern.wordUnicodeIgnoreCaseCharCharacterClass and
793         invert as appropriate when unicode and ignore case are both set.
794
795         * create_regex_tables:
796         * yarr/YarrInterpreter.h:
797         (JSC::Yarr::BytecodePattern::BytecodePattern):
798         * yarr/YarrPattern.cpp:
799         (JSC::Yarr::YarrPatternConstructor::atomBuiltInCharacterClass):
800
801 2016-06-25  Keith Miller  <keith_miller@apple.com>
802
803         DFGByteCodeParsing does not handle calling the Object constructor with no arguments correctly
804         https://bugs.webkit.org/show_bug.cgi?id=159117
805         <rdar://problem/26996781>
806
807         Reviewed by Saam Barati.
808
809         DFGByteCodeParsing always assumed there would be an argument to the Object constructor.
810         This is clearly not always the case and we should be able to handle it.
811
812         * dfg/DFGByteCodeParser.cpp:
813         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
814         * tests/stress/indirect-call-object-constructor-with-no-arguments.js: Added.
815         (let.foo.Object.test):
816
817 2016-06-24  Filip Pizlo  <fpizlo@apple.com>
818
819         B3 should die sooner if a Value has the wrong number of children
820         https://bugs.webkit.org/show_bug.cgi?id=159108
821
822         Reviewed by Mark Lam.
823         
824         I've been looking at a bug (rdar://problem/26500743) that's about a Vector OOB crash in
825         ReduceStrength::rangeFor(). The only Vector accesses are to Value::m_children, and all of
826         the accesses in rangeFor() are for child(0) or child(1) of binary arithmetic opcodes.
827         Clearly those should never go out-of-bounds.
828         
829         Maybe we have horrible memory corruption. Or maybe some path creates a Value with the
830         wrong number of children, and that path is not tested by any of our tests. This patch adds
831         release assertions that will catch the latter.
832         
833         I've tested this a lot. It's not a regression on our benchmarks.
834
835         * b3/B3Opcode.h:
836         * b3/B3Value.cpp:
837         (JSC::B3::Value::dumpMeta):
838         (JSC::B3::Value::typeFor):
839         (JSC::B3::Value::badOpcode):
840         (JSC::B3::Value::checkOpcode): Deleted.
841         * b3/B3Value.h:
842
843 2016-06-24  Mark Lam  <mark.lam@apple.com>
844
845         [JSC] Error prototypes are called on remote scripts.
846         https://bugs.webkit.org/show_bug.cgi?id=52192
847
848         Reviewed by Keith Miller.
849
850         Added a sanitizedToString() to the Error instance object so that it can be used
851         to get an error string without invoking getters and proxies.
852
853         * runtime/ErrorInstance.cpp:
854         (JSC::ErrorInstance::finishCreation):
855         (JSC::ErrorInstance::sanitizedToString):
856         * runtime/ErrorInstance.h:
857         (JSC::ErrorInstance::createStructure):
858         (JSC::ErrorInstance::runtimeTypeForCause):
859         (JSC::ErrorInstance::clearRuntimeTypeForCause):
860
861 2016-06-24  Commit Queue  <commit-queue@webkit.org>
862
863         Unreviewed, rolling out r202443.
864         https://bugs.webkit.org/show_bug.cgi?id=159105
865
866         Introduced memory corruption crashes (Requested by ap on
867         #webkit).
868
869         Reverted changeset:
870
871         "Web Inspector: CRASH in backend at
872         Inspector::HeapFrontendDispatcher::garbageCollected + 552 when
873         closing frontend/inspected page"
874         https://bugs.webkit.org/show_bug.cgi?id=159075
875         http://trac.webkit.org/changeset/202443
876
877 2016-06-24  Brian Burg  <bburg@apple.com>
878
879         Web Inspector: CRASH in backend at Inspector::HeapFrontendDispatcher::garbageCollected + 552 when closing frontend/inspected page
880         https://bugs.webkit.org/show_bug.cgi?id=159075
881         <rdar://problem/26094341>
882
883         Reviewed by Joseph Pecoraro.
884
885         Move the asynchronous work to a task class that can be cancelled when the
886         heap agent is reset, disabled or destroyed.
887
888         * inspector/agents/InspectorHeapAgent.cpp:
889         (Inspector::SendGarbageCollectionEventsTask::SendGarbageCollectionEventsTask):
890         (Inspector::SendGarbageCollectionEventsTask::addGarbageCollection):
891         (Inspector::SendGarbageCollectionEventsTask::reset):
892         (Inspector::SendGarbageCollectionEventsTask::timerFired):
893         Added. This holds onto GarbageCollection objects that need to be sent asynchronously.
894         It uses the RunLoop variant of Timer and can queue multiple pending objects to be sent.
895
896         (Inspector::InspectorHeapAgent::InspectorHeapAgent):
897         (Inspector::InspectorHeapAgent::~InspectorHeapAgent):
898         (Inspector::InspectorHeapAgent::disable):
899         Reset the task when disabling or tearing down the agent so the timer doesn't fire after destruction.
900
901         (Inspector::InspectorHeapAgent::didGarbageCollect):
902         Send the object to the task to be dispatched asynchronously.
903
904         * inspector/agents/InspectorHeapAgent.h:
905
906 2016-06-24  Commit Queue  <commit-queue@webkit.org>
907
908         Unreviewed, rolling out r202413.
909         https://bugs.webkit.org/show_bug.cgi?id=159097
910
911         Broke many JSC tests (Requested by ap on #webkit).
912
913         Reverted changeset:
914
915         "[JSC] Implement isFinite / isNaN in JS and make DFG ToNumber
916         accept non number values"
917         https://bugs.webkit.org/show_bug.cgi?id=154022
918         http://trac.webkit.org/changeset/202413
919
920 2016-06-23  Benjamin Poulain  <bpoulain@apple.com>
921
922         OOM Assertion failure in Array.prototype.toString
923         https://bugs.webkit.org/show_bug.cgi?id=158793
924
925         Reviewed by Saam Barati.
926
927         JSString::create() taking a StringImpl was using a signed integer
928         for the length of the string.
929         The problem is StringImpl uses an unsigned integer. When a large string
930         was passed to JSString, the signed integer would be negative and crash
931         JSString.
932
933         * runtime/JSString.h:
934         (JSC::JSString::create):
935
936 2016-06-23  Joseph Pecoraro  <pecoraro@apple.com> and Yusuke Suzuki  <utatane.tea@gmail.com>
937
938         [JSC] Implement isFinite / isNaN in JS and make DFG ToNumber accept non number values
939         https://bugs.webkit.org/show_bug.cgi?id=154022
940
941         Reviewed by Filip Pizlo.
942
943         We aim at optimizing @toInteger operation.
944         While it still has an unoptimized part[1], this patch should be a first step.
945
946         We introduce the @toNumber builtin intrinsic operation.
947         This converts the given value to the JS number by emitting op_to_number bytecode.
948         Previously @toInteger called C++ @Number constructor for that purpose.
949
950         And in DFG, op_to_number is converted to DFG ToNumber node.
951         During DFG, we attempt to convert this to edge filtering and Identity, but if we fail,
952         we just fall back to calling the C++ function.
953
954         To utilize ToNumber in user-land side, we add a path attempting to convert Number constructor calls
955         to ToNumber DFG nodes. This conversion is useful because `Number(value)` is used to convert a value to a number in JS.
956
957         Before this patch, we emit simple edge filtering (NumberUse) instead of emitting DFG node like ToNumber for op_to_number.
958         But emitting ToNumber is useful, because in the case of `Number(value)`, considering `value` may not be a number is reasonable.
959
960         By leveraging @toNumber operation, we rewrite Number.{isFinite, isNaN}, global.{isFinite, isNaN} and @toInteger.
961
962         ToNumber DFG node has a value profiling. This profiling is leveraged to determine the result number type of the ToNumber operation.
963         This value profiling is provided from either NumberConstructor's call operation or op_to_number.
964
965         The results (with the added performance tests) show that, while existing cases are performance neutral, the newly added cases gain the performance benefit.
966         And ASMBench/n-body.c also shows stable ~2% progression.
967
968         [1]: https://bugs.webkit.org/show_bug.cgi?id=153738
969
970         * CMakeLists.txt:
971         * DerivedSources.make:
972         * JavaScriptCore.xcodeproj/project.pbxproj:
973         * builtins/BuiltinNames.h:
974         * builtins/GlobalObject.js:
975         (globalPrivate.isFinite):
976         (globalPrivate.isNaN):
977         (globalPrivate.toInteger): Deleted.
978         (globalPrivate.toLength): Deleted.
979         (globalPrivate.isDictionary): Deleted.
980         (globalPrivate.speciesGetter): Deleted.
981         (globalPrivate.speciesConstructor): Deleted.
982         * builtins/GlobalOperations.js: Copied from Source/JavaScriptCore/builtins/GlobalObject.js.
983         (globalPrivate.toInteger):
984         (globalPrivate.toLength):
985         (globalPrivate.isDictionary):
986         (globalPrivate.speciesGetter):
987         (globalPrivate.speciesConstructor):
988         * builtins/NumberConstructor.js: Added.
989         (isFinite):
990         (isNaN):
991         * bytecode/BytecodeIntrinsicRegistry.cpp:
992         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
993         * bytecode/BytecodeIntrinsicRegistry.h:
994         * bytecode/BytecodeList.json:
995         * bytecode/CodeBlock.cpp:
996         (JSC::CodeBlock::dumpBytecode):
997         (JSC::CodeBlock::finishCreation):
998         * bytecompiler/BytecodeGenerator.cpp:
999         (JSC::BytecodeGenerator::emitUnaryOp):
1000         (JSC::BytecodeGenerator::emitUnaryOpProfiled):
1001         * bytecompiler/BytecodeGenerator.h:
1002         (JSC::BytecodeGenerator::emitToNumber):
1003         * bytecompiler/NodesCodegen.cpp:
1004         (JSC::BytecodeIntrinsicNode::emit_intrinsic_toNumber):
1005         (JSC::UnaryPlusNode::emitBytecode):
1006         * dfg/DFGAbstractInterpreterInlines.h:
1007         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1008         * dfg/DFGByteCodeParser.cpp:
1009         (JSC::DFG::ByteCodeParser::attemptToInlineCall):
1010         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
1011         (JSC::DFG::ByteCodeParser::parseBlock):
1012         We use `getPrediction()` to retrieve the heap prediction from the to_number bytecode.
1013         According to the benchmark results, choosing `getPredictionWithoutOSRExit()` causes performance regression (1.5%) in kraken stanford-crypto-aes.
1014
1015         * dfg/DFGClobberize.h:
1016         (JSC::DFG::clobberize):
1017         * dfg/DFGConstantFoldingPhase.cpp:
1018         (JSC::DFG::ConstantFoldingPhase::foldConstants):
1019         * dfg/DFGDoesGC.cpp:
1020         (JSC::DFG::doesGC):
1021         * dfg/DFGFixupPhase.cpp:
1022         (JSC::DFG::FixupPhase::fixupNode):
1023         (JSC::DFG::FixupPhase::fixupToNumber):
1024         * dfg/DFGNode.h:
1025         (JSC::DFG::Node::hasHeapPrediction):
1026         * dfg/DFGNodeType.h:
1027         * dfg/DFGOperations.cpp:
1028         * dfg/DFGOperations.h:
1029         * dfg/DFGPredictionPropagationPhase.cpp:
1030         Alway rely on the heap prediction.
1031
1032         * dfg/DFGSafeToExecute.h:
1033         (JSC::DFG::safeToExecute):
1034         * dfg/DFGSpeculativeJIT32_64.cpp:
1035         (JSC::DFG::SpeculativeJIT::compile):
1036         As of 64bit version, we carefully manage the register reuse. The largest difference between 32bit and 64bit is
1037         `branchIfNotNumber()` requires the temporary register. We should not use the result registers for that since
1038         it may be reuse the argument registers and it can break the argument registers before using them to call the operation.
1039         Currently, we allocate the additional temporary register for that scratch register.
1040
1041         * dfg/DFGSpeculativeJIT64.cpp:
1042         (JSC::DFG::SpeculativeJIT::compile):
1043         Reuse the argument register for the result if possible. And manually decrement the use count in the middle of the node.
1044         This is similar technique used in ToPrimitive. Typically, the child of ToNumber is only used by this ToNumber node since
1045         we would like to perform the type conversion onto this child node here. So this careful register reuse effectively removes
1046         the spills to call the operation. The example of the actually emitted code is the following.
1047
1048         76:<!2:loc11>     ToNumber(Untyped:@68, JS|MustGen|UseAsOther, DoubleimpurenanTopEmpty, R:World, W:Heap, Exits, ClobbersExit, bc#48)  predicting DoubleimpurenanTopEmpty
1049             0x7f986d5fe693: test %rax, %r14
1050             0x7f986d5fe696: jz 0x7f986d5fe6a1
1051             0x7f986d5fe69c: jmp 0x7f986d5fe6d1
1052             0x7f986d5fe6a1: mov %rax, %rsi
1053             0x7f986d5fe6a4: mov %rbp, %rdi
1054             0x7f986d5fe6a7: mov $0x2, 0x24(%rbp)
1055             0x7f986d5fe6ae: mov $0x7f98711ea5f0, %r11
1056             0x7f986d5fe6b8: call *%r11
1057             0x7f986d5fe6bb: mov $0x7f982d3f72d0, %r11
1058             0x7f986d5fe6c5: mov (%r11), %r11
1059             0x7f986d5fe6c8: test %r11, %r11
1060             0x7f986d5fe6cb: jnz 0x7f986d5fe88c
1061
1062         It effectively removes the unnecessary spill to call the operation!
1063
1064         * ftl/FTLCapabilities.cpp:
1065         (JSC::FTL::canCompile):
1066         * ftl/FTLLowerDFGToB3.cpp:
1067         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1068         (JSC::FTL::DFG::LowerDFGToB3::compileToNumber):
1069         (JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
1070         * jit/AssemblyHelpers.h:
1071         (JSC::AssemblyHelpers::branchIfNumber):
1072         (JSC::AssemblyHelpers::branchIfNotNumber):
1073         * jit/JITOpcodes.cpp:
1074         (JSC::JIT::emit_op_to_number):
1075         * jit/JITOpcodes32_64.cpp:
1076         (JSC::JIT::emit_op_to_number):
1077         * llint/LowLevelInterpreter32_64.asm:
1078         * llint/LowLevelInterpreter64.asm:
1079         * parser/Nodes.h:
1080         (JSC::UnaryOpNode::opcodeID):
1081         * runtime/CommonSlowPaths.cpp:
1082         (JSC::SLOW_PATH_DECL):
1083         * runtime/JSGlobalObject.cpp:
1084         (JSC::JSGlobalObject::init):
1085         * runtime/JSGlobalObjectFunctions.cpp:
1086         (JSC::globalFuncIsNaN): Deleted.
1087         (JSC::globalFuncIsFinite): Deleted.
1088         * runtime/JSGlobalObjectFunctions.h:
1089         * runtime/MathCommon.h:
1090         (JSC::maxSafeInteger):
1091         (JSC::minSafeInteger):
1092         * runtime/NumberConstructor.cpp:
1093         (JSC::NumberConstructor::finishCreation):
1094         (JSC::numberConstructorFuncIsFinite): Deleted.
1095         (JSC::numberConstructorFuncIsNaN): Deleted.
1096         * runtime/NumberConstructor.h:
1097         * tests/stress/Number-isNaN-basics.js: Added.
1098         (numberIsNaNOnInteger):
1099         (testNumberIsNaNOnIntegers):
1100         (verifyNumberIsNaNOnIntegerWithOtherTypes):
1101         (numberIsNaNOnDouble):
1102         (testNumberIsNaNOnDoubles):
1103         (verifyNumberIsNaNOnDoublesWithOtherTypes):
1104         (numberIsNaNNoArguments):
1105         (numberIsNaNTooManyArguments):
1106         (testNumberIsNaNOnConstants):
1107         (numberIsNaNStructTransition):
1108         (Number.isNaN):
1109         * tests/stress/global-is-finite.js: Added.
1110         (shouldBe):
1111         * tests/stress/global-is-nan.js: Added.
1112         (shouldBe):
1113         * tests/stress/global-isNaN-basics.js: Added.
1114         (isNaNOnInteger):
1115         (testIsNaNOnIntegers):
1116         (verifyIsNaNOnIntegerWithOtherTypes):
1117         (isNaNOnDouble):
1118         (testIsNaNOnDoubles):
1119         (verifyIsNaNOnDoublesWithOtherTypes):
1120         (verifyIsNaNOnCoercedTypes):
1121         (isNaNNoArguments):
1122         (isNaNTooManyArguments):
1123         (testIsNaNOnConstants):
1124         (isNaNTypeCoercionSideEffects):
1125         (i.value.isNaNTypeCoercionSideEffects.valueOf):
1126         (isNaNStructTransition):
1127         (isNaN):
1128         * tests/stress/number-is-finite.js: Added.
1129         (shouldBe):
1130         (test2):
1131         (test3):
1132         * tests/stress/number-is-nan.js: Added.
1133         (shouldBe):
1134         (test2):
1135         (test3):
1136         * tests/stress/to-number-basics.js: Added.
1137         (shouldBe):
1138         * tests/stress/to-number-convert-identity-without-execution.js: Added.
1139         (shouldBe):
1140         (object.valueOf):
1141         (valueOf):
1142         * tests/stress/to-number-int52.js: Added.
1143         (shouldBe):
1144         (object.valueOf):
1145         * tests/stress/to-number-intrinsic-convert-to-identity-without-execution.js: Added.
1146         (shouldBe):
1147         (object.valueOf):
1148         (valueOf):
1149         * tests/stress/to-number-intrinsic-int52.js: Added.
1150         (shouldBe):
1151         (object.valueOf):
1152         * tests/stress/to-number-intrinsic-object-without-execution.js: Added.
1153         (shouldBe):
1154         (object.valueOf):
1155         * tests/stress/to-number-intrinsic-value-profiling.js: Added.
1156         (shouldBe):
1157         (object.valueOf):
1158         * tests/stress/to-number-object-without-execution.js: Added.
1159         (shouldBe):
1160         (object.valueOf):
1161         * tests/stress/to-number-object.js: Added.
1162         (shouldBe):
1163         (test12):
1164         (object1.valueOf):
1165         (test2):
1166         (test22):
1167         (object2.valueOf):
1168         (test3):
1169         (test32):
1170         (object3.valueOf):
1171         * tests/stress/to-number-value-profiling.js: Added.
1172         (shouldBe):
1173         (object.valueOf):
1174
1175 2016-06-23  Saam Barati  <sbarati@apple.com>
1176
1177         DFGSpeculativeJIT's m_slowPathLambdas should restore the current node field and DFG OSR entry functions should use DeferGCForAWhile instead of DeferGC
1178         https://bugs.webkit.org/show_bug.cgi?id=159064
1179         <rdar://problem/26599119>
1180
1181         Reviewed by Filip Pizlo.
1182
1183         The DFG has a list of m_slowPathLambdas that are code generators it emits
1184         amongst its slow paths. These lambdas, however, did not update the m_currentNode field.
1185         This caused us to use whatever Node happened to be used as the currentNode at the time
1186         we call the slowPathLambda. This means the wrong CallSiteIndex was stored into the call
1187         frame when we made a call. This may lead to a crash if the CallSiteIndex corresponds to
1188         the wrong CodeOrigin. For example, the wrong CodeOrigin could have an InlineCallFrame with
1189         a calleeRecovery that will not be in sync with the current stack state. Trying
1190         to recover that callee will often lead to a crash. The solution is to update
1191         m_currentNode to the DFG::Node* it corresponds to when emitting these slowPathLambdas.
1192
1193         I found this bug because we were inside this bad state when calling an operation
1194         that happened to have a DeferGC. When this DeferGC actually GCed, it would
1195         take a StackTrace, which would lead to a crash because we were updating
1196         ShadowChicken with vm.topCallFrame. It just so happened that the CallSiteIndex
1197         in the call frame in this program corresponded to an InlineCallFrame with a calleeRecover.
1198         However, this CallSiteIndex didn't correspond to the actual state of execution
1199         of the program. I'm adding new options to make reproducing DeferGC related
1200         bugs easier by making DeferGC force a GC according to some probability. To
1201         always have DeferGC force a GC, you can set that probability to 1.
1202
1203         There is a second bug that I discovered after solving the above bug. We were
1204         using DeferGC instead of DeferGCForAWhile in the OSR entry related functions
1205         in the DFG. This would cause us to take a stack trace when the call frame was
1206         in an inconsistent state. For example, the operation would call FTL::prepareOSREntry,
1207         which would replace the DFG CodeBlock in the call frame with the FTL CodeBlock.
1208         However, we wouldn't update the CallSiteIndex to correspond to an FTL CallSiteIndex.
1209         This would lead to a crash when taking a stack trace. The solution is to prevent
1210         stack traces from being taken when the program is in this state by using
1211         DeferGCForAWhie instead of DeferGC.
1212
1213         * dfg/DFGOperations.cpp:
1214         * dfg/DFGSpeculativeJIT.cpp:
1215         (JSC::DFG::SpeculativeJIT::addSlowPathGenerator):
1216         (JSC::DFG::SpeculativeJIT::runSlowPathGenerators):
1217         * dfg/DFGSpeculativeJIT.h:
1218         * heap/Heap.h:
1219         * heap/HeapInlines.h:
1220         (JSC::Heap::collectIfNecessaryOrDefer):
1221         (JSC::Heap::collectAccordingToDeferGCProbability):
1222         (JSC::Heap::decrementDeferralDepthAndGCIfNeeded):
1223         (JSC::Heap::markListSet):
1224         * runtime/Options.cpp:
1225         (JSC::recomputeDependentOptions):
1226         (JSC::Options::initialize):
1227         * runtime/Options.h:
1228         * tests/stress/slow-path-generator-updating-current-node-dfg.js: Added.
1229         (foo):
1230         (bar):
1231
1232 2016-06-23  Filip Pizlo  <fpizlo@apple.com>
1233
1234         Failing baseline JIT compilation of a code block and then trying to compile it from OSR from DFG/FTL will corrupt the CodeBlock
1235         https://bugs.webkit.org/show_bug.cgi?id=158806
1236
1237         Reviewed by Saam Barati.
1238         
1239         If we try to compile a CodeBlock that we already tried compiling in the past then we need
1240         to clean up the data structures that were partly filled in by the failed compile. That
1241         causes some races, since the DFG may be trying to parse those data structures while we are
1242         clearing them. This patch introduces such a clean-up (CodeBlock::resetJITData()) and fixes
1243         the races.
1244
1245         * bytecode/CodeBlock.cpp:
1246         (JSC::CodeBlock::dumpBytecode):
1247         (JSC::CodeBlock::getStubInfoMap):
1248         (JSC::CodeBlock::getCallLinkInfoMap):
1249         (JSC::CodeBlock::getByValInfoMap):
1250         (JSC::CodeBlock::getCallLinkInfoForBytecodeIndex):
1251         (JSC::CodeBlock::resetJITData):
1252         (JSC::CodeBlock::visitOSRExitTargets):
1253         (JSC::CodeBlock::setSteppingMode):
1254         (JSC::CodeBlock::addRareCaseProfile):
1255         (JSC::CodeBlock::rareCaseProfileForBytecodeOffset):
1256         (JSC::CodeBlock::rareCaseProfileCountForBytecodeOffset):
1257         (JSC::CodeBlock::resultProfileForBytecodeOffset):
1258         (JSC::CodeBlock::specialFastCaseProfileCountForBytecodeOffset):
1259         (JSC::CodeBlock::couldTakeSpecialFastCase):
1260         (JSC::CodeBlock::ensureResultProfile):
1261         * bytecode/CodeBlock.h:
1262         (JSC::CodeBlock::getFromAllValueProfiles):
1263         (JSC::CodeBlock::numberOfRareCaseProfiles):
1264         (JSC::CodeBlock::numberOfResultProfiles):
1265         (JSC::CodeBlock::numberOfArrayProfiles):
1266         (JSC::CodeBlock::arrayProfiles):
1267         (JSC::CodeBlock::addRareCaseProfile): Deleted.
1268         (JSC::CodeBlock::specialFastCaseProfileCountForBytecodeOffset): Deleted.
1269         (JSC::CodeBlock::couldTakeSpecialFastCase): Deleted.
1270         * dfg/DFGByteCodeParser.cpp:
1271         (JSC::DFG::ByteCodeParser::makeSafe):
1272         * dfg/DFGGraph.cpp:
1273         (JSC::DFG::Graph::methodOfGettingAValueProfileFor):
1274         * jit/JIT.cpp:
1275         (JSC::JIT::link):
1276         * jit/JITWorklist.cpp:
1277         (JSC::JITWorklist::compileNow):
1278
1279 2016-06-23  Joseph Pecoraro  <pecoraro@apple.com>
1280
1281         Web Inspector: Memory Timeline sometimes shows impossible value for bmalloc size (underflowed)
1282         https://bugs.webkit.org/show_bug.cgi?id=158110
1283         <rdar://problem/26498584>
1284
1285         Reviewed by Andreas Kling.
1286
1287         * heap/Heap.cpp:
1288         (JSC::Heap::willStartCollection):
1289         (JSC::Heap::didFinishCollection):
1290         * heap/Heap.h:
1291         (JSC::Heap::externalMemorySize):
1292         * heap/HeapInlines.h:
1293         (JSC::Heap::reportExternalMemoryVisited):
1294         Keep count of external memory we visit.
1295
1296         * heap/SlotVisitor.h:
1297         * heap/SlotVisitorInlines.h:
1298         (JSC::SlotVisitor::reportExternalMemoryVisited):
1299         Report external memory visited like we do extra memory, since
1300         it will be some subset of extra memory that is external.
1301
1302 2016-06-23  Joseph Pecoraro  <pecoraro@apple.com>
1303
1304         Web Inspector: Snapshots should be cleared at some point
1305         https://bugs.webkit.org/show_bug.cgi?id=157907
1306         <rdar://problem/26373610>
1307
1308         Reviewed by Timothy Hatcher.
1309
1310         * heap/HeapSnapshotBuilder.h:
1311         * heap/HeapSnapshotBuilder.cpp:
1312         (JSC::HeapSnapshotBuilder::resetNextAvailableObjectIdentifier):
1313         Provide a way to reset the object identifier counter.
1314
1315         * inspector/agents/InspectorHeapAgent.h:
1316         * inspector/agents/InspectorHeapAgent.cpp:
1317         (Inspector::InspectorHeapAgent::clearHeapSnapshots):
1318         Make clearHeapSnapshots protected, so it can be called from a
1319         a PageHeapAgent on page navigations.
1320
1321 2016-06-22  Saam barati  <sbarati@apple.com>
1322
1323         TypeProfiler and TypeProfilerLog don't play nicely with the concurrent JIT
1324         https://bugs.webkit.org/show_bug.cgi?id=159037
1325         <rdar://problem/26935349>
1326
1327         Reviewed by Benjamin Poulain.
1328
1329         The primary focus of this patch is to make the concurrent
1330         baseline JIT work with the type profiler. We were clearing
1331         the type profiler log on the background baseline compiler
1332         thread which lead to bad things happening. This patch fixes
1333         this by processing the log before we launch the compile on
1334         a background thread.
1335
1336         Secondly, I audited the type profiler code inside the DFG,
1337         and found that we were doing some racy things. I haven't
1338         seen any crashes because of these things, but it is possible
1339         that they exist. We were grabbing a RefPtr to a TypeSet,
1340         even though TypeSet was RefCounted and not ThreadSafeRefCounted.
1341         This patch makes TypeSet ThreadSafeRefCounted. We were
1342         also copying a StructureSet while the execution thread could
1343         be augmenting the StructureSet. This patch puts changes to 
1344         TypeSet's StructureSet behind a ConcurrentJITLock.
1345
1346         I've also added two more large running tests that run with the
1347         type profiler enabled. These are here just to catch any major bugs
1348         in the type profiler implementation.
1349
1350         * jit/JIT.cpp:
1351         (JSC::JIT::compileWithoutLinking):
1352         (JSC::JIT::privateCompile):
1353         (JSC::JIT::privateCompileExceptionHandlers):
1354         (JSC::JIT::doMainThreadPreparationBeforeCompile):
1355         (JSC::JIT::frameRegisterCountFor):
1356         * jit/JIT.h:
1357         (JSC::JIT::compile):
1358         * jit/JITWorklist.cpp:
1359         (JSC::JITWorklist::Plan::Plan):
1360         (JSC::JITWorklist::Plan::compileInThread):
1361         * runtime/TypeSet.cpp:
1362         (JSC::TypeSet::addTypeInformation):
1363         (JSC::TypeSet::invalidateCache):
1364         * runtime/TypeSet.h:
1365         (JSC::TypeSet::create):
1366         (JSC::TypeSet::isEmpty):
1367         (JSC::TypeSet::seenTypes):
1368         (JSC::TypeSet::structureSet):
1369         * tests/typeProfiler/deltablue-for-of.js: Added.
1370         * tests/typeProfiler/getter-richards.js: Added.
1371
1372 2016-06-22  Keith Miller  <keith_miller@apple.com>
1373
1374         We should have a DFG intrinsic that checks if a value is a TypedArrayView
1375         https://bugs.webkit.org/show_bug.cgi?id=159048
1376
1377         Reviewed by Saam Barati.
1378
1379         This patch adds a new DFG Intrinsic that checks if a value is a TypedArrayView.
1380         The intrinsic, IsTypedArrayView, works in the same way that the other Is<insert-type>
1381         DFG nodes work. Additionally, a new builtin function isTypedArrayView has been added.
1382         These changes are needed to fix regressions in %TypedArray%.prototype.subarray.
1383
1384         * builtins/BuiltinNames.h:
1385         * dfg/DFGAbstractInterpreterInlines.h:
1386         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1387         * dfg/DFGByteCodeParser.cpp:
1388         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
1389         * dfg/DFGClobberize.h:
1390         (JSC::DFG::clobberize):
1391         * dfg/DFGDoesGC.cpp:
1392         (JSC::DFG::doesGC):
1393         * dfg/DFGFixupPhase.cpp:
1394         (JSC::DFG::FixupPhase::fixupNode):
1395         * dfg/DFGNodeType.h:
1396         * dfg/DFGPredictionPropagationPhase.cpp:
1397         * dfg/DFGSafeToExecute.h:
1398         (JSC::DFG::safeToExecute):
1399         * dfg/DFGSpeculativeJIT.cpp:
1400         (JSC::DFG::SpeculativeJIT::compileIsTypedArrayView):
1401         * dfg/DFGSpeculativeJIT.h:
1402         * dfg/DFGSpeculativeJIT32_64.cpp:
1403         (JSC::DFG::SpeculativeJIT::compile):
1404         * dfg/DFGSpeculativeJIT64.cpp:
1405         (JSC::DFG::SpeculativeJIT::compile):
1406         * ftl/FTLCapabilities.cpp:
1407         (JSC::FTL::canCompile):
1408         * ftl/FTLLowerDFGToB3.cpp:
1409         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1410         (JSC::FTL::DFG::LowerDFGToB3::compileIsTypedArrayView):
1411         (JSC::FTL::DFG::LowerDFGToB3::isTypedArrayView):
1412         * runtime/Intrinsic.h:
1413         * runtime/JSGlobalObject.cpp:
1414         (JSC::JSGlobalObject::init):
1415         * runtime/JSTypedArrayViewPrototype.cpp:
1416         (JSC::typedArrayViewPrivateFuncIsTypedArrayView):
1417         * runtime/JSTypedArrayViewPrototype.h:
1418         * tests/stress/istypedarrayview-intrinsic.js: Added.
1419         (makeFn):
1420         (typedArrays.forEach):
1421         (let.test):
1422         (test):
1423
1424 2016-06-21  Anders Carlsson  <andersca@apple.com>
1425
1426         Fix build.
1427
1428         * Configurations/FeatureDefines.xcconfig:
1429
1430 2016-06-21  Geoffrey Garen  <ggaren@apple.com>
1431
1432         Options::useImmortalObjects is not safe for conservative GC
1433         https://bugs.webkit.org/show_bug.cgi?id=158999
1434
1435         Reviewed by Geoffrey Garen.
1436
1437         useImmortalObjects set the mark bit to keep an object from being
1438         reallocated. This had the negative side-effect of convincing the
1439         conservative marker that the object was a valid and live cell, which
1440         would cause us to visit garbage.
1441
1442         * heap/Heap.cpp:
1443         (JSC::Heap::didFinishCollection):
1444         (JSC::Heap::resumeCompilerThreads):
1445         (JSC::Heap::setFullActivityCallback):
1446         (JSC::Heap::markDeadObjects): Deleted.
1447         * heap/Heap.h: Don't set the mark bit on a dead object. That's a bug in
1448         a conservative GC.
1449
1450         * heap/MarkedAllocator.cpp:
1451         (JSC::MarkedAllocator::retire): New helper.
1452
1453         (JSC::MarkedAllocator::reset): Automatically retire old blocks when
1454         we're doing the immortal objects thing. This has the effect of
1455         preserving memory for debugging because we never recycle a previously
1456         allocated block.
1457
1458 2016-06-21  Anders Carlsson  <andersca@apple.com>
1459
1460         Begin moving the Apple Pay code to the open source repository
1461         https://bugs.webkit.org/show_bug.cgi?id=158998
1462
1463         Reviewed by Tim Horton.
1464
1465         * Configurations/FeatureDefines.xcconfig:
1466         Add ENABLE_APPLE_PAY.
1467
1468 2016-06-21  Saam Barati  <sbarati@apple.com>
1469
1470         CodeBlock::shrinkToFit is racy
1471         https://bugs.webkit.org/show_bug.cgi?id=158994
1472         <rdar://problem/26920212>
1473
1474         Reviewed by Filip Pizlo.
1475
1476         To see why this is racy, consider the following scenario:
1477         - CodeBlock A is link()ing its baseline compile.
1478         - CodeBlock B is inlining A, and asks A for a result profile in DFGBytecodeParser.
1479         - The race occurs when the link() step of the baseline compile calls shrinkToFit
1480           on its m_resultProfiles field without grabbing a lock. This leads to a bad
1481           time because the DFG compile will be reading from that vector as it's getting
1482           changed by the baseline link() method.
1483
1484         This race has always existed, though the move to a concurrent baseline
1485         JIT has made it more likely to occur. The solution is to have CodeBlock::shrinkToFit
1486         grab its lock before shrinking the vector.
1487
1488         * bytecode/CodeBlock.cpp:
1489         (JSC::CodeBlock::shrinkToFit):
1490
1491 2016-06-21  David Kilzer  <ddkilzer@apple.com>
1492
1493         Migrate testair & testb3 settings from Xcode project to ToolExecutable.xcconfig
1494         <https://webkit.org/b/158989>
1495
1496         Reviewed by Andy Estes.
1497
1498         * Configurations/ToolExecutable.xcconfig:
1499         (CODE_SIGN_ENTITLEMENTS_ios_testair): Add from Xcode project.
1500         * JavaScriptCore.xcodeproj/project.pbxproj:
1501         (CODE_SIGN_ENTITLEMENTS_ios_testair): Move to
1502         ToolExecutable.xcconfig.
1503         (PRODUCT_NAME): Remove.  This variable is already set for both
1504         testair and testb3 since those build configurations use
1505         ToolExecutable.xcconfig as a base.
1506
1507 2016-06-21  Saam Barati  <sbarati@apple.com>
1508
1509         LLInt doesn't throw stack exception overflow from parent frame
1510         https://bugs.webkit.org/show_bug.cgi?id=158962
1511         <rdar://problem/26902188>
1512
1513         Reviewed by Filip Pizlo.
1514
1515         All JIT tiers will throw stack overflow exceptions from the parent frame.
1516         The LLInt, on the other hand, did not use to. I've changed the LLInt to be
1517         consistent with the JITs. The reason I found this bug is because we had a
1518         test that would give different results depending on if the function was compiled
1519         in the baseline or the LLInt. Since Filip recently landed the concurrent baseline
1520         JIT patch, this otherwise deterministic test became dependent on it being compiled
1521         in the LLInt or one of the JIT tiers. I've added a new test that is deterministic
1522         because it runs the test with --useJIT=false.
1523
1524         * llint/LLIntSlowPaths.cpp:
1525         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1526         * tests/stress/llint-stack-overflow-location.js: Added.
1527         (stackTraceDescription):
1528         (foo):
1529         (catch):
1530
1531 2016-06-21  David Kilzer  <ddkilzer@apple.com>
1532
1533         CODE_SIGN_ENTITLEMENTS should be applied to iOS Simulator builds
1534         <https://webkit.org/b/158990>
1535         <rdar://problem/26906273>
1536
1537         Reviewed by Dan Bernstein.
1538
1539         * Configurations/JSC.xcconfig:
1540         (CODE_SIGN_ENTITLEMENTS): Change [sdk=iphoneos*] to
1541         [sdk=iphone*] to apply setting to iOS Simulator as well.
1542         * Configurations/ToolExecutable.xcconfig:
1543         (CODE_SIGN_ENTITLEMENTS): Ditto.
1544
1545 2016-06-21  Keith Miller  <keith_miller@apple.com>
1546
1547         It should be easy to add a private global helper function for builtins
1548         https://bugs.webkit.org/show_bug.cgi?id=158893
1549
1550         Reviewed by Mark Lam.
1551
1552         This patch does two things. First it moves all the builtin names
1553         out of CommonIdentifiers and into BuiltinNames. This means that
1554         adding a new function to the Builtins does not require rebuilding
1555         all of JavaScriptCore. This patch also adds a new decorator to our
1556         builtins @privateGlobal that will automatically put the function
1557         on the global object. The name of the property will be the same as
1558         the private name of the function.
1559
1560         This patch, also, removes the JSArrayIterator.h/.cpp files
1561         as they no longer appear to be used in any real way. Finally,
1562         the builtins tests have been rebaselined. It appears this has
1563         not been done for a while so the expected files contain other
1564         changes.
1565
1566         * CMakeLists.txt:
1567         * JavaScriptCore.xcodeproj/project.pbxproj:
1568         * Scripts/builtins/builtins_generate_combined_header.py:
1569         (BuiltinsCombinedHeaderGenerator.generate_output):
1570         (generate_section_for_code_name_macro):
1571         (generate_section_for_global_private_code_name_macro):
1572         * Scripts/builtins/builtins_model.py:
1573         (BuiltinFunction.__init__):
1574         (BuiltinFunction.fromString):
1575         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
1576         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
1577         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
1578         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
1579         * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
1580         * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
1581         * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
1582         * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
1583         * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
1584         * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
1585         * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
1586         * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
1587         * builtins/ArrayIteratorPrototype.js:
1588         * builtins/ArrayPrototype.js:
1589         * builtins/BuiltinNames.h:
1590         * builtins/GeneratorPrototype.js:
1591         * builtins/GlobalObject.js:
1592         * builtins/PromiseOperations.js:
1593         * builtins/RegExpPrototype.js:
1594         * builtins/StringPrototype.js:
1595         * bytecode/BytecodeIntrinsicRegistry.cpp:
1596         * bytecompiler/BytecodeGenerator.cpp:
1597         (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
1598         (JSC::BytecodeGenerator::expectedFunctionForIdentifier):
1599         (JSC::BytecodeGenerator::emitGetTemplateObject):
1600         (JSC::BytecodeGenerator::emitLoadNewTargetFromArrowFunctionLexicalEnvironment):
1601         (JSC::BytecodeGenerator::emitLoadDerivedConstructorFromArrowFunctionLexicalEnvironment):
1602         (JSC::BytecodeGenerator::emitPutNewTargetToArrowFunctionContextScope):
1603         (JSC::BytecodeGenerator::emitPutDerivedConstructorToArrowFunctionContextScope):
1604         (JSC::BytecodeGenerator::emitGeneratorStateChange):
1605         * bytecompiler/NodesCodegen.cpp:
1606         (JSC::emitHomeObjectForCallee):
1607         (JSC::emitPutHomeObject):
1608         (JSC::FunctionNode::emitBytecode):
1609         * dfg/DFGOperations.cpp:
1610         * inspector/JSInjectedScriptHost.cpp:
1611         (Inspector::JSInjectedScriptHost::subtype):
1612         (Inspector::JSInjectedScriptHost::getInternalProperties): Deleted.
1613         * parser/Lexer.cpp:
1614         (JSC::Lexer<LChar>::parseIdentifier):
1615         (JSC::Lexer<UChar>::parseIdentifier):
1616         * parser/Nodes.h:
1617         * parser/Parser.cpp:
1618         (JSC::Parser<LexerType>::createGeneratorParameters):
1619         (JSC::Parser<LexerType>::parseExportDeclaration):
1620         * runtime/ArrayIteratorPrototype.cpp:
1621         * runtime/ArrayIteratorPrototype.h:
1622         * runtime/ArrayPrototype.cpp:
1623         * runtime/CommonIdentifiers.cpp:
1624         (JSC::CommonIdentifiers::CommonIdentifiers): Deleted.
1625         * runtime/CommonIdentifiers.h:
1626         * runtime/CommonSlowPaths.cpp:
1627         (JSC::SLOW_PATH_DECL):
1628         * runtime/IntlDateTimeFormat.cpp:
1629         * runtime/IntlDateTimeFormatPrototype.cpp:
1630         (JSC::IntlDateTimeFormatPrototypeGetterFormat):
1631         (JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions):
1632         * runtime/IntlNumberFormatPrototype.cpp:
1633         (JSC::IntlNumberFormatPrototypeGetterFormat):
1634         (JSC::IntlNumberFormatPrototypeFuncResolvedOptions):
1635         * runtime/IntlObjectInlines.h:
1636         (JSC::constructIntlInstanceWithWorkaroundForLegacyIntlConstructor):
1637         * runtime/JSArrayIterator.cpp: Removed.
1638         (JSC::JSArrayIterator::finishCreation): Deleted.
1639         (JSC::JSArrayIterator::kind): Deleted.
1640         (JSC::JSArrayIterator::iteratedValue): Deleted.
1641         * runtime/JSArrayIterator.h: Removed.
1642         (JSC::JSArrayIterator::createStructure): Deleted.
1643         (JSC::JSArrayIterator::create): Deleted.
1644         (JSC::JSArrayIterator::JSArrayIterator): Deleted.
1645         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
1646         (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::finishCreation):
1647         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
1648         * runtime/JSGlobalObject.cpp:
1649         (JSC::JSGlobalObject::init):
1650         * runtime/JSInternalPromise.cpp:
1651         * runtime/JSInternalPromiseDeferred.cpp:
1652         (JSC::JSInternalPromiseDeferred::create):
1653         * runtime/JSPromise.cpp:
1654         (JSC::JSPromise::finishCreation):
1655         (JSC::JSPromise::result):
1656         * runtime/JSPromiseDeferred.cpp:
1657         (JSC::JSPromiseDeferred::create):
1658         * runtime/JSStringIterator.cpp:
1659         (JSC::JSStringIterator::finishCreation):
1660         (JSC::JSStringIterator::iteratedValue):
1661         (JSC::JSStringIterator::clone):
1662         * runtime/MapPrototype.cpp:
1663         (JSC::MapPrototype::finishCreation):
1664         * runtime/ObjectConstructor.cpp:
1665         (JSC::ObjectConstructor::finishCreation):
1666         * runtime/ReflectObject.cpp:
1667         (JSC::ReflectObject::finishCreation):
1668         * runtime/StringPrototype.cpp:
1669         (JSC::StringPrototype::finishCreation):
1670         * runtime/TypedArrayInlines.h:
1671
1672 2016-06-20  Yusuke Suzuki  <utatane.tea@gmail.com>
1673
1674         [JSC] Use bytecode intrinsic to expose Module's loading status to builtin JS
1675         https://bugs.webkit.org/show_bug.cgi?id=158871
1676
1677         Reviewed by Sam Weinig.
1678
1679         Now JSC has bytecode intrinsic system. Use it instead of exposing status values through the loader's properties.
1680
1681         * builtins/ModuleLoaderObject.js:
1682         (newRegistryEntry):
1683         (fulfillFetch):
1684         (fulfillTranslate):
1685         (commitInstantiated):
1686         (requestFetch):
1687         (requestTranslate):
1688         (requestInstantiate):
1689         (requestResolveDependencies.):
1690         (requestResolveDependencies):
1691         (requestLink):
1692         (link):
1693         (provide):
1694         * bytecode/BytecodeIntrinsicRegistry.cpp:
1695         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
1696         * bytecode/BytecodeIntrinsicRegistry.h:
1697         * runtime/ModuleLoaderObject.cpp:
1698         (JSC::ModuleLoaderObject::finishCreation): Deleted.
1699
1700 2016-06-20  Commit Queue  <commit-queue@webkit.org>
1701
1702         Unreviewed, rolling out r202248.
1703         https://bugs.webkit.org/show_bug.cgi?id=158960
1704
1705         breaks builds on the simulator (Requested by keith_mi_ on
1706         #webkit).
1707
1708         Reverted changeset:
1709
1710         "It should be easy to add a private global helper function for
1711         builtins"
1712         https://bugs.webkit.org/show_bug.cgi?id=158893
1713         http://trac.webkit.org/changeset/202248
1714
1715 2016-06-20  Keith Miller  <keith_miller@apple.com>
1716
1717         It should be easy to add a private global helper function for builtins
1718         https://bugs.webkit.org/show_bug.cgi?id=158893
1719
1720         Reviewed by Mark Lam.
1721
1722         This patch does two things. First it moves all the builtin names
1723         out of CommonIdentifiers and into BuiltinNames. This means that
1724         adding a new function to the Builtins does not require rebuilding
1725         all of JavaScriptCore. This patch also adds a new decorator to our
1726         builtins @privateGlobal that will automatically put the function
1727         on the global object. The name of the property will be the same as
1728         the private name of the function.
1729
1730         This patch, also, removes the JSArrayIterator.h/.cpp files
1731         as they no longer appear to be used in any real way. Finally,
1732         the builtins tests have been rebaselined. It appears this has
1733         not been done for a while so the expected files contain other
1734         changes.
1735
1736         * CMakeLists.txt:
1737         * JavaScriptCore.xcodeproj/project.pbxproj:
1738         * Scripts/builtins/builtins_generate_combined_header.py:
1739         (BuiltinsCombinedHeaderGenerator.generate_output):
1740         (generate_section_for_code_name_macro):
1741         (generate_section_for_global_private_code_name_macro):
1742         * Scripts/builtins/builtins_model.py:
1743         (BuiltinFunction.__init__):
1744         (BuiltinFunction.fromString):
1745         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
1746         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
1747         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
1748         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
1749         * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
1750         * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
1751         * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
1752         * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
1753         * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
1754         * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
1755         * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
1756         * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
1757         * builtins/ArrayIteratorPrototype.js:
1758         * builtins/ArrayPrototype.js:
1759         * builtins/BuiltinNames.h:
1760         * builtins/GeneratorPrototype.js:
1761         * builtins/GlobalObject.js:
1762         * builtins/PromiseOperations.js:
1763         * builtins/RegExpPrototype.js:
1764         * builtins/StringPrototype.js:
1765         * bytecode/BytecodeIntrinsicRegistry.cpp:
1766         * bytecompiler/BytecodeGenerator.cpp:
1767         (JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
1768         (JSC::BytecodeGenerator::expectedFunctionForIdentifier):
1769         (JSC::BytecodeGenerator::emitGetTemplateObject):
1770         (JSC::BytecodeGenerator::emitLoadNewTargetFromArrowFunctionLexicalEnvironment):
1771         (JSC::BytecodeGenerator::emitLoadDerivedConstructorFromArrowFunctionLexicalEnvironment):
1772         (JSC::BytecodeGenerator::emitPutNewTargetToArrowFunctionContextScope):
1773         (JSC::BytecodeGenerator::emitPutDerivedConstructorToArrowFunctionContextScope):
1774         (JSC::BytecodeGenerator::emitGeneratorStateChange):
1775         * bytecompiler/NodesCodegen.cpp:
1776         (JSC::emitHomeObjectForCallee):
1777         (JSC::emitPutHomeObject):
1778         (JSC::FunctionNode::emitBytecode):
1779         * dfg/DFGOperations.cpp:
1780         * inspector/JSInjectedScriptHost.cpp:
1781         (Inspector::JSInjectedScriptHost::subtype):
1782         (Inspector::JSInjectedScriptHost::getInternalProperties): Deleted.
1783         * parser/Lexer.cpp:
1784         (JSC::Lexer<LChar>::parseIdentifier):
1785         (JSC::Lexer<UChar>::parseIdentifier):
1786         * parser/Nodes.h:
1787         * parser/Parser.cpp:
1788         (JSC::Parser<LexerType>::createGeneratorParameters):
1789         (JSC::Parser<LexerType>::parseExportDeclaration):
1790         * runtime/ArrayIteratorPrototype.cpp:
1791         * runtime/ArrayIteratorPrototype.h:
1792         * runtime/ArrayPrototype.cpp:
1793         * runtime/CommonIdentifiers.cpp:
1794         (JSC::CommonIdentifiers::CommonIdentifiers): Deleted.
1795         * runtime/CommonIdentifiers.h:
1796         * runtime/CommonSlowPaths.cpp:
1797         (JSC::SLOW_PATH_DECL):
1798         * runtime/IntlDateTimeFormat.cpp:
1799         * runtime/IntlDateTimeFormatPrototype.cpp:
1800         (JSC::IntlDateTimeFormatPrototypeGetterFormat):
1801         (JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions):
1802         * runtime/IntlNumberFormatPrototype.cpp:
1803         (JSC::IntlNumberFormatPrototypeGetterFormat):
1804         (JSC::IntlNumberFormatPrototypeFuncResolvedOptions):
1805         * runtime/IntlObjectInlines.h:
1806         (JSC::constructIntlInstanceWithWorkaroundForLegacyIntlConstructor):
1807         * runtime/JSArrayIterator.cpp: Removed.
1808         (JSC::JSArrayIterator::finishCreation): Deleted.
1809         (JSC::JSArrayIterator::kind): Deleted.
1810         (JSC::JSArrayIterator::iteratedValue): Deleted.
1811         * runtime/JSArrayIterator.h: Removed.
1812         (JSC::JSArrayIterator::createStructure): Deleted.
1813         (JSC::JSArrayIterator::create): Deleted.
1814         (JSC::JSArrayIterator::JSArrayIterator): Deleted.
1815         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
1816         (JSC::JSGenericTypedArrayViewConstructor<ViewClass>::finishCreation):
1817         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
1818         * runtime/JSGlobalObject.cpp:
1819         (JSC::JSGlobalObject::init):
1820         * runtime/JSInternalPromise.cpp:
1821         * runtime/JSInternalPromiseDeferred.cpp:
1822         (JSC::JSInternalPromiseDeferred::create):
1823         * runtime/JSPromise.cpp:
1824         (JSC::JSPromise::finishCreation):
1825         (JSC::JSPromise::result):
1826         * runtime/JSPromiseDeferred.cpp:
1827         (JSC::JSPromiseDeferred::create):
1828         * runtime/JSStringIterator.cpp:
1829         (JSC::JSStringIterator::finishCreation):
1830         (JSC::JSStringIterator::iteratedValue):
1831         (JSC::JSStringIterator::clone):
1832         * runtime/MapPrototype.cpp:
1833         (JSC::MapPrototype::finishCreation):
1834         * runtime/ObjectConstructor.cpp:
1835         (JSC::ObjectConstructor::finishCreation):
1836         * runtime/ReflectObject.cpp:
1837         (JSC::ReflectObject::finishCreation):
1838         * runtime/StringPrototype.cpp:
1839         (JSC::StringPrototype::finishCreation):
1840         * runtime/TypedArrayInlines.h:
1841
1842 2016-06-20  Filip Pizlo  <fpizlo@apple.com>
1843
1844         LLInt64 Float64 get_by_val doesn't purify NaN
1845         https://bugs.webkit.org/show_bug.cgi?id=158956
1846
1847         Reviewed by Michael Saboff.
1848
1849         * llint/LowLevelInterpreter64.asm: Fix the bug.
1850         * tests/stress/float64-array-nan-inlined.js: Make this test also run in LLInt-only mode to catch this bug.
1851
1852 2016-06-20  Keith Rollin  <krollin@apple.com>
1853
1854         Remove RefPtr::release() and change calls sites to use WTFMove()
1855         https://bugs.webkit.org/show_bug.cgi?id=158369
1856
1857         Reviewed by Chris Dumez.
1858
1859         RefPtr::release() releases its managed pointer awkwardly. It's more
1860         direct and clearer to use WTFMove to transfer ownership of the managed
1861         pointer.
1862
1863         As part of this cleanup, also change a lot of explicit data types to
1864         'auto'.
1865
1866         * API/JSObjectRef.cpp:
1867         (JSClassCreate):
1868         * API/JSScriptRef.cpp:
1869         * API/JSValueRef.cpp:
1870         (JSValueToStringCopy):
1871         * bytecompiler/StaticPropertyAnalyzer.h:
1872         (JSC::StaticPropertyAnalyzer::newObject):
1873         (JSC::StaticPropertyAnalyzer::mov):
1874         * debugger/DebuggerCallFrame.cpp:
1875         (JSC::DebuggerCallFrame::invalidate):
1876         * dfg/DFGJITCompiler.cpp:
1877         (JSC::DFG::JITCompiler::compile):
1878         (JSC::DFG::JITCompiler::compileFunction):
1879         * inspector/InspectorValues.cpp:
1880         (Inspector::InspectorValue::parseJSON):
1881         * inspector/agents/InspectorAgent.cpp:
1882         (Inspector::InspectorAgent::activateExtraDomain):
1883         (Inspector::InspectorAgent::activateExtraDomains):
1884         * inspector/agents/InspectorDebuggerAgent.cpp:
1885         (Inspector::InspectorDebuggerAgent::breakpointActionProbe):
1886         * inspector/remote/RemoteInspector.mm:
1887         (Inspector::RemoteInspector::receivedSetupMessage):
1888         * jit/Repatch.cpp:
1889         (JSC::linkPolymorphicCall):
1890         * runtime/GenericTypedArrayViewInlines.h:
1891         (JSC::GenericTypedArrayView<Adaptor>::create):
1892         (JSC::GenericTypedArrayView<Adaptor>::createUninitialized):
1893         * runtime/JSArrayBufferConstructor.cpp:
1894         (JSC::constructArrayBuffer):
1895         * runtime/PropertyNameArray.h:
1896         (JSC::PropertyNameArray::releaseData):
1897         * runtime/Structure.cpp:
1898         (JSC::Structure::toStructureShape):
1899         * runtime/TypeSet.cpp:
1900         (JSC::StructureShape::merge):
1901         * tools/FunctionOverrides.cpp:
1902         (JSC::initializeOverrideInfo):
1903
1904 2016-06-20  Joseph Pecoraro  <pecoraro@apple.com>
1905
1906         Web Inspector: console.profile should use the new Sampling Profiler
1907         https://bugs.webkit.org/show_bug.cgi?id=153499
1908         <rdar://problem/24352431>
1909
1910         Reviewed by Timothy Hatcher.
1911
1912         Currently console.profile/profileEnd behave slightly differently
1913         between JSContext and Web inspection. Unifying will be part of:
1914         <https://webkit.org/b/158753> Generalize the concept of Instruments on the backend
1915
1916         Both JSContext and Web inspection keep track of active
1917         profiles started and stopped via console.profile/profileEnd.
1918
1919         JSContext inspection sends its programmatic start/stop
1920         via the ScriptProfiler domain.
1921
1922         Web inspection sends its programmatic start/stop
1923         via the Timeline domain, and also will start/stop backend
1924         list of Instruments.
1925
1926         The functional differences between these is that for JSContext
1927         inspection, console.profile only starts/stops the ScriptProfiler
1928         domain, and does not auto-start other instruments. This isn't really
1929         a problem right now given the instruments available for JSContext
1930         inspection; but it will be nice to unify as we add more instruments.
1931         Also, JSContext inspection won't have "Profile (name)" records in
1932         its Events view, since those are currently generated only by the
1933         Web's Timeline domain.
1934
1935         * inspector/protocol/ScriptProfiler.json:
1936         * inspector/protocol/Timeline.json:
1937         Events to inform the frontend of programmatic start/stop.
1938
1939         * debugger/Debugger.h:
1940         * inspector/agents/InspectorDebuggerAgent.cpp:
1941         (Inspector::InspectorDebuggerAgent::breakpointsActive):
1942         (Inspector::InspectorDebuggerAgent::isPaused):
1943         * inspector/agents/InspectorDebuggerAgent.h:
1944         Expose breakpoints active state, since programmatic recording
1945         will temporarily disabled breakpoints if needed.
1946
1947         * inspector/JSGlobalObjectConsoleClient.cpp:
1948         (Inspector::JSGlobalObjectConsoleClient::JSGlobalObjectConsoleClient):
1949         (Inspector::JSGlobalObjectConsoleClient::profile):
1950         (Inspector::JSGlobalObjectConsoleClient::profileEnd):
1951         (Inspector::JSGlobalObjectConsoleClient::startConsoleProfile):
1952         (Inspector::JSGlobalObjectConsoleClient::stopConsoleProfile):
1953         * inspector/JSGlobalObjectConsoleClient.h:
1954         * inspector/JSGlobalObjectInspectorController.cpp:
1955         (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
1956         * inspector/agents/InspectorScriptProfilerAgent.cpp:
1957         (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStarted):
1958         (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStopped):
1959         * inspector/agents/InspectorScriptProfilerAgent.h:
1960         JSContext implementation of console.profile/profileEnd.
1961
1962 2016-06-19  Saam Barati  <sbarati@apple.com>
1963
1964         We should be able to generate more types of ICs inline
1965         https://bugs.webkit.org/show_bug.cgi?id=158719
1966         <rdar://problem/26825641>
1967
1968         Reviewed by Filip Pizlo.
1969
1970         This patch changes how we emit code for *byId ICs inline.
1971         We no longer keep data labels to patch structure checks, etc.
1972         Instead, we just regenerate the entire IC into a designated
1973         region of code that the Baseline/DFG/FTL JIT will emit inline.
1974         This makes it much simpler to patch inline ICs. All that's
1975         needed to patch an inline IC is to memcpy the code from
1976         a macro assembler inline using LinkBuffer. This architecture
1977         will be easy to extend into other forms of ICs, such as one
1978         for add, in the future.
1979
1980         To support this change, I've reworked the fields inside
1981         StructureStubInfo. It now has one field that is the CodeLocationLabel 
1982         of the start of the inline IC. Then it has a few ints that track deltas
1983         to other locations in the IC such as the slow path start, slow path call, the
1984         ICs 'done' location. We used to perform math on these ints in a bunch of different
1985         places. I've consolidated that math into methods inside StructureStubInfo.
1986
1987         To generate inline ICs, I've implemented a new class called InlineAccess.
1988         InlineAccess is stateless: it just has a bunch of static methods for
1989         generating code into the inline region specified by StructureStubInfo.
1990         Repatch will now decide when it wants to generate such an inline
1991         IC, and it will ask InlineAccess to do so.
1992
1993         I've implemented three types of inline ICs to begin with (extending
1994         this in the future should be easy):
1995         - Self property loads (both inline and out of line offsets).
1996         - Self property replace (both inline and out of line offsets).
1997         - Array length on specific array types.
1998         (An easy extension would be to implement JSString length.)
1999
2000         To know how much inline space to reserve, I've implemented a
2001         method that stubs out the various inline cache shapes and 
2002         dumps their size. This is used to determine how much space
2003         to save inline. When InlineAccess ends up generating more
2004         code than can fit inline, we will fall back to generating
2005         code with PolymorphicAccess instead.
2006
2007         To make generating code into already allocated executable memory
2008         efficient, I've made AssemblerData have 128 bytes of inline storage.
2009         This saves us a malloc when splatting code into the inline region.
2010
2011         This patch also tidies up LinkBuffer's API for generating
2012         into already allocated executable memory. Now, when generating
2013         code that has less size than the already allocated space, LinkBuffer
2014         will fill the extra space with nops. Also, if branch compaction shrinks
2015         the code, LinkBuffer will add a nop sled at the end of the shrunken
2016         code to take up the entire allocated size.
2017
2018         This looks like it could be a 1% octane progression.
2019
2020         * CMakeLists.txt:
2021         * JavaScriptCore.xcodeproj/project.pbxproj:
2022         * assembler/ARM64Assembler.h:
2023         (JSC::ARM64Assembler::nop):
2024         (JSC::ARM64Assembler::fillNops):
2025         * assembler/ARMv7Assembler.h:
2026         (JSC::ARMv7Assembler::nopw):
2027         (JSC::ARMv7Assembler::nopPseudo16):
2028         (JSC::ARMv7Assembler::nopPseudo32):
2029         (JSC::ARMv7Assembler::fillNops):
2030         (JSC::ARMv7Assembler::dmbSY):
2031         * assembler/AbstractMacroAssembler.h:
2032         (JSC::AbstractMacroAssembler::addLinkTask):
2033         (JSC::AbstractMacroAssembler::emitNops):
2034         (JSC::AbstractMacroAssembler::AbstractMacroAssembler):
2035         * assembler/AssemblerBuffer.h:
2036         (JSC::AssemblerData::AssemblerData):
2037         (JSC::AssemblerData::operator=):
2038         (JSC::AssemblerData::~AssemblerData):
2039         (JSC::AssemblerData::buffer):
2040         (JSC::AssemblerData::grow):
2041         (JSC::AssemblerData::isInlineBuffer):
2042         (JSC::AssemblerBuffer::AssemblerBuffer):
2043         (JSC::AssemblerBuffer::ensureSpace):
2044         (JSC::AssemblerBuffer::codeSize):
2045         (JSC::AssemblerBuffer::setCodeSize):
2046         (JSC::AssemblerBuffer::label):
2047         (JSC::AssemblerBuffer::debugOffset):
2048         (JSC::AssemblerBuffer::releaseAssemblerData):
2049         * assembler/LinkBuffer.cpp:
2050         (JSC::LinkBuffer::copyCompactAndLinkCode):
2051         (JSC::LinkBuffer::linkCode):
2052         (JSC::LinkBuffer::allocate):
2053         (JSC::LinkBuffer::performFinalization):
2054         (JSC::LinkBuffer::shrink): Deleted.
2055         * assembler/LinkBuffer.h:
2056         (JSC::LinkBuffer::LinkBuffer):
2057         (JSC::LinkBuffer::debugAddress):
2058         (JSC::LinkBuffer::size):
2059         (JSC::LinkBuffer::wasAlreadyDisassembled):
2060         (JSC::LinkBuffer::didAlreadyDisassemble):
2061         (JSC::LinkBuffer::applyOffset):
2062         (JSC::LinkBuffer::code):
2063         * assembler/MacroAssemblerARM64.h:
2064         (JSC::MacroAssemblerARM64::patchableBranch32):
2065         (JSC::MacroAssemblerARM64::patchableBranch64):
2066         * assembler/MacroAssemblerARMv7.h:
2067         (JSC::MacroAssemblerARMv7::patchableBranch32):
2068         (JSC::MacroAssemblerARMv7::patchableBranchPtrWithPatch):
2069         * assembler/X86Assembler.h:
2070         (JSC::X86Assembler::nop):
2071         (JSC::X86Assembler::fillNops):
2072         * bytecode/CodeBlock.cpp:
2073         (JSC::CodeBlock::printGetByIdCacheStatus):
2074         * bytecode/InlineAccess.cpp: Added.
2075         (JSC::InlineAccess::dumpCacheSizesAndCrash):
2076         (JSC::linkCodeInline):
2077         (JSC::InlineAccess::generateSelfPropertyAccess):
2078         (JSC::getScratchRegister):
2079         (JSC::hasFreeRegister):
2080         (JSC::InlineAccess::canGenerateSelfPropertyReplace):
2081         (JSC::InlineAccess::generateSelfPropertyReplace):
2082         (JSC::InlineAccess::isCacheableArrayLength):
2083         (JSC::InlineAccess::generateArrayLength):
2084         (JSC::InlineAccess::rewireStubAsJump):
2085         * bytecode/InlineAccess.h: Added.
2086         (JSC::InlineAccess::sizeForPropertyAccess):
2087         (JSC::InlineAccess::sizeForPropertyReplace):
2088         (JSC::InlineAccess::sizeForLengthAccess):
2089         * bytecode/PolymorphicAccess.cpp:
2090         (JSC::PolymorphicAccess::regenerate):
2091         * bytecode/StructureStubInfo.cpp:
2092         (JSC::StructureStubInfo::initGetByIdSelf):
2093         (JSC::StructureStubInfo::initArrayLength):
2094         (JSC::StructureStubInfo::initPutByIdReplace):
2095         (JSC::StructureStubInfo::deref):
2096         (JSC::StructureStubInfo::aboutToDie):
2097         (JSC::StructureStubInfo::propagateTransitions):
2098         (JSC::StructureStubInfo::containsPC):
2099         * bytecode/StructureStubInfo.h:
2100         (JSC::StructureStubInfo::considerCaching):
2101         (JSC::StructureStubInfo::slowPathCallLocation):
2102         (JSC::StructureStubInfo::doneLocation):
2103         (JSC::StructureStubInfo::slowPathStartLocation):
2104         (JSC::StructureStubInfo::patchableJumpForIn):
2105         (JSC::StructureStubInfo::valueRegs):
2106         * dfg/DFGJITCompiler.cpp:
2107         (JSC::DFG::JITCompiler::link):
2108         * dfg/DFGOSRExitCompilerCommon.cpp:
2109         (JSC::DFG::reifyInlinedCallFrames):
2110         * dfg/DFGSpeculativeJIT32_64.cpp:
2111         (JSC::DFG::SpeculativeJIT::cachedGetById):
2112         * dfg/DFGSpeculativeJIT64.cpp:
2113         (JSC::DFG::SpeculativeJIT::cachedGetById):
2114         * ftl/FTLLowerDFGToB3.cpp:
2115         (JSC::FTL::DFG::LowerDFGToB3::compileIn):
2116         (JSC::FTL::DFG::LowerDFGToB3::getById):
2117         * jit/JITInlineCacheGenerator.cpp:
2118         (JSC::JITByIdGenerator::finalize):
2119         (JSC::JITByIdGenerator::generateFastCommon):
2120         (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
2121         (JSC::JITGetByIdGenerator::generateFastPath):
2122         (JSC::JITPutByIdGenerator::JITPutByIdGenerator):
2123         (JSC::JITPutByIdGenerator::generateFastPath):
2124         (JSC::JITPutByIdGenerator::slowPathFunction):
2125         (JSC::JITByIdGenerator::generateFastPathChecks): Deleted.
2126         * jit/JITInlineCacheGenerator.h:
2127         (JSC::JITByIdGenerator::reportSlowPathCall):
2128         (JSC::JITByIdGenerator::slowPathBegin):
2129         (JSC::JITByIdGenerator::slowPathJump):
2130         (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
2131         * jit/JITPropertyAccess.cpp:
2132         (JSC::JIT::emitGetByValWithCachedId):
2133         (JSC::JIT::emit_op_try_get_by_id):
2134         (JSC::JIT::emit_op_get_by_id):
2135         * jit/JITPropertyAccess32_64.cpp:
2136         (JSC::JIT::emitGetByValWithCachedId):
2137         (JSC::JIT::emit_op_try_get_by_id):
2138         (JSC::JIT::emit_op_get_by_id):
2139         * jit/Repatch.cpp:
2140         (JSC::repatchCall):
2141         (JSC::tryCacheGetByID):
2142         (JSC::repatchGetByID):
2143         (JSC::appropriateGenericPutByIdFunction):
2144         (JSC::tryCachePutByID):
2145         (JSC::repatchPutByID):
2146         (JSC::tryRepatchIn):
2147         (JSC::repatchIn):
2148         (JSC::linkSlowFor):
2149         (JSC::resetGetByID):
2150         (JSC::resetPutByID):
2151         (JSC::resetIn):
2152         (JSC::repatchByIdSelfAccess): Deleted.
2153         (JSC::resetGetByIDCheckAndLoad): Deleted.
2154         (JSC::resetPutByIDCheckAndLoad): Deleted.
2155         (JSC::replaceWithJump): Deleted.
2156
2157 2016-06-19  Filip Pizlo  <fpizlo@apple.com>
2158
2159         REGRESSION(concurrent baseline JIT): Kraken/ai-astar runs 20% slower
2160         https://bugs.webkit.org/show_bug.cgi?id=158906
2161
2162         Reviewed by Benjamin Poulain.
2163         
2164         The concurrent baseline JIT was a 2-3% progression on JSBench, possibly a 1% progression
2165         on PLT3, but a 2-5% regression on Kraken. This patch fixes the Kraken regression without
2166         affecting the other tests.
2167         
2168         The problem is that Kraken/ai-astar's initialization code had a ginormous piece of init
2169         code that took about 16ms to compile in baseline. There's no good way to avoid letting it
2170         tier-up into baseline since it has a compute loop. The time it takes to run this code is
2171         never measured. The concurrent baseline JIT caused us to schedule the compilation of this
2172         huge code rather than doing it eagerly. This meant that after initialization was done and
2173         we started actually running real stuff, all of the real stuff's compiles would be convoyed
2174         behind this super-expensive baseline compile. Note that DFG and FTL compiles convoy behind
2175         baseline compiles, since you can't schedule a DFG compile for a code block until that code
2176         block is in baseline.
2177         
2178         This uses the simplest fix: if we are thinking about scheduling some compile and the
2179         thread is busy, do the compile on the main thread instead. This doesn't completely
2180         eliminate the ai-astar regression (we still have a 4% regression on that test) but it now
2181         results in concurrent baseline JIT being an overall progression on Kraken as a whole (1%
2182         on my machine). This is because concurrent baseline appears to help on other tests.
2183
2184         In the future, we could fix this even better by allowing the JITWorklist to spawn more
2185         threads or by being smarter about baseline compilation. I think it's nasty that if a giant
2186         piece of initialization code ends in a compute loop, we compile all of the code instead of
2187         just the loop. It's also gross that a constant-like object creation expression will result
2188         in so much code. It would result in less code if we allowed ourselves to do a bit more
2189         static reasoning about object literals.
2190         
2191         But for now, I think that this is a great way to recover the Kraken regression while still
2192         keeping the other progressions from concurrent baseline.
2193
2194         * jit/JITWorklist.cpp:
2195         (JSC::JITWorklist::Plan::Plan):
2196         (JSC::JITWorklist::Plan::compileInThread):
2197         (JSC::JITWorklist::Plan::finalize):
2198         (JSC::JITWorklist::Plan::codeBlock):
2199         (JSC::JITWorklist::Plan::isFinishedCompiling):
2200         (JSC::JITWorklist::Plan::compileNow):
2201         (JSC::JITWorklist::JITWorklist):
2202         (JSC::JITWorklist::compileLater):
2203         (JSC::JITWorklist::compileNow):
2204         (JSC::JITWorklist::runThread):
2205         (JSC::JITWorklist::Plan::isFinalized): Deleted.
2206         * jit/JITWorklist.h:
2207
2208 2016-06-17  Commit Queue  <commit-queue@webkit.org>
2209
2210         Unreviewed, rolling out r202152.
2211         https://bugs.webkit.org/show_bug.cgi?id=158897
2212
2213         The new test is very unstable, timing out frequently
2214         (Requested by ap on #webkit).
2215
2216         Reverted changeset:
2217
2218         "Web Inspector: console.profile should use the new Sampling
2219         Profiler"
2220         https://bugs.webkit.org/show_bug.cgi?id=153499
2221         http://trac.webkit.org/changeset/202152
2222
2223 2016-06-14  Filip Pizlo  <fpizlo@apple.com>
2224
2225         Baseline JIT should be concurrent
2226         https://bugs.webkit.org/show_bug.cgi?id=158755
2227
2228         Reviewed by Geoffrey Garen.
2229         
2230         This makes the baseline JIT concurrent. We want it to be concurrent because it takes up
2231         about 1% of PLT3 and 10% of JSBench (though the JSBench number might be down from recent
2232         optimizations).
2233         
2234         The idea is really simple: I separated the compile and link phases of JIT::privateCompile(),
2235         and arranged to call the compile phase from another thread. This doesn't reuse the old
2236         DFG::Worklist code, because that code does things we don't need (like compilation plan
2237         cancellation to allow GC to interleave with compilations) and is structured in a way that
2238         would have required more changes to the baseline JIT. Also, I think that code uses the wrong
2239         API, and as a result, clients of that API have a bad time. For example, it's never clear who
2240         has the responsibility of setting the JIT thresholds and the DFG::Worklist goes to great
2241         lengths to try to help its client set those things correctly, but since it doesn't set them
2242         directly, the client then has to have additional complex logic to combine what it learned
2243         from the Worklist and what it knows to set the thresholds. This patch takes a simpler
2244         approach: the JITWorklist takes complete control over scheduling compilations. It's like a
2245         combination of DFG::Worklist and operationOptimize().
2246         
2247         Because the baseline JIT runs quickly, we can take some shortcuts. The JITWorklist requires
2248         that all of its plans complete before a GC begins. This ensures that we don't have to worry
2249         about interactions between the concurrent baseline JIT and the GC.
2250         
2251         I needed to do a bunch of minor changes to the JIT to handle the races that emerged. For
2252         example, I needed to do things to opcodes that read profiling both in the main path code
2253         generator and the slow path one. One trick I used was to create a copy of the instruction
2254         stream and provide that for anyone interested in the original value of the profiles. Most
2255         code still uses the CodeBlock's instruction stream because it may emit JIT code that points
2256         at the stream.
2257         
2258         This also fixes a LLInt bug in prototype caching. This bug was revealed by this change
2259         because more of our LayoutTests now run in LLInt.
2260         
2261         This looks like it might be a ~1% Octane speed-up (on command line) and a ~0.7% PLT3
2262         speed-up. This also looks like a ~2% JSBench speed-up.
2263
2264         * CMakeLists.txt:
2265         * JavaScriptCore.xcodeproj/project.pbxproj:
2266         * debugger/Debugger.cpp:
2267         (JSC::Debugger::setSteppingMode):
2268         (JSC::Debugger::toggleBreakpoint):
2269         (JSC::Debugger::clearBreakpoints):
2270         (JSC::Debugger::clearDebuggerRequests):
2271         * dfg/DFGOSRExitPreparation.cpp:
2272         (JSC::DFG::prepareCodeOriginForOSRExit):
2273         * heap/Heap.cpp:
2274         (JSC::Heap::didFinishIterating):
2275         (JSC::Heap::completeAllJITPlans):
2276         (JSC::Heap::deleteAllCodeBlocks):
2277         (JSC::Heap::collectImpl):
2278         (JSC::Heap::completeAllDFGPlans): Deleted.
2279         * heap/Heap.h:
2280         * heap/HeapInlines.h:
2281         (JSC::Heap::forEachCodeBlock):
2282         * jit/JIT.cpp:
2283         (JSC::JIT::emitNotifyWrite):
2284         (JSC::JIT::privateCompileMainPass):
2285         (JSC::JIT::privateCompileSlowCases):
2286         (JSC::JIT::compileWithoutLinking):
2287         (JSC::JIT::link):
2288         (JSC::JIT::privateCompile):
2289         (JSC::JIT::privateCompileExceptionHandlers):
2290         * jit/JIT.h:
2291         (JSC::JIT::compile):
2292         (JSC::JIT::getSlowCase):
2293         (JSC::JIT::linkSlowCase):
2294         (JSC::JIT::linkDummySlowCase):
2295         * jit/JITInlines.h:
2296         (JSC::JIT::emitTagBool):
2297         (JSC::JIT::originalInstruction):
2298         * jit/JITPropertyAccess32_64.cpp:
2299         (JSC::JIT::emitSlow_op_put_to_scope):
2300         * jit/JITPropertyAccess.cpp:
2301         (JSC::JIT::emitSlow_op_put_by_val):
2302         (JSC::JIT::emit_op_resolve_scope):
2303         (JSC::JIT::emitSlow_op_resolve_scope):
2304         (JSC::JIT::emit_op_get_from_scope):
2305         (JSC::JIT::emitSlow_op_get_from_scope):
2306         (JSC::JIT::emit_op_put_to_scope):
2307         (JSC::JIT::emitSlow_op_put_to_scope):
2308         * jit/JITWorklist.cpp: Added.
2309         (JSC::JITWorklist::Plan::Plan):
2310         (JSC::JITWorklist::Plan::compileInThread):
2311         (JSC::JITWorklist::Plan::finalize):
2312         (JSC::JITWorklist::Plan::codeBlock):
2313         (JSC::JITWorklist::Plan::vm):
2314         (JSC::JITWorklist::Plan::isFinishedCompiling):
2315         (JSC::JITWorklist::Plan::isFinalized):
2316         (JSC::JITWorklist::JITWorklist):
2317         (JSC::JITWorklist::~JITWorklist):
2318         (JSC::JITWorklist::completeAllForVM):
2319         (JSC::JITWorklist::poll):
2320         (JSC::JITWorklist::compileLater):
2321         (JSC::JITWorklist::compileNow):
2322         (JSC::JITWorklist::runThread):
2323         (JSC::JITWorklist::finalizePlans):
2324         (JSC::JITWorklist::instance):
2325         * jit/JITWorklist.h: Added.
2326         * llint/LLIntSlowPaths.cpp:
2327         (JSC::LLInt::jitCompileAndSetHeuristics):
2328         * runtime/CommonSlowPaths.cpp:
2329         (JSC::SLOW_PATH_DECL):
2330         * runtime/CommonSlowPaths.h:
2331         (JSC::CommonSlowPaths::tryCachePutToScopeGlobal):
2332         (JSC::CommonSlowPaths::tryCacheGetFromScopeGlobal):
2333         * runtime/VM.cpp:
2334         (JSC::VM::~VM):
2335
2336 2016-06-16  Joseph Pecoraro  <pecoraro@apple.com>
2337
2338         Web Inspector: console.profile should use the new Sampling Profiler
2339         https://bugs.webkit.org/show_bug.cgi?id=153499
2340         <rdar://problem/24352431>
2341
2342         Reviewed by Timothy Hatcher.
2343
2344         Currently console.profile/profileEnd behave slightly differently
2345         between JSContext and Web inspection. Unifying will be part of:
2346         <https://webkit.org/b/158753> Generalize the concept of Instruments on the backend
2347
2348         Both JSContext and Web inspection keep track of active
2349         profiles started and stopped via console.profile/profileEnd.
2350
2351         JSContext inspection sends its programmatic start/stop
2352         via the ScriptProfiler domain.
2353
2354         Web inspection sends its programmatic start/stop
2355         via the Timeline domain, and also will start/stop backend
2356         list of Instruments.
2357
2358         The functional differences between these is that for JSContext
2359         inspection, console.profile only starts/stops the ScriptProfiler
2360         domain, and does not auto-start other instruments. This isn't really
2361         a problem right now given the instruments available for JSContext
2362         inspection; but it will be nice to unify as we add more instruments.
2363         Also, JSContext inspection won't have "Profile (name)" records in
2364         its Events view, since those are currently generated only by the
2365         Web's Timeline domain.
2366
2367         * inspector/protocol/ScriptProfiler.json:
2368         * inspector/protocol/Timeline.json:
2369         Events to inform the frontend of programmatic start/stop.
2370
2371         * debugger/Debugger.h:
2372         * inspector/agents/InspectorDebuggerAgent.cpp:
2373         (Inspector::InspectorDebuggerAgent::breakpointsActive):
2374         (Inspector::InspectorDebuggerAgent::isPaused):
2375         * inspector/agents/InspectorDebuggerAgent.h:
2376         Expose breakpoints active state, since programmatic recording
2377         will temporarily disabled breakpoints if needed.
2378
2379         * inspector/JSGlobalObjectConsoleClient.cpp:
2380         (Inspector::JSGlobalObjectConsoleClient::JSGlobalObjectConsoleClient):
2381         (Inspector::JSGlobalObjectConsoleClient::profile):
2382         (Inspector::JSGlobalObjectConsoleClient::profileEnd):
2383         (Inspector::JSGlobalObjectConsoleClient::startConsoleProfile):
2384         (Inspector::JSGlobalObjectConsoleClient::stopConsoleProfile):
2385         * inspector/JSGlobalObjectConsoleClient.h:
2386         * inspector/JSGlobalObjectInspectorController.cpp:
2387         (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
2388         * inspector/agents/InspectorScriptProfilerAgent.cpp:
2389         (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStarted):
2390         (Inspector::InspectorScriptProfilerAgent::programmaticCaptureStopped):
2391         * inspector/agents/InspectorScriptProfilerAgent.h:
2392         JSContext implementation of console.profile/profileEnd.
2393
2394 2016-06-16  Filip Pizlo  <fpizlo@apple.com>
2395
2396         Kraken/stanford-crypto-pbkdf2.js sometimes crashes with an OSR assertion in FTL
2397         https://bugs.webkit.org/show_bug.cgi?id=158850
2398
2399         Reviewed by Keith Miller.
2400         
2401         Bytecode liveness was incorrectly claiming that all tail-deleted locals are live! That's
2402         crazy! We never noticed this because extending OSR liveness is usually not a showstopper and
2403         until recently we didn't have a lot of tail-call test cases to play with. Well, we do now,
2404         thanks to the increasing reliance on tail calls in our builtins.
2405
2406         * dfg/DFGGraph.cpp:
2407         (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.
2408         * ftl/FTLLowerDFGToB3.cpp:
2409         (JSC::FTL::DFG::LowerDFGToB3::buildExitArguments): Make this assertion print more useful information.
2410
2411 2016-06-16  Mark Lam  <mark.lam@apple.com>
2412
2413         Add collecting of LLINT slow path stats.
2414         https://bugs.webkit.org/show_bug.cgi?id=158829
2415
2416         Reviewed by Keith Miller.
2417
2418         * llint/LLIntData.cpp:
2419         (JSC::LLInt::Data::dumpStats):
2420         * llint/LLIntData.h:
2421         * llint/LLIntSlowPaths.cpp:
2422         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2423         * llint/LLIntSlowPaths.h:
2424         * llint/LowLevelInterpreter.asm:
2425         * llint/LowLevelInterpreter32_64.asm:
2426         * llint/LowLevelInterpreter64.asm:
2427
2428 2016-06-15  Keith Miller  <keith_miller@apple.com>
2429
2430         Add support for Symbol.isConcatSpreadable (round 2)
2431         https://bugs.webkit.org/show_bug.cgi?id=158769
2432
2433         Reviewed by Mark Lam.
2434
2435         This patch adds support for Symbol.isConcatSpreadable. In order to
2436         do so, it was necessary to move the Array.prototype.concat function
2437         to JS. A number of different optimizations were needed to make
2438         such the move to a builtin performant. First, this patch adds a
2439         new Bytecode intrinsic, isJSArray, that checks if the value is a
2440         JSArray object. Specifically, isJSArray checks that the array
2441         object is a normal instance of JSArray and not a RuntimeArray or
2442         Array.prototype. isJSArray can also be converted into a constant
2443         by the DFG if we are able to prove that the incomming value is
2444         already a JSArray.
2445
2446         In order to further improve the perfomance we also now cover more
2447         indexing types in our fast path memcpy code. Before we would only
2448         memcpy Arrays if they had the same indexing type and did not have
2449         Array storage or were undecided. Now the memcpy code covers the
2450         following additional three cases:
2451
2452         1) One array is undecided and the other does not have array storage
2453
2454         2) One array is Int32 and the other is contiguous (we map this
2455         into a contiguous array).
2456
2457         3) The this value is an array and first argument is a non-array
2458         that does not have Symbol.isConcatSpreadable set.
2459
2460         This patch also adds a new fast path for concat with more than one
2461         array argument by using memcpy to append values onto the result
2462         array. This works roughly the same as the two array fast path
2463         using the same methodology to decide if we can memcpy the other
2464         butterfly into the result butterfly.
2465
2466         * JavaScriptCore.xcodeproj/project.pbxproj:
2467         * builtins/ArrayPrototype.js:
2468         (concatSlowPath):
2469         (concat):
2470         * bytecode/BytecodeIntrinsicRegistry.cpp:
2471         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
2472         * bytecode/BytecodeIntrinsicRegistry.h:
2473         * bytecode/BytecodeList.json:
2474         * bytecode/BytecodeUseDef.h:
2475         (JSC::computeUsesForBytecodeOffset):
2476         (JSC::computeDefsForBytecodeOffset):
2477         * bytecode/CodeBlock.cpp:
2478         (JSC::CodeBlock::dumpBytecode):
2479         * bytecompiler/BytecodeGenerator.h:
2480         (JSC::BytecodeGenerator::emitIsJSArray):
2481         * bytecompiler/NodesCodegen.cpp:
2482         (JSC::BytecodeIntrinsicNode::emit_intrinsic_isJSArray):
2483         * dfg/DFGAbstractInterpreterInlines.h:
2484         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2485         * dfg/DFGByteCodeParser.cpp:
2486         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
2487         (JSC::DFG::ByteCodeParser::parseBlock):
2488         * dfg/DFGCapabilities.cpp:
2489         (JSC::DFG::capabilityLevel):
2490         * dfg/DFGClobberize.h:
2491         (JSC::DFG::clobberize):
2492         * dfg/DFGDoesGC.cpp:
2493         (JSC::DFG::doesGC):
2494         * dfg/DFGFixupPhase.cpp:
2495         (JSC::DFG::FixupPhase::fixupNode):
2496         * dfg/DFGNodeType.h:
2497         * dfg/DFGOperations.cpp:
2498         * dfg/DFGOperations.h:
2499         * dfg/DFGPredictionPropagationPhase.cpp:
2500         * dfg/DFGSafeToExecute.h:
2501         (JSC::DFG::safeToExecute):
2502         * dfg/DFGSpeculativeJIT.cpp:
2503         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
2504         (JSC::DFG::SpeculativeJIT::compileIsJSArray):
2505         (JSC::DFG::SpeculativeJIT::compileCallObjectConstructor):
2506         * dfg/DFGSpeculativeJIT.h:
2507         (JSC::DFG::SpeculativeJIT::callOperation):
2508         * dfg/DFGSpeculativeJIT32_64.cpp:
2509         (JSC::DFG::SpeculativeJIT::compile):
2510         * dfg/DFGSpeculativeJIT64.cpp:
2511         (JSC::DFG::SpeculativeJIT::compile):
2512         * ftl/FTLCapabilities.cpp:
2513         (JSC::FTL::canCompile):
2514         * ftl/FTLLowerDFGToB3.cpp:
2515         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2516         (JSC::FTL::DFG::LowerDFGToB3::compileCallObjectConstructor):
2517         (JSC::FTL::DFG::LowerDFGToB3::compileIsJSArray):
2518         (JSC::FTL::DFG::LowerDFGToB3::isArray):
2519         * jit/JIT.cpp:
2520         (JSC::JIT::privateCompileMainPass):
2521         * jit/JIT.h:
2522         * jit/JITOpcodes.cpp:
2523         (JSC::JIT::emit_op_is_jsarray):
2524         * jit/JITOpcodes32_64.cpp:
2525         (JSC::JIT::emit_op_is_jsarray):
2526         * jit/JITOperations.h:
2527         * llint/LLIntData.cpp:
2528         (JSC::LLInt::Data::performAssertions):
2529         * llint/LowLevelInterpreter.asm:
2530         * llint/LowLevelInterpreter32_64.asm:
2531         * llint/LowLevelInterpreter64.asm:
2532         * runtime/ArrayConstructor.h:
2533         (JSC::isArrayConstructor):
2534         * runtime/ArrayPrototype.cpp:
2535         (JSC::ArrayPrototype::finishCreation):
2536         (JSC::speciesWatchpointsValid):
2537         (JSC::speciesConstructArray):
2538         (JSC::moveElements):
2539         (JSC::concatAppendOne):
2540         (JSC::arrayProtoFuncConcat): Deleted.
2541         * runtime/ArrayPrototype.h:
2542         * runtime/CommonIdentifiers.h:
2543         * runtime/CommonSlowPaths.cpp:
2544         (JSC::SLOW_PATH_DECL):
2545         * runtime/IndexingType.h:
2546         (JSC::indexingTypeForValue):
2547         * runtime/JSArray.cpp:
2548         (JSC::JSArray::appendMemcpy):
2549         (JSC::JSArray::fastConcatWith): Deleted.
2550         * runtime/JSArray.h:
2551         (JSC::JSArray::createStructure):
2552         (JSC::isJSArray):
2553         (JSC::JSArray::fastConcatType): Deleted.
2554         * runtime/JSArrayInlines.h: Added.
2555         (JSC::JSArray::mergeIndexingTypeForCopying):
2556         (JSC::JSArray::canFastCopy):
2557         * runtime/JSGlobalObject.cpp:
2558         (JSC::JSGlobalObject::init):
2559         * runtime/JSObject.cpp:
2560         (JSC::JSObject::convertUndecidedForValue):
2561         * runtime/JSType.h:
2562         * runtime/ObjectConstructor.h:
2563         (JSC::constructObject):
2564         * tests/es6.yaml:
2565         * tests/stress/array-concat-spread-object.js: Added.
2566         (arrayEq):
2567         * tests/stress/array-concat-spread-proxy-exception-check.js: Added.
2568         (arrayEq):
2569         * tests/stress/array-concat-spread-proxy.js: Added.
2570         (arrayEq):
2571         * tests/stress/array-concat-with-slow-indexingtypes.js: Added.
2572         (arrayEq):
2573         * tests/stress/array-species-config-array-constructor.js:
2574
2575 2016-06-15  Mark Lam  <mark.lam@apple.com>
2576
2577         Assertion failure when returning incomplete property descriptor from proxy trap.
2578         https://bugs.webkit.org/show_bug.cgi?id=157078
2579
2580         Reviewed by Saam Barati.
2581
2582         If the proxy returns a descriptor that expects a value but does not specify one,
2583         we should use undefined for the value.
2584
2585         * runtime/ProxyObject.cpp:
2586         (JSC::ProxyObject::performInternalMethodGetOwnProperty):
2587         * tests/stress/proxy-returning-incomplete-property-descriptor.js: Added.
2588         (truthiness):
2589         (compare):
2590         (shouldBe):
2591         (test):
2592         (get test):
2593
2594 2016-06-15  Keith Miller  <keith_miller@apple.com>
2595
2596         Unreviewed, fix typo in test and move tests to the correct files.
2597
2598         * tests/stress/multi-get-by-offset-proto-or-unset.js:
2599         * tests/stress/multi-get-by-offset-proto-self-or-unset.js:
2600
2601 2016-06-15  Keith Miller  <keith_miller@apple.com>
2602
2603         DFGByteCodeParser should be able to infer the value of unset properties in MultiGetByOffset
2604         https://bugs.webkit.org/show_bug.cgi?id=158802
2605
2606         Reviewed by Filip Pizlo.
2607
2608         This patch adds support for unset properties in MultiGetByOffset. Since MultiGetByOffset
2609         already supports constant values this patch just adds a constant case where the fetched
2610         value is undefined. Fortunately (or unfortunately) we don't support object allocation
2611         sinking for constant cases of MultiGetByOffset, which means we don't need to adjust any
2612         in that phase.
2613
2614         * dfg/DFGByteCodeParser.cpp:
2615         (JSC::DFG::ByteCodeParser::planLoad):
2616         (JSC::DFG::ByteCodeParser::handleGetById):
2617         * dfg/DFGMultiGetByOffsetData.h:
2618         * tests/stress/multi-get-by-offset-proto-or-unset.js: Added.
2619         (foo):
2620         * tests/stress/multi-get-by-offset-proto-self-or-unset.js: Added.
2621         (foo):
2622         * tests/stress/multi-get-by-offset-self-or-unset.js: Added.
2623         (foo):
2624
2625 2016-06-15  Chris Dumez  <cdumez@apple.com>
2626
2627         Unreviewed GCC build fix after r202098.
2628
2629         * bytecode/CodeBlock.cpp:
2630         (JSC::CodeBlock::thresholdForJIT):
2631
2632 2016-06-14  Geoffrey Garen  <ggaren@apple.com>
2633
2634         compilation policy should adapt to past behavior
2635         https://bugs.webkit.org/show_bug.cgi?id=158759
2636
2637         Reviewed by Saam Barati.
2638
2639         This looks like a ~9% speedup on JSBench.
2640
2641         * bytecode/CodeBlock.cpp:
2642         (JSC::CodeBlock::~CodeBlock): Record when a CodeBlock dies without ever
2643         making it to DFG.
2644
2645         (JSC::CodeBlock::thresholdForJIT): CodeBlocks that make it to DFG should
2646         compile sooner; CodeBlocks that don't should compile later. The goal is
2647         to use past behavior, in addition to execution counts, to determine
2648         whether compilation is profitable.
2649
2650         (JSC::CodeBlock::jitAfterWarmUp):
2651         (JSC::CodeBlock::jitSoon): Apply the thresholdForJIT rule.
2652
2653         * bytecode/CodeBlock.h: Moved some code into the .cpp file so I could
2654         change stuff without recompiling.
2655         (JSC::CodeBlock::jitAfterWarmUp): Deleted.
2656         (JSC::CodeBlock::jitSoon): Deleted.
2657
2658         * bytecode/UnlinkedCodeBlock.cpp:
2659         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
2660         * bytecode/UnlinkedCodeBlock.h:
2661         (JSC::UnlinkedCodeBlock::didOptimize):
2662         (JSC::UnlinkedCodeBlock::setDidOptimize): Added a piece of data to track
2663         whether we made it to DFG.
2664
2665         * jit/JITOperations.cpp: Record when we make it to DFG.
2666
2667 2016-06-15  Konstantin Tokarev  <annulen@yandex.ru>
2668
2669         Only Mac port needs ObjC API for JSC.
2670         https://bugs.webkit.org/show_bug.cgi?id=158780
2671
2672         Reviewed by Philippe Normand.
2673
2674         * API/JSBase.h: Removed !defined(BUILDING_GTK__)
2675
2676 2016-06-15  Keith Miller  <keith_miller@apple.com>
2677
2678         DFGByteCodeParser should be able to infer a property is unset from the Baseline inline cache.
2679         https://bugs.webkit.org/show_bug.cgi?id=158774
2680
2681         Reviewed by Filip Pizlo.
2682
2683         This patch allows the DFGByteCodeParser to speculatively convert a property access into a
2684         constant if that access was always a miss in the Baseline inline cache. This patch does
2685         not add support for MultiGetByOffset and unset properties. That functionality will come
2686         a future patch.
2687
2688         * bytecode/ComplexGetStatus.cpp:
2689         (JSC::ComplexGetStatus::computeFor):
2690         * bytecode/GetByIdStatus.cpp:
2691         (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
2692         * bytecode/GetByIdVariant.h:
2693         (JSC::GetByIdVariant::isPropertyUnset):
2694         * bytecode/PutByIdVariant.h:
2695         (JSC::PutByIdVariant::isPropertyUnset):
2696         * dfg/DFGByteCodeParser.cpp:
2697         (JSC::DFG::ByteCodeParser::load):
2698         (JSC::DFG::ByteCodeParser::handleGetById):
2699         * tests/stress/undefined-access-then-self-change.js: Added.
2700         (foo):
2701
2702 2016-06-15  Yusuke Suzuki  <utatane.tea@gmail.com>
2703
2704         [JSC] Move calling convention flags to WTF
2705         https://bugs.webkit.org/show_bug.cgi?id=158661
2706
2707         Reviewed by Keith Miller.
2708
2709         Due to some calling convention flags and JIT_OPERATION flags, MathCommon.h includes MacroAssemblerCodeRef and JITOperations.h.
2710         But MacroAssembler and JIT part should not be necessary for the MathCommon component.
2711         As with other calling convention flags like JSC_HOST_CALL, these flags should be in WTF.
2712
2713         * assembler/MacroAssemblerCodeRef.h:
2714         * jit/JITOperations.h:
2715         Add wtf/Platform.h inclusion driven by the Windows port build failure.
2716
2717         * runtime/MathCommon.h:
2718
2719 2016-06-15  Romain Bellessort  <romain.bellessort@crf.canon.fr>
2720
2721         Enabling Shadow DOM for all platforms
2722         https://bugs.webkit.org/show_bug.cgi?id=158738
2723
2724         Reviewed by Ryosuke Niwa.
2725
2726         Removed Shadow DOM from options (enabled by default)
2727
2728         * Configurations/FeatureDefines.xcconfig:
2729
2730 2016-06-14  Caio Lima  <ticaiolima@gmail.com>
2731
2732         The parser doesn't properly parse "super" when default parameter is an
2733         arrow function.
2734         https://bugs.webkit.org/show_bug.cgi?id=157872.
2735
2736         Reviewed by Saam Barati.
2737
2738         The "super" member or "super()" could not be used when default parameter is an
2739         arrow function, resuling in sytax error. It happened because the
2740         "closestOrdinaryFunctionScope" was not being initialized properly
2741         before "parseFunctionParameters" step and the condition
2742         "functionSuperBinding == SuperBinding::NotNeeded" or
2743         "functionConstructorKind != ConstructorKind::Derived" on
2744         "Parser<LexerType>::parseMemberExpression" step were being true
2745         resulting in SyntaxError.
2746
2747         * parser/Parser.cpp: 
2748         (JSC::Parser<LexerType>::parseFunctionInfo): setting
2749         "functionScope->setExpectedSuperBinding(expectedSuperBinding)" and
2750         "functionScope->setConstructorKind(constructorKind)" before
2751         "parseFunctionParameters" step.
2752
2753 2016-06-14  Joseph Pecoraro  <pecoraro@apple.com>
2754
2755         Web Inspector: Rename Timeline.setAutoCaptureInstruments to Timeline.setInstruments
2756         https://bugs.webkit.org/show_bug.cgi?id=158762
2757
2758         Reviewed by Timothy Hatcher.
2759
2760         Rename the protocol methods since the backend may use the instruments
2761         for purposes other then auto-capture, such as programmatic capture
2762         via console.profile.
2763
2764         * inspector/protocol/Timeline.json:
2765
2766 2016-06-14  David Kilzer  <ddkilzer@apple.com>
2767
2768         Document the native format of JSChar type
2769         <http://webkit.org/b/156137>
2770
2771         Reviewed by Darin Adler.
2772
2773         * API/JSStringRef.h:
2774         (typedef JSChar): Update documentation.
2775
2776 2016-06-14  Keith Miller  <keith_miller@apple.com>
2777
2778         The Array species constructor watchpoints should be created the first time they are needed rather than on creation
2779         https://bugs.webkit.org/show_bug.cgi?id=158754
2780
2781         Reviewed by Benjamin Poulain.
2782
2783         We use adaptive watchpoints for some Array prototype functions to
2784         ensure that the user has not overridden the value of the
2785         Array.prototype.constructor or Array[Symbol.species]. This patch
2786         changes when the Array species constructor watchpoints are
2787         initialized. Before, those watchpoints would be created when the
2788         global object is initialized. This had the advantage that it did
2789         not require validating the constructor and Symbol.species
2790         properties. On the other hand, it also meant that if the user were
2791         to reconfigure properties Array.prototype, which would cause the
2792         structure of the property to become an uncachable dictionary,
2793         prior to running code that the watchpoints would be
2794         invalidated. It turns out that JSBench amazon, for instance, does
2795         reconfigure some of Array.prototype's properties. This patch
2796         initializes the watchpoints the first time they are needed. Since
2797         we only initialize once we also flatten the structure of Array and
2798         Array.prototype.
2799
2800         * runtime/ArrayPrototype.cpp:
2801         (JSC::speciesConstructArray):
2802         (JSC::ArrayPrototype::attemptToInitializeSpeciesWatchpoint):
2803         (JSC::ArrayPrototypeAdaptiveInferredPropertyWatchpoint::handleFire):
2804         (JSC::ArrayPrototype::setConstructor): Deleted.
2805         * runtime/ArrayPrototype.h:
2806         (JSC::ArrayPrototype::speciesWatchpointStatus):
2807         (JSC::ArrayPrototype::didChangeConstructorOrSpeciesProperties): Deleted.
2808         * runtime/JSGlobalObject.cpp:
2809         (JSC::JSGlobalObject::init):
2810         * runtime/JSGlobalObject.h:
2811         (JSC::JSGlobalObject::speciesGetterSetter):
2812         (JSC::JSGlobalObject::arrayConstructor):
2813         * tests/stress/array-symbol-species-lazy-watchpoints.js: Added.
2814         (test):
2815         (arrayEq):
2816         (A):
2817
2818 2016-06-14  Keith Miller  <keith_miller@apple.com>
2819
2820         REGRESSION(202002-202014): 845 32-bit JSC Stress Test failures
2821         https://bugs.webkit.org/show_bug.cgi?id=158737
2822
2823         Reviewed by Filip Pizlo.
2824
2825         When the this child and arguments child for the varargs nodes was switched I missed one
2826         case in the 32-bit build.
2827
2828         * dfg/DFGSpeculativeJIT32_64.cpp:
2829         (JSC::DFG::SpeculativeJIT::emitCall):
2830
2831 2016-06-13  Gavin & Ellie Barraclough  <barraclough@apple.com>
2832
2833         setUpStaticFunctionSlot does not handle Builtin|Accessor properties
2834         https://bugs.webkit.org/show_bug.cgi?id=158637
2835
2836         Reviewed by Geoff Garen.
2837
2838         setUpStaticFunctionSlot contains a duplicate copy of the body of the function reifyStaticProperty
2839         - however it is missing handling for Accessor type under Builtin functions.
2840         Fix the bug by de-duplicating - setUpStaticFunctionSlot should just call reifyStaticProperty.
2841
2842         * runtime/Lookup.cpp:
2843         (JSC::setUpStaticFunctionSlot):
2844             - should just call reifyStaticProperty.
2845         * runtime/Lookup.h:
2846         (JSC::lookupPut):
2847         (JSC::reifyStaticProperty):
2848             - changed reifyStaticProperty to take PropertyName.
2849
2850 2016-06-13  Gavin & Ellie Barraclough  <barraclough@apple.com>
2851
2852         JSBoundSlotBaseFunction no longer binds slot base
2853         https://bugs.webkit.org/show_bug.cgi?id=157978
2854
2855         Reviewed by Geoff Garen.
2856
2857         This class is basically currently named after a bug. We should never have
2858         been binding function to slot bases - this was not ever correct behavior.
2859         This was fixed earlier in the year, but there is still some cruft including
2860         the class name to clean up.
2861
2862             - renamed JSBoundSlotBaseFunction -> JSCustomGetterSetterFunction
2863             - removed m_boundSlotBase - don't retain the original slot base
2864               (we were not really using it anyway).
2865             - ASSERT customGetterSetter->getter/setter are non-null, rather than checking.
2866             - Store the PropertyName such that we can pass this to the getter
2867               (we're currently reperforming the String->Identifier conversion every time).
2868             - Removed JSFunction::lookUpOrCreateNativeExecutable - this is just overhead,
2869               and not used consistently.
2870
2871         * CMakeLists.txt:
2872         * JavaScriptCore.xcodeproj/project.pbxproj:
2873         * runtime/JSBoundSlotBaseFunction.cpp: Removed.
2874         * runtime/JSBoundSlotBaseFunction.h: Removed.
2875             - JSBoundSlotBaseFunction -> JSCustomGetterSetterFunction
2876         * runtime/JSCustomGetterSetterFunction.cpp: Copied from Source/JavaScriptCore/runtime/JSBoundSlotBaseFunction.cpp.
2877         (JSC::JSCustomGetterSetterFunction::customGetterSetterFunctionCall):
2878             - made a static function on JSCustomGetterSetterFunction such that accessor
2879               to member properties could be made private. Call variant of callCustomSetter
2880               that does not require slotBase, ASSERT getter/setter present, pass stored
2881               PropertyName to getter.
2882         (JSC::JSCustomGetterSetterFunction::JSCustomGetterSetterFunction):
2883             - renamed, store propertyName.
2884         (JSC::JSCustomGetterSetterFunction::create):
2885             - use same function name to Executable as is being passed to Function::finishCreation.
2886         (JSC::JSCustomGetterSetterFunction::visitChildren):
2887         (JSC::JSCustomGetterSetterFunction::finishCreation):
2888             - removed m_boundSlotBase.
2889         * runtime/JSCustomGetterSetterFunction.h: Copied from Source/JavaScriptCore/runtime/JSBoundSlotBaseFunction.h.
2890         (JSC::JSCustomGetterSetterFunction::customGetterSetter):
2891         (JSC::JSCustomGetterSetterFunction::isSetter):
2892             - made private.
2893         (JSC::JSCustomGetterSetterFunction::propertyName):
2894             - new accessor.
2895         (JSC::JSBoundSlotBaseFunction::boundSlotBase): Deleted.
2896             - removed.
2897         * runtime/JSFunction.cpp:
2898         (JSC::JSFunction::create):
2899         (JSC::JSFunction::lookUpOrCreateNativeExecutable): Deleted.
2900             - removed lookUpOrCreateNativeExecutable. This inconsistently used wrapper was providing no value, only bloat.
2901         * runtime/JSFunction.h:
2902         * runtime/JSGlobalObject.cpp:
2903         (JSC::JSGlobalObject::init):
2904         (JSC::JSGlobalObject::visitChildren):
2905             - renamed JSBoundSlotBaseFunction -> JSCustomGetterSetterFunction, etc.
2906         * runtime/JSGlobalObject.h:
2907         (JSC::JSGlobalObject::customGetterSetterFunctionStructure):
2908         (JSC::JSGlobalObject::boundSlotBaseFunctionStructure): Deleted.
2909             - renamed JSBoundSlotBaseFunction -> JSCustomGetterSetterFunction, etc.
2910         * runtime/JSNativeStdFunction.cpp:
2911         (JSC::JSNativeStdFunction::create):
2912             - removed lookUpOrCreateNativeExecutable.
2913         * runtime/JSObject.cpp:
2914         (JSC::getCustomGetterSetterFunctionForGetterSetter):
2915         (JSC::JSObject::getOwnPropertyDescriptor):
2916         (JSC::getBoundSlotBaseFunctionForGetterSetter): Deleted.
2917             - renamed JSBoundSlotBaseFunction -> JSCustomGetterSetterFunction, etc.
2918         * runtime/VM.h:
2919             - renamed JSBoundSlotBaseFunction -> JSCustomGetterSetterFunction, etc.
2920
2921 2016-06-13  Saam Barati  <sbarati@apple.com>
2922
2923         The sampling profiler should further protect itself against certain forms of sampling bias that arise due to the sampling interval being in sync with some other system process
2924         https://bugs.webkit.org/show_bug.cgi?id=158678
2925
2926         Reviewed by Benjamin Poulain.
2927
2928         I first became aware of this problem when I read this paper:
2929         http://plv.colorado.edu/papers/mytkowicz-pldi10.pdf
2930
2931         To provide background for this change, I'll quote a paragraph
2932         from section 6.2:
2933         "One statically sound method for collecting random samples is to collect a
2934         sample at every t + r milliseconds, where t is the desired sampling interval
2935         and r is a random number between −t and t. One might think that sampling every
2936         t seconds is enough (i.e., drop the r component) but it is not: specifically,
2937         if a profiler samples every t seconds, the sampling rate would be synchronized
2938         with any program or system activity that occurs at regular time intervals [17].
2939         For example, if the thread scheduler switches between threads every 10ms and our
2940         sampling interval was also 10ms, then we may always take samples immediately after
2941         a thread switch. Because performance is often different immediately after a thread
2942         switch than at other points (e.g., due to cache and TLB warm-up effects) we would
2943         get biased data. The random component, r, guards against such situations."
2944
2945         * runtime/SamplingProfiler.cpp:
2946         (JSC::SamplingProfiler::timerLoop):
2947
2948 2016-06-13  Oliver Hunt  <oliver@apple.com>
2949
2950         DFG Validation fails when performing a concatenation with only a single entry
2951         https://bugs.webkit.org/show_bug.cgi?id=158699
2952
2953         Reviewed by Saam Barati.
2954
2955         Fairly simple short circuiting of a single replacement template string
2956         without any padding to be planted as a simple to string rather than
2957         op_strcat.
2958
2959         * bytecompiler/NodesCodegen.cpp:
2960         (JSC::TemplateLiteralNode::emitBytecode):
2961         * tests/stress/template-literal.js:
2962         (testSingleNode):
2963
2964 2016-06-13  Filip Pizlo  <fpizlo@apple.com>
2965
2966         FTL::Output methods should be out-of-line whenever possible
2967         https://bugs.webkit.org/show_bug.cgi?id=158704
2968
2969         Reviewed by Benjamin Poulain.
2970         
2971         These methods turn into a non-trivial amount of code because of the template-based B3 API.
2972         Inlining them didn't achieve any performance advantages for the FTL, but it did make the
2973         code larger. This outlines most methods in FTL::Output. It makes FTL::LowerDFGToB3 smaller
2974         and it doesn't change performance.
2975
2976         * ftl/FTLOutput.cpp:
2977         (JSC::FTL::Output::appendTo):
2978         (JSC::FTL::Output::framePointer):
2979         (JSC::FTL::Output::lockedStackSlot):
2980         (JSC::FTL::Output::constBool):
2981         (JSC::FTL::Output::constInt32):
2982         (JSC::FTL::Output::constInt64):
2983         (JSC::FTL::Output::constDouble):
2984         (JSC::FTL::Output::phi):
2985         (JSC::FTL::Output::add):
2986         (JSC::FTL::Output::sub):
2987         (JSC::FTL::Output::mul):
2988         (JSC::FTL::Output::div):
2989         (JSC::FTL::Output::chillDiv):
2990         (JSC::FTL::Output::mod):
2991         (JSC::FTL::Output::chillMod):
2992         (JSC::FTL::Output::neg):
2993         (JSC::FTL::Output::doubleAdd):
2994         (JSC::FTL::Output::doubleSub):
2995         (JSC::FTL::Output::doubleMul):
2996         (JSC::FTL::Output::doubleDiv):
2997         (JSC::FTL::Output::doubleMod):
2998         (JSC::FTL::Output::bitAnd):
2999         (JSC::FTL::Output::bitOr):
3000         (JSC::FTL::Output::bitXor):
3001         (JSC::FTL::Output::shl):
3002         (JSC::FTL::Output::aShr):
3003         (JSC::FTL::Output::lShr):
3004         (JSC::FTL::Output::bitNot):
3005         (JSC::FTL::Output::logicalNot):
3006         (JSC::FTL::Output::ctlz32):
3007         (JSC::FTL::Output::doubleAbs):
3008         (JSC::FTL::Output::doubleCeil):
3009         (JSC::FTL::Output::doubleFloor):
3010         (JSC::FTL::Output::doubleTrunc):
3011         (JSC::FTL::Output::doubleSin):
3012         (JSC::FTL::Output::doubleCos):
3013         (JSC::FTL::Output::doublePow):
3014         (JSC::FTL::Output::doublePowi):
3015         (JSC::FTL::Output::doubleSqrt):
3016         (JSC::FTL::Output::doubleLog):
3017         (JSC::FTL::Output::hasSensibleDoubleToInt):
3018         (JSC::FTL::Output::doubleToUInt):
3019         (JSC::FTL::Output::signExt32To64):
3020         (JSC::FTL::Output::zeroExt):
3021         (JSC::FTL::Output::intToDouble):
3022         (JSC::FTL::Output::unsignedToDouble):
3023         (JSC::FTL::Output::castToInt32):
3024         (JSC::FTL::Output::doubleToFloat):
3025         (JSC::FTL::Output::floatToDouble):
3026         (JSC::FTL::Output::load):
3027         (JSC::FTL::Output::load8SignExt32):
3028         (JSC::FTL::Output::baseIndex):
3029         (JSC::FTL::Output::equal):
3030         (JSC::FTL::Output::notEqual):
3031         (JSC::FTL::Output::above):
3032         (JSC::FTL::Output::aboveOrEqual):
3033         (JSC::FTL::Output::below):
3034         (JSC::FTL::Output::belowOrEqual):
3035         (JSC::FTL::Output::greaterThan):
3036         (JSC::FTL::Output::greaterThanOrEqual):
3037         (JSC::FTL::Output::lessThan):
3038         (JSC::FTL::Output::lessThanOrEqual):
3039         (JSC::FTL::Output::doubleEqual):
3040         (JSC::FTL::Output::doubleEqualOrUnordered):
3041         (JSC::FTL::Output::doubleNotEqualOrUnordered):
3042         (JSC::FTL::Output::doubleLessThan):
3043         (JSC::FTL::Output::doubleLessThanOrEqual):
3044         (JSC::FTL::Output::doubleGreaterThan):
3045         (JSC::FTL::Output::doubleGreaterThanOrEqual):
3046         (JSC::FTL::Output::doubleNotEqualAndOrdered):
3047         (JSC::FTL::Output::doubleLessThanOrUnordered):
3048         (JSC::FTL::Output::doubleLessThanOrEqualOrUnordered):
3049         (JSC::FTL::Output::doubleGreaterThanOrUnordered):
3050         (JSC::FTL::Output::doubleGreaterThanOrEqualOrUnordered):
3051         (JSC::FTL::Output::isZero32):
3052         (JSC::FTL::Output::notZero32):
3053         (JSC::FTL::Output::isZero64):
3054         (JSC::FTL::Output::notZero64):
3055         (JSC::FTL::Output::select):
3056         (JSC::FTL::Output::jump):
3057         (JSC::FTL::Output::branch):
3058         (JSC::FTL::Output::check):
3059         (JSC::FTL::Output::ret):
3060         (JSC::FTL::Output::unreachable):
3061         (JSC::FTL::Output::speculate):
3062         (JSC::FTL::Output::speculateAdd):
3063         (JSC::FTL::Output::speculateSub):
3064         (JSC::FTL::Output::speculateMul):
3065         (JSC::FTL::Output::patchpoint):
3066         (JSC::FTL::Output::trap):
3067         (JSC::FTL::Output::anchor):
3068         (JSC::FTL::Output::bitCast):
3069         (JSC::FTL::Output::fround):
3070         * ftl/FTLOutput.h:
3071         (JSC::FTL::Output::setOrigin):
3072         (JSC::FTL::Output::origin):
3073         (JSC::FTL::Output::constIntPtr):
3074         (JSC::FTL::Output::doubleNeg):
3075         (JSC::FTL::Output::zeroExtPtr):
3076         (JSC::FTL::Output::load32NonNegative):
3077         (JSC::FTL::Output::isNull):
3078         (JSC::FTL::Output::notNull):
3079         (JSC::FTL::Output::testIsZeroPtr):
3080         (JSC::FTL::Output::testNonZeroPtr):
3081         (JSC::FTL::Output::call):
3082         (JSC::FTL::Output::operation):
3083         (JSC::FTL::Output::branch):
3084         (JSC::FTL::Output::switchInstruction):
3085         (JSC::FTL::Output::addIncomingToPhi):
3086         (JSC::FTL::Output::framePointer): Deleted.
3087         (JSC::FTL::Output::constBool): Deleted.
3088         (JSC::FTL::Output::constInt32): Deleted.
3089         (JSC::FTL::Output::constInt64): Deleted.
3090         (JSC::FTL::Output::constDouble): Deleted.
3091         (JSC::FTL::Output::phi): Deleted.
3092         (JSC::FTL::Output::add): Deleted.
3093         (JSC::FTL::Output::sub): Deleted.
3094         (JSC::FTL::Output::mul): Deleted.
3095         (JSC::FTL::Output::div): Deleted.
3096         (JSC::FTL::Output::chillDiv): Deleted.
3097         (JSC::FTL::Output::mod): Deleted.
3098         (JSC::FTL::Output::chillMod): Deleted.
3099         (JSC::FTL::Output::doubleAdd): Deleted.
3100         (JSC::FTL::Output::doubleSub): Deleted.
3101         (JSC::FTL::Output::doubleMul): Deleted.
3102         (JSC::FTL::Output::doubleDiv): Deleted.
3103         (JSC::FTL::Output::doubleMod): Deleted.
3104         (JSC::FTL::Output::bitAnd): Deleted.
3105         (JSC::FTL::Output::bitOr): Deleted.
3106         (JSC::FTL::Output::bitXor): Deleted.
3107         (JSC::FTL::Output::shl): Deleted.
3108         (JSC::FTL::Output::aShr): Deleted.
3109         (JSC::FTL::Output::lShr): Deleted.
3110         (JSC::FTL::Output::ctlz32): Deleted.
3111         (JSC::FTL::Output::addWithOverflow32): Deleted.
3112         (JSC::FTL::Output::subWithOverflow32): Deleted.
3113         (JSC::FTL::Output::mulWithOverflow32): Deleted.
3114         (JSC::FTL::Output::addWithOverflow64): Deleted.
3115         (JSC::FTL::Output::subWithOverflow64): Deleted.
3116         (JSC::FTL::Output::mulWithOverflow64): Deleted.
3117         (JSC::FTL::Output::doubleAbs): Deleted.
3118         (JSC::FTL::Output::doubleCeil): Deleted.
3119         (JSC::FTL::Output::doubleFloor): Deleted.
3120         (JSC::FTL::Output::doubleSin): Deleted.
3121         (JSC::FTL::Output::doubleCos): Deleted.
3122         (JSC::FTL::Output::doublePow): Deleted.
3123         (JSC::FTL::Output::doubleSqrt): Deleted.
3124         (JSC::FTL::Output::doubleLog): Deleted.
3125         (JSC::FTL::Output::signExt32To64): Deleted.
3126         (JSC::FTL::Output::zeroExt): Deleted.
3127         (JSC::FTL::Output::intToDouble): Deleted.
3128         (JSC::FTL::Output::castToInt32): Deleted.
3129         (JSC::FTL::Output::doubleToFloat): Deleted.
3130         (JSC::FTL::Output::floatToDouble): Deleted.
3131         (JSC::FTL::Output::equal): Deleted.
3132         (JSC::FTL::Output::notEqual): Deleted.
3133         (JSC::FTL::Output::above): Deleted.
3134         (JSC::FTL::Output::aboveOrEqual): Deleted.
3135         (JSC::FTL::Output::below): Deleted.
3136         (JSC::FTL::Output::belowOrEqual): Deleted.
3137         (JSC::FTL::Output::greaterThan): Deleted.
3138         (JSC::FTL::Output::greaterThanOrEqual): Deleted.
3139         (JSC::FTL::Output::lessThan): Deleted.
3140         (JSC::FTL::Output::lessThanOrEqual): Deleted.
3141         (JSC::FTL::Output::doubleEqual): Deleted.
3142         (JSC::FTL::Output::doubleEqualOrUnordered): Deleted.
3143         (JSC::FTL::Output::doubleNotEqualOrUnordered): Deleted.
3144         (JSC::FTL::Output::doubleLessThan): Deleted.
3145         (JSC::FTL::Output::doubleLessThanOrEqual): Deleted.
3146         (JSC::FTL::Output::doubleGreaterThan): Deleted.
3147         (JSC::FTL::Output::doubleGreaterThanOrEqual): Deleted.
3148         (JSC::FTL::Output::doubleNotEqualAndOrdered): Deleted.
3149         (JSC::FTL::Output::doubleLessThanOrUnordered): Deleted.
3150         (JSC::FTL::Output::doubleLessThanOrEqualOrUnordered): Deleted.
3151         (JSC::FTL::Output::doubleGreaterThanOrUnordered): Deleted.
3152         (JSC::FTL::Output::doubleGreaterThanOrEqualOrUnordered): Deleted.
3153         (JSC::FTL::Output::isZero32): Deleted.
3154         (JSC::FTL::Output::notZero32): Deleted.
3155         (JSC::FTL::Output::isZero64): Deleted.
3156         (JSC::FTL::Output::notZero64): Deleted.
3157         (JSC::FTL::Output::select): Deleted.
3158         (JSC::FTL::Output::extractValue): Deleted.
3159         (JSC::FTL::Output::jump): Deleted.
3160         (JSC::FTL::Output::ret): Deleted.
3161         (JSC::FTL::Output::unreachable): Deleted.
3162         (JSC::FTL::Output::speculate): Deleted.
3163         (JSC::FTL::Output::speculateAdd): Deleted.
3164         (JSC::FTL::Output::speculateSub): Deleted.
3165         (JSC::FTL::Output::speculateMul): Deleted.
3166         (JSC::FTL::Output::patchpoint): Deleted.
3167         (JSC::FTL::Output::trap): Deleted.
3168         (JSC::FTL::Output::anchor): Deleted.
3169         (JSC::FTL::Output::bitCast): Deleted.
3170         (JSC::FTL::Output::fround): Deleted.
3171
3172 2016-06-13  Keith Miller  <keith_miller@apple.com>
3173
3174         Unreviewed, Cloop build fix.
3175
3176         * bytecode/BytecodeList.json:
3177
3178 2016-06-12  Keith Miller  <keith_miller@apple.com>
3179
3180         Add new builtin opcode tailCallForwardArguments
3181         https://bugs.webkit.org/show_bug.cgi?id=158666
3182
3183         Reviewed by Filip Pizlo.
3184
3185         We should support the ability to have a builtin forward its
3186         arguments to a helper without allocating an arguments object. This
3187         patch adds a new bytecode intrinsic @tailCallForwardArguments that
3188         takes two values. The first is the target of the call and the
3189         second is the new this value. This opcode will tail call to the
3190         passed function without triggering an allocation of an arguments
3191         object for the caller function.
3192
3193         In the LLInt and Baseline this function acts the same way a normal
3194         tail call does.  The bytecode will allocate a new stack frame
3195         copying all the arguments of the caller function into the new
3196         frame, along with the new this. Then when the actual call happens
3197         the new frame is copied over the caller frame. While this is not
3198         necessary, it allows the target function to have more arguments
3199         than the caller function via arity fixup.
3200
3201         Once we get to the DFG we reuse existing DFG Nodes for forwarding
3202         arguments, although there were some minor changes. This patch
3203         swaps the meaning of the second and third children for each DFG
3204         varargs node, exchanging the argmuments and this child,
3205         respectively. It also makes the arguments child for each varargs
3206         node, as well as the ForwardVarargs node optional. If the optional
3207         child is missing, then forwarding node assumes that the arguments
3208         for the node's inlineCallFrame should be used instead. Finally,
3209         when inlining the target of an inlined
3210         op_tail_call_forward_arguments we make sure the arguments of the
3211         forwarding function are marked as non-unboxable since this would
3212         normally be done by the caller's create arguments object node,
3213         which does not exist in this case.
3214
3215         * bytecode/BytecodeIntrinsicRegistry.h:
3216         * bytecode/BytecodeList.json:
3217         * bytecode/BytecodeUseDef.h:
3218         (JSC::computeUsesForBytecodeOffset):
3219         (JSC::computeDefsForBytecodeOffset):
3220         * bytecode/CallLinkInfo.h:
3221         (JSC::CallLinkInfo::callTypeFor):
3222         * bytecode/CodeBlock.cpp:
3223         (JSC::CodeBlock::dumpBytecode):
3224         (JSC::CodeBlock::finishCreation):
3225         * bytecompiler/BytecodeGenerator.cpp:
3226         (JSC::BytecodeGenerator::emitCallForwardArgumentsInTailPosition):
3227         (JSC::BytecodeGenerator::emitCallVarargs):
3228         * bytecompiler/BytecodeGenerator.h:
3229         * bytecompiler/NodesCodegen.cpp:
3230         (JSC::BytecodeIntrinsicNode::emit_intrinsic_tailCallForwardArguments):
3231         (JSC::BytecodeIntrinsicNode::emit_intrinsic_tryGetById):
3232         * dfg/DFGArgumentsEliminationPhase.cpp:
3233         * dfg/DFGByteCodeParser.cpp:
3234         (JSC::DFG::ByteCodeParser::getPredictionWithoutOSRExit):
3235         (JSC::DFG::ByteCodeParser::handleCall):
3236         (JSC::DFG::ByteCodeParser::handleVarargsCall):
3237         (JSC::DFG::ByteCodeParser::handleInlining):
3238         (JSC::DFG::ByteCodeParser::parseBlock):
3239         * dfg/DFGCapabilities.cpp:
3240         (JSC::DFG::capabilityLevel):
3241         * dfg/DFGFixupPhase.cpp:
3242         (JSC::DFG::FixupPhase::fixupNode):
3243         * dfg/DFGNode.h:
3244         (JSC::DFG::Node::hasArgumentsChild):
3245         (JSC::DFG::Node::argumentsChild):
3246         * dfg/DFGPreciseLocalClobberize.h:
3247         (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
3248         * dfg/DFGPredictionPropagationPhase.cpp:
3249         * dfg/DFGSpeculativeJIT.cpp:
3250         (JSC::DFG::SpeculativeJIT::compileForwardVarargs):
3251         * dfg/DFGSpeculativeJIT32_64.cpp:
3252         (JSC::DFG::SpeculativeJIT::emitCall):
3253         * dfg/DFGSpeculativeJIT64.cpp:
3254         (JSC::DFG::SpeculativeJIT::emitCall):
3255         * dfg/DFGVarargsForwardingPhase.cpp:
3256         * ftl/FTLLowerDFGToB3.cpp:
3257         (JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
3258         (JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargs):
3259         * interpreter/Interpreter.cpp:
3260         (JSC::sizeFrameForForwardArguments):
3261         (JSC::setupForwardArgumentsFrame):
3262         (JSC::setupForwardArgumentsFrameAndSetThis):
3263         * interpreter/Interpreter.h:
3264         * jit/JIT.cpp:
3265         (JSC::JIT::privateCompileMainPass):
3266         (JSC::JIT::privateCompileSlowCases):
3267         * jit/JIT.h:
3268         * jit/JITCall.cpp:
3269         (JSC::JIT::compileSetupVarargsFrame):
3270         (JSC::JIT::compileOpCall):
3271         (JSC::JIT::compileOpCallSlowCase):
3272         (JSC::JIT::emit_op_tail_call_forward_arguments):
3273         (JSC::JIT::emitSlow_op_tail_call_forward_arguments):
3274         * jit/JITCall32_64.cpp:
3275         (JSC::JIT::emitSlow_op_tail_call_forward_arguments):
3276         (JSC::JIT::emit_op_tail_call_forward_arguments):
3277         (JSC::JIT::compileSetupVarargsFrame):
3278         (JSC::JIT::compileOpCall):
3279         * jit/JITOperations.cpp:
3280         * jit/JITOperations.h:
3281         * llint/LLIntSlowPaths.cpp:
3282         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
3283         (JSC::LLInt::varargsSetup):
3284         * llint/LLIntSlowPaths.h:
3285         * llint/LowLevelInterpreter.asm:
3286         * tests/stress/tailCallForwardArguments.js: Added.
3287         (putFuncToPrivateName.createBuiltin):
3288         (putFuncToPrivateName):
3289         (createTailCallForwardingFuncWith):
3290         (baz):
3291         (baz2):
3292         (baz3):
3293         (let.bodyText):
3294         (baz4):
3295         (baz5):
3296         (arrayEq):
3297
3298 2016-06-13  Yusuke Suzuki  <utatane.tea@gmail.com>
3299
3300         Unreviewed, follow up patch for r201964
3301         https://bugs.webkit.org/show_bug.cgi?id=158619
3302
3303         Fix typo in the comment.
3304
3305         * runtime/MathCommon.h:
3306         (JSC::toInt32):
3307
3308 2016-06-13  Mark Lam  <mark.lam@apple.com>
3309
3310         Add a mechanism for collecting LLINT stats.
3311         https://bugs.webkit.org/show_bug.cgi?id=158668
3312
3313         Reviewed by Filip Pizlo.
3314
3315         This patch will add a mechanism for collecting the stats on LLINT opcode
3316         execution counts.  The changes made to enable this are:
3317
3318         1. Refactored how Options availability work so that we can add a new category:
3319            Configurable (in addition to the pre-existing Normal and Restricted
3320            availability).
3321                Normal options - always available.
3322                Restricted options - only available on debug builds.
3323                Configurable options - depends on #define flag options.
3324
3325            This change is necessary so that:
3326            a. we won't have to rebuild the world when we want to enable that #define flag
3327               to make that Configurable option available.
3328            b. when the #define flag is disabled, the option will be invisible to the user.
3329
3330            With this, we add our first configurable option, JSC_reportLLIntStats, which
3331            is dependent on the ENABLE_LLINT_STATS flag.  See next.
3332
3333         2. Added the ENABLE_LLINT_STATS flag in LLIntCommon.h.  To enable LLINT stats
3334            collection, we'll need to set this flag to a non-zero value, and rebuilding
3335            the project.  By design, this will only require a minimal set of files to
3336            be rebuilt.
3337
3338            ENABLE_LLINT_STATS is 0 (i.e. disabled) by default.
3339
3340         3. Added a slow path callback to the LLINT's traceExecution() macro, to call
3341            _llint_count_opcode(), which in turns counts the opcode.  This callback will
3342            only be built into the LLINT if ENABLE_LLINT_STATS is non-zero.
3343
3344         4. Added s_opcodeStatsArray to LLInt::Data.  This is where the stats are
3345            recorded and stored.
3346
3347         5. Added calls to LLInt::Data::dumpStats() in jsc.cpp and DumpRenderTree.mm
3348            to dump the LLINT stats if enabled.  If enabled, the LLINT stats will be
3349            sorted and dumped (via dataLog) before the programs terminate.
3350
3351         * interpreter/Interpreter.h:
3352         * jsc.cpp:
3353         (main):
3354         * llint/LLIntCommon.h:
3355         * llint/LLIntData.cpp:
3356         (JSC::LLInt::initialize):
3357         (JSC::LLInt::Data::dumpStats):
3358         * llint/LLIntData.h:
3359         (JSC::LLInt::Data::opcodeStats):
3360         * llint/LLIntOfflineAsmConfig.h:
3361         * llint/LLIntSlowPaths.cpp:
3362         (JSC::LLInt::llint_crash):
3363         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
3364         * llint/LLIntSlowPaths.h:
3365         * llint/LowLevelInterpreter.asm:
3366         * runtime/Options.cpp:
3367         (JSC::parse):
3368         (JSC::Options::isAvailable):
3369         (JSC::overrideOptionWithHeuristic):
3370         (JSC::scaleJITPolicy):
3371         (JSC::Options::initialize):
3372         (JSC::Options::setOptionWithoutAlias):
3373         (JSC::Options::dumpAllOptions):
3374         (JSC::Options::dumpOption):
3375         * runtime/Options.h:
3376         (JSC::Option::Option):
3377         (JSC::Option::operator!=):
3378         (JSC::Option::id):
3379
3380 2016-06-11  Mark Lam  <mark.lam@apple.com>
3381
3382         Minimize the amount of memcpy done for allocating Error stacks.
3383         https://bugs.webkit.org/show_bug.cgi?id=158664
3384
3385         Reviewed by Darin Adler.
3386
3387         Currently, Vector<StackFrame> are being copied around multiple times in the
3388         process of creating Error stacks.
3389
3390         This patch avoids this unnecessary copying by:
3391         1. Sizing the StackFrame vector correctly to begin with, and skipping
3392            undesirable top frames before filling in the vector.
3393         2. Using perfect forwarding or passing by reference to pass the vector data around
3394            instead of copying the vectors.
3395         3. Changing the Exception object to take a Vector<StackFrame> instead of a
3396            RefCountedArray<StackFrame>.
3397
3398         This patch has passed the JSC and layout tests.  Benchmarks show that perf is
3399         neutral.
3400
3401         * API/tests/testapi.mm:
3402         (testObjectiveCAPI):
3403         * inspector/ScriptCallStackFactory.cpp:
3404         (Inspector::createScriptCallStackFromException):
3405         * interpreter/Interpreter.cpp:
3406         (JSC::GetStackTraceFunctor::GetStackTraceFunctor):
3407         (JSC::GetStackTraceFunctor::operator()):
3408         (JSC::Interpreter::getStackTrace):
3409         (JSC::Interpreter::stackTraceAsString):
3410         (JSC::findExceptionHandler):
3411         * interpreter/Interpreter.h:
3412         * runtime/Error.cpp:
3413         (JSC::addErrorInfoAndGetBytecodeOffset):
3414         * runtime/Exception.cpp:
3415         (JSC::Exception::finishCreation):
3416         * runtime/Exception.h:
3417         (JSC::Exception::valueOffset):
3418         (JSC::Exception::value):
3419         (JSC::Exception::stack):
3420         (JSC::Exception::didNotifyInspectorOfThrow):
3421         (JSC::Exception::setDidNotifyInspectorOfThrow):
3422
3423 2016-06-11  Mark Lam  <mark.lam@apple.com>
3424
3425         Tests that overflows the stack should not be run with the sampling profiler.
3426         https://bugs.webkit.org/show_bug.cgi?id=158663
3427
3428         Reviewed by Saam Barati.
3429
3430         The sampling profiler will be sampling the whole stack, and the amount of memory
3431         churn will make this tests time out, especially with debug builds.  Hence,
3432         let's not run the test with the sampling profiler configuration.
3433
3434         * tests/stress/mutual-tail-call-no-stack-overflow.js:
3435         (shouldThrow):
3436
3437 2016-06-10  Yusuke Suzuki  <utatane.tea@gmail.com>
3438
3439         Unreviewed, attempt to fix r201964 failure on Apple ports
3440         https://bugs.webkit.org/show_bug.cgi?id=158619
3441
3442         Reviewed by Mark Lam.
3443
3444         Add Private attributes to MathCommon.h.
3445
3446         * JavaScriptCore.xcodeproj/project.pbxproj:
3447
3448 2016-06-10  Yusuke Suzuki  <utatane.tea@gmail.com>
3449
3450         [JSC] Inline JSC::toInt32 to improve kraken
3451         https://bugs.webkit.org/show_bug.cgi?id=158619
3452
3453         Reviewed by Mark Lam.
3454
3455         Several kraken benchmarks show that JSC::toInt32 is frequently called.
3456         For example, stanford-crypto-pbkdf2 reports that the hottest runtime function is JSC::toInt32.
3457
3458         The data is below (taken by Linux perf tools).
3459         5.50%  jsc      libJavaScriptCore.so.1.0.0  [.] _ZN3JSC7toInt32Ed
3460         3.96%  jsc      libJavaScriptCore.so.1.0.0  [.] _ZN3JSC20arrayProtoFuncConcatEPNS_9ExecStateE
3461         2.48%  jsc      libJavaScriptCore.so.1.0.0  [.] _ZN3JSC19arrayProtoFuncSliceEPNS_9ExecStateE
3462         1.69%  jsc      libJavaScriptCore.so.1.0.0  [.] _ZNK3JSC9Structure27holesMustForwardToPrototypeERNS_2VME
3463
3464         This is because of CommonSlowPaths' bit operations's JSValue::toInt32.
3465         Due to the slow path, in `value | 0`, `value` may be a double number value. In that case, JSC::toInt32 is called.
3466
3467         While JSC::toIn32 is hot, the function itself is very small. It's worth inlining.
3468
3469         This change offers the following kraken improvements.
3470
3471                                                          baseline                  patched
3472         Kraken:
3473            audio-beat-detection                       47.492+-1.701             46.657+-1.232           might be 1.0179x faster
3474            stanford-crypto-aes                        43.669+-0.210      ^      42.862+-0.115         ^ definitely 1.0188x faster
3475            stanford-crypto-ccm                        45.213+-1.424             44.490+-1.290           might be 1.0162x faster
3476            stanford-crypto-pbkdf2                    107.665+-0.581      ^     106.229+-0.807         ^ definitely 1.0135x faster
3477
3478         This patch only focused on the call to toInt32 from the runtime functions.
3479         So JSC::toInt32 calls from the baseline / DFG remain.
3480         We ensure that JIT code uses operationToInt32 instead of JSC::toInt32 since JSC::toInt32 is now marked as ALWAYS_INLINE.
3481         Linux perf profiler also finds that this `operationToInt32` is frequently called in the above benchmarks.
3482         It may be good to introduce asm emit for that instead of calling JSC::toInt32 operation in the separated patch.
3483
3484         * dfg/DFGSpeculativeJIT.cpp:
3485         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
3486         (JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
3487         * ftl/FTLLowerDFGToB3.cpp:
3488         (JSC::FTL::DFG::LowerDFGToB3::doubleToInt32):
3489         (JSC::FTL::DFG::LowerDFGToB3::sensibleDoubleToInt32):
3490         * runtime/JSCJSValue.cpp:
3491         (JSC::toInt32): Deleted.
3492         * runtime/JSCJSValueInlines.h:
3493         * runtime/MathCommon.cpp:
3494         (JSC::operationToInt32):
3495         * runtime/MathCommon.h:
3496         (JSC::toInt32):
3497
3498 2016-06-10  Filip Pizlo  <fpizlo@apple.com>
3499
3500         The backend should be happy to compile Unreachable even if AI didn't prove it to be unreachable
3501         https://bugs.webkit.org/show_bug.cgi?id=158631
3502
3503         Reviewed by Keith Miller.
3504         
3505         We've been slowly making the DFG Unreachable opcode behave like a grown-up. When we first
3506         added it, it was a hack for Throw, and we could always rely on AI proving that Unreachable
3507         was not reachable. But then we started using Unreachable as a proper Unreachable opcode,
3508         like Oops in B3 for example, which has a more nuanced meaning: you use it whenever you
3509         emit code that *you* know will not return, and you need some way of terminating the basic
3510         block. The DFG is not a proof-carrying compiler, and it never will be. So, when you have
3511         proved that something is not reachable, you should be able to use Unreachable even if
3512         there is no guarantee that the compiler will later be able to replicate your proof. This
3513         means that the backend may find itself compiling Unreachable because AI did not prove that
3514         it was unreachable.
3515         
3516         Prior to this change, we would crash compiling Unreachable because we would rely on AI
3517         preventing us from reaching Unreachable in the backend. But that's silly! We don't want
3518         users of Unreachable to have to also convince AI that their Unreachable is really
3519         Unreachable.
3520         
3521         This fixes crashes on real websites. I couldn't work out how to turn them into a reduced
3522         test.
3523
3524         * assembler/AbortReason.h:
3525         * dfg/DFGSpeculativeJIT.cpp:
3526         (JSC::DFG::SpeculativeJIT::emitInvalidationPoint):
3527         (JSC::DFG::SpeculativeJIT::unreachable):
3528         (JSC::DFG::SpeculativeJIT::terminateSpeculativeExecution):
3529         * dfg/DFGSpeculativeJIT.h:
3530         * dfg/DFGSpeculativeJIT32_64.cpp:
3531         (JSC::DFG::SpeculativeJIT::compile):
3532         * dfg/DFGSpeculativeJIT64.cpp:
3533         (JSC::DFG::SpeculativeJIT::compile):
3534         * ftl/FTLLowerDFGToB3.cpp:
3535         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
3536         (JSC::FTL::DFG::LowerDFGToB3::compilePutDynamicVar):
3537         (JSC::FTL::DFG::LowerDFGToB3::compileUnreachable):
3538         (JSC::FTL::DFG::LowerDFGToB3::compareEqObjectOrOtherToObject):
3539
3540 2016-06-09  Alex Christensen  <achristensen@webkit.org>
3541
3542         Clean up JavaScriptCore.vcxproj directory after switching to CMake.
3543
3544         * JavaScriptCore.vcxproj/LLInt: Removed.
3545         * JavaScriptCore.vcxproj/LLInt/LLIntAssembly: Removed.
3546         * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.make: Removed.
3547         * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/LLIntAssembly.vcxproj: Removed.
3548         * JavaScriptCore.vcxproj/LLInt/LLIntAssembly/build-LLIntAssembly.pl: Removed.
3549         * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets: Removed.
3550         * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.make: Removed.
3551         * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/LLIntDesiredOffsets.vcxproj: Removed.
3552         * JavaScriptCore.vcxproj/LLInt/LLIntDesiredOffsets/build-LLIntDesiredOffsets.pl: Removed.
3553         * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor: Removed.
3554         * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractor.vcxproj: Removed.
3555         * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorCommon.props: Removed.
3556         * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorDebug.props: Removed.
3557         * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorProduction.props: Removed.
3558         * JavaScriptCore.vcxproj/LLInt/LLIntOffsetsExtractor/LLIntOffsetsExtractorRelease.props: Removed.
3559         * JavaScriptCore.vcxproj/jsc: Removed.
3560         * JavaScriptCore.vcxproj/jsc/DLLLauncherMain.cpp: Removed.
3561         * JavaScriptCore.vcxproj/jsc/DLLLauncherWinCairo.props: Removed.
3562         * JavaScriptCore.vcxproj/jsc/jsc.vcxproj: Removed.
3563         * JavaScriptCore.vcxproj/jsc/jsc.vcxproj.filters: Removed.
3564         * JavaScriptCore.vcxproj/jsc/jscCommon.props: Removed.
3565         * JavaScriptCore.vcxproj/jsc/jscDebug.props: Removed.
3566         * JavaScriptCore.vcxproj/jsc/jscLauncher.vcxproj: Removed.
3567         * JavaScriptCore.vcxproj/jsc/jscLauncherPostBuild.cmd: Removed.
3568         * JavaScriptCore.vcxproj/jsc/jscLauncherPreBuild.cmd: Removed.
3569         * JavaScriptCore.vcxproj/jsc/jscLauncherPreLink.cmd: Removed.
3570         * JavaScriptCore.vcxproj/jsc/jscPostBuild.cmd: Removed.
3571         * JavaScriptCore.vcxproj/jsc/jscPreBuild.cmd: Removed.
3572         * JavaScriptCore.vcxproj/jsc/jscPreLink.cmd: Removed.
3573         * JavaScriptCore.vcxproj/jsc/jscProduction.props: Removed.
3574         * JavaScriptCore.vcxproj/jsc/jscRelease.props: Removed.
3575         * JavaScriptCore.vcxproj/testRegExp: Removed.
3576         * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj: Removed.
3577         * JavaScriptCore.vcxproj/testRegExp/testRegExp.vcxproj.filters: Removed.
3578         * JavaScriptCore.vcxproj/testRegExp/testRegExpCommon.props: Removed.
3579         * JavaScriptCore.vcxproj/testRegExp/testRegExpDebug.props: Removed.
3580         * JavaScriptCore.vcxproj/testRegExp/testRegExpLauncher.vcxproj: Removed.
3581         * JavaScriptCore.vcxproj/testRegExp/testRegExpLauncherPostBuild.cmd: Removed.
3582         * JavaScriptCore.vcxproj/testRegExp/testRegExpLauncherPreBuild.cmd: Removed.
3583         * JavaScriptCore.vcxproj/testRegExp/testRegExpLauncherPreLink.cmd: Removed.
3584         * JavaScriptCore.vcxproj/testRegExp/testRegExpPostBuild.cmd: Removed.
3585         * JavaScriptCore.vcxproj/testRegExp/testRegExpPreBuild.cmd: Removed.
3586         * JavaScriptCore.vcxproj/testRegExp/testRegExpPreLink.cmd: Removed.
3587         * JavaScriptCore.vcxproj/testRegExp/testRegExpProduction.props: Removed.
3588         * JavaScriptCore.vcxproj/testRegExp/testRegExpRelease.props: Removed.
3589         * JavaScriptCore.vcxproj/testapi: Removed.
3590         * JavaScriptCore.vcxproj/testapi/testapi.vcxproj: Removed.
3591         * JavaScriptCore.vcxproj/testapi/testapi.vcxproj.filters: Removed.
3592         * JavaScriptCore.vcxproj/testapi/testapiCommon.props: Removed.
3593         * JavaScriptCore.vcxproj/testapi/testapiCommonCFLite.props: Removed.
3594         * JavaScriptCore.vcxproj/testapi/testapiDebug.props: Removed.
3595         * JavaScriptCore.vcxproj/testapi/testapiDebugCFLite.props: Removed.
3596         * JavaScriptCore.vcxproj/testapi/testapiLauncher.vcxproj: Removed.
3597         * JavaScriptCore.vcxproj/testapi/testapiLauncherPostBuild.cmd: Removed.
3598         * JavaScriptCore.vcxproj/testapi/testapiLauncherPreBuild.cmd: Removed.
3599         * JavaScriptCore.vcxproj/testapi/testapiLauncherPreLink.cmd: Removed.
3600         * JavaScriptCore.vcxproj/testapi/testapiPostBuild.cmd: Removed.
3601         * JavaScriptCore.vcxproj/testapi/testapiPreBuild.cmd: Removed.
3602         * JavaScriptCore.vcxproj/testapi/testapiPreLink.cmd: Removed.
3603         * JavaScriptCore.vcxproj/testapi/testapiProduction.props: Removed.
3604         * JavaScriptCore.vcxproj/testapi/testapiRelease.props: Removed.
3605         * JavaScriptCore.vcxproj/testapi/testapiReleaseCFLite.props: Removed.
3606         * shell/DLLLauncherMain.cpp: Copied from JavaScriptCore.vcxproj/jsc/DLLLauncherMain.cpp.
3607         * shell/PlatformWin.cmake:
3608
3609 2016-06-09  Filip Pizlo  <fpizlo@apple.com>
3610
3611         Rare failure in stress/v8-deltablue-strict.js.ftl-eager
3612         https://bugs.webkit.org/show_bug.cgi?id=158591
3613
3614         Reviewed by Saam Barati.
3615         
3616         This is a simple and sensible fix to an amazing compiler bug that previously only
3617         manifested rarely in the v8-deltablue-strict test. It required on average 1000 runs while
3618         the system was under load for the bug to manifest. Fortunately, the bug is 100% repro with
3619         concurrent JIT disabled in the new "constant-fold-multi-get-by-offset-to-get-by-offset-on-
3620         prototype-and-sink-allocation.js" test.
3621         
3622         The problem here is that we were allowing ourselves to be super sloppy with the meaning of
3623         the two children of GetByOffset, and to a lesser extent, PutByOffset. The first two
3624         children of these nodes have these meanings:
3625         
3626         child1: the storage from which to load (or to which to store)
3627         child2: the logical object base
3628         
3629         Normally, child1 == child2, but child1 may point to a node that vends the storage pointer
3630         in case we are using multiple indirections to get to the property. That's fairly common.
3631         
3632         Where this gets nutty is that we don't validate the behavior of child1. Previously, the
3633         DFG::Validate phase would accept code that had child1 point to one object and child2 point
3634         to another object. That's bad because then, analyses will assume that we're loading from
3635         one object while we are actually loading from another. One of the fixes is to make
3636         Validate smarter about this, so that future problems with this get caught sooner.
3637         
3638         The actual bug was in ConstantFoldingPhase. When we first wrote ConstantFoldingPhase's
3639         logic for converting GetByIds and MultiGetByOffsets to GetByOffset, we assumed that this
3640         was only for non-prototype loads. This was becuase the logic was originally written based
3641         on a static GetByIdStatus analysis, which does not handle prototypes. So, as a shortcut,
3642         we would convert the GetById (or MultiGetByOffset) to a GetByOffset by doing this
3643         shuffling of children:
3644         
3645         child1 got the storage pointer, which might be a new GetButterfly node that we created.
3646         child2 got the old value of child1.
3647         
3648         The bug was introduced when I later made it possible for a monomorphic prototype
3649         MultiGetByOffset to be converted to a GetByOffset. Then this algorithm would mean that:
3650         
3651         child1 got either a pointer to the prototype or a storage pointer derived from the
3652             prototype.
3653         child2 got the old value of child1, which was a pointer to the base object (i.e. not the
3654             prototype).
3655         
3656         This happens super rarely because most prototype loads that we can statically reason about
3657         also happen to load constants, so we don't convert to GetByOffset at all. You need the
3658         strange combination of a MultiGetByOffset (not GetById or GetByOffset) on some prototypes
3659         and some static reasoning about the base so that we can convert it to a GetByOffset, but
3660         not enough static reasoning that we can convert it to a constant.
3661         
3662         Even if the bad thing happened, then this is not enough for it to cause symptons. If we
3663         did nothing else - like none of the other optimizations succeeded - then this would
3664         be OK because the backend will emit code based on child1, which is right. But disaster
3665         strikes when the code otherwise looks sane enough for ObjectAllocationSinkingPhase to kick
3666         in. This phase operates on child2, as any good phase should: child1 is only interesting
3667         for knowing *how* to load, not *what* we are loading. The phase is right to ignore child1.
3668
3669         So the phase would assume that we are loading the prototype property ("f" in the new test
3670         or "addToGraph" in deltablue) from the sunken base object allocation in the inlined
3671         constructor. The base object has no such property, but the phase conservatively assumes
3672         that it does indeed have such a property. That's just how the phase does things: it is
3673         very abstract and general, so it assumes that the set of properties on an allocation is
3674         the set of properties that accesses to the allocation speak of. Clearly, this GetByOffset
3675         was speaking of the property as being on the allocation. When sinking completed, it would
3676         convert the GetByOffset to the sunken (a.k.a. promoted) property. But nobody stored to
3677         this property on the allocation, so we'd get the bottom value, which is 1927. Why 1927? I
3678         don't remember anymore, but apparently I chose it. It helped here - when I started seeing
3679         that value come up, it took a quick grep to realize that this was the object allocation
3680         sinking phase's bottom value.
3681         
3682         The real fix to the bug is to make Node::convertToGetByOffset() take an explicit new base
3683         since its clients will use it to potentially create a load on a different object than the
3684         base of the original operation, as in the relatively new
3685         MultiGetByOffset(prototype)->GetByOffset optimization. As far as I know, the PutByOffset
3686         code did not have the same bug because we don't have any optimizations that turn a PutById
3687         or MultiPutByOffset into a PutByOffset on anything but the base object. But the logical
3688         bug is definitely there: there's code in ConstantFoldingPhase that claims to be able to
3689         convert any node to a PutByOffset on any base, but it actually silently reuses the
3690         original node's child1 as the logical base (i.e. child2). This patch makes all of this
3691         stuff explicit. You can't make this mistake anymore.
3692
3693         * dfg/DFGConstantFoldingPhase.cpp:
3694         (JSC::DFG::ConstantFoldingPhase::emitGetByOffset):
3695         (JSC::DFG::ConstantFoldingPhase::emitPutByOffset):
3696         * dfg/DFGNode.h:
3697         (JSC::DFG::Node::convertToGetStack):
3698         (JSC::DFG::Node::convertToGetByOffset):
3699         (JSC::DFG::Node::convertToMultiGetByOffset):
3700         (JSC::DFG::Node::convertToPutByOffset):
3701         * dfg/DFGValidate.cpp:
3702         * tests/stress/constant-fold-multi-get-by-offset-to-get-by-offset-on-prototype-and-sink-allocation.js: Added.
3703         (ThingA):
3704         (ThingB):
3705         (foo):
3706         (bar):
3707         * tests/stress/sink-to-impossible-multi-get-by-offset-on-prototypes.js: Added.
3708         (ThingA):
3709         (ThingB):
3710         (ThingC):
3711         (bar):
3712         (foo):
3713
3714 2016-06-09  Mark Lam  <mark.lam@apple.com>
3715
3716         Make some methods const.
3717         https://bugs.webkit.org/show_bug.cgi?id=158594
3718
3719         Reviewed by Benjamin Poulain.
3720
3721         * bytecode/CodeBlock.cpp:
3722         (JSC::CodeBlock::columnNumberForBytecodeOffset):
3723         (JSC::CodeBlock::expressionRangeForBytecodeOffset):
3724         * bytecode/CodeBlock.h:
3725         * bytecode/ExpressionRangeInfo.h:
3726         (JSC::ExpressionRangeInfo::encodeFatColumnMode):
3727         (JSC::ExpressionRangeInfo::decodeFatLineMode):
3728         (JSC::ExpressionRangeInfo::decodeFatColumnMode):
3729         * bytecode/UnlinkedCodeBlock.cpp:
3730         (JSC::UnlinkedCodeBlock::lineNumberForBytecodeOffset):
3731         (JSC::UnlinkedCodeBlock::getLineAndColumn):
3732         (JSC::UnlinkedCodeBlock::expressionRangeForBytecodeOffset):
3733         * bytecode/UnlinkedCodeBlock.h:
3734         (JSC::UnlinkedCodeBlock::createRareDataIfNecessary):
3735         * interpreter/Interpreter.cpp:
3736         (JSC::Interpreter::isOpcode):
3737         (JSC::StackFrame::computeLineAndColumn):
3738         (JSC::StackFrame::toString):
3739         * interpreter/Interpreter.h:
3740         (JSC::StackFrame::isNative):
3741
3742 2016-06-09  Michael Saboff  <msaboff@apple.com>
3743
3744         ES6: Reusing function name as a parameter name shouldn't throw Syntax Error
3745         https://bugs.webkit.org/show_bug.cgi?id=158575
3746
3747         Reviewed by Benjamin Poulain.
3748
3749         The check for a parameter with a duplicate name doesn't take into account the
3750         type of the prior variable.  Added a check that the duplicate is also a
3751         parameter.
3752
3753         See the relevant spec section at:
3754         http://www.ecma-international.org/ecma-262/6.0/#sec-function-definitions-static-semantics-early-errors
3755
3756         * parser/Parser.h:
3757         (JSC::Scope::declareParameter):
3758
3759 2016-06-09  Chris Dumez  <cdumez@apple.com>
3760
3761         Unreviewed, rolling out r201836, r201845, and r201848.
3762
3763         Looks like a 1-2% PLT regression on iOS
3764
3765         Reverted changesets:
3766
3767         "[JSC] Change some parameters based on a random search"
3768         https://bugs.webkit.org/show_bug.cgi?id=158514
3769         http://trac.webkit.org/changeset/201836
3770
3771         "Tempory fix for the debug bots"
3772         http://trac.webkit.org/changeset/201845
3773
3774         "Change thresholdForOptimizeSoon to match
3775         thresholdForOptimizeAfterWarmUp"
3776         http://trac.webkit.org/changeset/201848
3777
3778 2016-06-09  Commit Queue  <commit-queue@webkit.org>
3779
3780         Unreviewed, rolling out r201810.
3781         https://bugs.webkit.org/show_bug.cgi?id=158563
3782
3783         breaks build without ENABLE_WEB_ANIMATION (Requested by
3784         mcatanzaro on #webkit).
3785
3786         Reverted changeset:
3787
3788         "[web-animations] Add Animatable, AnimationEffect,
3789         KeyframeEffect and Animation interface"
3790         https://bugs.webkit.org/show_bug.cgi?id=156096
3791         http://trac.webkit.org/changeset/201810
3792
3793 2016-06-08  Gavin & Ellie Barraclough  <barraclough@apple.com>
3794
3795         JSObject::reifyAllStaticProperties cleanup
3796         https://bugs.webkit.org/show_bug.cgi?id=158543
3797
3798         Reviewed by Mark Lam.
3799
3800         - JSObject & Structure contain fields labeled 'staticFunctionsReified', however reification now
3801           affects all properties, not just functions. Rename to 'staticPropertiesReified'.
3802         - reifyAllStaticProperties relies on a 'hasStaticProperties' method on ClassInfo that walks the
3803           ClassInfo inheritance chain looking for static property tables. We can now more efficiently
3804           get this information from TypeInfo.
3805         - reifyAllStaticProperties triggers a 'toUncacheableDictionaryTransition'; this is overzealous,
3806           cacheable dictionary is sufficient - this is what we do in the case of DOM prototype property
3807           reification (see 'reifyStaticProperties' in Lookup.h). (Changing this with an eye on switching
3808           DOM prototype property reification to use JSObject:: reifyAllStaticProperties, rather than
3809           having its own special purpose code path.)
3810
3811         * runtime/ClassInfo.h:
3812         (JSC::ClassInfo::hasStaticProperties): Deleted.
3813             - deprecated by TypeInfo::hasStaticPropertyTable.
3814         * runtime/JSObject.cpp:
3815         (JSC::JSObject::putInlineSlow):
3816         (JSC::JSObject::deleteProperty):
3817         (JSC::JSObject::getOwnNonIndexPropertyNames):
3818             - staticFunctionsReified -> staticPropertiesReified
3819         (JSC::JSObject::reifyAllStaticProperties):
3820             - hasStaticProperties -> TypeInfo::hasStaticPropertyTable
3821             - toUncacheableDictionaryTransition -> toCacheableDictionaryTransition
3822             - staticFunctionsReified -> staticPropertiesReified
3823         * runtime/JSObject.h:
3824         (JSC::JSObject::staticPropertiesReified):
3825         (JSC::JSObject::staticFunctionsReified): Deleted.
3826         * runtime/Lookup.cpp: