Source/JavaScriptCore/ChangeLog

   1 2016-04-12  Saam barati  <sbarati@apple.com>
   2
   3         Lets not iterate over the constant pool twice every time we link a code block
   4         https://bugs.webkit.org/show_bug.cgi?id=156517
   5
   6         Reviewed by Mark Lam.
   7
   8         I introduced a second iteration over the constant pool when I implemented
   9         block scoping. I did this because we must clone all the symbol tables when
  10         we link a CodeBlock. We can just do this cloning when setting the constant
  11         registers for the first time. There is no need to iterate over the constant
  12         pool a second time.
  13
  14         * bytecode/CodeBlock.cpp:
  15         (JSC::CodeBlock::finishCreation):
  16         (JSC::CodeBlock::~CodeBlock):
  17         (JSC::CodeBlock::setConstantRegisters):
  18         (JSC::CodeBlock::setAlternative):
  19         * bytecode/CodeBlock.h:
  20         (JSC::CodeBlock::replaceConstant):
  21         (JSC::CodeBlock::setConstantRegisters): Deleted.
  22
  23 2016-04-12  Mark Lam  <mark.lam@apple.com>
  24
  25         ES6: Implement String.prototype.split and RegExp.prototype[@@split].
  26         https://bugs.webkit.org/show_bug.cgi?id=156013
  27
  28         Reviewed by Keith Miller.
  29
  30         * CMakeLists.txt:
  31         * JavaScriptCore.xcodeproj/project.pbxproj:
  32         * builtins/GlobalObject.js:
  33         (speciesConstructor):
  34         * builtins/PromisePrototype.js:
  35         - refactored to use the @speciesConstructor internal function.
  36
  37         * builtins/RegExpPrototype.js:
  38         (advanceStringIndex):
  39         - refactored from @advanceStringIndexUnicode() to be match the spec.
  40           Benchmarks show that there's no advantage in doing the unicode check outside
  41           of the advanceStringIndexUnicode part.  So, I simplified the code to match the
  42           spec (especially since @@split needs to call advanceStringIndex from more than
  43           1 location).
  44         (match):
  45         - Removed an unnecessary call to @Object because it was already proven above.
  46         - Changed to use advanceStringIndex instead of advanceStringIndexUnicode.
  47           Again, there's no perf regression for this.
  48         (regExpExec):
  49         (hasObservableSideEffectsForRegExpSplit):
  50         (split):
  51         (advanceStringIndexUnicode): Deleted.
  52
  53         * builtins/StringPrototype.js:
  54         (split):
  55         - Modified to use RegExp.prototype[@@split].
  56
  57         * bytecode/BytecodeIntrinsicRegistry.cpp:
  58         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
  59         (JSC::BytecodeIntrinsicRegistry::lookup):
  60         * bytecode/BytecodeIntrinsicRegistry.h:
  61         - Added the @@split symbol.
  62
  63         * runtime/CommonIdentifiers.h:
  64         * runtime/ECMAScriptSpecInternalFunctions.cpp: Added.
  65         (JSC::esSpecIsConstructor):
  66         (JSC::esSpecIsRegExp):
  67         * runtime/ECMAScriptSpecInternalFunctions.h: Added.
  68
  69         * runtime/JSGlobalObject.cpp:
  70         (JSC::getGetterById):
  71         (JSC::JSGlobalObject::init):
  72
  73         * runtime/PropertyDescriptor.cpp:
  74         (JSC::PropertyDescriptor::setDescriptor):
  75         - Removed an assert that is no longer valid.
  76
  77         * runtime/RegExpObject.h:
  78         - Made advanceStringUnicode() public so that it can be re-used by the regexp split
  79           fast path.
  80
  81         * runtime/RegExpPrototype.cpp:
  82         (JSC::RegExpPrototype::finishCreation):
  83         (JSC::regExpProtoFuncExec):
  84         (JSC::regExpProtoFuncSearch):
  85         (JSC::advanceStringIndex):
  86         (JSC::regExpProtoFuncSplitFast):
  87         * runtime/RegExpPrototype.h:
  88
  89         * runtime/StringObject.h:
  90         (JSC::jsStringWithReuse):
  91         (JSC::jsSubstring):
  92         - Hoisted some utility functions from StringPrototype.cpp so that they can be
  93           reused by the regexp split fast path.
  94
  95         * runtime/StringPrototype.cpp:
  96         (JSC::StringPrototype::finishCreation):
  97         (JSC::stringProtoFuncSplitFast):
  98         (JSC::stringProtoFuncSubstr):
  99         (JSC::builtinStringSubstrInternal):
 100         (JSC::stringProtoFuncSubstring):
 101         (JSC::stringIncludesImpl):
 102         (JSC::stringProtoFuncIncludes):
 103         (JSC::builtinStringIncludesInternal):
 104         (JSC::jsStringWithReuse): Deleted.
 105         (JSC::jsSubstring): Deleted.
 106         (JSC::stringProtoFuncSplit): Deleted.
 107         * runtime/StringPrototype.h:
 108
 109         * tests/es6.yaml:
 110
 111 2016-04-12  Keith Miller  <keith_miller@apple.com>
 112
 113         AbstractValue should use the result type to filter structures
 114         https://bugs.webkit.org/show_bug.cgi?id=156516
 115
 116         Reviewed by Geoffrey Garen.
 117
 118         When filtering an AbstractValue with a SpeculatedType we would not use the merged type when
 119         filtering out the valid structures (despite what the comment directly above said). This
 120         would cause us to crash if our structure-set was Top and the two speculated types were
 121         different kinds of cells.
 122
 123         * dfg/DFGAbstractValue.cpp:
 124         (JSC::DFG::AbstractValue::filter):
 125         * tests/stress/ai-consistency-filter-cells.js: Added.
 126         (get value):
 127         (attribute.value.get record):
 128         (attribute.attrs.get this):
 129         (get foo):
 130         (let.thisValue.return.serialize):
 131         (let.thisValue.transformFor):
 132
 133 2016-04-12  Filip Pizlo  <fpizlo@apple.com>
 134
 135         Unreviewed, remove FIXME for https://bugs.webkit.org/show_bug.cgi?id=156457 and replace it
 136         with a comment that describes what we do now.
 137
 138         * bytecode/PolymorphicAccess.h:
 139
 140 2016-04-12  Saam barati  <sbarati@apple.com>
 141
 142         isLocked() assertion broke builds because ConcurrentJITLock isn't always a real lock.
 143
 144         Rubber-stamped by Filip Pizlo.
 145
 146         * bytecode/CodeBlock.cpp:
 147         (JSC::CodeBlock::resultProfileForBytecodeOffset):
 148         (JSC::CodeBlock::ensureResultProfile):
 149
 150 2016-04-11  Filip Pizlo  <fpizlo@apple.com>
 151
 152         PolymorphicAccess should buffer AccessCases before regenerating
 153         https://bugs.webkit.org/show_bug.cgi?id=156457
 154
 155         Reviewed by Benjamin Poulain.
 156
 157         Prior to this change, whenever we added an AccessCase to a PolymorphicAccess, we would
 158         regenerate the whole stub. That meant that we'd do O(N^2) work for N access cases.
 159
 160         One way to fix this is to have each AccessCase generate a stub just for itself, which
 161         cascades down to the already-generated cases. But that removes the binary switch
 162         optimization, which makes the IC perform great even when there are many cases.
 163
 164         This change fixes the issue by buffering access cases. When we take slow path and try to add
 165         a new case, the StructureStubInfo will usually just buffer the new case without generating
 166         new code. We simply guarantee that after we buffer a case, we will take at most
 167         Options::repatchBufferingCountdown() slow path calls before generating code for it. That
 168         option is currently 7. Taking 7 more slow paths means that we have 7 more opportunities to
 169         gather more access cases, or to realize that this IC is too crazy to bother with.
 170
 171         This change ensures that the DFG still gets the same kind of profiling. This is because the
 172         buffered AccessCases are still part of PolymorphicAccess and so are still scanned by
 173         GetByIdStatus and PutByIdStatus. The fact that the AccessCases hadn't been generated and so
 174         hadn't executed doesn't change much. Mainly, it increases the likelihood that the DFG will
 175         see an access case that !couldStillSucceed(). The DFG's existing profile parsing logic can
 176         handle this just fine.
 177
 178         There are a bunch of algorithmic changes here. StructureStubInfo now caches the set of
 179         structures that it has seen as a guard to prevent adding lots of redundant cases, in case
 180         we see the same 7 cases after buffering the first one. This cache means we won't wastefully
 181         allocate 7 identical AccessCase instances. PolymorphicAccess is now restructured around
 182         having separate addCase() and regenerate() calls. That means a bit more moving data around.
 183         So far that seems OK for performance, probably since it's O(N) work rather than O(N^2) work.
 184         There is room for improvement for future patches, to be sure.
 185
 186         This is benchmarking as slightly positive or neutral on JS benchmarks. It's meant to reduce
 187         pathologies I saw in page loads.
 188
 189         * bytecode/GetByIdStatus.cpp:
 190         (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
 191         * bytecode/PolymorphicAccess.cpp:
 192         (JSC::PolymorphicAccess::PolymorphicAccess):
 193         (JSC::PolymorphicAccess::~PolymorphicAccess):
 194         (JSC::PolymorphicAccess::addCases):
 195         (JSC::PolymorphicAccess::addCase):
 196         (JSC::PolymorphicAccess::visitWeak):
 197         (JSC::PolymorphicAccess::dump):
 198         (JSC::PolymorphicAccess::commit):
 199         (JSC::PolymorphicAccess::regenerate):
 200         (JSC::PolymorphicAccess::aboutToDie):
 201         (WTF::printInternal):
 202         (JSC::PolymorphicAccess::regenerateWithCases): Deleted.
 203         (JSC::PolymorphicAccess::regenerateWithCase): Deleted.
 204         * bytecode/PolymorphicAccess.h:
 205         (JSC::AccessCase::isGetter):
 206         (JSC::AccessCase::callLinkInfo):
 207         (JSC::AccessGenerationResult::AccessGenerationResult):
 208         (JSC::AccessGenerationResult::madeNoChanges):
 209         (JSC::AccessGenerationResult::gaveUp):
 210         (JSC::AccessGenerationResult::buffered):
 211         (JSC::AccessGenerationResult::generatedNewCode):
 212         (JSC::AccessGenerationResult::generatedFinalCode):
 213         (JSC::AccessGenerationResult::shouldGiveUpNow):
 214         (JSC::AccessGenerationResult::generatedSomeCode):
 215         (JSC::PolymorphicAccess::isEmpty):
 216         (JSC::PolymorphicAccess::size):
 217         (JSC::PolymorphicAccess::at):
 218         * bytecode/PutByIdStatus.cpp:
 219         (JSC::PutByIdStatus::computeForStubInfo):
 220         * bytecode/StructureStubInfo.cpp:
 221         (JSC::StructureStubInfo::StructureStubInfo):
 222         (JSC::StructureStubInfo::addAccessCase):
 223         (JSC::StructureStubInfo::reset):
 224         (JSC::StructureStubInfo::visitWeakReferences):
 225         * bytecode/StructureStubInfo.h:
 226         (JSC::StructureStubInfo::considerCaching):
 227         (JSC::StructureStubInfo::willRepatch): Deleted.
 228         (JSC::StructureStubInfo::willCoolDown): Deleted.
 229         * jit/JITOperations.cpp:
 230         * jit/Repatch.cpp:
 231         (JSC::tryCacheGetByID):
 232         (JSC::repatchGetByID):
 233         (JSC::tryCachePutByID):
 234         (JSC::repatchPutByID):
 235         (JSC::tryRepatchIn):
 236         (JSC::repatchIn):
 237         * runtime/JSCJSValue.h:
 238         * runtime/JSCJSValueInlines.h:
 239         (JSC::JSValue::putByIndex):
 240         (JSC::JSValue::structureOrNull):
 241         (JSC::JSValue::structureOrUndefined):
 242         * runtime/Options.h:
 243
 244 2016-04-12  Saam barati  <sbarati@apple.com>
 245
 246         There is a race with the compiler thread and the main thread with result profiles
 247         https://bugs.webkit.org/show_bug.cgi?id=156503
 248
 249         Reviewed by Filip Pizlo.
 250
 251         The compiler thread should not be asking for a result
 252         profile while the execution thread is creating one.
 253         We must guard against such races with a lock.
 254
 255         * bytecode/CodeBlock.cpp:
 256         (JSC::CodeBlock::resultProfileForBytecodeOffset):
 257         (JSC::CodeBlock::ensureResultProfile):
 258         (JSC::CodeBlock::capabilityLevel):
 259         * bytecode/CodeBlock.h:
 260         (JSC::CodeBlock::couldTakeSlowCase):
 261         (JSC::CodeBlock::numberOfResultProfiles):
 262         (JSC::CodeBlock::specialFastCaseProfileCountForBytecodeOffset):
 263         (JSC::CodeBlock::ensureResultProfile): Deleted.
 264
 265 2016-04-12  Commit Queue  <commit-queue@webkit.org>
 266
 267         Unreviewed, rolling out r199339.
 268         https://bugs.webkit.org/show_bug.cgi?id=156505
 269
 270         memset_s is indeed necessary (Requested by alexchristensen_ on
 271         #webkit).
 272
 273         Reverted changeset:
 274
 275         "Build fix after r199299."
 276         https://bugs.webkit.org/show_bug.cgi?id=155508
 277         http://trac.webkit.org/changeset/199339
 278
 279 2016-04-12  Guillaume Emont  <guijemont@igalia.com>
 280
 281         MIPS: add MacroAssemblerMIPS::store8(TrustedImm32,ImplicitAddress)
 282         https://bugs.webkit.org/show_bug.cgi?id=156481
 283
 284         This method with this signature is used by r199075, and therefore
 285         WebKit doesn't build on MIPS since then.
 286
 287         Reviewed by Mark Lam.
 288
 289         * assembler/MacroAssemblerMIPS.h:
 290         (JSC::MacroAssemblerMIPS::store8):
 291
 292 2016-04-12  Saam barati  <sbarati@apple.com>
 293
 294         We incorrectly parse arrow function expressions
 295         https://bugs.webkit.org/show_bug.cgi?id=156373
 296
 297         Reviewed by Mark Lam.
 298
 299         This patch removes the notion of "isEndOfArrowFunction".
 300         This was a very weird function and it was incorrect.
 301         It checked that the arrow functions with concise body
 302         grammar production "had a valid ending". "had a valid
 303         ending" is in quotes because concise body arrow functions
 304         have a valid ending as long as their body has a valid
 305         assignment expression. I've removed all notion of this
 306         function because it was wrong and was causing us
 307         to throw syntax errors on valid programs.
 308
 309         * parser/Lexer.cpp:
 310         (JSC::Lexer<T>::nextTokenIsColon):
 311         (JSC::Lexer<T>::lex):
 312         (JSC::Lexer<T>::setTokenPosition): Deleted.
 313         * parser/Lexer.h:
 314         (JSC::Lexer::setIsReparsingFunction):
 315         (JSC::Lexer::isReparsingFunction):
 316         (JSC::Lexer::lineNumber):
 317         * parser/Parser.cpp:
 318         (JSC::Parser<LexerType>::parseInner):
 319         (JSC::Parser<LexerType>::parseArrowFunctionSingleExpressionBodySourceElements):
 320         (JSC::Parser<LexerType>::parseFunctionInfo):
 321         * parser/Parser.h:
 322         (JSC::Parser::matchIdentifierOrKeyword):
 323         (JSC::Parser::tokenStart):
 324         (JSC::Parser::autoSemiColon):
 325         (JSC::Parser::canRecurse):
 326         (JSC::Parser::isEndOfArrowFunction): Deleted.
 327         (JSC::Parser::setEndOfStatement): Deleted.
 328         * tests/stress/arrowfunction-others.js:
 329         (testCase):
 330         (simpleArrowFunction):
 331         (truthy):
 332         (falsey):
 333
 334 2016-04-12  Yusuke Suzuki  <utatane.tea@gmail.com>
 335
 336         [JSC] addStaticGlobals should emit SymbolTableEntry watchpoints to encourage constant folding in DFG
 337         https://bugs.webkit.org/show_bug.cgi?id=155110
 338
 339         Reviewed by Saam Barati.
 340
 341         `addStaticGlobals` does not emit SymbolTableEntry watchpoints for the added entries.
 342         So, all the global variable lookups pointing to these static globals are not converted
 343         into constants in DFGBytecodeGenerator: this fact leaves these lookups as GetGlobalVar.
 344         Such thing avoids constant folding chance and emits CheckCell for @privateFunction inlining.
 345         This operation is pure overhead.
 346
 347         Static globals are not configurable, and they are typically non-writable.
 348         So they are constants in almost all the cases.
 349
 350         This patch initializes watchpoints for these static globals.
 351         These watchpoints allow DFG to convert these nodes into constants in DFG BytecodeParser.
 352         These watchpoints includes many builtin operations and `undefined`.
 353
 354         The microbenchmark, many-foreach-calls shows 5 - 7% improvement since it removes unnecessary CheckCell.
 355
 356         * bytecode/VariableWriteFireDetail.h:
 357         * runtime/JSGlobalObject.cpp:
 358         (JSC::JSGlobalObject::addGlobalVar):
 359         (JSC::JSGlobalObject::addStaticGlobals):
 360         * runtime/JSSymbolTableObject.h:
 361         (JSC::symbolTablePutTouchWatchpointSet):
 362         (JSC::symbolTablePutInvalidateWatchpointSet):
 363         (JSC::symbolTablePut):
 364         (JSC::symbolTablePutWithAttributesTouchWatchpointSet): Deleted.
 365         * runtime/SymbolTable.h:
 366         (JSC::SymbolTableEntry::SymbolTableEntry):
 367         (JSC::SymbolTableEntry::operator=):
 368         (JSC::SymbolTableEntry::swap):
 369
 370 2016-04-12  Alex Christensen  <achristensen@webkit.org>
 371
 372         Build fix after r199299.
 373         https://bugs.webkit.org/show_bug.cgi?id=155508
 374
 375         * jit/ExecutableAllocatorFixedVMPool.cpp:
 376         (JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps):
 377         memset_s is not defined.  __STDC_WANT_LIB_EXT1__ is not defined anywhere.
 378         Since the return value is unused and set_constraint_handler_s is never called
 379         I'm chaning it to memset.
 380
 381 2016-04-11  Benjamin Poulain  <bpoulain@apple.com>
 382
 383         [JSC] B3 can use undefined bits or not defined required bits when spilling
 384         https://bugs.webkit.org/show_bug.cgi?id=156486
 385
 386         Reviewed by Filip Pizlo.
 387
 388         Spilling had issues when replacing arguments in place.
 389
 390         The problems are:
 391         1) If we have a 32bit stackslot, a x86 instruction could still try to load 64bits from it.
 392         2) If we have a 64bit stackslot, Move32 would only set half the bits.
 393         3) We were reducing Move to Move32 even if the top bits are read from the stack slot.
 394
 395         The case 1 appear with something like this:
 396             Move32 %tmp0, %tmp1
 397             Op64 %tmp1, %tmp2, %tmp3
 398         When we spill %tmp1, the stack slot is 32bit, Move32 sets 32bits
 399         but Op64 supports addressing for %tmp1. When we substitute %tmp1 in Op64,
 400         we are creating a 64bit read for a 32bit stack slot.
 401
 402         The case 2 is an other common one. If we have:
 403             BB#1
 404                 Move32 %tmp0, %tmp1
 405                 Jump #3
 406             BB#2
 407                 Op64 %tmp0, %tmp1
 408                 Jump #3
 409             BB#3
 410                 Use64 %tmp1
 411
 412         We have a stack slot of 64bits. When spilling %tmp1 in #1, we are
 413         effectively doing a 32bit store on the stack slot, leaving the top bits undefined.
 414
 415         Case 3 is pretty much the same as 2 but we create the Move32 ourself
 416         because the source is a 32bit with ZDef.
 417
 418         Case (1) is solved by requiring that the stack slot is at least as large as the largest
 419         use/def of that tmp.
 420
 421         Case (2) and (3) are solved by not replacing a Tmp by an Address if the Def
 422         is smaller than the stack slot.
 423
 424         * b3/air/AirIteratedRegisterCoalescing.cpp:
 425         * b3/testb3.cpp:
 426         (JSC::B3::testSpillDefSmallerThanUse):
 427         (JSC::B3::testSpillUseLargerThanDef):
 428         (JSC::B3::run):
 429
 430 2016-04-11  Brian Burg  <bburg@apple.com>
 431
 432         Web Inspector: get rid of InspectorBasicValue and InspectorString subclasses
 433         https://bugs.webkit.org/show_bug.cgi?id=156407
 434         <rdar://problem/25627659>
 435
 436         Reviewed by Joseph Pecoraro.
 437
 438         There's no point having these subclasses as they don't save any space.
 439         Add a StringImpl to the union and merge some implementations of writeJSON.
 440
 441         Rename m_data to m_map and explicitly name the union as InspectorValue::m_value.
 442         If the value is a string and the string is not empty or null (i.e., it has a
 443         StringImpl), then we need to ref() and deref() the string as the InspectorValue
 444         is created or destroyed.
 445
 446         Move uses of the subclass to InspectorValue and delete redundant methods.
 447         Now, most InspectorValue methods are non-virtual so they can be templated.
 448
 449         * bindings/ScriptValue.cpp:
 450         (Deprecated::jsToInspectorValue):
 451         * inspector/InjectedScriptBase.cpp:
 452         (Inspector::InjectedScriptBase::makeCall):
 453         Don't used deleted subclasses.
 454
 455         * inspector/InspectorValues.cpp:
 456         (Inspector::InspectorValue::null):
 457         (Inspector::InspectorValue::create):
 458         (Inspector::InspectorValue::asValue):
 459         (Inspector::InspectorValue::asBoolean):
 460         (Inspector::InspectorValue::asDouble):
 461         (Inspector::InspectorValue::asInteger):
 462         (Inspector::InspectorValue::asString):
 463         These only need one implementation now.
 464
 465         (Inspector::InspectorValue::writeJSON):
 466         Still a virtual method since Object and Array need their members.
 467
 468         (Inspector::InspectorObjectBase::InspectorObjectBase):
 469         (Inspector::InspectorBasicValue::asBoolean): Deleted.
 470         (Inspector::InspectorBasicValue::asDouble): Deleted.
 471         (Inspector::InspectorBasicValue::asInteger): Deleted.
 472         (Inspector::InspectorBasicValue::writeJSON): Deleted.
 473         (Inspector::InspectorString::asString): Deleted.
 474         (Inspector::InspectorString::writeJSON): Deleted.
 475         (Inspector::InspectorString::create): Deleted.
 476         (Inspector::InspectorBasicValue::create): Deleted.
 477
 478         * inspector/InspectorValues.h:
 479         (Inspector::InspectorObjectBase::find):
 480         (Inspector::InspectorObjectBase::setBoolean):
 481         (Inspector::InspectorObjectBase::setInteger):
 482         (Inspector::InspectorObjectBase::setDouble):
 483         (Inspector::InspectorObjectBase::setString):
 484         (Inspector::InspectorObjectBase::setValue):
 485         (Inspector::InspectorObjectBase::setObject):
 486         (Inspector::InspectorObjectBase::setArray):
 487         (Inspector::InspectorArrayBase::pushBoolean):
 488         (Inspector::InspectorArrayBase::pushInteger):
 489         (Inspector::InspectorArrayBase::pushDouble):
 490         (Inspector::InspectorArrayBase::pushString):
 491         (Inspector::InspectorArrayBase::pushValue):
 492         (Inspector::InspectorArrayBase::pushObject):
 493         (Inspector::InspectorArrayBase::pushArray):
 494         Use new factory methods.
 495
 496         * replay/EncodedValue.cpp:
 497         (JSC::ScalarEncodingTraits<bool>::encodeValue):
 498         (JSC::ScalarEncodingTraits<double>::encodeValue):
 499         (JSC::ScalarEncodingTraits<float>::encodeValue):
 500         (JSC::ScalarEncodingTraits<int32_t>::encodeValue):
 501         (JSC::ScalarEncodingTraits<int64_t>::encodeValue):
 502         (JSC::ScalarEncodingTraits<uint32_t>::encodeValue):
 503         (JSC::ScalarEncodingTraits<uint64_t>::encodeValue):
 504         * replay/EncodedValue.h:
 505         Use new factory methods.
 506
 507 2016-04-11  Filip Pizlo  <fpizlo@apple.com>
 508
 509         It should be possible to edit StructureStubInfo without recompiling the world
 510         https://bugs.webkit.org/show_bug.cgi?id=156470
 511
 512         Reviewed by Keith Miller.
 513
 514         This change makes it less painful to make changes to the IC code. It used to be that any
 515         change to StructureStubInfo caused every JIT-related file to get recompiled. Now only a
 516         smaller set of files - ones that actually peek into StructureStubInfo - will recompile. This
 517         is mainly because CodeBlock.h no longer includes StructureStubInfo.h.
 518
 519         * bytecode/ByValInfo.h:
 520         * bytecode/CodeBlock.cpp:
 521         * bytecode/CodeBlock.h:
 522         * bytecode/GetByIdStatus.cpp:
 523         * bytecode/GetByIdStatus.h:
 524         * bytecode/PutByIdStatus.cpp:
 525         * bytecode/PutByIdStatus.h:
 526         * bytecode/StructureStubInfo.h:
 527         (JSC::getStructureStubInfoCodeOrigin):
 528         * dfg/DFGByteCodeParser.cpp:
 529         * dfg/DFGJITCompiler.cpp:
 530         * dfg/DFGOSRExitCompilerCommon.cpp:
 531         * dfg/DFGSpeculativeJIT.h:
 532         * ftl/FTLLowerDFGToB3.cpp:
 533         * ftl/FTLSlowPathCall.h:
 534         * jit/IntrinsicEmitter.cpp:
 535         * jit/JITInlineCacheGenerator.cpp:
 536         * jit/JITInlineCacheGenerator.h:
 537         * jit/JITOperations.cpp:
 538         * jit/JITPropertyAccess.cpp:
 539         * jit/JITPropertyAccess32_64.cpp:
 540
 541 2016-04-11  Skachkov Oleksandr  <gskachkov@gmail.com>
 542
 543         Remove NewArrowFunction from DFG IR
 544         https://bugs.webkit.org/show_bug.cgi?id=156439
 545
 546         Reviewed by Saam Barati.
 547
 548         It seems that NewArrowFunction was left in DFG IR during refactoring by mistake.
 549
 550         * dfg/DFGAbstractInterpreterInlines.h:
 551         * dfg/DFGClobberize.h:
 552         (JSC::DFG::clobberize):
 553         * dfg/DFGClobbersExitState.cpp:
 554         * dfg/DFGDoesGC.cpp:
 555         * dfg/DFGFixupPhase.cpp:
 556         * dfg/DFGMayExit.cpp:
 557         * dfg/DFGNode.h:
 558         (JSC::DFG::Node::convertToPhantomNewFunction):
 559         * dfg/DFGNodeType.h:
 560         * dfg/DFGObjectAllocationSinkingPhase.cpp:
 561         * dfg/DFGPredictionPropagationPhase.cpp:
 562         * dfg/DFGSafeToExecute.h:
 563         * dfg/DFGSpeculativeJIT.cpp:
 564         (JSC::DFG::SpeculativeJIT::compileNewFunction):
 565         * dfg/DFGSpeculativeJIT32_64.cpp:
 566         * dfg/DFGSpeculativeJIT64.cpp:
 567         * dfg/DFGStoreBarrierInsertionPhase.cpp:
 568         * dfg/DFGStructureRegistrationPhase.cpp:
 569         * ftl/FTLCapabilities.cpp:
 570         * ftl/FTLLowerDFGToB3.cpp:
 571         (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
 572
 573 2016-04-05  Oliver Hunt  <oliver@apple.com>
 574
 575         Remove compile time define for SEPARATED_HEAP
 576         https://bugs.webkit.org/show_bug.cgi?id=155508
 577
 578         Reviewed by Mark Lam.
 579
 580         Remove the SEPARATED_HEAP compile time flag. The separated
 581         heap is available, but off by default, on x86_64, ARMv7, and
 582         ARM64.
 583
 584         Working through the issues that happened last time essentially
 585         required implementing the ARMv7 path for the separated heap
 586         just so I could find all the ways it was going wrong.
 587
 588         We fixed all the logic by making the branch and jump logic in
 589         the linker and assemblers take two parameters, the location to
 590         write to, and the location we'll actually be writing to. We
 591         need to do this because it's no longer sufficient to compute
 592         jumps relative to region the linker is writing to.
 593
 594         The repatching jump, branch, and call functions only need the
 595         executable address as the patching is performed directly using
 596         performJITMemcpy function which works in terms of the executable
 597         address.
 598
 599         There is no performance impact on jsc-benchmarks with the separate
 600         heap either emabled or disabled.
 601
 602         * Configurations/FeatureDefines.xcconfig:
 603         * assembler/ARM64Assembler.h:
 604         (JSC::ARM64Assembler::linkJump):
 605         (JSC::ARM64Assembler::linkCall):
 606         (JSC::ARM64Assembler::relinkJump):
 607         (JSC::ARM64Assembler::relinkCall):
 608         (JSC::ARM64Assembler::link):
 609         (JSC::ARM64Assembler::linkJumpOrCall):
 610         (JSC::ARM64Assembler::linkCompareAndBranch):
 611         (JSC::ARM64Assembler::linkConditionalBranch):
 612         (JSC::ARM64Assembler::linkTestAndBranch):
 613         (JSC::ARM64Assembler::relinkJumpOrCall):
 614         * assembler/ARMv7Assembler.h:
 615         (JSC::ARMv7Assembler::revertJumpTo_movT3movtcmpT2):
 616         (JSC::ARMv7Assembler::revertJumpTo_movT3):
 617         (JSC::ARMv7Assembler::link):
 618         (JSC::ARMv7Assembler::linkJump):
 619         (JSC::ARMv7Assembler::relinkJump):
 620         (JSC::ARMv7Assembler::repatchCompact):
 621         (JSC::ARMv7Assembler::replaceWithJump):
 622         (JSC::ARMv7Assembler::replaceWithLoad):
 623         (JSC::ARMv7Assembler::replaceWithAddressComputation):
 624         (JSC::ARMv7Assembler::setInt32):
 625         (JSC::ARMv7Assembler::setUInt7ForLoad):
 626         (JSC::ARMv7Assembler::isB):
 627         (JSC::ARMv7Assembler::isBX):
 628         (JSC::ARMv7Assembler::isMOV_imm_T3):
 629         (JSC::ARMv7Assembler::isMOVT):
 630         (JSC::ARMv7Assembler::isNOP_T1):
 631         (JSC::ARMv7Assembler::isNOP_T2):
 632         (JSC::ARMv7Assembler::linkJumpT1):
 633         (JSC::ARMv7Assembler::linkJumpT2):
 634         (JSC::ARMv7Assembler::linkJumpT3):
 635         (JSC::ARMv7Assembler::linkJumpT4):
 636         (JSC::ARMv7Assembler::linkConditionalJumpT4):
 637         (JSC::ARMv7Assembler::linkBX):
 638         (JSC::ARMv7Assembler::linkConditionalBX):
 639         (JSC::ARMv7Assembler::linkJumpAbsolute):
 640         * assembler/LinkBuffer.cpp:
 641         (JSC::LinkBuffer::copyCompactAndLinkCode):
 642         * assembler/MacroAssemblerARM64.h:
 643         (JSC::MacroAssemblerARM64::link):
 644         * assembler/MacroAssemblerARMv7.h:
 645         (JSC::MacroAssemblerARMv7::link):
 646         * jit/ExecutableAllocator.h:
 647         (JSC::performJITMemcpy):
 648         * jit/ExecutableAllocatorFixedVMPool.cpp:
 649         (JSC::FixedVMPoolExecutableAllocator::initializeSeparatedWXHeaps):
 650         (JSC::FixedVMPoolExecutableAllocator::jitWriteThunkGenerator):
 651         (JSC::FixedVMPoolExecutableAllocator::genericWriteToJITRegion):
 652         (JSC::FixedVMPoolExecutableAllocator::FixedVMPoolExecutableAllocator): Deleted.
 653         * runtime/Options.cpp:
 654         (JSC::recomputeDependentOptions):
 655         * runtime/Options.h:
 656
 657 2016-04-10  Filip Pizlo  <fpizlo@apple.com>
 658
 659         Clean up how we reason about the states of AccessCases
 660         https://bugs.webkit.org/show_bug.cgi?id=156454
 661
 662         Reviewed by Mark Lam.
 663
 664         Currently when we add an AccessCase to a PolymorphicAccess stub, we regenerate the stub.
 665         That means that as we grow a stub to have N cases, we will do O(N^2) generation work. I want
 666         to explore buffering AccessCases so that we can do O(N) generation work instead. But to
 667         before I go there, I want to make sure that the statefulness of AccessCase makes sense. So,
 668         I broke it down into three different states and added assertions about the transitions. I
 669         also broke out a separate operation called AccessCase::commit(), which is the work that
 670         cannot be buffered since there cannot be any JS effects between when the AccessCase was
 671         created and when we do the work in commit().
 672
 673         This opens up a fairly obvious path to buffering AccessCases: add them to the list without
 674         regenerating. Then when we do eventually trigger regeneration, those cases will get cloned
 675         and generated automagically. This patch doesn't implement this technique yet, but gives us
 676         an opportunity to independently test the scaffolding necessary to do it.
 677
 678         This is perf-neutral on lots of tests.
 679
 680         * bytecode/PolymorphicAccess.cpp:
 681         (JSC::AccessGenerationResult::dump):
 682         (JSC::AccessCase::clone):
 683         (JSC::AccessCase::commit):
 684         (JSC::AccessCase::guardedByStructureCheck):
 685         (JSC::AccessCase::dump):
 686         (JSC::AccessCase::generateWithGuard):
 687         (JSC::AccessCase::generate):
 688         (JSC::AccessCase::generateImpl):
 689         (JSC::PolymorphicAccess::regenerateWithCases):
 690         (JSC::PolymorphicAccess::regenerate):
 691         (WTF::printInternal):
 692         * bytecode/PolymorphicAccess.h:
 693         (JSC::AccessCase::type):
 694         (JSC::AccessCase::state):
 695         (JSC::AccessCase::offset):
 696         (JSC::AccessCase::viaProxy):
 697         (JSC::AccessCase::callLinkInfo):
 698         * bytecode/StructureStubInfo.cpp:
 699         (JSC::StructureStubInfo::addAccessCase):
 700         * bytecode/Watchpoint.h:
 701         * dfg/DFGOperations.cpp:
 702         * jit/Repatch.cpp:
 703         (JSC::repatchGetByID):
 704         (JSC::repatchPutByID):
 705         (JSC::repatchIn):
 706         * runtime/VM.cpp:
 707         (JSC::VM::dumpRegExpTrace):
 708         (JSC::VM::ensureWatchpointSetForImpureProperty):
 709         (JSC::VM::registerWatchpointForImpureProperty):
 710         (JSC::VM::addImpureProperty):
 711         * runtime/VM.h:
 712
 713 2016-04-11  Fujii Hironori  <Hironori.Fujii@jp.sony.com>
 714
 715         [CMake] Make FOLDER property INHERITED
 716         https://bugs.webkit.org/show_bug.cgi?id=156460
 717
 718         Reviewed by Brent Fulgham.
 719
 720         * CMakeLists.txt:
 721         * shell/CMakeLists.txt:
 722         * shell/PlatformWin.cmake:
 723         Set FOLDER property as a directory property not a target property
 724
 725 2016-04-09  Keith Miller  <keith_miller@apple.com>
 726
 727         tryGetById should be supported by the DFG/FTL
 728         https://bugs.webkit.org/show_bug.cgi?id=156378
 729
 730         Reviewed by Filip Pizlo.
 731
 732         This patch adds support for tryGetById in the DFG/FTL. It adds a new DFG node
 733         TryGetById, which acts similarly to the normal GetById DFG node. One key
 734         difference between GetById and TryGetById is that in the LLInt and Baseline
 735         we do not profile the result type. This profiling is unnessary for the current
 736         use case of tryGetById, which is expected to be a strict equality comparision
 737         against a specific object or undefined. In either case other DFG optimizations
 738         will make this equally fast with or without the profiling information.
 739
 740         Additionally, this patch adds new reuse modes for JSValueRegsTemporary that take
 741         an operand and attempt to reuse the registers for that operand if they are free
 742         after the current DFG node.
 743
 744         * bytecode/GetByIdStatus.cpp:
 745         (JSC::GetByIdStatus::computeFromLLInt):
 746         (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
 747         * dfg/DFGAbstractInterpreterInlines.h:
 748         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
 749         * dfg/DFGByteCodeParser.cpp:
 750         (JSC::DFG::ByteCodeParser::handleGetById):
 751         (JSC::DFG::ByteCodeParser::parseBlock):
 752         * dfg/DFGCapabilities.cpp:
 753         (JSC::DFG::capabilityLevel):
 754         * dfg/DFGClobberize.h:
 755         (JSC::DFG::clobberize):
 756         * dfg/DFGDoesGC.cpp:
 757         (JSC::DFG::doesGC):
 758         * dfg/DFGFixupPhase.cpp:
 759         (JSC::DFG::FixupPhase::fixupNode):
 760         * dfg/DFGNode.h:
 761         (JSC::DFG::Node::hasIdentifier):
 762         * dfg/DFGNodeType.h:
 763         * dfg/DFGPredictionPropagationPhase.cpp:
 764         (JSC::DFG::PredictionPropagationPhase::propagate):
 765         * dfg/DFGSafeToExecute.h:
 766         (JSC::DFG::safeToExecute):
 767         * dfg/DFGSpeculativeJIT.cpp:
 768         (JSC::DFG::SpeculativeJIT::compileTryGetById):
 769         (JSC::DFG::JSValueRegsTemporary::JSValueRegsTemporary):
 770         * dfg/DFGSpeculativeJIT.h:
 771         (JSC::DFG::GPRTemporary::operator=):
 772         * dfg/DFGSpeculativeJIT32_64.cpp:
 773         (JSC::DFG::SpeculativeJIT::cachedGetById):
 774         (JSC::DFG::SpeculativeJIT::compile):
 775         * dfg/DFGSpeculativeJIT64.cpp:
 776         (JSC::DFG::SpeculativeJIT::cachedGetById):
 777         (JSC::DFG::SpeculativeJIT::compile):
 778         * ftl/FTLCapabilities.cpp:
 779         (JSC::FTL::canCompile):
 780         * ftl/FTLLowerDFGToB3.cpp:
 781         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
 782         (JSC::FTL::DFG::LowerDFGToB3::compileGetById):
 783         (JSC::FTL::DFG::LowerDFGToB3::getById):
 784         * jit/JITOperations.cpp:
 785         * jit/JITOperations.h:
 786         * tests/stress/try-get-by-id.js:
 787         (tryGetByIdTextStrict):
 788         (get let):
 789         (let.get createBuiltin):
 790         (get throw):
 791         (getCaller.obj.1.throw.new.Error): Deleted.
 792
 793 2016-04-09  Saam barati  <sbarati@apple.com>
 794
 795         Allocation sinking SSA Defs are allowed to have replacements
 796         https://bugs.webkit.org/show_bug.cgi?id=156444
 797
 798         Reviewed by Filip Pizlo.
 799
 800         Consider the following program and the annotations that explain why
 801         the SSA defs we create in allocation sinking can have replacements.
 802
 803         function foo(a1) {
 804             let o1 = {x: 20, y: 50};
 805             let o2 = {y: 40, o1: o1};
 806             let o3 = {};
 807
 808             // We're Defing a new variable here, call it o3_field.
 809             // o3_field is defing the value that is the result of
 810             // a GetByOffset that gets eliminated through allocation sinking.
 811             o3.field = o1.y;
 812
 813             dontCSE();
 814
 815             // This control flow is here to not allow the phase to consult
 816             // its local SSA mapping (which properly handles replacements)
 817             // for the value of o3_field.
 818             if (a1) {
 819                 a1 = true;
 820             } else {
 821                 a1 = false;
 822             }
 823
 824             // Here, we ask for the reaching def of o3_field, and assert
 825             // it doesn't have a replacement. It does have a replacement
 826             // though. The original Def was the GetByOffset. We replaced
 827             // that GetByOffset with the value of the o1_y variable.
 828             let value = o3.field;
 829             assert(value === 50);
 830         }
 831
 832         * dfg/DFGObjectAllocationSinkingPhase.cpp:
 833         * tests/stress/allocation-sinking-defs-may-have-replacements.js: Added.
 834         (dontCSE):
 835         (assert):
 836         (foo):
 837
 838 2016-04-09  Commit Queue  <commit-queue@webkit.org>
 839
 840         Unreviewed, rolling out r199242.
 841         https://bugs.webkit.org/show_bug.cgi?id=156442
 842
 843         Caused many many leaks (Requested by ap on #webkit).
 844
 845         Reverted changeset:
 846
 847         "Web Inspector: get rid of InspectorBasicValue and
 848         InspectorString subclasses"
 849         https://bugs.webkit.org/show_bug.cgi?id=156407
 850         http://trac.webkit.org/changeset/199242
 851
 852 2016-04-09  Filip Pizlo  <fpizlo@apple.com>
 853
 854         Debug JSC test failure: stress/multi-put-by-offset-reallocation-butterfly-cse.js.ftl-no-cjit-small-pool
 855         https://bugs.webkit.org/show_bug.cgi?id=156406
 856
 857         Reviewed by Saam Barati.
 858
 859         The failure was because the GC ran from within the butterfly allocation call in a put_by_id
 860         transition AccessCase that had to deal with indexing storage. When the GC runs in a call from a stub,
 861         then we need to be extra careful:
 862
 863         1) The GC may reset the IC and delete the stub. So, the stub needs to tell the GC that it might be on
 864            the stack during GC, so that the GC keeps it alive if it's currently running.
 865
 866         2) If the stub uses (dereferences or stores) some object after the call, then we need to ensure that
 867            the stub routine knows about that object independently of the IC.
 868
 869         In the case of put_by_id transitions that use a helper to allocate the butterfly, we have both
 870         issues. A long time ago, we had to deal with (2), and we still had code to handle that case, although
 871         it appears to be dead. This change revives that code and glues it together with PolymorphicAccess.
 872
 873         * bytecode/PolymorphicAccess.cpp:
 874         (JSC::AccessCase::alternateBase):
 875         (JSC::AccessCase::doesCalls):
 876         (JSC::AccessCase::couldStillSucceed):
 877         (JSC::AccessCase::generate):
 878         (JSC::PolymorphicAccess::regenerate):
 879         * bytecode/PolymorphicAccess.h:
 880         (JSC::AccessCase::customSlotBase):
 881         (JSC::AccessCase::isGetter):
 882         (JSC::AccessCase::doesCalls): Deleted.
 883         * jit/GCAwareJITStubRoutine.cpp:
 884         (JSC::GCAwareJITStubRoutine::markRequiredObjectsInternal):
 885         (JSC::MarkingGCAwareJITStubRoutine::MarkingGCAwareJITStubRoutine):
 886         (JSC::MarkingGCAwareJITStubRoutine::~MarkingGCAwareJITStubRoutine):
 887         (JSC::MarkingGCAwareJITStubRoutine::markRequiredObjectsInternal):
 888         (JSC::GCAwareJITStubRoutineWithExceptionHandler::GCAwareJITStubRoutineWithExceptionHandler):
 889         (JSC::createJITStubRoutine):
 890         (JSC::MarkingGCAwareJITStubRoutineWithOneObject::MarkingGCAwareJITStubRoutineWithOneObject): Deleted.
 891         (JSC::MarkingGCAwareJITStubRoutineWithOneObject::~MarkingGCAwareJITStubRoutineWithOneObject): Deleted.
 892         (JSC::MarkingGCAwareJITStubRoutineWithOneObject::markRequiredObjectsInternal): Deleted.
 893         * jit/GCAwareJITStubRoutine.h:
 894         (JSC::createJITStubRoutine):
 895
 896 2016-04-08  Joseph Pecoraro  <pecoraro@apple.com>
 897
 898         Web Inspector: XHRs and Web Worker scripts are not searchable
 899         https://bugs.webkit.org/show_bug.cgi?id=154214
 900         <rdar://problem/24643587>
 901
 902         Reviewed by Timothy Hatcher.
 903
 904         * inspector/protocol/Page.json:
 905         Add optional requestId to search results properties and search
 906         parameters for when the frameId and url are not enough. XHR
 907         resources, and "Other" resources will use this.
 908
 909 2016-04-08  Guillaume Emont  <guijemont@igalia.com>
 910
 911         MIPS: support Signed cond in branchTest32()
 912         https://bugs.webkit.org/show_bug.cgi?id=156260
 913
 914         This is needed since r197688 makes use of it.
 915
 916         Reviewed by Mark Lam.
 917
 918         * assembler/MacroAssemblerMIPS.h:
 919         (JSC::MacroAssemblerMIPS::branchTest32):
 920
 921 2016-04-08  Alex Christensen  <achristensen@webkit.org>
 922
 923         Progress towards running CMake WebKit2 on Mac
 924         https://bugs.webkit.org/show_bug.cgi?id=156426
 925
 926         Reviewed by Tim Horton.
 927
 928         * PlatformMac.cmake:
 929
 930 2016-04-08  Saam barati  <sbarati@apple.com>
 931
 932         Debugger may dereference m_currentCallFrame even after the VM has gone idle
 933         https://bugs.webkit.org/show_bug.cgi?id=156413
 934
 935         Reviewed by Mark Lam.
 936
 937         There is a bug where the debugger may dereference its m_currentCallFrame
 938         pointer after that pointer becomes invalid to read from. This happens like so:
 939
 940         We may step over an instruction which causes the end of execution for the
 941         current program. This causes the VM to exit. Then, we perform a GC which
 942         causes us to collect the global object. The global object being collected
 943         causes us to detach the debugger. In detaching, we think we still have a
 944         valid m_currentCallFrame, we dereference it, and crash. The solution is to
 945         make sure we're paused when dereferencing this pointer inside ::detach().
 946
 947         * debugger/Debugger.cpp:
 948         (JSC::Debugger::detach):
 949
 950 2016-04-08  Brian Burg  <bburg@apple.com>
 951
 952         Web Inspector: get rid of InspectorBasicValue and InspectorString subclasses
 953         https://bugs.webkit.org/show_bug.cgi?id=156407
 954         <rdar://problem/25627659>
 955
 956         Reviewed by Timothy Hatcher.
 957
 958         There's no point having these subclasses as they don't save any space.
 959         Add m_stringValue to the union and merge some implementations of writeJSON.
 960         Move uses of the subclass to InspectorValue and delete redundant methods.
 961         Now, most InspectorValue methods are non-virtual so they can be templated.
 962
 963         * bindings/ScriptValue.cpp:
 964         (Deprecated::jsToInspectorValue):
 965         * inspector/InjectedScriptBase.cpp:
 966         (Inspector::InjectedScriptBase::makeCall):
 967         Don't used deleted subclasses.
 968
 969         * inspector/InspectorValues.cpp:
 970         (Inspector::InspectorValue::null):
 971         (Inspector::InspectorValue::create):
 972         (Inspector::InspectorValue::asValue):
 973         (Inspector::InspectorValue::asBoolean):
 974         (Inspector::InspectorValue::asDouble):
 975         (Inspector::InspectorValue::asInteger):
 976         (Inspector::InspectorValue::asString):
 977         These only need one implementation now.
 978
 979         (Inspector::InspectorValue::writeJSON):
 980         Still a virtual method since Object and Array need their members.
 981
 982         (Inspector::InspectorObjectBase::InspectorObjectBase):
 983         (Inspector::InspectorBasicValue::asBoolean): Deleted.
 984         (Inspector::InspectorBasicValue::asDouble): Deleted.
 985         (Inspector::InspectorBasicValue::asInteger): Deleted.
 986         (Inspector::InspectorBasicValue::writeJSON): Deleted.
 987         (Inspector::InspectorString::asString): Deleted.
 988         (Inspector::InspectorString::writeJSON): Deleted.
 989         (Inspector::InspectorString::create): Deleted.
 990         (Inspector::InspectorBasicValue::create): Deleted.
 991
 992         * inspector/InspectorValues.h:
 993         (Inspector::InspectorObjectBase::setBoolean):
 994         (Inspector::InspectorObjectBase::setInteger):
 995         (Inspector::InspectorObjectBase::setDouble):
 996         (Inspector::InspectorObjectBase::setString):
 997         (Inspector::InspectorArrayBase::pushBoolean):
 998         (Inspector::InspectorArrayBase::pushInteger):
 999         (Inspector::InspectorArrayBase::pushDouble):
1000         (Inspector::InspectorArrayBase::pushString):
1001         Use new factory methods.
1002
1003         * replay/EncodedValue.cpp:
1004         (JSC::ScalarEncodingTraits<bool>::encodeValue):
1005         (JSC::ScalarEncodingTraits<double>::encodeValue):
1006         (JSC::ScalarEncodingTraits<float>::encodeValue):
1007         (JSC::ScalarEncodingTraits<int32_t>::encodeValue):
1008         (JSC::ScalarEncodingTraits<int64_t>::encodeValue):
1009         (JSC::ScalarEncodingTraits<uint32_t>::encodeValue):
1010         (JSC::ScalarEncodingTraits<uint64_t>::encodeValue):
1011         * replay/EncodedValue.h:
1012         Use new factory methods.
1013
1014 2016-04-08  Filip Pizlo  <fpizlo@apple.com>
1015
1016         Add IC support for arguments.length
1017         https://bugs.webkit.org/show_bug.cgi?id=156389
1018
1019         Reviewed by Geoffrey Garen.
1020
1021         This adds support for caching accesses to arguments.length for both DirectArguments and
1022         ScopedArguments. In strict mode, we already cached these accesses since they were just
1023         normal properties.
1024
1025         Amazingly, we also already supported caching of overridden arguments.length in both
1026         DirectArguments and ScopedArguments. This is because when you override, the property gets
1027         materialized as a normal JS property and the structure is changed.
1028
1029         This patch painstakingly preserves our previous caching of overridden length while
1030         introducing caching of non-overridden length (i.e. the common case). In fact, we even cache
1031         the case where it could either be overridden or not, since we just end up with an AccessCase
1032         for each and they cascade to each other.
1033
1034         This is a >3x speed-up on microbenchmarks that do arguments.length in a polymorphic context.
1035         Entirely monomorphic accesses were already handled by the DFG.
1036
1037         * bytecode/PolymorphicAccess.cpp:
1038         (JSC::AccessGenerationState::calculateLiveRegistersForCallAndExceptionHandling):
1039         (JSC::AccessCase::guardedByStructureCheck):
1040         (JSC::AccessCase::generateWithGuard):
1041         (JSC::AccessCase::generate):
1042         (WTF::printInternal):
1043         * bytecode/PolymorphicAccess.h:
1044         * jit/ICStats.h:
1045         * jit/JITOperations.cpp:
1046         * jit/Repatch.cpp:
1047         (JSC::tryCacheGetByID):
1048         (JSC::tryCachePutByID):
1049         (JSC::tryRepatchIn):
1050         * tests/stress/direct-arguments-override-length-then-access-normal-length.js: Added.
1051         (args):
1052         (foo):
1053         (result.foo):
1054
1055 2016-04-08  Benjamin Poulain  <bpoulain@apple.com>
1056
1057         UInt32ToNumber should have an Int52 path
1058         https://bugs.webkit.org/show_bug.cgi?id=125704
1059
1060         Reviewed by Filip Pizlo.
1061
1062         When dealing with big numbers, fall back to Int52 instead
1063         of double when possible.
1064
1065         * dfg/DFGAbstractInterpreterInlines.h:
1066         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1067         * dfg/DFGFixupPhase.cpp:
1068         (JSC::DFG::FixupPhase::fixupNode):
1069         * dfg/DFGPredictionPropagationPhase.cpp:
1070         (JSC::DFG::PredictionPropagationPhase::propagate):
1071         * dfg/DFGSpeculativeJIT.cpp:
1072         (JSC::DFG::SpeculativeJIT::compileUInt32ToNumber):
1073         * ftl/FTLLowerDFGToB3.cpp:
1074         (JSC::FTL::DFG::LowerDFGToB3::compileUInt32ToNumber):
1075
1076 2016-04-08  Brian Burg  <bburg@apple.com>
1077
1078         Web Inspector: protocol generator should emit an error when 'type' is used instead of '$ref'
1079         https://bugs.webkit.org/show_bug.cgi?id=156275
1080         <rdar://problem/25569331>
1081
1082         Reviewed by Darin Adler.
1083
1084         * inspector/protocol/Heap.json: Fix a mistake that's now caught by the protocol generator.
1085
1086         * inspector/scripts/codegen/models.py:
1087         (TypeReference.__init__): Check here if type_kind is on a whitelist of primitive types.
1088         (TypeReference.referenced_name): Update comment.
1089
1090         Add a new test specifically for the case when the type would otherwise be resolved. Rebaseline.
1091
1092         * inspector/scripts/tests/expected/fail-on-type-reference-as-primitive-type.json-error: Added.
1093         * inspector/scripts/tests/expected/fail-on-unknown-type-reference-in-type-declaration.json-error:
1094         * inspector/scripts/tests/fail-on-type-reference-as-primitive-type.json: Added.
1095
1096 2016-04-07  Joseph Pecoraro  <pecoraro@apple.com>
1097
1098         Remove ENABLE(ENABLE_ES6_CLASS_SYNTAX) guards
1099         https://bugs.webkit.org/show_bug.cgi?id=156384
1100
1101         Reviewed by Ryosuke Niwa.
1102
1103         * Configurations/FeatureDefines.xcconfig:
1104         * features.json: Mark as Done.
1105         * parser/Parser.cpp:
1106         (JSC::Parser<LexerType>::parseExportDeclaration):
1107         (JSC::Parser<LexerType>::parseStatementListItem):
1108         (JSC::Parser<LexerType>::parsePrimaryExpression):
1109         (JSC::Parser<LexerType>::parseMemberExpression):
1110
1111 2016-04-07  Filip Pizlo  <fpizlo@apple.com>
1112
1113         Implementing caching transition puts that need to reallocate with indexing storage
1114         https://bugs.webkit.org/show_bug.cgi?id=130914
1115
1116         Reviewed by Saam Barati.
1117
1118         This enables the IC's put_by_id path to handle reallocating the out-of-line storage even if
1119         the butterfly has indexing storage. Like the DFG, we do this by calling operations that
1120         reallocate the butterfly. Those use JSObject API and do all of the nasty work for us, like
1121         triggering a barrier.
1122
1123         This does a bunch of refactoring to how PolymorphicAccess makes calls. It's a lot easier to
1124         do it now because the hard work is hidden under AccessGenerationState methods. This means
1125         that custom accessors now share logic with put_by_id transitions.
1126
1127         * bytecode/PolymorphicAccess.cpp:
1128         (JSC::AccessGenerationState::succeed):
1129         (JSC::AccessGenerationState::calculateLiveRegistersForCallAndExceptionHandling):
1130         (JSC::AccessGenerationState::preserveLiveRegistersToStackForCall):
1131         (JSC::AccessGenerationState::originalCallSiteIndex):
1132         (JSC::AccessGenerationState::emitExplicitExceptionHandler):
1133         (JSC::AccessCase::AccessCase):
1134         (JSC::AccessCase::transition):
1135         (JSC::AccessCase::generate):
1136         (JSC::PolymorphicAccess::regenerate):
1137         * bytecode/PolymorphicAccess.h:
1138         (JSC::AccessGenerationState::needsToRestoreRegistersIfException):
1139         (JSC::AccessGenerationState::liveRegistersToPreserveAtExceptionHandlingCallSite):
1140         * dfg/DFGOperations.cpp:
1141         * dfg/DFGOperations.h:
1142         * jit/JITOperations.cpp:
1143         * jit/JITOperations.h:
1144
1145 2016-04-07  Joseph Pecoraro  <pecoraro@apple.com>
1146
1147         Remote Inspector: When disallowing remote inspection on a debuggable, a listing is still sent to debuggers
1148         https://bugs.webkit.org/show_bug.cgi?id=156380
1149         <rdar://problem/25323727>
1150
1151         Reviewed by Timothy Hatcher.
1152
1153         * inspector/remote/RemoteInspector.mm:
1154         (Inspector::RemoteInspector::updateTarget):
1155         (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
1156         When a target has been updated and it no longer generates a listing,
1157         we should remove the old listing as that is now stale and should
1158         not be sent. Not generating a listing means this target is no
1159         longer allowed to be debugged.
1160
1161 2016-04-07  Joseph Pecoraro  <pecoraro@apple.com>
1162
1163         Web Inspector: Not necessary to validate webinspectord connection on iOS
1164         https://bugs.webkit.org/show_bug.cgi?id=156377
1165         <rdar://problem/25612460>
1166
1167         Reviewed by Simon Fraser.
1168
1169         * inspector/remote/RemoteInspectorXPCConnection.h:
1170         * inspector/remote/RemoteInspectorXPCConnection.mm:
1171         (Inspector::RemoteInspectorXPCConnection::handleEvent):
1172
1173 2016-04-07  Keith Miller  <keith_miller@apple.com>
1174
1175         Rename ArrayMode::supportsLength to supportsSelfLength
1176         https://bugs.webkit.org/show_bug.cgi?id=156374
1177
1178         Reviewed by Filip Pizlo.
1179
1180         The name supportsLength is confusing because TypedArray have a
1181         length function however it is on the prototype and not on the
1182         instance. supportsSelfLength makes more sense since we use the
1183         function during fixup to tell if we can intrinsic the length
1184         property lookup on self accesses.
1185
1186         * dfg/DFGArrayMode.h:
1187         (JSC::DFG::ArrayMode::supportsSelfLength):
1188         (JSC::DFG::ArrayMode::supportsLength): Deleted.
1189         * dfg/DFGFixupPhase.cpp:
1190         (JSC::DFG::FixupPhase::attemptToMakeGetArrayLength):
1191
1192 2016-04-07  Joseph Pecoraro  <pecoraro@apple.com>
1193
1194         Web Inspector: ProfileView source links are off by 1 line, worse in pretty printed code
1195         https://bugs.webkit.org/show_bug.cgi?id=156371
1196
1197         Reviewed by Timothy Hatcher.
1198
1199         * inspector/protocol/ScriptProfiler.json:
1200         Clarify that these locations are 1-based.
1201
1202 2016-04-07  Jon Davis  <jond@apple.com>
1203
1204         Add Web Animations API to Feature Status Page
1205         https://bugs.webkit.org/show_bug.cgi?id=156360
1206
1207         Reviewed by Timothy Hatcher.
1208
1209         * features.json:
1210
1211 2016-04-07  Saam barati  <sbarati@apple.com>
1212
1213         Invalid assertion inside DebuggerScope::getOwnPropertySlot
1214         https://bugs.webkit.org/show_bug.cgi?id=156357
1215
1216         Reviewed by Keith Miller.
1217
1218         The Type Profiler might profile JS code that uses DebuggerScope and accesses properties
1219         on it. Therefore, it may have a DebuggerScope object in its log. Objects in the log
1220         are subject to having their getOwnPropertySlot method called. Therefore, the DebuggerScope
1221         might not always be in a valid state when its getOwnPropertySlot method is called.
1222         Therefore, the assertion invalid.
1223
1224         * debugger/DebuggerScope.cpp:
1225         (JSC::DebuggerScope::getOwnPropertySlot):
1226
1227 2016-04-07  Saam barati  <sbarati@apple.com>
1228
1229         Initial implementation of annex b.3.3 behavior was incorrect
1230         https://bugs.webkit.org/show_bug.cgi?id=156276
1231
1232         Reviewed by Keith Miller.
1233
1234         I almost got annex B.3.3 correct in my first implementation.
1235         There is a subtlety here I got wrong. We always create a local binding for
1236         a function at the very beginning of execution of a block scope. So we
1237         hoist function declarations to their local binding within a given
1238         block scope. When we actually evaluate the function declaration statement
1239         itself, we must lookup the binding in the current scope, and bind the
1240         value to the binding in the "var" scope. We perform the following
1241         abstract operations when executing a function declaration statement.
1242
1243         f = lookupBindingInCurrentScope("func")
1244         store(varScope, "func", f)
1245
1246         I got this wrong by performing the store to the var binding at the beginning
1247         of the block scope instead of when we evaluate the function declaration statement.
1248         This behavior is observable. For example, a program could change the value
1249         of "func" before the actual function declaration statement executes.
1250         Consider the following two functions:
1251         ```
1252         function foo1() {
1253             // func === undefined
1254             {
1255                 // typeof func === "function"
1256                 function func() { } // Executing this statement binds the local "func" binding to the implicit "func" var binding.
1257                 func = 20 // This sets the local "func" binding to 20.
1258             }
1259             // typeof func === "function"
1260         }
1261
1262         function foo2() {
1263             // func === undefined
1264             {
1265                 // typeof func === "function"
1266                 func = 20 // This sets the local "func" binding to 20.
1267                 function func() { } // Executing this statement binds the local "func" binding to the implicit "func" var binding.
1268             }
1269             // func === 20
1270         }
1271         ```
1272
1273         * bytecompiler/BytecodeGenerator.cpp:
1274         (JSC::BytecodeGenerator::initializeBlockScopedFunctions):
1275         (JSC::BytecodeGenerator::hoistSloppyModeFunctionIfNecessary):
1276         * bytecompiler/BytecodeGenerator.h:
1277         (JSC::BytecodeGenerator::emitNodeForLeftHandSide):
1278         * bytecompiler/NodesCodegen.cpp:
1279         (JSC::FuncDeclNode::emitBytecode):
1280         * tests/stress/sloppy-mode-function-hoisting.js:
1281         (test.foo):
1282         (test):
1283         (test.):
1284         (test.bar):
1285         (test.switch.case.0):
1286         (test.capFoo1):
1287         (test.switch.capFoo2):
1288         (test.outer):
1289         (foo):
1290
1291 2016-04-07  Alex Christensen  <achristensen@webkit.org>
1292
1293         Build fix after r199170
1294
1295         * CMakeLists.txt:
1296
1297 2016-04-07  Keith Miller  <keith_miller@apple.com>
1298
1299         We should support the ability to do a non-effectful getById
1300         https://bugs.webkit.org/show_bug.cgi?id=156116
1301
1302         Reviewed by Benjamin Poulain.
1303
1304         Currently, there is no way in JS to do a non-effectful getById. A non-effectful getById is
1305         useful because it enables us to take different code paths based on values that we would
1306         otherwise not be able to have knowledge of. This patch adds this new feature called
1307         try_get_by_id that will attempt to do as much of a get_by_id as possible without performing
1308         an effectful behavior. Thus, try_get_by_id will return the value if the slot is a value, the
1309         GetterSetter object if the slot is a normal accessor (not a CustomGetterSetter) and
1310         undefined if the slot is unset.  If the slot is proxied or any other cases then the result
1311         is null. In theory, if we ever wanted to check for null we could add a sentinal object to
1312         the global object that indicates we could not get the result.
1313
1314         In order to implement this feature we add a new enum GetByIdKind that indicates what to do
1315         for accessor properties in PolymorphicAccess. If the GetByIdKind is pure then we treat the
1316         get_by_id the same way we would for load and return the value at the appropriate offset.
1317         Additionally, in order to make sure the we can properly compare the GetterSetter object
1318         with === GetterSetters are now JSObjects. This comes at the cost of eight extra bytes on the
1319         GetterSetter object but it vastly simplifies the patch. Additionally, the extra bytes are
1320         likely to have little to no impact on memory usage as normal accessors are generally rare.
1321
1322         * JavaScriptCore.xcodeproj/project.pbxproj:
1323         * builtins/BuiltinExecutableCreator.cpp: Added.
1324         (JSC::createBuiltinExecutable):
1325         * builtins/BuiltinExecutableCreator.h: Copied from Source/JavaScriptCore/builtins/BuiltinExecutables.h.
1326         * builtins/BuiltinExecutables.cpp:
1327         (JSC::BuiltinExecutables::createDefaultConstructor):
1328         (JSC::BuiltinExecutables::createBuiltinExecutable):
1329         (JSC::createBuiltinExecutable):
1330         (JSC::BuiltinExecutables::createExecutable):
1331         (JSC::createExecutableInternal): Deleted.
1332         * builtins/BuiltinExecutables.h:
1333         * bytecode/BytecodeIntrinsicRegistry.h:
1334         * bytecode/BytecodeList.json:
1335         * bytecode/BytecodeUseDef.h:
1336         (JSC::computeUsesForBytecodeOffset):
1337         (JSC::computeDefsForBytecodeOffset):
1338         * bytecode/CodeBlock.cpp:
1339         (JSC::CodeBlock::dumpBytecode):
1340         * bytecode/PolymorphicAccess.cpp:
1341         (JSC::AccessCase::tryGet):
1342         (JSC::AccessCase::generate):
1343         (WTF::printInternal):
1344         * bytecode/PolymorphicAccess.h:
1345         (JSC::AccessCase::isGet): Deleted.
1346         (JSC::AccessCase::isPut): Deleted.
1347         (JSC::AccessCase::isIn): Deleted.
1348         * bytecode/StructureStubInfo.cpp:
1349         (JSC::StructureStubInfo::reset):
1350         * bytecode/StructureStubInfo.h:
1351         * bytecompiler/BytecodeGenerator.cpp:
1352         (JSC::BytecodeGenerator::emitTryGetById):
1353         * bytecompiler/BytecodeGenerator.h:
1354         * bytecompiler/NodesCodegen.cpp:
1355         (JSC::BytecodeIntrinsicNode::emit_intrinsic_tryGetById):
1356         * dfg/DFGSpeculativeJIT32_64.cpp:
1357         (JSC::DFG::SpeculativeJIT::cachedGetById):
1358         * dfg/DFGSpeculativeJIT64.cpp:
1359         (JSC::DFG::SpeculativeJIT::cachedGetById):
1360         * ftl/FTLLowerDFGToB3.cpp:
1361         (JSC::FTL::DFG::LowerDFGToB3::getById):
1362         * jit/JIT.cpp:
1363         (JSC::JIT::privateCompileMainPass):
1364         (JSC::JIT::privateCompileSlowCases):
1365         * jit/JIT.h:
1366         * jit/JITInlineCacheGenerator.cpp:
1367         (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
1368         * jit/JITInlineCacheGenerator.h:
1369         * jit/JITInlines.h:
1370         (JSC::JIT::callOperation):
1371         * jit/JITOperations.cpp:
1372         * jit/JITOperations.h:
1373         * jit/JITPropertyAccess.cpp:
1374         (JSC::JIT::emitGetByValWithCachedId):
1375         (JSC::JIT::emit_op_try_get_by_id):
1376         (JSC::JIT::emitSlow_op_try_get_by_id):
1377         (JSC::JIT::emit_op_get_by_id):
1378         * jit/JITPropertyAccess32_64.cpp:
1379         (JSC::JIT::emitGetByValWithCachedId):
1380         (JSC::JIT::emit_op_try_get_by_id):
1381         (JSC::JIT::emitSlow_op_try_get_by_id):
1382         (JSC::JIT::emit_op_get_by_id):
1383         * jit/Repatch.cpp:
1384         (JSC::repatchByIdSelfAccess):
1385         (JSC::appropriateOptimizingGetByIdFunction):
1386         (JSC::appropriateGenericGetByIdFunction):
1387         (JSC::tryCacheGetByID):
1388         (JSC::repatchGetByID):
1389         (JSC::resetGetByID):
1390         * jit/Repatch.h:
1391         * jsc.cpp:
1392         (GlobalObject::finishCreation):
1393         (functionGetGetterSetter):
1394         (functionCreateBuiltin):
1395         * llint/LLIntData.cpp:
1396         (JSC::LLInt::Data::performAssertions):
1397         * llint/LLIntSlowPaths.cpp:
1398         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1399         * llint/LLIntSlowPaths.h:
1400         * llint/LowLevelInterpreter.asm:
1401         * runtime/GetterSetter.cpp:
1402         * runtime/GetterSetter.h:
1403         * runtime/JSType.h:
1404         * runtime/PropertySlot.cpp:
1405         (JSC::PropertySlot::getPureResult):
1406         * runtime/PropertySlot.h:
1407         * runtime/ProxyObject.cpp:
1408         (JSC::ProxyObject::getOwnPropertySlotCommon):
1409         * tests/stress/try-get-by-id.js: Added.
1410         (tryGetByIdText):
1411         (getCaller.obj.1.throw.new.Error.let.func):
1412         (getCaller.obj.1.throw.new.Error):
1413         (throw.new.Error.get let):
1414         (throw.new.Error.):
1415         (throw.new.Error.let.get createBuiltin):
1416         (get let):
1417         (let.get createBuiltin):
1418         (let.func):
1419         (get let.func):
1420         (get throw):
1421
1422 2016-04-07  Filip Pizlo  <fpizlo@apple.com>
1423
1424         Rationalize the makeSpaceForCCall stuff
1425         https://bugs.webkit.org/show_bug.cgi?id=156352
1426
1427         Reviewed by Mark Lam.
1428
1429         I want to add more code to PolymorphicAccess that makes C calls, so that I can finally fix
1430         https://bugs.webkit.org/show_bug.cgi?id=130914 (allow transition caches to handle indexing
1431         headers).
1432
1433         When trying to understand what it takes to make a C call, I came across code that was making
1434         room on the stack for spilled arguments. This logic was guarded with some complicated
1435         condition. At first, I tried to just refactor the code so that the same ugly condition
1436         wouldn't have to be copy-pasted everywhere that we made C calls. But then I started thinking
1437         about the condition, and realized that it was probably wrong: if the outer PolymorphicAccess
1438         harness decides to reuse a register for the scratchGPR then the top of the stack will store
1439         the old value of scratchGPR, but the condition wouldn't necessarily trigger. So if the call
1440         then overwrote something on the stack, we'd have a bad time.
1441
1442         Making room on the stack for a call is a cheap operation. It's orders of magnitude cheaper
1443         than the rest of the call. Therefore, I think that it's best to just unconditionally make
1444         room on the stack.
1445
1446         This patch makes us do just that. I also made the relevant helpers not inline, because I
1447         think that we have too many inline methods in our assemblers. Now it's much easier to make
1448         C calls from PolymorphicAccess because you just call the AssemblyHelper methods for making
1449         space. There are no special conditions or anything like that.
1450
1451         * bytecode/PolymorphicAccess.cpp:
1452         (JSC::AccessCase::generate):
1453         * jit/AssemblyHelpers.cpp:
1454         (JSC::AssemblyHelpers::emitLoadStructure):
1455         (JSC::AssemblyHelpers::makeSpaceOnStackForCCall):
1456         (JSC::AssemblyHelpers::reclaimSpaceOnStackForCCall):
1457         (JSC::emitRandomThunkImpl):
1458         * jit/AssemblyHelpers.h:
1459         (JSC::AssemblyHelpers::makeSpaceOnStackForCCall): Deleted.
1460         (JSC::AssemblyHelpers::reclaimSpaceOnStackForCCall): Deleted.
1461
1462 2016-04-07  Commit Queue  <commit-queue@webkit.org>
1463
1464         Unreviewed, rolling out r199128 and r199141.
1465         https://bugs.webkit.org/show_bug.cgi?id=156348
1466
1467         Causes crashes on multiple webpages (Requested by keith_mi_ on
1468         #webkit).
1469
1470         Reverted changesets:
1471
1472         "[ES6] Add support for Symbol.isConcatSpreadable."
1473         https://bugs.webkit.org/show_bug.cgi?id=155351
1474         http://trac.webkit.org/changeset/199128
1475
1476         "Unreviewed, uncomment accidentally commented line in test."
1477         http://trac.webkit.org/changeset/199141
1478
1479 2016-04-07  Filip Pizlo  <fpizlo@apple.com>
1480
1481         Rationalize the handling of PutById transitions a bit
1482         https://bugs.webkit.org/show_bug.cgi?id=156330
1483
1484         Reviewed by Mark Lam.
1485
1486         * bytecode/PolymorphicAccess.cpp:
1487         (JSC::AccessCase::generate): Get rid of the specialized slow calls. We can just use the failAndIgnore jump target. We just need to make sure that we don't make observable effects until we're done with all of the fast path checks.
1488         * bytecode/StructureStubInfo.cpp:
1489         (JSC::StructureStubInfo::addAccessCase): MadeNoChanges indicates that we should keep trying to repatch. Currently PutById transitions might trigger the case that addAccessCase() sees null, if the transition involves an indexing header. Doing repatching in that case is probably not good. But, we should just fix this the right way eventually.
1490
1491 2016-04-07  Per Arne Vollan  <peavo@outlook.com>
1492
1493         [Win] Fix for JSC stress test failures.
1494         https://bugs.webkit.org/show_bug.cgi?id=156343
1495
1496         Reviewed by Filip Pizlo.
1497
1498         We need to make it clear to MSVC that the method loadPtr(ImplicitAddress address, RegisterID dest)
1499         should be used, and not loadPtr(const void* address, RegisterID dest).
1500
1501         * jit/CCallHelpers.cpp:
1502         (JSC::CCallHelpers::setupShadowChickenPacket):
1503
1504 2016-04-06  Benjamin Poulain  <bpoulain@apple.com>
1505
1506         [JSC] UInt32ToNumber should be NodeMustGenerate
1507         https://bugs.webkit.org/show_bug.cgi?id=156329
1508
1509         Reviewed by Filip Pizlo.
1510
1511         It exits on negative numbers on the integer path.
1512
1513         * dfg/DFGFixupPhase.cpp:
1514         (JSC::DFG::FixupPhase::fixupNode):
1515         * dfg/DFGNodeType.h:
1516
1517 2016-04-04  Geoffrey Garen  <ggaren@apple.com>
1518
1519         Unreviewed, rolling out r199016.
1520         https://bugs.webkit.org/show_bug.cgi?id=156140
1521
1522         "Perf bots are down, so I can't re-land this right now."
1523
1524         Reverted changeset:
1525
1526         CopiedBlock should be 16kB
1527         https://bugs.webkit.org/show_bug.cgi?id=156168
1528         http://trac.webkit.org/changeset/199016
1529
1530 2016-04-06  Mark Lam  <mark.lam@apple.com>
1531
1532         String.prototype.match() should be calling internal function RegExpCreate.
1533         https://bugs.webkit.org/show_bug.cgi?id=156318
1534
1535         Reviewed by Filip Pizlo.
1536
1537         RegExpCreate is not the same as the RegExp constructor.  The current implementation
1538         invokes new @RegExp which calls the constructor.  This results in failures in
1539         es6/Proxy_internal_get_calls_String.prototype.match.js, and
1540         es6/Proxy_internal_get_calls_String.prototype.search.js due to observable side
1541         effects.
1542
1543         This patch fixes this by factoring out the part of the RegExp constructor that
1544         makes the RegExpCreate function, and changing String's match and search to call
1545         RegExpCreate instead in accordance with the ES6 spec.
1546
1547         * builtins/StringPrototype.js:
1548         (match):
1549         (search):
1550         * runtime/CommonIdentifiers.h:
1551         * runtime/JSGlobalObject.cpp:
1552         (JSC::JSGlobalObject::init):
1553         * runtime/RegExpConstructor.cpp:
1554         (JSC::toFlags):
1555         (JSC::regExpCreate):
1556         (JSC::constructRegExp):
1557         (JSC::esSpecRegExpCreate):
1558         (JSC::constructWithRegExpConstructor):
1559         * runtime/RegExpConstructor.h:
1560         (JSC::isRegExp):
1561
1562 2016-04-06  Keith Miller  <keith_miller@apple.com>
1563
1564         Unreviewed, uncomment accidentally commented line in test.
1565
1566         * tests/stress/array-concat-spread-object.js:
1567
1568 2016-04-06  Filip Pizlo  <fpizlo@apple.com>
1569
1570         JSC should have a simple way of gathering IC statistics
1571         https://bugs.webkit.org/show_bug.cgi?id=156317
1572
1573         Reviewed by Benjamin Poulain.
1574
1575         This adds a cheap, runtime-enabled way of gathering statistics about why we take the slow
1576         paths for inline caches. This is complementary to our existing bytecode profiler. Eventually
1577         we may want to combine the two things.
1578
1579         This is not a slow-down on anything because we only do extra work on IC slow paths and if
1580         it's disabled it's just a load-and-branch to skip the stats gathering code.
1581
1582         * CMakeLists.txt:
1583         * JavaScriptCore.xcodeproj/project.pbxproj:
1584         * jit/ICStats.cpp: Added.
1585         * jit/ICStats.h: Added.
1586         * jit/JITOperations.cpp:
1587         * runtime/JSCJSValue.h:
1588         * runtime/JSCJSValueInlines.h:
1589         (JSC::JSValue::inherits):
1590         (JSC::JSValue::classInfoOrNull):
1591         (JSC::JSValue::toThis):
1592         * runtime/Options.h:
1593
1594 2016-04-06  Filip Pizlo  <fpizlo@apple.com>
1595
1596         32-bit JSC stress/multi-put-by-offset-multiple-transitions.js failing
1597         https://bugs.webkit.org/show_bug.cgi?id=156292
1598
1599         Reviewed by Benjamin Poulain.
1600
1601         Make sure that we stash the callsite index before calling operationReallocateStorageAndFinishPut.
1602
1603         * bytecode/PolymorphicAccess.cpp:
1604         (JSC::AccessCase::generate):
1605
1606 2016-04-06  Filip Pizlo  <fpizlo@apple.com>
1607
1608         JSC test stress/arrowfunction-lexical-bind-superproperty.js failing
1609         https://bugs.webkit.org/show_bug.cgi?id=156309
1610
1611         Reviewed by Saam Barati.
1612
1613         Just be honest about the fact that the ArgumentCount and Callee parts of inline callframe runtime
1614         meta-data can be read at any time.
1615
1616         We only have to say this for the inline callframe forms of ArgumentCount and Callee because we don't
1617         sink any part of the machine prologue. This change just prevents us from sinking the pseudoprologue
1618         of inlined varargs or closure calls.
1619
1620         Shockingly, this is not a regression on anything.
1621
1622         * dfg/DFGClobberize.h:
1623         (JSC::DFG::clobberize):
1624
1625 2016-03-29  Keith Miller  <keith_miller@apple.com>
1626
1627         [ES6] Add support for Symbol.isConcatSpreadable.
1628         https://bugs.webkit.org/show_bug.cgi?id=155351
1629
1630         Reviewed by Saam Barati.
1631
1632         This patch adds support for Symbol.isConcatSpreadable. In order to do so it was necessary to move the
1633         Array.prototype.concat function to JS. A number of different optimizations were needed to make such the move to
1634         a builtin performant. First, four new DFG intrinsics were added.
1635
1636         1) IsArrayObject (I would have called it IsArray but we use the same name for an IndexingType): an intrinsic of
1637            the Array.isArray function.
1638         2) IsJSArray: checks the first child is a JSArray object.
1639         3) IsArrayConstructor: checks the first child is an instance of ArrayConstructor.
1640         4) CallObjectConstructor: an intrinsic of the Object constructor.
1641
1642         IsActualObject, IsJSArray, and CallObjectConstructor can all be converted into constants in the abstract interpreter if
1643         we are able to prove that the first child is an Array or for ToObject an Object.
1644
1645         In order to further improve the perfomance we also now cover more indexing types in our fast path memcpy
1646         code. Before we would only memcpy Arrays if they had the same indexing type and did not have Array storage and
1647         were not undecided. Now the memcpy code covers the following additional two cases: One array is undecided and
1648         the other is a non-array storage and the case where one array is Int32 and the other is contiguous (we map this
1649         into a contiguous array).
1650
1651         This patch also adds a new fast path for concat with more than one array argument by using memcpy to append
1652         values onto the result array. This works roughly the same as the two array fast path using the same methodology
1653         to decide if we can memcpy the other butterfly into the result butterfly.
1654
1655         Two new debugging tools are also added to the jsc cli. One is a version of the print function with a private
1656         name so it can be used for debugging builtins. The other is dumpDataLog, which takes a JSValue and runs our
1657         dataLog function on it.
1658
1659         Finally, this patch add a new constructor to JSValueRegsTemporary that allows it to reuse the the registers of a
1660         JSValueOperand if the operand's use count is one.
1661
1662         * JavaScriptCore.xcodeproj/project.pbxproj:
1663         * builtins/ArrayPrototype.js:
1664         (concatSlowPath):
1665         (concat):
1666         * bytecode/BytecodeIntrinsicRegistry.cpp:
1667         (JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
1668         * bytecode/BytecodeIntrinsicRegistry.h:
1669         * dfg/DFGAbstractInterpreterInlines.h:
1670         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1671         * dfg/DFGByteCodeParser.cpp:
1672         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
1673         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
1674         * dfg/DFGClobberize.h:
1675         (JSC::DFG::clobberize):
1676         * dfg/DFGDoesGC.cpp:
1677         (JSC::DFG::doesGC):
1678         * dfg/DFGFixupPhase.cpp:
1679         (JSC::DFG::FixupPhase::fixupNode):
1680         * dfg/DFGNodeType.h:
1681         * dfg/DFGOperations.cpp:
1682         * dfg/DFGOperations.h:
1683         * dfg/DFGPredictionPropagationPhase.cpp:
1684         (JSC::DFG::PredictionPropagationPhase::propagate):
1685         * dfg/DFGSafeToExecute.h:
1686         (JSC::DFG::safeToExecute):
1687         * dfg/DFGSpeculativeJIT.cpp:
1688         (JSC::DFG::SpeculativeJIT::compileCurrentBlock):
1689         (JSC::DFG::SpeculativeJIT::compileIsJSArray):
1690         (JSC::DFG::SpeculativeJIT::compileIsArrayObject):
1691         (JSC::DFG::SpeculativeJIT::compileIsArrayConstructor):
1692         (JSC::DFG::SpeculativeJIT::compileCallObjectConstructor):
1693         * dfg/DFGSpeculativeJIT.h:
1694         (JSC::DFG::SpeculativeJIT::callOperation):
1695         * dfg/DFGSpeculativeJIT32_64.cpp:
1696         (JSC::DFG::SpeculativeJIT::compile):
1697         * dfg/DFGSpeculativeJIT64.cpp:
1698         (JSC::DFG::SpeculativeJIT::compile):
1699         * ftl/FTLCapabilities.cpp:
1700         (JSC::FTL::canCompile):
1701         * ftl/FTLLowerDFGToB3.cpp:
1702         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1703         (JSC::FTL::DFG::LowerDFGToB3::compileCallObjectConstructor):
1704         (JSC::FTL::DFG::LowerDFGToB3::compileIsArrayObject):
1705         (JSC::FTL::DFG::LowerDFGToB3::compileIsJSArray):
1706         (JSC::FTL::DFG::LowerDFGToB3::compileIsArrayConstructor):
1707         (JSC::FTL::DFG::LowerDFGToB3::isArray):
1708         * jit/JITOperations.h:
1709         * jsc.cpp:
1710         (WTF::RuntimeArray::createStructure):
1711         (GlobalObject::finishCreation):
1712         (functionDebug):
1713         (functionDataLogValue):
1714         * runtime/ArrayConstructor.cpp:
1715         (JSC::ArrayConstructor::finishCreation):
1716         (JSC::arrayConstructorPrivateFuncIsArrayConstructor):
1717         * runtime/ArrayConstructor.h:
1718         (JSC::isArrayConstructor):
1719         * runtime/ArrayPrototype.cpp:
1720         (JSC::ArrayPrototype::finishCreation):
1721         (JSC::arrayProtoPrivateFuncIsJSArray):
1722         (JSC::moveElements):
1723         (JSC::arrayProtoPrivateFuncConcatMemcpy):
1724         (JSC::arrayProtoPrivateFuncAppendMemcpy):
1725         (JSC::arrayProtoFuncConcat): Deleted.
1726         * runtime/ArrayPrototype.h:
1727         (JSC::ArrayPrototype::createStructure):
1728         * runtime/CommonIdentifiers.h:
1729         * runtime/Intrinsic.h:
1730         * runtime/JSArray.cpp:
1731         (JSC::JSArray::appendMemcpy):
1732         (JSC::JSArray::fastConcatWith): Deleted.
1733         * runtime/JSArray.h:
1734         (JSC::JSArray::createStructure):
1735         (JSC::JSArray::fastConcatType): Deleted.
1736         * runtime/JSArrayInlines.h: Added.
1737         (JSC::JSArray::memCopyWithIndexingType):
1738         (JSC::JSArray::canFastCopy):
1739         * runtime/JSGlobalObject.cpp:
1740         (JSC::JSGlobalObject::init):
1741         * runtime/JSType.h:
1742         * runtime/ObjectConstructor.h:
1743         (JSC::constructObject):
1744         * tests/es6.yaml:
1745         * tests/stress/array-concat-spread-object.js: Added.
1746         (arrayEq):
1747         * tests/stress/array-concat-spread-proxy-exception-check.js: Added.
1748         (arrayEq):
1749         * tests/stress/array-concat-spread-proxy.js: Added.
1750         (arrayEq):
1751         * tests/stress/array-concat-with-slow-indexingtypes.js: Added.
1752         (arrayEq):
1753         * tests/stress/array-species-config-array-constructor.js:
1754
1755 2016-04-06  Commit Queue  <commit-queue@webkit.org>
1756
1757         Unreviewed, rolling out r199070.
1758         https://bugs.webkit.org/show_bug.cgi?id=156324
1759
1760         "It didn't fix the timeout" (Requested by saamyjoon on
1761         #webkit).
1762
1763         Reverted changeset:
1764
1765         "jsc-layout-tests.yaml/js/script-tests/regress-141098.js
1766         failing on Yosemite Debug after r198989"
1767         https://bugs.webkit.org/show_bug.cgi?id=156187
1768         http://trac.webkit.org/changeset/199070
1769
1770 2016-04-06  Geoffrey Garen  <ggaren@apple.com>
1771
1772         Unreviewed, rolling in r199016.
1773         https://bugs.webkit.org/show_bug.cgi?id=156140
1774
1775         It might work this time without regression because 16kB aligned requests
1776         now take the allocation fast path.
1777
1778         Restored changeset:
1779
1780         CopiedBlock should be 16kB
1781         https://bugs.webkit.org/show_bug.cgi?id=156168
1782         http://trac.webkit.org/changeset/199016
1783
1784 2016-04-06  Mark Lam  <mark.lam@apple.com>
1785
1786         Update es6.yaml to expect es6/Proxy_internal_get_calls_RegExp_constructor.js to pass.
1787         https://bugs.webkit.org/show_bug.cgi?id=156314
1788
1789         Reviewed by Saam Barati.
1790
1791         * tests/es6.yaml:
1792
1793 2016-04-06  Commit Queue  <commit-queue@webkit.org>
1794
1795         Unreviewed, rolling out r199104.
1796         https://bugs.webkit.org/show_bug.cgi?id=156301
1797
1798         Still breaks internal builds (Requested by keith_miller on
1799         #webkit).
1800
1801         Reverted changeset:
1802
1803         "We should support the ability to do a non-effectful getById"
1804         https://bugs.webkit.org/show_bug.cgi?id=156116
1805         http://trac.webkit.org/changeset/199104
1806
1807 2016-04-06  Keith Miller  <keith_miller@apple.com>
1808
1809         RegExp constructor should use Symbol.match and other properties
1810         https://bugs.webkit.org/show_bug.cgi?id=155873
1811
1812         Reviewed by Michael Saboff.
1813
1814         This patch updates the behavior of the RegExp constructor. Now the constructor
1815         should get the Symbol.match property and check if it exists to decide if something
1816         should be constructed like a regexp object.
1817
1818         * runtime/RegExpConstructor.cpp:
1819         (JSC::toFlags):
1820         (JSC::constructRegExp):
1821         (JSC::constructWithRegExpConstructor):
1822         (JSC::callRegExpConstructor):
1823         * runtime/RegExpConstructor.h:
1824         * tests/stress/regexp-constructor.js: Added.
1825         (assert):
1826         (throw.new.Error.get let):
1827         (throw.new.Error.):
1828         (throw.new.Error.get re):
1829
1830 2016-04-06  Keith Miller  <keith_miller@apple.com>
1831
1832         We should support the ability to do a non-effectful getById
1833         https://bugs.webkit.org/show_bug.cgi?id=156116
1834
1835         Reviewed by Benjamin Poulain.
1836
1837         Currently, there is no way in JS to do a non-effectful getById. A non-effectful getById is
1838         useful because it enables us to take different code paths based on values that we would
1839         otherwise not be able to have knowledge of. This patch adds this new feature called
1840         try_get_by_id that will attempt to do as much of a get_by_id as possible without performing
1841         an effectful behavior. Thus, try_get_by_id will return the value if the slot is a value, the
1842         GetterSetter object if the slot is a normal accessor (not a CustomGetterSetter) and
1843         undefined if the slot is unset.  If the slot is proxied or any other cases then the result
1844         is null. In theory, if we ever wanted to check for null we could add a sentinal object to
1845         the global object that indicates we could not get the result.
1846
1847         In order to implement this feature we add a new enum GetByIdKind that indicates what to do
1848         for accessor properties in PolymorphicAccess. If the GetByIdKind is pure then we treat the
1849         get_by_id the same way we would for load and return the value at the appropriate offset.
1850         Additionally, in order to make sure the we can properly compare the GetterSetter object
1851         with === GetterSetters are now JSObjects. This comes at the cost of eight extra bytes on the
1852         GetterSetter object but it vastly simplifies the patch. Additionally, the extra bytes are
1853         likely to have little to no impact on memory usage as normal accessors are generally rare.
1854
1855         * builtins/BuiltinExecutables.cpp:
1856         (JSC::BuiltinExecutables::createDefaultConstructor):
1857         (JSC::BuiltinExecutables::createBuiltinExecutable):
1858         (JSC::createBuiltinExecutable):
1859         (JSC::BuiltinExecutables::createExecutable):
1860         (JSC::createExecutableInternal): Deleted.
1861         * builtins/BuiltinExecutables.h:
1862         * bytecode/BytecodeIntrinsicRegistry.h:
1863         * bytecode/BytecodeList.json:
1864         * bytecode/BytecodeUseDef.h:
1865         (JSC::computeUsesForBytecodeOffset):
1866         (JSC::computeDefsForBytecodeOffset):
1867         * bytecode/CodeBlock.cpp:
1868         (JSC::CodeBlock::dumpBytecode):
1869         * bytecode/PolymorphicAccess.cpp:
1870         (JSC::AccessCase::tryGet):
1871         (JSC::AccessCase::generate):
1872         (WTF::printInternal):
1873         * bytecode/PolymorphicAccess.h:
1874         (JSC::AccessCase::isGet): Deleted.
1875         (JSC::AccessCase::isPut): Deleted.
1876         (JSC::AccessCase::isIn): Deleted.
1877         * bytecode/StructureStubInfo.cpp:
1878         (JSC::StructureStubInfo::reset):
1879         * bytecode/StructureStubInfo.h:
1880         * bytecompiler/BytecodeGenerator.cpp:
1881         (JSC::BytecodeGenerator::emitTryGetById):
1882         * bytecompiler/BytecodeGenerator.h:
1883         * bytecompiler/NodesCodegen.cpp:
1884         (JSC::BytecodeIntrinsicNode::emit_intrinsic_tryGetById):
1885         * dfg/DFGSpeculativeJIT32_64.cpp:
1886         (JSC::DFG::SpeculativeJIT::cachedGetById):
1887         * dfg/DFGSpeculativeJIT64.cpp:
1888         (JSC::DFG::SpeculativeJIT::cachedGetById):
1889         * ftl/FTLLowerDFGToB3.cpp:
1890         (JSC::FTL::DFG::LowerDFGToB3::getById):
1891         * jit/JIT.cpp:
1892         (JSC::JIT::privateCompileMainPass):
1893         (JSC::JIT::privateCompileSlowCases):
1894         * jit/JIT.h:
1895         * jit/JITInlineCacheGenerator.cpp:
1896         (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
1897         * jit/JITInlineCacheGenerator.h:
1898         * jit/JITInlines.h:
1899         (JSC::JIT::callOperation):
1900         * jit/JITOperations.cpp:
1901         * jit/JITOperations.h:
1902         * jit/JITPropertyAccess.cpp:
1903         (JSC::JIT::emitGetByValWithCachedId):
1904         (JSC::JIT::emit_op_try_get_by_id):
1905         (JSC::JIT::emitSlow_op_try_get_by_id):
1906         (JSC::JIT::emit_op_get_by_id):
1907         * jit/JITPropertyAccess32_64.cpp:
1908         (JSC::JIT::emitGetByValWithCachedId):
1909         (JSC::JIT::emit_op_try_get_by_id):
1910         (JSC::JIT::emitSlow_op_try_get_by_id):
1911         (JSC::JIT::emit_op_get_by_id):
1912         * jit/Repatch.cpp:
1913         (JSC::repatchByIdSelfAccess):
1914         (JSC::appropriateOptimizingGetByIdFunction):
1915         (JSC::appropriateGenericGetByIdFunction):
1916         (JSC::tryCacheGetByID):
1917         (JSC::repatchGetByID):
1918         (JSC::resetGetByID):
1919         * jit/Repatch.h:
1920         * jsc.cpp:
1921         (GlobalObject::finishCreation):
1922         (functionGetGetterSetter):
1923         (functionCreateBuiltin):
1924         * llint/LLIntData.cpp:
1925         (JSC::LLInt::Data::performAssertions):
1926         * llint/LLIntSlowPaths.cpp:
1927         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1928         * llint/LLIntSlowPaths.h:
1929         * llint/LowLevelInterpreter.asm:
1930         * runtime/GetterSetter.cpp:
1931         * runtime/GetterSetter.h:
1932         * runtime/JSType.h:
1933         * runtime/PropertySlot.cpp:
1934         (JSC::PropertySlot::getPureResult):
1935         * runtime/PropertySlot.h:
1936         * runtime/ProxyObject.cpp:
1937         (JSC::ProxyObject::getOwnPropertySlotCommon):
1938         * tests/stress/try-get-by-id.js: Added.
1939         (tryGetByIdText):
1940         (getCaller.obj.1.throw.new.Error.let.func):
1941         (getCaller.obj.1.throw.new.Error):
1942         (throw.new.Error.get let):
1943         (throw.new.Error.):
1944         (throw.new.Error.let.get createBuiltin):
1945         (get let):
1946         (let.get createBuiltin):
1947         (let.func):
1948         (get let.func):
1949         (get throw):
1950
1951 2016-04-05  Chris Dumez  <cdumez@apple.com>
1952
1953         Add support for [EnabledAtRuntime] operations on DOMWindow
1954         https://bugs.webkit.org/show_bug.cgi?id=156272
1955
1956         Reviewed by Alex Christensen.
1957
1958         Add identifier for 'fetch' so it can be used from the generated
1959         bindings.
1960
1961         * runtime/CommonIdentifiers.h:
1962
1963 2016-04-05  Alex Christensen  <achristensen@webkit.org>
1964
1965         Make CMake-generated binaries on Mac able to run
1966         https://bugs.webkit.org/show_bug.cgi?id=156268
1967
1968         Reviewed by Daniel Bates.
1969
1970         * CMakeLists.txt:
1971
1972 2016-04-05  Filip Pizlo  <fpizlo@apple.com>
1973
1974         Improve some other cases of context-sensitive inlining
1975         https://bugs.webkit.org/show_bug.cgi?id=156277
1976
1977         Reviewed by Benjamin Poulain.
1978
1979         This implements some improvements for inlining:
1980
1981         - We no longer do guarded inlining when the profiling doesn't come from a stub. Doing so would have
1982           been risky, and according to benchmarks, it wasn't common enough to matter. I think it's better to
1983           err on the side of not inlining.
1984
1985         - The jneq_ptr pattern for variadic calls no longer breaks the basic block. Not breaking the block
1986           increases the chances of the parser seeing the callee constant. While inlining doesn't require a
1987           callee constant, sometimes it makes a difference. Note that we were previously breaking the block
1988           for no reason at all: if the boundary after jneq_ptr is a jump target from some other jump, then
1989           the parser will automatically break the block for us. There is no reason to add any block breaking
1990           ourselves since we implement jneq_ptr by ignoring the affirmative jump destination and inserting a
1991           check and falling through.
1992
1993         - get_by_id handling now tries to apply some common sense to its status object. In particular, if
1994           the source is a NewObject and there was no interfering operation that could clobber the structure,
1995           then we know which case of a polymorphic GetByIdStatus we would take. This arises in some
1996           constructor patterns.
1997
1998         Long term, we should address all of these cases comprehensively by having a late inliner. The inliner
1999         being part of the bytecode parser means that there is a lot of complexity in the parser and it
2000         prevents us from inlining upon learning new information from static analysis. But for now, I think
2001         it's fine to experiment with one-off hacks, if only to learn what the possibilities are.
2002
2003         This is a 14% speed-up on Octane/raytrace.
2004
2005         * bytecode/CallLinkStatus.cpp:
2006         (JSC::CallLinkStatus::dump):
2007         * bytecode/CallLinkStatus.h:
2008         (JSC::CallLinkStatus::couldTakeSlowPath):
2009         (JSC::CallLinkStatus::setCouldTakeSlowPath):
2010         (JSC::CallLinkStatus::variants):
2011         (JSC::CallLinkStatus::size):
2012         (JSC::CallLinkStatus::at):
2013         * bytecode/GetByIdStatus.cpp:
2014         (JSC::GetByIdStatus::makesCalls):
2015         (JSC::GetByIdStatus::filter):
2016         (JSC::GetByIdStatus::dump):
2017         * bytecode/GetByIdStatus.h:
2018         (JSC::GetByIdStatus::wasSeenInJIT):
2019         * dfg/DFGByteCodeParser.cpp:
2020         (JSC::DFG::ByteCodeParser::handleCall):
2021         (JSC::DFG::ByteCodeParser::refineStatically):
2022         (JSC::DFG::ByteCodeParser::handleVarargsCall):
2023         (JSC::DFG::ByteCodeParser::handleInlining):
2024         (JSC::DFG::ByteCodeParser::handleGetById):
2025         (JSC::DFG::ByteCodeParser::parseBlock):
2026         * runtime/Options.h:
2027
2028 2016-04-05  Saam barati  <sbarati@apple.com>
2029
2030         JSC SamplingProfiler: Use a thread + sleep loop instead of WTF::WorkQueue for taking samples
2031         https://bugs.webkit.org/show_bug.cgi?id=154017
2032
2033         Reviewed by Geoffrey Garen.
2034
2035         By moving to an explicitly created seperate thread + sample-then-sleep
2036         loop, we can remove a lot of the crufty code around WorkQueue.
2037         We're also getting sample rates that are much closer to what we're
2038         asking the OS for. When the sampling handler was built off of WorkQueue,
2039         we'd often get sample rates much higher than the 1ms we asked for. On Kraken,
2040         we would average about 1.7ms sample rates, even though we'd ask for a 1ms rate.
2041         Now, on Kraken, we're getting about 1.2ms rates. Because we're getting
2042         higher rates, this patch is a performance regression. It's slower because
2043         we're sampling more frequently.
2044
2045         Before this patch, the sampling profiler had the following overhead:
2046         - 10% on Kraken
2047         - 12% on octane
2048         - 15% on AsmBench
2049
2050         With this patch, the sampling profiler has the following overhead:
2051         - 16% on Kraken
2052         - 17% on Octane
2053         - 30% on AsmBench
2054
2055         Comparatively, this new patch has the following overhead over the old sampling profiler:
2056         - 5% on Kraken
2057         - 3.5% on Octane
2058         - 13% slower on AsmBench
2059
2060         * inspector/agents/InspectorScriptProfilerAgent.cpp:
2061         (Inspector::InspectorScriptProfilerAgent::trackingComplete):
2062         * runtime/SamplingProfiler.cpp:
2063         (JSC::SamplingProfiler::SamplingProfiler):
2064         (JSC::SamplingProfiler::~SamplingProfiler):
2065         (JSC::SamplingProfiler::createThreadIfNecessary):
2066         (JSC::SamplingProfiler::timerLoop):
2067         (JSC::SamplingProfiler::takeSample):
2068         (JSC::tryGetBytecodeIndex):
2069         (JSC::SamplingProfiler::shutdown):
2070         (JSC::SamplingProfiler::start):
2071         (JSC::SamplingProfiler::pause):
2072         (JSC::SamplingProfiler::noticeCurrentThreadAsJSCExecutionThread):
2073         (JSC::SamplingProfiler::noticeJSLockAcquisition):
2074         (JSC::SamplingProfiler::noticeVMEntry):
2075         (JSC::SamplingProfiler::clearData):
2076         (JSC::SamplingProfiler::stop): Deleted.
2077         (JSC::SamplingProfiler::dispatchIfNecessary): Deleted.
2078         (JSC::SamplingProfiler::dispatchFunction): Deleted.
2079         * runtime/SamplingProfiler.h:
2080         (JSC::SamplingProfiler::setTimingInterval):
2081         (JSC::SamplingProfiler::setStopWatch):
2082         * runtime/VM.cpp:
2083         (JSC::VM::VM):
2084
2085 2016-04-05  Commit Queue  <commit-queue@webkit.org>
2086
2087         Unreviewed, rolling out r199073.
2088         https://bugs.webkit.org/show_bug.cgi?id=156261
2089
2090         This change broke internal Mac builds (Requested by ryanhaddad
2091         on #webkit).
2092
2093         Reverted changeset:
2094
2095         "We should support the ability to do a non-effectful getById"
2096         https://bugs.webkit.org/show_bug.cgi?id=156116
2097         http://trac.webkit.org/changeset/199073
2098
2099 2016-04-05  Youenn Fablet  <youenn.fablet@crf.canon.fr>
2100
2101         [Fetch API] Add a runtime flag to fetch API and related constructs
2102         https://bugs.webkit.org/show_bug.cgi?id=156113
2103
2104         Reviewed by Alex Christensen.
2105
2106         Add a fetch API runtime flag based on preferences.
2107         Disable fetch API by default.
2108
2109         * runtime/CommonIdentifiers.h:
2110
2111 2016-04-05  Filip Pizlo  <fpizlo@apple.com>
2112
2113         Unreviewed, fix cloop some more.
2114
2115         * runtime/RegExpInlines.h:
2116         (JSC::RegExp::hasCodeFor):
2117         (JSC::RegExp::hasMatchOnlyCodeFor):
2118
2119 2016-04-05  Filip Pizlo  <fpizlo@apple.com>
2120
2121         Unreviewed, fix cloop.
2122
2123         * jit/CCallHelpers.cpp:
2124
2125 2016-03-18  Filip Pizlo  <fpizlo@apple.com>
2126
2127         JSC should use a shadow stack version of CHICKEN so that debuggers have the option of retrieving tail-deleted frames
2128         https://bugs.webkit.org/show_bug.cgi?id=155598
2129
2130         Reviewed by Saam Barati.
2131
2132         JSC is the first JSVM to have proper tail calls. This means that error.stack and the
2133         debugger will appear to "delete" strict mode stack frames, if the call that this frame made
2134         was in tail position. This is exactly what functional programmers expect - they don't want
2135         the VM to waste resources on tail-deleted frames to ensure that it's legal to loop forever
2136         using tail calls. It's also something that non-functional programmers fear. It's not clear
2137         that tail-deleted frames would actually degrade the debugging experience, but the fear is
2138         real, so it's worthwhile to do something about it.
2139
2140         It turns out that there is at least one tail call implementation that doesn't suffer from
2141         this problem. It implements proper tail calls in the sense that you won't run out of memory
2142         by tail-looping. It also has the power to show you tail-deleted frames in a backtrace, so
2143         long as you haven't yet run out of memory. It's called CHICKEN Scheme, and it's one of my
2144         favorite hacks:
2145
2146         http://www.more-magic.net/posts/internals-gc.html
2147
2148         CHICKEN does many awesome things. The intuition from CHICKEN that we use here is a simple
2149         one: what if a tail call still kept the tail-deleted frame, and the GC actually deleted that
2150         frame only once we proved that there was insufficient memory to keep it around.
2151
2152         CHICKEN does this by reshaping the C stack with longjmp/setjmp. We can't do that because we
2153         can have arbitrary native code, and that native code does not have relocatable stack frames.
2154
2155         But we can do something almost like CHICKEN on a shadow stack. It's a common trick to have a
2156         VM maintain two stacks - the actual execution stack plus a shadow stack that has some extra
2157         information. The shadow stack can be reshaped, moved, etc, since the VM tightly controls its
2158         layout. The main stack can then continue to obey ABI rules.
2159
2160         This patch implements a mechanism for being able to display stack traces that include
2161         tail-deleted frames. It uses a shadow stack that behaves like a CHICKEN stack: it has all
2162         frames all the time, though we will collect the tail-deleted ones if the stack gets too big.
2163         This new mechanism is called ShadowChicken, obviously: it's CHICKEN on a shadow stack.
2164
2165         ShadowChicken is always on, but individual CodeBlocks may make their own choices about
2166         whether to opt into it. They will do that at bytecompile time based on the debugger mode on
2167         their global object.
2168
2169         When no CodeBlock opts in, there is no overhead, since ShadowChicken ends up doing nothing
2170         in that case. Well, except when exceptions are thrown. Then it might do some work, but it's
2171         minor.
2172
2173         When all CodeBlocks opt in, there is about 6% overhead. That's too much overhead to enable
2174         this all the time, but it's low enough to justify enabling in the Inspector. It's currently
2175         enabled on all CodeBlocks only when you use an Option. Otherwise it will auto-enable if the
2176         debugger is on.
2177
2178         Note that ShadowChicken attempts to gracefully handle the presence of stack frames that have
2179         no logging. This is essential since we *can* have debugging enabled in one GlobalObject and
2180         disabled in another. Also, some frames don't do ShadowChicken because they just haven't been
2181         hacked to do it yet. Native frames fall into this category, as do the VM entry frames.
2182
2183         This doesn't yet wire ShadowChicken into DebuggerCallFrame. That will take more work. It
2184         just makes a ShadowChicken stack walk function available to jsc. It's used from the
2185         shadow-chicken tests.
2186
2187         * API/JSContextRef.cpp:
2188         (BacktraceFunctor::BacktraceFunctor):
2189         (BacktraceFunctor::operator()):
2190         (JSContextCreateBacktrace):
2191         * CMakeLists.txt:
2192         * JavaScriptCore.xcodeproj/project.pbxproj:
2193         * bytecode/BytecodeList.json:
2194         * bytecode/BytecodeUseDef.h:
2195         (JSC::computeUsesForBytecodeOffset):
2196         (JSC::computeDefsForBytecodeOffset):
2197         * bytecode/CodeBlock.cpp:
2198         (JSC::CodeBlock::dumpBytecode):
2199         (JSC::RecursionCheckFunctor::RecursionCheckFunctor):
2200         (JSC::RecursionCheckFunctor::operator()):
2201         (JSC::CodeBlock::noticeIncomingCall):
2202         * bytecompiler/BytecodeGenerator.cpp:
2203         (JSC::BytecodeGenerator::emitEnter):
2204         (JSC::BytecodeGenerator::emitCallInTailPosition):
2205         (JSC::BytecodeGenerator::emitCallVarargsInTailPosition):
2206         (JSC::BytecodeGenerator::emitCallVarargs):
2207         (JSC::BytecodeGenerator::emitLogShadowChickenPrologueIfNecessary):
2208         (JSC::BytecodeGenerator::emitLogShadowChickenTailIfNecessary):
2209         (JSC::BytecodeGenerator::emitCallDefineProperty):
2210         * bytecompiler/BytecodeGenerator.h:
2211         * debugger/DebuggerCallFrame.cpp:
2212         (JSC::LineAndColumnFunctor::operator()):
2213         (JSC::LineAndColumnFunctor::column):
2214         (JSC::FindCallerMidStackFunctor::FindCallerMidStackFunctor):
2215         (JSC::FindCallerMidStackFunctor::operator()):
2216         (JSC::DebuggerCallFrame::DebuggerCallFrame):
2217         * dfg/DFGAbstractInterpreterInlines.h:
2218         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2219         * dfg/DFGByteCodeParser.cpp:
2220         (JSC::DFG::ByteCodeParser::parseBlock):
2221         * dfg/DFGClobberize.h:
2222         (JSC::DFG::clobberize):
2223         * dfg/DFGDoesGC.cpp:
2224         (JSC::DFG::doesGC):
2225         * dfg/DFGFixupPhase.cpp:
2226         (JSC::DFG::FixupPhase::fixupNode):
2227         * dfg/DFGNodeType.h:
2228         * dfg/DFGPredictionPropagationPhase.cpp:
2229         (JSC::DFG::PredictionPropagationPhase::propagate):
2230         * dfg/DFGSafeToExecute.h:
2231         (JSC::DFG::safeToExecute):
2232         * dfg/DFGSpeculativeJIT32_64.cpp:
2233         (JSC::DFG::SpeculativeJIT::compile):
2234         * dfg/DFGSpeculativeJIT64.cpp:
2235         (JSC::DFG::SpeculativeJIT::compile):
2236         * ftl/FTLAbstractHeapRepository.cpp:
2237         * ftl/FTLAbstractHeapRepository.h:
2238         * ftl/FTLCapabilities.cpp:
2239         (JSC::FTL::canCompile):
2240         * ftl/FTLLowerDFGToB3.cpp:
2241         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2242         (JSC::FTL::DFG::LowerDFGToB3::compileSetRegExpObjectLastIndex):
2243         (JSC::FTL::DFG::LowerDFGToB3::compileLogShadowChickenPrologue):
2244         (JSC::FTL::DFG::LowerDFGToB3::compileLogShadowChickenTail):
2245         (JSC::FTL::DFG::LowerDFGToB3::didOverflowStack):
2246         (JSC::FTL::DFG::LowerDFGToB3::allocateJSArray):
2247         (JSC::FTL::DFG::LowerDFGToB3::setupShadowChickenPacket):
2248         (JSC::FTL::DFG::LowerDFGToB3::boolify):
2249         * heap/Heap.cpp:
2250         (JSC::Heap::markRoots):
2251         (JSC::Heap::visitSamplingProfiler):
2252         (JSC::Heap::visitShadowChicken):
2253         (JSC::Heap::traceCodeBlocksAndJITStubRoutines):
2254         (JSC::Heap::collectImpl):
2255         * heap/Heap.h:
2256         * inspector/ScriptCallStackFactory.cpp:
2257         (Inspector::CreateScriptCallStackFunctor::CreateScriptCallStackFunctor):
2258         (Inspector::CreateScriptCallStackFunctor::operator()):
2259         (Inspector::createScriptCallStack):
2260         * interpreter/CallFrame.h:
2261         (JSC::ExecState::iterate):
2262         * interpreter/Interpreter.cpp:
2263         (JSC::DumpRegisterFunctor::DumpRegisterFunctor):
2264         (JSC::DumpRegisterFunctor::operator()):
2265         (JSC::GetStackTraceFunctor::GetStackTraceFunctor):
2266         (JSC::GetStackTraceFunctor::operator()):
2267         (JSC::Interpreter::getStackTrace):
2268         (JSC::GetCatchHandlerFunctor::handler):
2269         (JSC::GetCatchHandlerFunctor::operator()):
2270         (JSC::notifyDebuggerOfUnwinding):
2271         (JSC::UnwindFunctor::UnwindFunctor):
2272         (JSC::UnwindFunctor::operator()):
2273         (JSC::UnwindFunctor::copyCalleeSavesToVMCalleeSavesBuffer):
2274         * interpreter/ShadowChicken.cpp: Added.
2275         (JSC::ShadowChicken::Packet::dump):
2276         (JSC::ShadowChicken::Frame::dump):
2277         (JSC::ShadowChicken::ShadowChicken):
2278         (JSC::ShadowChicken::~ShadowChicken):
2279         (JSC::ShadowChicken::log):
2280         (JSC::ShadowChicken::update):
2281         (JSC::ShadowChicken::visitChildren):
2282         (JSC::ShadowChicken::reset):
2283         (JSC::ShadowChicken::dump):
2284         (JSC::ShadowChicken::functionsOnStack):
2285         * interpreter/ShadowChicken.h: Added.
2286         (JSC::ShadowChicken::Packet::Packet):
2287         (JSC::ShadowChicken::Packet::tailMarker):
2288         (JSC::ShadowChicken::Packet::throwMarker):
2289         (JSC::ShadowChicken::Packet::prologue):
2290         (JSC::ShadowChicken::Packet::tail):
2291         (JSC::ShadowChicken::Packet::throwPacket):
2292         (JSC::ShadowChicken::Packet::operator bool):
2293         (JSC::ShadowChicken::Packet::isPrologue):
2294         (JSC::ShadowChicken::Packet::isTail):
2295         (JSC::ShadowChicken::Packet::isThrow):
2296         (JSC::ShadowChicken::Frame::Frame):
2297         (JSC::ShadowChicken::Frame::operator==):
2298         (JSC::ShadowChicken::Frame::operator!=):
2299         (JSC::ShadowChicken::log):
2300         (JSC::ShadowChicken::logSize):
2301         (JSC::ShadowChicken::addressOfLogCursor):
2302         (JSC::ShadowChicken::logEnd):
2303         * interpreter/ShadowChickenInlines.h: Added.
2304         (JSC::ShadowChicken::iterate):
2305         * interpreter/StackVisitor.h:
2306         (JSC::StackVisitor::Frame::callee):
2307         (JSC::StackVisitor::Frame::codeBlock):
2308         (JSC::StackVisitor::Frame::bytecodeOffset):
2309         (JSC::StackVisitor::Frame::inlineCallFrame):
2310         (JSC::StackVisitor::Frame::isJSFrame):
2311         (JSC::StackVisitor::Frame::isInlinedFrame):
2312         (JSC::StackVisitor::visit):
2313         * jit/CCallHelpers.cpp: Added.
2314         (JSC::CCallHelpers::logShadowChickenProloguePacket):
2315         (JSC::CCallHelpers::logShadowChickenTailPacket):
2316         (JSC::CCallHelpers::setupShadowChickenPacket):
2317         * jit/CCallHelpers.h:
2318         (JSC::CCallHelpers::prepareForTailCallSlow):
2319         * jit/JIT.cpp:
2320         (JSC::JIT::privateCompileMainPass):
2321         * jit/JIT.h:
2322         * jit/JITExceptions.cpp:
2323         (JSC::genericUnwind):
2324         * jit/JITOpcodes.cpp:
2325         (JSC::JIT::emit_op_resume):
2326         (JSC::JIT::emit_op_log_shadow_chicken_prologue):
2327         (JSC::JIT::emit_op_log_shadow_chicken_tail):
2328         * jit/JITOperations.cpp:
2329         * jit/JITOperations.h:
2330         * jsc.cpp:
2331         (GlobalObject::finishCreation):
2332         (FunctionJSCStackFunctor::FunctionJSCStackFunctor):
2333         (FunctionJSCStackFunctor::operator()):
2334         (functionClearSamplingFlags):
2335         (functionShadowChickenFunctionsOnStack):
2336         (functionReadline):
2337         * llint/LLIntOffsetsExtractor.cpp:
2338         * llint/LLIntSlowPaths.cpp:
2339         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2340         (JSC::LLInt::llint_throw_stack_overflow_error):
2341         * llint/LLIntSlowPaths.h:
2342         * llint/LowLevelInterpreter.asm:
2343         * profiler/ProfileGenerator.cpp:
2344         (JSC::AddParentForConsoleStartFunctor::foundParent):
2345         (JSC::AddParentForConsoleStartFunctor::operator()):
2346         * runtime/Error.cpp:
2347         (JSC::FindFirstCallerFrameWithCodeblockFunctor::FindFirstCallerFrameWithCodeblockFunctor):
2348         (JSC::FindFirstCallerFrameWithCodeblockFunctor::operator()):
2349         (JSC::addErrorInfoAndGetBytecodeOffset):
2350         * runtime/JSFunction.cpp:
2351         (JSC::RetrieveArgumentsFunctor::result):
2352         (JSC::RetrieveArgumentsFunctor::operator()):
2353         (JSC::retrieveArguments):
2354         (JSC::RetrieveCallerFunctionFunctor::result):
2355         (JSC::RetrieveCallerFunctionFunctor::operator()):
2356         (JSC::retrieveCallerFunction):
2357         * runtime/JSGlobalObjectFunctions.cpp:
2358         (JSC::GlobalFuncProtoGetterFunctor::result):
2359         (JSC::GlobalFuncProtoGetterFunctor::operator()):
2360         (JSC::globalFuncProtoGetter):
2361         (JSC::GlobalFuncProtoSetterFunctor::allowsAccess):
2362         (JSC::GlobalFuncProtoSetterFunctor::operator()):
2363         * runtime/NullSetterFunction.cpp:
2364         (JSC::GetCallerStrictnessFunctor::GetCallerStrictnessFunctor):
2365         (JSC::GetCallerStrictnessFunctor::operator()):
2366         (JSC::GetCallerStrictnessFunctor::callerIsStrict):
2367         (JSC::callerIsStrict):
2368         * runtime/ObjectConstructor.cpp:
2369         (JSC::ObjectConstructorGetPrototypeOfFunctor::result):
2370         (JSC::ObjectConstructorGetPrototypeOfFunctor::operator()):
2371         (JSC::objectConstructorGetPrototypeOf):
2372         * runtime/Options.h:
2373         * runtime/VM.cpp:
2374         (JSC::VM::VM):
2375         (JSC::SetEnabledProfilerFunctor::operator()):
2376         * runtime/VM.h:
2377         (JSC::VM::shouldBuilderPCToCodeOriginMapping):
2378         (JSC::VM::bytecodeIntrinsicRegistry):
2379         (JSC::VM::shadowChicken):
2380         * tests/stress/resources/shadow-chicken-support.js: Added.
2381         (describeFunction):
2382         (describeArray):
2383         (expectStack):
2384         (initialize):
2385         * tests/stress/shadow-chicken-disabled.js: Added.
2386         (test1.foo):
2387         (test1.bar):
2388         (test1.baz):
2389         (test1):
2390         (test2.foo):
2391         (test2.bar):
2392         (test2.baz):
2393         (test2):
2394         (test3.foo):
2395         (test3.bar):
2396         (test3.baz):
2397         (test3):
2398         * tests/stress/shadow-chicken-enabled.js: Added.
2399         (test1.foo):
2400         (test1.bar):
2401         (test1.baz):
2402         (test1):
2403         (test2.foo):
2404         (test2.bar):
2405         (test2.baz):
2406         (test2):
2407         (test3.bob):
2408         (test3.thingy):
2409         (test3.foo):
2410         (test3.bar):
2411         (test3.baz):
2412         (test3):
2413         (test4.bob):
2414         (test4.thingy):
2415         (test4.foo):
2416         (test4.bar):
2417         (test4.baz):
2418         (test4):
2419         (test5.foo):
2420         (test5):
2421         * tools/JSDollarVMPrototype.cpp:
2422         (JSC::CallerFrameJITTypeFunctor::CallerFrameJITTypeFunctor):
2423         (JSC::CallerFrameJITTypeFunctor::operator()):
2424         (JSC::CallerFrameJITTypeFunctor::jitType):
2425         (JSC::functionLLintTrue):
2426         (JSC::CellAddressCheckFunctor::CellAddressCheckFunctor):
2427         (JSC::CellAddressCheckFunctor::operator()):
2428         (JSC::JSDollarVMPrototype::isValidCell):
2429         (JSC::JSDollarVMPrototype::isValidCodeBlock):
2430         (JSC::JSDollarVMPrototype::codeBlockForFrame):
2431         (JSC::PrintFrameFunctor::PrintFrameFunctor):
2432         (JSC::PrintFrameFunctor::operator()):
2433         (JSC::printCallFrame):
2434
2435 2016-03-19  Filip Pizlo  <fpizlo@apple.com>
2436
2437         DFG and FTL should constant-fold RegExpExec, RegExpTest, and StringReplace
2438         https://bugs.webkit.org/show_bug.cgi?id=155270
2439
2440         Reviewed by Saam Barati.
2441
2442         This enables constant-folding of RegExpExec, RegExpTest, and StringReplace.
2443
2444         It's now possible to run Yarr on the JIT threads. Since previous work on constant-folding
2445         strings gave the DFG an API for reasoning about JSString constants in terms of
2446         JIT-thread-local WTF::Strings, it's now super easy to just pass strings to Yarr and build IR
2447         based on the results.
2448
2449         But RegExpExec is hard: the folded version still must allocate a RegExpMatchesArray. We must
2450         use the same Structure that the code would have used or else we'll pollute the program's
2451         inline caches. Also, RegExpMatchesArray.h|cpp will allocate the array and its named
2452         properties in one go - we don't want to lose that optimization. So, this patch enables
2453         MaterializeNewObject to allocate objects or arrays with any number of indexed or named
2454         properties. Previously it could only handle objects (but not arrays) and named properties
2455         (but not indexed ones).
2456
2457         This also adds a few minor things for setting the RegExpConstructor cached result.
2458
2459         This is about a 2x speed-up on microbenchmarks when we fold a match success and about a
2460         8x speed-up when we fold a match failure. It's a 10% speed-up on Octane/regexp.
2461
2462         * JavaScriptCore.xcodeproj/project.pbxproj:
2463         * dfg/DFGAbstractInterpreterInlines.h:
2464         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2465         * dfg/DFGClobberize.h:
2466         (JSC::DFG::clobberize):
2467         * dfg/DFGDoesGC.cpp:
2468         (JSC::DFG::doesGC):
2469         * dfg/DFGFixupPhase.cpp:
2470         (JSC::DFG::FixupPhase::fixupNode):
2471         * dfg/DFGGraph.cpp:
2472         (JSC::DFG::Graph::dump):
2473         * dfg/DFGInsertionSet.cpp:
2474         (JSC::DFG::InsertionSet::insertSlow):
2475         (JSC::DFG::InsertionSet::execute):
2476         * dfg/DFGInsertionSet.h:
2477         (JSC::DFG::InsertionSet::insertCheck):
2478         * dfg/DFGLazyJSValue.cpp:
2479         (JSC::DFG::LazyJSValue::tryGetString):
2480         * dfg/DFGMayExit.cpp:
2481         (JSC::DFG::mayExit):
2482         * dfg/DFGNode.h:
2483         (JSC::DFG::StackAccessData::flushedAt):
2484         (JSC::DFG::OpInfo::OpInfo): Deleted.
2485         * dfg/DFGNodeType.h:
2486         * dfg/DFGObjectAllocationSinkingPhase.cpp:
2487         * dfg/DFGObjectMaterializationData.cpp:
2488         (JSC::DFG::ObjectMaterializationData::dump):
2489         (JSC::DFG::PhantomPropertyValue::dump): Deleted.
2490         (JSC::DFG::ObjectMaterializationData::oneWaySimilarityScore): Deleted.
2491         (JSC::DFG::ObjectMaterializationData::similarityScore): Deleted.
2492         * dfg/DFGObjectMaterializationData.h:
2493         (JSC::DFG::PhantomPropertyValue::PhantomPropertyValue): Deleted.
2494         (JSC::DFG::PhantomPropertyValue::operator==): Deleted.
2495         * dfg/DFGOpInfo.h: Added.
2496         (JSC::DFG::OpInfo::OpInfo):
2497         * dfg/DFGOperations.cpp:
2498         * dfg/DFGOperations.h:
2499         * dfg/DFGPredictionPropagationPhase.cpp:
2500         (JSC::DFG::PredictionPropagationPhase::propagate):
2501         * dfg/DFGPromotedHeapLocation.cpp:
2502         (WTF::printInternal):
2503         * dfg/DFGPromotedHeapLocation.h:
2504         * dfg/DFGSafeToExecute.h:
2505         (JSC::DFG::safeToExecute):
2506         * dfg/DFGSpeculativeJIT.cpp:
2507         (JSC::DFG::SpeculativeJIT::~SpeculativeJIT):
2508         (JSC::DFG::SpeculativeJIT::emitAllocateRawObject):
2509         (JSC::DFG::SpeculativeJIT::emitGetLength):
2510         (JSC::DFG::SpeculativeJIT::compileLazyJSConstant):
2511         (JSC::DFG::SpeculativeJIT::compileMaterializeNewObject):
2512         (JSC::DFG::SpeculativeJIT::compileRecordRegExpCachedResult):
2513         (JSC::DFG::SpeculativeJIT::emitAllocateJSArray): Deleted.
2514         * dfg/DFGSpeculativeJIT.h:
2515         (JSC::DFG::SpeculativeJIT::emitAllocateDestructibleObject):
2516         * dfg/DFGSpeculativeJIT32_64.cpp:
2517         (JSC::DFG::SpeculativeJIT::compile):
2518         * dfg/DFGSpeculativeJIT64.cpp:
2519         (JSC::DFG::SpeculativeJIT::compile):
2520         * dfg/DFGStoreBarrierInsertionPhase.cpp:
2521         * dfg/DFGStrengthReductionPhase.cpp:
2522         (JSC::DFG::StrengthReductionPhase::StrengthReductionPhase):
2523         (JSC::DFG::StrengthReductionPhase::handleNode):
2524         (JSC::DFG::StrengthReductionPhase::handleCommutativity):
2525         (JSC::DFG::StrengthReductionPhase::executeInsertionSet):
2526         * dfg/DFGValidate.cpp:
2527         (JSC::DFG::Validate::validate):
2528         (JSC::DFG::Validate::validateCPS):
2529         * ftl/FTLAbstractHeapRepository.cpp:
2530         * ftl/FTLAbstractHeapRepository.h:
2531         * ftl/FTLCapabilities.cpp:
2532         (JSC::FTL::canCompile):
2533         * ftl/FTLLowerDFGToB3.cpp:
2534         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2535         (JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSize):
2536         (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
2537         (JSC::FTL::DFG::LowerDFGToB3::compileMaterializeCreateActivation):
2538         (JSC::FTL::DFG::LowerDFGToB3::compileSetRegExpObjectLastIndex):
2539         (JSC::FTL::DFG::LowerDFGToB3::compileRecordRegExpCachedResult):
2540         (JSC::FTL::DFG::LowerDFGToB3::didOverflowStack):
2541         (JSC::FTL::DFG::LowerDFGToB3::storageForTransition):
2542         (JSC::FTL::DFG::LowerDFGToB3::initializeArrayElements):
2543         (JSC::FTL::DFG::LowerDFGToB3::allocatePropertyStorage):
2544         (JSC::FTL::DFG::LowerDFGToB3::isNotCellOrMisc):
2545         (JSC::FTL::DFG::LowerDFGToB3::unboxDouble):
2546         * ftl/FTLOperations.cpp:
2547         (JSC::FTL::operationPopulateObjectInOSR):
2548         (JSC::FTL::operationNewObjectWithButterfly): Deleted.
2549         * ftl/FTLOperations.h:
2550         * inspector/ContentSearchUtilities.cpp:
2551         * runtime/JSObject.h:
2552         (JSC::JSObject::createRawObject):
2553         (JSC::JSFinalObject::create):
2554         * runtime/RegExp.cpp:
2555         (JSC::RegExp::compile):
2556         (JSC::RegExp::match):
2557         (JSC::RegExp::matchConcurrently):
2558         (JSC::RegExp::compileMatchOnly):
2559         (JSC::RegExp::deleteCode):
2560         * runtime/RegExp.h:
2561         * runtime/RegExpCachedResult.h:
2562         (JSC::RegExpCachedResult::offsetOfLastRegExp):
2563         (JSC::RegExpCachedResult::offsetOfLastInput):
2564         (JSC::RegExpCachedResult::offsetOfResult):
2565         (JSC::RegExpCachedResult::offsetOfReified):
2566         * runtime/RegExpConstructor.h:
2567         (JSC::RegExpConstructor::offsetOfCachedResult):
2568         * runtime/RegExpInlines.h:
2569         (JSC::RegExp::hasCodeFor):
2570         (JSC::RegExp::compileIfNecessary):
2571         (JSC::RegExp::matchInline):
2572         (JSC::RegExp::hasMatchOnlyCodeFor):
2573         (JSC::RegExp::compileIfNecessaryMatchOnly):
2574         * runtime/RegExpObjectInlines.h:
2575         (JSC::RegExpObject::execInline):
2576         * runtime/StringPrototype.cpp:
2577         (JSC::substituteBackreferencesSlow):
2578         (JSC::substituteBackreferencesInline):
2579         (JSC::substituteBackreferences):
2580         (JSC::StringRange::StringRange):
2581         * runtime/StringPrototype.h:
2582         * runtime/VM.h:
2583         * tests/stress/simple-regexp-exec-folding-fail.js: Added.
2584         (foo):
2585         * tests/stress/simple-regexp-exec-folding.js: Added.
2586         (foo):
2587         * tests/stress/simple-regexp-test-folding-fail.js: Added.
2588         (foo):
2589         * tests/stress/simple-regexp-test-folding.js: Added.
2590         (foo):
2591         * yarr/RegularExpression.cpp:
2592         * yarr/Yarr.h:
2593         * yarr/YarrInterpreter.cpp:
2594         (JSC::Yarr::Interpreter::interpret):
2595         (JSC::Yarr::ByteCompiler::ByteCompiler):
2596         (JSC::Yarr::ByteCompiler::compile):
2597         (JSC::Yarr::ByteCompiler::checkInput):
2598         (JSC::Yarr::byteCompile):
2599         (JSC::Yarr::interpret):
2600         * yarr/YarrInterpreter.h:
2601         (JSC::Yarr::BytecodePattern::BytecodePattern):
2602
2603 2016-04-05  Keith Miller  <keith_miller@apple.com>
2604
2605         We should support the ability to do a non-effectful getById
2606         https://bugs.webkit.org/show_bug.cgi?id=156116
2607
2608         Reviewed by Benjamin Poulain.
2609
2610         Currently, there is no way in JS to do a non-effectful getById. A non-effectful getById is
2611         useful because it enables us to take different code paths based on values that we would
2612         otherwise not be able to have knowledge of. This patch adds this new feature called
2613         try_get_by_id that will attempt to do as much of a get_by_id as possible without performing
2614         an effectful behavior. Thus, try_get_by_id will return the value if the slot is a value, the
2615         GetterSetter object if the slot is a normal accessor (not a CustomGetterSetter) and
2616         undefined if the slot is unset.  If the slot is proxied or any other cases then the result
2617         is null. In theory, if we ever wanted to check for null we could add a sentinal object to
2618         the global object that indicates we could not get the result.
2619
2620         In order to implement this feature we add a new enum GetByIdKind that indicates what to do
2621         for accessor properties in PolymorphicAccess. If the GetByIdKind is pure then we treat the
2622         get_by_id the same way we would for load and return the value at the appropriate offset.
2623         Additionally, in order to make sure the we can properly compare the GetterSetter object
2624         with === GetterSetters are now JSObjects. This comes at the cost of eight extra bytes on the
2625         GetterSetter object but it vastly simplifies the patch. Additionally, the extra bytes are
2626         likely to have little to no impact on memory usage as normal accessors are generally rare.
2627
2628         * JavaScriptCore.xcodeproj/project.pbxproj:
2629         * builtins/BuiltinExecutables.cpp:
2630         (JSC::BuiltinExecutables::createDefaultConstructor):
2631         (JSC::BuiltinExecutables::createBuiltinExecutable):
2632         (JSC::createBuiltinExecutable):
2633         (JSC::BuiltinExecutables::createExecutable):
2634         (JSC::createExecutableInternal): Deleted.
2635         * builtins/BuiltinExecutables.h:
2636         * bytecode/BytecodeIntrinsicRegistry.h:
2637         * bytecode/BytecodeList.json:
2638         * bytecode/BytecodeUseDef.h:
2639         (JSC::computeUsesForBytecodeOffset):
2640         (JSC::computeDefsForBytecodeOffset):
2641         * bytecode/CodeBlock.cpp:
2642         (JSC::CodeBlock::dumpBytecode):
2643         * bytecode/PolymorphicAccess.cpp:
2644         (JSC::AccessCase::tryGet):
2645         (JSC::AccessCase::generate):
2646         (WTF::printInternal):
2647         * bytecode/PolymorphicAccess.h:
2648         (JSC::AccessCase::isGet): Deleted.
2649         (JSC::AccessCase::isPut): Deleted.
2650         (JSC::AccessCase::isIn): Deleted.
2651         * bytecode/StructureStubInfo.cpp:
2652         (JSC::StructureStubInfo::reset):
2653         * bytecode/StructureStubInfo.h:
2654         * bytecompiler/BytecodeGenerator.cpp:
2655         (JSC::BytecodeGenerator::emitTryGetById):
2656         * bytecompiler/BytecodeGenerator.h:
2657         * bytecompiler/NodesCodegen.cpp:
2658         (JSC::BytecodeIntrinsicNode::emit_intrinsic_tryGetById):
2659         * dfg/DFGSpeculativeJIT32_64.cpp:
2660         (JSC::DFG::SpeculativeJIT::cachedGetById):
2661         * dfg/DFGSpeculativeJIT64.cpp:
2662         (JSC::DFG::SpeculativeJIT::cachedGetById):
2663         * ftl/FTLLowerDFGToB3.cpp:
2664         (JSC::FTL::DFG::LowerDFGToB3::getById):
2665         * jit/JIT.cpp:
2666         (JSC::JIT::privateCompileMainPass):
2667         (JSC::JIT::privateCompileSlowCases):
2668         * jit/JIT.h:
2669         * jit/JITInlineCacheGenerator.cpp:
2670         (JSC::JITGetByIdGenerator::JITGetByIdGenerator):
2671         * jit/JITInlineCacheGenerator.h:
2672         * jit/JITInlines.h:
2673         (JSC::JIT::callOperation):
2674         * jit/JITOperations.cpp:
2675         * jit/JITOperations.h:
2676         * jit/JITPropertyAccess.cpp:
2677         (JSC::JIT::emitGetByValWithCachedId):
2678         (JSC::JIT::emit_op_try_get_by_id):
2679         (JSC::JIT::emitSlow_op_try_get_by_id):
2680         (JSC::JIT::emit_op_get_by_id):
2681         * jit/JITPropertyAccess32_64.cpp:
2682         (JSC::JIT::emitGetByValWithCachedId):
2683         (JSC::JIT::emit_op_try_get_by_id):
2684         (JSC::JIT::emitSlow_op_try_get_by_id):
2685         (JSC::JIT::emit_op_get_by_id):
2686         * jit/Repatch.cpp:
2687         (JSC::repatchByIdSelfAccess):
2688         (JSC::appropriateOptimizingGetByIdFunction):
2689         (JSC::appropriateGenericGetByIdFunction):
2690         (JSC::tryCacheGetByID):
2691         (JSC::repatchGetByID):
2692         (JSC::resetGetByID):
2693         * jit/Repatch.h:
2694         * jsc.cpp:
2695         (GlobalObject::finishCreation):
2696         (functionGetGetterSetter):
2697         (functionCreateBuiltin):
2698         * llint/LLIntData.cpp:
2699         (JSC::LLInt::Data::performAssertions):
2700         * llint/LLIntSlowPaths.cpp:
2701         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
2702         * llint/LLIntSlowPaths.h:
2703         * llint/LowLevelInterpreter.asm:
2704         * runtime/GetterSetter.cpp:
2705         * runtime/GetterSetter.h:
2706         * runtime/JSType.h:
2707         * runtime/PropertySlot.cpp:
2708         (JSC::PropertySlot::getPureResult):
2709         * runtime/PropertySlot.h:
2710         * runtime/ProxyObject.cpp:
2711         (JSC::ProxyObject::getOwnPropertySlotCommon):
2712         * tests/stress/try-get-by-id.js: Added.
2713         (tryGetByIdText):
2714         (getCaller.obj.1.throw.new.Error.let.func):
2715         (getCaller.obj.1.throw.new.Error):
2716         (throw.new.Error.get let):
2717         (throw.new.Error.):
2718         (throw.new.Error.let.get createBuiltin):
2719         (get let):
2720         (let.get createBuiltin):
2721         (let.func):
2722         (get let.func):
2723         (get throw):
2724
2725 2016-04-05  Saam barati  <sbarati@apple.com>
2726
2727         jsc-layout-tests.yaml/js/script-tests/regress-141098.js failing on Yosemite Debug after r198989
2728         https://bugs.webkit.org/show_bug.cgi?id=156187
2729
2730         Reviewed by Filip Pizlo.
2731
2732         This is a speculative fix. Lets see if the prevents the timeout.
2733
2734         * parser/Parser.cpp:
2735         (JSC::Parser<LexerType>::parseStatementListItem):
2736
2737 2016-04-04  Filip Pizlo  <fpizlo@apple.com>
2738
2739         PolymorphicAccess should have a MegamorphicLoad case
2740         https://bugs.webkit.org/show_bug.cgi?id=156182
2741
2742         Reviewed by Geoffrey Garen and Keith Miller.
2743
2744         This introduces a new case to PolymorphicAccess called MegamorphicLoad. This inlines the lookup in
2745         the PropertyTable. It's cheaper than switching on a huge number of cases and it's cheaper than
2746         calling into C++ to do the same job - particularly since inlining the lookup into an access means
2747         that we can precompute the hash code.
2748
2749         When writing the inline code for the hashtable lookup, I found that our hashing algorithm was not
2750         optimal. It used a double-hashing method for reducing collision pathologies. This is great for
2751         improving the performance of some worst-case scenarios. But this misses the point of a hashtable: we
2752         want to optimize the average-case performance. When optimizing for average-case, we can choose to
2753         either focus on maximizing the likelihood of the fast case happening, or to minimize the cost of the
2754         worst-case, or to minimize the cost of the fast case. Even a very basic hashtable will achieve a high
2755         probability of hitting the fast case. So, doing work to reduce the likelihood of a worst-case
2756         pathology only makes sense if it also preserves the good performance of the fast case, or reduces the
2757         likelihood of the worst-case by so much that it's a win for the average case even with a slow-down in
2758         the fast case.
2759
2760         I don't believe, based on looking at how the double-hashing is implemented, that it's possible that
2761         this preserves the good performance of the fast case. It requires at least one more value to be live
2762         around the loop, and dramatically increases the register pressure at key points inside the loop. The
2763         biggest offender is the doubleHash() method itself. There is no getting around how bad this is: if
2764         the compiler live-range-splits that method to death to avoid degrading register pressure elsewhere
2765         then we will pay a steep price anytime we take the second iteration around the loop; but if the
2766         compiler doesn't split around the call then the hashtable lookup fast path will be full of spills on
2767         some architectures (I performed biological register allocation and found that I needed 9 registers
2768         for complete lookup, while x86-64 has only 6 callee-saves; OTOH ARM64 has 10 callee-saves so it might
2769         be better off).
2770
2771         Hence, this patch changes the hashtable lookup to use simple linear probing. This was not a slow-down
2772         on anything, and it made MegamorphicLoad much more sensible since it is less likely to have to spill.
2773
2774         There are some other small changes in this patch, like rationalizing the IC's choice between giving
2775         up after a repatch (i.e. never trying again) and just pretending that nothing happened (so we can
2776         try to repatch again in the future). It looked like the code in Repatch.cpp was set up to be able to
2777         choose between those options, but we weren't fully taking advantage of it because the
2778         regenerateWithCase() method just returned null for any failure, and didn't say whether it was the
2779         sort of failure that renders the inline cache unrepatchable (like memory allocation failure). Now
2780         this is all made explicit. I wanted to make sure this change happened in this patch since the
2781         MegamorphicLoad code automagically generates a MegamorphicLoad case by coalescing other cases. Since
2782         this is intended to avoid blowing out the cache and making it unrepatchable, I wanted to make sure
2783         that the rules for giving up were something that made sense to me.
2784
2785         This is a big win on microbenchmarks. It's neutral on traditional JS benchmarks. It's a slight
2786         speed-up for page loading, because many real websites like to have megamorphic property accesses.
2787
2788         * bytecode/PolymorphicAccess.cpp:
2789         (JSC::AccessGenerationResult::dump):
2790         (JSC::AccessGenerationState::addWatchpoint):
2791         (JSC::AccessCase::get):
2792         (JSC::AccessCase::megamorphicLoad):
2793         (JSC::AccessCase::replace):
2794         (JSC::AccessCase::guardedByStructureCheck):
2795         (JSC::AccessCase::couldStillSucceed):
2796         (JSC::AccessCase::canBeReplacedByMegamorphicLoad):
2797         (JSC::AccessCase::canReplace):
2798         (JSC::AccessCase::generateWithGuard):
2799         (JSC::AccessCase::generate):
2800         (JSC::PolymorphicAccess::PolymorphicAccess):
2801         (JSC::PolymorphicAccess::~PolymorphicAccess):
2802         (JSC::PolymorphicAccess::regenerateWithCases):
2803         (JSC::PolymorphicAccess::regenerateWithCase):
2804         (WTF::printInternal):
2805         * bytecode/PolymorphicAccess.h:
2806         (JSC::AccessCase::isGet):
2807         (JSC::AccessCase::isPut):
2808         (JSC::AccessCase::isIn):
2809         (JSC::AccessGenerationResult::AccessGenerationResult):
2810         (JSC::AccessGenerationResult::operator==):
2811         (JSC::AccessGenerationResult::operator!=):
2812         (JSC::AccessGenerationResult::operator bool):
2813         (JSC::AccessGenerationResult::kind):
2814         (JSC::AccessGenerationResult::code):
2815         (JSC::AccessGenerationResult::madeNoChanges):
2816         (JSC::AccessGenerationResult::gaveUp):
2817         (JSC::AccessGenerationResult::generatedNewCode):
2818         (JSC::PolymorphicAccess::isEmpty):
2819         (JSC::AccessGenerationState::AccessGenerationState):
2820         * bytecode/StructureStubInfo.cpp:
2821         (JSC::StructureStubInfo::aboutToDie):
2822         (JSC::StructureStubInfo::addAccessCase):
2823         * bytecode/StructureStubInfo.h:
2824         * jit/AssemblyHelpers.cpp:
2825         (JSC::AssemblyHelpers::emitStoreStructureWithTypeInfo):
2826         (JSC::AssemblyHelpers::loadProperty):
2827         (JSC::emitRandomThunkImpl):
2828         (JSC::AssemblyHelpers::emitRandomThunk):
2829         (JSC::AssemblyHelpers::emitLoadStructure):
2830         * jit/AssemblyHelpers.h:
2831         (JSC::AssemblyHelpers::loadValue):
2832         (JSC::AssemblyHelpers::moveValueRegs):
2833         (JSC::AssemblyHelpers::argumentsStart):
2834         (JSC::AssemblyHelpers::emitStoreStructureWithTypeInfo):
2835         (JSC::AssemblyHelpers::emitLoadStructure): Deleted.
2836         * jit/GPRInfo.cpp:
2837         (JSC::JSValueRegs::dump):
2838         * jit/GPRInfo.h:
2839         (JSC::JSValueRegs::uses):
2840         * jit/Repatch.cpp:
2841         (JSC::replaceWithJump):
2842         (JSC::tryCacheGetByID):
2843         (JSC::tryCachePutByID):
2844         (JSC::tryRepatchIn):
2845         * jit/ThunkGenerators.cpp:
2846         (JSC::virtualThunkFor):
2847         * runtime/Options.h:
2848         * runtime/PropertyMapHashTable.h:
2849         (JSC::PropertyTable::begin):
2850         (JSC::PropertyTable::find):
2851         (JSC::PropertyTable::get):
2852         * runtime/Structure.h:
2853
2854 2016-04-05  Antoine Quint  <graouts@apple.com>
2855
2856         [WebGL2] Turn the ENABLE_WEBGL2 flag on
2857         https://bugs.webkit.org/show_bug.cgi?id=156061
2858         <rdar://problem/25463193>
2859
2860         Reviewed by Alex Christensen.
2861
2862         * Configurations/FeatureDefines.xcconfig:
2863         * runtime/CommonIdentifiers.h:
2864
2865         Define the conditionalized classes WebGL2RenderingContext and WebGLVertexArrayObject.
2866
2867 2016-04-04  Zan Dobersek  <zdobersek@igalia.com>
2868
2869         Add missing EABI_32BIT_DUMMY_ARG arguments for some callOperation(J_JITOperation_EGReoJ, ...) overloads
2870         https://bugs.webkit.org/show_bug.cgi?id=156161
2871
2872         Reviewed by Yusuke Suzuki.
2873
2874         r197641 added a couple of callOperation(J_JITOperation_EGReoJ, ...) overloads
2875         that handle arguments split into the tag and the payload. The two were split
2876         between the last argument register and the stack on 32-bit ARM EABI systems,
2877         causing incorrect behavior.
2878
2879         Adding EABI_32BIT_DUMMY_ARG pushes the tag and payload together onto the
2880         stack, removing the issue.
2881
2882         * dfg/DFGSpeculativeJIT.h:
2883         (JSC::DFG::SpeculativeJIT::callOperation):
2884
2885 2016-04-04  Joseph Pecoraro  <pecoraro@apple.com>
2886
2887         Avoid copying ModuleLoaderObject.js to resources bundle
2888         https://bugs.webkit.org/show_bug.cgi?id=156188
2889         <rdar://problem/25534383>
2890
2891         Reviewed by Alexey Proskuryakov.
2892
2893         * JavaScriptCore.xcodeproj/project.pbxproj:
2894
2895 2016-04-04  Geoffrey Garen  <ggaren@apple.com>
2896
2897         Unreviewed, rolling out r199016.
2898         https://bugs.webkit.org/show_bug.cgi?id=156140
2899
2900         "Regressed Octane and Kraken on the perf bots."
2901
2902         Reverted changeset:
2903
2904         CopiedBlock should be 16kB
2905         https://bugs.webkit.org/show_bug.cgi?id=156168
2906         http://trac.webkit.org/changeset/199016
2907
2908 2016-04-04  Benjamin Poulain  <bpoulain@apple.com>
2909
2910         [JSC][x86] Fix an assertion in MacroAssembler::branch8()
2911         https://bugs.webkit.org/show_bug.cgi?id=156181
2912
2913         Reviewed by Geoffrey Garen.
2914
2915         * assembler/MacroAssemblerX86Common.h:
2916         (JSC::MacroAssemblerX86Common::branch8):
2917         The test was wrong because valid negative numbers have ones
2918         in the top bits.
2919
2920         I replaced the assertion to be explicit about the valid range.
2921
2922 2016-04-04  Chris Dumez  <cdumez@apple.com>
2923
2924         Regression(r196145): Crash in getOwnPropertyDescriptor on http://www.history.com/shows/vikings
2925         https://bugs.webkit.org/show_bug.cgi?id=156136
2926         <rdar://problem/25410767>
2927
2928         Reviewed by Ryosuke Niwa.
2929
2930         Add a few more identifiers for using in the generated bindings.
2931
2932         * runtime/CommonIdentifiers.h:
2933
2934 2016-04-04  Geoffrey Garen  <ggaren@apple.com>
2935
2936         CopiedBlock should be 16kB
2937         https://bugs.webkit.org/show_bug.cgi?id=156168
2938
2939         Reviewed by Mark Lam.
2940
2941         MarkedBlock is 16kB, and bmalloc's largest fast-path allocation is 16kB,
2942         and the largest page size on Apple devices is 16kB -- so this change
2943         should improve sharing and recycling and keep us on the fast path more.
2944
2945         32kB is also super aggro. At 16kB, we support allocations up to 8kB,
2946         which covers 99.3% of allocations on facebook.com. The 32kB block size
2947         only covered an additional 0.2% of allocations.
2948
2949         * heap/CopiedBlock.h:
2950
2951 2016-04-04  Carlos Garcia Campos  <cgarcia@igalia.com>
2952
2953         REGRESSION(r198792): [GTK] Inspector crashes in Inspector::Protocol::getEnumConstantValue since r198792
2954         https://bugs.webkit.org/show_bug.cgi?id=155745
2955         <rdar://problem/25289456>
2956
2957         Reviewed by Brian Burg.
2958
2959         The problem is that we are generating the Inspector::Protocol::getEnumConstantValue() method and the
2960         enum_constant_values array for every framework that has enum values. So, in case of GTK port we have two
2961         implementations, one for the inspector in JavaScriptCore and another one for Web Automation in WebKit2, but when
2962         using the inspector in WebKit2 we always end up using the one in WebKit2. Since the enum_constant_values array
2963         is smaller in WebKit2 than the one in JavaScriptCore, we crash every time we receive an enum value higher than
2964         the array size. We need to disambiguate the getEnumConstantValue() generated and used for every framework, so we
2965         can use a specific namespace for the enum conversion methods.
2966
2967         * inspector/agents/InspectorDebuggerAgent.cpp:
2968         (Inspector::breakpointActionTypeForString): Use Inspector::Protocol::InspectorHelpers.
2969         * inspector/scripts/codegen/cpp_generator.py:
2970         (CppGenerator.helpers_namespace): Return the namespace name that should be used for the helper methods.
2971         * inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
2972         (CppBackendDispatcherImplementationGenerator._generate_async_dispatcher_class_for_domain): Use
2973         CppGenerator.helpers_namespace() to use the right namespace when using getEnumConstantValue().
2974         (CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command): Ditto.
2975         * inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py:
2976         (CppFrontendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_event): Ditto.
2977         * inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
2978         (CppProtocolTypesHeaderGenerator.generate_output): Move declaration of getEnumConstantValue to a helper function.
2979         (_generate_enum_constant_value_conversion_methods): Do not emit any code if there aren't enums and ensure all
2980         conversion methods are declared inside the helpers namespace.
2981         (_generate_builder_setter_for_member): Use CppGenerator.helpers_namespace() to use the right namespace when
2982         using getEnumConstantValue().
2983         (_generate_unchecked_setter_for_member): Ditto.
2984         (_generate_declarations_for_enum_conversion_methods): Return a list instead of a string so that we can return an
2985         empty list in case of not emitting any code. The caller will use extend() that has no effect when an empty list
2986         is passed.
2987         * inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py:
2988         (CppProtocolTypesImplementationGenerator.generate_output): Use the new helper function to generate both the enum
2989         mapping and conversion methods inside the helpers namespace.
2990         (CppProtocolTypesImplementationGenerator._generate_enum_mapping): Return a list instead of a string so that we
2991         can return an empty list in case of not emitting any code.
2992         (CppProtocolTypesImplementationGenerator._generate_enum_mapping_and_conversion_methods): Ensure we only emit
2993         code when there are enum values, and it's generated inside the helpers namespace.
2994         * inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
2995         * inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
2996         * inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
2997         * inspector/scripts/tests/expected/enum-values.json-result:
2998         * inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
2999         * inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
3000         * inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
3001         * inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
3002         * inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
3003         * inspector/scripts/tests/expected/type-declaration-array-type.json-result:
3004         * inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
3005         * inspector/scripts/tests/expected/type-declaration-object-type.json-result:
3006         * inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
3007
3008 2016-04-04  Csaba Osztrogonác  <ossy@webkit.org>
3009
3010         Unreviewed ARM buildfix after r198981.
3011
3012         * assembler/MacroAssemblerARM.h:
3013         (JSC::MacroAssemblerARM::roundTowardZeroDouble):
3014
3015 2016-04-03  Saam barati  <sbarati@apple.com>
3016
3017         Implement Annex B.3.3 function hoisting rules for function code
3018         https://bugs.webkit.org/show_bug.cgi?id=155672
3019
3020         Reviewed by Geoffrey Garen.
3021
3022         The spec states that functions declared inside a function
3023         inside a block scope are subject to the rules of Annex B.3.3:
3024         https://tc39.github.io/ecma262/#sec-block-level-function-declarations-web-legacy-compatibility-semantics
3025
3026         The rule states that functions declared in such blocks should
3027         be local bindings of the block. If declaring the function's name
3028         as a "var" in the function would not lead to a syntax error (i.e,
3029         if we don't have a let/const/class variable with the same name)
3030         and if we don't have a parameter with the same name, then we
3031         implictly also declare the funcion name as a "var". When evaluating
3032         the block statement we bind the hoisted "var" to be the value
3033         of the local function binding.
3034
3035         There is one more thing we do for web compatibility. We allow
3036         function declarations inside if/else statements that aren't
3037         blocks. For such statements, we transform the code as if the
3038         function were declared inside a block statement. For example:
3039         ``` function foo() { if (cond) function baz() { } }```
3040         is transformed into:
3041         ``` function foo() { if (cond) { function baz() { } } }```
3042
3043         * bytecompiler/BytecodeGenerator.cpp:
3044         (JSC::BytecodeGenerator::initializeDefaultParameterValuesAndSetupFunctionScopeStack):
3045         (JSC::BytecodeGenerator::initializeBlockScopedFunctions):
3046         * bytecompiler/BytecodeGenerator.h:
3047         * parser/Nodes.cpp:
3048         (JSC::ScopeNode::ScopeNode):
3049         (JSC::ProgramNode::ProgramNode):
3050         (JSC::ModuleProgramNode::ModuleProgramNode):
3051         (JSC::EvalNode::EvalNode):
3052         (JSC::FunctionNode::FunctionNode):
3053         * parser/Nodes.h:
3054         (JSC::ScopeNode::hasCapturedVariables):
3055         (JSC::ScopeNode::captures):
3056         (JSC::ScopeNode::hasSloppyModeHoistedFunction):
3057         (JSC::ScopeNode::varDeclarations):
3058         (JSC::ProgramNode::startColumn):
3059         (JSC::ProgramNode::endColumn):
3060         (JSC::EvalNode::startColumn):
3061         (JSC::EvalNode::endColumn):
3062         (JSC::ModuleProgramNode::startColumn):
3063         (JSC::ModuleProgramNode::endColumn):
3064         * parser/Parser.cpp:
3065         (JSC::Parser<LexerType>::Parser):
3066         (JSC::Parser<LexerType>::parseInner):
3067         (JSC::Parser<LexerType>::didFinishParsing):
3068         (JSC::Parser<LexerType>::parseStatement):
3069         (JSC::Parser<LexerType>::parseIfStatement):
3070         * parser/Parser.h:
3071         (JSC::Scope::declareVariable):
3072         (JSC::Scope::declareFunction):
3073         (JSC::Scope::addSloppyModeHoistableFunctionCandidate):
3074         (JSC::Scope::appendFunction):
3075         (JSC::Scope::declareParameter):
3076         (JSC::Scope::mergeInnerArrowFunctionFeatures):
3077         (JSC::Scope::getSloppyModeHoistedFunctions):
3078         (JSC::Scope::getCapturedVars):
3079         (JSC::ScopeRef::containingScope):
3080         (JSC::ScopeRef::operator==):
3081         (JSC::ScopeRef::operator!=):
3082         (JSC::Parser::declareFunction):
3083         (JSC::Parser::hasDeclaredVariable):
3084         (JSC::Parser::isFunctionMetadataNode):
3085         (JSC::Parser::DepthManager::DepthManager):
3086         (JSC::Parser<LexerType>::parse):
3087         * parser/VariableEnvironment.h:
3088         (JSC::VariableEnvironmentEntry::isImported):
3089         (JSC::VariableEnvironmentEntry::isImportedNamespace):
3090         (JSC::VariableEnvironmentEntry::isFunction):
3091         (JSC::VariableEnvironmentEntry::isParameter):
3092         (JSC::VariableEnvironmentEntry::isSloppyModeHoistingCandidate):
3093         (JSC::VariableEnvironmentEntry::setIsCaptured):
3094         (JSC::VariableEnvironmentEntry::setIsConst):
3095         (JSC::VariableEnvironmentEntry::setIsImported):
3096         (JSC::VariableEnvironmentEntry::setIsImportedNamespace):
3097         (JSC::VariableEnvironmentEntry::setIsFunction):
3098         (JSC::VariableEnvironmentEntry::setIsParameter):
3099         (JSC::VariableEnvironmentEntry::setIsSloppyModeHoistingCandidate):
3100         (JSC::VariableEnvironmentEntry::clearIsVar):
3101         * runtime/CodeCache.h:
3102         (JSC::SourceCodeValue::SourceCodeValue):
3103         * runtime/JSScope.cpp:
3104         * runtime/JSScope.h:
3105         * tests/es6.yaml:
3106         * tests/stress/sloppy-mode-function-hoisting.js: Added.
3107         (assert):
3108         (test):
3109         (falsey):
3110         (truthy):
3111         (test.):
3112         (test.a):
3113         (test.f):
3114         (test.let.funcs.f):
3115         (test.catch.f):
3116         (test.foo):
3117         (test.bar):
3118         (test.switch.case.0):
3119         (test.else.f):
3120         (test.b):
3121         (test.c):
3122         (test.d):
3123         (test.e):
3124         (test.g):
3125         (test.h):
3126         (test.i):
3127         (test.j):
3128         (test.k):
3129         (test.l):
3130         (test.m):
3131         (test.n):
3132         (test.o):
3133         (test.p):
3134         (test.q):
3135         (test.r):
3136         (test.s):
3137         (test.t):
3138         (test.u):
3139         (test.v):
3140         (test.w):
3141         (test.x):
3142         (test.y):
3143         (test.z):
3144         (foo):
3145         (bar):
3146         (falsey.bar):
3147         (baz):
3148         (falsey.baz):
3149
3150 2016-04-03  Yusuke Suzuki  <utatane.tea@gmail.com>
3151
3152         Unreviewed, turn ES6 for-in loop test success
3153         https://bugs.webkit.org/show_bug.cgi?id=155451
3154
3155         * tests/es6.yaml:
3156
3157 2016-04-03  Yusuke Suzuki  <utatane.tea@gmail.com>
3158
3159         [JSC] Add truncate operation (rounding to zero)
3160         https://bugs.webkit.org/show_bug.cgi?id=156072
3161
3162         Reviewed by Saam Barati.
3163
3164         Add TruncIntrinsic for Math.trunc. DFG handles it as ArithTrunc.
3165         In DFG, ArithTrunc behaves similar to ArithRound, ArithCeil, and ArithFloor.
3166         ArithTrunc rounds the value towards zero.
3167
3168         And we rewrite @toInteger to use @trunc instead of @abs, @floor, negation and branch.
3169         This is completely the same to what we do in JSValue::toInteger.
3170
3171         Since DFG recognize it, DFG can convert ArithTrunc to Identity if the given argument is Int32.
3172         This is useful because almost all the argument is Int32 in @toLength -> @toInteger -> @trunc case.
3173         In such cases, we can eliminate trunc() call.
3174
3175         As a bonus, to speed up Math.trunc operation, we use x86 SSE round and frintz in ARM64 for ArithRound.
3176         In DFG, we emit these instructions. In FTL, we use Patchpoint to emit these instructions to avoid adding a new B3 IR.
3177
3178         * assembler/MacroAssemblerARM64.h:
3179         (JSC::MacroAssemblerARM64::roundTowardZeroDouble):
3180         (JSC::MacroAssemblerARM64::roundTowardZeroFloat):
3181         * assembler/MacroAssemblerARMv7.h:
3182         (JSC::MacroAssemblerARMv7::roundTowardZeroDouble):
3183         * assembler/MacroAssemblerMIPS.h:
3184         (JSC::MacroAssemblerMIPS::roundTowardZeroDouble):
3185         * assembler/MacroAssemblerSH4.h:
3186         (JSC::MacroAssemblerSH4::roundTowardZeroDouble):
3187         * assembler/MacroAssemblerX86Common.h:
3188         (JSC::MacroAssemblerX86Common::roundTowardZeroDouble):
3189         (JSC::MacroAssemblerX86Common::roundTowardZeroFloat):
3190         * builtins/GlobalObject.js:
3191         (toInteger):
3192         * dfg/DFGAbstractInterpreterInlines.h:
3193         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
3194         * dfg/DFGByteCodeParser.cpp:
3195         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
3196         * dfg/DFGClobberize.h:
3197         (JSC::DFG::clobberize):
3198         * dfg/DFGDoesGC.cpp:
3199         (JSC::DFG::doesGC):
3200         * dfg/DFGFixupPhase.cpp:
3201         (JSC::DFG::FixupPhase::fixupNode):
3202         * dfg/DFGGraph.h:
3203         (JSC::DFG::Graph::roundShouldSpeculateInt32):
3204         * dfg/DFGNode.h:
3205         (JSC::DFG::Node::arithNodeFlags):
3206         (JSC::DFG::Node::hasHeapPrediction):
3207         (JSC::DFG::Node::hasArithRoundingMode):
3208         * dfg/DFGNodeType.h:
3209         * dfg/DFGPredictionPropagationPhase.cpp:
3210         (JSC::DFG::PredictionPropagationPhase::propagate):
3211         * dfg/DFGSafeToExecute.h:
3212         (JSC::DFG::safeToExecute):
3213         * dfg/DFGSpeculativeJIT.cpp:
3214         (JSC::DFG::SpeculativeJIT::compileArithRounding):
3215         * dfg/DFGSpeculativeJIT.h:
3216         * dfg/DFGSpeculativeJIT32_64.cpp:
3217         (JSC::DFG::SpeculativeJIT::compile):
3218         * dfg/DFGSpeculativeJIT64.cpp:
3219         (JSC::DFG::SpeculativeJIT::compile):
3220         * ftl/FTLCapabilities.cpp:
3221         (JSC::FTL::canCompile):
3222         * ftl/FTLLowerDFGToB3.cpp:
3223         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
3224         (JSC::FTL::DFG::LowerDFGToB3::compileArithTrunc):
3225         * ftl/FTLOutput.cpp:
3226         (JSC::FTL::Output::doubleTrunc):
3227         * ftl/FTLOutput.h:
3228         * jit/ThunkGenerators.cpp:
3229         (JSC::truncThunkGenerator):
3230         * jit/ThunkGenerators.h:
3231         * runtime/CommonIdentifiers.h:
3232         * runtime/Intrinsic.h:
3233         * runtime/JSGlobalObject.cpp:
3234         (JSC::JSGlobalObject::init):
3235         * runtime/MathObject.cpp:
3236         (JSC::MathObject::finishCreation):
3237         * runtime/MathObject.h:
3238         * runtime/VM.cpp:
3239         (JSC::thunkGeneratorForIntrinsic):
3240         * tests/stress/math-rounding-infinity.js:
3241         (testTrunc):
3242         * tests/stress/math-rounding-nan.js:
3243         (testTrunc):
3244         * tests/stress/math-rounding-negative-zero.js:
3245         (testTrunc):
3246         * tests/stress/math-trunc-arith-rounding-mode.js: Added.
3247         (firstCareAboutZeroSecondDoesNot):
3248         (firstDoNotCareAboutZeroSecondDoes):
3249         (warmup):
3250         (verifyNegativeZeroIsPreserved):
3251         * tests/stress/math-trunc-basics.js: Added.
3252         (mathTruncOnIntegers):
3253         (mathTruncOnDoubles):
3254         (mathTruncOnBooleans):
3255         (uselessMathTrunc):
3256         (mathTruncWithOverflow):
3257         (mathTruncConsumedAsDouble):
3258         (mathTruncDoesNotCareAboutMinusZero):
3259         (mathTruncNoArguments):
3260         (mathTruncTooManyArguments):
3261         (testMathTruncOnConstants):
3262         (mathTruncStructTransition):
3263         (Math.trunc):
3264         * tests/stress/math-trunc-should-be-truncate.js: Added.
3265         (mathTrunc):
3266
3267 2016-04-03  Skachkov Oleksandr  <gskachkov@gmail.com>
3268
3269         [ES6] Class syntax. Access to new.target inside of the eval should not lead to SyntaxError
3270         https://bugs.webkit.org/show_bug.cgi?id=155545
3271
3272         Reviewed by Saam Barati.
3273
3274         Current patch allow to invoke new.target in eval if this eval is executed within function,
3275         otherwise this will lead to Syntax error
3276
3277         * bytecode/EvalCodeCache.h:
3278         (JSC::EvalCodeCache::getSlow):
3279         * bytecode/ExecutableInfo.h:
3280         (JSC::ExecutableInfo::ExecutableInfo):
3281         (JSC::ExecutableInfo::evalContextType):
3282         * bytecode/UnlinkedCodeBlock.cpp:
3283         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
3284         * bytecode/UnlinkedCodeBlock.h:
3285         (JSC::UnlinkedCodeBlock::evalContextType):
3286         * bytecode/UnlinkedFunctionExecutable.cpp:
3287         (JSC::generateUnlinkedFunctionCodeBlock):
3288         * debugger/DebuggerCallFrame.cpp:
3289         (JSC::DebuggerCallFrame::evaluate):
3290         * interpreter/Interpreter.cpp:
3291         (JSC::eval):
3292         * parser/Parser.cpp:
3293         (JSC::Parser<LexerType>::Parser):
3294         (JSC::Parser<LexerType>::parseMemberExpression):
3295         * parser/Parser.h:
3296         (JSC::Scope::Scope):
3297         (JSC::Scope::setEvalContextType):
3298         (JSC::Scope::evalContextType):
3299         (JSC::parse):
3300         * runtime/CodeCache.cpp:
3301         (JSC::CodeCache::getGlobalCodeBlock):
3302         (JSC::CodeCache::getProgramCodeBlock):
3303         (JSC::CodeCache::getEvalCodeBlock):
3304         (JSC::CodeCache::getModuleProgramCodeBlock):
3305         * runtime/CodeCache.h:
3306         * runtime/Executable.cpp:
3307         (JSC::ScriptExecutable::ScriptExecutable):
3308         (JSC::EvalExecutable::create):
3309         (JSC::EvalExecutable::EvalExecutable):
3310         (JSC::ProgramExecutable::ProgramExecutable):
3311         (JSC::ModuleProgramExecutable::ModuleProgramExecutable):
3312         (JSC::FunctionExecutable::FunctionExecutable):
3313         * runtime/Executable.h:
3314         (JSC::ScriptExecutable::evalContextType):
3315         * runtime/JSGlobalObject.cpp:
3316         (JSC::JSGlobalObject::createEvalCodeBlock):
3317         * runtime/JSGlobalObjectFunctions.cpp:
3318         (JSC::globalFuncEval):
3319         * tests/stress/arrowfunction-lexical-bind-newtarget.js:
3320         * tests/stress/new-target.js:
3321
3322 2016-04-02  Commit Queue  <commit-queue@webkit.org>
3323
3324         Unreviewed, rolling out r198976.
3325         https://bugs.webkit.org/show_bug.cgi?id=156140
3326
3327         "Causes js/regress/array-nonarray-polymorhpic-access.html to
3328         crash." (Requested by ddkilzer on #webkit).
3329
3330         Reverted changeset: