Cannot call initializeIndex() if we didn't create the array using tryCreateUninitiali...
[WebKit-https.git] / Source / JavaScriptCore / ChangeLog
1 2016-02-11  Filip Pizlo  <fpizlo@apple.com>
2
3         Cannot call initializeIndex() if we didn't create the array using tryCreateUninitialized()
4         https://bugs.webkit.org/show_bug.cgi?id=154126
5
6         Reviewed by Saam Barati.
7
8         * runtime/ArrayPrototype.cpp:
9         (JSC::arrayProtoFuncSplice):
10
11 2016-02-11  Sukolsak Sakshuwong  <sukolsak@gmail.com>
12
13         [INTL] Implement Intl.NumberFormat.prototype.resolvedOptions ()
14         https://bugs.webkit.org/show_bug.cgi?id=147602
15
16         Reviewed by Darin Adler.
17
18         This patch implements Intl.NumberFormat.prototype.resolvedOptions() according
19         to the ECMAScript 2015 Internationalization API spec (ECMA-402 2nd edition.)
20
21         * runtime/IntlDateTimeFormat.cpp:
22         (JSC::localeData):
23         * runtime/IntlNumberFormat.cpp:
24         (JSC::localeData):
25         (JSC::computeCurrencySortKey):
26         (JSC::extractCurrencySortKey):
27         (JSC::computeCurrencyDigits):
28         (JSC::IntlNumberFormat::initializeNumberFormat):
29         (JSC::IntlNumberFormat::styleString):
30         (JSC::IntlNumberFormat::currencyDisplayString):
31         (JSC::IntlNumberFormat::resolvedOptions):
32         (JSC::IntlNumberFormat::setBoundFormat):
33         * runtime/IntlNumberFormat.h:
34         * runtime/IntlNumberFormatConstructor.cpp:
35         (JSC::constructIntlNumberFormat):
36         (JSC::callIntlNumberFormat):
37         * runtime/IntlNumberFormatPrototype.cpp:
38         (JSC::IntlNumberFormatPrototypeFuncResolvedOptions):
39         * runtime/IntlObject.cpp:
40         (JSC::intlNumberOption):
41         (JSC::numberingSystemsForLocale):
42         (JSC::getNumberingSystemsForLocale): Deleted.
43         * runtime/IntlObject.h:
44
45 2016-02-11  Filip Pizlo  <fpizlo@apple.com>
46
47         MacroAssemblerX86 should be happy with shift(cx, cx)
48         https://bugs.webkit.org/show_bug.cgi?id=154124
49
50         Reviewed by Saam Barati.
51
52         Prior to this change the assembler asserted that shift_amount and dest cannot be the same.
53         That's a good assertion for when shift_amount is not in cx. But if it's in cx already then
54         it's OK for them to be the same. Air will sometimes do shift(cx, cx) if you do "x << x" and
55         the coalescing got particularly clever.
56
57         * assembler/MacroAssemblerX86Common.h:
58         (JSC::MacroAssemblerX86Common::lshift32):
59         (JSC::MacroAssemblerX86Common::rshift32):
60         (JSC::MacroAssemblerX86Common::urshift32):
61         * assembler/MacroAssemblerX86_64.h:
62         (JSC::MacroAssemblerX86_64::lshift64):
63         (JSC::MacroAssemblerX86_64::rshift64):
64         (JSC::MacroAssemblerX86_64::urshift64):
65         * b3/testb3.cpp:
66         (JSC::B3::testLShiftSelf32):
67         (JSC::B3::testRShiftSelf32):
68         (JSC::B3::testURShiftSelf32):
69         (JSC::B3::testLShiftSelf64):
70         (JSC::B3::testRShiftSelf64):
71         (JSC::B3::testURShiftSelf64):
72         (JSC::B3::run):
73
74 2016-02-11  Saam barati  <sbarati@apple.com>
75
76         The sampling profiler's stack walker methods should be marked with SUPPRESS_ASAN
77         https://bugs.webkit.org/show_bug.cgi?id=154123
78
79         Reviewed by Mark Lam.
80
81         The entire premise of the sampling profiler is to load from
82         another thread's memory. We should SUPPRESS_ASAN on the
83         methods that do this.
84
85         * runtime/SamplingProfiler.cpp:
86         (JSC::FrameWalker::FrameWalker):
87         (JSC::FrameWalker::walk):
88         (JSC::FrameWalker::advanceToParentFrame):
89         (JSC::FrameWalker::isAtTop):
90         (JSC::FrameWalker::resetAtMachineFrame):
91
92 2016-02-11  Csaba Osztrogonác  <ossy@webkit.org>
93
94         Unreviewed typo fix after r190063.
95
96         * dfg/DFGSpeculativeJIT.cpp: Removed property svn:executable.
97         * dfg/DFGSpeculativeJIT.h: Removed property svn:executable.
98         * jit/JIT.h: Removed property svn:executable.
99         * jit/JITInlines.h: Removed property svn:executable.
100         * jit/JITOpcodes.cpp: Removed property svn:executable.
101
102 2016-02-11  Csaba Osztrogonác  <ossy@webkit.org>
103
104         Unreviewed typo fix after r190063.
105
106         * dfg/DFGSpeculativeJIT.cpp: Removed property svn:executable.
107         * dfg/DFGSpeculativeJIT.h: Removed property svn:executable.
108         * jit/JIT.h: Removed property svn:executable.
109         * jit/JITInlines.h: Removed property svn:executable.
110         * jit/JITOpcodes.cpp: Removed property svn:executable.
111
112 2016-02-10  Keith Miller  <keith_miller@apple.com>
113
114         Symbol.species accessors on builtin constructors should be configurable
115         https://bugs.webkit.org/show_bug.cgi?id=154097
116
117         Reviewed by Benjamin Poulain.
118
119         We did not have the Symbol.species accessors on our builtin constructors
120         marked as configurable. This does not accurately follow the ES6 spec as
121         the ES6 spec states that all default accessors on builtins should be
122         configurable. This means that we need an additional watchpoint on
123         ArrayConstructor to make sure that no users re-configures Symbol.species.
124
125         * runtime/ArrayConstructor.cpp:
126         (JSC::ArrayConstructor::finishCreation):
127         * runtime/ArrayPrototype.cpp:
128         (JSC::speciesConstructArray):
129         (JSC::ArrayPrototype::setConstructor):
130         (JSC::ArrayPrototypeAdaptiveInferredPropertyWatchpoint::handleFire):
131         * runtime/ArrayPrototype.h:
132         (JSC::ArrayPrototype::didChangeConstructorOrSpeciesProperties):
133         (JSC::ArrayPrototype::didChangeConstructorProperty): Deleted.
134         * runtime/JSArrayBufferConstructor.cpp:
135         (JSC::JSArrayBufferConstructor::finishCreation):
136         * runtime/JSPromiseConstructor.cpp:
137         (JSC::JSPromiseConstructor::finishCreation):
138         * runtime/JSTypedArrayViewConstructor.cpp:
139         (JSC::JSTypedArrayViewConstructor::finishCreation):
140         * runtime/MapConstructor.cpp:
141         (JSC::MapConstructor::finishCreation):
142         * runtime/RegExpConstructor.cpp:
143         (JSC::RegExpConstructor::finishCreation):
144         * runtime/SetConstructor.cpp:
145         (JSC::SetConstructor::finishCreation):
146         * tests/stress/array-species-config-array-constructor.js: Added.
147         (A):
148         * tests/stress/symbol-species.js:
149         (testSymbolSpeciesOnConstructor):
150
151 2016-02-10  Benjamin Poulain  <benjamin@webkit.org>
152
153         [JSC] The destination of Sqrt should be Def, not UseDef
154         https://bugs.webkit.org/show_bug.cgi?id=154086
155
156         Reviewed by Geoffrey Garen.
157
158         An unfortunate copy-paste: the destination of SqrtDouble and SqrtFloat
159         was defined as UseDef. As a result, the argument would be interfering
160         with everything defined prior.
161
162         * b3/air/AirOpcode.opcodes:
163
164 2016-02-10  Chris Dumez  <cdumez@apple.com>
165
166         [Web IDL] interface objects should be Function objects
167         https://bugs.webkit.org/show_bug.cgi?id=154038
168         <rdar://problem/24569358>
169
170         Reviewed by Geoffrey Garen.
171
172         Update functionProtoFuncToString() to handle JSObjects that
173         have the TypeOfShouldCallGetCallData flag and are callable,
174         as these behave like functions and use ClassInfo::className()
175         as function name in this case.
176
177         * runtime/FunctionPrototype.cpp:
178         (JSC::functionProtoFuncToString):
179
180 2016-02-10  Chris Dumez  <cdumez@apple.com>
181
182         Attributes on the Window instance should be configurable unless [Unforgeable]
183         https://bugs.webkit.org/show_bug.cgi?id=153920
184         <rdar://problem/24563211>
185
186         Reviewed by Darin Adler.
187
188         Marking the Window instance attributes as configurable but cause
189         getOwnPropertyDescriptor() to report them as configurable, as
190         expected. However, trying to delete them would actually lead to
191         unexpected behavior because:
192         - We did not reify custom accessor properties (most of the Window
193           properties are custom accessors) upon deletion.
194         - For non-reified static properties marked as configurable,
195           JSObject::deleteProperty() would attempt to call the property
196           setter with undefined. As a result, calling delete window.name
197           would cause window.name to become the string "undefined" instead
198           of the undefined value.
199
200         * runtime/JSObject.cpp:
201         (JSC::getClassPropertyNames):
202         Now that we reify ALL properties, we only need to check the property table
203         if we have not reified. As a result, I dropped the 'didReify' parameter for
204         this function and instead only call this function if we have not yet reified.
205
206         (JSC::JSObject::putInlineSlow):
207         Only call putEntry() if we have not reified: Drop the
208         '|| !(entry->attributes() & BuiltinOrFunctionOrAccessor)'
209         check as such properties now get reified as well.
210
211         (JSC::JSObject::deleteProperty):
212         - Call reifyAllStaticProperties() instead of reifyStaticFunctionsForDelete()
213           so that we now reify all properties upon deletion, including the custom
214           accessors. reifyStaticFunctionsForDelete() is now removed and the same
215           reification function is now used by: deletion, getOwnPropertyDescriptor()
216           and eager reification of the prototype objects in the bindings.
217         - Drop code that falls back to calling the static property setter with
218           undefined if we cannot find the property in the property storage. As
219           we now reify ALL properties, the code removing the property from the
220           property storage should succeed, provided that the property actually
221           exists.
222
223         (JSC::JSObject::getOwnNonIndexPropertyNames):
224         Only call getClassPropertyNames() if we have not reified. We should no longer
225         check the static property table after reifying now that we reify all
226         properties.
227
228         (JSC::JSObject::reifyAllStaticProperties):
229         Merge with reifyStaticFunctionsForDelete(). The only behavior change is the
230         flattening to an uncacheable dictionary, like reifyStaticFunctionsForDelete()
231         used to do.
232
233         * runtime/JSObject.h:
234
235 2016-02-10  Commit Queue  <commit-queue@webkit.org>
236
237         Unreviewed, rolling out r196251.
238         https://bugs.webkit.org/show_bug.cgi?id=154078
239
240         Large regression on Dromaeo needs explanation (Requested by
241         kling on #webkit).
242
243         Reverted changeset:
244
245         "Visiting a WeakBlock should report bytes visited, since we
246         reported them allocated."
247         https://bugs.webkit.org/show_bug.cgi?id=153978
248         http://trac.webkit.org/changeset/196251
249
250 2016-02-10  Csaba Osztrogonác  <ossy@webkit.org>
251
252         REGRESSION(r196331): It made ~180 JSC tests crash on ARMv7 Linux
253         https://bugs.webkit.org/show_bug.cgi?id=154064
254
255         Reviewed by Mark Lam.
256
257         * bytecode/PolymorphicAccess.cpp:
258         (JSC::AccessCase::generate): Added EABI_32BIT_DUMMY_ARG where it is necessary.
259         * dfg/DFGSpeculativeJIT.h: Fixed the comment.
260         * jit/CCallHelpers.h:
261         (JSC::CCallHelpers::setupArgumentsWithExecState): Added.
262         * wasm/WASMFunctionCompiler.h: Fixed the comment.
263
264 2016-02-09  Keith Miller  <keith_miller@apple.com>
265
266         calling methods off super in a class constructor should check for TDZ
267         https://bugs.webkit.org/show_bug.cgi?id=154060
268
269         Reviewed by Ryosuke Niwa.
270
271         In a class constructor we need to check for TDZ when calling a method
272         off the super class. This is because, for super method calls, we use
273         the derived class's newly constructed object as the super method's
274         this value.
275
276         * bytecompiler/NodesCodegen.cpp:
277         (JSC::FunctionCallDotNode::emitBytecode):
278         * tests/stress/super-method-calls-check-tdz.js: Added.
279         (Base):
280         (Derived):
281         (test):
282
283 2016-02-09  Filip Pizlo  <fpizlo@apple.com>
284
285         Don't crash if we fail to parse a builtin
286         https://bugs.webkit.org/show_bug.cgi?id=154047
287         rdar://problem/24300617
288
289         Reviewed by Mark Lam.
290
291         Crashing probably seemed like a good idea at the time, but we could get here in case of a
292         near stack overflow, so that the parser bails because of recursion.
293
294         * parser/Parser.h:
295         (JSC::parse):
296
297 2016-02-07  Gavin Barraclough  <barraclough@apple.com>
298
299         GetValueFunc/PutValueFunc should not take both slotBase and thisValue
300         https://bugs.webkit.org/show_bug.cgi?id=154009
301
302         Reviewed by Geoff Garen.
303
304         In JavaScript there are two types of properties - regular value properties, and accessor properties.
305         One difference between these is how they are reflected by getOwnPropertyDescriptor, and another is
306         what object they operate on in the case of a prototype access. If you access a value property of a
307         prototype object it return a value pertinent to the prototype, but in the case of a prototype object
308         returning an accessor, then the accessor function is applied to the base object of the access.
309
310         JSC supports special 'custom' properties implemented as a c++ callback, and these custom properties
311         can be used to implement either value- or accessor-like behavior. getOwnPropertyDescriptor behavior
312         is selected via the CustomAccessor attribute. Value- or accessor-like object selection is current
313         supported by passing both the slotBase and the thisValue to the callback,and hoping it uses the
314         right one. This is probably inefficient, bug-prone, and leads to crazy like JSBoundSlotBaseFunction.
315
316         Instead, just pass one thisValue to the callback functions, consistent with CustomAccessor.
317
318         * API/JSCallbackObject.h:
319         * API/JSCallbackObjectFunctions.h:
320         (JSC::JSCallbackObject<Parent>::getStaticValue):
321         (JSC::JSCallbackObject<Parent>::staticFunctionGetter):
322         (JSC::JSCallbackObject<Parent>::callbackGetter):
323             - Merged slotBase & thisValue to custom property callbacks.
324         * bytecode/PolymorphicAccess.cpp:
325         (JSC::AccessCase::generate):
326             - Modified the call being JIT generated - GetValueFunc/PutValueFunc now only take 3,
327               rather than 4 arguments. Selects which one to keep/drop based on access type.
328         (WTF::printInternal):
329         * bytecode/PolymorphicAccess.h:
330         (JSC::AccessCase::isGet):
331         (JSC::AccessCase::isPut):
332         (JSC::AccessCase::isIn):
333         (JSC::AccessCase::doesCalls):
334         (JSC::AccessCase::isGetter):
335         * bytecode/PutByIdStatus.cpp:
336         (JSC::PutByIdStatus::computeForStubInfo):
337         * jit/Repatch.cpp:
338         (JSC::tryCacheGetByID):
339         (JSC::tryCachePutByID):
340             - Split the CustomGetter/Setter access types into Value/Accessor variants.
341         * jsc.cpp:
342         (WTF::CustomGetter::getOwnPropertySlot):
343         (WTF::CustomGetter::customGetter):
344         (WTF::RuntimeArray::RuntimeArray):
345         (WTF::RuntimeArray::lengthGetter):
346             - Merged slotBase & thisValue to custom property callbacks.
347         * runtime/CustomGetterSetter.cpp:
348         (JSC::callCustomSetter):
349             - Pass 3 arguments when calling PutValueFunc.
350         * runtime/CustomGetterSetter.h:
351         * runtime/JSBoundSlotBaseFunction.cpp:
352         (JSC::boundSlotBaseFunctionCall):
353         (JSC::JSBoundSlotBaseFunction::JSBoundSlotBaseFunction):
354         * runtime/JSCJSValue.cpp:
355         (JSC::JSValue::putToPrimitive):
356             - callCustomSetter currently takes a flag to distinguish value/accessor calls.
357         * runtime/JSFunction.cpp:
358         (JSC::retrieveArguments):
359         (JSC::JSFunction::argumentsGetter):
360         (JSC::retrieveCallerFunction):
361         (JSC::JSFunction::callerGetter):
362         (JSC::JSFunction::lengthGetter):
363         (JSC::JSFunction::nameGetter):
364         * runtime/JSFunction.h:
365         * runtime/JSModuleNamespaceObject.cpp:
366         (JSC::JSModuleNamespaceObject::visitChildren):
367         (JSC::callbackGetter):
368             - Merged slotBase & thisValue to custom property callbacks.
369         * runtime/JSObject.cpp:
370         (JSC::JSObject::putInlineSlow):
371             - callCustomSetter currently takes a flag to distinguish value/accessor calls.
372         * runtime/Lookup.h:
373         (JSC::putEntry):
374             - split PutPropertySlot setCustom into Value/Accessor variants.
375         * runtime/PropertySlot.cpp:
376         (JSC::PropertySlot::functionGetter):
377         (JSC::PropertySlot::customGetter):
378         * runtime/PropertySlot.h:
379         (JSC::PropertySlot::PropertySlot):
380         (JSC::PropertySlot::getValue):
381             - added customGetter helper to call GetValueFunc.
382         * runtime/PutPropertySlot.h:
383         (JSC::PutPropertySlot::PutPropertySlot):
384         (JSC::PutPropertySlot::setNewProperty):
385         (JSC::PutPropertySlot::setCustomValue):
386         (JSC::PutPropertySlot::setCustomAccessor):
387         (JSC::PutPropertySlot::setThisValue):
388         (JSC::PutPropertySlot::customSetter):
389         (JSC::PutPropertySlot::context):
390         (JSC::PutPropertySlot::isStrictMode):
391         (JSC::PutPropertySlot::isCacheablePut):
392         (JSC::PutPropertySlot::isCacheableSetter):
393         (JSC::PutPropertySlot::isCacheableCustom):
394         (JSC::PutPropertySlot::isCustomAccessor):
395         (JSC::PutPropertySlot::isInitialization):
396         (JSC::PutPropertySlot::cachedOffset):
397         (JSC::PutPropertySlot::setCustomProperty): Deleted.
398             - split PutPropertySlot setCustom into Value/Accessor variants.
399         * runtime/RegExpConstructor.cpp:
400         (JSC::RegExpConstructor::getOwnPropertySlot):
401         (JSC::regExpConstructorDollar1):
402         (JSC::regExpConstructorDollar2):
403         (JSC::regExpConstructorDollar3):
404         (JSC::regExpConstructorDollar4):
405         (JSC::regExpConstructorDollar5):
406         (JSC::regExpConstructorDollar6):
407         (JSC::regExpConstructorDollar7):
408         (JSC::regExpConstructorDollar8):
409         (JSC::regExpConstructorDollar9):
410         (JSC::regExpConstructorInput):
411         (JSC::regExpConstructorMultiline):
412         (JSC::regExpConstructorLastMatch):
413         (JSC::regExpConstructorLastParen):
414         (JSC::regExpConstructorLeftContext):
415         (JSC::regExpConstructorRightContext):
416         (JSC::setRegExpConstructorInput):
417         (JSC::setRegExpConstructorMultiline):
418         * runtime/RegExpObject.cpp:
419         (JSC::RegExpObject::defineOwnProperty):
420         (JSC::regExpObjectSetLastIndexStrict):
421         (JSC::regExpObjectSetLastIndexNonStrict):
422         (JSC::RegExpObject::put):
423             - Merged slotBase & thisValue to custom property callbacks.
424
425 2016-02-09  Filip Pizlo  <fpizlo@apple.com>
426
427         Spread expressions are not fair game for direct binding
428         https://bugs.webkit.org/show_bug.cgi?id=154042
429         rdar://problem/24291413
430
431         Reviewed by Saam Barati.
432
433         Prior to this change we crashed on this:
434
435             var [x] = [...y];
436
437         Because NodesCodegen thinks that this is a direct binding.  It's not, because we cannot
438         directly generate bytecode for "...y".  This is a unique property of spread expressions, so
439         its sufficient to just bail out of direct binding if we see a spread expression. That's what
440         this patch does.
441
442         * bytecompiler/NodesCodegen.cpp:
443         (JSC::ArrayPatternNode::emitDirectBinding):
444         * tests/stress/spread-in-tail.js: Added.
445         (foo):
446         (catch):
447
448 2016-02-09  Commit Queue  <commit-queue@webkit.org>
449
450         Unreviewed, rolling out r196286.
451         https://bugs.webkit.org/show_bug.cgi?id=154026
452
453         Looks like 5% iOS PLT regression (Requested by kling on
454         #webkit).
455
456         Reverted changeset:
457
458         "[iOS] Throw away some unlinked code when navigating to a new
459         page."
460         https://bugs.webkit.org/show_bug.cgi?id=154014
461         http://trac.webkit.org/changeset/196286
462
463 2016-02-08  Keith Miller  <keith_miller@apple.com>
464
465         Error construction for inlined operations should not use the inliner's CodeBlock
466         https://bugs.webkit.org/show_bug.cgi?id=154021
467
468         Reviewed by Mark Lam.
469
470         Previously, if one function, A, was inlined into another function, B, in the DFG/FTL
471         we would use B's DFG/FTL CodeBlock to construct source information about the Error.
472         We would correctly compute the bytecodeOffset in A for the an expression but we would
473         not use one of A's CodeBlocks when looking up source. This caused crashes during
474         operationIn as we expected to be able to find the text "in" in the source.
475
476         * runtime/ErrorInstance.cpp:
477         (JSC::appendSourceToError):
478         * tests/stress/inlined-error-gets-correct-codeblock-for-bytecodeoffset.js: Added.
479         (map):
480         (n):
481         (one):
482         (catch):
483
484 2016-02-08  Saam Barati  <sbarati@apple.com>
485
486         runtimeTypeForValue should protect against seeing TDZ value
487         https://bugs.webkit.org/show_bug.cgi?id=154023
488         rdar://problem/24291413
489
490         Reviewed by Michael Saboff.
491
492         There are a few back traces I've seen from crashes that bottom out
493         inside runtimeTypeForValue. I haven't been able to reproduce
494         any such crash, but it's likely that we're encountering the
495         empty JSValue. It's better to just have this function protect
496         against seeing the empty value instead of dereferencing a null
497         pointer when it thinks the value is a cell.
498
499         * runtime/RuntimeType.cpp:
500         (JSC::runtimeTypeForValue):
501
502 2016-02-08  Andreas Kling  <akling@apple.com>
503
504         [iOS] Throw away some unlinked code when navigating to a new page.
505         <https://webkit.org/b/154014>
506
507         Reviewed by Gavin Barraclough.
508
509         * runtime/VM.cpp:
510         (JSC::VM::deleteAllCodeExceptCaches):
511         (JSC::VM::deleteAllLinkedCode): Deleted.
512         * runtime/VM.h:
513
514 2016-02-08  Filip Pizlo  <fpizlo@apple.com>
515
516         B3::foldPathConstants() needs to execute its insertion set
517         https://bugs.webkit.org/show_bug.cgi?id=154020
518
519         Reviewed by Saam Barati.
520
521         * b3/B3FoldPathConstants.cpp:
522         * b3/testb3.cpp:
523         (JSC::B3::testFoldPathEqual): Added this. It used to crash in validation.
524         (JSC::B3::run):
525
526 2016-02-08  Yusuke Suzuki  <utatane.tea@gmail.com>
527
528         [JSC] Introduce @isObject bytecode intrinsic and use it instead of JS implemented one
529         https://bugs.webkit.org/show_bug.cgi?id=153976
530
531         Reviewed by Darin Adler.
532
533         Use bytecode op_is_object directly.
534
535         * builtins/GlobalObject.js:
536         (isObject): Deleted.
537         * bytecode/BytecodeIntrinsicRegistry.h:
538         * bytecompiler/NodesCodegen.cpp:
539         (JSC::BytecodeIntrinsicNode::emit_intrinsic_toString):
540         (JSC::BytecodeIntrinsicNode::emit_intrinsic_isObject):
541         * runtime/JSGlobalObject.cpp:
542         (JSC::JSGlobalObject::init): Deleted.
543
544 2016-02-08  Yusuke Suzuki  <utatane.tea@gmail.com>
545
546         {Map,Set}.prototype.forEach should be visible as own properties
547         https://bugs.webkit.org/show_bug.cgi?id=153974
548
549         Reviewed by Darin Adler.
550
551         Now, Map and Set uses builtin tables. We should inlude it in class info.
552
553         * runtime/MapPrototype.cpp:
554         * runtime/SetPrototype.cpp:
555
556 2016-02-08  Filip Pizlo  <fpizlo@apple.com>
557
558         Baseline JIT should not require its input to be constant-propagated
559         https://bugs.webkit.org/show_bug.cgi?id=154011
560         rdar://problem/24290933
561
562         Reviewed by Mark Lam.
563
564         * jit/JITArithmetic.cpp:
565         (JSC::JIT::emitBitBinaryOpFastPath):
566         (JSC::JIT::emitRightShiftFastPath):
567         (JSC::JIT::emit_op_add):
568         (JSC::JIT::emit_op_div):
569         (JSC::JIT::emit_op_mul):
570
571 2016-02-08  Filip Pizlo  <fpizlo@apple.com>
572
573         CodeCache should give up on evals if there are variables under TDZ
574         https://bugs.webkit.org/show_bug.cgi?id=154002
575         rdar://problem/24300998
576
577         Reviewed by Mark Lam.
578
579         Disable the code cache optimization because our approach to TDZ for scoped variables - using
580         a separate check_tdz opcode when logically it's the get_from_scope's job to do it - makes
581         caching code impossible if there are any variables in TDZ.
582
583         We should do the right thing in the future, and fold the TDZ check into the get_from_scope.
584         This is better not only because it will restore caching, but because our bytecode for heap
585         accesses is usually at the highest practically doable level of abstraction, so that ICs,
586         compilers and caches can see the intended meaning of the bytecode more easily.
587
588         This doesn't appear to slow anything down, but that's just because we don't have enough ES6
589         benchmarks. I've filed: https://bugs.webkit.org/show_bug.cgi?id=154010
590
591         * runtime/CodeCache.cpp:
592         (JSC::CodeCache::getGlobalCodeBlock):
593
594 2016-02-08  Skachkov Oleksandr  <gskachkov@gmail.com>
595
596         [ES6] Arrow function syntax. Using 'super' in arrow function that declared out of the class should lead to Syntax error
597         https://bugs.webkit.org/show_bug.cgi?id=150893
598
599         Reviewed by Saam Barati.
600
601         'super' and 'super()' inside of the arrow function should lead to syntax error if they are used 
602         out of the class context or they wrapped by ordinary function. Now JSC returns ReferenceError but 
603         should return SyntaxError according to the following specs:
604         http://www.ecma-international.org/ecma-262/6.0/#sec-function-definitions-static-semantics-early-errors
605         and http://www.ecma-international.org/ecma-262/6.0/#sec-arrow-function-definitions-runtime-semantics-evaluation 
606         Curren patch implemented only one case when super/super() are used inside of the arrow function
607         Case when super/super() are used within the eval:
608            class A {} 
609            class B extends A { 
610                costructor() { eval("super()");} 
611            }
612         is not part of this patch and will be implemented in this issue https://bugs.webkit.org/show_bug.cgi?id=153864. 
613         The same for case when eval with super/super() is invoked in arrow function will be 
614         implemented in issue https://bugs.webkit.org/show_bug.cgi?id=153977. 
615  
616         * parser/Parser.cpp:
617         (JSC::Parser<LexerType>::parseFunctionInfo):
618         * parser/Parser.h:
619         (JSC::Scope::Scope):
620         (JSC::Scope::setExpectedSuperBinding):
621         (JSC::Scope::expectedSuperBinding):
622         (JSC::Scope::setConstructorKind):
623         (JSC::Scope::constructorKind):
624         (JSC::Parser::closestParentNonArrowFunctionNonLexicalScope):
625         * tests/stress/arrowfunction-lexical-bind-supercall-4.js:
626         * tests/stress/arrowfunction-lexical-bind-superproperty.js:
627
628 2016-02-08  Filip Pizlo  <fpizlo@apple.com>
629
630         Parser should detect error before calls to parseAssignmentExpression()
631         https://bugs.webkit.org/show_bug.cgi?id=153975
632         rdar://problem/24291231
633
634         Reviewed by Saam Barati.
635
636         Fixes a very hard-to-create situation that an internal test picked up.
637
638         * parser/Parser.cpp:
639         (JSC::Parser<LexerType>::parseVariableDeclarationList):
640         (JSC::Parser<LexerType>::parseAssignmentExpression):
641
642 2016-02-08  Andreas Kling  <akling@apple.com>
643
644         Visiting a WeakBlock should report bytes visited, since we reported them allocated.
645         <https://webkit.org/b/153978>
646
647         Reviewed by Darin Adler.
648
649         When creating a WeakBlock, we tell Heap that we've allocated 1 KB (WeakBlock::blockSize)
650         of memory. Consequently, when visiting a WeakBlock, we should also report 1 KB of memory
651         visited. Otherwise Heap will think that those 1 KB already went away.
652
653         This was causing us to underestimate heap size, which affects collection scheduling.
654
655         * heap/SlotVisitor.h:
656         (JSC::SlotVisitor::reportMemoryVisited):
657         * heap/WeakBlock.cpp:
658         (JSC::WeakBlock::visit):
659
660 2016-02-07  Saam barati  <sbarati@apple.com>
661
662         Follow up patch to: [ES6] bound functions .name property should be "bound " + the target function's name 
663         https://bugs.webkit.org/show_bug.cgi?id=153796
664
665         Reviewed by Darin Adler.
666
667         This follow-up patch addresses some comments/suggestions by
668         Ryosuke, Darin, and Joe. It simplifies JSBoundFunction::toStringName
669         and adds some tests for bound names.
670
671         * runtime/JSBoundFunction.cpp:
672         (JSC::hasInstanceBoundFunction):
673         (JSC::JSBoundFunction::create):
674         (JSC::JSBoundFunction::toStringName):
675
676 2016-02-07  Filip Pizlo  <fpizlo@apple.com>
677
678         String.match should defend against matches that would crash the VM
679         https://bugs.webkit.org/show_bug.cgi?id=153964
680         rdar://problem/24301119
681
682         Reviewed by Saam Barati.
683
684         This fixes a crash in an internal test case.
685
686         * runtime/ArgList.cpp:
687         (JSC::MarkedArgumentBuffer::slowAppend): Use best practices to ensure that the size we
688             compute makes sense. Crash if it stops making sense, since most users of this API assume
689             that they are creating something small enough to fit on the stack.
690         * runtime/ArgList.h:
691         (JSC::MarkedArgumentBuffer::~MarkedArgumentBuffer):
692         (JSC::MarkedArgumentBuffer::size):
693         (JSC::MarkedArgumentBuffer::operator new): Deleted. These were ineffective. According to the
694             debugger, we were still calling system malloc. So, I changed the code to use fastMalloc()
695             directly.
696         (JSC::MarkedArgumentBuffer::operator delete): Deleted.
697         * runtime/StringPrototype.cpp:
698         (JSC::stringProtoFuncMatch): Explicitly defend against absurd sizes. Of course, it's still
699             possible to crash the VM on OOME. That's sort of always been the philosophy of JSC - we
700             don't guarantee that you'll get a nice-looking error whenever you run out of memory,
701             since in a GC'd environment you can't really guarantee those things. But, if you have a
702             match that obvious won't fit in memory, then reporting an error is useful in case this is
703             a developer experimenting with a buggy regexp.
704
705 2016-02-07  Dan Bernstein  <mitz@apple.com>
706
707         [Cocoa] Replace __has_include guards around inclusion of Apple-internal-SDK headers with USE(APPLE_INTERNAL_SDK)
708         https://bugs.webkit.org/show_bug.cgi?id=153963
709
710         Reviewed by Sam Weinig.
711
712         * inspector/remote/RemoteInspectorXPCConnection.mm:
713
714 2016-02-06  Filip Pizlo  <fpizlo@apple.com>
715
716         FTL must store the call site index before runtime calls, even if it's the tail call slow path
717         https://bugs.webkit.org/show_bug.cgi?id=153955
718         rdar://problem/24290970
719
720         Reviewed by Saam Barati.
721
722         This is necessary because you could throw an exception in a host call on the tail call's slow
723         path. That'll route us to lookupExceptionHandler(), which unwinds starting with the call site
724         index of our frame. Bad things happen if it's not set. Prior to this patch it was possible
725         for the call site index field to be uninitialized, which meant that the throwing machinery
726         was making a wild guess about where we are.
727
728         * ftl/FTLLowerDFGToLLVM.cpp:
729         (JSC::FTL::DFG::LowerDFGToLLVM::compileTailCall):
730         * tests/stress/tail-call-host-call-throw.js: Added.
731
732 2016-02-06  Darin Adler  <darin@apple.com>
733
734         Finish auditing call sites of upper() and lower(), eliminate many, and rename the functions
735         https://bugs.webkit.org/show_bug.cgi?id=153905
736
737         Reviewed by Sam Weinig.
738
739         * runtime/IntlObject.cpp:
740         (JSC::canonicalLangTag): Use converToASCIIUppercase on the language tag.
741
742         * runtime/StringPrototype.cpp:
743         (JSC::stringProtoFuncToLowerCase): Tweak style and update for name change.
744         (JSC::stringProtoFuncToUpperCase): Ditto.
745
746 2016-02-06  Chris Dumez  <cdumez@apple.com>
747
748         Object.getOwnPropertyDescriptor() does not work on sub-frame's window
749         https://bugs.webkit.org/show_bug.cgi?id=153925
750
751         Reviewed by Darin Adler.
752
753         Calling Object.getOwnPropertyDescriptor() on a sub-frame's window was
754         returning undefined for that window's own properties. The reason was
755         that the check getOwnPropertySlot() is using to make sure the
756         PropertySlot is not for a property coming from the prototype was wrong.
757
758         The check was checking that 'this != slotBase' which works fine unless
759         this is a JSProxy (e.g. JSDOMWindowShell). To handle proxies, the code
760         was also checking that 'slotBase.toThis() != this', attempting to
761         get the slotBase/Window's proxy. However, due to the implementation of
762         toThis(), we were getting the lexical global object's proxy instead of
763         slotBase's proxy. To avoid this issue, the new code explicitly checks
764         if 'this' is a JSProxy and makes sure 'JSProxy::target() != slotBase',
765         instead of using toThis().
766
767         * runtime/JSObject.cpp:
768         (JSC::JSObject::getOwnPropertyDescriptor):
769
770 2016-02-06  Andreas Kling  <akling@apple.com>
771
772         [iOS] Throw away linked code when navigating to a new page.
773         <https://webkit.org/b/153851>
774
775         Reviewed by Gavin Barraclough.
776
777         Add a VM API for throwing away linked code only.
778
779         * runtime/VM.cpp:
780         (JSC::VM::deleteAllLinkedCode):
781         * runtime/VM.h:
782
783 2016-02-06  Commit Queue  <commit-queue@webkit.org>
784
785         Unreviewed, rolling out r196104.
786         https://bugs.webkit.org/show_bug.cgi?id=153940
787
788         Regressed Speedometer on iOS (Requested by kling on #webkit).
789
790         Reverted changeset:
791
792         "[iOS] Throw away linked code when navigating to a new page."
793         https://bugs.webkit.org/show_bug.cgi?id=153851
794         http://trac.webkit.org/changeset/196104
795
796 2016-02-05  Alex Christensen  <achristensen@webkit.org>
797
798         Fix internal Windows build
799         https://bugs.webkit.org/show_bug.cgi?id=153930
800         <rdar://problem/24534864>
801
802         Reviewed by Mark Lam.
803
804         * JavaScriptCore.vcxproj/JavaScriptCore.proj:
805         I made a typo in r196144.
806
807 2016-02-05  Saam barati  <sbarati@apple.com>
808
809         Web Inspector: Include SamplingProfiler's expression-level data for stack frames in the protocol
810         https://bugs.webkit.org/show_bug.cgi?id=153455
811         <rdar://problem/24335884>
812
813         Reviewed by Joseph Pecoraro.
814
815         We now send the sampling profiler's expression-level
816         line/column info in the inspector protocol.
817
818         * inspector/agents/InspectorScriptProfilerAgent.cpp:
819         (Inspector::buildSamples):
820         * inspector/protocol/ScriptProfiler.json:
821         * runtime/SamplingProfiler.h:
822         (JSC::SamplingProfiler::StackFrame::hasExpressionInfo):
823
824 2016-02-05  Saam barati  <sbarati@apple.com>
825
826         follow-up to: JSC Sampling Profiler: (host) is confusing in cases where I would expect to see JS name
827         https://bugs.webkit.org/show_bug.cgi?id=153663
828         <rdar://problem/24415092>
829
830         Rubber stamped by Joseph Pecoraro.
831
832         We were performing operations that required us to
833         hold the VM lock even when we might not have been holding it.
834         We now ensure we're holding it.
835
836         * inspector/agents/InspectorScriptProfilerAgent.cpp:
837         (Inspector::InspectorScriptProfilerAgent::trackingComplete):
838
839 2016-02-05  Filip Pizlo  <fpizlo@apple.com>
840
841         Arrayify for a typed array shouldn't create a monster
842         https://bugs.webkit.org/show_bug.cgi?id=153908
843         rdar://problem/24290639
844
845         Reviewed by Mark Lam.
846
847         Previously if you convinced the DFG to emit an Arrayify to ArrayStorage and then gave it a
848         typed array, you'd corrupt the object.
849
850         * runtime/JSArrayBufferView.cpp:
851         (WTF::printInternal):
852         * runtime/JSArrayBufferView.h:
853         * runtime/JSGenericTypedArrayViewInlines.h:
854         (JSC::JSGenericTypedArrayView<Adaptor>::visitChildren):
855         (JSC::JSGenericTypedArrayView<Adaptor>::slowDownAndWasteMemory):
856         * runtime/JSObject.cpp:
857         (JSC::JSObject::copyButterfly):
858         (JSC::JSObject::enterDictionaryIndexingMode):
859         (JSC::JSObject::ensureInt32Slow):
860         (JSC::JSObject::ensureDoubleSlow):
861         (JSC::JSObject::ensureContiguousSlow):
862         (JSC::JSObject::ensureArrayStorageSlow):
863         (JSC::JSObject::growOutOfLineStorage):
864         (JSC::getBoundSlotBaseFunctionForGetterSetter):
865         * runtime/Structure.h:
866         * tests/stress/arrayify-array-storage-typed-array.js: Added. This test failed.
867         * tests/stress/arrayify-int32-typed-array.js: Added. This test case already had other protections, but we beefed them up.
868
869 2016-02-04  Joseph Pecoraro  <pecoraro@apple.com>
870
871         Web Inspector: InspectorTimelineAgent doesn't need to recompile functions because it now uses the sampling profiler
872         https://bugs.webkit.org/show_bug.cgi?id=153500
873         <rdar://problem/24352458>
874
875         Reviewed by Timothy Hatcher.
876
877         Be more explicit about enabling legacy profiling.
878
879         * jsc.cpp:
880         * runtime/Executable.cpp:
881         (JSC::ScriptExecutable::newCodeBlockFor):
882         * runtime/JSGlobalObject.cpp:
883         (JSC::JSGlobalObject::hasLegacyProfiler):
884         (JSC::JSGlobalObject::createProgramCodeBlock):
885         (JSC::JSGlobalObject::createEvalCodeBlock):
886         (JSC::JSGlobalObject::createModuleProgramCodeBlock):
887         (JSC::JSGlobalObject::hasProfiler): Deleted.
888         * runtime/JSGlobalObject.h:
889         (JSC::JSGlobalObject::supportsLegacyProfiling):
890         (JSC::JSGlobalObject::supportsProfiling): Deleted.
891
892 2016-02-04  Keith Miller  <keith_miller@apple.com>
893
894         ArrayPrototype should have a destroy function
895         https://bugs.webkit.org/show_bug.cgi?id=153847
896
897         Reviewed by Filip Pizlo.
898
899         ArrayPrototype should have an destroy function as it now has a unique_ptr member that
900         needs to be freed at the end of the object's life cycle. Also, this patch adds an
901         option, gcAtEnd, that will cause jsc.cpp to do a garbage collection before exiting.
902
903         * jsc.cpp:
904         (runJSC):
905         (jscmain):
906         * runtime/ArrayPrototype.cpp:
907         (JSC::ArrayPrototype::create):
908         (JSC::ArrayPrototype::destroy):
909         * runtime/ArrayPrototype.h:
910         * runtime/Options.h:
911
912 2016-02-04  Filip Pizlo  <fpizlo@apple.com>
913
914         REGRESSION(192409): Cannot rely on add32() to zero-extend
915         https://bugs.webkit.org/show_bug.cgi?id=153897
916
917         Unreviewed rollout of r192409.
918
919         * assembler/MacroAssemblerARM64.h:
920         (JSC::MacroAssemblerARM64::add32):
921         (JSC::MacroAssemblerARM64::add64):
922         * assembler/MacroAssemblerARMv7.h:
923         (JSC::MacroAssemblerARMv7::add32):
924         * assembler/MacroAssemblerX86.h:
925         (JSC::MacroAssemblerX86::add32):
926         * assembler/MacroAssemblerX86Common.h:
927         (JSC::MacroAssemblerX86Common::add32):
928         (JSC::MacroAssemblerX86Common::add8):
929         (JSC::MacroAssemblerX86Common::branchAdd32):
930         (JSC::MacroAssemblerX86Common::generateTest32):
931         (JSC::MacroAssemblerX86Common::clz32AfterBsr):
932         (JSC::MacroAssemblerX86Common::add32AndSetFlags): Deleted.
933         * assembler/MacroAssemblerX86_64.h:
934         (JSC::MacroAssemblerX86_64::add32):
935         (JSC::MacroAssemblerX86_64::add64):
936         (JSC::MacroAssemblerX86_64::branchAdd64):
937         (JSC::MacroAssemblerX86_64::repatchCall):
938         (JSC::MacroAssemblerX86_64::clz64AfterBsr):
939         (JSC::MacroAssemblerX86_64::add64AndSetFlags): Deleted.
940
941 2016-02-04  Andreas Kling  <akling@apple.com>
942
943         Remove dead ENABLE(BYTECODE_COMMENTS) cruft.
944         <https://webkit.org/b/153888>
945
946         Reviewed by Antti Koivisto.
947
948         * bytecode/UnlinkedCodeBlock.cpp:
949         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): Deleted.
950         * bytecode/UnlinkedCodeBlock.h:
951         (JSC::UnlinkedCodeBlock::shrinkToFit): Deleted.
952
953 2016-02-04  Saam barati  <sbarati@apple.com>
954
955         JSC Sampling Profiler: (host) is confusing in cases where I would expect to see JS name
956         https://bugs.webkit.org/show_bug.cgi?id=153663
957         <rdar://problem/24415092>
958
959         Reviewed by Geoffrey Garen.
960
961         We now collect the Callee in the processed StackFrame
962         when the Callee is a valid GC object. We later ask
963         the Callee for it's .displayName or .name property.
964         When we don't have a valid callee, we will still
965         use the Executable for this information.
966
967         This helps us come up with good names for frames where 
968         the Callee object is a bound function or an InternalFunction.
969
970         * inspector/agents/InspectorScriptProfilerAgent.cpp:
971         (Inspector::InspectorScriptProfilerAgent::addEvent):
972         (Inspector::buildSamples):
973         (Inspector::InspectorScriptProfilerAgent::trackingComplete):
974         * runtime/SamplingProfiler.cpp:
975         (JSC::reportStats):
976         (JSC::FrameWalker::walk):
977         (JSC::SamplingProfiler::processUnverifiedStackTraces):
978         (JSC::SamplingProfiler::visit):
979         (JSC::SamplingProfiler::shutdown):
980         (JSC::SamplingProfiler::clearData):
981         (JSC::SamplingProfiler::StackFrame::nameFromCallee):
982         (JSC::SamplingProfiler::StackFrame::displayName):
983         (JSC::SamplingProfiler::StackFrame::displayNameForJSONTests):
984         (JSC::SamplingProfiler::stackTracesAsJSON):
985         * runtime/SamplingProfiler.h:
986         (JSC::SamplingProfiler::UnprocessedStackFrame::UnprocessedStackFrame):
987         (JSC::SamplingProfiler::StackFrame::StackFrame):
988         * tests/stress/sampling-profiler-basic.js:
989         (platformSupportsSamplingProfiler.nothing):
990         (platformSupportsSamplingProfiler.top):
991         * tests/stress/sampling-profiler-bound-function-name.js: Added.
992         (platformSupportsSamplingProfiler.foo):
993         (platformSupportsSamplingProfiler.bar):
994         (platformSupportsSamplingProfiler.let.baz):
995         (platformSupportsSamplingProfiler):
996         * tests/stress/sampling-profiler-display-name.js: Added.
997         (platformSupportsSamplingProfiler.foo):
998         (platformSupportsSamplingProfiler.baz):
999         (platformSupportsSamplingProfiler.):
1000         (platformSupportsSamplingProfiler.bar):
1001         (platformSupportsSamplingProfiler.jaz):
1002         (platformSupportsSamplingProfiler.makeFunction.let.result):
1003         (platformSupportsSamplingProfiler.makeFunction):
1004         * tests/stress/sampling-profiler-internal-function-name.js: Added.
1005         (platformSupportsSamplingProfiler.foo):
1006         (platformSupportsSamplingProfiler.bar):
1007         (platformSupportsSamplingProfiler):
1008
1009 2016-02-04  Chris Dumez  <cdumez@apple.com>
1010
1011         Object.getOwnPropertyDescriptor() returns incomplete descriptor for instance properties
1012         https://bugs.webkit.org/show_bug.cgi?id=153817
1013
1014         Reviewed by Geoffrey Garen.
1015
1016         Extend support for Object.getOwnPropertyDescriptor() on native bindings
1017         to instance properties (e.g. Unforgeable properties or Global object
1018         properties) so that the returned descriptor has getter / setter
1019         functions, as expected.
1020
1021         * runtime/JSObject.cpp:
1022         (JSC::JSObject::reifyAllStaticProperties):
1023         Add method that reifies all static properties, including the custom
1024         accessors. This is similar to what is done eagerly on the prototype
1025         objects in the bindings code.
1026
1027         (JSC::JSObject::getOwnPropertyDescriptor):
1028         getOwnPropertyDescriptor() would previously fails for custom accessors
1029         that are on the instance because getDirect() does not check the static
1030         property table and those custom accessors were not reified (We only
1031         reified all properties eagerly - including custom accessors - on
1032         prototype objects. To address this issue, we now call
1033         reifyAllStaticProperties() if the call to getDirect() fails and then
1034         call getDirect() again. This fix is however insufficient for Window
1035         properties because |this| is a JSDOMWindowShell / JSProxy in this case
1036         and getDirect() / reifyAllStaticProperties() would fail as the proxy
1037         does not actually have the properties. This issue was addressed by
1038         checking if |this| is a JSProxy and then using JSProxy::target() instead
1039         of |this| for the calls to getDirect() and for the reification.
1040
1041         * runtime/JSObject.h:
1042         * runtime/Lookup.h:
1043         (JSC::reifyStaticProperty):
1044         (JSC::reifyStaticProperties):
1045         Move most code in reifyStaticProperties() to a separate function so the
1046         code can be shared with JSObject::reifyAllStaticProperties().
1047         reifyStaticProperties() is currently called by the bindings on the
1048         prototype objects.
1049
1050 2016-02-04  Alex Christensen  <achristensen@webkit.org>
1051
1052         Fix internal Windows build
1053         https://bugs.webkit.org/show_bug.cgi?id=153886
1054         <rdar://problem/24499887>
1055
1056         Reviewed by Mark Lam.
1057
1058         * JavaScriptCore.vcxproj/JavaScriptCore.proj:
1059         In r190253 I changed the directory of the headers from AppleInternal/include/JavaScriptCore 
1060         to AppleInternal/include/private/JavaScriptCore.  This is ok for WebCore and WebKit, but not
1061         other projects, such as CFNetwork, which expect the public API headers to be in the old location.
1062         This used to be done by a combination of copy-files.cmd and the old JavaScriptCore.proj.
1063         This change copies all the API headers, which copies everything in copy-files.cmd except APIShims.h
1064         which does not exist any more.  It copies additional headers that were not copied before, but
1065         I think this is beneficial so we do not forget to add new public headers to a list of public headers
1066         to be copied in the internal build.  Having extra public headers in the internal Windows build is
1067         not a problem because only internal clients use the internal Windows build.
1068
1069 2016-02-03  Yusuke Suzuki  <utatane.tea@gmail.com>
1070
1071         [JSC] Make some classes non JSDestructibleObject
1072         https://bugs.webkit.org/show_bug.cgi?id=153838
1073
1074         Reviewed by Geoffrey Garen.
1075
1076         SymbolPrototype, JSMapIterator and JSSetIterator are trivially destructible.
1077         So there is no need to inherit JSDestructibleObject.
1078
1079         * runtime/JSMapIterator.cpp:
1080         (JSC::JSMapIterator::destroy): Deleted.
1081         * runtime/JSMapIterator.h:
1082         * runtime/JSSetIterator.cpp:
1083         (JSC::JSSetIterator::destroy): Deleted.
1084         * runtime/JSSetIterator.h:
1085         * runtime/MapData.h:
1086         * runtime/SymbolPrototype.h:
1087
1088 2016-02-03  Yusuke Suzuki  <utatane.tea@gmail.com>
1089
1090         [JSC] Symbol structure has unnecessary flags
1091         https://bugs.webkit.org/show_bug.cgi?id=153840
1092
1093         Reviewed by Saam Barati.
1094
1095         * runtime/Symbol.h:
1096         * tests/stress/symbol-get-own-property.js: Added.
1097         (shouldBe):
1098
1099 2016-02-03  Andreas Kling  <akling@apple.com>
1100
1101         [iOS] Throw away linked code when navigating to a new page.
1102         <https://webkit.org/b/153851>
1103
1104         Reviewed by Gavin Barraclough.
1105
1106         Add a VM API for throwing away linked code only.
1107
1108         * runtime/VM.cpp:
1109         (JSC::VM::deleteAllLinkedCode):
1110         * runtime/VM.h:
1111
1112 2016-02-03  Michael Catanzaro  <mcatanzaro@igalia.com>
1113
1114         [GTK][EFL] Switch FTL to B3
1115         https://bugs.webkit.org/show_bug.cgi?id=153478
1116
1117         Reviewed by Csaba Osztrogonác.
1118
1119         Conditionalize code to make it possible to build FTL completely without LLVM.
1120
1121         * CMakeLists.txt:
1122         * dfg/DFGCommon.h:
1123         * dfg/DFGPlan.cpp:
1124         (JSC::DFG::Plan::compileInThreadImpl):
1125         * ftl/FTLAbbreviatedTypes.h:
1126         * ftl/FTLFail.cpp:
1127         (JSC::FTL::fail):
1128         * ftl/FTLState.cpp:
1129         (JSC::FTL::State::State):
1130         (JSC::FTL::State::~State):
1131
1132 2016-02-03  Carlos Garcia Campos  <cgarcia@igalia.com>
1133
1134         Unreviewed. Fix JavaScriptCore build with B3 enabled.
1135
1136         Include <limits.h> for UINT_MAX.
1137
1138         * b3/B3StackSlot.h:
1139         * b3/air/AirStackSlot.h:
1140
1141 2016-02-02  Caitlin Potter  <caitp@igalia.com>
1142
1143         JSSymbolTableObject::deleteProperty() crashes deleting Symbols
1144         https://bugs.webkit.org/show_bug.cgi?id=153816
1145
1146         Reviewed by Darin Adler.
1147
1148         Changes JSSymbolTableObject::deleteProperty() to check if its
1149         symbolTable() contains the property's uid() rather than publicName().
1150         This ensures that it will not crash in the case of Symbols.
1151
1152         * runtime/JSSymbolTableObject.cpp:
1153         (JSC::JSSymbolTableObject::deleteProperty):
1154         * tests/es6/Object_static_methods_Object.getOwnPropertyDescriptors.js:
1155         (testGlobalProxy):
1156         * tests/stress/regress-153816.js: Added.
1157         (deleteSymbolFromJSSymbolTableObject):
1158
1159 2016-02-02  Benjamin Poulain  <benjamin@webkit.org>
1160
1161         [JSC] Do not copy FP when lowering FramePointer
1162         https://bugs.webkit.org/show_bug.cgi?id=153769
1163
1164         Reviewed by Michael Saboff.
1165
1166         That extra move is just wasted time. The fewer Moves we have,
1167         the happier IRC is.
1168
1169         * b3/B3LowerToAir.cpp:
1170         (JSC::B3::Air::LowerToAir::tmp):
1171         (JSC::B3::Air::LowerToAir::lower):
1172
1173 2016-02-02  Keith Miller  <keith_miller@apple.com>
1174
1175         DFG, FTL, B3, and Air should all have a unique option for printing their graphs
1176         https://bugs.webkit.org/show_bug.cgi?id=153815
1177
1178         Reviewed by Benjamin Poulain.
1179
1180         This patch adds a new printing option for each of the DFG/FTL compilation phases.
1181
1182         * b3/B3Common.cpp:
1183         (JSC::B3::shouldDumpIR):
1184         (JSC::B3::shouldDumpIRAtEachPhase):
1185         * b3/B3Common.h:
1186         * b3/B3Generate.cpp:
1187         (JSC::B3::generateToAir):
1188         * b3/B3PhaseScope.cpp:
1189         (JSC::B3::PhaseScope::PhaseScope):
1190         * b3/air/AirGenerate.cpp:
1191         (JSC::B3::Air::prepareForGeneration):
1192         * b3/air/AirPhaseScope.cpp:
1193         (JSC::B3::Air::PhaseScope::PhaseScope):
1194         * dfg/DFGCFAPhase.cpp:
1195         (JSC::DFG::CFAPhase::run):
1196         * dfg/DFGCommon.h:
1197         (JSC::DFG::shouldDumpGraphAtEachPhase):
1198         * dfg/DFGPhase.cpp:
1199         (JSC::DFG::Phase::beginPhase):
1200         * runtime/Options.cpp:
1201         (JSC::recomputeDependentOptions):
1202         * runtime/Options.h:
1203
1204 2016-02-02  Caitlin Potter  <caitp@igalia.com>
1205
1206         [JSC] make Object.getOwnPropertyDescriptors() work with non-JSObject types
1207         https://bugs.webkit.org/show_bug.cgi?id=153814
1208
1209         Reviewed by Yusuke Suzuki.
1210
1211         * runtime/ObjectConstructor.cpp:
1212         (JSC::objectConstructorGetOwnPropertyDescriptors):
1213         * tests/es6/Object_static_methods_Object.getOwnPropertyDescriptors.js:
1214         (testGlobalProxy):
1215
1216 2016-02-02  Aakash Jain  <aakash_jain@apple.com>
1217
1218         Remove references to CallFrameInlines.h
1219         https://bugs.webkit.org/show_bug.cgi?id=153810
1220
1221         Reviewed by Mark Lam.
1222
1223         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1224         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1225
1226 2016-02-02  Caitlin Potter  <caitp@igalia.com>
1227
1228         [JSC] Implement Object.getOwnPropertyDescriptors() proposal
1229         https://bugs.webkit.org/show_bug.cgi?id=153799
1230
1231         Reviewed by Darin Adler.
1232
1233         Implements the Object.getOwnPropertyDescriptors() proposal, which
1234         reached Stage 3 in the TC39 process in January 2016.
1235         https://github.com/tc39/proposal-object-getownpropertydescriptors
1236
1237         The method extracts a set of property descriptor objects, which can
1238         be safely used via `Object.create()`.
1239
1240         * runtime/ObjectConstructor.cpp:
1241         (JSC::objectConstructorGetOwnPropertyDescriptors):
1242
1243 2016-02-02  Filip Pizlo  <fpizlo@apple.com>
1244
1245         B3 should be able to compile trivial self-loops
1246         https://bugs.webkit.org/show_bug.cgi?id=153802
1247         rdar://problem/24465632
1248
1249         Reviewed by Michael Saboff.
1250
1251         Tail-duplicating a self-loop would mean doing a kind of loop unrolling. It wouldn't be
1252         profitable even if it did work. It turns out that it doesn't work, because we edit the target
1253         block before reading the source block, which breaks if the target and source block are the
1254         same.
1255
1256         This disables tail duplication of self-loops, adds a test, and adds better validation for this
1257         issue.
1258
1259         * b3/B3DuplicateTails.cpp:
1260         * b3/B3Procedure.cpp:
1261         (JSC::B3::Procedure::resetReachability):
1262         * b3/testb3.cpp:
1263         (JSC::B3::testComputeDivisionMagic):
1264         (JSC::B3::testTrivialInfiniteLoop):
1265         (JSC::B3::zero):
1266         (JSC::B3::run):
1267
1268 2016-02-02  Saam barati  <sbarati@apple.com>
1269
1270         [ES6] bound functions .name property should be "bound " + the target function's name
1271         https://bugs.webkit.org/show_bug.cgi?id=153796
1272
1273         Reviewed by Mark Lam.
1274
1275         See http://tc39.github.io/ecma262/#sec-function.prototype.bind for details.
1276         What the spec says:
1277         ```
1278         function foo() { }
1279         foo.bind(null).name === "bound foo"
1280
1281         (function bar() { }).bind(null).name === "bound bar"
1282         ```
1283
1284         * runtime/FunctionPrototype.cpp:
1285         (JSC::functionProtoFuncToString):
1286         * runtime/JSBoundFunction.cpp:
1287         (JSC::hasInstanceBoundFunction):
1288         (JSC::JSBoundFunction::create):
1289         (JSC::JSBoundFunction::visitChildren):
1290         (JSC::JSBoundFunction::toStringName):
1291         * runtime/JSBoundFunction.h:
1292         (JSC::JSBoundFunction::boundThis):
1293         (JSC::JSBoundFunction::boundArgs):
1294         (JSC::JSBoundFunction::createStructure):
1295         * tests/es6.yaml:
1296
1297 2016-02-02  Filip Pizlo  <fpizlo@apple.com>
1298
1299         Get rid of anonymous stack slots
1300         https://bugs.webkit.org/show_bug.cgi?id=151128
1301
1302         Reviewed by Mark Lam.
1303
1304         When I first designed stack slots, the idea was that an "anonymous" stack slot was one that
1305         behaved exactly like a C variable: if it never escaped, it would not need to get stack space
1306         for the entire lifetime of the function - it could get any slab of stack so long as it
1307         didn't interfere with other stack slots that would be live at the same time. The reason I
1308         called them "anonymous" is that external code could not get its address. This felt like it
1309         gave the stack slot anonymity. But it was never a good name for this concept.
1310
1311         Then I had the register allocator lower temporaries to anonymous stack slots when it spilled
1312         them. Spilling became the sole client of anonymous stack slots.
1313
1314         Then I realized that there was an aspect of how spill slots work that make them want
1315         slightly different semantics than a normal C variable. A C variable is a proper memory
1316         location - you could do a store to only some bytes in the variable, and it's reasonable to
1317         expect that this will not destroy the other bytes in the variable. But that means that to
1318         compute their liveness, you have to do something like a per-byte liveness. That's overkill
1319         for spill slots. You want any store to the spill slot to kill the whole slot even if it
1320         writes to just part of the slot. This matches how temporaries work. So rather than implement
1321         per-byte liveness, I decided to change the semantics of anonymous stack slots to make them
1322         work like how I wanted spill slots to work. This was quite dirty, and put B3 in the awkward
1323         situation that B3's anonymous stack slots behaved like spill slots. But it was OK since
1324         nobody used anonymous stack slots in B3.
1325
1326         Then I added tail duplication, which required having a mechanism for introducing non-SSA
1327         variables in B3. I decided to use anonymous stack slots for this purpose. All of a sudden
1328         this all felt like it made sense: anonymous stack slots were just like variables! Hooray for
1329         the amazing foresight of anonymous stack slots!
1330
1331         But then I realized that this was all very bad. We want B3 to be able to optimize Store and
1332         Load operations by reasoning about how they affect bytes in memory. For example, if you do
1333         a Load of a 64-bit value, and then you modify just the low 32 bits of that value, and then
1334         you do a 64-bit store back to the same location, then it would be better to transform this
1335         into 32-bit operations. We don't do this optimization yet, but it's the kind of thing that
1336         we want B3 to be able to do. To do it, we need Store to mean that it only affects N bytes
1337         starting at the pointer, where N is the size of the thing being stored. But that's not what
1338         Store means for anonymous stack slots. For anonymous slots, storing to any byte in the slot
1339         clobbers all bytes in the slot. We were never clear if you need to store directly to an
1340         anonymous slot to get this behavior, or if any pointer that points to an anoymous slot must
1341         exhibit this behavior when stored to. Neither kinds of semantics make sense to me.
1342
1343         This change fixes the problem by eradicating anonymous stack slots. In B3, they are replaced
1344         with Variables. In Air, they are replaced with a different stack slot kind, called Spill.
1345         There is no such thing as stack slot kinds in B3 anymore, all B3 stack slots are locked. In
1346         Air, there is still the concept of stack slot kind - Locked or Spill.
1347
1348         B3 Variables are awesome. They are exactly what they seem to be. They have a type. They are
1349         declared at the top level in the Procedure. You can access them with new opcodes, Get and
1350         Set. This greatly simplifies demoting SSA values to variables and promoting them back to
1351         SSA. I even made the instruction selector do the right things for variables, which means
1352         that introducing variables won't hurt instruction selection (there will be extra moves, but
1353         IRC will kill them). It's great to have non-SSA variables as an explicit concept in IR
1354         because it means that you don't have to do any magic to use them - they Just Work.
1355
1356         Air spill slots behave almost like anonymous stack slots, with one exception: you cannot
1357         escape them. We validate this by making it illegal to UseAddr on a spill slot. This removes
1358         the need to answer awkward questions like: does a 32-bit Def on a pointer that may point to
1359         a 64-bit spill slot do anything to the 32 bits above the pointer?  Does it write zero to it?
1360         Does it write zero to it just when the pointer actually points to a spill slot or always?
1361         These are silly questions, and we don't have to answer them because the only way to refer to
1362         a spill slot is directly. No escaping means no aliasing.
1363
1364         This doesn't affect performance. It just makes the compiler more fun to work with by
1365         removing some cognitive dissonance.
1366
1367         * CMakeLists.txt:
1368         * JavaScriptCore.xcodeproj/project.pbxproj:
1369         * b3/B3ArgumentRegValue.h:
1370         * b3/B3CCallValue.h:
1371         * b3/B3CheckValue.cpp:
1372         (JSC::B3::CheckValue::cloneImpl):
1373         (JSC::B3::CheckValue::CheckValue):
1374         * b3/B3CheckValue.h:
1375         * b3/B3Const32Value.h:
1376         * b3/B3Const64Value.h:
1377         * b3/B3ConstDoubleValue.h:
1378         * b3/B3ConstFloatValue.h:
1379         * b3/B3ConstPtrValue.h:
1380         (JSC::B3::ConstPtrValue::ConstPtrValue):
1381         * b3/B3ControlValue.cpp:
1382         (JSC::B3::ControlValue::convertToJump):
1383         (JSC::B3::ControlValue::convertToOops):
1384         (JSC::B3::ControlValue::dumpMeta):
1385         * b3/B3ControlValue.h:
1386         * b3/B3Effects.cpp:
1387         (JSC::B3::Effects::interferes):
1388         (JSC::B3::Effects::dump):
1389         * b3/B3Effects.h:
1390         (JSC::B3::Effects::mustExecute):
1391         * b3/B3EliminateCommonSubexpressions.cpp:
1392         * b3/B3FixSSA.cpp:
1393         (JSC::B3::demoteValues):
1394         (JSC::B3::fixSSA):
1395         * b3/B3FixSSA.h:
1396         * b3/B3IndexMap.h:
1397         (JSC::B3::IndexMap::resize):
1398         (JSC::B3::IndexMap::clear):
1399         (JSC::B3::IndexMap::size):
1400         (JSC::B3::IndexMap::operator[]):
1401         * b3/B3IndexSet.h:
1402         (JSC::B3::IndexSet::contains):
1403         (JSC::B3::IndexSet::size):
1404         (JSC::B3::IndexSet::isEmpty):
1405         * b3/B3LowerToAir.cpp:
1406         (JSC::B3::Air::LowerToAir::run):
1407         (JSC::B3::Air::LowerToAir::lower):
1408         * b3/B3MemoryValue.h:
1409         * b3/B3Opcode.cpp:
1410         (WTF::printInternal):
1411         * b3/B3Opcode.h:
1412         * b3/B3PatchpointValue.cpp:
1413         (JSC::B3::PatchpointValue::cloneImpl):
1414         (JSC::B3::PatchpointValue::PatchpointValue):
1415         * b3/B3PatchpointValue.h:
1416         * b3/B3Procedure.cpp:
1417         (JSC::B3::Procedure::Procedure):
1418         (JSC::B3::Procedure::addBlock):
1419         (JSC::B3::Procedure::addStackSlot):
1420         (JSC::B3::Procedure::addVariable):
1421         (JSC::B3::Procedure::clone):
1422         (JSC::B3::Procedure::addIntConstant):
1423         (JSC::B3::Procedure::dump):
1424         (JSC::B3::Procedure::deleteStackSlot):
1425         (JSC::B3::Procedure::deleteVariable):
1426         (JSC::B3::Procedure::deleteValue):
1427         (JSC::B3::Procedure::deleteOrphans):
1428         (JSC::B3::Procedure::calleeSaveRegisters):
1429         (JSC::B3::Procedure::addValueImpl):
1430         (JSC::B3::Procedure::setBlockOrderImpl):
1431         (JSC::B3::Procedure::addAnonymousStackSlot): Deleted.
1432         (JSC::B3::Procedure::addStackSlotIndex): Deleted.
1433         (JSC::B3::Procedure::addValueIndex): Deleted.
1434         * b3/B3Procedure.h:
1435         (JSC::B3::Procedure::setBlockOrder):
1436         (JSC::B3::Procedure::stackSlots):
1437         (JSC::B3::Procedure::variables):
1438         (JSC::B3::Procedure::values):
1439         (JSC::B3::Procedure::StackSlotsCollection::StackSlotsCollection): Deleted.
1440         (JSC::B3::Procedure::StackSlotsCollection::size): Deleted.
1441         (JSC::B3::Procedure::StackSlotsCollection::at): Deleted.
1442         (JSC::B3::Procedure::StackSlotsCollection::operator[]): Deleted.
1443         (JSC::B3::Procedure::StackSlotsCollection::iterator::iterator): Deleted.
1444         (JSC::B3::Procedure::StackSlotsCollection::iterator::operator*): Deleted.
1445         (JSC::B3::Procedure::StackSlotsCollection::iterator::operator++): Deleted.
1446         (JSC::B3::Procedure::StackSlotsCollection::iterator::operator==): Deleted.
1447         (JSC::B3::Procedure::StackSlotsCollection::iterator::operator!=): Deleted.
1448         (JSC::B3::Procedure::StackSlotsCollection::iterator::findNext): Deleted.
1449         (JSC::B3::Procedure::StackSlotsCollection::begin): Deleted.
1450         (JSC::B3::Procedure::StackSlotsCollection::end): Deleted.
1451         (JSC::B3::Procedure::ValuesCollection::ValuesCollection): Deleted.
1452         (JSC::B3::Procedure::ValuesCollection::iterator::iterator): Deleted.
1453         (JSC::B3::Procedure::ValuesCollection::iterator::operator*): Deleted.
1454         (JSC::B3::Procedure::ValuesCollection::iterator::operator++): Deleted.
1455         (JSC::B3::Procedure::ValuesCollection::iterator::operator==): Deleted.
1456         (JSC::B3::Procedure::ValuesCollection::iterator::operator!=): Deleted.
1457         (JSC::B3::Procedure::ValuesCollection::iterator::findNext): Deleted.
1458         (JSC::B3::Procedure::ValuesCollection::begin): Deleted.
1459         (JSC::B3::Procedure::ValuesCollection::end): Deleted.
1460         (JSC::B3::Procedure::ValuesCollection::size): Deleted.
1461         (JSC::B3::Procedure::ValuesCollection::at): Deleted.
1462         (JSC::B3::Procedure::ValuesCollection::operator[]): Deleted.
1463         * b3/B3ProcedureInlines.h:
1464         (JSC::B3::Procedure::add):
1465         * b3/B3ReduceStrength.cpp:
1466         * b3/B3SlotBaseValue.h:
1467         * b3/B3SparseCollection.h: Added.
1468         (JSC::B3::SparseCollection::SparseCollection):
1469         (JSC::B3::SparseCollection::add):
1470         (JSC::B3::SparseCollection::addNew):
1471         (JSC::B3::SparseCollection::remove):
1472         (JSC::B3::SparseCollection::size):
1473         (JSC::B3::SparseCollection::isEmpty):
1474         (JSC::B3::SparseCollection::at):
1475         (JSC::B3::SparseCollection::operator[]):
1476         (JSC::B3::SparseCollection::iterator::iterator):
1477         (JSC::B3::SparseCollection::iterator::operator*):
1478         (JSC::B3::SparseCollection::iterator::operator++):
1479         (JSC::B3::SparseCollection::iterator::operator==):
1480         (JSC::B3::SparseCollection::iterator::operator!=):
1481         (JSC::B3::SparseCollection::iterator::findNext):
1482         (JSC::B3::SparseCollection::begin):
1483         (JSC::B3::SparseCollection::end):
1484         * b3/B3StackSlot.cpp:
1485         (JSC::B3::StackSlot::deepDump):
1486         (JSC::B3::StackSlot::StackSlot):
1487         * b3/B3StackSlot.h:
1488         (JSC::B3::StackSlot::byteSize):
1489         (JSC::B3::StackSlot::index):
1490         (JSC::B3::StackSlot::setOffsetFromFP):
1491         (JSC::B3::StackSlot::kind): Deleted.
1492         (JSC::B3::StackSlot::isLocked): Deleted.
1493         * b3/B3StackSlotKind.cpp: Removed.
1494         * b3/B3StackSlotKind.h: Removed.
1495         * b3/B3StackmapValue.cpp:
1496         (JSC::B3::StackmapValue::dumpMeta):
1497         (JSC::B3::StackmapValue::StackmapValue):
1498         * b3/B3StackmapValue.h:
1499         * b3/B3SwitchValue.cpp:
1500         (JSC::B3::SwitchValue::cloneImpl):
1501         (JSC::B3::SwitchValue::SwitchValue):
1502         * b3/B3SwitchValue.h:
1503         * b3/B3UpsilonValue.h:
1504         * b3/B3Validate.cpp:
1505         * b3/B3Value.cpp:
1506         (JSC::B3::Value::replaceWithIdentity):
1507         (JSC::B3::Value::replaceWithNop):
1508         (JSC::B3::Value::replaceWithPhi):
1509         (JSC::B3::Value::dump):
1510         (JSC::B3::Value::effects):
1511         (JSC::B3::Value::checkOpcode):
1512         * b3/B3Value.h:
1513         * b3/B3Variable.cpp: Added.
1514         (JSC::B3::Variable::~Variable):
1515         (JSC::B3::Variable::dump):
1516         (JSC::B3::Variable::deepDump):
1517         (JSC::B3::Variable::Variable):
1518         * b3/B3Variable.h: Added.
1519         (JSC::B3::Variable::type):
1520         (JSC::B3::Variable::index):
1521         (JSC::B3::DeepVariableDump::DeepVariableDump):
1522         (JSC::B3::DeepVariableDump::dump):
1523         (JSC::B3::deepDump):
1524         * b3/B3VariableValue.cpp: Added.
1525         (JSC::B3::VariableValue::~VariableValue):
1526         (JSC::B3::VariableValue::dumpMeta):
1527         (JSC::B3::VariableValue::cloneImpl):
1528         (JSC::B3::VariableValue::VariableValue):
1529         * b3/B3VariableValue.h: Added.
1530         * b3/air/AirAllocateStack.cpp:
1531         (JSC::B3::Air::allocateStack):
1532         * b3/air/AirCode.cpp:
1533         (JSC::B3::Air::Code::addStackSlot):
1534         (JSC::B3::Air::Code::addSpecial):
1535         (JSC::B3::Air::Code::cCallSpecial):
1536         * b3/air/AirCode.h:
1537         (JSC::B3::Air::Code::begin):
1538         (JSC::B3::Air::Code::end):
1539         (JSC::B3::Air::Code::stackSlots):
1540         (JSC::B3::Air::Code::specials):
1541         (JSC::B3::Air::Code::forAllTmps):
1542         (JSC::B3::Air::Code::StackSlotsCollection::StackSlotsCollection): Deleted.
1543         (JSC::B3::Air::Code::StackSlotsCollection::size): Deleted.
1544         (JSC::B3::Air::Code::StackSlotsCollection::at): Deleted.
1545         (JSC::B3::Air::Code::StackSlotsCollection::operator[]): Deleted.
1546         (JSC::B3::Air::Code::StackSlotsCollection::iterator::iterator): Deleted.
1547         (JSC::B3::Air::Code::StackSlotsCollection::iterator::operator*): Deleted.
1548         (JSC::B3::Air::Code::StackSlotsCollection::iterator::operator++): Deleted.
1549         (JSC::B3::Air::Code::StackSlotsCollection::iterator::operator==): Deleted.
1550         (JSC::B3::Air::Code::StackSlotsCollection::iterator::operator!=): Deleted.
1551         (JSC::B3::Air::Code::StackSlotsCollection::begin): Deleted.
1552         (JSC::B3::Air::Code::StackSlotsCollection::end): Deleted.
1553         (JSC::B3::Air::Code::SpecialsCollection::SpecialsCollection): Deleted.
1554         (JSC::B3::Air::Code::SpecialsCollection::size): Deleted.
1555         (JSC::B3::Air::Code::SpecialsCollection::at): Deleted.
1556         (JSC::B3::Air::Code::SpecialsCollection::operator[]): Deleted.
1557         (JSC::B3::Air::Code::SpecialsCollection::iterator::iterator): Deleted.
1558         (JSC::B3::Air::Code::SpecialsCollection::iterator::operator*): Deleted.
1559         (JSC::B3::Air::Code::SpecialsCollection::iterator::operator++): Deleted.
1560         (JSC::B3::Air::Code::SpecialsCollection::iterator::operator==): Deleted.
1561         (JSC::B3::Air::Code::SpecialsCollection::iterator::operator!=): Deleted.
1562         (JSC::B3::Air::Code::SpecialsCollection::begin): Deleted.
1563         (JSC::B3::Air::Code::SpecialsCollection::end): Deleted.
1564         * b3/air/AirFixObviousSpills.cpp:
1565         * b3/air/AirInstInlines.h:
1566         * b3/air/AirIteratedRegisterCoalescing.cpp:
1567         * b3/air/AirLiveness.h:
1568         * b3/air/AirLowerAfterRegAlloc.cpp:
1569         (JSC::B3::Air::lowerAfterRegAlloc):
1570         * b3/air/AirSpecial.cpp:
1571         (JSC::B3::Air::Special::Special):
1572         * b3/air/AirSpecial.h:
1573         * b3/air/AirSpillEverything.cpp:
1574         (JSC::B3::Air::spillEverything):
1575         * b3/air/AirStackSlot.cpp:
1576         (JSC::B3::Air::StackSlot::dump):
1577         (JSC::B3::Air::StackSlot::deepDump):
1578         (JSC::B3::Air::StackSlot::StackSlot):
1579         * b3/air/AirStackSlot.h:
1580         (JSC::B3::Air::StackSlot::byteSize):
1581         (JSC::B3::Air::StackSlot::kind):
1582         (JSC::B3::Air::StackSlot::isLocked):
1583         (JSC::B3::Air::StackSlot::isSpill):
1584         (JSC::B3::Air::StackSlot::index):
1585         (JSC::B3::Air::StackSlot::ensureSize):
1586         * b3/air/AirStackSlotKind.cpp: Copied from Source/JavaScriptCore/b3/B3StackSlotKind.cpp.
1587         (WTF::printInternal):
1588         * b3/air/AirStackSlotKind.h: Copied from Source/JavaScriptCore/b3/B3StackSlotKind.h.
1589         * b3/air/opcode_generator.rb:
1590         * b3/air/testair.cpp:
1591         (JSC::B3::Air::testShuffleBroadcastAllRegs):
1592         (JSC::B3::Air::testShuffleShiftAllRegs):
1593         (JSC::B3::Air::testShuffleRotateAllRegs):
1594         * b3/testb3.cpp:
1595         (JSC::B3::testStackSlot):
1596         (JSC::B3::testStoreLoadStackSlot):
1597         * ftl/FTLB3Output.cpp:
1598         (JSC::FTL::Output::lockedStackSlot):
1599         (JSC::FTL::Output::neg):
1600         * ftl/FTLLowerDFGToLLVM.cpp:
1601         (JSC::FTL::DFG::LowerDFGToLLVM::compileInvalidationPoint):
1602
1603 2016-02-02  Yusuke Suzuki  <utatane.tea@gmail.com>
1604
1605         [JSC] Introduce BytecodeIntrinsic constant rep like @undefined
1606         https://bugs.webkit.org/show_bug.cgi?id=153737
1607
1608         Reviewed by Darin Adler.
1609
1610         This patch enhances existing BytecodeIntrinsic mechanism to accept `@xxx` form,
1611         that will be used to represent bytecode intrinsic constants.
1612         After this change, we can use 2 forms for bytecode intrinsics. (1) Function form (like, @toString(value))
1613         and (2) Constant form (like @undefined).
1614
1615         Bytecode intrinsic constants allow us to easily expose constant values from C++ world.
1616         For example, we can expose ArrayIterationKind flags to JS world without using private global variables.
1617         Exposed constant values are loaded from bytecodes directly through constant registers.
1618         While previously we expose them through private global variables, bytecode intrinsic constants
1619         can be loaded directly from CodeBlock. And later, it will become JSConstant in DFG.
1620
1621         And by using this mechanism, we implement several constants. @undefined, @arrayIterationKindKeyValue etc.
1622
1623         * builtins/ArrayConstructor.js:
1624         (from):
1625         * builtins/ArrayIteratorPrototype.js:
1626         (next):
1627         * builtins/ArrayPrototype.js:
1628         (reduce):
1629         (reduceRight):
1630         (every):
1631         (forEach):
1632         (filter):
1633         (map):
1634         (some):
1635         (fill):
1636         (find):
1637         (findIndex):
1638         (includes):
1639         (sort.compactSparse):
1640         (sort.compactSlow):
1641         (sort.compact):
1642         (sort):
1643         (copyWithin):
1644         * builtins/DatePrototype.js:
1645         (toLocaleString.toDateTimeOptionsAnyAll):
1646         (toLocaleString):
1647         (toLocaleDateString.toDateTimeOptionsDateDate):
1648         (toLocaleDateString):
1649         (toLocaleTimeString.toDateTimeOptionsTimeTime):
1650         (toLocaleTimeString):
1651         * builtins/GeneratorPrototype.js:
1652         (generatorResume):
1653         * builtins/GlobalObject.js:
1654         (isDictionary):
1655         * builtins/InternalPromiseConstructor.js:
1656         (internalAll.newResolveElement):
1657         (internalAll):
1658         * builtins/IteratorPrototype.js:
1659         (symbolIteratorGetter):
1660         (symbolIterator): Deleted.
1661         * builtins/MapPrototype.js:
1662         (forEach):
1663         * builtins/ModuleLoaderObject.js:
1664         (newRegistryEntry):
1665         (forceFulfillPromise):
1666         (commitInstantiated):
1667         (requestFetch):
1668         (requestTranslate):
1669         (requestInstantiate):
1670         (requestLink):
1671         (provide):
1672         * builtins/PromiseConstructor.js:
1673         (all.newResolveElement):
1674         (all):
1675         (race):
1676         (reject):
1677         (resolve):
1678         * builtins/PromiseOperations.js:
1679         (newPromiseCapability.executor):
1680         (newPromiseCapability):
1681         (rejectPromise):
1682         (fulfillPromise):
1683         (createResolvingFunctions.resolve):
1684         (createResolvingFunctions.reject):
1685         (createResolvingFunctions):
1686         (promiseReactionJob):
1687         (promiseResolveThenableJob):
1688         (initializePromise):
1689         * builtins/PromisePrototype.js:
1690         (catch):
1691         (then):
1692         * builtins/SetPrototype.js:
1693         (forEach):
1694         * builtins/StringConstructor.js:
1695         (raw):
1696         * builtins/StringIteratorPrototype.js:
1697         (next):
1698         * builtins/StringPrototype.js:
1699         (localeCompare):
1700         * builtins/TypedArrayConstructor.js:
1701         (of):
1702         (from):
1703         * builtins/TypedArrayPrototype.js:
1704         (every):
1705         (find):
1706         (findIndex):
1707         (forEach):
1708         (some):
1709         (reduce):
1710         (reduceRight):
1711         (map):
1712         (filter):
1713         * bytecode/BytecodeIntrinsicRegistry.cpp:
1714         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
1715         (JSC::BytecodeIntrinsicRegistry::lookup):
1716         * bytecode/BytecodeIntrinsicRegistry.h:
1717         * bytecompiler/NodesCodegen.cpp:
1718         * parser/ASTBuilder.h:
1719         (JSC::ASTBuilder::createResolve):
1720         (JSC::ASTBuilder::makeFunctionCallNode):
1721         * parser/NodeConstructors.h:
1722         (JSC::BytecodeIntrinsicNode::BytecodeIntrinsicNode):
1723         * parser/Nodes.h:
1724         (JSC::ExpressionNode::isBytecodeIntrinsicNode):
1725         (JSC::BytecodeIntrinsicNode::type):
1726         (JSC::BytecodeIntrinsicNode::emitter):
1727         * parser/Parser.cpp:
1728         (JSC::Parser<LexerType>::parseProperty):
1729         (JSC::Parser<LexerType>::parsePrimaryExpression):
1730         * parser/SyntaxChecker.h:
1731         (JSC::SyntaxChecker::createResolve):
1732         * runtime/CommonIdentifiers.cpp:
1733         (JSC::CommonIdentifiers::CommonIdentifiers): Deleted.
1734         * runtime/CommonIdentifiers.h:
1735         (JSC::CommonIdentifiers::bytecodeIntrinsicRegistry): Deleted.
1736         * runtime/IteratorPrototype.cpp:
1737         (JSC::IteratorPrototype::finishCreation):
1738         * runtime/JSGlobalObject.cpp:
1739         (JSC::JSGlobalObject::init): Deleted.
1740         * runtime/VM.cpp:
1741         (JSC::VM::VM):
1742         * runtime/VM.h:
1743         (JSC::VM::bytecodeIntrinsicRegistry):
1744
1745 2016-02-02  Per Arne Vollan  <peavo@outlook.com>
1746
1747         [B3][Win64] Compile fixes.
1748         https://bugs.webkit.org/show_bug.cgi?id=153605
1749
1750         Reviewed by Filip Pizlo.
1751
1752         Fix remaining compile errors on Win64.
1753
1754         * CMakeLists.txt:
1755         * b3/B3CFG.h:
1756         (JSC::B3::CFG::newMap):
1757         * ftl/FTLJITCode.h:
1758
1759 2016-02-01  Chris Dumez  <cdumez@apple.com>
1760
1761         object.__lookupGetter__() / object.__lookupSetter__() does not work for native bindings
1762         https://bugs.webkit.org/show_bug.cgi?id=153765
1763         <rdar://problem/24439699>
1764
1765         Reviewed by Oliver Hunt.
1766
1767         Add support for CustomAccessor slots to objectProtoFuncLookupGetter() and
1768         objectProtoFuncLookupSetter() by return getOwnPropertyDescriptor().get / set.
1769         getOwnPropertyDescriptor() now correctly deals with CustomAccessors since
1770         r196001.
1771
1772         * runtime/ObjectPrototype.cpp:
1773         (JSC::objectProtoFuncLookupGetter):
1774         (JSC::objectProtoFuncLookupSetter):
1775
1776 2016-02-01  Chris Dumez  <cdumez@apple.com>
1777
1778         Native Bindings Descriptors are Incomplete
1779         https://bugs.webkit.org/show_bug.cgi?id=140575
1780         <rdar://problem/19506502>
1781
1782         Reviewed by Oliver Hunt.
1783
1784         This patch is based on initial work by Joe Pecoraro and Matthew Mirman.
1785
1786         This patch was initially rolled out for breaking chromeexperiments.com,
1787         presumably because our IDL attributes were not marked as [configurable]
1788         at the time. However, since r190104, our IDL attributes are now
1789         configurable. Based on local testing, chromeexperiments.com seems to be
1790         working fine now.
1791
1792         * JavaScriptCore.xcodeproj/project.pbxproj:
1793         * inspector/InjectedScriptSource.js:
1794         (endsWith):
1795         (InjectedScript.prototype.processProperties):
1796         * runtime/JSBoundSlotBaseFunction.cpp: Added.
1797         (JSC::boundSlotBaseFunctionCall):
1798         (JSC::JSBoundSlotBaseFunction::JSBoundSlotBaseFunction):
1799         (JSC::JSBoundSlotBaseFunction::create):
1800         (JSC::JSBoundSlotBaseFunction::visitChildren):
1801         (JSC::JSBoundSlotBaseFunction::finishCreation):
1802         * runtime/JSBoundSlotBaseFunction.h: Added.
1803         (JSC::JSBoundSlotBaseFunction::createStructure):
1804         (JSC::JSBoundSlotBaseFunction::boundSlotBase):
1805         (JSC::JSBoundSlotBaseFunction::customGetterSetter):
1806         (JSC::JSBoundSlotBaseFunction::isSetter):
1807         * runtime/JSGlobalObject.cpp:
1808         (JSC::JSGlobalObject::init):
1809         (JSC::JSGlobalObject::visitChildren):
1810         * runtime/JSGlobalObject.h:
1811         (JSC::JSGlobalObject::boundSlotBaseFunctionStructure):
1812         * runtime/JSObject.cpp:
1813         (JSC::getBoundSlotBaseFunctionForGetterSetter):
1814         (JSC::JSObject::getOwnPropertyDescriptor):
1815         * runtime/VM.cpp:
1816         (JSC::VM::VM):
1817         * runtime/VM.h:
1818
1819 2016-02-01  Joseph Pecoraro  <pecoraro@apple.com>
1820
1821         Web Inspector: High Level Memory Overview Instrument
1822         https://bugs.webkit.org/show_bug.cgi?id=153516
1823         <rdar://problem/24356378>
1824
1825         Reviewed by Brian Burg.
1826
1827         * CMakeLists.txt:
1828         * Configurations/FeatureDefines.xcconfig:
1829         * DerivedSources.make:
1830         * inspector/protocol/Memory.json: Added.
1831         * inspector/scripts/codegen/generator.py:
1832         New Memory domain guarded by ENABLE(RESOURCE_USAGE).
1833         This feature flag was already used in WebCore.
1834
1835 2016-02-01  Benjamin Poulain  <benjamin@webkit.org>
1836
1837         [JSC] IRC can coalesce the frame pointer with a Tmp that is modified
1838         https://bugs.webkit.org/show_bug.cgi?id=153694
1839
1840         Reviewed by Filip Pizlo.
1841
1842         Let's say we have:
1843             Move(FP, Tmp1)
1844             Add64(#1, Tmp1)
1845
1846         If we were to coalesce the Move, we would modify the frame pointer.
1847         Well, that's exactly what was happening with IRC.
1848
1849         Since the epilogue is not know to Air before IRC, the liveness analysis
1850         never discovers that FP is live when Tmp1 is UseDef by Add64. Adding
1851         FP would a be a problem anyway for a bunch of reasons.
1852
1853         I tried two ways to prevent IRC to override IRC:
1854         1) Add an interference edge with FP for all non-duplication Defs.
1855         2) Let coalesce() know about FP and constraint any coalescing with a re-Def.
1856
1857         The two are within margin of error for performance. The second one was considerably
1858         more complicated. This patch implements the first one.
1859
1860         Some extra note:
1861         -It is very important to not increment the degree of a Tmp when making it interfere
1862          with FP. FP is not a valid color, it is not counted in the "K" colors considered
1863          for coloring. Increasing the degree with the edge to FP would make every stage
1864          pessimistic since there is an extra degree that can never be removed.
1865         -I put "interferenceEdges" and "adjacencyList" in an inconsistent state.
1866          This is intentional, "interferenceEdges" is used to test the existence of an edge,
1867          "adjacencyList" is used to go over all the edges. In this case, we don't want
1868          the edge with FP to be considered when pruning the graph.
1869
1870         * b3/air/AirIteratedRegisterCoalescing.cpp:
1871         One branch could be transformed into an assertion: TmpLiveness is type specific now.
1872         * b3/testb3.cpp:
1873         (JSC::B3::testOverrideFramePointer):
1874         (JSC::B3::run):
1875
1876 2016-02-01  Csaba Osztrogonác  <ossy@webkit.org>
1877
1878         Unreviewed speculative buildfix.
1879
1880         * dfg/DFGCommon.h: FTL_USES_B3 should be false if FTL JIT is disabled.
1881
1882 2016-01-31  Dan Bernstein  <mitz@apple.com>
1883
1884         [Cocoa] Remove unused definition of HAVE_HEADER_DETECTION_H
1885         https://bugs.webkit.org/show_bug.cgi?id=153729
1886
1887         Reviewed by Sam Weinig.
1888
1889         After r141700, HAVE_HEADER_DETECTION_H is no longer used.
1890
1891         * Configurations/Base.xcconfig:
1892
1893 2016-01-30  Filip Pizlo  <fpizlo@apple.com>
1894
1895         B3->Air lowering should use MoveFloat more
1896         https://bugs.webkit.org/show_bug.cgi?id=153714
1897
1898         Reviewed by Sam Weinig.
1899
1900         This is a very minor and benign bug. It just means that we will use the more canonical
1901         MoveFloat instruction when moving floats, rather than using MoveDouble.
1902
1903         * b3/B3LowerToAir.cpp:
1904         (JSC::B3::Air::LowerToAir::relaxedMoveForType):
1905
1906 2016-01-31  Yusuke Suzuki  <utatane.tea@gmail.com>
1907
1908         Should not predict OtherObj for ToThis with primitive types under strict mode
1909         https://bugs.webkit.org/show_bug.cgi?id=153544
1910
1911         Reviewed by Filip Pizlo.
1912
1913         Currently, ToThis predicates OtherObj for primitive values.
1914         But it's not true in strict mode.
1915         In strict mode, ToThis does nothing on primitive values.
1916
1917         In this patch, we
1918
1919         1. fix prediction. Handles primitive types in strict mode. And we also handles StringObject.
1920         2. convert it to Identity if the argument should be predicted as primitive types.
1921
1922         This optimization is important to implement Primitive.prototype.methods[1].
1923         Otherwise, we always got BadType OSR exits.
1924
1925         [1]: https://bugs.webkit.org/show_bug.cgi?id=143889
1926
1927         * dfg/DFGAbstractInterpreterInlines.h:
1928         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1929         * dfg/DFGConstantFoldingPhase.cpp:
1930         (JSC::DFG::ConstantFoldingPhase::foldConstants):
1931         * dfg/DFGFixupPhase.cpp:
1932         (JSC::DFG::FixupPhase::fixupNode):
1933         (JSC::DFG::FixupPhase::fixupToThis):
1934         * dfg/DFGPredictionPropagationPhase.cpp:
1935         (JSC::DFG::PredictionPropagationPhase::propagate):
1936         * tests/stress/to-this-boolean.js: Added.
1937         (Boolean.prototype.negate):
1938         (Boolean.prototype.negate2):
1939         * tests/stress/to-this-double.js: Added.
1940         (Number.prototype.negate):
1941         * tests/stress/to-this-int32.js: Added.
1942         (Number.prototype.negate):
1943         * tests/stress/to-this-int52.js: Added.
1944         (Number.prototype.negate):
1945         * tests/stress/to-this-number.js: Added.
1946         (Number.prototype.negate):
1947         * tests/stress/to-this-string.js: Added.
1948         (String.prototype.prefix):
1949         (String.prototype.first):
1950         (String.prototype.second):
1951         * tests/stress/to-this-symbol.js: Added.
1952         (Symbol.prototype.identity):
1953         (Symbol.prototype.identity2):
1954
1955 2016-01-31  Guillaume Emont  <guijemont@igalia.com>
1956
1957         [mips] don't save to a callee saved register too early
1958         https://bugs.webkit.org/show_bug.cgi?id=153463
1959
1960         If we save $gp to $s4 in pichdr, then in some cases, we were
1961         overwriting $s4 before LLInt's pushCalleeSaves() is called (as pichdr
1962         is at the very beginning of a function). Now we save $gp to $s4 at the
1963         end of pushCalleeSaves().
1964
1965         Reviewed by Michael Saboff.
1966
1967         * offlineasm/mips.rb:
1968         * llint/LowLevelInterpreter.asm:
1969         Move the saving of $gp to $s4 from pichdr to pushCalleeSaves(). Take
1970         the opportunity to only save $s4 as we never use the other callee
1971         saved registers.
1972
1973 2016-01-30  Commit Queue  <commit-queue@webkit.org>
1974
1975         Unreviewed, rolling out r195799 and r195828.
1976         https://bugs.webkit.org/show_bug.cgi?id=153722
1977
1978         Caused assertion failures, severely affecting EWS (Requested
1979         by ap on #webkit).
1980
1981         Reverted changesets:
1982
1983         "Web Inspector: InspectorTimelineAgent doesn't need to
1984         recompile functions because it now uses the sampling profiler"
1985         https://bugs.webkit.org/show_bug.cgi?id=153500
1986         http://trac.webkit.org/changeset/195799
1987
1988         "Attempt to fix the Windows build after r195799"
1989         http://trac.webkit.org/changeset/195828
1990
1991 2016-01-30  Yusuke Suzuki  <utatane.tea@gmail.com>
1992
1993         [B3] JetStream/quicksort.c fails/hangs on Linux with GCC
1994         https://bugs.webkit.org/show_bug.cgi?id=153647
1995
1996         Reviewed by Filip Pizlo.
1997
1998         In B3ComputeDivisionMagic, we accidentally perform sub, add operation onto signed integer. (In this case, int32_t)
1999         But integer overflow is undefined behavior in C![1][2]
2000         As a result, in GCC 4.9 release build, computeDivisionMagic(2) returns unexpected value.
2001         `divisor = 2`
2002         `d = 2`
2003         `signedMin = INT32_MIN = -2147483647 (-0x7fffffff)`
2004         `t = signedMin`
2005         `anc = t - 1 - (t % ad)` Oops, we performed overflow operation!
2006
2007         So, `anc` value becomes undefined.
2008         In this patch, we first cast all the operated values to unsigned one.
2009         Reading the code, there are no operations that depends on signedness. (For example, we used aboveEqual like unsigned operations for comparison.)
2010
2011         [1]: http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
2012         [2]: http://dl.acm.org/citation.cfm?id=2522728
2013
2014         * b3/B3ComputeDivisionMagic.h:
2015         (JSC::B3::computeDivisionMagic):
2016         * b3/testb3.cpp:
2017         (JSC::B3::testComputeDivisionMagic):
2018         (JSC::B3::run):
2019
2020 2016-01-30  Andreas Kling  <akling@apple.com>
2021
2022         Shrink Heap::m_executables after cleaning it.
2023         <https://webkit.org/b/153682>
2024
2025         Reviewed by Darin Adler.
2026
2027         The Heap::m_executables Vector was never shrunk down, despite sometimes
2028         getting pretty huge (~500kB in my longest-running WebContent process.)
2029
2030         After GC has finished pruning unmarked Executables, shrink the Vector.
2031
2032         * heap/Heap.cpp:
2033         (JSC::Heap::clearUnmarkedExecutables):
2034
2035 2016-01-29  Ada Chan  <adachan@apple.com>
2036
2037         Enable VIDEO_PRESENTATION_MODE only in Debug and Release builds on Mac
2038         https://bugs.webkit.org/show_bug.cgi?id=153665
2039
2040         Reviewed by Dan Bernstein.
2041
2042         * Configurations/FeatureDefines.xcconfig:
2043
2044 2016-01-30  Yusuke Suzuki  <utatane.tea@gmail.com>
2045
2046         [B3] REGRESSION(r195882): Should break early after modConstant replaceWithNewValue succeeds
2047         https://bugs.webkit.org/show_bug.cgi?id=153711
2048
2049         Reviewed by Filip Pizlo.
2050
2051         Should break after modConstant replaceWithNewValue succeeds. m_value is already replaced with Identity
2052         if modConstant succeeds. So it does not have any children. m_value->child(1) breaks testb3.
2053
2054         * b3/B3ReduceStrength.cpp:
2055
2056 2016-01-30  Yusuke Suzuki  <utatane.tea@gmail.com>
2057
2058         Enable SamplingProfiler on POSIX environment
2059         https://bugs.webkit.org/show_bug.cgi?id=153584
2060
2061         Reviewed by Michael Saboff.
2062
2063         In this patch, we implement suspend and resume mechanizm for POSIX threads.
2064         And with GLIBC, we can retrieve registers from it.
2065
2066         We take the following strategy.
2067
2068         Suspend side.
2069         1. install sigaction to the threads.
2070         2. in the profiler (suspend / resume callers), emit signal with pthread_kill and wait with POSIX semaphore.
2071         3. in the signal handler, up the POSIX semaphore. Use sem_post because it is the async-signal-safe function in POSIX.
2072         4. in the signal handler, perform sigsuspend to stop the thread until being resumed.
2073         5. in the profiler, we can be waken up from the semaphore because (3) ups.
2074
2075         Resume side.
2076         1. in the profiler, emit signal and wait on the semaphore.
2077         2. in the signal handler, it is waken up from the sigsuspend.
2078         3. in the signal handler, up the semaphore.
2079         4. in the profiler, the profiler is waken up from the semaphore. It is ensured that the given thread is resumed by the signal.
2080
2081         * heap/MachineStackMarker.cpp:
2082         (pthreadSignalHandlerSuspendResume):
2083         (JSC::MachineThreads::Thread::Thread):
2084         (JSC::MachineThreads::Thread::~Thread):
2085         (JSC::MachineThreads::Thread::suspend):
2086         (JSC::MachineThreads::Thread::resume):
2087         (JSC::MachineThreads::Thread::getRegisters):
2088         (JSC::MachineThreads::Thread::Registers::stackPointer):
2089         (JSC::MachineThreads::Thread::Registers::framePointer):
2090         (JSC::MachineThreads::Thread::Registers::instructionPointer):
2091         (JSC::MachineThreads::Thread::Registers::llintPC):
2092         (JSC::MachineThreads::Thread::freeRegisters):
2093         * heap/MachineStackMarker.h:
2094         * runtime/SamplingProfiler.cpp:
2095         (JSC::reportStats):
2096         * tests/stress/call-varargs-from-inlined-code-with-odd-number-of-arguments.js:
2097         * tests/stress/call-varargs-from-inlined-code.js:
2098         * tests/stress/v8-earley-boyer-strict.js:
2099
2100 2016-01-29  Filip Pizlo  <fpizlo@apple.com>
2101
2102         B3 should reduce Mod(value, constant) to Div and Mul so that our Div optimizations can do things
2103         https://bugs.webkit.org/show_bug.cgi?id=153693
2104
2105         Reviewed by Saam Barati.
2106
2107         The most efficient way to handle Mod(value, constant) is to reduce it to
2108         Sub(value, Mul(Div(value, constant), constant)) and then let the Div optimizations do their
2109         thing.
2110
2111         In the future we could add special handling of Mod(value, 1 << constant), but it's not
2112         obvious that this would produce better code than reducing through Div, if we also make sure
2113         that we have great optimizations for Mul and Div.
2114
2115         * b3/B3ReduceStrength.cpp:
2116
2117 2016-01-29  Keith Miller  <keith_miller@apple.com>
2118
2119         Array.prototype native functions should use Symbol.species to construct the result
2120         https://bugs.webkit.org/show_bug.cgi?id=153660
2121
2122         Reviewed by Saam Barati.
2123
2124         This patch adds support for Symbol.species in the Array.prototype native functions.
2125         We make an optimization to avoid regressions on some benchmarks by using an
2126         adaptive watchpoint to check if Array.prototype.constructor is ever changed.
2127
2128         * runtime/ArrayPrototype.cpp:
2129         (JSC::putLength):
2130         (JSC::setLength):
2131         (JSC::speciesConstructArray):
2132         (JSC::arrayProtoFuncConcat):
2133         (JSC::arrayProtoFuncSlice):
2134         (JSC::arrayProtoFuncSplice):
2135         (JSC::ArrayPrototype::setConstructor):
2136         (JSC::ArrayPrototypeAdaptiveInferredPropertyWatchpoint::ArrayPrototypeAdaptiveInferredPropertyWatchpoint):
2137         (JSC::ArrayPrototypeAdaptiveInferredPropertyWatchpoint::handleFire):
2138         * runtime/ArrayPrototype.h:
2139         (JSC::ArrayPrototype::didChangeConstructorProperty):
2140         * runtime/ConstructData.cpp:
2141         (JSC::construct):
2142         * runtime/ConstructData.h:
2143         * runtime/JSGlobalObject.cpp:
2144         (JSC::JSGlobalObject::init):
2145         * tests/es6.yaml:
2146         * tests/stress/array-species-functions.js: Added.
2147         (Symbol.species):
2148         (funcThrows):
2149         (test.species):
2150         (test):
2151
2152 2016-01-29  Filip Pizlo  <fpizlo@apple.com>
2153
2154         CallLinkStatus should trust BadCell exit sites whenever there is no stub
2155         https://bugs.webkit.org/show_bug.cgi?id=153691
2156
2157         Reviewed by Benjamin Poulain.
2158
2159         This fixes a regression in our treatment of inlining failure exit sites when deciding if we
2160         should inline a call.
2161
2162         A long time ago, a BadCell exit site would ensure that a CallLinkStatus returned
2163         takesSlowPath.
2164
2165         But then we added closure calls. A BadCell exit site might just mean that we should do
2166         closure call inlining. We added a BadExecutable exit site to indicate that even closure call
2167         inlining had failed. BadCell would no longer force CallLinkStatus to return takesSlowPath,
2168         but BadExecutable would stuff do so.
2169
2170         But then we unified the IR for checking functions and executables, and the DFG stopped using
2171         the BadExecutable exit kind. Probably this change disabled our ability to use exit site
2172         counting for deciding when to takesSlowPath. But this isn't necessarily a disaster, since
2173         any time you exited in this way, you'd be taken to a baseline call inline cache, and that
2174         inline cache would record the slow path.
2175
2176         But then we introduced polymorphic call inlining. Polymorphic call inlining means that call
2177         unlinking, like when one of the callees is optimized, will reset the stub. We also made it
2178         so that the stub is like a gate for the slow path count. A clear inline cache must first
2179         cause the creation of a stub and then cause it to overflow before the slow path is counted.
2180
2181         So, if the DFG or FTL exits on a cell check associated with a particular callsite being
2182         speculatively inlined, then it's possible that nobody will know about the exit because:
2183
2184         - The exit kind is BadCell but CallLinkStatus needs BadExecutable to disable inlining.
2185
2186         - Between when we tiered up to the DFG (or FTL) and when the exit happened, one of the
2187           callees was tiered up, causing the baseline CallLinkInfo to be unlinked. Therefore, after
2188           the exit, the inline cache is in a reset state and will not count the call as taking slow
2189           path.
2190
2191         The challenge when dealing with this is that often, we will have an super early compilation
2192         of a minimorphic call site before we have seen all of its small set of callees. For example
2193         we may have seen only one of two possible callees. That early compilation will OSR exit, and
2194         in trunk, will be recompiled with bimorphic speculative inlining. That's a pretty good
2195         outcome. Basically, we are trusting that if during the time that the function has been
2196         running prior to a given compilation, a callsite has only seen a small number of callees,
2197         then it's safe to assume that it won't see another one anytime soon.
2198
2199         So, simply forcing the CallLinkStatus to set takesSlowPath any time there was a BadCell exit
2200         would hurt our performance in some cases, because trunk prior to this change would have their
2201         final compilation use speculative inlining, and this change would make guarded inlining
2202         instead.
2203
2204         The compromise that I came up with relies on the fact that a CallLinkInfo must be reset quite
2205         frequently for it to routinely happen in between tier-up to DFG (or FTL) and an exit. So,
2206         most likely, such a CallLinkInfo will also show up as being clear when the CallLinkStatus
2207         is built during DFG profiling. The CallLinkStatus will then fall back on the CallLinkInfo's
2208         lastSeenCallee field, which is persistent across resets. This change just makes it so that
2209         CallLinkStatus sets takesSlowPath if there is a BadCell exit and the status had to be
2210         inferred from the lastSeenCallee.
2211
2212         This change reduces pointless recompilations in gbemu. It's an 11% speed-up on gbemu. It
2213         doesn't seem to hurt any benchmarks.
2214
2215         * bytecode/CallLinkStatus.cpp:
2216         (JSC::CallLinkStatus::computeFor):
2217         (JSC::CallLinkStatus::computeExitSiteData):
2218         (JSC::CallLinkStatus::computeFromCallLinkInfo):
2219         * bytecode/CallLinkStatus.h:
2220         (JSC::CallLinkStatus::CallLinkStatus):
2221         (JSC::CallLinkStatus::at):
2222         (JSC::CallLinkStatus::operator[]):
2223         (JSC::CallLinkStatus::isProved):
2224         (JSC::CallLinkStatus::isBasedOnStub):
2225         (JSC::CallLinkStatus::canOptimize):
2226         (JSC::CallLinkStatus::maxNumArguments):
2227         (JSC::CallLinkStatus::ExitSiteData::ExitSiteData): Deleted.
2228
2229 2016-01-29  Saam barati  <sbarati@apple.com>
2230
2231         Pack FunctionExecutable and UnlinkedFunctionExecutable harder
2232         https://bugs.webkit.org/show_bug.cgi?id=153687
2233
2234         Reviewed by Andreas Kling.
2235
2236         This patch reduces FunctionExecutable from 120 to 104 bytes.
2237         This patch reduces UnlinkedFunctionExecutable from 144 to 136 bytes.
2238
2239         * bytecode/ExecutableInfo.h:
2240         * bytecode/UnlinkedFunctionExecutable.cpp:
2241         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
2242         * bytecode/UnlinkedFunctionExecutable.h:
2243         * parser/ParserModes.h:
2244         (JSC::functionNameScopeIsDynamic):
2245         * runtime/Executable.cpp:
2246         (JSC::ScriptExecutable::ScriptExecutable):
2247         * runtime/Executable.h:
2248         (JSC::ScriptExecutable::needsActivation):
2249         (JSC::ScriptExecutable::isArrowFunctionContext):
2250         (JSC::ScriptExecutable::isStrictMode):
2251         (JSC::ScriptExecutable::derivedContextType):
2252         (JSC::ScriptExecutable::ecmaMode):
2253         (JSC::ScriptExecutable::finishCreation):
2254
2255 2016-01-29  Saam barati  <sbarati@apple.com>
2256
2257         JSC Sampling Profiler: Come up with a (program counter => CodeOrigin) mapping
2258         https://bugs.webkit.org/show_bug.cgi?id=152629
2259
2260         Reviewed by Filip Pizlo.
2261
2262         This patch implements a mapping from PC to CodeOrigin
2263         that lives off of JITed CodeBlocks. We build this mapping
2264         while JITing code, and then we compress it and store
2265         it on the CodeBlock. We only build the mapping if a debugger
2266         has ever been attached to any global object.
2267
2268         CodeBlock consults this mapping when searching for a CodeOrigin
2269         for a given PC, but it also consults other code ranges
2270         off the main path that may own the PC. Specifically, it searches
2271         through inline caches, OSRExits, and LazySlowPaths.
2272
2273         To find PC info for the LLInt, we also save the LLInt pc when
2274         taking a stack trace where the top frame is in LLInt code.
2275
2276         This patch also cleans up code inside the SamplingProfier.
2277         I realized a bug in the SamplingProfiler's implementation.
2278         We used to walk the inline stack while gathering a stack
2279         trace. This is wrong. It's super dangerous to do this because
2280         we might pause the JSC process while it's modifying its
2281         CodeOrigin table. We used to walk the inline stack while
2282         taking a stack trace because doing so could save us from
2283         having to verify a particular stack trace. This patch changes that.
2284         We now have to verify all stack traces taken. This verification step
2285         includes walking the inline stack.
2286
2287         Because we have a PC=>CodeOrigin map, we can now gather more
2288         detailed information about the top-frame we pause. This allows
2289         us to correctly observe inlining. It also allows us to observe
2290         expression-level line/column information for the top frame.
2291         The reason we don't consult this mapping for parent frames is 
2292         that all parent frames should set the CallSiteIndex on the call
2293         frame header, which means we can consult that value to get inlining 
2294         and expression-level line/column information.
2295
2296         * CMakeLists.txt:
2297         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
2298         * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
2299         * JavaScriptCore.xcodeproj/project.pbxproj:
2300         * assembler/AbstractMacroAssembler.h:
2301         (JSC::AbstractMacroAssembler::Label::Label):
2302         (JSC::AbstractMacroAssembler::Label::operator==):
2303         (JSC::AbstractMacroAssembler::Label::isSet):
2304         * assembler/AssemblerBuffer.h:
2305         (JSC::AssemblerLabel::labelAtOffset):
2306         (JSC::AssemblerLabel::operator==):
2307         * b3/B3Generate.cpp:
2308         * b3/B3Origin.h:
2309         (JSC::B3::Origin::data):
2310         (JSC::B3::Origin::operator==):
2311         * b3/B3PCToOriginMap.h: Added.
2312         (JSC::B3::PCToOriginMap::PCToOriginMap):
2313         (JSC::B3::PCToOriginMap::appendItem):
2314         (JSC::B3::PCToOriginMap::ranges):
2315         * b3/B3Procedure.h:
2316         (JSC::B3::Procedure::pcToOriginMap):
2317         (JSC::B3::Procedure::releasePCToOriginMap):
2318         * b3/air/AirGenerate.cpp:
2319         (JSC::B3::Air::generate):
2320         * bytecode/CodeBlock.cpp:
2321         (JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
2322         (JSC::CodeBlock::setPCToCodeOriginMap):
2323         (JSC::CodeBlock::findPC):
2324         * bytecode/CodeBlock.h:
2325         (JSC::CodeBlock::jitCodeMap):
2326         (JSC::CodeBlock::bytecodeOffset):
2327         * bytecode/CodeOrigin.h:
2328         (JSC::CodeOrigin::operator==):
2329         (JSC::CodeOriginHash::hash):
2330         (JSC::CodeOriginHash::equal):
2331         * bytecode/InlineCallFrame.h:
2332         (JSC::baselineCodeBlockForOriginAndBaselineCodeBlock):
2333         (JSC::CodeOrigin::walkUpInlineStack):
2334         * bytecode/PolymorphicAccess.h:
2335         (JSC::PolymorphicAccess::containsPC):
2336         * bytecode/StructureStubInfo.cpp:
2337         (JSC::StructureStubInfo::visitWeakReferences):
2338         (JSC::StructureStubInfo::containsPC):
2339         * bytecode/StructureStubInfo.h:
2340         * bytecode/UnlinkedCodeBlock.h:
2341         (JSC::UnlinkedCodeBlock::hasExpressionInfo):
2342         (JSC::UnlinkedCodeBlock::expressionInfo):
2343         (JSC::UnlinkedCodeBlock::setThisRegister):
2344         * debugger/Debugger.cpp:
2345         (JSC::Debugger::attach):
2346         * dfg/DFGJITCode.cpp:
2347         (JSC::DFG::JITCode::validateReferences):
2348         (JSC::DFG::JITCode::findPC):
2349         * dfg/DFGJITCode.h:
2350         (JSC::DFG::JITCode::commonDataOffset):
2351         * dfg/DFGJITCompiler.cpp:
2352         (JSC::DFG::JITCompiler::JITCompiler):
2353         (JSC::DFG::JITCompiler::link):
2354         (JSC::DFG::JITCompiler::compile):
2355         (JSC::DFG::JITCompiler::compileFunction):
2356         (JSC::DFG::JITCompiler::recordCallSiteAndGenerateExceptionHandlingOSRExitIfNeeded):
2357         (JSC::DFG::JITCompiler::setEndOfMainPath):
2358         (JSC::DFG::JITCompiler::setEndOfCode):
2359         * dfg/DFGJITCompiler.h:
2360         (JSC::DFG::JITCompiler::setStartOfCode):
2361         (JSC::DFG::JITCompiler::setForNode):
2362         (JSC::DFG::JITCompiler::addCallSite):
2363         (JSC::DFG::JITCompiler::pcToCodeOriginMapBuilder):
2364         (JSC::DFG::JITCompiler::setEndOfMainPath): Deleted.
2365         (JSC::DFG::JITCompiler::setEndOfCode): Deleted.
2366         * dfg/DFGSlowPathGenerator.h:
2367         (JSC::DFG::SlowPathGenerator::call):
2368         (JSC::DFG::SlowPathGenerator::origin):
2369         * dfg/DFGSpeculativeJIT.cpp:
2370         (JSC::DFG::SpeculativeJIT::addSlowPathGenerator):
2371         (JSC::DFG::SpeculativeJIT::runSlowPathGenerators):
2372         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
2373         * dfg/DFGSpeculativeJIT.h:
2374         * ftl/FTLB3Compile.cpp:
2375         (JSC::FTL::compile):
2376         * ftl/FTLJITCode.cpp:
2377         (JSC::FTL::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
2378         (JSC::FTL::JITCode::findPC):
2379         * ftl/FTLJITCode.h:
2380         (JSC::FTL::JITCode::b3Code):
2381         * heap/MachineStackMarker.cpp:
2382         (JSC::MachineThreads::Thread::Registers::instructionPointer):
2383         (JSC::MachineThreads::Thread::Registers::llintPC):
2384         (JSC::MachineThreads::Thread::freeRegisters):
2385         * heap/MachineStackMarker.h:
2386         * inspector/agents/InspectorScriptProfilerAgent.cpp:
2387         (Inspector::InspectorScriptProfilerAgent::addEvent):
2388         (Inspector::buildSamples):
2389         (Inspector::InspectorScriptProfilerAgent::trackingComplete):
2390         * jit/JIT.cpp:
2391         (JSC::JIT::JIT):
2392         (JSC::JIT::privateCompileMainPass):
2393         (JSC::JIT::privateCompileSlowCases):
2394         (JSC::JIT::privateCompile):
2395         * jit/JIT.h:
2396         * jit/JITCode.h:
2397         (JSC::JITCode::findPC):
2398         * jit/PCToCodeOriginMap.cpp: Added.
2399         (JSC::PCToCodeOriginMapBuilder::PCToCodeOriginMapBuilder):
2400         (JSC::PCToCodeOriginMapBuilder::appendItem):
2401         (JSC::PCToCodeOriginMap::PCToCodeOriginMap):
2402         (JSC::PCToCodeOriginMap::~PCToCodeOriginMap):
2403         (JSC::PCToCodeOriginMap::memorySize):
2404         (JSC::PCToCodeOriginMap::findPC):
2405         * jit/PCToCodeOriginMap.h: Added.
2406         (JSC::PCToCodeOriginMapBuilder::defaultCodeOrigin):
2407         (JSC::PCToCodeOriginMapBuilder::didBuildMapping):
2408         * jsc.cpp:
2409         (functionSamplingProfilerStackTraces):
2410         * llint/LLIntPCRanges.h:
2411         (JSC::LLInt::isLLIntPC):
2412         * llint/LowLevelInterpreter.asm:
2413         * runtime/Options.h:
2414         * runtime/SamplingProfiler.cpp:
2415         (JSC::reportStats):
2416         (JSC::FrameWalker::FrameWalker):
2417         (JSC::FrameWalker::walk):
2418         (JSC::FrameWalker::resetAtMachineFrame):
2419         (JSC::FrameWalker::isValidFramePointer):
2420         (JSC::SamplingProfiler::SamplingProfiler):
2421         (JSC::SamplingProfiler::~SamplingProfiler):
2422         (JSC::tryGetBytecodeIndex):
2423         (JSC::SamplingProfiler::processUnverifiedStackTraces):
2424         (JSC::SamplingProfiler::visit):
2425         (JSC::SamplingProfiler::noticeVMEntry):
2426         (JSC::SamplingProfiler::clearData):
2427         (JSC::SamplingProfiler::StackFrame::displayName):
2428         (JSC::SamplingProfiler::StackFrame::displayNameForJSONTests):
2429         (JSC::SamplingProfiler::StackFrame::functionStartLine):
2430         (JSC::SamplingProfiler::StackFrame::functionStartColumn):
2431         (JSC::SamplingProfiler::StackFrame::sourceID):
2432         (JSC::SamplingProfiler::StackFrame::url):
2433         (JSC::SamplingProfiler::releaseStackTraces):
2434         (JSC::SamplingProfiler::stackTracesAsJSON):
2435         (WTF::printInternal):
2436         (JSC::SamplingProfiler::StackFrame::startLine): Deleted.
2437         (JSC::SamplingProfiler::StackFrame::startColumn): Deleted.
2438         (JSC::SamplingProfiler::stackTraces): Deleted.
2439         * runtime/SamplingProfiler.h:
2440         (JSC::SamplingProfiler::UnprocessedStackFrame::UnprocessedStackFrame):
2441         (JSC::SamplingProfiler::StackFrame::StackFrame):
2442         (JSC::SamplingProfiler::StackTrace::StackTrace):
2443         (JSC::SamplingProfiler::totalTime):
2444         (JSC::SamplingProfiler::setStopWatch):
2445         * runtime/VM.cpp:
2446         (JSC::VM::VM):
2447         * runtime/VM.h:
2448         (JSC::VM::setShouldBuildPCToCodeOriginMapping):
2449         (JSC::VM::shouldBuilderPCToCodeOriginMapping):
2450         * tests/stress/sampling-profiler-basic.js:
2451         (platformSupportsSamplingProfiler.top):
2452         (platformSupportsSamplingProfiler.jaz):
2453         (platformSupportsSamplingProfiler.kaz):
2454
2455 2016-01-29  Saam barati  <sbarati@apple.com>
2456
2457         Remove our notion of having a single activation register
2458         https://bugs.webkit.org/show_bug.cgi?id=153673
2459
2460         Reviewed by Filip Pizlo.
2461
2462         We have many functions lurking around where we think a function 
2463         might only have one activation register. This is clearly wrong
2464         now that ES6 has block scoping. This patch removes this false notion.
2465
2466         * bytecode/CodeBlock.cpp:
2467         (JSC::CodeBlock::dumpBytecode):
2468         (JSC::CodeBlock::CodeBlock):
2469         * bytecode/CodeBlock.h:
2470         (JSC::CodeBlock::scopeRegister):
2471         (JSC::CodeBlock::codeType):
2472         (JSC::CodeBlock::setActivationRegister): Deleted.
2473         (JSC::CodeBlock::activationRegister): Deleted.
2474         (JSC::CodeBlock::uncheckedActivationRegister): Deleted.
2475         (JSC::CodeBlock::needsActivation): Deleted.
2476         * bytecode/ExecutableInfo.h:
2477         (JSC::ExecutableInfo::ExecutableInfo):
2478         (JSC::ExecutableInfo::usesEval):
2479         (JSC::ExecutableInfo::isStrictMode):
2480         (JSC::ExecutableInfo::isConstructor):
2481         (JSC::ExecutableInfo::isClassContext):
2482         (JSC::ExecutableInfo::needsActivation): Deleted.
2483         * bytecode/UnlinkedCodeBlock.cpp:
2484         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
2485         * bytecode/UnlinkedCodeBlock.h:
2486         (JSC::UnlinkedCodeBlock::isArrowFunctionContext):
2487         (JSC::UnlinkedCodeBlock::isClassContext):
2488         (JSC::UnlinkedCodeBlock::setThisRegister):
2489         (JSC::UnlinkedCodeBlock::setScopeRegister):
2490         (JSC::UnlinkedCodeBlock::usesGlobalObject):
2491         (JSC::UnlinkedCodeBlock::setGlobalObjectRegister):
2492         (JSC::UnlinkedCodeBlock::thisRegister):
2493         (JSC::UnlinkedCodeBlock::scopeRegister):
2494         (JSC::UnlinkedCodeBlock::addPropertyAccessInstruction):
2495         (JSC::UnlinkedCodeBlock::needsFullScopeChain): Deleted.
2496         (JSC::UnlinkedCodeBlock::setActivationRegister): Deleted.
2497         (JSC::UnlinkedCodeBlock::activationRegister): Deleted.
2498         (JSC::UnlinkedCodeBlock::hasActivationRegister): Deleted.
2499         * bytecode/UnlinkedFunctionExecutable.cpp:
2500         (JSC::generateUnlinkedFunctionCodeBlock):
2501         * bytecompiler/BytecodeGenerator.cpp:
2502         (JSC::BytecodeGenerator::BytecodeGenerator):
2503         (JSC::BytecodeGenerator::initializeVarLexicalEnvironment):
2504         * bytecompiler/BytecodeGenerator.h:
2505         (JSC::BytecodeGenerator::destinationForAssignResult):
2506         (JSC::BytecodeGenerator::leftHandSideNeedsCopy):
2507         (JSC::BytecodeGenerator::emitNodeForLeftHandSide):
2508         * dfg/DFGByteCodeParser.cpp:
2509         (JSC::DFG::ByteCodeParser::inliningCost):
2510         (JSC::DFG::ByteCodeParser::parseCodeBlock):
2511         * dfg/DFGGraph.h:
2512         (JSC::DFG::Graph::hasExitSite):
2513         (JSC::DFG::Graph::activationRegister): Deleted.
2514         (JSC::DFG::Graph::uncheckedActivationRegister): Deleted.
2515         (JSC::DFG::Graph::machineActivationRegister): Deleted.
2516         (JSC::DFG::Graph::uncheckedMachineActivationRegister): Deleted.
2517         * dfg/DFGStackLayoutPhase.cpp:
2518         (JSC::DFG::StackLayoutPhase::run):
2519         * interpreter/CallFrame.cpp:
2520         (JSC::CallFrame::callSiteIndex):
2521         (JSC::CallFrame::stack):
2522         (JSC::CallFrame::callerFrame):
2523         (JSC::CallFrame::friendlyFunctionName):
2524         (JSC::CallFrame::hasActivation): Deleted.
2525         (JSC::CallFrame::uncheckedActivation): Deleted.
2526         (JSC::CallFrame::lexicalEnvironment): Deleted.
2527         (JSC::CallFrame::lexicalEnvironmentOrNullptr): Deleted.
2528         (JSC::CallFrame::setActivation): Deleted.
2529         * interpreter/CallFrame.h:
2530         (JSC::ExecState::scope):
2531         (JSC::ExecState::setCallerFrame):
2532         (JSC::ExecState::setScope):
2533         (JSC::ExecState::init):
2534         * interpreter/Register.h:
2535         * llint/LLIntSlowPaths.cpp:
2536         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2537         * runtime/Executable.h:
2538         (JSC::ScriptExecutable::usesEval):
2539         (JSC::ScriptExecutable::usesArguments):
2540         (JSC::ScriptExecutable::isArrowFunctionContext):
2541         (JSC::ScriptExecutable::isStrictMode):
2542         (JSC::ScriptExecutable::derivedContextType):
2543         (JSC::ScriptExecutable::needsActivation): Deleted.
2544         * runtime/JSLexicalEnvironment.h:
2545         (JSC::asActivation):
2546         (JSC::Register::lexicalEnvironment): Deleted.
2547
2548 2016-01-29  Filip Pizlo  <fpizlo@apple.com>
2549
2550         Air:fixObviousSpills should handle floats and doubles
2551         https://bugs.webkit.org/show_bug.cgi?id=153197
2552
2553         Reviewed by Saam Barati.
2554
2555         This adds the most obvious handling of float spills, where we just enable load elimination on
2556         float spill code.
2557
2558         * b3/air/AirFixObviousSpills.cpp:
2559
2560 2016-01-29  Andreas Kling  <akling@apple.com>
2561
2562         Shrink CodeBlock!
2563         <https://webkit.org/b/153640>
2564
2565         Reviewed by Saam Barati.
2566
2567         Shrink CodeBlock by 112 bytes (from 640 to 528) by employing
2568         these sophisticated tricks:
2569
2570             - Remove members that are not used by anyone.
2571             - Don't cache both VM* and Heap* in members.
2572             - Reorder members to minimize struct padding.
2573             - Use RefCountedArray instead of Vector for arrays that never resize.
2574             - Put a not-always-present HashMap in a std::unique_ptr.
2575
2576         This increases CodeBlock space efficiency by 20%, as we can now
2577         fit 30 of them in a MarkedBlock, up from 25.)
2578
2579         * bytecode/CodeBlock.cpp:
2580         (JSC::CodeBlock::CodeBlock):
2581         (JSC::CodeBlock::finishCreation):
2582         (JSC::CodeBlock::setNumParameters):
2583         (JSC::CodeBlock::jettison):
2584         (JSC::CodeBlock::noticeIncomingCall):
2585         (JSC::CodeBlock::resultProfileForBytecodeOffset):
2586         * bytecode/CodeBlock.h:
2587         (JSC::CodeBlock::setJITCode):
2588         (JSC::CodeBlock::capabilityLevelState):
2589         (JSC::CodeBlock::codeType):
2590         (JSC::CodeBlock::ensureResultProfile):
2591         (JSC::CodeBlock::heap):
2592
2593 2016-01-29  Saam barati  <sbarati@apple.com>
2594
2595         Exits from exceptions shouldn't jettison code
2596         https://bugs.webkit.org/show_bug.cgi?id=153564
2597
2598         Reviewed by Geoffrey Garen.
2599
2600         We create two new exit kinds for exception-handling
2601         OSRExits:
2602         - ExceptionCheck: an exception check after a C call.
2603         - GenericUnwind: an OSR exit executes because it's jumped to from genericUnwind machinery.
2604
2605         Having these two new exit kinds allows us to remove fields from
2606         various OSRExit variants that store booleans indicating
2607         if the exit is an exception handler, and if so, what kind
2608         of exception handler. Most of this patch is just removing
2609         those old fields and adding new equivalent functions.
2610
2611         This patch also implements the policy that we should never consider jettisoning
2612         code from exits that happen from an exception check to an op_catch (it might be worth
2613         considering a similar policy for 'throw'). We're choosing this policy because
2614         it will almost never be more expensive, in total, to execute the OSR exit than
2615         to execute the baseline variant of the code. When an exception is thrown, we do
2616         really expensive work, like call through to genericUnwind, and also create an error
2617         object with a stack trace. The cost of OSR exiting here is small in comparison to
2618         those other operations. And penalizing a CodeBlock for OSR exiting from an exception
2619         is silly because the basis of our implementation of exception handling in the
2620         upper tiers is to OSR exit on a caught exception. So we used to penalize
2621         ourselves for having an implementation that is correct w.r.t our design goals.
2622
2623         I've verified this hypothesis with on v8-raytrace by adding a new 
2624         benchmark that throws with very high frequency. Implementing
2625         this policy on that benchmark results in about a 4-5% speed up.
2626
2627         * bytecode/ExitKind.cpp:
2628         (JSC::exitKindToString):
2629         (JSC::exitKindMayJettison):
2630         (JSC::exitKindIsCountable): Deleted.
2631         * bytecode/ExitKind.h:
2632         * dfg/DFGJITCode.cpp:
2633         (JSC::DFG::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
2634         * dfg/DFGJITCompiler.cpp:
2635         (JSC::DFG::JITCompiler::noticeOSREntry):
2636         (JSC::DFG::JITCompiler::appendExceptionHandlingOSRExit):
2637         (JSC::DFG::JITCompiler::exceptionCheck):
2638         (JSC::DFG::JITCompiler::recordCallSiteAndGenerateExceptionHandlingOSRExitIfNeeded):
2639         * dfg/DFGJITCompiler.h:
2640         * dfg/DFGOSRExit.cpp:
2641         (JSC::DFG::OSRExit::OSRExit):
2642         * dfg/DFGOSRExit.h:
2643         (JSC::DFG::OSRExit::considerAddingAsFrequentExitSite):
2644         * dfg/DFGOSRExitBase.h:
2645         (JSC::DFG::OSRExitBase::OSRExitBase):
2646         (JSC::DFG::OSRExitBase::isExceptionHandler):
2647         (JSC::DFG::OSRExitBase::isGenericUnwindHandler):
2648         (JSC::DFG::OSRExitBase::considerAddingAsFrequentExitSite):
2649         * dfg/DFGOSRExitCompiler.cpp:
2650         * dfg/DFGOSRExitCompiler32_64.cpp:
2651         (JSC::DFG::OSRExitCompiler::compileExit):
2652         * dfg/DFGOSRExitCompiler64.cpp:
2653         (JSC::DFG::OSRExitCompiler::compileExit):
2654         * dfg/DFGOSRExitCompilerCommon.cpp:
2655         (JSC::DFG::handleExitCounts):
2656         (JSC::DFG::osrWriteBarrier):
2657         (JSC::DFG::adjustAndJumpToTarget):
2658         * dfg/DFGOSRExitCompilerCommon.h:
2659         (JSC::DFG::adjustFrameAndStackInOSRExitCompilerThunk):
2660         * ftl/FTLCompile.cpp:
2661         (JSC::FTL::mmAllocateDataSection):
2662         * ftl/FTLExitThunkGenerator.cpp:
2663         (JSC::FTL::ExitThunkGenerator::emitThunk):
2664         * ftl/FTLJITCode.cpp:
2665         (JSC::FTL::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
2666         * ftl/FTLLowerDFGToLLVM.cpp:
2667         (JSC::FTL::DFG::LowerDFGToLLVM::callCheck):
2668         (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExitArgumentsForPatchpointIfWillCatchException):
2669         (JSC::FTL::DFG::LowerDFGToLLVM::appendOSRExit):
2670         (JSC::FTL::DFG::LowerDFGToLLVM::blessSpeculation):
2671         * ftl/FTLOSRExit.cpp:
2672         (JSC::FTL::OSRExitDescriptor::emitOSRExit):
2673         (JSC::FTL::OSRExitDescriptor::emitOSRExitLater):
2674         (JSC::FTL::OSRExitDescriptor::prepareOSRExitHandle):
2675         (JSC::FTL::OSRExit::OSRExit):
2676         (JSC::FTL::OSRExit::spillRegistersToSpillSlot):
2677         (JSC::FTL::OSRExit::recoverRegistersFromSpillSlot):
2678         (JSC::FTL::OSRExit::willArriveAtExitFromIndirectExceptionCheck):
2679         (JSC::FTL::OSRExit::willArriveAtOSRExitFromCallOperation):
2680         (JSC::FTL::exceptionTypeWillArriveAtOSRExitFromGenericUnwind): Deleted.
2681         (JSC::FTL::OSRExit::willArriveAtOSRExitFromGenericUnwind): Deleted.
2682         * ftl/FTLOSRExit.h:
2683         * ftl/FTLOSRExitCompiler.cpp:
2684         (JSC::FTL::compileStub):
2685         (JSC::FTL::compileFTLOSRExit):
2686         * ftl/FTLPatchpointExceptionHandle.cpp:
2687         (JSC::FTL::PatchpointExceptionHandle::scheduleExitCreation):
2688         (JSC::FTL::PatchpointExceptionHandle::scheduleExitCreationForUnwind):
2689         (JSC::FTL::PatchpointExceptionHandle::PatchpointExceptionHandle):
2690         (JSC::FTL::PatchpointExceptionHandle::createHandle):
2691         * ftl/FTLPatchpointExceptionHandle.h:
2692
2693 2016-01-28  Yusuke Suzuki  <utatane.tea@gmail.com>
2694
2695         [B3] REGRESSION(r195395): testComplex(64, 128) asserts on Linux with GCC
2696         https://bugs.webkit.org/show_bug.cgi?id=153422
2697
2698         Reviewed by Filip Pizlo.
2699
2700         Previously proc.values() returns ValuesCollection (Not reference!).
2701         values.values takes const ValueCollection&.
2702         And later it produces IndexSet<Value>::Iterable<Procedure::ValuesCollection>,
2703         it holds const ValueCollection& as its member.
2704         But IndexSet<Value>::Iterable<Procedure::ValuesCollection> is just an instance.
2705         So after creating this, the lifetime of the ValueCollection const reference finished.
2706
2707         To fix that, we hold ValuesCollection as a member of Procedure.
2708         And change the signature to const ValuesCollection& Procedure::values().
2709
2710         * b3/B3Procedure.cpp:
2711         (JSC::B3::Procedure::Procedure):
2712         * b3/B3Procedure.h:
2713         (JSC::B3::Procedure::values):
2714
2715 2016-01-28  Joseph Pecoraro  <pecoraro@apple.com>
2716
2717         Web Inspector: InspectorTimelineAgent doesn't need to recompile functions because it now uses the sampling profiler
2718         https://bugs.webkit.org/show_bug.cgi?id=153500
2719         <rdar://problem/24352458>
2720
2721         Reviewed by Timothy Hatcher.
2722
2723         Be more explicit about enabling legacy profiling.
2724
2725         * jsc.cpp:
2726         * runtime/Executable.cpp:
2727         (JSC::ScriptExecutable::newCodeBlockFor):
2728         * runtime/JSGlobalObject.cpp:
2729         (JSC::JSGlobalObject::hasLegacyProfiler):
2730         (JSC::JSGlobalObject::createProgramCodeBlock):
2731         (JSC::JSGlobalObject::createEvalCodeBlock):
2732         (JSC::JSGlobalObject::createModuleProgramCodeBlock):
2733         (JSC::JSGlobalObject::hasProfiler): Deleted.
2734         * runtime/JSGlobalObject.h:
2735         (JSC::JSGlobalObject::supportsLegacyProfiling):
2736         (JSC::JSGlobalObject::supportsProfiling): Deleted.
2737
2738 2016-01-28  Yusuke Suzuki  <utatane.tea@gmail.com>
2739
2740         Fix the B3 build with GCC 4.9.3
2741         https://bugs.webkit.org/show_bug.cgi?id=151624
2742
2743         Reviewed by Filip Pizlo.
2744
2745         Due to GCC 4.9's compiler issue[1], method calls inside (2 or so) nested lambdas need to use `this` to avoid internal compiler errors.
2746         [1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62272
2747
2748         * b3/air/AirIteratedRegisterCoalescing.cpp:
2749
2750 2016-01-28  Filip Pizlo  <fpizlo@apple.com>
2751
2752         LowerToAir::preferRightForResult() should resolve use count ties by selecting the child that is closest in an idom walk
2753         https://bugs.webkit.org/show_bug.cgi?id=153583
2754
2755         Reviewed by Benjamin Poulain.
2756
2757         This undoes the AsmBench/n-body regression in r195654 while preserving that revision's
2758         Kraken progression.
2759
2760         * b3/B3LowerToAir.cpp:
2761         (JSC::B3::Air::LowerToAir::LowerToAir):
2762         (JSC::B3::Air::LowerToAir::preferRightForResult):
2763
2764 2016-01-28  Benjamin Poulain  <bpoulain@apple.com>
2765
2766         [JSC] B3 Tail Call with Varargs do not restore callee saved registers
2767         https://bugs.webkit.org/show_bug.cgi?id=153579
2768
2769         Reviewed by Michael Saboff.
2770
2771         We were trashing the callee saved registers in Tail Calls.
2772
2773         I just copied the code from DFG to fix this :)
2774
2775         * ftl/FTLLowerDFGToLLVM.cpp:
2776         (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstructVarargs):
2777
2778 2016-01-27  Filip Pizlo  <fpizlo@apple.com>
2779
2780         B3 IntRange analysis should know more about shifting
2781         https://bugs.webkit.org/show_bug.cgi?id=153568
2782
2783         Reviewed by Benjamin Poulain.
2784
2785         This teaches the IntRange analysis that the result of a right shift is usually better than
2786         the worst-case mask based on the shift amount. In fact, you can reach useful conclusions
2787         from looking at the IntRange of the input. This helps because Octane/crypto does something
2788         like:
2789
2790             CheckMul((@x & $268435455) >> 14, @y >> 14, ...)
2791
2792         If you consider just the shifts, then this may overflow. But if you consider that @x is
2793         first masked, then the IntRange coming out of the first shift is tight enough to prove that
2794         the CheckMul cannot overflow.
2795
2796         * b3/B3ReduceStrength.cpp:
2797         * b3/testb3.cpp:
2798
2799 2016-01-27  Benjamin Poulain  <bpoulain@apple.com>
2800
2801         [JSC] adjustFrameAndStackInOSRExitCompilerThunk() can trash values in FTL
2802         https://bugs.webkit.org/show_bug.cgi?id=153536
2803
2804         Reviewed by Saam Barati.
2805
2806         Workaround to get B3 working on ARM.
2807
2808         * dfg/DFGOSRExitCompilerCommon.h:
2809         (JSC::DFG::adjustFrameAndStackInOSRExitCompilerThunk):
2810         The code was using the scratch registers in a few places.
2811
2812         I initially tried to make is not use scratch registers anywhere
2813         but that looked super fragile.
2814
2815         Instead, I just preserve the scratch registers. That's easy and
2816         it should be relatively cheap compared to everything done on OSR Exits.
2817
2818 2016-01-27  Konstantin Tokarev  <annulen@yandex.ru>
2819
2820         [mips] Use reinterpret_cast_ptr to suppress alignment warnings.
2821         https://bugs.webkit.org/show_bug.cgi?id=153424
2822
2823         Reviewed by Darin Adler.
2824
2825         * runtime/JSGenericTypedArrayView.h:
2826         (JSC::JSGenericTypedArrayView::sortFloat):
2827
2828 2016-01-27  Per Arne Vollan  <peavo@outlook.com>
2829
2830         [FTL][Win64] Compile fix.
2831         https://bugs.webkit.org/show_bug.cgi?id=153555
2832
2833         Reviewed by Alex Christensen.
2834
2835         MSVC does not accept preprocessor conditionals in macros.
2836
2837         * ftl/FTLOSRExitCompiler.cpp:
2838         (JSC::FTL::compileStub):
2839
2840 2016-01-27  Filip Pizlo  <fpizlo@apple.com>
2841
2842         Air::TmpWidth uses a stale pointer into its HashMap after it calls add()
2843         https://bugs.webkit.org/show_bug.cgi?id=153546
2844
2845         Reviewed by Saam Barati.
2846
2847         * b3/air/AirTmpWidth.cpp:
2848         (JSC::B3::Air::TmpWidth::recompute):
2849
2850 2016-01-27  Alexey Proskuryakov  <ap@apple.com>
2851
2852         Remove ENABLE_CURRENTSRC
2853         https://bugs.webkit.org/show_bug.cgi?id=153545
2854
2855         Reviewed by Simon Fraser.
2856
2857         * Configurations/FeatureDefines.xcconfig:
2858
2859 2016-01-26  Benjamin Poulain  <benjamin@webkit.org>
2860
2861         [JSC] When lowering B3 to Air, preferRightForResult() should prefer values from the same block
2862         https://bugs.webkit.org/show_bug.cgi?id=153477
2863
2864         Reviewed by Filip Pizlo.
2865
2866         In cases like this:
2867
2868         Block #0
2869             @1 = something
2870             @2 = Jump #1
2871         Block #1
2872             @3 = something else
2873             @4 = Add(@3, @1)
2874             ...
2875             @42 = Branch(@x, #1, #2)
2876
2877         B3LowerToAir would pick @1 for the argument copied
2878         for what goes into the UseDef side of Add.
2879
2880         This created a bunch of moves that could never be coalesced.
2881         In Kraken's imaging-desaturate, there were enough Moves to slow
2882         down the hot loop.
2883
2884         Ideally, we should not use UseCount for lowering. We should use
2885         the real liveness for preferRightForResult(), and a loop-weighted
2886         use-count for effective addresses. The problem is keeping the cost
2887         low for those simple helpers.
2888
2889         In this patch, I went with a simple heuristic: prioritize the value
2890         defined in the same block for UseDef.
2891
2892         There is one other way that would be cheap but a bit invasive:
2893         -Get rid of UseDef.
2894         -Make every ops, 3 operands.
2895         -Tell the register allocator to attempt aliasing of the 2 uses
2896          with the def.
2897         -If the allocator fails, just add a move as needed.
2898
2899         For now, the simple heuristic seems okay for the cases have.
2900
2901         * b3/B3LowerToAir.cpp:
2902         (JSC::B3::Air::LowerToAir::preferRightForResult):
2903
2904 2016-01-26  Filip Pizlo  <fpizlo@apple.com>
2905
2906         Tail duplication should break critical edges first
2907         https://bugs.webkit.org/show_bug.cgi?id=153530
2908
2909         Reviewed by Benjamin Poulain.
2910
2911         This speeds up Octane/boyer.
2912
2913         * b3/B3DuplicateTails.cpp:
2914
2915 2016-01-26  Joseph Pecoraro  <pecoraro@apple.com>
2916
2917         Generalize ResourceUsageData gathering to be used outside of ResourceUsageOverlay
2918         https://bugs.webkit.org/show_bug.cgi?id=153509
2919         <rdar://problem/24354291>
2920
2921         Reviewed by Andreas Kling.
2922
2923         * heap/Heap.h:
2924         * heap/HeapInlines.h:
2925         (JSC::Heap::didAllocateBlock):
2926         (JSC::Heap::didFreeBlock):
2927         Rename the ENABLE flag.
2928
2929 2016-01-26  Csaba Osztrogonác  <ossy@webkit.org>
2930
2931         [B3] Fix control reaches end of non-void function GCC warning after r195139
2932         https://bugs.webkit.org/show_bug.cgi?id=153426
2933
2934         Reviewed by Michael Catanzaro.
2935
2936         * b3/air/AirArg.h:
2937         (JSC::B3::Air::Arg::cooled):
2938
2939 2016-01-26  Saam barati  <sbarati@apple.com>
2940
2941         testb3 and testAir should be compiled under -O0
2942         https://bugs.webkit.org/show_bug.cgi?id=153520
2943
2944         Reviewed by Benjamin Poulain.
2945
2946         * JavaScriptCore.xcodeproj/project.pbxproj:
2947
2948 2016-01-26  Filip Pizlo  <fpizlo@apple.com>
2949
2950         B3's integer range analysis should know that Mul'ing two sufficiently small numbers will yield a number that still has a meaningful range
2951         https://bugs.webkit.org/show_bug.cgi?id=153518
2952
2953         Reviewed by Benjamin Poulain.
2954
2955         Octane/encrypt had an addition overflow check that can be proved away by being sufficiently
2956         sneaky about the analysis of adds, multiplies, and shifts.
2957
2958         I almost added these optimizations to the DFG integer range optimization phase. That phase is
2959         very complicated. B3's integer range analysis is trivial. So I added it to B3. Eventually
2960         we'll want this same machinery in the DFG also.
2961
2962         8% speed-up on Octane/encrypt.
2963
2964         * b3/B3ReduceStrength.cpp:
2965         * b3/B3Value.cpp:
2966         (JSC::B3::Value::dump): Dumping a constant value's name now dumps its value. This makes a huge difference for reading IR.
2967         (JSC::B3::Value::cloneImpl):
2968         (JSC::B3::Value::deepDump):
2969
2970 2016-01-26  Filip Pizlo  <fpizlo@apple.com>
2971
2972         It should be possible to disable FTL for a range like we disable DFG for a range
2973         https://bugs.webkit.org/show_bug.cgi?id=153511
2974
2975         Reviewed by Geoffrey Garen.
2976
2977         * dfg/DFGTierUpCheckInjectionPhase.cpp:
2978         (JSC::DFG::TierUpCheckInjectionPhase::run):
2979         * runtime/Options.h:
2980
2981 2016-01-26  Filip Pizlo  <fpizlo@apple.com>
2982
2983         Shifts by an amount computed using BitAnd with a mask that subsumes the shift's own mask should be rewired around the BitAnd
2984         https://bugs.webkit.org/show_bug.cgi?id=153505
2985
2986         Reviewed by Saam Barati.
2987
2988         Turn this: Shl(@x, BitAnd(@y, 63))
2989         Into this: Shl(@x, @y)
2990
2991         It matters for Octane/crypto.
2992
2993         We should also stop FTL from generating such code, but even if we did that, we'd still want
2994         this optimization in case user code did the BitAnd.
2995
2996         Also we can't stop the FTL from generating such code yet, because when targetting LLVM, you
2997         must mask your shifts this way.
2998
2999         * b3/B3ReduceStrength.cpp:
3000
3001 2016-01-26  Filip Pizlo  <fpizlo@apple.com>
3002
3003         The thing that B3 uses to describe a stack slot should not be a Value
3004         https://bugs.webkit.org/show_bug.cgi?id=153491
3005         rdar://problem/24349446
3006
3007         Reviewed by Geoffrey Garen and Saam Barati.
3008
3009         Prior to this change, B3 represented stack slots by having a StackSlotValue that carried
3010         two meanings:
3011
3012         - It represented a stack slot.
3013
3014         - It was a kind of Value for getting the base of the stack slot.
3015
3016         This seems like a good idea until you consider the following issues.
3017
3018         1) A Value can be killed if it is on an unreachable path, or if it has no effects and
3019            nobody refers to it. But the FTL uses StackSlotValue to allocate space on the stack.
3020            When it does this, it doesn't want it to be killed. It will dereference the object, so
3021            killing it is a bug.
3022
3023         2) A premise of B3 is that it should be always legal to perform the following
3024            transformation on a value:
3025
3026            value->replaceWithIdentity(insertionSet.insertValue(index, proc.clone(value)));
3027
3028            This inserts a new value just before the old one. The new value is a clone of the old
3029            one. Then the old one is essentially deleted (anything that becomes an identity dies
3030            shortly thereafter). Problem (1) prevents this from being legal, which breaks a major
3031            premise of B3 IR.
3032
3033         3) A premise of B3 is that it should be always legal to perform the following
3034            transformation on a value:
3035
3036            Before:
3037                    @42 = Thing(...)
3038
3039            After:
3040                    Branch(@doesntMatter, #yes, #no)
3041                BB#yes:
3042                    @42_one = Thing(...)
3043                    Upsilon(@42_one, ^42)
3044                    Jump(#done)
3045                BB#no:
3046                    @42_two = Thing(...)
3047                    Upsilon(@42_two, ^42)
3048                    Jump(#done)
3049                BB#done:
3050                    @42 = Phi()
3051
3052            But prior to this change, such a transformation makes absolutely no sense for
3053            StackSlot. It will "work" in the sense that the compiler will proceed undaunted, but
3054            it will disable SSA fix-up for the cloned stack slot and we will end up allocating two
3055            stack slots instead of one, and then we will assume that they both escape, which will
3056            disable efficient stack allocation. Note that the moral equivalent of this
3057            transformation could already happen due to tail duplication, and the only reason why
3058            it's not a bug right now is that we happen to hoist stack slots to the root block. But
3059            the whole point of our stack slots was supposed to be that they do not have to be
3060            hoisted.
3061
3062         This change fixes this issue by splitting StackSlotValue into two things: SlotBaseValue,
3063         which is a pure operation for getting the base address of a StackSlot, and StackSlot,
3064         which is a representation of the actual stack slot. StackSlot cannot get duplicated and
3065         can only be killed if it's anonymous. SlotBaseValue can be killed, moved, cloned,
3066         hoisted, etc. Since it has no effects and it has a ValueKey, it's one of the most
3067         permissive Values in the IR, just as one would hope (after all, there is actually zero
3068         code that needs to execute to evaluate SlotBaseValue).
3069
3070         This fixes a crash that we saw with GuardMalloc and ASan. It also makes the IR a lot more
3071         easy to reason about.
3072
3073         * CMakeLists.txt:
3074         * JavaScriptCore.xcodeproj/project.pbxproj:
3075         * b3/B3EliminateCommonSubexpressions.cpp:
3076         * b3/B3FixSSA.cpp:
3077         (JSC::B3::demoteValues):
3078         (JSC::B3::fixSSA):
3079         * b3/B3LowerToAir.cpp:
3080         (JSC::B3::Air::LowerToAir::run):
3081         (JSC::B3::Air::LowerToAir::effectiveAddr):
3082         (JSC::B3::Air::LowerToAir::lower):
3083         * b3/B3Opcode.cpp:
3084         (WTF::printInternal):
3085         * b3/B3Opcode.h:
3086         * b3/B3Procedure.cpp:
3087         (JSC::B3::Procedure::setBlockOrderImpl):
3088         (JSC::B3::Procedure::addStackSlot):
3089         (JSC::B3::Procedure::addAnonymousStackSlot):
3090         (JSC::B3::Procedure::clone):
3091         (JSC::B3::Procedure::dump):
3092         (JSC::B3::Procedure::blocksInPostOrder):
3093         (JSC::B3::Procedure::deleteStackSlot):
3094         (JSC::B3::Procedure::deleteValue):
3095         (JSC::B3::Procedure::calleeSaveRegisters):
3096         (JSC::B3::Procedure::addStackSlotIndex):
3097         (JSC::B3::Procedure::addValueIndex):
3098         * b3/B3Procedure.h:
3099         (JSC::B3::Procedure::setBlockOrder):
3100         (JSC::B3::Procedure::StackSlotsCollection::StackSlotsCollection):
3101         (JSC::B3::Procedure::StackSlotsCollection::size):
3102         (JSC::B3::Procedure::StackSlotsCollection::at):
3103         (JSC::B3::Procedure::StackSlotsCollection::operator[]):
3104         (JSC::B3::Procedure::StackSlotsCollection::iterator::iterator):
3105         (JSC::B3::Procedure::StackSlotsCollection::iterator::operator*):
3106         (JSC::B3::Procedure::StackSlotsCollection::iterator::operator++):
3107         (JSC::B3::Procedure::StackSlotsCollection::iterator::operator==):
3108         (JSC::B3::Procedure::StackSlotsCollection::iterator::operator!=):
3109         (JSC::B3::Procedure::StackSlotsCollection::iterator::findNext):
3110         (JSC::B3::Procedure::StackSlotsCollection::begin):
3111         (JSC::B3::Procedure::StackSlotsCollection::end):
3112         (JSC::B3::Procedure::stackSlots):
3113         (JSC::B3::Procedure::ValuesCollection::ValuesCollection):
3114         * b3/B3ReduceStrength.cpp:
3115         * b3/B3SlotBaseValue.cpp: Copied from Source/JavaScriptCore/b3/B3StackSlotValue.cpp.
3116         (JSC::B3::SlotBaseValue::~SlotBaseValue):
3117         (JSC::B3::SlotBaseValue::dumpMeta):
3118         (JSC::B3::SlotBaseValue::cloneImpl):
3119         (JSC::B3::StackSlotValue::~StackSlotValue): Deleted.
3120         (JSC::B3::StackSlotValue::dumpMeta): Deleted.
3121         (JSC::B3::StackSlotValue::cloneImpl): Deleted.
3122         * b3/B3SlotBaseValue.h: Copied from Source/JavaScriptCore/b3/B3StackSlotValue.h.
3123         * b3/B3StackSlot.cpp: Added.
3124         (JSC::B3::StackSlot::~StackSlot):
3125         (JSC::B3::StackSlot::dump):
3126         (JSC::B3::StackSlot::deepDump):
3127         (JSC::B3::StackSlot::StackSlot):
3128         * b3/B3StackSlot.h: Added.
3129         (JSC::B3::StackSlot::byteSize):
3130         (JSC::B3::StackSlot::kind):
3131         (JSC::B3::StackSlot::isLocked):
3132         (JSC::B3::StackSlot::index):
3133         (JSC::B3::StackSlot::offsetFromFP):
3134         (JSC::B3::StackSlot::setOffsetFromFP):
3135         (JSC::B3::DeepStackSlotDump::DeepStackSlotDump):
3136         (JSC::B3::DeepStackSlotDump::dump):
3137         (JSC::B3::deepDump):
3138         * b3/B3StackSlotValue.cpp: Removed.
3139         * b3/B3StackSlotValue.h: Removed.
3140         * b3/B3Validate.cpp:
3141         * b3/B3Value.cpp:
3142         (JSC::B3::Value::effects):
3143         (JSC::B3::Value::key):
3144         (JSC::B3::Value::checkOpcode):
3145         * b3/B3ValueKey.cpp:
3146         (JSC::B3::ValueKey::materialize):
3147         * b3/air/AirCode.cpp:
3148         (JSC::B3::Air::Code::addBlock):
3149         (JSC::B3::Air::Code::addStackSlot):
3150         (JSC::B3::Air::Code::addSpecial):
3151         * b3/air/AirCode.h:
3152         * b3/air/AirStackSlot.cpp:
3153         (JSC::B3::Air::StackSlot::setOffsetFromFP):
3154         (JSC::B3::Air::StackSlot::dump):
3155         (JSC::B3::Air::StackSlot::deepDump):
3156         (JSC::B3::Air::StackSlot::StackSlot):
3157         * b3/air/AirStackSlot.h:
3158         (JSC::B3::Air::StackSlot::alignment):
3159         (JSC::B3::Air::StackSlot::b3Slot):
3160         (JSC::B3::Air::StackSlot::offsetFromFP):
3161         (WTF::printInternal):
3162         (JSC::B3::Air::StackSlot::value): Deleted.
3163         * b3/testb3.cpp:
3164         (JSC::B3::testStackSlot):
3165         (JSC::B3::testStoreLoadStackSlot):
3166         * ftl/FTLB3Compile.cpp:
3167         * ftl/FTLB3Output.cpp:
3168         (JSC::FTL::Output::appendTo):
3169         (JSC::FTL::Output::lockedStackSlot):
3170         (JSC::FTL::Output::neg):
3171         * ftl/FTLB3Output.h:
3172         (JSC::FTL::Output::framePointer):
3173         (JSC::FTL::Output::constBool):
3174         (JSC::FTL::Output::constInt32):
3175         * ftl/FTLLowerDFGToLLVM.cpp:
3176         (JSC::FTL::DFG::LowerDFGToLLVM::lower):
3177         * ftl/FTLState.h:
3178
3179 2016-01-26  Benjamin Poulain  <benjamin@webkit.org>
3180
3181         Remove a useless #include
3182         https://bugs.webkit.org/show_bug.cgi?id=153474
3183
3184         Reviewed by Alexey Proskuryakov.
3185
3186         * b3/B3ReduceStrength.cpp:
3187
3188 2016-01-26  Alex Christensen  <achristensen@webkit.org>
3189
3190         [Win] Fix clean build after r195545.
3191         ​https://bugs.webkit.org/show_bug.cgi?id=153434
3192
3193         * CMakeLists.txt:
3194         * PlatformWin.cmake:
3195         Derived sources need to be copied after the build, but everything else should be copied before.
3196         This should fix ews issues like the one seen in bug 153473.
3197
3198 2016-01-25  Filip Pizlo  <fpizlo@apple.com>
3199
3200         FTLB3Output should maintain good block order like the LLVM one does
3201         https://bugs.webkit.org/show_bug.cgi?id=152222
3202
3203         Reviewed by Geoffrey Garen.
3204
3205         This fixes FTLB3Output to emit an ordered B3 IR. This makes inspecting IR *a lot* easier.
3206         It will also be a performance win whenever we use range-based data structures for
3207         liveness.
3208
3209         Also two small other changes:
3210         - Added some more dumping in integer range optimization phase.
3211         - Refined the disassembler's printing of instruction width suffixes so that "jzl" is not
3212           a thing. It was using "l" as the suffix because jumps take a 32-bit immediate.
3213
3214         * b3/B3Procedure.cpp:
3215         (JSC::B3::Procedure::addBlock):
3216         (JSC::B3::Procedure::setBlockOrderImpl):
3217         (JSC::B3::Procedure::clone):
3218         * b3/B3Procedure.h:
3219         (JSC::B3::Procedure::frontendData):
3220         (JSC::B3::Procedure::setBlockOrder):
3221         * dfg/DFGIntegerRangeOptimizationPhase.cpp:
3222         * disassembler/udis86/udis86_syn-att.c:
3223         (ud_translate_att):
3224         * ftl/FTLB3Output.cpp:
3225         (JSC::FTL::Output::initialize):
3226         (JSC::FTL::Output::newBlock):
3227         (JSC::FTL::Output::applyBlockOrder):
3228         (JSC::FTL::Output::appendTo):
3229         * ftl/FTLB3Output.h:
3230         (JSC::FTL::Output::setFrequency):
3231         (JSC::FTL::Output::insertNewBlocksBefore):
3232         (JSC::FTL::Output::callWithoutSideEffects):
3233         (JSC::FTL::Output::newBlock): Deleted.
3234         * ftl/FTLLowerDFGToLLVM.cpp:
3235         (JSC::FTL::DFG::LowerDFGToLLVM::lower):
3236
3237 2016-01-25  Skachkov Oleksandr  <gskachkov@gmail.com>
3238
3239         [ES6] Arrow function syntax. Arrow function specific features. Lexical bind "arguments"
3240         https://bugs.webkit.org/show_bug.cgi?id=145132
3241
3242         Reviewed by Saam Barati.
3243         
3244         Added support of ES6 arrow function specific feature, lexical bind of arguments. 
3245         http://www.ecma-international.org/ecma-262/6.0/#sec-arrow-function-definitions-runtime-semantics-evaluation
3246         'arguments' variable in arrow function must resolve to a binding in a lexically enclosing environment.
3247         In srict mode it points to arguments object, and in non-stric mode it points to arguments object or varible 
3248         with name 'arguments' if it was declared. 
3249
3250         * bytecompiler/BytecodeGenerator.cpp:
3251         (JSC::BytecodeGenerator::BytecodeGenerator):
3252         * parser/Parser.h:
3253         (JSC::Scope::Scope):
3254         (JSC::Scope::setSourceParseMode):
3255         (JSC::Scope::isArrowFunction):
3256         (JSC::Scope::collectFreeVariables):
3257         (JSC::Scope::setIsArrowFunction):
3258         * tests/es6.yaml:
3259         * tests/stress/arrowfunction-lexical-bind-arguments-non-strict-1.js: Added.
3260         * tests/stress/arrowfunction-lexical-bind-arguments-non-strict-2.js: Added.
3261         * tests/stress/arrowfunction-lexical-bind-arguments-strict.js: Added.
3262
3263 2016-01-25  Benjamin Poulain  <bpoulain@apple.com>
3264
3265         [JSC] We should never use x18 on iOS ARM64
3266         https://bugs.webkit.org/show_bug.cgi?id=153461
3267
3268         Reviewed by Filip Pizlo.
3269
3270         The register x18 is reserved in the iOS variant of the ARM64 ABI.
3271
3272         The weird thing is: if you use it, its value will change completely
3273         randomly. It looks like it is changed by the system on interrupts.
3274
3275         This patch adds x18 to the reserved register and add assertions
3276         to the assembler to prevent similar problems in the future.
3277
3278         * assembler/ARM64Assembler.h:
3279         (JSC::ARM64Assembler::xOrSp):
3280         (JSC::ARM64Assembler::xOrZr):
3281         * assembler/AbstractMacroAssembler.h:
3282         (JSC::isIOS): Deleted.
3283         * assembler/AssemblerCommon.h:
3284         (JSC::isIOS):
3285         * jit/RegisterSet.cpp:
3286         (JSC::RegisterSet::reservedHardwareRegisters):
3287
3288 2016-01-25  Commit Queue  <commit-queue@webkit.org>
3289
3290         Unreviewed, rolling out r195550.
3291         https://bugs.webkit.org/show_bug.cgi?id=153471
3292
3293         broke animometer bot (and now we have crash logs!) (Requested
3294         by kling on #webkit).
3295
3296         Reverted changeset:
3297
3298         "Restore CodeBlock jettison code Geoff accidentally removed"
3299         https://bugs.webkit.org/show_bug.cgi?id=151241
3300         http://trac.webkit.org/changeset/195550
3301
3302 2016-01-25  Andreas Kling  <akling@apple.com>
3303
3304         MarkedSpace should have more precise allocators.
3305         <https://webkit.org/b/153448>
3306         <rdar://problem/23897477>
3307
3308         Reviewed by Geoffrey Garen.
3309
3310         The four classes responsible for the bulk of MarkedBlock allocations today are:
3311
3312             - FunctionCodeBlock (640 bytes)
3313             - UnlinkedFunctionCodeBlock (304 bytes)
3314             - FunctionExecutable (168 bytes)
3315             - UnlinkedFunctionExecutable (144 bytes)
3316
3317         Due to the size class distribution in MarkedSpace, we've been wasting quite a lot
3318         of heap space on these objects. Our "precise" allocators allowed allocation sizes
3319         in 16-byte increments up to 128 bytes, but after that point, we'd only allocate
3320         in 256-byte size increments.
3321
3322         Thus each instance of those classes would waste space as follows:
3323
3324             - FunctionCodeBlock (768-byte cell, 128 bytes wasted)
3325             - UnlinkedFunctionCodeBlock (512-byte cell, 208 bytes wasted)
3326             - FunctionExecutable(256-byte cell, 88 bytes wasted)
3327             - UnlinkedFunctionExecutable(256-byte cell, 112 bytes wasted)
3328
3329         This patch raises the limit for precise allocations from 128 to 768, allowing us
3330         to allocate these objects with far better space efficiency.
3331
3332         The cost of this is 7kB worth of MarkedAllocators and 70 (~2x) more allocators to
3333         iterate whenever we iterate all the allocators.
3334
3335         * heap/MarkedSpace.h:
3336         * heap/MarkedSpace.cpp:
3337         (JSC::MarkedSpace::MarkedSpace):
3338         (JSC::MarkedSpace::resetAllocators):
3339         (JSC::MarkedSpace::forEachAllocator):
3340         (JSC::MarkedSpace::isPagedOut):
3341
3342 2016-01-25  Filip Pizlo  <fpizlo@apple.com>
3343
3344         Fix the comment about FTL_USES_B3.
3345
3346         * dfg/DFGCommon.h:
3347
3348 2016-01-25  Filip Pizlo  <fpizlo@apple.com>
3349
3350         Switch FTL to B3 on X86_64/Mac
3351         https://bugs.webkit.org/show_bug.cgi?id=153445
3352
3353         Rubber stamped by Geoffrey Garen.
3354
3355         This finally switches from LLVM to B3 in the FTL on X86_64 on the Mac. We recommend that other
3356         X86_64 platforms make the switch as well. We will be focusing our performance work on B3 rather
3357         than LLVM in the future. ARM64 support is also coming soon, so we will be able to remove FTL
3358         LLVM code once that lands.
3359
3360         Right now this mostly appears as perf-neutral on the major tests