1 2016-02-11 Filip Pizlo <fpizlo@apple.com>
3 Cannot call initializeIndex() if we didn't create the array using tryCreateUninitialized()
4 https://bugs.webkit.org/show_bug.cgi?id=154126
6 Reviewed by Saam Barati.
8 * runtime/ArrayPrototype.cpp:
9 (JSC::arrayProtoFuncSplice):
11 2016-02-11 Sukolsak Sakshuwong <sukolsak@gmail.com>
13 [INTL] Implement Intl.NumberFormat.prototype.resolvedOptions ()
14 https://bugs.webkit.org/show_bug.cgi?id=147602
16 Reviewed by Darin Adler.
18 This patch implements Intl.NumberFormat.prototype.resolvedOptions() according
19 to the ECMAScript 2015 Internationalization API spec (ECMA-402 2nd edition.)
21 * runtime/IntlDateTimeFormat.cpp:
23 * runtime/IntlNumberFormat.cpp:
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:
45 2016-02-11 Filip Pizlo <fpizlo@apple.com>
47 MacroAssemblerX86 should be happy with shift(cx, cx)
48 https://bugs.webkit.org/show_bug.cgi?id=154124
50 Reviewed by Saam Barati.
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.
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):
66 (JSC::B3::testLShiftSelf32):
67 (JSC::B3::testRShiftSelf32):
68 (JSC::B3::testURShiftSelf32):
69 (JSC::B3::testLShiftSelf64):
70 (JSC::B3::testRShiftSelf64):
71 (JSC::B3::testURShiftSelf64):
74 2016-02-11 Saam barati <sbarati@apple.com>
76 The sampling profiler's stack walker methods should be marked with SUPPRESS_ASAN
77 https://bugs.webkit.org/show_bug.cgi?id=154123
81 The entire premise of the sampling profiler is to load from
82 another thread's memory. We should SUPPRESS_ASAN on the
85 * runtime/SamplingProfiler.cpp:
86 (JSC::FrameWalker::FrameWalker):
87 (JSC::FrameWalker::walk):
88 (JSC::FrameWalker::advanceToParentFrame):
89 (JSC::FrameWalker::isAtTop):
90 (JSC::FrameWalker::resetAtMachineFrame):
92 2016-02-11 Csaba Osztrogonác <ossy@webkit.org>
94 Unreviewed typo fix after r190063.
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.
102 2016-02-11 Csaba Osztrogonác <ossy@webkit.org>
104 Unreviewed typo fix after r190063.
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.
112 2016-02-10 Keith Miller <keith_miller@apple.com>
114 Symbol.species accessors on builtin constructors should be configurable
115 https://bugs.webkit.org/show_bug.cgi?id=154097
117 Reviewed by Benjamin Poulain.
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.
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.
148 * tests/stress/symbol-species.js:
149 (testSymbolSpeciesOnConstructor):
151 2016-02-10 Benjamin Poulain <benjamin@webkit.org>
153 [JSC] The destination of Sqrt should be Def, not UseDef
154 https://bugs.webkit.org/show_bug.cgi?id=154086
156 Reviewed by Geoffrey Garen.
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.
162 * b3/air/AirOpcode.opcodes:
164 2016-02-10 Chris Dumez <cdumez@apple.com>
166 [Web IDL] interface objects should be Function objects
167 https://bugs.webkit.org/show_bug.cgi?id=154038
168 <rdar://problem/24569358>
170 Reviewed by Geoffrey Garen.
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.
177 * runtime/FunctionPrototype.cpp:
178 (JSC::functionProtoFuncToString):
180 2016-02-10 Chris Dumez <cdumez@apple.com>
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>
186 Reviewed by Darin Adler.
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.
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.
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.
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
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
228 (JSC::JSObject::reifyAllStaticProperties):
229 Merge with reifyStaticFunctionsForDelete(). The only behavior change is the
230 flattening to an uncacheable dictionary, like reifyStaticFunctionsForDelete()
233 * runtime/JSObject.h:
235 2016-02-10 Commit Queue <commit-queue@webkit.org>
237 Unreviewed, rolling out r196251.
238 https://bugs.webkit.org/show_bug.cgi?id=154078
240 Large regression on Dromaeo needs explanation (Requested by
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
250 2016-02-10 Csaba Osztrogonác <ossy@webkit.org>
252 REGRESSION(r196331): It made ~180 JSC tests crash on ARMv7 Linux
253 https://bugs.webkit.org/show_bug.cgi?id=154064
255 Reviewed by Mark Lam.
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.
264 2016-02-09 Keith Miller <keith_miller@apple.com>
266 calling methods off super in a class constructor should check for TDZ
267 https://bugs.webkit.org/show_bug.cgi?id=154060
269 Reviewed by Ryosuke Niwa.
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
276 * bytecompiler/NodesCodegen.cpp:
277 (JSC::FunctionCallDotNode::emitBytecode):
278 * tests/stress/super-method-calls-check-tdz.js: Added.
283 2016-02-09 Filip Pizlo <fpizlo@apple.com>
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
289 Reviewed by Mark Lam.
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.
297 2016-02-07 Gavin Barraclough <barraclough@apple.com>
299 GetValueFunc/PutValueFunc should not take both slotBase and thisValue
300 https://bugs.webkit.org/show_bug.cgi?id=154009
302 Reviewed by Geoff Garen.
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.
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.
316 Instead, just pass one thisValue to the callback functions, consistent with CustomAccessor.
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):
338 (JSC::tryCacheGetByID):
339 (JSC::tryCachePutByID):
340 - Split the CustomGetter/Setter access types into Value/Accessor variants.
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.
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.
425 2016-02-09 Filip Pizlo <fpizlo@apple.com>
427 Spread expressions are not fair game for direct binding
428 https://bugs.webkit.org/show_bug.cgi?id=154042
429 rdar://problem/24291413
431 Reviewed by Saam Barati.
433 Prior to this change we crashed on this:
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
442 * bytecompiler/NodesCodegen.cpp:
443 (JSC::ArrayPatternNode::emitDirectBinding):
444 * tests/stress/spread-in-tail.js: Added.
448 2016-02-09 Commit Queue <commit-queue@webkit.org>
450 Unreviewed, rolling out r196286.
451 https://bugs.webkit.org/show_bug.cgi?id=154026
453 Looks like 5% iOS PLT regression (Requested by kling on
458 "[iOS] Throw away some unlinked code when navigating to a new
460 https://bugs.webkit.org/show_bug.cgi?id=154014
461 http://trac.webkit.org/changeset/196286
463 2016-02-08 Keith Miller <keith_miller@apple.com>
465 Error construction for inlined operations should not use the inliner's CodeBlock
466 https://bugs.webkit.org/show_bug.cgi?id=154021
468 Reviewed by Mark Lam.
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.
476 * runtime/ErrorInstance.cpp:
477 (JSC::appendSourceToError):
478 * tests/stress/inlined-error-gets-correct-codeblock-for-bytecodeoffset.js: Added.
484 2016-02-08 Saam Barati <sbarati@apple.com>
486 runtimeTypeForValue should protect against seeing TDZ value
487 https://bugs.webkit.org/show_bug.cgi?id=154023
488 rdar://problem/24291413
490 Reviewed by Michael Saboff.
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.
499 * runtime/RuntimeType.cpp:
500 (JSC::runtimeTypeForValue):
502 2016-02-08 Andreas Kling <akling@apple.com>
504 [iOS] Throw away some unlinked code when navigating to a new page.
505 <https://webkit.org/b/154014>
507 Reviewed by Gavin Barraclough.
510 (JSC::VM::deleteAllCodeExceptCaches):
511 (JSC::VM::deleteAllLinkedCode): Deleted.
514 2016-02-08 Filip Pizlo <fpizlo@apple.com>
516 B3::foldPathConstants() needs to execute its insertion set
517 https://bugs.webkit.org/show_bug.cgi?id=154020
519 Reviewed by Saam Barati.
521 * b3/B3FoldPathConstants.cpp:
523 (JSC::B3::testFoldPathEqual): Added this. It used to crash in validation.
526 2016-02-08 Yusuke Suzuki <utatane.tea@gmail.com>
528 [JSC] Introduce @isObject bytecode intrinsic and use it instead of JS implemented one
529 https://bugs.webkit.org/show_bug.cgi?id=153976
531 Reviewed by Darin Adler.
533 Use bytecode op_is_object directly.
535 * builtins/GlobalObject.js:
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.
544 2016-02-08 Yusuke Suzuki <utatane.tea@gmail.com>
546 {Map,Set}.prototype.forEach should be visible as own properties
547 https://bugs.webkit.org/show_bug.cgi?id=153974
549 Reviewed by Darin Adler.
551 Now, Map and Set uses builtin tables. We should inlude it in class info.
553 * runtime/MapPrototype.cpp:
554 * runtime/SetPrototype.cpp:
556 2016-02-08 Filip Pizlo <fpizlo@apple.com>
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
562 Reviewed by Mark Lam.
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):
571 2016-02-08 Filip Pizlo <fpizlo@apple.com>
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
577 Reviewed by Mark Lam.
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.
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.
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
591 * runtime/CodeCache.cpp:
592 (JSC::CodeCache::getGlobalCodeBlock):
594 2016-02-08 Skachkov Oleksandr <gskachkov@gmail.com>
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
599 Reviewed by Saam Barati.
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:
610 costructor() { eval("super()");}
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.
617 (JSC::Parser<LexerType>::parseFunctionInfo):
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:
628 2016-02-08 Filip Pizlo <fpizlo@apple.com>
630 Parser should detect error before calls to parseAssignmentExpression()
631 https://bugs.webkit.org/show_bug.cgi?id=153975
632 rdar://problem/24291231
634 Reviewed by Saam Barati.
636 Fixes a very hard-to-create situation that an internal test picked up.
639 (JSC::Parser<LexerType>::parseVariableDeclarationList):
640 (JSC::Parser<LexerType>::parseAssignmentExpression):
642 2016-02-08 Andreas Kling <akling@apple.com>
644 Visiting a WeakBlock should report bytes visited, since we reported them allocated.
645 <https://webkit.org/b/153978>
647 Reviewed by Darin Adler.
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.
653 This was causing us to underestimate heap size, which affects collection scheduling.
655 * heap/SlotVisitor.h:
656 (JSC::SlotVisitor::reportMemoryVisited):
657 * heap/WeakBlock.cpp:
658 (JSC::WeakBlock::visit):
660 2016-02-07 Saam barati <sbarati@apple.com>
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
665 Reviewed by Darin Adler.
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.
671 * runtime/JSBoundFunction.cpp:
672 (JSC::hasInstanceBoundFunction):
673 (JSC::JSBoundFunction::create):
674 (JSC::JSBoundFunction::toStringName):
676 2016-02-07 Filip Pizlo <fpizlo@apple.com>
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
682 Reviewed by Saam Barati.
684 This fixes a crash in an internal test case.
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.
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()
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.
705 2016-02-07 Dan Bernstein <mitz@apple.com>
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
710 Reviewed by Sam Weinig.
712 * inspector/remote/RemoteInspectorXPCConnection.mm:
714 2016-02-06 Filip Pizlo <fpizlo@apple.com>
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
720 Reviewed by Saam Barati.
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.
728 * ftl/FTLLowerDFGToLLVM.cpp:
729 (JSC::FTL::DFG::LowerDFGToLLVM::compileTailCall):
730 * tests/stress/tail-call-host-call-throw.js: Added.
732 2016-02-06 Darin Adler <darin@apple.com>
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
737 Reviewed by Sam Weinig.
739 * runtime/IntlObject.cpp:
740 (JSC::canonicalLangTag): Use converToASCIIUppercase on the language tag.
742 * runtime/StringPrototype.cpp:
743 (JSC::stringProtoFuncToLowerCase): Tweak style and update for name change.
744 (JSC::stringProtoFuncToUpperCase): Ditto.
746 2016-02-06 Chris Dumez <cdumez@apple.com>
748 Object.getOwnPropertyDescriptor() does not work on sub-frame's window
749 https://bugs.webkit.org/show_bug.cgi?id=153925
751 Reviewed by Darin Adler.
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.
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().
767 * runtime/JSObject.cpp:
768 (JSC::JSObject::getOwnPropertyDescriptor):
770 2016-02-06 Andreas Kling <akling@apple.com>
772 [iOS] Throw away linked code when navigating to a new page.
773 <https://webkit.org/b/153851>
775 Reviewed by Gavin Barraclough.
777 Add a VM API for throwing away linked code only.
780 (JSC::VM::deleteAllLinkedCode):
783 2016-02-06 Commit Queue <commit-queue@webkit.org>
785 Unreviewed, rolling out r196104.
786 https://bugs.webkit.org/show_bug.cgi?id=153940
788 Regressed Speedometer on iOS (Requested by kling on #webkit).
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
796 2016-02-05 Alex Christensen <achristensen@webkit.org>
798 Fix internal Windows build
799 https://bugs.webkit.org/show_bug.cgi?id=153930
800 <rdar://problem/24534864>
802 Reviewed by Mark Lam.
804 * JavaScriptCore.vcxproj/JavaScriptCore.proj:
805 I made a typo in r196144.
807 2016-02-05 Saam barati <sbarati@apple.com>
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>
813 Reviewed by Joseph Pecoraro.
815 We now send the sampling profiler's expression-level
816 line/column info in the inspector protocol.
818 * inspector/agents/InspectorScriptProfilerAgent.cpp:
819 (Inspector::buildSamples):
820 * inspector/protocol/ScriptProfiler.json:
821 * runtime/SamplingProfiler.h:
822 (JSC::SamplingProfiler::StackFrame::hasExpressionInfo):
824 2016-02-05 Saam barati <sbarati@apple.com>
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>
830 Rubber stamped by Joseph Pecoraro.
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.
836 * inspector/agents/InspectorScriptProfilerAgent.cpp:
837 (Inspector::InspectorScriptProfilerAgent::trackingComplete):
839 2016-02-05 Filip Pizlo <fpizlo@apple.com>
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
845 Reviewed by Mark Lam.
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.
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.
869 2016-02-04 Joseph Pecoraro <pecoraro@apple.com>
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>
875 Reviewed by Timothy Hatcher.
877 Be more explicit about enabling legacy profiling.
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.
892 2016-02-04 Keith Miller <keith_miller@apple.com>
894 ArrayPrototype should have a destroy function
895 https://bugs.webkit.org/show_bug.cgi?id=153847
897 Reviewed by Filip Pizlo.
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.
906 * runtime/ArrayPrototype.cpp:
907 (JSC::ArrayPrototype::create):
908 (JSC::ArrayPrototype::destroy):
909 * runtime/ArrayPrototype.h:
912 2016-02-04 Filip Pizlo <fpizlo@apple.com>
914 REGRESSION(192409): Cannot rely on add32() to zero-extend
915 https://bugs.webkit.org/show_bug.cgi?id=153897
917 Unreviewed rollout of r192409.
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.
941 2016-02-04 Andreas Kling <akling@apple.com>
943 Remove dead ENABLE(BYTECODE_COMMENTS) cruft.
944 <https://webkit.org/b/153888>
946 Reviewed by Antti Koivisto.
948 * bytecode/UnlinkedCodeBlock.cpp:
949 (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock): Deleted.
950 * bytecode/UnlinkedCodeBlock.h:
951 (JSC::UnlinkedCodeBlock::shrinkToFit): Deleted.
953 2016-02-04 Saam barati <sbarati@apple.com>
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>
959 Reviewed by Geoffrey Garen.
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.
967 This helps us come up with good names for frames where
968 the Callee object is a bound function or an InternalFunction.
970 * inspector/agents/InspectorScriptProfilerAgent.cpp:
971 (Inspector::InspectorScriptProfilerAgent::addEvent):
972 (Inspector::buildSamples):
973 (Inspector::InspectorScriptProfilerAgent::trackingComplete):
974 * runtime/SamplingProfiler.cpp:
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):
1009 2016-02-04 Chris Dumez <cdumez@apple.com>
1011 Object.getOwnPropertyDescriptor() returns incomplete descriptor for instance properties
1012 https://bugs.webkit.org/show_bug.cgi?id=153817
1014 Reviewed by Geoffrey Garen.
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.
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.
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.
1041 * runtime/JSObject.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
1050 2016-02-04 Alex Christensen <achristensen@webkit.org>
1052 Fix internal Windows build
1053 https://bugs.webkit.org/show_bug.cgi?id=153886
1054 <rdar://problem/24499887>
1056 Reviewed by Mark Lam.
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.
1069 2016-02-03 Yusuke Suzuki <utatane.tea@gmail.com>
1071 [JSC] Make some classes non JSDestructibleObject
1072 https://bugs.webkit.org/show_bug.cgi?id=153838
1074 Reviewed by Geoffrey Garen.
1076 SymbolPrototype, JSMapIterator and JSSetIterator are trivially destructible.
1077 So there is no need to inherit JSDestructibleObject.
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:
1088 2016-02-03 Yusuke Suzuki <utatane.tea@gmail.com>
1090 [JSC] Symbol structure has unnecessary flags
1091 https://bugs.webkit.org/show_bug.cgi?id=153840
1093 Reviewed by Saam Barati.
1096 * tests/stress/symbol-get-own-property.js: Added.
1099 2016-02-03 Andreas Kling <akling@apple.com>
1101 [iOS] Throw away linked code when navigating to a new page.
1102 <https://webkit.org/b/153851>
1104 Reviewed by Gavin Barraclough.
1106 Add a VM API for throwing away linked code only.
1109 (JSC::VM::deleteAllLinkedCode):
1112 2016-02-03 Michael Catanzaro <mcatanzaro@igalia.com>
1114 [GTK][EFL] Switch FTL to B3
1115 https://bugs.webkit.org/show_bug.cgi?id=153478
1117 Reviewed by Csaba Osztrogonác.
1119 Conditionalize code to make it possible to build FTL completely without LLVM.
1124 (JSC::DFG::Plan::compileInThreadImpl):
1125 * ftl/FTLAbbreviatedTypes.h:
1129 (JSC::FTL::State::State):
1130 (JSC::FTL::State::~State):
1132 2016-02-03 Carlos Garcia Campos <cgarcia@igalia.com>
1134 Unreviewed. Fix JavaScriptCore build with B3 enabled.
1136 Include <limits.h> for UINT_MAX.
1139 * b3/air/AirStackSlot.h:
1141 2016-02-02 Caitlin Potter <caitp@igalia.com>
1143 JSSymbolTableObject::deleteProperty() crashes deleting Symbols
1144 https://bugs.webkit.org/show_bug.cgi?id=153816
1146 Reviewed by Darin Adler.
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.
1152 * runtime/JSSymbolTableObject.cpp:
1153 (JSC::JSSymbolTableObject::deleteProperty):
1154 * tests/es6/Object_static_methods_Object.getOwnPropertyDescriptors.js:
1156 * tests/stress/regress-153816.js: Added.
1157 (deleteSymbolFromJSSymbolTableObject):
1159 2016-02-02 Benjamin Poulain <benjamin@webkit.org>
1161 [JSC] Do not copy FP when lowering FramePointer
1162 https://bugs.webkit.org/show_bug.cgi?id=153769
1164 Reviewed by Michael Saboff.
1166 That extra move is just wasted time. The fewer Moves we have,
1169 * b3/B3LowerToAir.cpp:
1170 (JSC::B3::Air::LowerToAir::tmp):
1171 (JSC::B3::Air::LowerToAir::lower):
1173 2016-02-02 Keith Miller <keith_miller@apple.com>
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
1178 Reviewed by Benjamin Poulain.
1180 This patch adds a new printing option for each of the DFG/FTL compilation phases.
1183 (JSC::B3::shouldDumpIR):
1184 (JSC::B3::shouldDumpIRAtEachPhase):
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):
1197 (JSC::DFG::shouldDumpGraphAtEachPhase):
1199 (JSC::DFG::Phase::beginPhase):
1200 * runtime/Options.cpp:
1201 (JSC::recomputeDependentOptions):
1202 * runtime/Options.h:
1204 2016-02-02 Caitlin Potter <caitp@igalia.com>
1206 [JSC] make Object.getOwnPropertyDescriptors() work with non-JSObject types
1207 https://bugs.webkit.org/show_bug.cgi?id=153814
1209 Reviewed by Yusuke Suzuki.
1211 * runtime/ObjectConstructor.cpp:
1212 (JSC::objectConstructorGetOwnPropertyDescriptors):
1213 * tests/es6/Object_static_methods_Object.getOwnPropertyDescriptors.js:
1216 2016-02-02 Aakash Jain <aakash_jain@apple.com>
1218 Remove references to CallFrameInlines.h
1219 https://bugs.webkit.org/show_bug.cgi?id=153810
1221 Reviewed by Mark Lam.
1223 * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj:
1224 * JavaScriptCore.vcxproj/JavaScriptCore.vcxproj.filters:
1226 2016-02-02 Caitlin Potter <caitp@igalia.com>
1228 [JSC] Implement Object.getOwnPropertyDescriptors() proposal
1229 https://bugs.webkit.org/show_bug.cgi?id=153799
1231 Reviewed by Darin Adler.
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
1237 The method extracts a set of property descriptor objects, which can
1238 be safely used via `Object.create()`.
1240 * runtime/ObjectConstructor.cpp:
1241 (JSC::objectConstructorGetOwnPropertyDescriptors):
1243 2016-02-02 Filip Pizlo <fpizlo@apple.com>
1245 B3 should be able to compile trivial self-loops
1246 https://bugs.webkit.org/show_bug.cgi?id=153802
1247 rdar://problem/24465632
1249 Reviewed by Michael Saboff.
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
1256 This disables tail duplication of self-loops, adds a test, and adds better validation for this
1259 * b3/B3DuplicateTails.cpp:
1260 * b3/B3Procedure.cpp:
1261 (JSC::B3::Procedure::resetReachability):
1263 (JSC::B3::testComputeDivisionMagic):
1264 (JSC::B3::testTrivialInfiniteLoop):
1268 2016-02-02 Saam barati <sbarati@apple.com>
1270 [ES6] bound functions .name property should be "bound " + the target function's name
1271 https://bugs.webkit.org/show_bug.cgi?id=153796
1273 Reviewed by Mark Lam.
1275 See http://tc39.github.io/ecma262/#sec-function.prototype.bind for details.
1279 foo.bind(null).name === "bound foo"
1281 (function bar() { }).bind(null).name === "bound bar"
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):
1297 2016-02-02 Filip Pizlo <fpizlo@apple.com>
1299 Get rid of anonymous stack slots
1300 https://bugs.webkit.org/show_bug.cgi?id=151128
1302 Reviewed by Mark Lam.
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.
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.
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.
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!
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.
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.
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.
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.
1364 This doesn't affect performance. It just makes the compiler more fun to work with by
1365 removing some cognitive dissonance.
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:
1387 (JSC::B3::Effects::interferes):
1388 (JSC::B3::Effects::dump):
1390 (JSC::B3::Effects::mustExecute):
1391 * b3/B3EliminateCommonSubexpressions.cpp:
1393 (JSC::B3::demoteValues):
1397 (JSC::B3::IndexMap::resize):
1398 (JSC::B3::IndexMap::clear):
1399 (JSC::B3::IndexMap::size):
1400 (JSC::B3::IndexMap::operator[]):
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:
1410 (WTF::printInternal):
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.
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):
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:
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):
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):
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):
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):
1603 2016-02-02 Yusuke Suzuki <utatane.tea@gmail.com>
1605 [JSC] Introduce BytecodeIntrinsic constant rep like @undefined
1606 https://bugs.webkit.org/show_bug.cgi?id=153737
1608 Reviewed by Darin Adler.
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).
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.
1621 And by using this mechanism, we implement several constants. @undefined, @arrayIterationKindKeyValue etc.
1623 * builtins/ArrayConstructor.js:
1625 * builtins/ArrayIteratorPrototype.js:
1627 * builtins/ArrayPrototype.js:
1639 (sort.compactSparse):
1644 * builtins/DatePrototype.js:
1645 (toLocaleString.toDateTimeOptionsAnyAll):
1647 (toLocaleDateString.toDateTimeOptionsDateDate):
1648 (toLocaleDateString):
1649 (toLocaleTimeString.toDateTimeOptionsTimeTime):
1650 (toLocaleTimeString):
1651 * builtins/GeneratorPrototype.js:
1653 * builtins/GlobalObject.js:
1655 * builtins/InternalPromiseConstructor.js:
1656 (internalAll.newResolveElement):
1658 * builtins/IteratorPrototype.js:
1659 (symbolIteratorGetter):
1660 (symbolIterator): Deleted.
1661 * builtins/MapPrototype.js:
1663 * builtins/ModuleLoaderObject.js:
1665 (forceFulfillPromise):
1666 (commitInstantiated):
1669 (requestInstantiate):
1672 * builtins/PromiseConstructor.js:
1673 (all.newResolveElement):
1678 * builtins/PromiseOperations.js:
1679 (newPromiseCapability.executor):
1680 (newPromiseCapability):
1683 (createResolvingFunctions.resolve):
1684 (createResolvingFunctions.reject):
1685 (createResolvingFunctions):
1686 (promiseReactionJob):
1687 (promiseResolveThenableJob):
1688 (initializePromise):
1689 * builtins/PromisePrototype.js:
1692 * builtins/SetPrototype.js:
1694 * builtins/StringConstructor.js:
1696 * builtins/StringIteratorPrototype.js:
1698 * builtins/StringPrototype.js:
1700 * builtins/TypedArrayConstructor.js:
1703 * builtins/TypedArrayPrototype.js:
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):
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.
1743 (JSC::VM::bytecodeIntrinsicRegistry):
1745 2016-02-02 Per Arne Vollan <peavo@outlook.com>
1747 [B3][Win64] Compile fixes.
1748 https://bugs.webkit.org/show_bug.cgi?id=153605
1750 Reviewed by Filip Pizlo.
1752 Fix remaining compile errors on Win64.
1756 (JSC::B3::CFG::newMap):
1759 2016-02-01 Chris Dumez <cdumez@apple.com>
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>
1765 Reviewed by Oliver Hunt.
1767 Add support for CustomAccessor slots to objectProtoFuncLookupGetter() and
1768 objectProtoFuncLookupSetter() by return getOwnPropertyDescriptor().get / set.
1769 getOwnPropertyDescriptor() now correctly deals with CustomAccessors since
1772 * runtime/ObjectPrototype.cpp:
1773 (JSC::objectProtoFuncLookupGetter):
1774 (JSC::objectProtoFuncLookupSetter):
1776 2016-02-01 Chris Dumez <cdumez@apple.com>
1778 Native Bindings Descriptors are Incomplete
1779 https://bugs.webkit.org/show_bug.cgi?id=140575
1780 <rdar://problem/19506502>
1782 Reviewed by Oliver Hunt.
1784 This patch is based on initial work by Joe Pecoraro and Matthew Mirman.
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
1792 * JavaScriptCore.xcodeproj/project.pbxproj:
1793 * inspector/InjectedScriptSource.js:
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):
1819 2016-02-01 Joseph Pecoraro <pecoraro@apple.com>
1821 Web Inspector: High Level Memory Overview Instrument
1822 https://bugs.webkit.org/show_bug.cgi?id=153516
1823 <rdar://problem/24356378>
1825 Reviewed by Brian Burg.
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.
1835 2016-02-01 Benjamin Poulain <benjamin@webkit.org>
1837 [JSC] IRC can coalesce the frame pointer with a Tmp that is modified
1838 https://bugs.webkit.org/show_bug.cgi?id=153694
1840 Reviewed by Filip Pizlo.
1846 If we were to coalesce the Move, we would modify the frame pointer.
1847 Well, that's exactly what was happening with IRC.
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.
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.
1857 The two are within margin of error for performance. The second one was considerably
1858 more complicated. This patch implements the first one.
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.
1870 * b3/air/AirIteratedRegisterCoalescing.cpp:
1871 One branch could be transformed into an assertion: TmpLiveness is type specific now.
1873 (JSC::B3::testOverrideFramePointer):
1876 2016-02-01 Csaba Osztrogonác <ossy@webkit.org>
1878 Unreviewed speculative buildfix.
1880 * dfg/DFGCommon.h: FTL_USES_B3 should be false if FTL JIT is disabled.
1882 2016-01-31 Dan Bernstein <mitz@apple.com>
1884 [Cocoa] Remove unused definition of HAVE_HEADER_DETECTION_H
1885 https://bugs.webkit.org/show_bug.cgi?id=153729
1887 Reviewed by Sam Weinig.
1889 After r141700, HAVE_HEADER_DETECTION_H is no longer used.
1891 * Configurations/Base.xcconfig:
1893 2016-01-30 Filip Pizlo <fpizlo@apple.com>
1895 B3->Air lowering should use MoveFloat more
1896 https://bugs.webkit.org/show_bug.cgi?id=153714
1898 Reviewed by Sam Weinig.
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.
1903 * b3/B3LowerToAir.cpp:
1904 (JSC::B3::Air::LowerToAir::relaxedMoveForType):
1906 2016-01-31 Yusuke Suzuki <utatane.tea@gmail.com>
1908 Should not predict OtherObj for ToThis with primitive types under strict mode
1909 https://bugs.webkit.org/show_bug.cgi?id=153544
1911 Reviewed by Filip Pizlo.
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.
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.
1922 This optimization is important to implement Primitive.prototype.methods[1].
1923 Otherwise, we always got BadType OSR exits.
1925 [1]: https://bugs.webkit.org/show_bug.cgi?id=143889
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):
1955 2016-01-31 Guillaume Emont <guijemont@igalia.com>
1957 [mips] don't save to a callee saved register too early
1958 https://bugs.webkit.org/show_bug.cgi?id=153463
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().
1965 Reviewed by Michael Saboff.
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
1973 2016-01-30 Commit Queue <commit-queue@webkit.org>
1975 Unreviewed, rolling out r195799 and r195828.
1976 https://bugs.webkit.org/show_bug.cgi?id=153722
1978 Caused assertion failures, severely affecting EWS (Requested
1981 Reverted changesets:
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
1988 "Attempt to fix the Windows build after r195799"
1989 http://trac.webkit.org/changeset/195828
1991 2016-01-30 Yusuke Suzuki <utatane.tea@gmail.com>
1993 [B3] JetStream/quicksort.c fails/hangs on Linux with GCC
1994 https://bugs.webkit.org/show_bug.cgi?id=153647
1996 Reviewed by Filip Pizlo.
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.
2003 `signedMin = INT32_MIN = -2147483647 (-0x7fffffff)`
2005 `anc = t - 1 - (t % ad)` Oops, we performed overflow operation!
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.)
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
2014 * b3/B3ComputeDivisionMagic.h:
2015 (JSC::B3::computeDivisionMagic):
2017 (JSC::B3::testComputeDivisionMagic):
2020 2016-01-30 Andreas Kling <akling@apple.com>
2022 Shrink Heap::m_executables after cleaning it.
2023 <https://webkit.org/b/153682>
2025 Reviewed by Darin Adler.
2027 The Heap::m_executables Vector was never shrunk down, despite sometimes
2028 getting pretty huge (~500kB in my longest-running WebContent process.)
2030 After GC has finished pruning unmarked Executables, shrink the Vector.
2033 (JSC::Heap::clearUnmarkedExecutables):
2035 2016-01-29 Ada Chan <adachan@apple.com>
2037 Enable VIDEO_PRESENTATION_MODE only in Debug and Release builds on Mac
2038 https://bugs.webkit.org/show_bug.cgi?id=153665
2040 Reviewed by Dan Bernstein.
2042 * Configurations/FeatureDefines.xcconfig:
2044 2016-01-30 Yusuke Suzuki <utatane.tea@gmail.com>
2046 [B3] REGRESSION(r195882): Should break early after modConstant replaceWithNewValue succeeds
2047 https://bugs.webkit.org/show_bug.cgi?id=153711
2049 Reviewed by Filip Pizlo.
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.
2054 * b3/B3ReduceStrength.cpp:
2056 2016-01-30 Yusuke Suzuki <utatane.tea@gmail.com>
2058 Enable SamplingProfiler on POSIX environment
2059 https://bugs.webkit.org/show_bug.cgi?id=153584
2061 Reviewed by Michael Saboff.
2063 In this patch, we implement suspend and resume mechanizm for POSIX threads.
2064 And with GLIBC, we can retrieve registers from it.
2066 We take the following strategy.
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.
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.
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:
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:
2100 2016-01-29 Filip Pizlo <fpizlo@apple.com>
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
2105 Reviewed by Saam Barati.
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
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.
2115 * b3/B3ReduceStrength.cpp:
2117 2016-01-29 Keith Miller <keith_miller@apple.com>
2119 Array.prototype native functions should use Symbol.species to construct the result
2120 https://bugs.webkit.org/show_bug.cgi?id=153660
2122 Reviewed by Saam Barati.
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.
2128 * runtime/ArrayPrototype.cpp:
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:
2142 * runtime/ConstructData.h:
2143 * runtime/JSGlobalObject.cpp:
2144 (JSC::JSGlobalObject::init):
2146 * tests/stress/array-species-functions.js: Added.
2152 2016-01-29 Filip Pizlo <fpizlo@apple.com>
2154 CallLinkStatus should trust BadCell exit sites whenever there is no stub
2155 https://bugs.webkit.org/show_bug.cgi?id=153691
2157 Reviewed by Benjamin Poulain.
2159 This fixes a regression in our treatment of inlining failure exit sites when deciding if we
2160 should inline a call.
2162 A long time ago, a BadCell exit site would ensure that a CallLinkStatus returned
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.
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.
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.
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:
2184 - The exit kind is BadCell but CallLinkStatus needs BadExecutable to disable inlining.
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
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.
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
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.
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.
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.
2229 2016-01-29 Saam barati <sbarati@apple.com>
2231 Pack FunctionExecutable and UnlinkedFunctionExecutable harder
2232 https://bugs.webkit.org/show_bug.cgi?id=153687
2234 Reviewed by Andreas Kling.
2236 This patch reduces FunctionExecutable from 120 to 104 bytes.
2237 This patch reduces UnlinkedFunctionExecutable from 144 to 136 bytes.
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):
2255 2016-01-29 Saam barati <sbarati@apple.com>
2257 JSC Sampling Profiler: Come up with a (program counter => CodeOrigin) mapping
2258 https://bugs.webkit.org/show_bug.cgi?id=152629
2260 Reviewed by Filip Pizlo.
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.
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.
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.
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.
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.
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:
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):
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):
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):
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):
2392 (JSC::JIT::privateCompileMainPass):
2393 (JSC::JIT::privateCompileSlowCases):
2394 (JSC::JIT::privateCompile):
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):
2409 (functionSamplingProfilerStackTraces):
2410 * llint/LLIntPCRanges.h:
2411 (JSC::LLInt::isLLIntPC):
2412 * llint/LowLevelInterpreter.asm:
2413 * runtime/Options.h:
2414 * runtime/SamplingProfiler.cpp:
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):
2448 (JSC::VM::setShouldBuildPCToCodeOriginMapping):
2449 (JSC::VM::shouldBuilderPCToCodeOriginMapping):
2450 * tests/stress/sampling-profiler-basic.js:
2451 (platformSupportsSamplingProfiler.top):
2452 (platformSupportsSamplingProfiler.jaz):
2453 (platformSupportsSamplingProfiler.kaz):
2455 2016-01-29 Saam barati <sbarati@apple.com>
2457 Remove our notion of having a single activation register
2458 https://bugs.webkit.org/show_bug.cgi?id=153673
2460 Reviewed by Filip Pizlo.
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.
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):
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.
2548 2016-01-29 Filip Pizlo <fpizlo@apple.com>
2550 Air:fixObviousSpills should handle floats and doubles
2551 https://bugs.webkit.org/show_bug.cgi?id=153197
2553 Reviewed by Saam Barati.
2555 This adds the most obvious handling of float spills, where we just enable load elimination on
2558 * b3/air/AirFixObviousSpills.cpp:
2560 2016-01-29 Andreas Kling <akling@apple.com>
2563 <https://webkit.org/b/153640>
2565 Reviewed by Saam Barati.
2567 Shrink CodeBlock by 112 bytes (from 640 to 528) by employing
2568 these sophisticated tricks:
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.
2576 This increases CodeBlock space efficiency by 20%, as we can now
2577 fit 30 of them in a MarkedBlock, up from 25.)
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):
2593 2016-01-29 Saam barati <sbarati@apple.com>
2595 Exits from exceptions shouldn't jettison code
2596 https://bugs.webkit.org/show_bug.cgi?id=153564
2598 Reviewed by Geoffrey Garen.
2600 We create two new exit kinds for exception-handling
2602 - ExceptionCheck: an exception check after a C call.
2603 - GenericUnwind: an OSR exit executes because it's jumped to from genericUnwind machinery.
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.
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.
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.
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):
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.
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:
2693 2016-01-28 Yusuke Suzuki <utatane.tea@gmail.com>
2695 [B3] REGRESSION(r195395): testComplex(64, 128) asserts on Linux with GCC
2696 https://bugs.webkit.org/show_bug.cgi?id=153422
2698 Reviewed by Filip Pizlo.
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.
2707 To fix that, we hold ValuesCollection as a member of Procedure.
2708 And change the signature to const ValuesCollection& Procedure::values().
2710 * b3/B3Procedure.cpp:
2711 (JSC::B3::Procedure::Procedure):
2713 (JSC::B3::Procedure::values):
2715 2016-01-28 Joseph Pecoraro <pecoraro@apple.com>
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>
2721 Reviewed by Timothy Hatcher.
2723 Be more explicit about enabling legacy profiling.
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.
2738 2016-01-28 Yusuke Suzuki <utatane.tea@gmail.com>
2740 Fix the B3 build with GCC 4.9.3
2741 https://bugs.webkit.org/show_bug.cgi?id=151624
2743 Reviewed by Filip Pizlo.
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
2748 * b3/air/AirIteratedRegisterCoalescing.cpp:
2750 2016-01-28 Filip Pizlo <fpizlo@apple.com>
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
2755 Reviewed by Benjamin Poulain.
2757 This undoes the AsmBench/n-body regression in r195654 while preserving that revision's
2760 * b3/B3LowerToAir.cpp:
2761 (JSC::B3::Air::LowerToAir::LowerToAir):
2762 (JSC::B3::Air::LowerToAir::preferRightForResult):
2764 2016-01-28 Benjamin Poulain <bpoulain@apple.com>
2766 [JSC] B3 Tail Call with Varargs do not restore callee saved registers
2767 https://bugs.webkit.org/show_bug.cgi?id=153579
2769 Reviewed by Michael Saboff.
2771 We were trashing the callee saved registers in Tail Calls.
2773 I just copied the code from DFG to fix this :)
2775 * ftl/FTLLowerDFGToLLVM.cpp:
2776 (JSC::FTL::DFG::LowerDFGToLLVM::compileCallOrConstructVarargs):
2778 2016-01-27 Filip Pizlo <fpizlo@apple.com>
2780 B3 IntRange analysis should know more about shifting
2781 https://bugs.webkit.org/show_bug.cgi?id=153568
2783 Reviewed by Benjamin Poulain.
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
2790 CheckMul((@x & $268435455) >> 14, @y >> 14, ...)
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.
2796 * b3/B3ReduceStrength.cpp:
2799 2016-01-27 Benjamin Poulain <bpoulain@apple.com>
2801 [JSC] adjustFrameAndStackInOSRExitCompilerThunk() can trash values in FTL
2802 https://bugs.webkit.org/show_bug.cgi?id=153536
2804 Reviewed by Saam Barati.
2806 Workaround to get B3 working on ARM.
2808 * dfg/DFGOSRExitCompilerCommon.h:
2809 (JSC::DFG::adjustFrameAndStackInOSRExitCompilerThunk):
2810 The code was using the scratch registers in a few places.
2812 I initially tried to make is not use scratch registers anywhere
2813 but that looked super fragile.
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.
2818 2016-01-27 Konstantin Tokarev <annulen@yandex.ru>
2820 [mips] Use reinterpret_cast_ptr to suppress alignment warnings.
2821 https://bugs.webkit.org/show_bug.cgi?id=153424
2823 Reviewed by Darin Adler.
2825 * runtime/JSGenericTypedArrayView.h:
2826 (JSC::JSGenericTypedArrayView::sortFloat):
2828 2016-01-27 Per Arne Vollan <peavo@outlook.com>
2830 [FTL][Win64] Compile fix.
2831 https://bugs.webkit.org/show_bug.cgi?id=153555
2833 Reviewed by Alex Christensen.
2835 MSVC does not accept preprocessor conditionals in macros.
2837 * ftl/FTLOSRExitCompiler.cpp:
2838 (JSC::FTL::compileStub):
2840 2016-01-27 Filip Pizlo <fpizlo@apple.com>
2842 Air::TmpWidth uses a stale pointer into its HashMap after it calls add()
2843 https://bugs.webkit.org/show_bug.cgi?id=153546
2845 Reviewed by Saam Barati.
2847 * b3/air/AirTmpWidth.cpp:
2848 (JSC::B3::Air::TmpWidth::recompute):
2850 2016-01-27 Alexey Proskuryakov <ap@apple.com>
2852 Remove ENABLE_CURRENTSRC
2853 https://bugs.webkit.org/show_bug.cgi?id=153545
2855 Reviewed by Simon Fraser.
2857 * Configurations/FeatureDefines.xcconfig:
2859 2016-01-26 Benjamin Poulain <benjamin@webkit.org>
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
2864 Reviewed by Filip Pizlo.
2875 @42 = Branch(@x, #1, #2)
2877 B3LowerToAir would pick @1 for the argument copied
2878 for what goes into the UseDef side of Add.
2880 This created a bunch of moves that could never be coalesced.
2881 In Kraken's imaging-desaturate, there were enough Moves to slow
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.
2889 In this patch, I went with a simple heuristic: prioritize the value
2890 defined in the same block for UseDef.
2892 There is one other way that would be cheap but a bit invasive:
2894 -Make every ops, 3 operands.
2895 -Tell the register allocator to attempt aliasing of the 2 uses
2897 -If the allocator fails, just add a move as needed.
2899 For now, the simple heuristic seems okay for the cases have.
2901 * b3/B3LowerToAir.cpp:
2902 (JSC::B3::Air::LowerToAir::preferRightForResult):
2904 2016-01-26 Filip Pizlo <fpizlo@apple.com>
2906 Tail duplication should break critical edges first
2907 https://bugs.webkit.org/show_bug.cgi?id=153530
2909 Reviewed by Benjamin Poulain.
2911 This speeds up Octane/boyer.
2913 * b3/B3DuplicateTails.cpp:
2915 2016-01-26 Joseph Pecoraro <pecoraro@apple.com>
2917 Generalize ResourceUsageData gathering to be used outside of ResourceUsageOverlay
2918 https://bugs.webkit.org/show_bug.cgi?id=153509
2919 <rdar://problem/24354291>
2921 Reviewed by Andreas Kling.
2924 * heap/HeapInlines.h:
2925 (JSC::Heap::didAllocateBlock):
2926 (JSC::Heap::didFreeBlock):
2927 Rename the ENABLE flag.
2929 2016-01-26 Csaba Osztrogonác <ossy@webkit.org>
2931 [B3] Fix control reaches end of non-void function GCC warning after r195139
2932 https://bugs.webkit.org/show_bug.cgi?id=153426
2934 Reviewed by Michael Catanzaro.
2937 (JSC::B3::Air::Arg::cooled):
2939 2016-01-26 Saam barati <sbarati@apple.com>
2941 testb3 and testAir should be compiled under -O0
2942 https://bugs.webkit.org/show_bug.cgi?id=153520
2944 Reviewed by Benjamin Poulain.
2946 * JavaScriptCore.xcodeproj/project.pbxproj:
2948 2016-01-26 Filip Pizlo <fpizlo@apple.com>
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
2953 Reviewed by Benjamin Poulain.
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.
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.
2962 8% speed-up on Octane/encrypt.
2964 * b3/B3ReduceStrength.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):
2970 2016-01-26 Filip Pizlo <fpizlo@apple.com>
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
2975 Reviewed by Geoffrey Garen.
2977 * dfg/DFGTierUpCheckInjectionPhase.cpp:
2978 (JSC::DFG::TierUpCheckInjectionPhase::run):
2979 * runtime/Options.h:
2981 2016-01-26 Filip Pizlo <fpizlo@apple.com>
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
2986 Reviewed by Saam Barati.
2988 Turn this: Shl(@x, BitAnd(@y, 63))
2989 Into this: Shl(@x, @y)
2991 It matters for Octane/crypto.
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.
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.
2999 * b3/B3ReduceStrength.cpp:
3001 2016-01-26 Filip Pizlo <fpizlo@apple.com>
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
3007 Reviewed by Geoffrey Garen and Saam Barati.
3009 Prior to this change, B3 represented stack slots by having a StackSlotValue that carried
3012 - It represented a stack slot.
3014 - It was a kind of Value for getting the base of the stack slot.
3016 This seems like a good idea until you consider the following issues.
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.
3023 2) A premise of B3 is that it should be always legal to perform the following
3024 transformation on a value:
3026 value->replaceWithIdentity(insertionSet.insertValue(index, proc.clone(value)));
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
3033 3) A premise of B3 is that it should be always legal to perform the following
3034 transformation on a value:
3040 Branch(@doesntMatter, #yes, #no)
3042 @42_one = Thing(...)
3043 Upsilon(@42_one, ^42)
3046 @42_two = Thing(...)
3047 Upsilon(@42_two, ^42)
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
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).
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.
3074 * JavaScriptCore.xcodeproj/project.pbxproj:
3075 * b3/B3EliminateCommonSubexpressions.cpp:
3077 (JSC::B3::demoteValues):
3079 * b3/B3LowerToAir.cpp:
3080 (JSC::B3::Air::LowerToAir::run):
3081 (JSC::B3::Air::LowerToAir::effectiveAddr):
3082 (JSC::B3::Air::LowerToAir::lower):
3084 (WTF::printInternal):
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):
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:
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):
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.
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):
3179 2016-01-26 Benjamin Poulain <benjamin@webkit.org>
3181 Remove a useless #include
3182 https://bugs.webkit.org/show_bug.cgi?id=153474
3184 Reviewed by Alexey Proskuryakov.
3186 * b3/B3ReduceStrength.cpp:
3188 2016-01-26 Alex Christensen <achristensen@webkit.org>
3190 [Win] Fix clean build after r195545.
3191 https://bugs.webkit.org/show_bug.cgi?id=153434
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.
3198 2016-01-25 Filip Pizlo <fpizlo@apple.com>
3200 FTLB3Output should maintain good block order like the LLVM one does
3201 https://bugs.webkit.org/show_bug.cgi?id=152222
3203 Reviewed by Geoffrey Garen.
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
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.
3214 * b3/B3Procedure.cpp:
3215 (JSC::B3::Procedure::addBlock):
3216 (JSC::B3::Procedure::setBlockOrderImpl):
3217 (JSC::B3::Procedure::clone):
3219 (JSC::B3::Procedure::frontendData):
3220 (JSC::B3::Procedure::setBlockOrder):
3221 * dfg/DFGIntegerRangeOptimizationPhase.cpp:
3222 * disassembler/udis86/udis86_syn-att.c:
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):
3237 2016-01-25 Skachkov Oleksandr <gskachkov@gmail.com>
3239 [ES6] Arrow function syntax. Arrow function specific features. Lexical bind "arguments"
3240 https://bugs.webkit.org/show_bug.cgi?id=145132
3242 Reviewed by Saam Barati.
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.
3250 * bytecompiler/BytecodeGenerator.cpp:
3251 (JSC::BytecodeGenerator::BytecodeGenerator):
3253 (JSC::Scope::Scope):
3254 (JSC::Scope::setSourceParseMode):
3255 (JSC::Scope::isArrowFunction):
3256 (JSC::Scope::collectFreeVariables):
3257 (JSC::Scope::setIsArrowFunction):
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.
3263 2016-01-25 Benjamin Poulain <bpoulain@apple.com>
3265 [JSC] We should never use x18 on iOS ARM64
3266 https://bugs.webkit.org/show_bug.cgi?id=153461
3268 Reviewed by Filip Pizlo.
3270 The register x18 is reserved in the iOS variant of the ARM64 ABI.
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.
3275 This patch adds x18 to the reserved register and add assertions
3276 to the assembler to prevent similar problems in the future.
3278 * assembler/ARM64Assembler.h:
3279 (JSC::ARM64Assembler::xOrSp):
3280 (JSC::ARM64Assembler::xOrZr):
3281 * assembler/AbstractMacroAssembler.h:
3282 (JSC::isIOS): Deleted.
3283 * assembler/AssemblerCommon.h:
3285 * jit/RegisterSet.cpp:
3286 (JSC::RegisterSet::reservedHardwareRegisters):
3288 2016-01-25 Commit Queue <commit-queue@webkit.org>
3290 Unreviewed, rolling out r195550.
3291 https://bugs.webkit.org/show_bug.cgi?id=153471
3293 broke animometer bot (and now we have crash logs!) (Requested
3294 by kling on #webkit).
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
3302 2016-01-25 Andreas Kling <akling@apple.com>
3304 MarkedSpace should have more precise allocators.
3305 <https://webkit.org/b/153448>
3306 <rdar://problem/23897477>
3308 Reviewed by Geoffrey Garen.
3310 The four classes responsible for the bulk of MarkedBlock allocations today are:
3312 - FunctionCodeBlock (640 bytes)
3313 - UnlinkedFunctionCodeBlock (304 bytes)
3314 - FunctionExecutable (168 bytes)
3315 - UnlinkedFunctionExecutable (144 bytes)
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.
3322 Thus each instance of those classes would waste space as follows:
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)
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.
3332 The cost of this is 7kB worth of MarkedAllocators and 70 (~2x) more allocators to
3333 iterate whenever we iterate all the allocators.
3335 * heap/MarkedSpace.h:
3336 * heap/MarkedSpace.cpp:
3337 (JSC::MarkedSpace::MarkedSpace):
3338 (JSC::MarkedSpace::resetAllocators):
3339 (JSC::MarkedSpace::forEachAllocator):
3340 (JSC::MarkedSpace::isPagedOut):
3342 2016-01-25 Filip Pizlo <fpizlo@apple.com>
3344 Fix the comment about FTL_USES_B3.
3348 2016-01-25 Filip Pizlo <fpizlo@apple.com>
3350 Switch FTL to B3 on X86_64/Mac
3351 https://bugs.webkit.org/show_bug.cgi?id=153445
3353 Rubber stamped by Geoffrey Garen.
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.
3360 Right now this mostly appears as perf-neutral on the major tests