Source/JavaScriptCore/ChangeLog

   1 2016-05-05  Filip Pizlo  <fpizlo@apple.com>
   2
   3         Reduce maximum JIT pool size on X86_64.
   4
   5         Rubber stamped by Geoffrey Garen.
   6
   7         This changes our maximum pool size to 100MB. The problem with letting a page allocate much
   8         more than this is that we will sometimes call deleteAllCode() or one of its friends. Deleting
   9         a huge amount of memory is expensive in our allocator.
  10
  11         So long as we allow for such large-scale code death to happen, and so long as it's expensive,
  12         we should bound the amount of code we end up with in the first place.
  13
  14         In the long run, we should fix our executable allocator so that it's not so expensive to kill
  15         all code.
  16
  17         * jit/ExecutableAllocator.h:
  18
  19 2016-05-05  Filip Pizlo  <fpizlo@apple.com>
  20
  21         Reduce thresholds that control the maximum IC stub size.
  22
  23         Rubber stamped by Chris Dumez and Benjamin Poulain.
  24
  25         This reduces the thresholds to before the megamorphic load optimizations to see if that
  26         recovers a PLT regression.
  27
  28         * runtime/Options.h:
  29
  30 2016-05-05  Filip Pizlo  <fpizlo@apple.com>
  31
  32         We shouldn't crash if DFG AI proved that something was unreachable on one run but then decided not to prove it on another run
  33         https://bugs.webkit.org/show_bug.cgi?id=157379
  34
  35         Reviewed by Mark Lam.
  36
  37         Any run of DFG AI is a fixpoint that loosens the proof until it can't find any more
  38         counterexamples to the proof.  It errs on the side of loosening proofs, i.e., on the side of
  39         proving fewer things.
  40
  41         We run this fixpoint multiple times since there are multiple points in the DFG optimization
  42         pipeline when we run DFG AI.  Each of those runs completes a fixpoint and produces the
  43         tightest proof it can that did not result in counterexamples being found.
  44
  45         It's possible that on run K of DFG AI, we prove some property, but on run K+1, we don't prove
  46         that property. The code could have changed between the two runs due to other phases. Other
  47         phases may modify the code in such a way that it's less amenable to AI's analysis. Our design
  48         allows this because DFG AI is not 100% precise. It defends itself from making unsound choices
  49         or running forever by sometimes punting on proving some property. It must be able to do this,
  50         and so therefore, it might sometimes prove fewer things on a later run.
  51
  52         Currently in trunk if the property that AI proves on run K but fails to prove on run K+1 is
  53         the reachability of a piece of code, then run K+1 will crash on an assertion at the
  54         Unreachable node. It will complain that it reached an Unreachable. But it might be reaching
  55         that Unreachable because it failed to prove that something earlier was always exiting. That's
  56         OK, see above.
  57
  58         So, we should remove the assertion that AI doesn't see Unreachable.
  59
  60         No new tests because I don't know how to make this happen. I believe that this happens in the
  61         wild based on crash logs.
  62
  63         * dfg/DFGAbstractInterpreterInlines.h:
  64         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
  65
  66 2016-05-05  Joseph Pecoraro  <pecoraro@apple.com>
  67
  68         Crash if you type "debugger" in the console and continue
  69         https://bugs.webkit.org/show_bug.cgi?id=156924
  70         <rdar://problem/25884189>
  71
  72         Reviewed by Mark Lam.
  73
  74         * inspector/agents/InspectorDebuggerAgent.cpp:
  75         (Inspector::InspectorDebuggerAgent::evaluateOnCallFrame):
  76         Bail with an error when we are not paused.
  77
  78         * inspector/agents/InspectorRuntimeAgent.cpp:
  79         (Inspector::InspectorRuntimeAgent::callFunctionOn):
  80         (Inspector::InspectorRuntimeAgent::getProperties):
  81         (Inspector::InspectorRuntimeAgent::getDisplayableProperties):
  82         (Inspector::InspectorRuntimeAgent::getCollectionEntries):
  83         (Inspector::InspectorRuntimeAgent::saveResult):
  84         Update poor error message.
  85
  86 2016-05-05  Keith Miller  <keith_miller@apple.com>
  87
  88         Add support for delete by value to the DFG
  89         https://bugs.webkit.org/show_bug.cgi?id=157372
  90
  91         Reviewed by Filip Pizlo.
  92
  93         This patch adds basic support for delete by value to the DFG. delete by value
  94         just calls out to a C++ operation on each execution. Additionally, this patch
  95         fixes an issue with delete by id where we would crash if the base was null
  96         or undefined.
  97
  98         * dfg/DFGAbstractInterpreterInlines.h:
  99         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
 100         * dfg/DFGByteCodeParser.cpp:
 101         (JSC::DFG::ByteCodeParser::parseBlock):
 102         * dfg/DFGCapabilities.cpp:
 103         (JSC::DFG::capabilityLevel):
 104         * dfg/DFGClobberize.h:
 105         (JSC::DFG::clobberize):
 106         * dfg/DFGDoesGC.cpp:
 107         (JSC::DFG::doesGC):
 108         * dfg/DFGFixupPhase.cpp:
 109         (JSC::DFG::FixupPhase::fixupNode):
 110         * dfg/DFGNodeType.h:
 111         * dfg/DFGPredictionPropagationPhase.cpp:
 112         * dfg/DFGSafeToExecute.h:
 113         (JSC::DFG::safeToExecute):
 114         * dfg/DFGSpeculativeJIT.cpp:
 115         (JSC::DFG::SpeculativeJIT::compileDeleteById):
 116         (JSC::DFG::SpeculativeJIT::compileDeleteByVal):
 117         * dfg/DFGSpeculativeJIT.h:
 118         (JSC::DFG::SpeculativeJIT::callOperation):
 119         * dfg/DFGSpeculativeJIT32_64.cpp:
 120         (JSC::DFG::SpeculativeJIT::compile):
 121         * dfg/DFGSpeculativeJIT64.cpp:
 122         (JSC::DFG::SpeculativeJIT::compile):
 123         * jit/JIT.cpp:
 124         (JSC::JIT::privateCompileMainPass):
 125         * jit/JIT.h:
 126         * jit/JITOperations.cpp:
 127         * jit/JITOperations.h:
 128         * jit/JITPropertyAccess.cpp:
 129         (JSC::JIT::emit_op_del_by_val):
 130         * jit/JITPropertyAccess32_64.cpp:
 131         (JSC::JIT::emit_op_del_by_val):
 132         * tests/stress/delete-by-val.js: Added.
 133         (assert):
 134         (test):
 135         * tests/stress/delete-to-object-exception.js: Added.
 136         (assert):
 137         (test):
 138
 139 2016-05-05  Michael Saboff  <msaboff@apple.com>
 140
 141         Unreviewed build fix after change set r200447.
 142
 143         Made the detection of clang version XCode build specific.
 144         Now shouldEnableDebugAnnotations() should return false for all other build types.
 145
 146         * offlineasm/config.rb:
 147
 148 2016-05-05  Joseph Pecoraro  <pecoraro@apple.com>
 149
 150         Create console object lazily
 151         https://bugs.webkit.org/show_bug.cgi?id=157328
 152
 153         Reviewed by Geoffrey Garen.
 154
 155         * runtime/CommonIdentifiers.h:
 156         * runtime/JSGlobalObject.cpp:
 157         (JSC::createConsoleProperty):
 158         (JSC::JSGlobalObject::init): Deleted.
 159
 160 2016-05-04  Michael Saboff  <msaboff@apple.com>
 161
 162         Enable Dwarf2 debug information in offline assembler for clang compiler
 163         https://bugs.webkit.org/show_bug.cgi?id=157364.
 164
 165         Reviewed by Mark Lam.
 166
 167         Added a new function shouldEnableDebugAnnotations() that determines if
 168         we are using clang and a new enough version to support the debug annotations.
 169
 170         * offlineasm/config.rb:
 171         (shouldEnableDebugAnnotations): Added.
 172
 173 2016-05-04  Keith Miller  <keith_miller@apple.com>
 174
 175         Unreviewed, fix test for new ArrayIteratorPrototype.next() error message.
 176
 177         * tests/stress/array-iterators-next-with-call.js:
 178
 179 2016-05-04  Filip Pizlo  <fpizlo@apple.com>
 180
 181         Speed up JSGlobalObject initialization by making some properties lazy
 182         https://bugs.webkit.org/show_bug.cgi?id=157045
 183
 184         Reviewed by Keith Miller.
 185
 186         This makes about half of JSGlobalObject's state lazy. There are three categories of
 187         state in JSGlobalObject:
 188
 189         1) C++ fields in JSGlobalObject.
 190         2) JS object properties in JSGlobalObject's JSObject superclass.
 191         3) JS variables in JSGlobalObject's JSSegmentedVariableObject superclass.
 192
 193         State held in JS variables cannot yet be made lazy. That's why this patch only goes
 194         half-way.
 195
 196         State in JS object properties can be made lazy if we move it to the static property
 197         hashtable. JSGlobalObject already had one of those. This patch makes static property
 198         hashtables a lot more powerful, by adding three new kinds of static properties. These
 199         new kinds allow us to make almost all of JSGlobalObject's object properties lazy.
 200
 201         State in C++ fields can now be made lazy thanks in part to WTF's support for stateless
 202         lambdas. You can of course make anything lazy by hand, but there are many C++ fields in
 203         JSGlobalObject and we are adding more all the time. We don't want to require that each
 204         of these has a getter with an initialization check and a corresponding out-of-line slow
 205         path that does the initialization. We want this kind of boilerplate to be handled by
 206         some abstractions.
 207
 208         The primary abstraction introduced in this patch is LazyProperty<Type>. Currently, this
 209         only works where Type is a subclass of JSCell. Such a property holds a pointer to Type.
 210         You can use it like you would a WriteBarrier<Type>. It even has set() and get() methods,
 211         so it's almost a drop-in replacement.
 212
 213         The key to LazyProperty<Type>'s power is that you can do this:
 214
 215             class Bar {
 216                 ...
 217                 LazyProperty<Foo> m_foo;
 218             };
 219             ...
 220             m_foo.initLater(
 221                 [] (const LazyProperty<Foo>::Initializer<Bar>& init) {
 222                     init.set(Foo::create(init.vm, init.owner));
 223                 });
 224
 225         This initLater() call requires that you pass a stateless lambda (see WTF changelog for
 226         the definition). Miraculously, this initLater() call is guaranteed to compile to a store
 227         of a pointer constant to m_foo, as in:
 228
 229             movabsq 0xBLAH, %rax
 230             movq %rax, &m_foo
 231
 232         This magical pointer constant points to a callback that was generated by the template
 233         instantiation of initLater(). That callback knows to call your stateless lambda, but
 234         also does some other bookkeeping: it makes sure that you indeed initialized the property
 235         inside the callback and it manages recursive initializations. It's totally legal to call
 236         m_foo.get() inside the initLater() callback. If you do that before you call init.set(),
 237         m_foo.get() will return null. This is an excellent escape hatch if we ever find
 238         ourselves in a dependency cycle. I added this feature because I already had to create a
 239         dependency cycle.
 240
 241         Note that using LazyProperties from DFG threads is super awkward. It's going to be hard
 242         to get this right. The DFG thread cannot initialize those fields, so it has to make sure
 243         that it does conservative things. But for some nodes this could mean adding a lot of new
 244         logic, like NewTypedArray, which currently is written in such a way that it assumes that
 245         we always have the typed array structure. Currently we take a two-fold approach: for
 246         typed arrays we don't handle the NewTypedArray intrinsic if the structure isn't
 247         initialized, and for everything else we don't make the properties lazy if the DFG needs
 248         them. As we optimize this further we might need to teach the DFG to handle more lazy
 249         properties. I tried to do this for RegExp but found it to be very confusing. With typed
 250         arrays I got lucky.
 251
 252         There is also a somewhat more powerful construct called LazyClassStructure. We often
 253         need to keep around the structure of some standard JS class, like Date. We also need to
 254         make sure that the constructor ends up in the global object's property table. And we
 255         often need to keep the original value of the constructor for ourselves. In this case, we
 256         want to make sure that the creation of the structure-prototype-constructor constellation
 257         is atomic. We don't want code to start looking at the structure if it points to a
 258         prototype that doesn't have its "constructor" property set yet, for example.
 259         LazyClassStructure solves this by abstracting that whole initialization. You provide the
 260         callback that allocates everything, since we are super inconsistent about the way we
 261         initialize things, but LazyClassStructure establishes the workflow and helps you not
 262         mess up.
 263
 264         Finally, the new static hashtable attributes allow for all of this to work with the JS
 265         property table:
 266
 267         PropertyCallback: if you use this attribute, the second column in the table should be
 268         the name of a function to call to initialize this property. This is useful for things
 269         like the Math property. The Math object turns out to be very expensive to allocate.
 270         Delaying its allocation is super easy with the PropertyCallback attribute.
 271
 272         CellProperty: with this attribute the second column should be a C++ field name like
 273         JSGlobalObject::m_evalErrorConstructor. The static hashtable will grab the offset of
 274         this property, and when it needs to be initialized, Lookup will assume you have a
 275         LazyProperty<JSCell> and call its get() method. It will initialize the property to
 276         whatever get() returned. Note that it's legal to cast a LazyProperty<Anything> to
 277         LazyProperty<JSCell> for the purpose of calling get() because the get() method will just
 278         call whatever callback function pointer is encoded in the property and it does not need
 279         to know anything about what type that callback will instantiate.
 280
 281         ClassStructure: with this attribute the second column should be a C++ field name. The
 282         static hashtable will initialize the property by treating the field as a
 283         LazyClassStructure and it will call get(). LazyClassStructure completely owns the whole
 284         initialization workflow, so Lookup assumes that when LazyClassStructure::get() returns,
 285         the property in question will already be set. By convention, we have LazyClassStructure
 286         initialize the property with a pointer to the constructor, since that's how all of our
 287         classes work: "globalObject.Date" points to the DateConstructor.
 288
 289         This is a 2x speed-up in JSGlobalObject initialization time in a microbenchmark that
 290         calls our C API. This is a 1% speed-up on SunSpider and JSRegress.
 291
 292         Rolling this back in after fixing the function pointer alignment issue. The last version
 293         relied on function pointers being aligned to a 4-byte boundary. We cannot rely on this,
 294         especially since ARMv7 uses the low bit of function pointers as a tag to indicate the
 295         instruction set. This version adds an extra indirection, so that
 296         LazyProperty<>::m_pointer points to a pointer that points to the function. A pointer to
 297         a pointer is guaranteed to be at least 4-byte aligned.
 298
 299         * API/JSCallbackFunction.cpp:
 300         (JSC::JSCallbackFunction::create):
 301         * API/ObjCCallbackFunction.h:
 302         (JSC::ObjCCallbackFunction::impl):
 303         * API/ObjCCallbackFunction.mm:
 304         (JSC::ObjCCallbackFunction::ObjCCallbackFunction):
 305         (JSC::ObjCCallbackFunction::create):
 306         * CMakeLists.txt:
 307         * JavaScriptCore.xcodeproj/project.pbxproj:
 308         * create_hash_table:
 309         * debugger/DebuggerScope.cpp:
 310         (JSC::DebuggerScope::create):
 311         (JSC::DebuggerScope::DebuggerScope):
 312         * debugger/DebuggerScope.h:
 313         (JSC::DebuggerScope::jsScope):
 314         (JSC::DebuggerScope::create): Deleted.
 315         * dfg/DFGAbstractInterpreterInlines.h:
 316         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
 317         * dfg/DFGAbstractValue.cpp:
 318         (JSC::DFG::AbstractValue::set):
 319         * dfg/DFGArrayMode.cpp:
 320         (JSC::DFG::ArrayMode::originalArrayStructure):
 321         * dfg/DFGByteCodeParser.cpp:
 322         (JSC::DFG::ByteCodeParser::handleTypedArrayConstructor):
 323         * dfg/DFGSpeculativeJIT.cpp:
 324         (JSC::DFG::SpeculativeJIT::compileNewTypedArray):
 325         * dfg/DFGSpeculativeJIT32_64.cpp:
 326         (JSC::DFG::SpeculativeJIT::compile):
 327         * dfg/DFGSpeculativeJIT64.cpp:
 328         (JSC::DFG::SpeculativeJIT::compile):
 329         * dfg/DFGStructureRegistrationPhase.cpp:
 330         (JSC::DFG::StructureRegistrationPhase::run):
 331         * ftl/FTLLowerDFGToB3.cpp:
 332         (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
 333         * runtime/ClonedArguments.cpp:
 334         (JSC::ClonedArguments::getOwnPropertySlot):
 335         (JSC::ClonedArguments::materializeSpecials):
 336         * runtime/CommonSlowPaths.cpp:
 337         (JSC::SLOW_PATH_DECL):
 338         * runtime/FunctionPrototype.cpp:
 339         (JSC::functionProtoFuncToString):
 340         * runtime/InternalFunction.cpp:
 341         (JSC::InternalFunction::visitChildren):
 342         (JSC::InternalFunction::name):
 343         (JSC::InternalFunction::calculatedDisplayName):
 344         (JSC::InternalFunction::createSubclassStructure):
 345         * runtime/InternalFunction.h:
 346         * runtime/JSBoundFunction.cpp:
 347         (JSC::JSBoundFunction::finishCreation):
 348         (JSC::JSBoundFunction::visitChildren):
 349         * runtime/JSBoundSlotBaseFunction.cpp:
 350         (JSC::JSBoundSlotBaseFunction::create):
 351         * runtime/JSFunction.cpp:
 352         (JSC::retrieveCallerFunction):
 353         (JSC::getThrowTypeErrorGetterSetter):
 354         (JSC::JSFunction::callerGetter):
 355         (JSC::JSFunction::getOwnPropertySlot):
 356         (JSC::JSFunction::defineOwnProperty):
 357         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
 358         (JSC::constructGenericTypedArrayView):
 359         * runtime/JSGlobalObject.cpp:
 360         (JSC::createProxyProperty):
 361         (JSC::createJSONProperty):
 362         (JSC::createMathProperty):
 363         (JSC::JSGlobalObject::init):
 364         (JSC::JSGlobalObject::stringPrototypeChainIsSane):
 365         (JSC::JSGlobalObject::resetPrototype):
 366         (JSC::JSGlobalObject::visitChildren):
 367         (JSC::JSGlobalObject::toThis):
 368         (JSC::JSGlobalObject::getOwnPropertySlot):
 369         (JSC::JSGlobalObject::createThrowTypeError): Deleted.
 370         (JSC::JSGlobalObject::createThrowTypeErrorArgumentsAndCaller): Deleted.
 371         * runtime/JSGlobalObject.h:
 372         (JSC::JSGlobalObject::objectConstructor):
 373         (JSC::JSGlobalObject::promiseConstructor):
 374         (JSC::JSGlobalObject::internalPromiseConstructor):
 375         (JSC::JSGlobalObject::evalErrorConstructor):
 376         (JSC::JSGlobalObject::rangeErrorConstructor):
 377         (JSC::JSGlobalObject::referenceErrorConstructor):
 378         (JSC::JSGlobalObject::syntaxErrorConstructor):
 379         (JSC::JSGlobalObject::typeErrorConstructor):
 380         (JSC::JSGlobalObject::URIErrorConstructor):
 381         (JSC::JSGlobalObject::nullGetterFunction):
 382         (JSC::JSGlobalObject::nullSetterFunction):
 383         (JSC::JSGlobalObject::callFunction):
 384         (JSC::JSGlobalObject::applyFunction):
 385         (JSC::JSGlobalObject::definePropertyFunction):
 386         (JSC::JSGlobalObject::arrayProtoValuesFunction):
 387         (JSC::JSGlobalObject::initializePromiseFunction):
 388         (JSC::JSGlobalObject::newPromiseCapabilityFunction):
 389         (JSC::JSGlobalObject::functionProtoHasInstanceSymbolFunction):
 390         (JSC::JSGlobalObject::regExpProtoExecFunction):
 391         (JSC::JSGlobalObject::regExpProtoSymbolReplaceFunction):
 392         (JSC::JSGlobalObject::regExpProtoGlobalGetter):
 393         (JSC::JSGlobalObject::regExpProtoUnicodeGetter):
 394         (JSC::JSGlobalObject::throwTypeErrorGetterSetter):
 395         (JSC::JSGlobalObject::throwTypeErrorArgumentsAndCallerGetterSetter):
 396         (JSC::JSGlobalObject::moduleLoader):
 397         (JSC::JSGlobalObject::objectPrototype):
 398         (JSC::JSGlobalObject::functionPrototype):
 399         (JSC::JSGlobalObject::arrayPrototype):
 400         (JSC::JSGlobalObject::booleanPrototype):
 401         (JSC::JSGlobalObject::stringPrototype):
 402         (JSC::JSGlobalObject::symbolPrototype):
 403         (JSC::JSGlobalObject::numberPrototype):
 404         (JSC::JSGlobalObject::datePrototype):
 405         (JSC::JSGlobalObject::regExpPrototype):
 406         (JSC::JSGlobalObject::errorPrototype):
 407         (JSC::JSGlobalObject::iteratorPrototype):
 408         (JSC::JSGlobalObject::generatorFunctionPrototype):
 409         (JSC::JSGlobalObject::generatorPrototype):
 410         (JSC::JSGlobalObject::debuggerScopeStructure):
 411         (JSC::JSGlobalObject::withScopeStructure):
 412         (JSC::JSGlobalObject::strictEvalActivationStructure):
 413         (JSC::JSGlobalObject::activationStructure):
 414         (JSC::JSGlobalObject::moduleEnvironmentStructure):
 415         (JSC::JSGlobalObject::directArgumentsStructure):
 416         (JSC::JSGlobalObject::scopedArgumentsStructure):
 417         (JSC::JSGlobalObject::clonedArgumentsStructure):
 418         (JSC::JSGlobalObject::isOriginalArrayStructure):
 419         (JSC::JSGlobalObject::booleanObjectStructure):
 420         (JSC::JSGlobalObject::callbackConstructorStructure):
 421         (JSC::JSGlobalObject::callbackFunctionStructure):
 422         (JSC::JSGlobalObject::callbackObjectStructure):
 423         (JSC::JSGlobalObject::propertyNameIteratorStructure):
 424         (JSC::JSGlobalObject::objcCallbackFunctionStructure):
 425         (JSC::JSGlobalObject::objcWrapperObjectStructure):
 426         (JSC::JSGlobalObject::dateStructure):
 427         (JSC::JSGlobalObject::nullPrototypeObjectStructure):
 428         (JSC::JSGlobalObject::errorStructure):
 429         (JSC::JSGlobalObject::calleeStructure):
 430         (JSC::JSGlobalObject::functionStructure):
 431         (JSC::JSGlobalObject::boundFunctionStructure):
 432         (JSC::JSGlobalObject::boundSlotBaseFunctionStructure):
 433         (JSC::JSGlobalObject::getterSetterStructure):
 434         (JSC::JSGlobalObject::nativeStdFunctionStructure):
 435         (JSC::JSGlobalObject::namedFunctionStructure):
 436         (JSC::JSGlobalObject::functionNameOffset):
 437         (JSC::JSGlobalObject::numberObjectStructure):
 438         (JSC::JSGlobalObject::privateNameStructure):
 439         (JSC::JSGlobalObject::mapStructure):
 440         (JSC::JSGlobalObject::regExpStructure):
 441         (JSC::JSGlobalObject::generatorFunctionStructure):
 442         (JSC::JSGlobalObject::setStructure):
 443         (JSC::JSGlobalObject::stringObjectStructure):
 444         (JSC::JSGlobalObject::symbolObjectStructure):
 445         (JSC::JSGlobalObject::iteratorResultObjectStructure):
 446         (JSC::JSGlobalObject::lazyTypedArrayStructure):
 447         (JSC::JSGlobalObject::typedArrayStructure):
 448         (JSC::JSGlobalObject::typedArrayStructureConcurrently):
 449         (JSC::JSGlobalObject::isOriginalTypedArrayStructure):
 450         (JSC::JSGlobalObject::typedArrayConstructor):
 451         (JSC::JSGlobalObject::actualPointerFor):
 452         (JSC::JSGlobalObject::internalFunctionStructure): Deleted.
 453         * runtime/JSNativeStdFunction.cpp:
 454         (JSC::JSNativeStdFunction::create):
 455         * runtime/JSWithScope.cpp:
 456         (JSC::JSWithScope::create):
 457         (JSC::JSWithScope::visitChildren):
 458         (JSC::JSWithScope::createStructure):
 459         (JSC::JSWithScope::JSWithScope):
 460         * runtime/JSWithScope.h:
 461         (JSC::JSWithScope::object):
 462         (JSC::JSWithScope::create): Deleted.
 463         (JSC::JSWithScope::createStructure): Deleted.
 464         (JSC::JSWithScope::JSWithScope): Deleted.
 465         * runtime/LazyClassStructure.cpp: Added.
 466         (JSC::LazyClassStructure::Initializer::Initializer):
 467         (JSC::LazyClassStructure::Initializer::setPrototype):
 468         (JSC::LazyClassStructure::Initializer::setStructure):
 469         (JSC::LazyClassStructure::Initializer::setConstructor):
 470         (JSC::LazyClassStructure::visit):
 471         (JSC::LazyClassStructure::dump):
 472         * runtime/LazyClassStructure.h: Added.
 473         (JSC::LazyClassStructure::LazyClassStructure):
 474         (JSC::LazyClassStructure::get):
 475         (JSC::LazyClassStructure::prototype):
 476         (JSC::LazyClassStructure::constructor):
 477         (JSC::LazyClassStructure::getConcurrently):
 478         (JSC::LazyClassStructure::prototypeConcurrently):
 479         (JSC::LazyClassStructure::constructorConcurrently):
 480         * runtime/LazyClassStructureInlines.h: Added.
 481         (JSC::LazyClassStructure::initLater):
 482         * runtime/LazyProperty.h: Added.
 483         (JSC::LazyProperty::Initializer::Initializer):
 484         (JSC::LazyProperty::LazyProperty):
 485         (JSC::LazyProperty::get):
 486         (JSC::LazyProperty::getConcurrently):
 487         * runtime/LazyPropertyInlines.h: Added.
 488         (JSC::ElementType>::Initializer::set):
 489         (JSC::ElementType>::initLater):
 490         (JSC::ElementType>::setMayBeNull):
 491         (JSC::ElementType>::set):
 492         (JSC::ElementType>::visit):
 493         (JSC::ElementType>::dump):
 494         (JSC::ElementType>::callFunc):
 495         * runtime/Lookup.cpp:
 496         (JSC::setUpStaticFunctionSlot):
 497         * runtime/Lookup.h:
 498         (JSC::HashTableValue::function):
 499         (JSC::HashTableValue::functionLength):
 500         (JSC::HashTableValue::propertyGetter):
 501         (JSC::HashTableValue::propertyPutter):
 502         (JSC::HashTableValue::accessorGetter):
 503         (JSC::HashTableValue::accessorSetter):
 504         (JSC::HashTableValue::constantInteger):
 505         (JSC::HashTableValue::lexerValue):
 506         (JSC::HashTableValue::lazyCellPropertyOffset):
 507         (JSC::HashTableValue::lazyClassStructureOffset):
 508         (JSC::HashTableValue::lazyPropertyCallback):
 509         (JSC::getStaticPropertySlot):
 510         (JSC::getStaticValueSlot):
 511         (JSC::putEntry):
 512         (JSC::reifyStaticProperty):
 513         * runtime/PropertySlot.h:
 514         * runtime/TypedArrayType.h:
 515
 516 2016-05-04  Joseph Pecoraro  <pecoraro@apple.com>
 517
 518         Improve the grammar of some error messages 'a argument list' => 'an argument list'
 519         https://bugs.webkit.org/show_bug.cgi?id=157350
 520         <rdar://problem/26082108>
 521
 522         Reviewed by Mark Lam.
 523
 524         * parser/Parser.cpp:
 525         (JSC::Parser<LexerType>::parseIfStatement):
 526         (JSC::Parser<LexerType>::parseImportDeclaration):
 527         (JSC::Parser<LexerType>::parseExportDeclaration):
 528         (JSC::Parser<LexerType>::parseObjectLiteral):
 529         (JSC::Parser<LexerType>::parseStrictObjectLiteral):
 530         (JSC::Parser<LexerType>::parseArguments):
 531         Use the alternate error message formatter macro which outputs 'an'
 532         instead of 'a' preceding the last argument.
 533
 534 2016-05-04  Keith Miller  <keith_miller@apple.com>
 535
 536         Corrections to r200422
 537         https://bugs.webkit.org/show_bug.cgi?id=157351
 538
 539         Reviewed by Joseph Pecoraro.
 540
 541         Fix some typos in various files. Also, make separate error messages
 542         for the this value being undefined vs null in the ArrayIteratorprototype
 543         next function and add test.
 544
 545         * Scripts/builtins/builtins_model.py:
 546         * builtins/ArrayIteratorPrototype.js:
 547         (next):
 548         (arrayIteratorValueNext):
 549         (arrayIteratorKeyNext):
 550         (arrayIteratorKeyValueNext):
 551         * builtins/ArrayPrototype.js:
 552         (keys):
 553         (entries):
 554         * builtins/TypedArrayPrototype.js:
 555         * runtime/JSGlobalObject.cpp:
 556         (JSC::JSGlobalObject::init): Deleted.
 557         * tests/stress/array-iterators-next-error-messages.js: Added.
 558         (assert):
 559         (catch):
 560
 561 2016-05-04  Keith Miller  <keith_miller@apple.com>
 562
 563         Unreviewed, reland r200149 since the rollout had inconclusive PLT AB testing results.
 564
 565 2016-05-04  Mark Lam  <mark.lam@apple.com>
 566
 567         ES6 Function.name inferred from property names of literal objects can break some websites.
 568         https://bugs.webkit.org/show_bug.cgi?id=157246
 569
 570         Reviewed by Geoffrey Garen.
 571
 572         Specifically, the library mathjs (see http://mathjs.org and https://github.com/josdejong/mathjs)
 573         uses an idiom where it created literal objects with property names that look like
 574         this: 'number | BigNumber | Unit'.  Later, this name is used in a string to create
 575         function source code that gets eval'ed.  Since 'number | BigNumber | Unit' is not
 576         a valid function name, we get a syntax error.
 577
 578         Here are the details:
 579
 580         1. mathjs uses object literals with the funky property names for its function members.
 581            For example,
 582
 583               // helper function to type check the middle value of the array
 584               var middle = typed({
 585                 'number | BigNumber | Unit': function (value) {
 586                   return value;
 587                 }
 588               });
 589
 590         2. mathjs' getName() uses Function.name to get the name of functions (hence, picks
 591            up the property name as inferred value of Function.name as specified by ES6):
 592
 593                 /**
 594                  * Retrieve the function name from a set of functions, and check
 595                  * whether the name of all functions match (if given)
 596                  ...
 597                  */
 598                 function getName (fns) {
 599                   var name = '';
 600
 601                   for (var i = 0; i < fns.length; i++) {
 602                     var fn = fns[i];
 603                     ...
 604                         name = fn.name;
 605                     ...
 606                   return name;
 607                 }
 608
 609         3. mathjs uses that name to assembler new function source code that gets eval'ed:
 610
 611                 /**
 612                  * Compose a function from sub-functions each handling a single type signature.
 613                  ...
 614                  */
 615                 function _typed(name, signatures) {
 616                   ...
 617                   // generate code for the typed function
 618                   var code = [];
 619                   var _name = name || '';
 620                   ...
 621                   code.push('function ' + _name + '(' + _args.join(', ') + ') {');
 622                   code.push('  "use strict";');
 623                   code.push('  var name = \'' + _name + '\';');
 624                   code.push(node.toCode(refs, '  '));
 625                   code.push('}');
 626
 627                   // generate body for the factory function
 628                   var body = [
 629                     refs.toCode(),
 630                     'return ' + code.join('\n')
 631                   ].join('\n');
 632
 633                   // evaluate the JavaScript code and attach function references
 634                   var factory = (new Function(refs.name, 'createError', body));  // <== Syntax Error here!
 635                   var fn = factory(refs, createError);
 636                   ...
 637                   return fn;
 638                 }
 639
 640         Until mathjs (and any other frameworks that does similar things) and sites that
 641         uses mathjs has been updated to work with ES6, we'll need a compatibility hack to
 642         work around it.
 643
 644         Here's what we'll do:
 645         1. Introduce a needsSiteSpecificQuirks flag in JSGlobalObject.
 646         2. Have WebCore's JSDOMWindowBase set that flag if the browser's
 647            needsSiteSpecificQuirks is enabled in its settings.
 648         3. If needsSiteSpecificQuirks is enabled, have JSFunction::reifyName() check for
 649            ' ' or '|' in the name string it will use to reify the Function.name property.
 650            If those characters exists in the name, we'll replace the name string with a
 651            null string.
 652
 653         * runtime/JSFunction.cpp:
 654         (JSC::JSFunction::reifyName):
 655         * runtime/JSGlobalObject.h:
 656         (JSC::JSGlobalObject::needsSiteSpecificQuirks):
 657         (JSC::JSGlobalObject::GlobalPropertyInfo::GlobalPropertyInfo):
 658         (JSC::JSGlobalObject::setNeedsSiteSpecificQuirks):
 659
 660 2016-05-04  Keith Miller  <keith_miller@apple.com>
 661
 662         Speedup array iterators
 663         https://bugs.webkit.org/show_bug.cgi?id=157315
 664
 665         Reviewed by Michael Saboff.
 666
 667         This patch improves the performance of Array iterators in ES6. There are two main changes
 668         that make things faster. The first is that the value, keys and entries functions have been
 669         moved to JS. This enables us to inline the construction of the iterator. Thus, when we get
 670         to the FTL we are able to sink the allocation of the iterator object. This significantly
 671         improves the performance of any for-of loop since we are now able to have both the iteration
 672         counter and the iterated object in local variables rather than in the heap.
 673
 674         Secondly, instead of using a number to store the iteratation kind we now use a virtual
 675         method on the iteration object to indicate which next function to use. This ends up being
 676         helpful because it means we can eliminate the branches in the old next function that decide
 677         what value to return. With those branches gone the various next functions are now small
 678         enough to inline. Once the next functions are inlined then the FTL is able to sink the
 679         allocation of next() result object. There is still room for optimization in the loop since
 680         we currently don't recognize that the array access in the next function is in bounds or that
 681         the increment to the loop counter cannot overflow.
 682
 683         The overall performance changes appear to be a ~4-6x speedup in a simple microbenchmark that
 684         computes the sum of an array with some extra arithmetic. The variance depends on the exact
 685         body of the loop. Additionally, on a new regress test that changes all the loops in
 686         deltablue into for-of loops this patch is a 1.8x progression. Overall, it still looks like
 687         for-of loops are significantly slower than an indexed for loop. In the first test it's ~2-4x
 688         slower with the difference depending on the body of the loop. If the loop is just the sum
 689         then we see a much larger regression than if the loop does even simple arithmetic. It looks
 690         like the indexed for loop without extra arithmetic is small enough to fit into the x86
 691         replay buffer on my machine, which would explain why there is such a big difference between
 692         the for of loop in that case. On the deltablue benchmark it's 1.4x slower. It's clear from
 693         these numbers that there is still a lot of work we can do to make for of loops faster.
 694
 695         This patch also makes some changes to the way that we decorate our builtin js
 696         functions. Instead of the old syntax (putting the decorated values in [] before the function
 697         declaration i.e. [intrinsic=foo]) this patch changes the syntax to be closer to the way that
 698         decorators are proposed in a future ECMAScript proposal (using @ followed by the entry on a
 699         new line before the function declaration i.e. @intrinsic=foo).
 700
 701         Finally, in the builtin scripts regular expressions re.S has been changed to re.DOTALL since
 702         DOTALL is easier to understand without going to the reference page for python regular
 703         expressions.
 704
 705         * Scripts/builtins/builtins_model.py:
 706         * builtins/ArrayIteratorPrototype.js:
 707         (next):
 708         (arrayIteratorValueNext):
 709         (arrayIteratorKeyNext):
 710         (arrayIteratorKeyValueNext):
 711         * builtins/ArrayPrototype.js:
 712         (createArrayIterator):
 713         (values):
 714         (keys):
 715         (entries):
 716         * builtins/RegExpPrototype.js:
 717         (intrinsic.RegExpTestIntrinsic.test):
 718         * builtins/StringPrototype.js:
 719         (intrinsic.StringPrototypeReplaceIntrinsic.replace):
 720         * builtins/TypedArrayPrototype.js:
 721         (values):
 722         (keys):
 723         (entries):
 724         * inspector/JSInjectedScriptHost.cpp:
 725         (Inspector::cloneArrayIteratorObject):
 726         (Inspector::JSInjectedScriptHost::iteratorEntries):
 727         * jit/ThunkGenerators.cpp:
 728         * runtime/ArrayPrototype.cpp:
 729         (JSC::ArrayPrototype::finishCreation):
 730         (JSC::arrayProtoFuncValues): Deleted.
 731         (JSC::arrayProtoFuncEntries): Deleted.
 732         (JSC::arrayProtoFuncKeys): Deleted.
 733         * runtime/CommonIdentifiers.h:
 734         * runtime/JSArrayIterator.cpp:
 735         (JSC::JSArrayIterator::clone): Deleted.
 736         * runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
 737         (JSC::genericTypedArrayViewProtoFuncEntries): Deleted.
 738         (JSC::genericTypedArrayViewProtoFuncKeys): Deleted.
 739         (JSC::typedArrayViewProtoFuncValues): Deleted.
 740         * runtime/JSGlobalObject.cpp:
 741         (JSC::JSGlobalObject::init):
 742         * runtime/JSGlobalObject.h:
 743         * runtime/JSTypedArrayViewPrototype.cpp:
 744         (JSC::JSTypedArrayViewPrototype::finishCreation):
 745         (JSC::typedArrayViewProtoFuncEntries): Deleted.
 746         (JSC::typedArrayViewProtoFuncKeys): Deleted.
 747         (JSC::typedArrayViewProtoFuncValues): Deleted.
 748         * runtime/MapPrototype.cpp:
 749         (JSC::MapPrototype::finishCreation):
 750         * runtime/SetPrototype.cpp:
 751         (JSC::SetPrototype::finishCreation):
 752
 753 2016-05-04  Yusuke Suzuki  <utatane.tea@gmail.com>
 754
 755         [JSC] Object constructor need to be aware of new.target
 756         https://bugs.webkit.org/show_bug.cgi?id=157196
 757
 758         Reviewed by Darin Adler.
 759
 760         Object constructor should be aware of new.target.
 761         When the new.target is specified, we should store it.prototype to the newly created
 762         object's [[Prototype]].
 763
 764         * runtime/JSGlobalObject.cpp:
 765         (JSC::JSGlobalObject::init):
 766         (JSC::JSGlobalObject::visitChildren):
 767         Take the design that caches the structure used for empty object.
 768         This structure is also used in constructEmptyObject frequently.
 769
 770         * runtime/JSGlobalObject.h:
 771         (JSC::JSGlobalObject::objectStructureForObjectConstructor):
 772         * runtime/ObjectConstructor.cpp:
 773         (JSC::constructObject):
 774         (JSC::constructWithObjectConstructor):
 775         (JSC::callObjectConstructor):
 776         * runtime/ObjectConstructor.h:
 777         (JSC::constructEmptyObject):
 778         Construct the object by using the plain structure that is also used in the ObjectConstructor.
 779
 780         * tests/stress/object-constructor-should-be-new-target-aware.js: Added.
 781         (shouldBe):
 782         (Hello):
 783
 784 2016-05-04  Chris Dumez  <cdumez@apple.com>
 785
 786         Unreviewed, rolling out r200383 and r200406.
 787
 788         Seems to have caused crashes on iOS / ARMv7s
 789
 790         Reverted changesets:
 791
 792         "Speed up JSGlobalObject initialization by making some
 793         properties lazy"
 794         https://bugs.webkit.org/show_bug.cgi?id=157045
 795         http://trac.webkit.org/changeset/200383
 796
 797         "REGRESSION(r200383): Setting lazily initialized properties
 798         across frame boundaries crashes"
 799         https://bugs.webkit.org/show_bug.cgi?id=157333
 800         http://trac.webkit.org/changeset/200406
 801
 802 2016-05-04  Yusuke Suzuki  <utatane.tea@gmail.com>
 803
 804         Assertion failure for super() call in direct eval in method function
 805         https://bugs.webkit.org/show_bug.cgi?id=157091
 806
 807         Reviewed by Darin Adler.
 808
 809         While we ensure that direct super is under the correct context,
 810         we don't check it for the eval code. This patch moves the check from the end of parsing the function
 811         to the places where we found the direct super or the super bindings. This covers the direct eval that
 812         contains the direct super calls.
 813
 814         * parser/Parser.cpp:
 815         (JSC::Parser<LexerType>::parseGeneratorFunctionSourceElements):
 816         (JSC::Parser<LexerType>::parseFunctionInfo):
 817         (JSC::Parser<LexerType>::parseMemberExpression):
 818         * parser/Parser.h:
 819         (JSC::Scope::hasDirectSuper):
 820         (JSC::Scope::setHasDirectSuper):
 821         (JSC::Scope::needsSuperBinding):
 822         (JSC::Scope::setNeedsSuperBinding):
 823         (JSC::Parser::closestParentOrdinaryFunctionNonLexicalScope):
 824         * tests/stress/eval-and-super.js: Added.
 825         (shouldBe):
 826         (shouldThrow):
 827         (prototype.m):
 828         (prototype.n):
 829         * tests/stress/generator-and-super.js: Added.
 830         (testSyntaxError):
 831         (testSyntaxError.Base.prototype.hello):
 832         (testSyntaxError.Base.prototype.ok):
 833         (testSyntaxError.Base):
 834         (Hello.prototype.gen):
 835         (Hello):
 836         (testSyntaxError.hello):
 837
 838 2016-05-03  Filip Pizlo  <fpizlo@apple.com>
 839
 840         REGRESSION(r200383): Setting lazily initialized properties across frame boundaries crashes
 841         https://bugs.webkit.org/show_bug.cgi?id=157333
 842
 843         Reviewed by Benjamin Poulain.
 844
 845         I forgot to add logic for lazy properties in putEntry(). It turns out that it's easy to
 846         add.
 847
 848         * runtime/Lookup.h:
 849         (JSC::putEntry):
 850         * runtime/PropertySlot.h:
 851
 852 2016-05-03  Filip Pizlo  <fpizlo@apple.com>
 853
 854         References from code to Structures should be stronger than weak
 855         https://bugs.webkit.org/show_bug.cgi?id=157324
 856
 857         Reviewed by Mark Lam.
 858
 859         If code refers to a Structure and the Structure dies, then previously we'd kill the code.
 860         This makes sense because the Structure could be the only thing left referring to some global
 861         object or prototype.
 862
 863         But this also causes unnecessary churn. Sometimes there will be a structure that we just
 864         haven't really done anything with recently and so it appears dead. The approach we use
 865         elsewhere in our type inference is that the type that the code uses is general enough to
 866         handle every past execution. Having the GC clear code when some Structure it uses dies means
 867         that we forget that the code used that Structure. We'll either assume that the code is more
 868         monomorphic than it really is (because after GC we patch in some other structure but not the
 869         deleted one, so it looks like we only ever saw the new structure), or we'll assume that it's
 870         crazier than it really is (because we'll remember that there had been some structure that
 871         caused deletion, so we'll assume that deletions might happen in the future, so we'll use a
 872         fully dynamic IC).
 873
 874         This change introduces a more nuanced policy: if it's cheap to mark a dead Structure then we
 875         should mark it just so that all of the code that refers to it remembers that there had been
 876         this exact Structure in the past. If the code often goes through different Structures then
 877         we already have great mechanisms to realize that the code is nutty (namely, the
 878         PolymorphicAccess size limit). But if the code just does this a handful of times then
 879         remembering this old Structure is probably net good:
 880
 881         - It obeys the "handle all past executions" law.
 882         - It preserves the history of the property access, allowing a precise measure of its past
 883           polymorphism.
 884         - It makes the code ready to run fast if the user decides to use that Structure again.
 885           Marking the Structure means it will stay in whatever property transition tables it was in,
 886           so if the program does the same thing it did in the past, it will get this old Structure.
 887
 888         It looks like this is a progression in gbemu and it makes gbemu perform more
 889         deterministically. Also, it seems that this makes JetStream run faster.
 890
 891         Over five in-browser runs of JetStream, here's what we see before and after:
 892
 893         Geometric Mean:
 894             Before              After
 895             229.23 +- 8.2523    230.70 +- 12.888
 896             232.91 +- 15.638    239.04 +- 13.766
 897             234.79 +- 12.760    236.32 +- 15.562
 898             236.20 +- 23.125    242.02 +- 3.3865
 899             237.22 +- 2.1929    237.23 +- 17.664
 900
 901         Just gbemu:
 902             Before              After
 903             541.0 +- 135.8      481.7 +- 143.4
 904             518.9 +- 15.65      508.1 +- 136.3
 905             362.5 +- 0.8884     489.7 +- 101.4
 906             470.7 +- 313.3      530.7 +- 11.49
 907             418.7 +- 180.6      537.2 +- 6.514
 908
 909         Notice that there is plenty of noise before and after, but the noise is now far less severe.
 910         After this change I did not see any runs like "470.7 +- 313.3" where the size of the
 911         confidence interval (313.3 * 2) is greater than the score (470.7). Also, notice that the
 912         least noisy run before the change also got a lower score than we ever observed after the
 913         change (36.5 +- 0.8884). The noise, and these occasional very low scores, are due to a
 914         pathology where the GC would reset some stubs at an unfortunate time during profiling,
 915         causing the optimizing compiler to make many poor decisions. That pathology doesn't exist
 916         anymore.
 917
 918         On the other hand, prior to this change it was possible for gbemu to sometimes run sooooper
 919         fast because the GC would cause the profiler to forget gbemu's behavior on the first tick
 920         and focus only on its behavior in subsequent ticks. So, in steady state, we'd optimize gbemu
 921         for its later behavior rather than a combination of its early behavior and later behavior.
 922         We rarely got lucky this way, so it's not fair to view this quirk as a feature.
 923
 924         * bytecode/CodeBlock.cpp:
 925         (JSC::CodeBlock::propagateTransitions):
 926         * bytecode/PolymorphicAccess.cpp:
 927         (JSC::AccessCase::visitWeak):
 928         (JSC::AccessCase::propagateTransitions):
 929         (JSC::AccessCase::generateWithGuard):
 930         (JSC::PolymorphicAccess::visitWeak):
 931         (JSC::PolymorphicAccess::propagateTransitions):
 932         (JSC::PolymorphicAccess::dump):
 933         * bytecode/PolymorphicAccess.h:
 934         * bytecode/StructureStubInfo.cpp:
 935         (JSC::StructureStubInfo::visitWeakReferences):
 936         (JSC::StructureStubInfo::propagateTransitions):
 937         (JSC::StructureStubInfo::containsPC):
 938         * bytecode/StructureStubInfo.h:
 939         (JSC::StructureStubInfo::considerCaching):
 940         * runtime/Structure.cpp:
 941         (JSC::Structure::visitChildren):
 942         (JSC::Structure::isCheapDuringGC):
 943         (JSC::Structure::markIfCheap):
 944         (JSC::Structure::prototypeChainMayInterceptStoreTo):
 945         * runtime/Structure.h:
 946
 947 2016-05-03  Joseph Pecoraro  <pecoraro@apple.com>
 948
 949         Web Inspector: Simplify console.clear
 950         https://bugs.webkit.org/show_bug.cgi?id=157316
 951
 952         Reviewed by Timothy Hatcher.
 953
 954         * inspector/ScriptArguments.cpp:
 955         (Inspector::ScriptArguments::createEmpty):
 956         (Inspector::ScriptArguments::ScriptArguments):
 957         * inspector/ScriptArguments.h:
 958         Provide a way to create an empty list.
 959
 960         * runtime/ConsoleClient.cpp:
 961         (JSC::ConsoleClient::clear):
 962         * runtime/ConsoleClient.h:
 963         Drop unnecessary parameter.
 964
 965         * runtime/ConsoleObject.cpp:
 966         (JSC::consoleProtoFuncClear):
 967         No need to parse arguments.
 968
 969 2016-05-03  Yusuke Suzuki  <utatane.tea@gmail.com>
 970
 971         Improve Symbol() to string coercion error message
 972         https://bugs.webkit.org/show_bug.cgi?id=157317
 973
 974         Reviewed by Geoffrey Garen.
 975
 976         Improve error messages related to Symbols.
 977
 978         * runtime/JSCJSValue.cpp:
 979         (JSC::JSValue::toStringSlowCase):
 980         * runtime/Symbol.cpp:
 981         (JSC::Symbol::toNumber):
 982         * runtime/SymbolConstructor.cpp:
 983         (JSC::symbolConstructorKeyFor):
 984         * runtime/SymbolPrototype.cpp:
 985         (JSC::symbolProtoFuncToString):
 986         (JSC::symbolProtoFuncValueOf):
 987         * tests/stress/dfg-to-primitive-pass-symbol.js:
 988         * tests/stress/floating-point-div-to-mul.js:
 989         (i.catch):
 990         * tests/stress/string-from-code-point.js:
 991         (shouldThrow):
 992         (string_appeared_here.shouldThrow):
 993         * tests/stress/symbol-error-messages.js: Added.
 994         (shouldThrow):
 995         * tests/stress/symbol-registry.js:
 996
 997 2016-05-03  Joseph Pecoraro  <pecoraro@apple.com>
 998
 999         Web Inspector: Give console.time/timeEnd a default label and warnings
1000         https://bugs.webkit.org/show_bug.cgi?id=157325
1001         <rdar://problem/26073290>
1002
1003         Reviewed by Timothy Hatcher.
1004
1005         Provide more user friendly console.time/timeEnd. The timer name
1006         is now optional, and is "default" if not provided. Also provide
1007         warnings when attempting to start an already started timer,
1008         or stop a timer that does not exist.
1009
1010         * inspector/agents/InspectorConsoleAgent.cpp:
1011         (Inspector::InspectorConsoleAgent::startTiming):
1012         (Inspector::InspectorConsoleAgent::stopTiming):
1013         Warnings for bad cases.
1014
1015         * runtime/ConsoleObject.cpp:
1016         (JSC::defaultLabelString):
1017         (JSC::consoleProtoFuncTime):
1018         (JSC::consoleProtoFuncTimeEnd):
1019         Optional label becomes "default".
1020
1021 2016-05-03  Xan Lopez  <xlopez@igalia.com>
1022
1023         Fix the ENABLE(WEBASSEMBLY) build
1024         https://bugs.webkit.org/show_bug.cgi?id=157312
1025
1026         Reviewed by Darin Adler.
1027
1028         * runtime/Executable.cpp:
1029         (JSC::WebAssemblyExecutable::WebAssemblyExecutable):
1030         * wasm/WASMFunctionCompiler.h:
1031         (JSC::WASMFunctionCompiler::convertValueToDouble):
1032
1033 2016-05-03  Joseph Pecoraro  <pecoraro@apple.com>
1034
1035         Web Inspector: Remove unused parameter of ScriptArguments::getFirstArgumentAsString
1036         https://bugs.webkit.org/show_bug.cgi?id=157301
1037
1038         Reviewed by Timothy Hatcher.
1039
1040         * inspector/ScriptArguments.cpp:
1041         (Inspector::ScriptArguments::getFirstArgumentAsString):
1042         * inspector/ScriptArguments.h:
1043         Remove unused argument and related code.
1044
1045         * runtime/ConsoleClient.cpp:
1046         (JSC::ConsoleClient::printConsoleMessageWithArguments):
1047         Drive by remove unnecessary cast.
1048
1049 2016-05-03  Michael Saboff  <msaboff@apple.com>
1050
1051         Crash: Array.prototype.slice() and .splice() can call fastSlice() after an array is truncated
1052         https://bugs.webkit.org/show_bug.cgi?id=157322
1053
1054         Reviewed by Filip Pizlo.
1055
1056         Check to see if the source array has changed length before calling fastSlice().
1057         If it has, take the slow path.
1058
1059         * runtime/ArrayPrototype.cpp:
1060         (JSC::arrayProtoFuncSlice):
1061         (JSC::arrayProtoFuncSplice):
1062         * tests/stress/regress-157322.js: New test.
1063
1064 2016-05-03  Joseph Pecoraro  <pecoraro@apple.com>
1065
1066         Eliminate PassRefPtr conversion from ConsoleObject
1067         https://bugs.webkit.org/show_bug.cgi?id=157300
1068
1069         Reviewed by Timothy Hatcher.
1070
1071         * runtime/ConsoleObject.cpp:
1072         (JSC::consoleLogWithLevel):
1073         (JSC::consoleProtoFuncClear):
1074         (JSC::consoleProtoFuncDir):
1075         (JSC::consoleProtoFuncDirXML):
1076         (JSC::consoleProtoFuncTable):
1077         (JSC::consoleProtoFuncTrace):
1078         (JSC::consoleProtoFuncAssert):
1079         (JSC::consoleProtoFuncCount):
1080         (JSC::consoleProtoFuncTimeStamp):
1081         (JSC::consoleProtoFuncGroup):
1082         (JSC::consoleProtoFuncGroupCollapsed):
1083         (JSC::consoleProtoFuncGroupEnd):
1084         No need to release to a PassRefPtr, we can just move into the RefPtr<>&&.
1085
1086 2016-05-01  Filip Pizlo  <fpizlo@apple.com>
1087
1088         Speed up JSGlobalObject initialization by making some properties lazy
1089         https://bugs.webkit.org/show_bug.cgi?id=157045
1090
1091         Reviewed by Keith Miller.
1092
1093         This makes about half of JSGlobalObject's state lazy. There are three categories of
1094         state in JSGlobalObject:
1095
1096         1) C++ fields in JSGlobalObject.
1097         2) JS object properties in JSGlobalObject's JSObject superclass.
1098         3) JS variables in JSGlobalObject's JSSegmentedVariableObject superclass.
1099
1100         State held in JS variables cannot yet be made lazy. That's why this patch only goes
1101         half-way.
1102
1103         State in JS object properties can be made lazy if we move it to the static property
1104         hashtable. JSGlobalObject already had one of those. This patch makes static property
1105         hashtables a lot more powerful, by adding three new kinds of static properties. These
1106         new kinds allow us to make almost all of JSGlobalObject's object properties lazy.
1107
1108         State in C++ fields can now be made lazy thanks in part to WTF's support for stateless
1109         lambdas. You can of course make anything lazy by hand, but there are many C++ fields in
1110         JSGlobalObject and we are adding more all the time. We don't want to require that each
1111         of these has a getter with an initialization check and a corresponding out-of-line slow
1112         path that does the initialization. We want this kind of boilerplate to be handled by
1113         some abstractions.
1114
1115         The primary abstraction introduced in this patch is LazyProperty<Type>. Currently, this
1116         only works where Type is a subclass of JSCell. Such a property holds a pointer to Type.
1117         You can use it like you would a WriteBarrier<Type>. It even has set() and get() methods,
1118         so it's almost a drop-in replacement.
1119
1120         The key to LazyProperty<Type>'s power is that you can do this:
1121
1122             class Bar {
1123                 ...
1124                 LazyProperty<Foo> m_foo;
1125             };
1126             ...
1127             m_foo.initLater(
1128                 [] (const LazyProperty<Foo>::Initializer<Bar>& init) {
1129                     init.set(Foo::create(init.vm, init.owner));
1130                 });
1131
1132         This initLater() call requires that you pass a stateless lambda (see WTF changelog for
1133         the definition). Miraculously, this initLater() call is guaranteed to compile to a store
1134         of a pointer constant to m_foo, as in:
1135
1136             movabsq 0xBLAH, %rax
1137             movq %rax, &m_foo
1138
1139         This magical pointer constant points to a callback that was generated by the template
1140         instantiation of initLater(). That callback knows to call your stateless lambda, but
1141         also does some other bookkeeping: it makes sure that you indeed initialized the property
1142         inside the callback and it manages recursive initializations. It's totally legal to call
1143         m_foo.get() inside the initLater() callback. If you do that before you call init.set(),
1144         m_foo.get() will return null. This is an excellent escape hatch if we ever find
1145         ourselves in a dependency cycle. I added this feature because I already had to create a
1146         dependency cycle.
1147
1148         Note that using LazyProperties from DFG threads is super awkward. It's going to be hard
1149         to get this right. The DFG thread cannot initialize those fields, so it has to make sure
1150         that it does conservative things. But for some nodes this could mean adding a lot of new
1151         logic, like NewTypedArray, which currently is written in such a way that it assumes that
1152         we always have the typed array structure. Currently we take a two-fold approach: for
1153         typed arrays we don't handle the NewTypedArray intrinsic if the structure isn't
1154         initialized, and for everything else we don't make the properties lazy if the DFG needs
1155         them. As we optimize this further we might need to teach the DFG to handle more lazy
1156         properties. I tried to do this for RegExp but found it to be very confusing. With typed
1157         arrays I got lucky.
1158
1159         There is also a somewhat more powerful construct called LazyClassStructure. We often
1160         need to keep around the structure of some standard JS class, like Date. We also need to
1161         make sure that the constructor ends up in the global object's property table. And we
1162         often need to keep the original value of the constructor for ourselves. In this case, we
1163         want to make sure that the creation of the structure-prototype-constructor constellation
1164         is atomic. We don't want code to start looking at the structure if it points to a
1165         prototype that doesn't have its "constructor" property set yet, for example.
1166         LazyClassStructure solves this by abstracting that whole initialization. You provide the
1167         callback that allocates everything, since we are super inconsistent about the way we
1168         initialize things, but LazyClassStructure establishes the workflow and helps you not
1169         mess up.
1170
1171         Finally, the new static hashtable attributes allow for all of this to work with the JS
1172         property table:
1173
1174         PropertyCallback: if you use this attribute, the second column in the table should be
1175         the name of a function to call to initialize this property. This is useful for things
1176         like the Math property. The Math object turns out to be very expensive to allocate.
1177         Delaying its allocation is super easy with the PropertyCallback attribute.
1178
1179         CellProperty: with this attribute the second column should be a C++ field name like
1180         JSGlobalObject::m_evalErrorConstructor. The static hashtable will grab the offset of
1181         this property, and when it needs to be initialized, Lookup will assume you have a
1182         LazyProperty<JSCell> and call its get() method. It will initialize the property to
1183         whatever get() returned. Note that it's legal to cast a LazyProperty<Anything> to
1184         LazyProperty<JSCell> for the purpose of calling get() because the get() method will just
1185         call whatever callback function pointer is encoded in the property and it does not need
1186         to know anything about what type that callback will instantiate.
1187
1188         ClassStructure: with this attribute the second column should be a C++ field name. The
1189         static hashtable will initialize the property by treating the field as a
1190         LazyClassStructure and it will call get(). LazyClassStructure completely owns the whole
1191         initialization workflow, so Lookup assumes that when LazyClassStructure::get() returns,
1192         the property in question will already be set. By convention, we have LazyClassStructure
1193         initialize the property with a pointer to the constructor, since that's how all of our
1194         classes work: "globalObject.Date" points to the DateConstructor.
1195
1196         This is a 2x speed-up in JSGlobalObject initialization time in a microbenchmark that
1197         calls our C API. This is a 1% speed-up on SunSpider and JSRegress.
1198
1199         * API/JSCallbackFunction.cpp:
1200         (JSC::JSCallbackFunction::create):
1201         * API/ObjCCallbackFunction.h:
1202         (JSC::ObjCCallbackFunction::impl):
1203         * API/ObjCCallbackFunction.mm:
1204         (JSC::ObjCCallbackFunction::ObjCCallbackFunction):
1205         (JSC::ObjCCallbackFunction::create):
1206         * CMakeLists.txt:
1207         * JavaScriptCore.xcodeproj/project.pbxproj:
1208         * create_hash_table:
1209         * dfg/DFGAbstractInterpreterInlines.h:
1210         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1211         * dfg/DFGAbstractValue.cpp:
1212         (JSC::DFG::AbstractValue::set):
1213         * dfg/DFGArrayMode.cpp:
1214         (JSC::DFG::ArrayMode::originalArrayStructure):
1215         * dfg/DFGByteCodeParser.cpp:
1216         (JSC::DFG::ByteCodeParser::handleTypedArrayConstructor):
1217         * dfg/DFGSpeculativeJIT.cpp:
1218         (JSC::DFG::SpeculativeJIT::compileNewTypedArray):
1219         * dfg/DFGSpeculativeJIT32_64.cpp:
1220         (JSC::DFG::SpeculativeJIT::compile):
1221         * dfg/DFGSpeculativeJIT64.cpp:
1222         (JSC::DFG::SpeculativeJIT::compile):
1223         * dfg/DFGStructureRegistrationPhase.cpp:
1224         (JSC::DFG::StructureRegistrationPhase::run):
1225         * ftl/FTLLowerDFGToB3.cpp:
1226         (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
1227         * runtime/ClonedArguments.cpp:
1228         (JSC::ClonedArguments::getOwnPropertySlot):
1229         (JSC::ClonedArguments::materializeSpecials):
1230         * runtime/CommonSlowPaths.cpp:
1231         (JSC::SLOW_PATH_DECL):
1232         * runtime/FunctionPrototype.cpp:
1233         (JSC::functionProtoFuncToString):
1234         * runtime/InternalFunction.cpp:
1235         (JSC::InternalFunction::visitChildren):
1236         (JSC::InternalFunction::name):
1237         (JSC::InternalFunction::calculatedDisplayName):
1238         (JSC::InternalFunction::createSubclassStructure):
1239         * runtime/InternalFunction.h:
1240         * runtime/JSBoundFunction.cpp:
1241         (JSC::JSBoundFunction::finishCreation):
1242         (JSC::JSBoundFunction::visitChildren):
1243         * runtime/JSFunction.cpp:
1244         (JSC::JSFunction::getOwnPropertySlot):
1245         (JSC::JSFunction::defineOwnProperty):
1246         * runtime/JSGenericTypedArrayViewConstructorInlines.h:
1247         (JSC::constructGenericTypedArrayView):
1248         * runtime/JSGlobalObject.cpp:
1249         (JSC::createProxyProperty):
1250         (JSC::createJSONProperty):
1251         (JSC::createMathProperty):
1252         (JSC::JSGlobalObject::init):
1253         (JSC::JSGlobalObject::stringPrototypeChainIsSane):
1254         (JSC::JSGlobalObject::resetPrototype):
1255         (JSC::JSGlobalObject::visitChildren):
1256         (JSC::JSGlobalObject::toThis):
1257         (JSC::JSGlobalObject::getOwnPropertySlot):
1258         (JSC::JSGlobalObject::createThrowTypeError): Deleted.
1259         * runtime/JSGlobalObject.h:
1260         (JSC::JSGlobalObject::objectConstructor):
1261         (JSC::JSGlobalObject::promiseConstructor):
1262         (JSC::JSGlobalObject::internalPromiseConstructor):
1263         (JSC::JSGlobalObject::evalErrorConstructor):
1264         (JSC::JSGlobalObject::rangeErrorConstructor):
1265         (JSC::JSGlobalObject::referenceErrorConstructor):
1266         (JSC::JSGlobalObject::syntaxErrorConstructor):
1267         (JSC::JSGlobalObject::typeErrorConstructor):
1268         (JSC::JSGlobalObject::URIErrorConstructor):
1269         (JSC::JSGlobalObject::nullGetterFunction):
1270         (JSC::JSGlobalObject::nullSetterFunction):
1271         (JSC::JSGlobalObject::callFunction):
1272         (JSC::JSGlobalObject::applyFunction):
1273         (JSC::JSGlobalObject::definePropertyFunction):
1274         (JSC::JSGlobalObject::arrayProtoValuesFunction):
1275         (JSC::JSGlobalObject::initializePromiseFunction):
1276         (JSC::JSGlobalObject::newPromiseCapabilityFunction):
1277         (JSC::JSGlobalObject::functionProtoHasInstanceSymbolFunction):
1278         (JSC::JSGlobalObject::regExpProtoExecFunction):
1279         (JSC::JSGlobalObject::regExpProtoSymbolReplaceFunction):
1280         (JSC::JSGlobalObject::regExpProtoGlobalGetter):
1281         (JSC::JSGlobalObject::regExpProtoUnicodeGetter):
1282         (JSC::JSGlobalObject::throwTypeErrorGetterSetter):
1283         (JSC::JSGlobalObject::moduleLoader):
1284         (JSC::JSGlobalObject::objectPrototype):
1285         (JSC::JSGlobalObject::functionPrototype):
1286         (JSC::JSGlobalObject::arrayPrototype):
1287         (JSC::JSGlobalObject::booleanPrototype):
1288         (JSC::JSGlobalObject::stringPrototype):
1289         (JSC::JSGlobalObject::symbolPrototype):
1290         (JSC::JSGlobalObject::numberPrototype):
1291         (JSC::JSGlobalObject::datePrototype):
1292         (JSC::JSGlobalObject::regExpPrototype):
1293         (JSC::JSGlobalObject::errorPrototype):
1294         (JSC::JSGlobalObject::iteratorPrototype):
1295         (JSC::JSGlobalObject::generatorFunctionPrototype):
1296         (JSC::JSGlobalObject::generatorPrototype):
1297         (JSC::JSGlobalObject::debuggerScopeStructure):
1298         (JSC::JSGlobalObject::withScopeStructure):
1299         (JSC::JSGlobalObject::strictEvalActivationStructure):
1300         (JSC::JSGlobalObject::activationStructure):
1301         (JSC::JSGlobalObject::moduleEnvironmentStructure):
1302         (JSC::JSGlobalObject::directArgumentsStructure):
1303         (JSC::JSGlobalObject::scopedArgumentsStructure):
1304         (JSC::JSGlobalObject::clonedArgumentsStructure):
1305         (JSC::JSGlobalObject::isOriginalArrayStructure):
1306         (JSC::JSGlobalObject::booleanObjectStructure):
1307         (JSC::JSGlobalObject::callbackConstructorStructure):
1308         (JSC::JSGlobalObject::callbackFunctionStructure):
1309         (JSC::JSGlobalObject::callbackObjectStructure):
1310         (JSC::JSGlobalObject::propertyNameIteratorStructure):
1311         (JSC::JSGlobalObject::objcCallbackFunctionStructure):
1312         (JSC::JSGlobalObject::objcWrapperObjectStructure):
1313         (JSC::JSGlobalObject::dateStructure):
1314         (JSC::JSGlobalObject::nullPrototypeObjectStructure):
1315         (JSC::JSGlobalObject::errorStructure):
1316         (JSC::JSGlobalObject::calleeStructure):
1317         (JSC::JSGlobalObject::functionStructure):
1318         (JSC::JSGlobalObject::boundFunctionStructure):
1319         (JSC::JSGlobalObject::boundSlotBaseFunctionStructure):
1320         (JSC::JSGlobalObject::getterSetterStructure):
1321         (JSC::JSGlobalObject::nativeStdFunctionStructure):
1322         (JSC::JSGlobalObject::namedFunctionStructure):
1323         (JSC::JSGlobalObject::functionNameOffset):
1324         (JSC::JSGlobalObject::numberObjectStructure):
1325         (JSC::JSGlobalObject::privateNameStructure):
1326         (JSC::JSGlobalObject::mapStructure):
1327         (JSC::JSGlobalObject::regExpStructure):
1328         (JSC::JSGlobalObject::generatorFunctionStructure):
1329         (JSC::JSGlobalObject::setStructure):
1330         (JSC::JSGlobalObject::stringObjectStructure):
1331         (JSC::JSGlobalObject::symbolObjectStructure):
1332         (JSC::JSGlobalObject::iteratorResultObjectStructure):
1333         (JSC::JSGlobalObject::lazyTypedArrayStructure):
1334         (JSC::JSGlobalObject::typedArrayStructure):
1335         (JSC::JSGlobalObject::typedArrayStructureConcurrently):
1336         (JSC::JSGlobalObject::isOriginalTypedArrayStructure):
1337         (JSC::JSGlobalObject::typedArrayConstructor):
1338         (JSC::JSGlobalObject::actualPointerFor):
1339         (JSC::JSGlobalObject::internalFunctionStructure): Deleted.
1340         * runtime/JSNativeStdFunction.cpp:
1341         (JSC::JSNativeStdFunction::create):
1342         * runtime/JSWithScope.cpp:
1343         (JSC::JSWithScope::create):
1344         (JSC::JSWithScope::visitChildren):
1345         (JSC::JSWithScope::createStructure):
1346         (JSC::JSWithScope::JSWithScope):
1347         * runtime/JSWithScope.h:
1348         (JSC::JSWithScope::object):
1349         (JSC::JSWithScope::create): Deleted.
1350         (JSC::JSWithScope::createStructure): Deleted.
1351         (JSC::JSWithScope::JSWithScope): Deleted.
1352         * runtime/LazyClassStructure.cpp: Added.
1353         (JSC::LazyClassStructure::Initializer::Initializer):
1354         (JSC::LazyClassStructure::Initializer::setPrototype):
1355         (JSC::LazyClassStructure::Initializer::setStructure):
1356         (JSC::LazyClassStructure::Initializer::setConstructor):
1357         (JSC::LazyClassStructure::visit):
1358         (JSC::LazyClassStructure::dump):
1359         * runtime/LazyClassStructure.h: Added.
1360         (JSC::LazyClassStructure::LazyClassStructure):
1361         (JSC::LazyClassStructure::get):
1362         (JSC::LazyClassStructure::prototype):
1363         (JSC::LazyClassStructure::constructor):
1364         (JSC::LazyClassStructure::getConcurrently):
1365         (JSC::LazyClassStructure::prototypeConcurrently):
1366         (JSC::LazyClassStructure::constructorConcurrently):
1367         * runtime/LazyClassStructureInlines.h: Added.
1368         (JSC::LazyClassStructure::initLater):
1369         * runtime/LazyProperty.h: Added.
1370         (JSC::LazyProperty::Initializer::Initializer):
1371         (JSC::LazyProperty::LazyProperty):
1372         (JSC::LazyProperty::get):
1373         (JSC::LazyProperty::getConcurrently):
1374         * runtime/LazyPropertyInlines.h: Added.
1375         (JSC::LazyProperty<ElementType>::Initializer<OwnerType>::set):
1376         (JSC::LazyProperty<ElementType>::initLater):
1377         (JSC::LazyProperty<ElementType>::setMayBeNull):
1378         (JSC::LazyProperty<ElementType>::set):
1379         (JSC::LazyProperty<ElementType>::visit):
1380         (JSC::LazyProperty<ElementType>::dump):
1381         (JSC::LazyProperty<ElementType>::callFunc):
1382         * runtime/Lookup.cpp:
1383         (JSC::setUpStaticFunctionSlot):
1384         * runtime/Lookup.h:
1385         (JSC::HashTableValue::function):
1386         (JSC::HashTableValue::functionLength):
1387         (JSC::HashTableValue::propertyGetter):
1388         (JSC::HashTableValue::propertyPutter):
1389         (JSC::HashTableValue::accessorGetter):
1390         (JSC::HashTableValue::accessorSetter):
1391         (JSC::HashTableValue::constantInteger):
1392         (JSC::HashTableValue::lexerValue):
1393         (JSC::HashTableValue::lazyCellPropertyOffset):
1394         (JSC::HashTableValue::lazyClassStructureOffset):
1395         (JSC::HashTableValue::lazyPropertyCallback):
1396         (JSC::getStaticPropertySlot):
1397         (JSC::getStaticValueSlot):
1398         (JSC::reifyStaticProperty):
1399         * runtime/PropertySlot.h:
1400         * runtime/TypedArrayType.h:
1401
1402 2016-05-03  Per Arne Vollan  <peavo@outlook.com>
1403
1404         [Win] Remove Windows XP Compatibility Requirements
1405         https://bugs.webkit.org/show_bug.cgi?id=152899
1406
1407         Reviewed by Brent Fulgham.
1408
1409         Windows XP is not supported anymore, we can remove workarounds.
1410
1411         * JavaScriptCore.vcxproj/jsc/DLLLauncherMain.cpp:
1412         (enableTerminationOnHeapCorruption):
1413
1414 2016-05-03  Joseph Pecoraro  <pecoraro@apple.com>
1415
1416         Web Inspector: console.assert should do far less work when the assertion is true
1417         https://bugs.webkit.org/show_bug.cgi?id=157297
1418         <rdar://problem/26056556>
1419
1420         Reviewed by Timothy Hatcher.
1421
1422         * runtime/ConsoleClient.h:
1423         * runtime/ConsoleClient.cpp:
1424         (JSC::ConsoleClient::assertion):
1425         (JSC::ConsoleClient::assertCondition): Deleted.
1426         Rename, now that this will only get called when the assertion failed.
1427
1428         * runtime/ConsoleObject.cpp:
1429         (JSC::consoleProtoFuncAssert):
1430         Avoid doing any work if the assertion succeeded.
1431
1432 2016-05-03  Joseph Pecoraro  <pecoraro@apple.com>
1433
1434         Unreviewed follow-up testapi fix after r200355.
1435
1436         * runtime/JSGlobalObject.cpp:
1437         (JSC::JSGlobalObject::init):
1438         Revert back to non-enumerable. This matches our older behavior,
1439         we can decide to make this Enumerable later if needed.
1440
1441 2016-05-02  Joseph Pecoraro  <pecoraro@apple.com>
1442
1443         Web Inspector: Reflect.toString() should be [object Object] not [object Reflect]
1444         https://bugs.webkit.org/show_bug.cgi?id=157288
1445
1446         Reviewed by Darin Adler.
1447
1448         * runtime/ReflectObject.cpp:
1449         * tests/stress/reflect.js: Added.
1450
1451 2016-05-02  Jon Davis  <jond@apple.com>
1452
1453         Add Resource Timing entry to the Feature Status page.
1454         https://bugs.webkit.org/show_bug.cgi?id=157285
1455
1456         Reviewed by Timothy Hatcher.
1457
1458         * features.json:
1459
1460 2016-05-02  Joseph Pecoraro  <pecoraro@apple.com>
1461
1462         Make console a namespace object (like Math/JSON), allowing functions to be called unbound
1463         https://bugs.webkit.org/show_bug.cgi?id=157286
1464         <rdar://problem/26052830>
1465
1466         Reviewed by Timothy Hatcher.
1467
1468         This changes `console` to be a global namespace object, like `Math` and `JSON`.
1469         It just holds a bunch of functions, that can be used on their own, unbound.
1470         For example, `[1,2,3].forEach(console.log)` and `var log = console.log; log(1)`
1471         used to throw exceptions and now do not.
1472
1473         Previously console was an Object/Prototype pair, so functions were on
1474         ConsolePrototype (console.__proto__.log) and they needed to be called
1475         Console objects as the `this` value. Now, `console` is just a standard
1476         object with a bunch of functions. Since there is no console prototype the
1477         functions can be passed around and called as expected and they will
1478         just do the right thing.
1479
1480         For compatability with other browsers, `console` was made enumerable
1481         on the global object.
1482
1483         * CMakeLists.txt:
1484         * JavaScriptCore.xcodeproj/project.pbxproj:
1485         Add new files and remove old files.
1486
1487         * runtime/CommonIdentifiers.h:
1488         Add "console".
1489
1490         * runtime/ConsoleObject.cpp: Renamed from Source/JavaScriptCore/runtime/ConsolePrototype.cpp.
1491         (JSC::ConsoleObject::ConsoleObject):
1492         (JSC::ConsoleObject::finishCreation):
1493         (JSC::valueToStringWithUndefinedOrNullCheck):
1494         (JSC::consoleLogWithLevel):
1495         (JSC::consoleProtoFuncDebug):
1496         (JSC::consoleProtoFuncError):
1497         (JSC::consoleProtoFuncLog):
1498         (JSC::consoleProtoFuncInfo):
1499         (JSC::consoleProtoFuncWarn):
1500         (JSC::consoleProtoFuncClear):
1501         (JSC::consoleProtoFuncDir):
1502         (JSC::consoleProtoFuncDirXML):
1503         (JSC::consoleProtoFuncTable):
1504         (JSC::consoleProtoFuncTrace):
1505         (JSC::consoleProtoFuncAssert):
1506         (JSC::consoleProtoFuncCount):
1507         (JSC::consoleProtoFuncProfile):
1508         (JSC::consoleProtoFuncProfileEnd):
1509         (JSC::consoleProtoFuncTakeHeapSnapshot):
1510         (JSC::consoleProtoFuncTime):
1511         (JSC::consoleProtoFuncTimeEnd):
1512         (JSC::consoleProtoFuncTimeStamp):
1513         (JSC::consoleProtoFuncGroup):
1514         (JSC::consoleProtoFuncGroupCollapsed):
1515         (JSC::consoleProtoFuncGroupEnd):
1516         Console functions no longer need to check if the this object is
1517         a Console object. They will always just work now.
1518
1519         * runtime/MathObject.cpp:
1520         * runtime/MathObject.h:
1521         * runtime/ConsoleObject.h: Renamed from Source/JavaScriptCore/runtime/ConsolePrototype.h.
1522         (JSC::ConsoleObject::create):
1523         (JSC::ConsoleObject::createStructure):
1524         ConsoleObject is a basic object like MathObject.
1525
1526         * runtime/JSConsole.cpp: Removed.
1527         * runtime/JSConsole.h: Removed.
1528         * runtime/JSGlobalObject.h:
1529         * runtime/JSGlobalObject.cpp:
1530         (JSC::JSGlobalObject::init):
1531         (JSC::JSGlobalObject::visitChildren):
1532         Remove JSConsole / ConsolePrototype in favor of the single ConsoleObject.
1533
1534 2016-05-02  Per Arne Vollan  <peavo@outlook.com>
1535
1536         [Win] Clean up annoying compiler warnings
1537         https://bugs.webkit.org/show_bug.cgi?id=149813
1538
1539         Reviewed by Alex Christensen.
1540
1541         * bytecode/PropertyCondition.cpp:
1542         (JSC::PropertyCondition::isWatchableWhenValid):
1543         * dfg/DFGObjectAllocationSinkingPhase.cpp:
1544         * dfg/DFGSpeculativeJIT32_64.cpp:
1545         (JSC::DFG::SpeculativeJIT::emitCall):
1546         * inspector/InspectorBackendDispatcher.cpp:
1547         (Inspector::BackendDispatcher::sendPendingErrors):
1548         * jit/JITCall32_64.cpp:
1549         (JSC::JIT::compileOpCall):
1550         * parser/Parser.cpp:
1551         (JSC::Parser<LexerType>::parseAssignmentExpression):
1552         * runtime/ClonedArguments.cpp:
1553         (JSC::ClonedArguments::createWithInlineFrame):
1554         * runtime/Error.cpp:
1555         (JSC::addErrorInfoAndGetBytecodeOffset):
1556         * runtime/IntlNumberFormat.cpp:
1557         (JSC::IntlNumberFormat::initializeNumberFormat):
1558         * runtime/JSObject.cpp:
1559         (JSC::JSObject::heapSnapshot):
1560         (JSC::callToPrimitiveFunction):
1561         * runtime/RegExpPrototype.cpp:
1562         (JSC::flagsString):
1563         * runtime/SamplingProfiler.cpp:
1564         (JSC::SamplingProfiler::StackFrame::functionStartColumn):
1565
1566 2016-05-02  Keith Miller  <keith_miller@apple.com>
1567
1568         ToThis should be able to be eliminated in Constant Folding
1569         https://bugs.webkit.org/show_bug.cgi?id=157213
1570
1571         Reviewed by Saam Barati.
1572
1573         This patch enables eliminating the ToThis value when we have abstract interpreter
1574         indicates the node is not needed. Since there are Objects that override their
1575         ToThis behavior we first check if we can eliminate the node by looking at its
1576         speculated type. If the function is in strict mode then we can eliminate ToThis as
1577         long as the speculated type is not SpecObjectOther since that contains objects
1578         that may set OverridesToThis. If the function is not in strict mode then we can
1579         eliminate ToThis as long is the speculated type is an object that is not SpecObjectOther.
1580
1581         If we can't eliminate with type information we can still eliminate the ToThis node with
1582         the proven structure set. When ToThis only sees structures that do not set OverridesToThis
1583         it can be eliminated. Additionally, if the function is in strict mode then we can eliminate
1584         ToThis as long as all only the object structures don't set OverridesToThis.
1585
1586         * dfg/DFGAbstractInterpreterInlines.h:
1587         (JSC::DFG::isToThisAnIdentity):
1588         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1589         * dfg/DFGConstantFoldingPhase.cpp:
1590         (JSC::DFG::ConstantFoldingPhase::foldConstants):
1591         * dfg/DFGFixupPhase.cpp:
1592         (JSC::DFG::FixupPhase::fixupToThis):
1593         * tests/stress/to-this-global-object.js: Added.
1594         (test):
1595         (test2):
1596         (get for):
1597
1598 2016-05-01  Skachkov Oleksandr  <gskachkov@gmail.com>
1599
1600         Class contructor and methods shouldn't have "arguments" and "caller"
1601         https://bugs.webkit.org/show_bug.cgi?id=144238
1602
1603         Reviewed by Ryosuke Niwa.
1604
1605         Added TypeError that is raised in case of access to properties 'arguments' or 'caller'
1606         of constructor or method of class. Actually TypeError already raised for most cases, except
1607         case with undeclared constructor e. g.
1608         class A {}
1609         (new A).constructor.caller
1610         (new A).constructor.arguments
1611
1612         * runtime/JSFunction.cpp:
1613         (JSC::getThrowTypeErrorGetterSetter):
1614         (JSC::JSFunction::getOwnPropertySlot):
1615         * runtime/JSGlobalObject.cpp:
1616         (JSC::JSGlobalObject::createThrowTypeErrorArgumentsAndCaller):
1617         (JSC::JSGlobalObject::visitChildren):
1618         * runtime/JSGlobalObject.h:
1619         (JSC::JSGlobalObject::throwTypeErrorArgumentsAndCallerGetterSetter):
1620         * runtime/JSGlobalObjectFunctions.cpp:
1621         (JSC::globalFuncThrowTypeErrorArgumentsAndCaller):
1622         * runtime/JSGlobalObjectFunctions.h:
1623
1624 2016-05-02  Yoav Weiss  <yoav@yoav.ws>
1625
1626         Move ResourceTiming behind a runtime flag
1627         https://bugs.webkit.org/show_bug.cgi?id=157133
1628
1629         Reviewed by Alex Christensen.
1630
1631         * runtime/CommonIdentifiers.h: Added PerformanceEntry, PerformanceEntryList and PerformanceResourceTiming as property names.
1632
1633 2016-05-02  Yusuke Suzuki  <utatane.tea@gmail.com>
1634
1635         Assertion failure for bound function with custom prototype and Reflect.construct
1636         https://bugs.webkit.org/show_bug.cgi?id=157081
1637
1638         Reviewed by Saam Barati.
1639
1640         We ensured `newTarget != exec->callee()`. However, it does not mean `newTarget.get("prototype") != exec->callee()->get("prototype")`.
1641         When the given `prototype` is the same to `baseStructure->sotredPrototype()`, it is unnecessary to create a new structure from this
1642         baseStructure.
1643
1644         * bytecode/InternalFunctionAllocationProfile.h:
1645         (JSC::InternalFunctionAllocationProfile::createAllocationStructureFromBase):
1646         * tests/stress/custom-prototype-may-be-same-to-original-one.js: Added.
1647         (shouldBe):
1648         (boundFunction):
1649
1650 2016-04-30  Konstantin Tokarev  <annulen@yandex.ru>
1651
1652         Guard ObjC-specific code in Heap.cpp with USE(FOUNDATION)
1653         https://bugs.webkit.org/show_bug.cgi?id=157236
1654
1655         Reviewed by Darin Adler.
1656
1657         This also fixes build with GCC 4.8 which does not provide
1658         __has_include.
1659
1660         * heap/Heap.cpp:
1661
1662 2016-04-30  Yusuke Suzuki  <utatane.tea@gmail.com>
1663
1664         Assertion failure for destructuring assignment with new.target and unary operator
1665         https://bugs.webkit.org/show_bug.cgi?id=157149
1666
1667         Reviewed by Saam Barati.
1668
1669         The caller of parseDefaultValueForDestructuringPattern() should propagate errors.
1670         And this patch also cleans up createSavePoint and createSavePointForError; introducing SavePointWithError.
1671
1672         * parser/Parser.cpp:
1673         (JSC::Parser<LexerType>::parseSourceElements):
1674         (JSC::Parser<LexerType>::parseDestructuringPattern):
1675         Add propagateErorr() for parseDefaultValueForDestructuringPattern.
1676
1677         (JSC::Parser<LexerType>::parseAssignmentExpression):
1678         * parser/Parser.h:
1679         (JSC::Parser::restoreLexerState):
1680         (JSC::Parser::internalSaveState):
1681         (JSC::Parser::createSavePointForError):
1682         (JSC::Parser::createSavePoint):
1683         (JSC::Parser::internalRestoreState):
1684         (JSC::Parser::restoreSavePointWithError):
1685         (JSC::Parser::restoreSavePoint):
1686         * tests/stress/default-value-parsing-should-propagate-error.js: Added.
1687         (testSyntaxError):
1688         (testSyntaxError.f):
1689
1690 2016-04-28  Darin Adler  <darin@apple.com>
1691
1692         First step in using "enum class" instead of "String" for enumerations in DOM
1693         https://bugs.webkit.org/show_bug.cgi?id=157163
1694
1695         Reviewed by Chris Dumez.
1696
1697         * runtime/JSString.h:
1698         (JSC::jsStringWithCache): Deleted unneeded overload for AtomicString.
1699
1700 2016-04-29  Benjamin Poulain  <bpoulain@apple.com>
1701
1702         [JSC][ARMv7S] Arithmetic module results change when tiering up to DFG
1703         https://bugs.webkit.org/show_bug.cgi?id=157217
1704         rdar://problem/24733432
1705
1706         Reviewed by Mark Lam.
1707
1708         ARMv7's fmod() returns less accurate results than an integer division.
1709         Since we have integer div on ARMv7s, the results start changing when
1710         we reach DFG.
1711
1712         In this patch, I change our fmod slow path to behave like the fast path
1713         on ARMv7s.
1714
1715         * dfg/DFGSpeculativeJIT.cpp:
1716         (JSC::DFG::SpeculativeJIT::compileArithMod):
1717         (JSC::DFG::fmodAsDFGOperation): Deleted.
1718         * runtime/CommonSlowPaths.cpp:
1719         (JSC::SLOW_PATH_DECL):
1720         * runtime/MathCommon.cpp:
1721         (JSC::isStrictInt32):
1722         * runtime/MathCommon.h:
1723
1724 2016-04-29  Joseph Pecoraro  <pecoraro@apple.com>
1725
1726         Web Inspector: Issues inspecting the inspector, pausing on breakpoints causes content to not load
1727         https://bugs.webkit.org/show_bug.cgi?id=157198
1728         <rdar://problem/26011049>
1729
1730         Reviewed by Timothy Hatcher.
1731
1732         * inspector/InspectorBackendDispatcher.cpp:
1733         (Inspector::BackendDispatcher::sendResponse):
1734         While auditing the code, add a WTFMove.
1735
1736 2016-04-29  Mark Lam  <mark.lam@apple.com>
1737
1738         Make RegExp.prototype.test spec compliant.
1739         https://bugs.webkit.org/show_bug.cgi?id=155862
1740
1741         Reviewed by Saam Barati.
1742
1743         * builtins/RegExpPrototype.js:
1744         (intrinsic.RegExpTestIntrinsic.test):
1745
1746         * create_hash_table:
1747         - Delete obsoleted code.
1748
1749         * dfg/DFGByteCodeParser.cpp:
1750         (JSC::DFG::ByteCodeParser::addToGraph):
1751         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
1752         - We now have 2 intrinsics for RegExp.prototype.test:
1753           RegExpTestIntrinsic and RegExpTestFastIntrinsic.
1754
1755           RegExpTestIntrinsic maps to the entry at the top of the builtin ES6
1756           RegExp.prototype.test.
1757           RegExpTestFastIntrinsic maps to the fast path in the builtin ES6
1758           RegExp.prototype.test.
1759
1760           Both will end up using the RegExpTest DFG node to implement the fast path
1761           of RegExp.prototype.test.  RegExpTestIntrinsic will have some additional checks
1762           before the RegExpTest node.  Those checks are for speculating that it is ok for
1763           us to take the fast path.
1764
1765         * runtime/CommonIdentifiers.h:
1766         * runtime/Intrinsic.h:
1767
1768         * runtime/JSGlobalObject.cpp:
1769         (JSC::JSGlobalObject::init):
1770         - Added the regExpTestFast function.
1771         - Also fixed the parameter length on 2 other functions that were erroneous.
1772
1773         * runtime/RegExpPrototype.cpp:
1774         (JSC::RegExpPrototype::finishCreation):
1775         (JSC::regExpProtoFuncTestFast):
1776         (JSC::regExpProtoFuncTest): Deleted.
1777         * runtime/RegExpPrototype.h:
1778         * tests/es6.yaml:
1779
1780 2016-04-29  Benjamin Poulain  <benjamin@webkit.org>
1781
1782         Extend math-pow-stable-results.js to get more information about the failure
1783
1784         * tests/stress/math-pow-stable-results.js:
1785
1786 2016-04-29  Yusuke Suzuki  <utatane.tea@gmail.com>
1787
1788         Assertion failure for exception in "prototype" property getter and Reflect.construct
1789         https://bugs.webkit.org/show_bug.cgi?id=157084
1790
1791         Reviewed by Mark Lam.
1792
1793         InternalFunction::createSubclassStrucuture may throw exceptions because it performs [[Get]] to
1794         look up the "prototype" object. The current assertion is invalid.
1795         We also found that Object constructor is not aware of new.target. This is filed[1].
1796
1797         [1]: https://bugs.webkit.org/show_bug.cgi?id=157196
1798
1799         * runtime/InternalFunction.cpp:
1800         (JSC::InternalFunction::createSubclassStructure):
1801         * tests/stress/create-subclass-structure-may-throw-exception-when-getting-prototype.js: Added.
1802         (shouldThrow):
1803         (bf):
1804
1805 2016-04-29  Commit Queue  <commit-queue@webkit.org>
1806
1807         Unreviewed, rolling out r200232.
1808         https://bugs.webkit.org/show_bug.cgi?id=157189
1809
1810         This change broke the Mac CMake build and its LayoutTest is
1811         failing and/or flaky on all platforms (Requested by ryanhaddad
1812         on #webkit).
1813
1814         Reverted changeset:
1815
1816         "Move ResourceTiming behind a runtime flag"
1817         https://bugs.webkit.org/show_bug.cgi?id=157133
1818         http://trac.webkit.org/changeset/200232
1819
1820 2016-04-29  Yusuke Suzuki  <utatane.tea@gmail.com>
1821
1822         [ES6] RegExp.prototype.@@replace should use @isObject instead of `instanceof` for object guard
1823         https://bugs.webkit.org/show_bug.cgi?id=157124
1824
1825         Reviewed by Keith Miller.
1826
1827         Use @isObject instead of `instanceof @Object`.
1828         The `instanceof` check is not enough to check Object Type.
1829         This fix itself is the same to r199647, and this patch is for RegExp.prototype.@@replace.
1830
1831         * builtins/RegExpPrototype.js:
1832         (replace):
1833         * tests/stress/regexp-replace-in-other-realm-should-work.js: Added.
1834         (shouldBe):
1835         * tests/stress/regexp-replace-should-work-with-objects-not-inheriting-object-prototype.js: Added.
1836         (shouldBe):
1837         (regexp.exec):
1838
1839 2016-04-29  Yoav Weiss  <yoav@yoav.ws>
1840
1841         Move ResourceTiming behind a runtime flag
1842         https://bugs.webkit.org/show_bug.cgi?id=157133
1843
1844         Reviewed by Alex Christensen.
1845
1846         * runtime/CommonIdentifiers.h: Added PerformanceEntry, PerformanceEntryList and PerformanceResourceTiming as property names.
1847
1848 2016-04-28  Joseph Pecoraro  <pecoraro@apple.com>
1849
1850         Remove unused bool parameter in CodeCache::getGlobalCodeBlock
1851         https://bugs.webkit.org/show_bug.cgi?id=157156
1852
1853         Reviewed by Mark Lam.
1854
1855         The bool parameter appears to be isArrowFunctionContext, but the method's
1856         contents just get that property from the Executable, so the parameter is
1857         unnecessary and unused.
1858
1859         * runtime/CodeCache.cpp:
1860         (JSC::CodeCache::getGlobalCodeBlock):
1861         (JSC::CodeCache::getProgramCodeBlock):
1862         (JSC::CodeCache::getEvalCodeBlock):
1863         (JSC::CodeCache::getModuleProgramCodeBlock):
1864         * runtime/CodeCache.h:
1865         * runtime/Executable.cpp:
1866         (JSC::EvalExecutable::create):
1867         * runtime/JSGlobalObject.cpp:
1868         (JSC::JSGlobalObject::createEvalCodeBlock):
1869         * runtime/JSGlobalObject.h:
1870
1871 2016-04-28  Caitlin Potter  <caitp@igalia.com>
1872
1873         [JSC] re-implement String#padStart and String#padEnd in JavaScript
1874         https://bugs.webkit.org/show_bug.cgi?id=157146
1875
1876         Reviewed by Saam Barati.
1877
1878         * builtins/StringPrototype.js:
1879         (repeatCharactersSlowPath):
1880         (padStart):
1881         (padEnd):
1882         * runtime/JSGlobalObject.cpp:
1883         (JSC::JSGlobalObject::init):
1884         * runtime/StringPrototype.cpp:
1885         (JSC::StringPrototype::finishCreation): Deleted.
1886         (JSC::repeatStringPattern): Deleted.
1887         (JSC::padString): Deleted.
1888         (JSC::stringProtoFuncPadEnd): Deleted.
1889         (JSC::stringProtoFuncPadStart): Deleted.
1890
1891 2016-04-28  Joseph Pecoraro  <pecoraro@apple.com>
1892
1893         Web Inspector: Tweak auto attach initialization on some platforms
1894         https://bugs.webkit.org/show_bug.cgi?id=157150
1895         <rdar://problem/21222045>
1896
1897         Reviewed by Timothy Hatcher.
1898
1899         * inspector/EventLoop.cpp:
1900         (Inspector::EventLoop::cycle):
1901         * inspector/remote/RemoteInspector.mm:
1902         (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
1903
1904 2016-04-28  Benjamin Poulain  <bpoulain@apple.com>
1905
1906         [JSC] Unify Math.pow() accross all tiers
1907         https://bugs.webkit.org/show_bug.cgi?id=157121
1908
1909         Reviewed by Geoffrey Garen.
1910
1911         My previous optimizations of DFG compile time have slowly
1912         regressed Sunspider's math-partial-sums.
1913
1914         What is happenning is baseline used a thunk for Math.pow()
1915         that has a special case for an exponent of -0.5, while
1916         DFG/FTL have other special cases for other exponents.
1917         The faster we get to DFG, the less time we spend in that fast
1918         case for -0.5.
1919
1920         While looking into this, I discovered some correctness issues. Baseline
1921         optimizes y=-0.5 by turning it into 1/sqrt(). DFG/FTL optimize constant
1922         y=0.5 by turning it into sqrt(). The problem is sqrt() behaves differently
1923         for -0 and -Infinity. With sqrt(), negative numbers are undefined,
1924         and the result is NaN. With pow(), they have a result.
1925
1926         Something else that has bothered me for a while is that Math.pow()
1927         with the same arguments give you different results in LLINT, Baseline,
1928         and DFG/FTL. This seems a bit dangerous for numerical stability.
1929
1930         With this patch, I unify the behaviors for all tiers while keeping
1931         the "special cases".
1932
1933         We have pow() that is super slow, but most callers don't need the
1934         full power. We have:
1935         -pow() with an exponent between 0 and 1000 is a fast path implemented
1936          by multiplication only.
1937         -pow(x, 0.5) is sqrt with special checks for negative values.
1938         -pow(x, -0.5) is sqrt with special checks for negative values.
1939
1940         The C++ implementation handles all those optimizations too. This ensure
1941         you get the same results from LLINT to FTL.
1942
1943         The thunk is eliminated, it was producing incorrect results and only
1944         optimized Sunspider's partial-sums.
1945
1946         DFG gets the optimized integer, 0.5 and -0.5 cases since those are important
1947         for somewhat-hot code. DFG falls back to the C++ code for any non-obvious case.
1948
1949         FTL gets the full C++ implementation inlined in B3. B3 knows how to eliminate
1950         all the dead cases so you get the best if your code is hot enough to reach FTL.
1951
1952         * dfg/DFGFixupPhase.cpp:
1953         (JSC::DFG::FixupPhase::fixupNode): Deleted.
1954         * dfg/DFGNode.h:
1955         (JSC::DFG::Node::convertToArithSqrt): Deleted.
1956         * dfg/DFGNodeType.h:
1957         * dfg/DFGSpeculativeJIT.cpp:
1958         (JSC::DFG::compileArithPowIntegerFastPath):
1959         (JSC::DFG::SpeculativeJIT::compileArithPow):
1960         * dfg/DFGStrengthReductionPhase.cpp:
1961         (JSC::DFG::StrengthReductionPhase::handleNode):
1962         * ftl/FTLLowerDFGToB3.cpp:
1963         (JSC::FTL::DFG::LowerDFGToB3::compileArithPow):
1964         * jit/ThunkGenerators.cpp:
1965         (JSC::powThunkGenerator): Deleted.
1966         * jit/ThunkGenerators.h:
1967         * runtime/MathCommon.cpp:
1968         (JSC::operationMathPow):
1969         * runtime/MathCommon.h:
1970         * runtime/VM.cpp:
1971         (JSC::thunkGeneratorForIntrinsic): Deleted.
1972         * tests/stress/math-pow-stable-results.js: Added.
1973         Getting consistent results when tiering up is new.
1974         This test verify that results always remains the same as LLINT.
1975
1976         * tests/stress/math-pow-with-constants.js:
1977         (testPowUsedAsSqrt):
1978         (powUsedAsOneOverSqrt):
1979         (testPowUsedAsOneOverSqrt):
1980         (powUsedAsSquare):
1981         (testPowUsedAsSquare):
1982
1983 2016-04-28  Mark Lam  <mark.lam@apple.com>
1984
1985         DebuggerScope::className() should not assert scope->isValid().
1986         https://bugs.webkit.org/show_bug.cgi?id=157143
1987
1988         Reviewed by Keith Miller.
1989
1990         DebuggerScope::className() should not assert scope->isValid() because the
1991         TypeProfiler logs objects it encounters, and may indirectly call
1992         JSObject::calculatedClassName() on those objects later, thereby calling
1993         DebuggerScope::className() on an invalidated DebuggerScope.
1994
1995         The existing handling in DebuggerScope::className() for an invalidated scope
1996         (that returns a null string) is sufficient.
1997
1998         * debugger/DebuggerScope.cpp:
1999         (JSC::DebuggerScope::className):
2000
2001 2016-04-28  Caitlin Potter  <caitp@igalia.com>
2002
2003         [JSC] implement spec changes for String#padStart and String#padEnd
2004         https://bugs.webkit.org/show_bug.cgi?id=157139
2005
2006         Reviewed by Keith Miller.
2007
2008         Previously, if the fill string was the empty string, it was treated as a
2009         single U+0020 SPACE character. Now, if this occurs, the original string
2010         is returned instead.
2011
2012         Change was discussed at TC39 in March [1], and is reflected in new
2013         test262 tests for the feature.
2014
2015         [1] https://github.com/tc39/tc39-notes/blob/master/es7/2016-03/march-29.md#stringprototypepadstartpadend
2016
2017         * runtime/StringPrototype.cpp:
2018         (JSC::padString):
2019         * tests/es6/String.prototype_methods_String.prototype.padEnd.js:
2020         (TestFillerToString):
2021         (TestFillerEmptyString):
2022         * tests/es6/String.prototype_methods_String.prototype.padStart.js:
2023         (TestFillerToString):
2024         (TestFillerEmptyString):
2025
2026 2016-04-28  Skachkov Oleksandr  <gskachkov@gmail.com>
2027
2028         Crash for non-static super property call in derived class constructor
2029         https://bugs.webkit.org/show_bug.cgi?id=157089
2030
2031         Reviewed by Darin Adler.
2032
2033         Added tdz check of the 'this' before access to the 'super' for FunctionCallBracketNode,
2034         the same as it was done for FunctionCallDotNode.
2035
2036         * bytecompiler/NodesCodegen.cpp:
2037         (JSC::FunctionCallBracketNode::emitBytecode):
2038
2039 2016-04-27  Mark Lam  <mark.lam@apple.com>
2040
2041         The GetterSetter structure needs a globalObject.
2042         https://bugs.webkit.org/show_bug.cgi?id=157120
2043
2044         Reviewed by Filip Pizlo.
2045
2046         In r199170: <http://trac.webkit.org/r199170>, GetterSetter was promoted from
2047         being a JSCell to a JSObject.  JSObject methods expect their structure to have a
2048         globalObject.  For example, see JSObject::calculatedClassName().  GetterSetter
2049         was previously using a singleton getterSetterStructure owned by the VM.  That
2050         singleton getterSetterStructure is not associated with any globalObjects.  As a
2051         result, JSObject::calculatedClassName() will run into a null globalObject when it
2052         is called on a GetterSetter object.
2053
2054         This patch removes the VM singleton getterSetterStructure, and instead, creates
2055         a getterSetterStructure for each JSGlobalObject.
2056
2057         * dfg/DFGAbstractInterpreterInlines.h:
2058         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2059         * dfg/DFGStructureRegistrationPhase.cpp:
2060         (JSC::DFG::StructureRegistrationPhase::run):
2061         * runtime/GetterSetter.h:
2062         * runtime/JSGlobalObject.cpp:
2063         (JSC::JSGlobalObject::init):
2064         (JSC::JSGlobalObject::visitChildren):
2065         * runtime/JSGlobalObject.h:
2066         (JSC::JSGlobalObject::functionStructure):
2067         (JSC::JSGlobalObject::boundFunctionStructure):
2068         (JSC::JSGlobalObject::boundSlotBaseFunctionStructure):
2069         (JSC::JSGlobalObject::getterSetterStructure):
2070         (JSC::JSGlobalObject::nativeStdFunctionStructure):
2071         (JSC::JSGlobalObject::namedFunctionStructure):
2072         (JSC::JSGlobalObject::functionNameOffset):
2073         * runtime/VM.cpp:
2074         (JSC::VM::VM):
2075         * runtime/VM.h:
2076
2077 2016-04-27  Keith Miller  <keith_miller@apple.com>
2078
2079         Unreviewed, Revert r199397 due to PLT regressions
2080
2081         * JavaScriptCore.xcodeproj/project.pbxproj:
2082         * builtins/ArrayPrototype.js:
2083         (concatSlowPath): Deleted.
2084         (concat): Deleted.
2085         * bytecode/BytecodeIntrinsicRegistry.cpp:
2086         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry): Deleted.
2087         * bytecode/BytecodeIntrinsicRegistry.h:
2088         * dfg/DFGAbstractInterpreterInlines.h:
2089         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2090         * dfg/DFGByteCodeParser.cpp:
2091         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
2092         (JSC::DFG::ByteCodeParser::handleIntrinsicCall): Deleted.
2093         * dfg/DFGClobberize.h:
2094         (JSC::DFG::clobberize):
2095         * dfg/DFGDoesGC.cpp:
2096         (JSC::DFG::doesGC): Deleted.
2097         * dfg/DFGFixupPhase.cpp:
2098         (JSC::DFG::FixupPhase::fixupNode):
2099         * dfg/DFGNodeType.h:
2100         * dfg/DFGOperations.cpp:
2101         * dfg/DFGOperations.h:
2102         * dfg/DFGPredictionPropagationPhase.cpp:
2103         * dfg/DFGSafeToExecute.h:
2104         (JSC::DFG::safeToExecute): Deleted.
2105         * dfg/DFGSpeculativeJIT.cpp:
2106         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
2107         (JSC::DFG::SpeculativeJIT::compileIsJSArray): Deleted.
2108         (JSC::DFG::SpeculativeJIT::compileIsArrayObject): Deleted.
2109         (JSC::DFG::SpeculativeJIT::compileIsArrayConstructor): Deleted.
2110         (JSC::DFG::SpeculativeJIT::compileCallObjectConstructor): Deleted.
2111         * dfg/DFGSpeculativeJIT.h:
2112         (JSC::DFG::SpeculativeJIT::callOperation): Deleted.
2113         * dfg/DFGSpeculativeJIT32_64.cpp:
2114         (JSC::DFG::SpeculativeJIT::compile): Deleted.
2115         * dfg/DFGSpeculativeJIT64.cpp:
2116         (JSC::DFG::SpeculativeJIT::compile):
2117         * ftl/FTLCapabilities.cpp:
2118         (JSC::FTL::canCompile): Deleted.
2119         * ftl/FTLLowerDFGToB3.cpp:
2120         (JSC::FTL::DFG::LowerDFGToB3::compileNode): Deleted.
2121         (JSC::FTL::DFG::LowerDFGToB3::compileCallObjectConstructor): Deleted.
2122         (JSC::FTL::DFG::LowerDFGToB3::compileIsArrayObject): Deleted.
2123         (JSC::FTL::DFG::LowerDFGToB3::compileIsJSArray): Deleted.
2124         (JSC::FTL::DFG::LowerDFGToB3::compileIsArrayConstructor): Deleted.
2125         (JSC::FTL::DFG::LowerDFGToB3::isArray): Deleted.
2126         * jit/JITOperations.h:
2127         * jsc.cpp:
2128         (GlobalObject::finishCreation):
2129         (functionDataLogValue): Deleted.
2130         * runtime/ArrayConstructor.cpp:
2131         (JSC::ArrayConstructor::finishCreation):
2132         (JSC::arrayConstructorPrivateFuncIsArrayConstructor):
2133         * runtime/ArrayConstructor.h:
2134         (JSC::isArrayConstructor): Deleted.
2135         * runtime/ArrayPrototype.cpp:
2136         (JSC::ArrayPrototype::finishCreation):
2137         (JSC::arrayProtoFuncConcat):
2138         (JSC::arrayProtoPrivateFuncIsJSArray): Deleted.
2139         (JSC::moveElements): Deleted.
2140         (JSC::arrayProtoPrivateFuncConcatMemcpy): Deleted.
2141         (JSC::arrayProtoPrivateFuncAppendMemcpy): Deleted.
2142         * runtime/ArrayPrototype.h:
2143         * runtime/CommonIdentifiers.h:
2144         * runtime/Intrinsic.h:
2145         * runtime/JSArray.cpp:
2146         (JSC::JSArray::fastConcatWith):
2147         (JSC::JSArray::appendMemcpy): Deleted.
2148         * runtime/JSArray.h:
2149         (JSC::JSArray::fastConcatType):
2150         (JSC::JSArray::createStructure):
2151         (JSC::isJSArray):
2152         * runtime/JSArrayInlines.h: Removed.
2153         (JSC::JSArray::memCopyWithIndexingType): Deleted.
2154         (JSC::JSArray::canFastCopy): Deleted.
2155         * runtime/JSGlobalObject.cpp:
2156         (JSC::JSGlobalObject::init):
2157         * runtime/JSType.h:
2158         * runtime/ObjectConstructor.h:
2159         (JSC::constructObject): Deleted.
2160         * tests/es6.yaml:
2161         * tests/stress/array-concat-spread-object.js: Removed.
2162         (arrayEq): Deleted.
2163         * tests/stress/array-concat-spread-proxy-exception-check.js: Removed.
2164         (arrayEq): Deleted.
2165         * tests/stress/array-concat-spread-proxy.js: Removed.
2166         (arrayEq): Deleted.
2167         * tests/stress/array-concat-with-slow-indexingtypes.js: Removed.
2168         (arrayEq): Deleted.
2169         * tests/stress/array-species-config-array-constructor.js:
2170
2171 2016-04-27  Michael Saboff  <msaboff@apple.com>
2172
2173         REGRESSION(r200117): Crash in lowerDFGToB3::compileStringReplace()
2174         https://bugs.webkit.org/show_bug.cgi?id=157099
2175
2176         Reviewed by Saam Barati.
2177
2178         Given that the DFGFixupPhase could mark the edge of child2 as StringUse,
2179         we need to lower that edge appropriately.
2180
2181         * ftl/FTLLowerDFGToB3.cpp:
2182         (JSC::FTL::DFG::LowerDFGToB3::compileStringReplace):
2183
2184 2016-04-27  Mark Lam  <mark.lam@apple.com>
2185
2186         Address feedback from https://bugs.webkit.org/show_bug.cgi?id=157048#c5.
2187         https://bugs.webkit.org/show_bug.cgi?id=157096
2188
2189         Reviewed by Geoffrey Garen.
2190
2191         1. Check for USE(APPLE_INTERNAL_SDK) instead of __has_include(<mach-o/dyld_priv.h>).
2192         2. Rename webkitFirstSDKVersionWithInitConstructorSupport to
2193            firstSDKVersionWithInitConstructorSupport.
2194
2195         * API/JSWrapperMap.mm:
2196         (supportsInitMethodConstructors):
2197
2198 2016-04-27  Mark Lam  <mark.lam@apple.com>
2199
2200         Restrict the availability of some JSC options to local debug builds only.
2201         https://bugs.webkit.org/show_bug.cgi?id=157058
2202
2203         Reviewed by Geoffrey Garen.
2204
2205         1. Each option will be given an availability flag.
2206         2. The functionOverrides and useDollarVM (along with its alias, enableDollarVM)
2207            will have "Restricted" availability.
2208         3. All other options will have “Normal” availability.
2209         4. Any options with "Restricted" availability will only be accessible if function
2210            allowRestrictedOptions() returns true.
2211         5. For now, allowRestrictedOptions() always returns false for release builds, and
2212            true for debug builds.
2213
2214         If an option is "Restricted" and restricted options are not allowed, the VM will
2215         behave semantically as if that option does not exist at all:
2216         1. Option dumps will not show the option.
2217         2. Attempts to set the option will fail as if the option does not exist.
2218
2219         Behind the scene, the option does exist, and is set to its default value
2220         (whatever that may be) once and only once on options initialization.
2221
2222         * runtime/Options.cpp:
2223         (JSC::allowRestrictedOptions):
2224         (JSC::parse):
2225         (JSC::overrideOptionWithHeuristic):
2226         (JSC::Options::initialize):
2227         (JSC::Options::setOptionWithoutAlias):
2228         (JSC::Options::dumpOption):
2229         * runtime/Options.h:
2230         (JSC::Option::type):
2231         (JSC::Option::availability):
2232         (JSC::Option::isOverridden):
2233
2234 2016-04-27  Gavin Barraclough  <barraclough@apple.com>
2235
2236         Enable separated heap by default on ios
2237         https://bugs.webkit.org/show_bug.cgi?id=156720
2238         <rdar://problem/25841790>
2239
2240         Unreviewed rollout - caused memory regression.
2241
2242         * runtime/Options.cpp:
2243         (JSC::recomputeDependentOptions):
2244
2245 2016-04-27  Benjamin Poulain  <bpoulain@apple.com>
2246
2247         Follow up for r200113 on 32bit
2248
2249         I forgot to do the 32bit counterpart of r200113.
2250         The test fails on the bots.
2251
2252         * dfg/DFGSpeculativeJIT32_64.cpp:
2253         (JSC::DFG::SpeculativeJIT::compile):
2254
2255 2016-04-27  Alberto Garcia  <berto@igalia.com>
2256
2257         [GTK] Fails to build randomly when generating LLIntDesiredOffsets.h
2258         https://bugs.webkit.org/show_bug.cgi?id=155427
2259
2260         Reviewed by Carlos Garcia Campos.
2261
2262         If the build directory contains the -I string, the script that
2263         generates LLIntDesiredOffsets.h will confuse it with an option to
2264         declare an include directory.
2265
2266         In order to avoid that we should only use the arguments that start
2267         with -I when extracting the list of include directories, instead
2268         of using the ones that simply contain that string.
2269
2270         * offlineasm/parser.rb:
2271
2272 2016-04-27  Saam barati  <sbarati@apple.com>
2273
2274         JSC should have an option to allow global const redeclarations
2275         https://bugs.webkit.org/show_bug.cgi?id=157006
2276
2277         Reviewed by Geoffrey Garen.
2278
2279         This patch implements an option that dictates whether
2280         const redeclarations at the program level will throw.
2281         This option defaults to true but allows users of JSC
2282         to set it to false. This option is per VM. This is needed
2283         for backwards compatibility with our old const implementation.
2284
2285         * jsc.cpp:
2286         (GlobalObject::finishCreation):
2287         (functionShadowChickenFunctionsOnStack):
2288         (functionSetGlobalConstRedeclarationShouldNotThrow):
2289         (functionReadline):
2290         * runtime/Executable.cpp:
2291         (JSC::ProgramExecutable::initializeGlobalProperties):
2292         * runtime/JSGlobalLexicalEnvironment.cpp:
2293         (JSC::JSGlobalLexicalEnvironment::put):
2294         (JSC::JSGlobalLexicalEnvironment::isConstVariable):
2295         * runtime/JSGlobalLexicalEnvironment.h:
2296         (JSC::JSGlobalLexicalEnvironment::isEmpty):
2297         * runtime/VM.h:
2298         (JSC::VM::setGlobalConstRedeclarationShouldThrow):
2299         (JSC::VM::globalConstRedeclarationShouldThrow):
2300         * tests/stress/global-const-redeclaration-setting: Added.
2301         * tests/stress/global-const-redeclaration-setting-2.js: Added.
2302         (assert):
2303         * tests/stress/global-const-redeclaration-setting-3.js: Added.
2304         (assert):
2305         (catch):
2306         * tests/stress/global-const-redeclaration-setting-4.js: Added.
2307         (assert):
2308         (catch):
2309         * tests/stress/global-const-redeclaration-setting-5.js: Added.
2310         (assert):
2311         (catch):
2312         * tests/stress/global-const-redeclaration-setting.js: Added.
2313         (assert):
2314         * tests/stress/global-const-redeclaration-setting/first.js: Added.
2315         * tests/stress/global-const-redeclaration-setting/let.js: Added.
2316         * tests/stress/global-const-redeclaration-setting/second.js: Added.
2317         * tests/stress/global-const-redeclaration-setting/strict.js: Added.
2318
2319 2016-04-26  Michael Saboff  <msaboff@apple.com>
2320
2321         [ES] Implement RegExp.prototype.@@replace and use it for String.prototype.replace
2322         https://bugs.webkit.org/show_bug.cgi?id=156562
2323
2324         Reviewed by Filip Pizlo.
2325
2326         Added builtins for String.prototype.replace as well as RegExp.prototype[Symbol.replace].
2327
2328         The String.prototype.replace also has an intrinsic, StringPrototypeReplaceIntrinsic.
2329         This original intrinsic was copied to make StringPrototypeReplaceRegExpIntrinsic.
2330         The difference between the two intrinsics is that StringPrototypeReplaceIntrinsic has
2331         the same checks found in the new builtin hasObservableSideEffectsForStringReplace.
2332         We implement these primordial checks for StringPrototypeReplaceIntrinsic in two places.
2333         First, we do a trial check during ByteCode parsing time to see if the current
2334         RegExp.prototype properties have changed from the original.  If they have, we don't
2335         inline the intrinsic.  Later, in the fixup phase, we add nodes to the IR to emit the
2336         checks at runtime.
2337
2338         The new intrinsic StringPrototypeReplaceRegExpIntrinsic is only available via the
2339         private @replaceUsingRegExp, which is called in the String.prototype.replace builtin.
2340         It is only called after hasObservableSideEffectsForStringReplace has been called
2341
2342         Both of these intrinsics are needed, because the JS code containing String.replace() calls
2343         runs initially in the LLint and then the baseline JIT.  Even after the function tiers up
2344         to the DFG JIT, the inlining budget may not allow StringPrototypeReplaceIntrinsic to be inlined.
2345         Having StringPrototypeReplaceRegExpIntrinsic allows for the String.prototype.replace builtin to
2346         get reasonable performance before the other intrinsic is inlined or when it can't.
2347
2348         * builtins/RegExpPrototype.js:
2349         (match):
2350         (getSubstitution):
2351         (replace):
2352         (search):
2353         (split):
2354         * builtins/StringPrototype.js:
2355         (repeat):
2356         (hasObservableSideEffectsForStringReplace):
2357         (intrinsic.StringPrototypeReplaceIntrinsic.replace):
2358         (localeCompare):
2359         New builtins for String.prototype.replace and RegExp.prototype[Symbol.replace].
2360
2361         * bytecode/BytecodeIntrinsicRegistry.cpp:
2362         * bytecode/BytecodeIntrinsicRegistry.h:
2363         * dfg/DFGAbstractInterpreterInlines.h:
2364         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2365         * dfg/DFGByteCodeParser.cpp:
2366         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
2367         * dfg/DFGClobberize.h:
2368         (JSC::DFG::clobberize):
2369         * dfg/DFGDoesGC.cpp:
2370         (JSC::DFG::doesGC):
2371         * dfg/DFGFixupPhase.cpp:
2372         (JSC::DFG::FixupPhase::fixupNode):
2373         (JSC::DFG::FixupPhase::fixupGetAndSetLocalsInBlock):
2374         (JSC::DFG::FixupPhase::tryAddStringReplacePrimordialChecks):
2375         (JSC::DFG::FixupPhase::checkArray):
2376         * dfg/DFGGraph.cpp:
2377         (JSC::DFG::Graph::getRegExpPrototypeProperty):
2378         * dfg/DFGGraph.h:
2379         (JSC::DFG::Graph::getRegExpPrototypeProperty):
2380         * dfg/DFGNode.h:
2381         (JSC::DFG::Node::hasHeapPrediction):
2382         * dfg/DFGNodeType.h:
2383         * dfg/DFGPredictionPropagationPhase.cpp:
2384         * dfg/DFGSafeToExecute.h:
2385         (JSC::DFG::safeToExecute):
2386         * dfg/DFGSpeculativeJIT32_64.cpp:
2387         (JSC::DFG::SpeculativeJIT::compile):
2388         * dfg/DFGSpeculativeJIT64.cpp:
2389         (JSC::DFG::SpeculativeJIT::compile):
2390         * dfg/DFGStrengthReductionPhase.cpp:
2391         (JSC::DFG::StrengthReductionPhase::handleNode):
2392         * ftl/FTLCapabilities.cpp:
2393         (JSC::FTL::canCompile):
2394         * ftl/FTLLowerDFGToB3.cpp:
2395         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2396         * runtime/CommonIdentifiers.h:
2397         * runtime/Intrinsic.h:
2398         * runtime/RegExpPrototype.cpp:
2399         (JSC::RegExpPrototype::finishCreation):
2400         * runtime/StringPrototype.cpp:
2401         (JSC::StringPrototype::finishCreation):
2402         (JSC::replace):
2403         (JSC::stringProtoFuncReplaceUsingRegExp):
2404         (JSC::stringProtoFuncReplaceUsingStringSearch):
2405         (JSC::operationStringProtoFuncReplaceGeneric):
2406         (JSC::stringProtoFuncReplace): Deleted.
2407         Added StringReplaceRegExp intrinsic.  Added checks for RegExp profiled arguments to StringReplace
2408         that mirror what is in hasObservableSideEffectsForStringReplace().  If we aren't able to add the
2409         checks, we OSR exit.  Add Graph::getPrimordialRegExpPrototypeProperty() as a helper to get the
2410         primordial values from RegExp.prototype.
2411
2412         * runtime/JSGlobalObject.cpp:
2413         (JSC::JSGlobalObject::init): Added @regExpPrototypeSymbolReplace and
2414         @hasObservableSideEffectsForStringReplace here instead og String.prototype so that we reduce the
2415         number of objects we have to traverse.
2416
2417         * tests/es6.yaml: Changed expectations for the various replace related tests to passing.
2418
2419         * tests/stress/regexp-replace-proxy.js:
2420         (assert):
2421         (let.getProxyNullExec.new.Proxy):
2422         (let.getSetProxyNullExec.new.Proxy):
2423         (get resetTracking):
2424         (let.getSetProxyMatches_comma.new.Proxy):
2425         (set get getSetProxyNullExec):
2426         (let.getSetProxyReplace_phoneNumber.new.Proxy):
2427         (set get getSetProxyMatches_comma):
2428         (let.getSetProxyReplaceUnicode_digit_nonGreedy.new.Proxy):
2429         (set get resetTracking):
2430         * tests/stress/string-replace-proxy.js:
2431         (assert):
2432         (let.getSetProxyReplace.new.Proxy.replace):
2433         New tests.
2434
2435 2016-04-26  Mark Lam  <mark.lam@apple.com>
2436
2437         Gardening: speculative build fix.
2438
2439         Not reviewed.
2440
2441         * API/JSWrapperMap.mm:
2442
2443 2016-04-26  Mark Lam  <mark.lam@apple.com>
2444
2445         Update the compatibility version check for the ObjC API's InitConstructorSupport to use dyld_get_program_sdk_version().
2446         https://bugs.webkit.org/show_bug.cgi?id=157048
2447
2448         Reviewed by Geoffrey Garen.
2449
2450         * API/JSWrapperMap.mm:
2451         (supportsInitMethodConstructors):
2452         (getJSExportProtocol):
2453
2454 2016-04-26  Benjamin Poulain  <bpoulain@apple.com>
2455
2456         [JSC] GetByVal on Undecided use its children before its OSR Exit
2457         https://bugs.webkit.org/show_bug.cgi?id=157046
2458
2459         Reviewed by Mark Lam.
2460
2461         Very silly bug: GetByVal on Undecided uses its children before
2462         the speculationCheck(). If we fail the speculation, we have already
2463         lost how to recover the values.
2464
2465         The existing tests did not catch this because we tier up to B3
2466         before such Exits happen. B3 has explicit liveness and did not suffer
2467         from this bug.
2468         The new test has a smaller warmup to exercise the OSR Exit in DFG
2469         instead of FTL.
2470
2471         * dfg/DFGSpeculativeJIT64.cpp:
2472         (JSC::DFG::SpeculativeJIT::compile):
2473         * tests/stress/get-by-val-on-undecided-out-of-bounds.js: Added.
2474         (string_appeared_here.opaqueGetByValKnownArray):
2475
2476 2016-04-26  Skachkov Oleksandr  <gskachkov@gmail.com>
2477
2478         calling super() a second time in a constructor should throw
2479         https://bugs.webkit.org/show_bug.cgi?id=151113
2480
2481         Reviewed by Saam Barati.
2482
2483         Currently, our implementation checks if 'super()' was called in a constructor more
2484         than once and raises a RuntimeError before the second call. According to the spec
2485         we need to raise an error just after the second super() is finished and before
2486         the new 'this' is assigned https://esdiscuss.org/topic/duplicate-super-call-behaviour.
2487         To implement this behavior this patch adds a new op code, op_is_empty, that is used
2488         to check if 'this' is empty.
2489
2490         * bytecode/BytecodeList.json:
2491         * bytecode/BytecodeUseDef.h:
2492         (JSC::computeUsesForBytecodeOffset):
2493         (JSC::computeDefsForBytecodeOffset):
2494         * bytecode/CodeBlock.cpp:
2495         (JSC::CodeBlock::dumpBytecode):
2496         * bytecompiler/BytecodeGenerator.cpp:
2497         (JSC::BytecodeGenerator::emitIsEmpty):
2498         * bytecompiler/BytecodeGenerator.h:
2499         * bytecompiler/NodesCodegen.cpp:
2500         (JSC::FunctionCallValueNode::emitBytecode):
2501         * dfg/DFGAbstractInterpreterInlines.h:
2502         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2503         * dfg/DFGByteCodeParser.cpp:
2504         (JSC::DFG::ByteCodeParser::parseBlock):
2505         * dfg/DFGCapabilities.cpp:
2506         (JSC::DFG::capabilityLevel):
2507         * dfg/DFGClobberize.h:
2508         (JSC::DFG::clobberize):
2509         * dfg/DFGDoesGC.cpp:
2510         (JSC::DFG::doesGC):
2511         * dfg/DFGFixupPhase.cpp:
2512         (JSC::DFG::FixupPhase::fixupNode):
2513         * dfg/DFGNodeType.h:
2514         * dfg/DFGPredictionPropagationPhase.cpp:
2515         * dfg/DFGSafeToExecute.h:
2516         (JSC::DFG::safeToExecute):
2517         * dfg/DFGSpeculativeJIT32_64.cpp:
2518         (JSC::DFG::SpeculativeJIT::compile):
2519         * dfg/DFGSpeculativeJIT64.cpp:
2520         (JSC::DFG::SpeculativeJIT::compile):
2521         * ftl/FTLCapabilities.cpp:
2522         (JSC::FTL::canCompile):
2523         * ftl/FTLLowerDFGToB3.cpp:
2524         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2525         (JSC::FTL::DFG::LowerDFGToB3::compileIsEmpty):
2526         * jit/JIT.cpp:
2527         (JSC::JIT::privateCompileMainPass):
2528         * jit/JIT.h:
2529         * jit/JITOpcodes.cpp:
2530         (JSC::JIT::emit_op_is_empty):
2531         * jit/JITOpcodes32_64.cpp:
2532         (JSC::JIT::emit_op_is_empty):
2533         * llint/LowLevelInterpreter32_64.asm:
2534         * llint/LowLevelInterpreter64.asm:
2535         * tests/stress/class-syntax-double-constructor.js: Added.
2536
2537 2016-04-26  Mark Lam  <mark.lam@apple.com>
2538
2539         Changed jsc options title to be more descriptive.
2540         https://bugs.webkit.org/show_bug.cgi?id=157036
2541
2542         Reviewed by Joseph Pecoraro.
2543
2544         Let the title for --dumpOptions be "Modified JSC runtime options:" since it only
2545         dumps overridden options.  The title for --options will remain "All JSC runtime
2546         options:" since it dumps all all options with verbose detail.
2547
2548         * jsc.cpp:
2549         (CommandLine::parseArguments):
2550
2551 2016-04-26  Oliver Hunt  <oliver@apple.com>
2552
2553         Enable separated heap by default on ios
2554         https://bugs.webkit.org/show_bug.cgi?id=156720
2555
2556         Unreviewed roll-in of this change. There is only one
2557         additional allocation involved in this logic, and that
2558         is a duplicate mapping.
2559
2560         Either our tools are not report real memory usage
2561         or this revision is not responsible for the regression.
2562
2563         * runtime/Options.cpp:
2564         (JSC::recomputeDependentOptions):
2565
2566 2016-04-26  Filip Pizlo  <fpizlo@apple.com>
2567
2568         DFG backends shouldn't emit type checks at KnownBlah edges
2569         https://bugs.webkit.org/show_bug.cgi?id=157025
2570
2571         Reviewed by Michael Saboff.
2572
2573         This fixes a crash I found when browsing Bing maps with forceEagerCompilation. I include a
2574         100% repro test case.
2575
2576         The issue is that our code still doesn't fully appreciate the devious implications of
2577         KnownBlah use kinds. Consider KnownCell for example. It means: "trust me, I know that this
2578         value will be a cell". You aren't required to provide a proof when you use KnownCell. Often,
2579         we use it as a result of a path-sensitive proof. The abstract interpreter is not
2580         path-sensitive, so AI will be absolutely sure that the KnownCell use might see a non-cell.
2581         This can lead to debug assertions (which this change removes) and it can lead to the backends
2582         emitting a type check. That type check can be pure evil if the node that has this edge does
2583         not have an exit origin. Such a node would have passed validation because the validater would
2584         have thought that the node cannot exit (after all, according to the IR semantics, there is no
2585         speculation at KnownCell).
2586
2587         This comprehensively fixes the issue by recognizing that Foo(KnownCell:@x) means: I have
2588         already proved that by the time you start executing Foo, @x will already be a cell. I cannot
2589         tell you how I proved this but you can rely on it anyway. AI now takes advantage of this
2590         meaning and will always do filtering of KnownBlah edges regardless of whether the backend
2591         actually emits any type checks for those edges. Since the filtering runs before the backend,
2592         the backend will not emit any checks because it will know that the edge was already checked
2593         (by whatever mechanism we used when we made the edge KnownBlah).
2594
2595         Note that it's good that we found this bug now. The DFG currently does very few
2596         sparse-conditional or path-sensitive optimizations, but it will probably do more in the
2597         future. The bug happens because GetByOffset and friends can achieve path-sensitive proofs via
2598         watchpoints on the inferred type. Normally, AI can follow along with this proof. But in the
2599         example program, and on Bing maps, we would GCSE one GetByOffset with another that had a
2600         weaker proven type. That turned out to be completely sound - between the two GetByOffset's
2601         there was a Branch to null check it. The inferred type of the second GetByOffset ended up
2602         knowing that it cannot be null because null only occurred in some structures but not others.
2603         If we added more sparse-conditional stuff to Branch, then AI would know how to follow along
2604         with the proof but it would also create more situations where we'd have a path-sensitive
2605         proof. So, it's good that we're now getting this right.
2606
2607         * dfg/DFGAbstractInterpreter.h:
2608         (JSC::DFG::AbstractInterpreter::filterEdgeByUse):
2609         * dfg/DFGAbstractInterpreterInlines.h:
2610         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEdges):
2611         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeKnownEdgeTypes):
2612         (JSC::DFG::AbstractInterpreter<AbstractStateType>::verifyEdge):
2613         * dfg/DFGSpeculativeJIT.cpp:
2614         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
2615         * dfg/DFGUseKind.h:
2616         (JSC::DFG::typeFilterFor):
2617         * ftl/FTLLowerDFGToB3.cpp:
2618         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2619         * tests/stress/path-sensitive-known-cell-crash.js: Added.
2620         (bar):
2621         (foo):
2622
2623 2016-04-26  Gavin Barraclough  <barraclough@apple.com>
2624
2625         Enable separated heap by default on ios
2626         https://bugs.webkit.org/show_bug.cgi?id=156720
2627
2628         Unreviewed rollout - caused memory regression.
2629
2630         * runtime/Options.cpp:
2631         (JSC::recomputeDependentOptions):
2632
2633 2016-04-26  Joseph Pecoraro  <pecoraro@apple.com>
2634
2635         Improve jsc --help and making sampling options
2636         https://bugs.webkit.org/show_bug.cgi?id=157015
2637
2638         Reviewed by Saam Barati.
2639
2640         Simplify sampling options to be easier to remember:
2641
2642           * --reportSamplingProfilerData => --sample
2643           * --samplingProfilerTimingInterval => --sampleInterval
2644
2645         Update the --help to mention --sample, and restore the behavior of
2646         --options outputing all possible options so you can discover which
2647         options are available.
2648
2649         * jsc.cpp:
2650         (printUsageStatement):
2651         (CommandLine::parseArguments):
2652         Improve help and modify option dumping.
2653
2654         * runtime/Options.h:
2655         * runtime/SamplingProfiler.cpp:
2656         (JSC::SamplingProfiler::SamplingProfiler):
2657         Rename the sampling interval option.
2658
2659 2016-04-26  Commit Queue  <commit-queue@webkit.org>
2660
2661         Unreviewed, rolling out r200083.
2662         https://bugs.webkit.org/show_bug.cgi?id=157033
2663
2664          It brokes the debug build (Requested by gskachkov on
2665         #webkit).
2666
2667         Reverted changeset:
2668
2669         "calling super() a second time in a constructor should throw"
2670         https://bugs.webkit.org/show_bug.cgi?id=151113
2671         http://trac.webkit.org/changeset/200083
2672
2673 2016-04-26  Skachkov Oleksandr  <gskachkov@gmail.com>
2674
2675         calling super() a second time in a constructor should throw
2676         https://bugs.webkit.org/show_bug.cgi?id=151113
2677
2678         Reviewed by Saam Barati.
2679
2680         Currently, our implementation checks if 'super()' was called in a constructor more
2681         than once and raises a RuntimeError before the second call. According to the spec
2682         we need to raise an error just after the second super() is finished and before
2683         the new 'this' is assigned https://esdiscuss.org/topic/duplicate-super-call-behaviour.
2684         To implement this behavior this patch adds a new op code, op_is_empty, that is used
2685         to check if 'this' is empty.
2686
2687         * bytecode/BytecodeList.json:
2688         * bytecode/BytecodeUseDef.h:
2689         (JSC::computeUsesForBytecodeOffset):
2690         (JSC::computeDefsForBytecodeOffset):
2691         * bytecode/CodeBlock.cpp:
2692         (JSC::CodeBlock::dumpBytecode):
2693         * bytecompiler/BytecodeGenerator.cpp:
2694         (JSC::BytecodeGenerator::emitIsEmpty):
2695         * bytecompiler/BytecodeGenerator.h:
2696         * bytecompiler/NodesCodegen.cpp:
2697         (JSC::FunctionCallValueNode::emitBytecode):
2698         * dfg/DFGAbstractInterpreterInlines.h:
2699         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2700         * dfg/DFGByteCodeParser.cpp:
2701         (JSC::DFG::ByteCodeParser::parseBlock):
2702         * dfg/DFGCapabilities.cpp:
2703         (JSC::DFG::capabilityLevel):
2704         * dfg/DFGClobberize.h:
2705         (JSC::DFG::clobberize):
2706         * dfg/DFGDoesGC.cpp:
2707         (JSC::DFG::doesGC):
2708         * dfg/DFGFixupPhase.cpp:
2709         (JSC::DFG::FixupPhase::fixupNode):
2710         * dfg/DFGNodeType.h:
2711         * dfg/DFGSafeToExecute.h:
2712         (JSC::DFG::safeToExecute):
2713         * dfg/DFGSpeculativeJIT32_64.cpp:
2714         (JSC::DFG::SpeculativeJIT::compile):
2715         * dfg/DFGSpeculativeJIT64.cpp:
2716         (JSC::DFG::SpeculativeJIT::compile):
2717         * ftl/FTLCapabilities.cpp:
2718         (JSC::FTL::canCompile):
2719         * ftl/FTLLowerDFGToB3.cpp:
2720         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2721         (JSC::FTL::DFG::LowerDFGToB3::compileIsEmpty):
2722         * jit/JIT.cpp:
2723         (JSC::JIT::privateCompileMainPass):
2724         * jit/JIT.h:
2725         * jit/JITOpcodes.cpp:
2726         (JSC::JIT::emit_op_is_empty):
2727         * jit/JITOpcodes32_64.cpp:
2728         (JSC::JIT::emit_op_is_empty):
2729         * llint/LowLevelInterpreter32_64.asm:
2730         * llint/LowLevelInterpreter64.asm:
2731         * tests/stress/class-syntax-double-constructor.js: Added.
2732
2733 2016-04-25  Ryosuke Niwa  <rniwa@webkit.org>
2734
2735         Remove the build flag for template elements
2736         https://bugs.webkit.org/show_bug.cgi?id=157022
2737
2738         Reviewed by Daniel Bates.
2739
2740         * Configurations/FeatureDefines.xcconfig:
2741
2742 2016-04-25  Benjamin Poulain  <bpoulain@apple.com>
2743
2744         [JSC] Constant folding of UInt32ToNumber is incorrect
2745         https://bugs.webkit.org/show_bug.cgi?id=157011
2746         rdar://problem/25769641
2747
2748         Reviewed by Geoffrey Garen.
2749
2750         UInt32ToNumber should return the unsigned 32bit value of
2751         its child. The abstract interpreter fails to do that when handling
2752         Int52.
2753
2754         None of the tests caught that because the bytecode generator already
2755         fold the operation if given a constant. If the constant is not visible
2756         from the bytecode generator (for example because it comes from an inlined call),
2757         then the abstract interpreter folding was producing invalid results.
2758
2759         * dfg/DFGAbstractInterpreterInlines.h:
2760         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2761         * tests/stress/uint32-to-number-constant-folding.js: Added.
2762         (uint32ToNumberMinusOne):
2763         (uint32ToNumberMinusOnePlusInteger):
2764         (inlineMinusOne):
2765         (uint32ToNumberOnHiddenMinusOne):
2766         (uint32ToNumberOnHiddenMinusOnePlusInteger):
2767         (inlineLargeNegativeNumber1):
2768         (inlineLargeNegativeNumber2):
2769         (inlineLargeNegativeNumber3):
2770         (uint32ToNumberOnHiddenLargeNegativeNumber1):
2771         (uint32ToNumberOnHiddenLargeNegativeNumber2):
2772         (uint32ToNumberOnHiddenLargeNegativeNumber3):
2773
2774 2016-04-25  Fujii Hironori  <Hironori.Fujii@sony.com>
2775
2776         Heap corruption is detected when destructing JSGlobalObject
2777         https://bugs.webkit.org/show_bug.cgi?id=156831
2778
2779         Reviewed by Mark Lam.
2780
2781         WebKit uses CRT static library on Windows.  Each copy of the CRT
2782         library has its own heap manager, allocating memory in one CRT
2783         library and passing the pointer across a DLL boundary to be freed
2784         by a different copy of the CRT library is a potential cause for
2785         heap corruption.
2786
2787           Potential Errors Passing CRT Objects Across DLL Boundaries
2788           <https://msdn.microsoft.com/en-us/library/ms235460(v=vs.140).aspx>
2789
2790         JSGlobalObject::createRareDataIfNeeded is inlined but
2791         JSGlobalObject::~JSGlobalObject is not.  Then, the heap of
2792         allocating JSGlobalObjectRareData is WebKit.dll, but deallocating
2793         JavaScriptCore.dll.  Adding WTF_MAKE_FAST_ALLOCATED to
2794         JSGlobalObjectRareData ensures heap consistency of it.  WTF::Lock
2795         also needs WTF_MAKE_FAST_ALLOCATED because it is allocated from
2796         the inlined constructor of JSGlobalObjectRareData.
2797
2798         Test: fast/dom/insertedIntoDocument-iframe.html
2799
2800         * runtime/JSGlobalObject.h:
2801         Add WTF_MAKE_FAST_ALLOCATED to JSGlobalObjectRareData.
2802
2803 2016-04-25  Michael Saboff  <msaboff@apple.com>
2804
2805         Crash using @tryGetById in DFG
2806         https://bugs.webkit.org/show_bug.cgi?id=156992
2807
2808         Reviewed by Filip Pizlo.
2809
2810         We need to spill live registers when compiling TryGetById in DFG.
2811
2812         * dfg/DFGSpeculativeJIT.cpp:
2813         (JSC::DFG::SpeculativeJIT::compileTryGetById):
2814         * tests/stress/regress-156992.js: New test.
2815         (tryMultipleGetByIds):
2816         (test):
2817
2818 2016-04-25  Saam barati  <sbarati@apple.com>
2819
2820         We don't have to parse a function's parameters every time if the function is in the source provider cache
2821         https://bugs.webkit.org/show_bug.cgi?id=156943
2822
2823         Reviewed by Filip Pizlo.
2824
2825         This patch makes a few changes to make parsing inner functions
2826         faster.
2827
2828         First, we were always parsing an inner function's parameter
2829         list using the templatized TreeBuiler. This means if our parent scope
2830         was building an AST, we ended up building AST nodes for the inner
2831         function's parameter list even though these nodes would go unused.
2832         This patch fixes that to *always* build an inner function's parameter
2833         list using the SyntaxChecker. (Note that this is consistent now with
2834         always building an inner function's body with a SyntaxChecker.)
2835
2836         Second, we were always parsing an inner function's parameter list
2837         even if we had that function saved in the source provider cache.
2838         I've fixed that bug and made it so that we skip over the parsing
2839         of a function's parameter list when it's in the source provider
2840         cache. We could probably enhance this in the future to skip
2841         over the entirety of a function starting at the "function"
2842         keyword or any other start of the function (depending on
2843         the function type: arrow function, method, etc).
2844
2845         This patch also renames a few fields. First, I fixed a typo
2846         from "tocken" => "token" for a few field names. Secondly,
2847         I renamed a field that was called 'bodyStartColumn' to
2848         'parametersStartColumn' because the field really held the
2849         parameter list's start column.
2850
2851         I'm benchmarking this as a 1.5-2% octane/jquery speedup
2852         on a 15" MBP.
2853
2854         * parser/ASTBuilder.h:
2855         (JSC::ASTBuilder::createFunctionExpr):
2856         (JSC::ASTBuilder::createMethodDefinition):
2857         (JSC::ASTBuilder::createArrowFunctionExpr):
2858         (JSC::ASTBuilder::createGetterOrSetterProperty):
2859         (JSC::ASTBuilder::createFuncDeclStatement):
2860         * parser/Lexer.cpp:
2861         (JSC::Lexer<T>::lex):
2862         * parser/Lexer.h:
2863         (JSC::Lexer::currentPosition):
2864         (JSC::Lexer::positionBeforeLastNewline):
2865         (JSC::Lexer::lastTokenLocation):
2866         (JSC::Lexer::setLastLineNumber):
2867         (JSC::Lexer::lastLineNumber):
2868         (JSC::Lexer::prevTerminator):
2869         * parser/Parser.cpp:
2870         (JSC::Parser<LexerType>::parseInner):
2871         (JSC::Parser<LexerType>::parseGeneratorFunctionSourceElements):
2872         (JSC::Parser<LexerType>::parseFunctionBody):
2873         (JSC::stringForFunctionMode):
2874         (JSC::Parser<LexerType>::parseFunctionParameters):
2875         (JSC::Parser<LexerType>::parseFunctionInfo):
2876         * parser/Parser.h:
2877         (JSC::Scope::usedVariablesContains):
2878         (JSC::Scope::forEachUsedVariable):
2879         (JSC::Scope::useVariable):
2880         (JSC::Scope::copyCapturedVariablesToVector):
2881         (JSC::Scope::fillParametersForSourceProviderCache):
2882         (JSC::Scope::restoreFromSourceProviderCache):
2883         * parser/ParserFunctionInfo.h:
2884         * parser/SourceProviderCacheItem.h:
2885         (JSC::SourceProviderCacheItem::endFunctionToken):
2886         (JSC::SourceProviderCacheItem::usedVariables):
2887         (JSC::SourceProviderCacheItem::SourceProviderCacheItem):
2888
2889 2016-04-25  Mark Lam  <mark.lam@apple.com>
2890
2891         Renaming SpecInt32, SpecInt52, MachineInt to SpecInt32Only, SpecInt52Only, AnyInt.
2892         https://bugs.webkit.org/show_bug.cgi?id=156941
2893
2894         Reviewed by Filip Pizlo.
2895
2896         While looking at https://bugs.webkit.org/show_bug.cgi?id=153431, it was decided
2897         that SpecInt32Only, SpecInt52Only, and AnyInt would be better names for
2898         SpecInt32, SpecInt52, and MachineInt.  Let's do a bulk rename.
2899
2900         This is only a renaming patch, and deletion of a piece of unused code.  There are
2901         no semantic changes.
2902
2903         * bindings/ScriptValue.cpp:
2904         (Inspector::jsToInspectorValue):
2905         * bytecode/SpeculatedType.cpp:
2906         (JSC::dumpSpeculation):
2907         (JSC::speculationToAbbreviatedString):
2908         (JSC::speculationFromValue):
2909         (JSC::leastUpperBoundOfStrictlyEquivalentSpeculations):
2910         (JSC::typeOfDoubleNegation):
2911         (JSC::typeOfDoubleRounding):
2912         * bytecode/SpeculatedType.h:
2913         (JSC::isInt32Speculation):
2914         (JSC::isInt32OrBooleanSpeculation):
2915         (JSC::isInt32SpeculationForArithmetic):
2916         (JSC::isInt32OrBooleanSpeculationForArithmetic):
2917         (JSC::isInt32OrBooleanSpeculationExpectingDefined):
2918         (JSC::isInt52Speculation):
2919         (JSC::isAnyIntSpeculation):
2920         (JSC::isAnyIntAsDoubleSpeculation):
2921         (JSC::isDoubleRealSpeculation):
2922         (JSC::isMachineIntSpeculation): Deleted.
2923         (JSC::isInt52AsDoubleSpeculation): Deleted.
2924         (JSC::isIntegerSpeculation): Deleted.
2925         * dfg/DFGAbstractInterpreterInlines.h:
2926         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2927         * dfg/DFGAbstractValue.cpp:
2928         (JSC::DFG::AbstractValue::set):
2929         (JSC::DFG::AbstractValue::fixTypeForRepresentation):
2930         (JSC::DFG::AbstractValue::checkConsistency):
2931         (JSC::DFG::AbstractValue::resultType):
2932         * dfg/DFGAbstractValue.h:
2933         (JSC::DFG::AbstractValue::validateType):
2934         * dfg/DFGArgumentsUtilities.cpp:
2935         (JSC::DFG::emitCodeToGetArgumentsArrayLength):
2936         * dfg/DFGByteCodeParser.cpp:
2937         (JSC::DFG::ByteCodeParser::handleInlining):
2938         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
2939         * dfg/DFGFixupPhase.cpp:
2940         (JSC::DFG::FixupPhase::fixupNode):
2941         (JSC::DFG::FixupPhase::fixupToThis):
2942         (JSC::DFG::FixupPhase::observeUseKindOnNode):
2943         (JSC::DFG::FixupPhase::fixIntConvertingEdge):
2944         (JSC::DFG::FixupPhase::fixIntOrBooleanEdge):
2945         (JSC::DFG::FixupPhase::fixDoubleOrBooleanEdge):
2946         (JSC::DFG::FixupPhase::truncateConstantToInt32):
2947         (JSC::DFG::FixupPhase::attemptToMakeIntegerAdd):
2948         (JSC::DFG::FixupPhase::prependGetArrayLength):
2949         (JSC::DFG::FixupPhase::fixupChecksInBlock):
2950         * dfg/DFGGraph.h:
2951         (JSC::DFG::Graph::addShouldSpeculateInt32):
2952         (JSC::DFG::Graph::addShouldSpeculateAnyInt):
2953         (JSC::DFG::Graph::binaryArithShouldSpeculateInt32):
2954         (JSC::DFG::Graph::binaryArithShouldSpeculateAnyInt):
2955         (JSC::DFG::Graph::unaryArithShouldSpeculateInt32):
2956         (JSC::DFG::Graph::unaryArithShouldSpeculateAnyInt):
2957         (JSC::DFG::Graph::addShouldSpeculateMachineInt): Deleted.
2958         (JSC::DFG::Graph::binaryArithShouldSpeculateMachineInt): Deleted.
2959         (JSC::DFG::Graph::unaryArithShouldSpeculateMachineInt): Deleted.
2960         * dfg/DFGInPlaceAbstractState.cpp:
2961         (JSC::DFG::InPlaceAbstractState::initialize):
2962         * dfg/DFGJITCompiler.cpp:
2963         (JSC::DFG::JITCompiler::noticeOSREntry):
2964         * dfg/DFGNode.cpp:
2965         (JSC::DFG::Node::convertToIdentityOn):
2966         * dfg/DFGNode.h:
2967         (JSC::DFG::Node::asNumber):
2968         (JSC::DFG::Node::isAnyIntConstant):
2969         (JSC::DFG::Node::asAnyInt):
2970         (JSC::DFG::Node::isBooleanConstant):
2971         (JSC::DFG::Node::shouldSpeculateInt32OrBooleanExpectingDefined):
2972         (JSC::DFG::Node::shouldSpeculateAnyInt):
2973         (JSC::DFG::Node::shouldSpeculateDouble):
2974         (JSC::DFG::Node::shouldSpeculateNumber):
2975         (JSC::DFG::Node::isMachineIntConstant): Deleted.
2976         (JSC::DFG::Node::asMachineInt): Deleted.
2977         (JSC::DFG::Node::shouldSpeculateMachineInt): Deleted.
2978         * dfg/DFGOSREntry.cpp:
2979         (JSC::DFG::OSREntryData::dumpInContext):
2980         (JSC::DFG::prepareOSREntry):
2981         * dfg/DFGOSREntry.h:
2982         * dfg/DFGPredictionPropagationPhase.cpp:
2983         * dfg/DFGSSALoweringPhase.cpp:
2984         (JSC::DFG::SSALoweringPhase::handleNode):
2985         (JSC::DFG::SSALoweringPhase::lowerBoundsCheck):
2986         * dfg/DFGSafeToExecute.h:
2987         (JSC::DFG::SafeToExecuteEdge::operator()):
2988         * dfg/DFGSpeculativeJIT.cpp:
2989         (JSC::DFG::SpeculativeJIT::silentFill):
2990         (JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray):
2991         (JSC::DFG::SpeculativeJIT::compileArithAdd):
2992         (JSC::DFG::SpeculativeJIT::compileArithSub):
2993         (JSC::DFG::SpeculativeJIT::compileArithNegate):
2994         (JSC::DFG::SpeculativeJIT::speculateInt32):
2995         (JSC::DFG::SpeculativeJIT::speculateNumber):
2996         (JSC::DFG::SpeculativeJIT::speculateMisc):
2997         (JSC::DFG::SpeculativeJIT::speculate):
2998         * dfg/DFGSpeculativeJIT.h:
2999         (JSC::DFG::SpeculativeJIT::spill):
3000         (JSC::DFG::SpeculativeJIT::isKnownInteger):
3001         (JSC::DFG::SpeculativeJIT::isKnownCell):
3002         (JSC::DFG::SpeculativeJIT::isKnownNotInteger):
3003         (JSC::DFG::SpeculativeJIT::isKnownNotNumber):
3004         (JSC::DFG::SpeculativeJIT::isKnownNotCell):
3005         (JSC::DFG::SpeculativeJIT::isKnownNotOther):
3006         * dfg/DFGSpeculativeJIT32_64.cpp:
3007         (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
3008         (JSC::DFG::SpeculativeJIT::compile):
3009         * dfg/DFGSpeculativeJIT64.cpp:
3010         (JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
3011         (JSC::DFG::SpeculativeJIT::fillSpeculateInt52):
3012         (JSC::DFG::SpeculativeJIT::fillSpeculateDouble):
3013         (JSC::DFG::SpeculativeJIT::emitBranch):
3014         (JSC::DFG::SpeculativeJIT::compile):
3015         (JSC::DFG::SpeculativeJIT::blessBoolean):
3016         (JSC::DFG::SpeculativeJIT::convertAnyInt):
3017         (JSC::DFG::SpeculativeJIT::speculateAnyInt):
3018         (JSC::DFG::SpeculativeJIT::speculateDoubleRepAnyInt):
3019         (JSC::DFG::SpeculativeJIT::convertMachineInt): Deleted.
3020         (JSC::DFG::SpeculativeJIT::speculateMachineInt): Deleted.
3021         (JSC::DFG::SpeculativeJIT::speculateDoubleRepMachineInt): Deleted.
3022         * dfg/DFGUseKind.cpp:
3023         (WTF::printInternal):
3024         * dfg/DFGUseKind.h:
3025         (JSC::DFG::typeFilterFor):
3026         (JSC::DFG::isNumerical):
3027         (JSC::DFG::isDouble):
3028         * dfg/DFGValidate.cpp:
3029         * dfg/DFGVariableAccessData.cpp:
3030         (JSC::DFG::VariableAccessData::makePredictionForDoubleFormat):
3031         (JSC::DFG::VariableAccessData::couldRepresentInt52Impl):
3032         (JSC::DFG::VariableAccessData::flushFormat):
3033         * ftl/FTLCapabilities.cpp:
3034         (JSC::FTL::canCompile):
3035         * ftl/FTLLowerDFGToB3.cpp:
3036         (JSC::FTL::DFG::LowerDFGToB3::compileInt52Constant):
3037         (JSC::FTL::DFG::LowerDFGToB3::compileInt52Rep):
3038         (JSC::FTL::DFG::LowerDFGToB3::compileArithAddOrSub):
3039         (JSC::FTL::DFG::LowerDFGToB3::compileArithNegate):
3040         (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
3041         (JSC::FTL::DFG::LowerDFGToB3::compilePutByVal):
3042         (JSC::FTL::DFG::LowerDFGToB3::compileArrayPush):
3043         (JSC::FTL::DFG::LowerDFGToB3::lowInt32):
3044         (JSC::FTL::DFG::LowerDFGToB3::strictInt52ToInt32):
3045         (JSC::FTL::DFG::LowerDFGToB3::isInt32):
3046         (JSC::FTL::DFG::LowerDFGToB3::isNotInt32):
3047         (JSC::FTL::DFG::LowerDFGToB3::jsValueToStrictInt52):
3048         (JSC::FTL::DFG::LowerDFGToB3::doubleToStrictInt52):
3049         (JSC::FTL::DFG::LowerDFGToB3::speculate):
3050         (JSC::FTL::DFG::LowerDFGToB3::speculateCellOrOther):
3051         (JSC::FTL::DFG::LowerDFGToB3::speculateAnyInt):
3052         (JSC::FTL::DFG::LowerDFGToB3::speculateDoubleRepReal):
3053         (JSC::FTL::DFG::LowerDFGToB3::speculateDoubleRepAnyInt):
3054         (JSC::FTL::DFG::LowerDFGToB3::speculateMachineInt): Deleted.
3055         (JSC::FTL::DFG::LowerDFGToB3::speculateDoubleRepMachineInt): Deleted.
3056         * jit/JITOpcodes.cpp:
3057         (JSC::JIT::emit_op_profile_type):
3058         * jit/JITOpcodes32_64.cpp:
3059         (JSC::JIT::emit_op_profile_type):
3060         * runtime/JSCJSValue.h:
3061         * runtime/JSCJSValueInlines.h:
3062         (JSC::isInt52):
3063         (JSC::JSValue::isAnyInt):
3064         (JSC::JSValue::asAnyInt):
3065         (JSC::JSValue::isMachineInt): Deleted.
3066         (JSC::JSValue::asMachineInt): Deleted.
3067         * runtime/RuntimeType.cpp:
3068         (JSC::runtimeTypeForValue):
3069         (JSC::runtimeTypeAsString):
3070         * runtime/RuntimeType.h:
3071         * runtime/TypeSet.cpp:
3072         (JSC::TypeSet::dumpTypes):
3073         (JSC::TypeSet::displayName):
3074         (JSC::TypeSet::inspectorTypeSet):
3075         (JSC::TypeSet::toJSONString):
3076
3077 2016-04-24  Yusuke Suzuki  <utatane.tea@gmail.com>
3078
3079         [JSC] Optimize JSON.parse string fast path
3080         https://bugs.webkit.org/show_bug.cgi?id=156953
3081
3082         Reviewed by Mark Lam.
3083
3084         This patch further optimizes the string parsing fast path.
3085         Previously, we generated the WTF::String to hold the ownership of the token's string.
3086         And always copied the token in LiteralParser side.
3087         Instead, we hold the ownership of the token String by the StringBuilder in LiteralParser::Lexer,
3088         and remove the processing in the string parsing fast path.
3089         This patch gives us stable 1 - 2.5% improvement in Kraken json-parse-financial.
3090
3091                                        Baseline                  Modified
3092
3093         json-parse-financial        41.383+-0.248      ^      40.894+-0.189         ^ definitely 1.0120x faster
3094
3095         * runtime/LiteralParser.cpp:
3096         (JSC::LiteralParser<CharType>::tryJSONPParse):
3097         (JSC::LiteralParser<CharType>::Lexer::lex):
3098         (JSC::LiteralParser<CharType>::Lexer::lexStringSlow):
3099         (JSC::LiteralParser<CharType>::parse):
3100         (JSC::LiteralParser<CharType>::Lexer::lexString): Deleted.
3101         * runtime/LiteralParser.h:
3102         (JSC::LiteralParser::tryLiteralParse):
3103         (JSC::LiteralParser::Lexer::currentToken):
3104         (JSC::LiteralParser::Lexer::LiteralParserTokenPtr::LiteralParserTokenPtr):
3105         (JSC::LiteralParser::Lexer::LiteralParserTokenPtr::operator->):
3106
3107 2016-04-24  Filip Pizlo <fpizlo@apple.com> and Andy VanWagoner <thetalecrafter@gmail.com>
3108
3109         [INTL] Implement String.prototype.localeCompare in ECMA-402
3110         https://bugs.webkit.org/show_bug.cgi?id=147607
3111
3112         Reviewed by Darin Adler.
3113
3114         Part of this change is just rolling 194394 back in.
3115
3116         The other part is making that not a regression on CDjs. Other than the fact that it uses
3117         bound functions, the problem with this new localeCompare implementation is that it uses
3118         the arguments object. It uses it in a way that *seems* like ArgumentsEliminationPhase
3119         ought to handle, but to my surprise it didn't:
3120
3121         - If we have a ForceExit GetByVal on the arguments object, we would previously assume that
3122           it escaped. That's false since we just exit at ForceExit. On the other hand we probably
3123           should be pruning unreachable paths before we get here, but that's a separate issue. I
3124           don't want to play with phase order right now.
3125
3126         - If we have a OutOfBounds GetByVal on the arguments object, then the best that would
3127           previously happen is that we'd compile it into an in-bounds arguments access. That's quite
3128           bad, as Andy's localeCompare illustrates: it uses out-of-bounds access on the arguments
3129           object to detect if an argument was passed. This change introduces an OutOfBounds version
3130           of GetMyArgumentByVal for this purpose.
3131
3132         This change required registering sane chain watchpoints. In the process, I noticed that the
3133         old way of doing it had a race condition: we might register watchpoints for the structure
3134         that had become insane. This change introduces a double-checking idiom that I believe works
3135         because once the structure becomes insane it can't go back to sane and watchpoints
3136         registration already involves executing the hardest possible fences.
3137
3138         * builtins/StringPrototype.js:
3139         (repeat):
3140         (localeCompare):
3141         (search):
3142         * dfg/DFGAbstractInterpreterInlines.h:
3143         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3144         * dfg/DFGArgumentsEliminationPhase.cpp:
3145         * dfg/DFGArrayMode.cpp:
3146         (JSC::DFG::ArrayMode::refine):
3147         * dfg/DFGClobberize.h:
3148         (JSC::DFG::clobberize):
3149         * dfg/DFGConstantFoldingPhase.cpp:
3150         (JSC::DFG::ConstantFoldingPhase::foldConstants):
3151         * dfg/DFGDoesGC.cpp:
3152         (JSC::DFG::doesGC):
3153         * dfg/DFGFixupPhase.cpp:
3154         (JSC::DFG::FixupPhase::fixupNode):
3155         * dfg/DFGNodeType.h:
3156         * dfg/DFGPreciseLocalClobberize.h:
3157         (JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
3158         * dfg/DFGPredictionPropagationPhase.cpp:
3159         * dfg/DFGSafeToExecute.h:
3160         (JSC::DFG::safeToExecute):
3161         * dfg/DFGSpeculativeJIT.cpp:
3162         (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
3163         * dfg/DFGSpeculativeJIT32_64.cpp:
3164         (JSC::DFG::SpeculativeJIT::compile):
3165         * dfg/DFGSpeculativeJIT64.cpp:
3166         (JSC::DFG::SpeculativeJIT::compile):
3167         * dfg/DFGValidate.cpp:
3168         * ftl/FTLCapabilities.cpp:
3169         (JSC::FTL::canCompile):
3170         * ftl/FTLLowerDFGToB3.cpp:
3171         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
3172         (JSC::FTL::DFG::LowerDFGToB3::compileGetMyArgumentByVal):
3173         (JSC::FTL::DFG::LowerDFGToB3::compilePutByVal):
3174         (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
3175         * ftl/FTLTypedPointer.h:
3176         (JSC::FTL::TypedPointer::TypedPointer):
3177         (JSC::FTL::TypedPointer::operator bool):
3178         (JSC::FTL::TypedPointer::heap):
3179         (JSC::FTL::TypedPointer::operator!): Deleted.
3180         * runtime/StringPrototype.cpp:
3181         (JSC::StringPrototype::finishCreation):
3182
3183 2016-04-23  Filip Pizlo  <fpizlo@apple.com>
3184
3185         Unreviewed, unbreak cloop.
3186
3187         * runtime/VM.cpp:
3188         (JSC::VM::getHostFunction):
3189
3190 2016-04-22  Filip Pizlo  <fpizlo@apple.com>
3191
3192         Speed up bound functions a bit
3193         https://bugs.webkit.org/show_bug.cgi?id=156889
3194
3195         Reviewed by Saam Barati.
3196
3197         Bound functions are hard to optimize because JSC doesn't have a good notion of non-JS code
3198         that does JS-ey things like make JS calls. What I mean by "non-JS code" is code that did not
3199         originate from JS source. A bound function does a highly polymorphic call to the target
3200         stored in the JSBoundFunction. Prior to this change, we represented it as native code that
3201         used the generic native->JS call API. That's not cheap.
3202
3203         We could model bound functions using a builtin, but it's not clear that this would be easy
3204         to grok, since so much of the code would have to access special parts of the JSBoundFunction
3205         type. Doing it that way might solve the performance problems but it would mean extra work to
3206         arrange for the builtin to have speedy access to the call target, the bound this, and the
3207         bound arguments. Also, optimizing bound functions that way would mean that bound function
3208         performance would be gated on the performance of a bunch of other things in our system. For
3209         example, we'd want this polymorphic call to be handled like the funnel that it is: if we're
3210         compiling the bound function's outgoing call with no context then we should compile it as
3211         fully polymorphic but we can let it assume basic sanity like that the callee is a real
3212         function; but if we're compiling the call with any amount of calling context then we want to
3213         use normal call IC's.
3214
3215         Since the builtin path wouldn't lead to a simpler patch and since I think that the VM will
3216         benefit in the long run from using custom handling for bound functions, I kept the native
3217         code and just added Intrinsic/thunk support.
3218
3219         This just adds an Intrinsic for bound function calls where the JSBoundFunction targets a
3220         JSFunction instance and has no bound arguments (only bound this). This intrinsic is
3221         currently only implemented as a thunk and not yet recognized by the DFG bytecode parser.
3222
3223         I needed to loosen some restrictions to do this. For one, I was really tired of our bad use
3224         of ENABLE(JIT) conditionals, which made it so that any serious client of Intrinsics would
3225         have to have #ifdefs. Really what should happen is that if the JIT is not enabled then we
3226         just ignore intrinsics. Also, the code was previously assuming that having a native
3227         constructor and knowing the Intrinsic for your native call were mutually exclusive. This
3228         change makes it possible to have a native executable that has a custom function, custom
3229         constructor, and an Intrinsic.
3230
3231         This is a >4x speed-up on bound function calls with no bound arguments.
3232
3233         In the future, we should teach the DFG Intrinsic handling to deal with bound functions and
3234         we should teach the inliner (and ByteCodeParser::handleCall() in general) how to deal with
3235         the function call inside the bound function. That would be super awesome.
3236
3237         * assembler/AbstractMacroAssembler.h:
3238         (JSC::AbstractMacroAssembler::timesPtr):
3239         (JSC::AbstractMacroAssembler::Address::withOffset):
3240         (JSC::AbstractMacroAssembler::BaseIndex::BaseIndex):
3241         (JSC::MacroAssemblerType>::Address::indexedBy):
3242         * jit/AssemblyHelpers.h:
3243         (JSC::AssemblyHelpers::storeCell):
3244         (JSC::AssemblyHelpers::loadCell):
3245         (JSC::AssemblyHelpers::storeValue):
3246         (JSC::AssemblyHelpers::emitSaveCalleeSaves):
3247         (JSC::AssemblyHelpers::emitSaveThenMaterializeTagRegisters):
3248         (JSC::AssemblyHelpers::emitRestoreCalleeSaves):
3249         (JSC::AssemblyHelpers::emitRestoreSavedTagRegisters):
3250         (JSC::AssemblyHelpers::copyCalleeSavesToVMCalleeSavesBuffer):
3251         * jit/JITThunks.cpp:
3252         (JSC::JITThunks::ctiNativeTailCall):
3253         (JSC::JITThunks::ctiNativeTailCallWithoutSavedTags):
3254         (JSC::JITThunks::ctiStub):
3255         (JSC::JITThunks::hostFunctionStub):
3256         (JSC::JITThunks::clearHostFunctionStubs):
3257         * jit/JITThunks.h:
3258         * jit/SpecializedThunkJIT.h:
3259         (JSC::SpecializedThunkJIT::callDoubleToDoublePreservingReturn):
3260         (JSC::SpecializedThunkJIT::tagReturnAsInt32):
3261         (JSC::SpecializedThunkJIT::emitSaveThenMaterializeTagRegisters): Deleted.
3262         (JSC::SpecializedThunkJIT::emitRestoreSavedTagRegisters): Deleted.
3263         * jit/ThunkGenerators.cpp:
3264         (JSC::virtualThunkFor):
3265         (JSC::nativeForGenerator):
3266         (JSC::nativeCallGenerator):
3267         (JSC::nativeTailCallGenerator):
3268         (JSC::nativeTailCallWithoutSavedTagsGenerator):
3269         (JSC::nativeConstructGenerator):
3270         (JSC::randomThunkGenerator):
3271         (JSC::boundThisNoArgsFunctionCallGenerator):
3272         * jit/ThunkGenerators.h:
3273         * runtime/Executable.cpp:
3274         (JSC::NativeExecutable::create):
3275         (JSC::NativeExecutable::destroy):
3276         (JSC::NativeExecutable::createStructure):
3277         (JSC::NativeExecutable::finishCreation):
3278         (JSC::NativeExecutable::NativeExecutable):
3279         (JSC::ScriptExecutable::ScriptExecutable):
3280         * runtime/Executable.h:
3281         * runtime/FunctionPrototype.cpp:
3282         (JSC::functionProtoFuncBind):
3283         * runtime/IntlCollatorPrototype.cpp:
3284         (JSC::IntlCollatorPrototypeGetterCompare):
3285         * runtime/Intrinsic.h:
3286         * runtime/JSBoundFunction.cpp:
3287         (JSC::boundThisNoArgsFunctionCall):
3288         (JSC::boundFunctionCall):
3289         (JSC::boundThisNoArgsFunctionConstruct):
3290         (JSC::boundFunctionConstruct):
3291         (JSC::getBoundFunctionStructure):
3292         (JSC::JSBoundFunction::create):