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