Source/JavaScriptCore/ChangeLog

   1 2017-06-02  Yusuke Suzuki  <utatane.tea@gmail.com>
   2
   3         ASSERTION FAILED: "We should only declare a function as a lexically scoped variable in scopes where var declarations aren't allowed. ..." for function redeclaration with async function module export
   4         https://bugs.webkit.org/show_bug.cgi?id=168844
   5
   6         Reviewed by Saam Barati.
   7
   8         As the same to the exported function declaration, we should set statementDepth = 1 for exported async function declaration.
   9
  10         * parser/Parser.cpp:
  11         (JSC::DepthManager::DepthManager):
  12         (JSC::Parser<LexerType>::parseExportDeclaration):
  13         * parser/Parser.h:
  14         (JSC::Parser::DepthManager::DepthManager): Deleted.
  15         (JSC::Parser::DepthManager::~DepthManager): Deleted.
  16
  17 2017-06-02  Keith Miller  <keith_miller@apple.com>
  18
  19         Defer installing mach breakpoint handler until watchdog is actually called
  20         https://bugs.webkit.org/show_bug.cgi?id=172885
  21
  22         Reviewed by Saam Barati.
  23
  24         Eagerly installing the mach breakpoint handler causes issues with Xcode GUI debugging.
  25         This hides the issue, so it won't occur as often.
  26
  27         * runtime/VMTraps.cpp:
  28         (JSC::VMTraps::SignalSender::send):
  29         (JSC::VMTraps::VMTraps): Deleted.
  30         * runtime/VMTraps.h:
  31
  32 2017-06-02  Filip Pizlo  <fpizlo@apple.com>
  33
  34         Atomics.load and Atomics.store need to be fully fenced
  35         https://bugs.webkit.org/show_bug.cgi?id=172844
  36
  37         Reviewed by Keith Miller.
  38
  39         Implement fully fenced loads and stores in FTL using AtomicXchgAdd(0, ptr) for the load and
  40         AtomicXchg(value, ptr) for the store.
  41
  42         DFG needed no changes because it implements all atomics using a CAS loop.
  43
  44         AtomicsObject.cpp now uses new Atomic<> API for fully fences loads and stores.
  45
  46         Prior to this change, we used half fences (acquire/release) for atomic loads and stores. This
  47         is not correct according to my current understanding of the SAB memory model, which requires
  48         that atomic operations are SC with respect to everything not just other atomics.
  49
  50         * ftl/FTLLowerDFGToB3.cpp:
  51         (JSC::FTL::DFG::LowerDFGToB3::compileAtomicsReadModifyWrite):
  52         * ftl/FTLOutput.cpp:
  53         (JSC::FTL::Output::atomicWeakCAS):
  54         * ftl/FTLOutput.h:
  55         * runtime/AtomicsObject.cpp:
  56
  57 2017-06-02  Ryan Haddad  <ryanhaddad@apple.com>
  58
  59         Unreviewed, attempt to fix the iOS build after r217711.
  60
  61         * assembler/MacroAssemblerARM64.h:
  62         (JSC::MacroAssemblerARM64::xor32):
  63         (JSC::MacroAssemblerARM64::xor64):
  64
  65 2017-06-01  Filip Pizlo  <fpizlo@apple.com>
  66
  67         GC should use scrambled free-lists
  68         https://bugs.webkit.org/show_bug.cgi?id=172793
  69
  70         Reviewed by Mark Lam.
  71
  72         Previously, our bump'n'pop allocator would use a conventional linked-list for the free-list.
  73         The linked-list would be threaded through free memory, as is the usual convention.
  74
  75         This scrambles the next pointers of that free-list. It also scrambles the head pointer, because
  76         this leads to a more natural fast-path structure and saves one register on ARM64.
  77
  78         The secret with which pointers are scrambled is per-allocator. Allocators choose a new secret
  79         every time they do a sweep-to-pop.
  80
  81         This doesn't change the behavior of the bump part of bump'n'pop, but it does refactor the code
  82         quite a bit. Previously, there were four copies of the allocator fast path: two in
  83         MarkedAllocatorInlines.h, one in MarkedAllocator.cpp, and one in AssemblyHelpers.h. The JIT one
  84         was obviously different-looking, but the other three were almost identical. This moves all of
  85         that logic into FreeList. There are now just two copies of the allocator: FreeListInlines.h and
  86         AssemblyHelpers.h.
  87
  88         This appears to be just as fast as our previously allocator.
  89
  90         * JavaScriptCore.xcodeproj/project.pbxproj:
  91         * heap/FreeList.cpp:
  92         (JSC::FreeList::FreeList):
  93         (JSC::FreeList::~FreeList):
  94         (JSC::FreeList::clear):
  95         (JSC::FreeList::initializeList):
  96         (JSC::FreeList::initializeBump):
  97         (JSC::FreeList::contains):
  98         (JSC::FreeList::dump):
  99         * heap/FreeList.h:
 100         (JSC::FreeList::allocationWillFail):
 101         (JSC::FreeList::originalSize):
 102         (JSC::FreeList::addressOfList):
 103         (JSC::FreeList::offsetOfBlock):
 104         (JSC::FreeList::offsetOfList):
 105         (JSC::FreeList::offsetOfIndex):
 106         (JSC::FreeList::offsetOfPayloadEnd):
 107         (JSC::FreeList::offsetOfRemaining):
 108         (JSC::FreeList::offsetOfOriginalSize):
 109         (JSC::FreeList::FreeList): Deleted.
 110         (JSC::FreeList::list): Deleted.
 111         (JSC::FreeList::bump): Deleted.
 112         (JSC::FreeList::operator==): Deleted.
 113         (JSC::FreeList::operator!=): Deleted.
 114         (JSC::FreeList::operator bool): Deleted.
 115         * heap/FreeListInlines.h: Added.
 116         (JSC::FreeList::addFreeCell):
 117         (JSC::FreeList::allocate):
 118         (JSC::FreeList::forEach):
 119         (JSC::FreeList::toOffset):
 120         (JSC::FreeList::fromOffset):
 121         * heap/IncrementalSweeper.cpp:
 122         (JSC::IncrementalSweeper::sweepNextBlock):
 123         * heap/MarkedAllocator.cpp:
 124         (JSC::MarkedAllocator::MarkedAllocator):
 125         (JSC::MarkedAllocator::didConsumeFreeList):
 126         (JSC::MarkedAllocator::tryAllocateWithoutCollecting):
 127         (JSC::MarkedAllocator::tryAllocateIn):
 128         (JSC::MarkedAllocator::allocateSlowCaseImpl):
 129         (JSC::MarkedAllocator::stopAllocating):
 130         (JSC::MarkedAllocator::prepareForAllocation):
 131         (JSC::MarkedAllocator::resumeAllocating):
 132         (JSC::MarkedAllocator::sweep):
 133         (JSC::MarkedAllocator::setFreeList): Deleted.
 134         * heap/MarkedAllocator.h:
 135         (JSC::MarkedAllocator::freeList):
 136         (JSC::MarkedAllocator::isFreeListedCell): Deleted.
 137         * heap/MarkedAllocatorInlines.h:
 138         (JSC::MarkedAllocator::isFreeListedCell):
 139         (JSC::MarkedAllocator::tryAllocate):
 140         (JSC::MarkedAllocator::allocate):
 141         * heap/MarkedBlock.cpp:
 142         (JSC::MarkedBlock::Handle::stopAllocating):
 143         (JSC::MarkedBlock::Handle::lastChanceToFinalize):
 144         (JSC::MarkedBlock::Handle::resumeAllocating):
 145         (JSC::MarkedBlock::Handle::zap):
 146         (JSC::MarkedBlock::Handle::sweep):
 147         (JSC::MarkedBlock::Handle::isFreeListedCell):
 148         (JSC::MarkedBlock::Handle::forEachFreeCell): Deleted.
 149         * heap/MarkedBlock.h:
 150         * heap/MarkedBlockInlines.h:
 151         (JSC::MarkedBlock::Handle::specializedSweep):
 152         (JSC::MarkedBlock::Handle::finishSweepKnowingSubspace):
 153         (JSC::MarkedBlock::Handle::isFreeListedCell): Deleted.
 154         * heap/Subspace.cpp:
 155         (JSC::Subspace::finishSweep):
 156         * heap/Subspace.h:
 157         * jit/AssemblyHelpers.h:
 158         (JSC::AssemblyHelpers::emitAllocateWithNonNullAllocator):
 159         * runtime/JSDestructibleObjectSubspace.cpp:
 160         (JSC::JSDestructibleObjectSubspace::finishSweep):
 161         * runtime/JSDestructibleObjectSubspace.h:
 162         * runtime/JSSegmentedVariableObjectSubspace.cpp:
 163         (JSC::JSSegmentedVariableObjectSubspace::finishSweep):
 164         * runtime/JSSegmentedVariableObjectSubspace.h:
 165         * runtime/JSStringSubspace.cpp:
 166         (JSC::JSStringSubspace::finishSweep):
 167         * runtime/JSStringSubspace.h:
 168         * wasm/js/JSWebAssemblyCodeBlockSubspace.cpp:
 169         (JSC::JSWebAssemblyCodeBlockSubspace::finishSweep):
 170         * wasm/js/JSWebAssemblyCodeBlockSubspace.h:
 171
 172 2017-06-02  Yusuke Suzuki  <utatane.tea@gmail.com>
 173
 174         [JSC] Use @globalPrivate for concatSlowPath
 175         https://bugs.webkit.org/show_bug.cgi?id=172802
 176
 177         Reviewed by Darin Adler.
 178
 179         Use @globalPrivate instead of manually putting it to JSGlobalObject.
 180
 181         * builtins/ArrayPrototype.js:
 182         (concatSlowPath): Deleted.
 183         * runtime/JSGlobalObject.cpp:
 184         (JSC::JSGlobalObject::init):
 185
 186 2017-06-01  Andy Estes  <aestes@apple.com>
 187
 188         REGRESSION (r217626): ENABLE_APPLE_PAY_SESSION_V3 was disabled by mistake
 189         https://bugs.webkit.org/show_bug.cgi?id=172828
 190
 191         Reviewed by Beth Dakin.
 192
 193         * Configurations/FeatureDefines.xcconfig:
 194
 195 2017-06-01  Keith Miller  <keith_miller@apple.com>
 196
 197         Undo rollout in r217638 with bug fix
 198         https://bugs.webkit.org/show_bug.cgi?id=172824
 199
 200         Unreviewed, reland patch with unused set_state code removed.
 201
 202         * API/tests/ExecutionTimeLimitTest.cpp:
 203         (dispatchTermitateCallback):
 204         (testExecutionTimeLimit):
 205         * runtime/JSLock.cpp:
 206         (JSC::JSLock::didAcquireLock):
 207         * runtime/Options.cpp:
 208         (JSC::overrideDefaults):
 209         (JSC::Options::initialize):
 210         * runtime/Options.h:
 211         * runtime/VMTraps.cpp:
 212         (JSC::SignalContext::SignalContext):
 213         (JSC::SignalContext::adjustPCToPointToTrappingInstruction):
 214         (JSC::installSignalHandler):
 215         (JSC::VMTraps::SignalSender::send):
 216         * tools/SigillCrashAnalyzer.cpp:
 217         (JSC::SignalContext::SignalContext):
 218         (JSC::SignalContext::dump):
 219         (JSC::installCrashHandler):
 220         * wasm/WasmBBQPlan.cpp:
 221         (JSC::Wasm::BBQPlan::compileFunctions):
 222         * wasm/WasmFaultSignalHandler.cpp:
 223         (JSC::Wasm::trapHandler):
 224         (JSC::Wasm::enableFastMemory):
 225         * wasm/WasmMachineThreads.cpp:
 226         (JSC::Wasm::resetInstructionCacheOnAllThreads):
 227
 228 2017-06-01  Guillaume Emont  <guijemont@igalia.com>
 229
 230         [JSC][MIPS] SamplingProfiler::timerLoop() sleeps for 4000+ seconds
 231         https://bugs.webkit.org/show_bug.cgi?id=172800
 232
 233         Reviewed by Saam Barati.
 234
 235         This fixes a static_cast<uint64_t> by making it a cast to int64_t
 236         instead, which looks like the original intent. This fixes the
 237         sampling-profiler tests in JSTests/stress.
 238
 239         * runtime/SamplingProfiler.cpp:
 240         (JSC::SamplingProfiler::timerLoop):
 241
 242 2017-06-01  Tomas Popela  <tpopela@redhat.com>, Mark Lam  <mark.lam@apple.com>
 243
 244         RELEASE_ASSERT_NOT_REACHED() in InferredType::kindForFlags() on Big-Endians
 245         https://bugs.webkit.org/show_bug.cgi?id=170945
 246
 247         Reviewed by Mark Lam.
 248
 249         Re-define PutByIdFlags as a int32_t enum explicitly because it is
 250         stored as an int32_t value in UnlinkedInstruction.  This prevents
 251         a bug on 64-bit big endian architectures where the word order is
 252         inverted (when we convert the UnlinkedInstruction into a CodeBlock
 253         Instruction), resulting in the PutByIdFlags value not being stored in
 254         the 32-bit word that the rest of the code expects it to be in.
 255
 256         * bytecode/PutByIdFlags.h:
 257
 258 2017-05-31  Yusuke Suzuki  <utatane.tea@gmail.com>
 259
 260         [JSC] Implement String.prototype.concat in JS builtins
 261         https://bugs.webkit.org/show_bug.cgi?id=172798
 262
 263         Reviewed by Sam Weinig.
 264
 265         Since we have highly effective + operation for strings,
 266         implementing String.prototype.concat in JS simplifies the
 267         implementation and improves performance by using speculated
 268         types.
 269
 270         Added microbenchmarks show performance improvement.
 271
 272         string-concat-long-convert     1063.2787+-12.9101    ^    109.0855+-2.8083        ^ definitely 9.7472x faster
 273         string-concat-convert          1111.1366+-12.2363    ^     99.3402+-1.9874        ^ definitely 11.1852x faster
 274         string-concat                   131.7377+-3.8359     ^     54.3949+-0.9580        ^ definitely 2.4219x faster
 275         string-concat-long               79.4726+-1.9644     ^     64.6301+-1.4941        ^ definitely 1.2297x faster
 276
 277         * builtins/StringPrototype.js:
 278         (globalPrivate.stringConcatSlowPath):
 279         (concat):
 280         * runtime/StringPrototype.cpp:
 281         (JSC::StringPrototype::finishCreation):
 282         (JSC::stringProtoFuncConcat): Deleted.
 283
 284 2017-05-31  Mark Lam  <mark.lam@apple.com>
 285
 286         Remove overrides of visitChildren() that do not add any functionality.
 287         https://bugs.webkit.org/show_bug.cgi?id=172789
 288         <rdar://problem/32500865>
 289
 290         Reviewed by Andreas Kling.
 291
 292         * bytecode/UnlinkedModuleProgramCodeBlock.cpp:
 293         (JSC::UnlinkedModuleProgramCodeBlock::visitChildren): Deleted.
 294         * bytecode/UnlinkedModuleProgramCodeBlock.h:
 295         * bytecode/UnlinkedProgramCodeBlock.cpp:
 296         (JSC::UnlinkedProgramCodeBlock::visitChildren): Deleted.
 297         * bytecode/UnlinkedProgramCodeBlock.h:
 298         * wasm/js/WebAssemblyFunction.cpp:
 299         (JSC::WebAssemblyFunction::visitChildren): Deleted.
 300         * wasm/js/WebAssemblyFunction.h:
 301         * wasm/js/WebAssemblyInstanceConstructor.cpp:
 302         (JSC::WebAssemblyInstanceConstructor::visitChildren): Deleted.
 303         * wasm/js/WebAssemblyInstanceConstructor.h:
 304         * wasm/js/WebAssemblyMemoryConstructor.cpp:
 305         (JSC::WebAssemblyMemoryConstructor::visitChildren): Deleted.
 306         * wasm/js/WebAssemblyMemoryConstructor.h:
 307         * wasm/js/WebAssemblyModuleConstructor.cpp:
 308         (JSC::WebAssemblyModuleConstructor::visitChildren): Deleted.
 309         * wasm/js/WebAssemblyModuleConstructor.h:
 310         * wasm/js/WebAssemblyTableConstructor.cpp:
 311         (JSC::WebAssemblyTableConstructor::visitChildren): Deleted.
 312         * wasm/js/WebAssemblyTableConstructor.h:
 313
 314 2017-05-31  Commit Queue  <commit-queue@webkit.org>
 315
 316         Unreviewed, rolling out r217611 and r217631.
 317         https://bugs.webkit.org/show_bug.cgi?id=172785
 318
 319         "caused wasm-hashset-many.html to become flaky." (Requested by
 320         keith_miller on #webkit).
 321
 322         Reverted changesets:
 323
 324         "Reland r216808, underlying lldb bug has been fixed."
 325         https://bugs.webkit.org/show_bug.cgi?id=172759
 326         http://trac.webkit.org/changeset/217611
 327
 328         "Use dispatch queues for mach exceptions"
 329         https://bugs.webkit.org/show_bug.cgi?id=172775
 330         http://trac.webkit.org/changeset/217631
 331
 332 2017-05-31  Oleksandr Skachkov  <gskachkov@gmail.com>
 333
 334         Rolling out: Prevent async methods named 'function'
 335         https://bugs.webkit.org/show_bug.cgi?id=172776
 336
 337         Reviewed by Mark Lam.
 338
 339         Rolling out https://bugs.webkit.org/show_bug.cgi?id=172660 r217578,
 340         https://bugs.webkit.org/show_bug.cgi?id=172598  r217478
 341         PR to spec was closed, so changes need to roll out. See
 342         https://github.com/tc39/ecma262/pull/884#issuecomment-305212494
 343
 344         * parser/Parser.cpp:
 345         (JSC::Parser<LexerType>::parseClass):
 346         (JSC::Parser<LexerType>::parsePropertyMethod):
 347
 348 2017-05-31  Andy Estes  <aestes@apple.com>
 349
 350         Rename ENABLE_APPLE_PAY_DELEGATE to ENABLE_APPLE_PAY_SESSION_V3 and bump the supported version number
 351         https://bugs.webkit.org/show_bug.cgi?id=172366
 352
 353         Reviewed by Daniel Bates.
 354
 355         * Configurations/FeatureDefines.xcconfig:
 356
 357 2017-05-31  Keith Miller  <keith_miller@apple.com>
 358
 359         Reland r216808, underlying lldb bug has been fixed.
 360         https://bugs.webkit.org/show_bug.cgi?id=172759
 361
 362
 363         Unreviewed, relanding old patch. See: rdar://problem/31183352
 364
 365         * API/tests/ExecutionTimeLimitTest.cpp:
 366         (dispatchTermitateCallback):
 367         (testExecutionTimeLimit):
 368         * runtime/JSLock.cpp:
 369         (JSC::JSLock::didAcquireLock):
 370         * runtime/Options.cpp:
 371         (JSC::overrideDefaults):
 372         (JSC::Options::initialize):
 373         * runtime/Options.h:
 374         * runtime/VMTraps.cpp:
 375         (JSC::SignalContext::SignalContext):
 376         (JSC::SignalContext::adjustPCToPointToTrappingInstruction):
 377         (JSC::installSignalHandler):
 378         (JSC::VMTraps::SignalSender::send):
 379         * tools/SigillCrashAnalyzer.cpp:
 380         (JSC::SignalContext::SignalContext):
 381         (JSC::SignalContext::dump):
 382         (JSC::installCrashHandler):
 383         * wasm/WasmBBQPlan.cpp:
 384         (JSC::Wasm::BBQPlan::compileFunctions):
 385         * wasm/WasmFaultSignalHandler.cpp:
 386         (JSC::Wasm::trapHandler):
 387         (JSC::Wasm::enableFastMemory):
 388         * wasm/WasmMachineThreads.cpp:
 389         (JSC::Wasm::resetInstructionCacheOnAllThreads):
 390
 391 2017-05-31  Keith Miller  <keith_miller@apple.com>
 392
 393         Fix leak in PromiseDeferredTimer
 394         https://bugs.webkit.org/show_bug.cgi?id=172755
 395
 396         Reviewed by JF Bastien.
 397
 398         We were not properly freeing the list of dependencies if we were already tracking the promise before.
 399         This is because addPendingPromise takes the list of dependencies as an rvalue-reference. In the case
 400         where we were already tracking the promise we append the provided dependency list to the existing list.
 401         Since we never bound or rvalue-ref to a non-temporary value we never destructed the Vector, leaking its
 402         contents.
 403
 404         * runtime/PromiseDeferredTimer.cpp:
 405         (JSC::PromiseDeferredTimer::addPendingPromise):
 406
 407 2017-05-30  Oleksandr Skachkov  <gskachkov@gmail.com>
 408
 409         Prevent async methods named 'function' in Object literal
 410         https://bugs.webkit.org/show_bug.cgi?id=172660
 411
 412         Reviewed by Saam Barati.
 413
 414         Prevent async method named 'function' in object.
 415         https://github.com/tc39/ecma262/pull/884
 416
 417         * parser/Parser.cpp:
 418         (JSC::Parser<LexerType>::parsePropertyMethod):
 419
 420 2017-05-30  Oleksandr Skachkov  <gskachkov@gmail.com>
 421
 422         ASSERTION FAILED: generator.isConstructor() || generator.derivedContextType() == DerivedContextType::DerivedConstructorContext
 423         https://bugs.webkit.org/show_bug.cgi?id=171274
 424
 425         Reviewed by Saam Barati.
 426
 427         Current patch allow to use async arrow function within constructor,
 428         and allow to access to `this`. Current patch force load 'this' from
 429         virtual scope each time as we access to `this` in async arrow function
 430         within constructor it is neccessary because async function can be
 431         suspended and `superCall` can be called and async function resumed.
 432
 433         * bytecompiler/BytecodeGenerator.cpp:
 434         (JSC::BytecodeGenerator::emitPutGeneratorFields):
 435         (JSC::BytecodeGenerator::ensureThis):
 436         * bytecompiler/BytecodeGenerator.h:
 437         (JSC::BytecodeGenerator::makeFunction):
 438
 439 2017-05-30  Ali Juma  <ajuma@chromium.org>
 440
 441         [CredentialManagement] Incorporate IDL updates from latest spec
 442         https://bugs.webkit.org/show_bug.cgi?id=172011
 443
 444         Reviewed by Daniel Bates.
 445
 446         * runtime/CommonIdentifiers.h:
 447
 448 2017-05-30  Alex Christensen  <achristensen@webkit.org>
 449
 450         Update libwebrtc configuration
 451         https://bugs.webkit.org/show_bug.cgi?id=172727
 452
 453         Reviewed by Geoffrey Garen.
 454
 455         * Configurations/FeatureDefines.xcconfig:
 456
 457 2017-05-28  Dan Bernstein  <mitz@apple.com>
 458
 459         [Xcode] ALWAYS_SEARCH_USER_PATHS is set to YES
 460         https://bugs.webkit.org/show_bug.cgi?id=172691
 461
 462         Reviewed by Tim Horton.
 463
 464         * Configurations/Base.xcconfig: Set ALWAYS_SEARCH_USER_PATHS to NO.
 465         * JavaScriptCore.xcodeproj/project.pbxproj: Added ParseInt.h to the JavaScriptCore target.
 466
 467 2017-05-28  Yusuke Suzuki  <utatane.tea@gmail.com>
 468
 469         [JSC] Provide better type information of toLength and tighten bytecode
 470         https://bugs.webkit.org/show_bug.cgi?id=172690
 471
 472         Reviewed by Sam Weinig.
 473
 474         In this patch, we carefully leverage operator + in order to
 475
 476         1. tighten bytecode
 477
 478         operator+ emits to_number bytecode. What this bytecode does is the same
 479         to @Number() call. It is more efficient, and it is smaller bytecode
 480         than @Number() call (load global variable @Number, set up arguments, and
 481         call it).
 482
 483         2. offer better type prediction data
 484
 485         Now, we have code like
 486
 487             length > 0 ? (length < @MAX_SAFE_INTEGER ? length : @MAX_SAFE_INTEGER) : 0
 488
 489         This is not good because DFG prediction propagation phase predicts as Double
 490         since @MAX_SAFE_INTEGER is double. But actually it rarely becomes Double.
 491         Usually, the result becomes Int32. This patch leverages to_number in a bit
 492         interesting way: to_number has value profiling to offer better type prediction.
 493         This value profiling can offer a chance to change the prediction to Int32 efficiently.
 494         It is a bit tricky. But it is worth doing to speed up our builtin functions,
 495         which should leverage all the JSC's tricky things to be optimized.
 496
 497         Related microbenchmarks show performance improvement.
 498
 499                                                   baseline                  patched
 500
 501             array-prototype-forEach           50.2348+-2.2331           49.7568+-2.3507
 502             array-prototype-map               51.0574+-1.8166           47.9531+-2.1653          might be 1.0647x faster
 503             array-prototype-some              52.3926+-1.8882     ^     48.3632+-2.0852        ^ definitely 1.0833x faster
 504             array-prototype-every             52.7394+-2.0712           50.2896+-2.1480          might be 1.0487x faster
 505             array-prototype-reduce            54.9994+-2.3638           51.8716+-2.6253          might be 1.0603x faster
 506             array-prototype-reduceRight      209.7594+-9.2594     ^     51.5867+-2.5745        ^ definitely 4.0662x faster
 507
 508
 509         * builtins/GlobalOperations.js:
 510         (globalPrivate.toInteger):
 511         (globalPrivate.toLength):
 512
 513 2017-05-28  Sam Weinig  <sam@webkit.org>
 514
 515         [WebIDL] @@iterator should only be accessed once when disambiguating a union type
 516         https://bugs.webkit.org/show_bug.cgi?id=172684
 517
 518         Reviewed by Yusuke Suzuki.
 519
 520         * runtime/IteratorOperations.cpp:
 521         (JSC::iteratorMethod):
 522         (JSC::iteratorForIterable):
 523         * runtime/IteratorOperations.h:
 524         (JSC::forEachInIterable):
 525         Add additional iterator helpers to allow union + sequence conversion code
 526         to check for iterability by getting the iterator method, and iterate using
 527         that method later on.
 528
 529 2017-05-28  Yusuke Suzuki  <utatane.tea@gmail.com>
 530
 531         Unreviewed, build fix for Windows
 532         https://bugs.webkit.org/show_bug.cgi?id=172413
 533
 534         Optimized jsDynamicCast for JSMap and JSSet will be handled in [1].
 535
 536         [1]: https://bugs.webkit.org/show_bug.cgi?id=172685
 537
 538         * runtime/JSMap.h:
 539         (JSC::isJSMap):
 540         (JSC::jsDynamicCast): Deleted.
 541         (JSC::>): Deleted.
 542         * runtime/JSSet.h:
 543         (JSC::isJSSet):
 544         (JSC::jsDynamicCast): Deleted.
 545         (JSC::>): Deleted.
 546         * runtime/MapConstructor.cpp:
 547         (JSC::constructMap):
 548         * runtime/SetConstructor.cpp:
 549         (JSC::constructSet):
 550
 551 2017-05-28  Mark Lam  <mark.lam@apple.com>
 552
 553         Implement a faster Interpreter::getOpcodeID().
 554         https://bugs.webkit.org/show_bug.cgi?id=172669
 555
 556         Reviewed by Saam Barati.
 557
 558         We can implement Interpreter::getOpcodeID() without a hash table lookup by always
 559         embedding the OpcodeID in the 32-bit word just before the start of the LLInt
 560         handler code that executes each opcode.  getOpcodeID() can therefore just read
 561         the 32-bits before the opcode address to get its OpcodeID.
 562
 563         This is currently only enabled for CPU(X86), CPU(X86_64), CPU(ARM64),
 564         CPU(ARM_THUMB2), and only for OS(DARWIN).  It'll probably just work for linux as
 565         well, but I'll let the Linux folks turn that on after they have verified that it
 566         works on linux too.
 567
 568         I'll also take this opportunity to clean up how we initialize the opcodeIDTable:
 569         1. we only need to initialize it once per process, not once per VM / interpreter
 570            instance.
 571         2. we can initialize it in the Interpreter constructor instead of requiring a
 572            separate call to an initialize() function.
 573
 574         On debug builds, the Interpreter constructor will also verify that getOpcodeID()
 575         is working correctly for each opcode when USE(LLINT_EMBEDDED_OPCODE_ID).
 576
 577         * bytecode/BytecodeList.json:
 578         * generate-bytecode-files:
 579         * interpreter/Interpreter.cpp:
 580         (JSC::Interpreter::Interpreter):
 581         (JSC::Interpreter::opcodeIDTable):
 582         (JSC::Interpreter::initialize): Deleted.
 583         * interpreter/Interpreter.h:
 584         (JSC::Interpreter::getOpcode):
 585         (JSC::Interpreter::getOpcodeID):
 586         * llint/LowLevelInterpreter.cpp:
 587         * runtime/VM.cpp:
 588         (JSC::VM::VM):
 589
 590 2017-05-27  Yusuke Suzuki  <utatane.tea@gmail.com>
 591
 592         [JSC] Map and Set constructors should have fast path for cloning
 593         https://bugs.webkit.org/show_bug.cgi?id=172413
 594
 595         Reviewed by Saam Barati.
 596
 597         In this patch, we add a fast path for cloning in Set and Map constructors.
 598
 599         In ARES-6 Air, we have code like `new Set(set)` to clone the given set.
 600         At that time, our generic path just iterates the given set object and add
 601         it to the newly created one. It is quite slow because we need to follow
 602         the iterator protocol inside C++ and we need to call set.add() repeatedly
 603         while the given set guarantees the elements are unique.
 604
 605         This patch implements clone() function to JSMap and JSSet. Cloning JSMap
 606         and JSSet are done really fast without invoking any observable JS functions.
 607         To check whether we can use this clone() function in Set and Map constructors,
 608         we set several watchpoints.
 609
 610         In the case of Set,
 611
 612         1. Set.prototype[Symbol.iterator] is not changed.
 613         2. SetIterator.prototype.next is not changed.
 614         3. Set.prototype.add is not changed.
 615         4. The given Set does not have [Symbol.iterator] function in its instance.
 616         5. The given Set's [[Prototype]] is Set.prototype.
 617         6. Newly created set's [[Prototype]] is Set.prototype.
 618
 619         If the above requirements are met, cloning the given Set is not observable to users.
 620         Thus we can take a fast path.
 621
 622         Currently, we do not integrate this optimization into DFG and FTL.
 623         And we do not optimize other iterables. For example, we can optimize Set
 624         constructor taking Int32 Array. And we should optimize generic iterator cases too.
 625         They are planned as part of a separate bug[1].
 626
 627         This change improves ARES-6 Air by 5.3% in steady state.
 628
 629         Baseline:
 630             Running... Air ( 1  to go)
 631             firstIteration:     76.41 +- 15.60 ms
 632             averageWorstCase:   40.63 +- 7.54 ms
 633             steadyState:        9.13 +- 0.51 ms
 634
 635
 636         Patched:
 637             Running... Air ( 1  to go)
 638             firstIteration:     75.00 +- 22.54 ms
 639             averageWorstCase:   39.18 +- 8.45 ms
 640             steadyState:        8.67 +- 0.28 ms
 641
 642         [1]: https://bugs.webkit.org/show_bug.cgi?id=172419
 643
 644         * CMakeLists.txt:
 645         * JavaScriptCore.xcodeproj/project.pbxproj:
 646         * runtime/ArrayIteratorAdaptiveWatchpoint.cpp: Removed.
 647         * runtime/HashMapImpl.h:
 648         (JSC::HashMapBucket::extractValue):
 649         (JSC::HashMapImpl::finishCreation):
 650         (JSC::HashMapImpl::add):
 651         (JSC::HashMapImpl::setUpHeadAndTail):
 652         (JSC::HashMapImpl::addNormalizedNonExistingForCloning):
 653         (JSC::HashMapImpl::addNormalizedInternal):
 654         * runtime/InternalFunction.cpp:
 655         (JSC::InternalFunction::createSubclassStructureSlow):
 656         (JSC::InternalFunction::createSubclassStructure): Deleted.
 657         * runtime/InternalFunction.h:
 658         (JSC::InternalFunction::createSubclassStructure):
 659         * runtime/JSGlobalObject.cpp:
 660         (JSC::JSGlobalObject::JSGlobalObject):
 661         (JSC::JSGlobalObject::init):
 662         (JSC::JSGlobalObject::visitChildren):
 663         * runtime/JSGlobalObject.h:
 664         (JSC::JSGlobalObject::mapIteratorProtocolWatchpoint):
 665         (JSC::JSGlobalObject::setIteratorProtocolWatchpoint):
 666         (JSC::JSGlobalObject::mapSetWatchpoint):
 667         (JSC::JSGlobalObject::setAddWatchpoint):
 668         (JSC::JSGlobalObject::mapPrototype):
 669         (JSC::JSGlobalObject::jsSetPrototype):
 670         (JSC::JSGlobalObject::setStructure):
 671         * runtime/JSGlobalObjectInlines.h:
 672         (JSC::JSGlobalObject::isMapPrototypeIteratorProtocolFastAndNonObservable):
 673         (JSC::JSGlobalObject::isSetPrototypeIteratorProtocolFastAndNonObservable):
 674         (JSC::JSGlobalObject::isMapPrototypeSetFastAndNonObservable):
 675         (JSC::JSGlobalObject::isSetPrototypeAddFastAndNonObservable):
 676         * runtime/JSMap.cpp:
 677         (JSC::JSMap::clone):
 678         (JSC::JSMap::canCloneFastAndNonObservable):
 679         * runtime/JSMap.h:
 680         (JSC::jsDynamicCast):
 681         (JSC::>):
 682         (JSC::JSMap::createStructure): Deleted.
 683         (JSC::JSMap::create): Deleted.
 684         (JSC::JSMap::set): Deleted.
 685         (JSC::JSMap::JSMap): Deleted.
 686         * runtime/JSSet.cpp:
 687         (JSC::JSSet::clone):
 688         (JSC::JSSet::canCloneFastAndNonObservable):
 689         * runtime/JSSet.h:
 690         (JSC::jsDynamicCast):
 691         (JSC::>):
 692         (JSC::JSSet::createStructure): Deleted.
 693         (JSC::JSSet::create): Deleted.
 694         (JSC::JSSet::JSSet): Deleted.
 695         * runtime/MapConstructor.cpp:
 696         (JSC::constructMap):
 697         * runtime/ObjectPropertyChangeAdaptiveWatchpoint.h: Renamed from Source/JavaScriptCore/runtime/ArrayIteratorAdaptiveWatchpoint.h.
 698         (JSC::ObjectPropertyChangeAdaptiveWatchpoint::ObjectPropertyChangeAdaptiveWatchpoint):
 699         * runtime/SetConstructor.cpp:
 700         (JSC::constructSet):
 701
 702 2017-05-27  Yusuke Suzuki  <utatane.tea@gmail.com>
 703
 704         [DOMJIT] Move DOMJIT patchpoint infrastructure out of domjit
 705         https://bugs.webkit.org/show_bug.cgi?id=172260
 706
 707         Reviewed by Filip Pizlo.
 708
 709         DOMJIT::Patchpoint is now used for generalized CheckSubClass. And it becomes mature enough
 710         to be used as a general-purpose injectable compiler over all the JIT tiers.
 711
 712         We extract DOMJIT::Patchpoint to jit/ and rename it JSC::Snippet.
 713
 714         * CMakeLists.txt:
 715         * JavaScriptCore.xcodeproj/project.pbxproj:
 716         * bytecode/AccessCaseSnippetParams.cpp: Renamed from Source/JavaScriptCore/bytecode/DOMJITAccessCasePatchpointParams.cpp.
 717         (JSC::SlowPathCallGeneratorWithArguments::generateImpl):
 718         (JSC::AccessCaseSnippetParams::emitSlowPathCalls):
 719         * bytecode/AccessCaseSnippetParams.h: Renamed from Source/JavaScriptCore/bytecode/DOMJITAccessCasePatchpointParams.h.
 720         (JSC::AccessCaseSnippetParams::AccessCaseSnippetParams):
 721         * bytecode/GetterSetterAccessCase.cpp:
 722         (JSC::GetterSetterAccessCase::emitDOMJITGetter):
 723         * dfg/DFGAbstractInterpreterInlines.h:
 724         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
 725         * dfg/DFGByteCodeParser.cpp:
 726         (JSC::DFG::blessCallDOMGetter):
 727         (JSC::DFG::ByteCodeParser::handleDOMJITGetter):
 728         * dfg/DFGClobberize.h:
 729         (JSC::DFG::clobberize):
 730         * dfg/DFGFixupPhase.cpp:
 731         (JSC::DFG::FixupPhase::fixupNode):
 732         * dfg/DFGGraph.h:
 733         * dfg/DFGNode.h:
 734         * dfg/DFGSnippetParams.cpp: Renamed from Source/JavaScriptCore/dfg/DFGDOMJITPatchpointParams.cpp.
 735         * dfg/DFGSnippetParams.h: Renamed from Source/JavaScriptCore/dfg/DFGDOMJITPatchpointParams.h.
 736         (JSC::DFG::SnippetParams::SnippetParams):
 737         * dfg/DFGSpeculativeJIT.cpp:
 738         (JSC::DFG::allocateTemporaryRegistersForSnippet):
 739         (JSC::DFG::SpeculativeJIT::compileCallDOMGetter):
 740         (JSC::DFG::SpeculativeJIT::compileCheckSubClass):
 741         (JSC::DFG::allocateTemporaryRegistersForPatchpoint): Deleted.
 742         * domjit/DOMJITCallDOMGetterSnippet.h: Renamed from Source/JavaScriptCore/domjit/DOMJITCallDOMGetterPatchpoint.h.
 743         (JSC::DOMJIT::CallDOMGetterSnippet::create):
 744         * domjit/DOMJITGetterSetter.h:
 745         * domjit/DOMJITSignature.h:
 746         * domjit/DOMJITValue.h: Removed.
 747         * ftl/FTLLowerDFGToB3.cpp:
 748         (JSC::FTL::DFG::LowerDFGToB3::compileCheckSubClass):
 749         (JSC::FTL::DFG::LowerDFGToB3::compileCallDOMGetter):
 750         * ftl/FTLSnippetParams.cpp: Renamed from Source/JavaScriptCore/ftl/FTLDOMJITPatchpointParams.cpp.
 751         * ftl/FTLSnippetParams.h: Renamed from Source/JavaScriptCore/ftl/FTLDOMJITPatchpointParams.h.
 752         (JSC::FTL::SnippetParams::SnippetParams):
 753         * jit/Snippet.h: Renamed from Source/JavaScriptCore/domjit/DOMJITPatchpoint.h.
 754         (JSC::Snippet::create):
 755         (JSC::Snippet::setGenerator):
 756         (JSC::Snippet::generator):
 757         * jit/SnippetParams.h: Renamed from Source/JavaScriptCore/domjit/DOMJITPatchpointParams.h.
 758         (JSC::SnippetParams::~SnippetParams):
 759         (JSC::SnippetParams::Value::Value):
 760         (JSC::SnippetParams::Value::isGPR):
 761         (JSC::SnippetParams::Value::isFPR):
 762         (JSC::SnippetParams::Value::isJSValueRegs):
 763         (JSC::SnippetParams::Value::gpr):
 764         (JSC::SnippetParams::Value::fpr):
 765         (JSC::SnippetParams::Value::jsValueRegs):
 766         (JSC::SnippetParams::Value::reg):
 767         (JSC::SnippetParams::Value::value):
 768         (JSC::SnippetParams::SnippetParams):
 769         * jit/SnippetReg.h: Renamed from Source/JavaScriptCore/domjit/DOMJITReg.h.
 770         (JSC::SnippetReg::SnippetReg):
 771         * jit/SnippetSlowPathCalls.h: Renamed from Source/JavaScriptCore/domjit/DOMJITSlowPathCalls.h.
 772         * jsc.cpp:
 773         (WTF::DOMJITNode::checkSubClassSnippet):
 774         (WTF::DOMJITFunctionObject::checkSubClassSnippet):
 775         (WTF::DOMJITNode::checkSubClassPatchpoint): Deleted.
 776         (WTF::DOMJITFunctionObject::checkSubClassPatchpoint): Deleted.
 777         * runtime/ClassInfo.h:
 778
 779 2017-05-26  Keith Miller  <keith_miller@apple.com>
 780
 781         REEGRESSION(r217459): testapi fails in JSExportTest's wrapperForNSObjectisObject().
 782         https://bugs.webkit.org/show_bug.cgi?id=172654
 783
 784         Reviewed by Mark Lam.
 785
 786         The test's intent is to assert that an exception has not been
 787         thrown (as indicated by the message string), but the test was
 788         erroneously checking for ! the right condition. This is now fixed.
 789
 790         * API/tests/JSExportTests.mm:
 791         (wrapperForNSObjectisObject):
 792
 793 2017-05-26  Joseph Pecoraro  <pecoraro@apple.com>
 794
 795         JSContext Inspector: Improve the reliability of automatically pausing in auto-attach
 796         https://bugs.webkit.org/show_bug.cgi?id=172664
 797         <rdar://problem/32362933>
 798
 799         Reviewed by Matt Baker.
 800
 801         Automatically pause on connection was triggering a pause before the
 802         frontend may have initialized. Often during frontend initialization
 803         the frontend may perform an action that clears the pause state requested
 804         by the developer. This change defers the pause until after the frontend
 805         has initialized, right before returning to the application's code.
 806
 807         * inspector/remote/RemoteControllableTarget.h:
 808         * inspector/remote/RemoteInspectionTarget.h:
 809         * inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm:
 810         (Inspector::RemoteConnectionToTarget::setup):
 811         * inspector/remote/glib/RemoteConnectionToTargetGlib.cpp:
 812         (Inspector::RemoteConnectionToTarget::setup):
 813         * runtime/JSGlobalObjectDebuggable.cpp:
 814         (JSC::JSGlobalObjectDebuggable::connect):
 815         (JSC::JSGlobalObjectDebuggable::pause): Deleted.
 816         * runtime/JSGlobalObjectDebuggable.h:
 817         Pass an immediatelyPause boolean on to the controller. Remove
 818         the current path that invokes a pause before initialization.
 819
 820         * inspector/JSGlobalObjectInspectorController.h:
 821         * inspector/JSGlobalObjectInspectorController.cpp:
 822         (Inspector::JSGlobalObjectInspectorController::connectFrontend):
 823         (Inspector::JSGlobalObjectInspectorController::disconnectFrontend):
 824         Manage should immediately pause state.
 825
 826         (Inspector::JSGlobalObjectInspectorController::frontendInitialized):
 827         (Inspector::JSGlobalObjectInspectorController::pause): Deleted.
 828         When initialized, trigger a pause if requested.
 829
 830 2017-05-26  Mark Lam  <mark.lam@apple.com>
 831
 832         Temporarily commenting out a JSExportTest test until webkit.org/b/172654 is fixed.
 833         https://bugs.webkit.org/show_bug.cgi?id=172655
 834
 835         Reviewed by Saam Barati.
 836
 837         * API/tests/JSExportTests.mm:
 838         (wrapperForNSObjectisObject):
 839
 840 2017-05-26  Mark Lam  <mark.lam@apple.com>
 841
 842         REGRESSION(216914): testCFStrings encounters an invalid ExecState callee pointer.
 843         https://bugs.webkit.org/show_bug.cgi?id=172651
 844
 845         Reviewed by Saam Barati.
 846
 847         This is because the assertion utility functions used in testCFStrings() expects
 848         to get the JSGlobalContextRef from the global context variable.  However,
 849         testCFStrings() creates its own JSGlobalContextRef but does not set the global
 850         context variable to it.
 851
 852         The fix is to make testCFStrings() initialize the global context variable properly.
 853
 854         * API/tests/testapi.c:
 855         (testCFStrings):
 856
 857 2017-05-26  Yusuke Suzuki  <utatane.tea@gmail.com>
 858
 859         Give ModuleProgram the same treatment that we did for ProgramCode in bug#167725
 860         https://bugs.webkit.org/show_bug.cgi?id=167805
 861
 862         Reviewed by Saam Barati.
 863
 864         Since ModuleProgramExecutable is executed only once, we can skip compiling
 865         code unreachable from the current program count. This can skip massive
 866         initialization code.
 867
 868         We already do this for global code in bug#167725. This patch extends it to
 869         module code.
 870
 871         * interpreter/Interpreter.cpp:
 872         (JSC::Interpreter::executeModuleProgram):
 873         * interpreter/Interpreter.h:
 874         * jit/JIT.cpp:
 875         (JSC::JIT::privateCompileMainPass):
 876         * runtime/JSModuleRecord.cpp:
 877         (JSC::JSModuleRecord::evaluate):
 878         * runtime/JSModuleRecord.h:
 879         (JSC::JSModuleRecord::moduleProgramExecutable): Deleted.
 880
 881 2017-05-26  Oleksandr Skachkov  <gskachkov@gmail.com>
 882
 883         Prevent async methods named 'function'
 884         https://bugs.webkit.org/show_bug.cgi?id=172598
 885
 886         Reviewed by Mark Lam.
 887
 888         Prevent async method named 'function' in class.
 889         Link to change in ecma262 specification
 890         https://github.com/tc39/ecma262/pull/884
 891
 892         * parser/Parser.cpp:
 893         (JSC::Parser<LexerType>::parseClass):
 894
 895 2017-05-25  Yusuke Suzuki  <utatane.tea@gmail.com>
 896
 897         Unreviewed, build fix for GCC
 898
 899         std::tuple does not have implicit constructor.
 900         Thus, we cannot use implicit construction with initializer brace.
 901         We should specify the name like `GetInst { }`.
 902
 903         * bytecompiler/BytecodeGenerator.h:
 904         (JSC::StructureForInContext::addGetInst):
 905
 906 2017-05-25  Keith Miller  <keith_miller@apple.com>
 907
 908         Cleanup tests after r217240
 909         https://bugs.webkit.org/show_bug.cgi?id=172466
 910
 911         Reviewed by Mark Lam.
 912
 913         I forgot to make my test an actual test. Also, remove second call runJSExportTests()
 914
 915         * API/tests/JSExportTests.mm:
 916         (wrapperForNSObjectisObject):
 917         * API/tests/testapi.mm:
 918         (testObjectiveCAPIMain):
 919
 920 2017-05-25  Michael Saboff  <msaboff@apple.com>
 921
 922         The default setting of Option::criticalGCMemoryThreshold is too high for iOS
 923         https://bugs.webkit.org/show_bug.cgi?id=172617
 924
 925         Reviewed by Mark Lam.
 926
 927         Reducing criticalGCMemoryThreshold to 0.80 eliminated jetsam on iOS devices
 928         when tested running JetStream.
 929
 930         * runtime/Options.h:
 931
 932 2017-05-25  Saam Barati  <sbarati@apple.com>
 933
 934         Our for-in optimization in the bytecode generator does its static analysis incorrectly
 935         https://bugs.webkit.org/show_bug.cgi?id=172532
 936         <rdar://problem/32369452>
 937
 938         Reviewed by Mark Lam.
 939
 940         Our static analysis for when a for-in induction variable
 941         is written to tried to its analysis as we generate
 942         bytecode. This has issues, since it does not account for
 943         the dynamic execution path of the program. Let's consider
 944         a program where our old analysis worked:
 945
 946         ```
 947         for (let p in o) {
 948             o[p]; // We can transform this into a fast get_direct_pname
 949             p = 20;
 950             o[p]; // We cannot transform this since p has been changed.
 951         }
 952         ```
 953
 954         However, our static analysis did not account for loops, which exist
 955         in JavaScript. e.g, it would incorrectly compile this program as:
 956         ```
 957         for (let p in o) {
 958             for (let i = 0; i < 20; ++i) {
 959                 o[p]; // It transforms this to use get_direct_pname even though p will be over-written if we get here from the inner loop back edge!
 960                 p = 20;
 961                 o[p]; // We correctly do not transform this.
 962             }
 963         }
 964         ```
 965
 966         Because of this flaw, I've made the optimization more conservative.
 967         We now optimistically emit code for the optimized access. However,
 968         if a for-in context is *ever* invalidated, before we pop it off
 969         the stack, we rewrite the program's optimized accesses to no longer
 970         be optimized. To do this, each context keeps track of its optimized
 971         accesses.
 972
 973         This patch also adds a new bytecode, op_nop, which is just a no-op.
 974         It was helpful to add this because reverting get_direct_pname to get_by_val
 975         will leave us with an extra instruction word because get_direct_pname is
 976         has a length of 7 where get_by_val has a length of 6. This leaves us with
 977         an extra slot that we fill with an op_nop.
 978
 979         * bytecode/BytecodeDumper.cpp:
 980         (JSC::BytecodeDumper<Block>::dumpBytecode):
 981         * bytecode/BytecodeList.json:
 982         * bytecode/BytecodeUseDef.h:
 983         (JSC::computeUsesForBytecodeOffset):
 984         (JSC::computeDefsForBytecodeOffset):
 985         * bytecompiler/BytecodeGenerator.cpp:
 986         (JSC::BytecodeGenerator::emitGetByVal):
 987         (JSC::BytecodeGenerator::popIndexedForInScope):
 988         (JSC::BytecodeGenerator::popStructureForInScope):
 989         (JSC::BytecodeGenerator::invalidateForInContextForLocal):
 990         (JSC::StructureForInContext::pop):
 991         (JSC::IndexedForInContext::pop):
 992         * bytecompiler/BytecodeGenerator.h:
 993         (JSC::StructureForInContext::addGetInst):
 994         (JSC::IndexedForInContext::addGetInst):
 995         * dfg/DFGByteCodeParser.cpp:
 996         (JSC::DFG::ByteCodeParser::parseBlock):
 997         * dfg/DFGCapabilities.cpp:
 998         (JSC::DFG::capabilityLevel):
 999         * jit/JIT.cpp:
1000         (JSC::JIT::privateCompileMainPass):
1001         * jit/JIT.h:
1002         * jit/JITOpcodes.cpp:
1003         (JSC::JIT::emit_op_nop):
1004         * llint/LowLevelInterpreter.asm:
1005
1006 2017-05-25  Mark Lam  <mark.lam@apple.com>
1007
1008         ObjectToStringAdaptiveInferredPropertyValueWatchpoint should not reinstall itself nor handleFire if it's dying shortly.
1009         https://bugs.webkit.org/show_bug.cgi?id=172548
1010         <rdar://problem/31458393>
1011
1012         Reviewed by Filip Pizlo.
1013
1014         Consider the following scenario:
1015
1016         1. A ObjectToStringAdaptiveInferredPropertyValueWatchpoint O1, watches for
1017            structure transitions, e.g. structure S2 transitioning to structure S3.
1018            In this case, O1 would be installed in S2's watchpoint set.
1019         2. When the structure transition happens, structure S2 will fire watchpoint O1.
1020         3. O1's handler will normally re-install itself in the watchpoint set of the new
1021            "transitioned to" structure S3.
1022         4. "Installation" here requires writing into the StructureRareData SD3 of the new
1023            structure S3.  If SD3 does not exist yet, the installation process will trigger
1024            the allocation of StructureRareData SD3.
1025         5. It is possible that the Structure S1, and StructureRareData SD1 that owns the
1026            ObjectToStringAdaptiveInferredPropertyValueWatchpoint O1 is no longer reachable
1027            by the GC, and therefore will be collected soon.
1028         6. The allocation of SD3 in (4) may trigger the sweeping of the StructureRareData
1029            SD1.  This, in turn, triggers the deletion of the
1030            ObjectToStringAdaptiveInferredPropertyValueWatchpoint O1.
1031
1032         After O1 is deleted in (6) and SD3 is allocated in (4), execution continues in
1033         AdaptiveInferredPropertyValueWatchpointBase::fire() where O1 gets installed in
1034         structure S3's watchpoint set.  This is obviously incorrect because O1 is already
1035         deleted.  The result is that badness happens later when S3's watchpoint set fires
1036         its watchpoints and accesses the deleted O1.
1037
1038         The fix is to enhance AdaptiveInferredPropertyValueWatchpointBase::fire() to
1039         check if "this" is still valid before proceeding to re-install itself or to
1040         invoke its handleFire() method.
1041
1042         ObjectToStringAdaptiveInferredPropertyValueWatchpoint (which extends
1043         AdaptiveInferredPropertyValueWatchpointBase) will override its isValid() method,
1044         and return false its owner StructureRareData is no longer reachable by the GC.
1045         This ensures that it won't be deleted while it's installed to any watchpoint set.
1046
1047         Additional considerations and notes:
1048         1. In the above, I talked about the ObjectToStringAdaptiveInferredPropertyValueWatchpoint
1049            being installed in watchpoint sets.  What actually happens is that
1050            ObjectToStringAdaptiveInferredPropertyValueWatchpoint has 2 members
1051            (m_structureWatchpoint and m_propertyWatchpoint) which may be installed in
1052            watchpoint sets.  The ObjectToStringAdaptiveInferredPropertyValueWatchpoint is
1053            not itself a Watchpoint object.
1054
1055            But for brevity, in the above, I refer to the ObjectToStringAdaptiveInferredPropertyValueWatchpoint
1056            instead of its Watchpoint members.  The description of the issue is still
1057            accurate given the life-cycle of the Watchpoint members are embedded in the
1058            enclosing ObjectToStringAdaptiveInferredPropertyValueWatchpoint object, and
1059            hence, they share the same life-cycle.
1060
1061         2. The top of AdaptiveInferredPropertyValueWatchpointBase::fire() removes its
1062            m_structureWatchpoint and m_propertyWatchpoint if they have been added to any
1063            watchpoint sets.  This is safe to do even if the owner StructureRareData is no
1064            longer reachable by the GC.
1065
1066            This is because the only way we can get to AdaptiveInferredPropertyValueWatchpointBase::fire()
1067            is if its Watchpoint members are still installed in some watchpoint set that
1068            fired.  This means that the AdaptiveInferredPropertyValueWatchpointBase
1069            instance has not been deleted yet, because its destructor will automatically
1070            remove the Watchpoint members from any watchpoint sets.
1071
1072         * bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp:
1073         (JSC::AdaptiveInferredPropertyValueWatchpointBase::fire):
1074         (JSC::AdaptiveInferredPropertyValueWatchpointBase::isValid):
1075         * bytecode/AdaptiveInferredPropertyValueWatchpointBase.h:
1076         * heap/FreeList.cpp:
1077         (JSC::FreeList::contains):
1078         * heap/FreeList.h:
1079         * heap/HeapCell.h:
1080         * heap/HeapCellInlines.h:
1081         (JSC::HeapCell::isLive):
1082         * heap/MarkedAllocator.h:
1083         (JSC::MarkedAllocator::isFreeListedCell):
1084         * heap/MarkedBlock.h:
1085         * heap/MarkedBlockInlines.h:
1086         (JSC::MarkedBlock::Handle::isFreeListedCell):
1087         * runtime/StructureRareData.cpp:
1088         (JSC::ObjectToStringAdaptiveInferredPropertyValueWatchpoint::isValid):
1089
1090 2017-05-23  Saam Barati  <sbarati@apple.com>
1091
1092         We should not mmap zero bytes for a memory in Wasm
1093         https://bugs.webkit.org/show_bug.cgi?id=172528
1094         <rdar://problem/32257076>
1095
1096         Reviewed by Mark Lam.
1097
1098         This patch fixes a bug where we would call into mmap with zero bytes
1099         when creating a slow WasmMemory with zero initial page size. This fix
1100         is simple: if we don't have any initial bytes, we just call the constructor
1101         in WasmMemory that's meant to handle this case.
1102
1103         * wasm/WasmMemory.cpp:
1104         (JSC::Wasm::Memory::create):
1105
1106 2017-05-23  Brian Burg  <bburg@apple.com>
1107
1108         REGRESSION(r217051): Automation sessions fail to complete bootstrap
1109         https://bugs.webkit.org/show_bug.cgi?id=172513
1110         <rdar://problem/32338354>
1111
1112         Reviewed by Joseph Pecoraro.
1113
1114         The changes to be more strict about typechecking messages were too strict.
1115
1116         * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
1117         (Inspector::RemoteInspector::receivedSetupMessage):
1118         WIRAutomatically is an optional key in the setup message. In the relay, this key gets copied
1119         into an NSDictionary as NSNull if the key isn't present in a forwarded command.
1120         We need to revert NSNull values to nil, since it's valid to call [nil boolValue] but not
1121         [[NSNull null] boolValue]. We also need to allow for nil in the typecheck for this key.
1122
1123 2017-05-23  Myles C. Maxfield  <mmaxfield@apple.com>
1124
1125         Remove dead ENABLE(FONT_LOAD_EVENTS) code
1126         https://bugs.webkit.org/show_bug.cgi?id=172517
1127
1128         Rubber-stamped by Simon Fraser.
1129
1130         * Configurations/FeatureDefines.xcconfig:
1131
1132 2017-05-23  Saam Barati  <sbarati@apple.com>
1133
1134         CFGSimplificationPhase should not merge a block with itself
1135         https://bugs.webkit.org/show_bug.cgi?id=172508
1136         <rdar://problem/28424006>
1137
1138         Reviewed by Keith Miller.
1139
1140         CFGSimplificationPhase can run into or create IR that ends up with a
1141         block that has a Jump to itself, and no other predecessors. It should
1142         gracefully handle such IR. Before this patch, it would not. The only criteria
1143         for merging 'block' with 'targetBlock' used to be that 'targetBlock.predecessors.size() == 1'.
1144         The code is written in such a way that if we merge a block with itself, we
1145         will infinite loop until we run out of memory.
1146
1147         Merging a block with itself does not make sense for a few reasons. First,
1148         we're joining the contents of two blocks. What is the definition of joining
1149         a block with itself? I suppose we could simply unroll this self loop
1150         one level, but that would not be wise because this self loop is by definition
1151         unreachable unless it's the root block in the graph (which I think is
1152         invalid IR since we'd never generate bytecode that would do this).
1153
1154         This patch employs an easy fix: we can't merge a block with itself.
1155
1156         * dfg/DFGCFGSimplificationPhase.cpp:
1157         (JSC::DFG::CFGSimplificationPhase::canMergeBlocks):
1158         (JSC::DFG::CFGSimplificationPhase::run):
1159         (JSC::DFG::CFGSimplificationPhase::convertToJump):
1160         (JSC::DFG::CFGSimplificationPhase::mergeBlocks):
1161
1162 2017-05-22  Brian Burg  <bburg@apple.com>
1163
1164         Web Inspector: webkit reload policy should match default behavior
1165         https://bugs.webkit.org/show_bug.cgi?id=171385
1166         <rdar://problem/31871515>
1167
1168         Reviewed by Joseph Pecoraro.
1169
1170         Add a new option to Page.reload that allows the test harness
1171         to reload its test page using the old reload behavior.
1172
1173         The new behavior of revalidating expired cached subresources only
1174         is the current default, since only the test harness needs the old behavior.
1175
1176         * inspector/protocol/Page.json:
1177
1178 2017-05-22  Keith Miller  <keith_miller@apple.com>
1179
1180         [Cocoa] An exported Objective C class’s prototype and constructor don't persist across JSContext deallocation
1181         https://bugs.webkit.org/show_bug.cgi?id=167708
1182
1183         Reviewed by Geoffrey Garen.
1184
1185         This patch moves the Objective C wrapper map to the global object. In order to make this work the JSWrapperMap
1186         class no longer holds a reference to the JSContext. Instead, the context must be provided when getting a wrapper.
1187
1188         Also, this patch fixes a "bug" where we would observe changes to the Object property on the global object when
1189         creating a wrapper for NSObject.
1190
1191         * API/APICast.h:
1192         (toJSGlobalObject):
1193         * API/JSContext.mm:
1194         (-[JSContext ensureWrapperMap]):
1195         (-[JSContext initWithVirtualMachine:]):
1196         (-[JSContext dealloc]):
1197         (-[JSContext wrapperMap]):
1198         (-[JSContext initWithGlobalContextRef:]):
1199         (-[JSContext wrapperForObjCObject:]):
1200         (-[JSContext wrapperForJSObject:]):
1201         * API/JSWrapperMap.h:
1202         * API/JSWrapperMap.mm:
1203         (-[JSObjCClassInfo initForClass:]):
1204         (-[JSObjCClassInfo allocateConstructorAndPrototypeInContext:]):
1205         (-[JSObjCClassInfo wrapperForObject:inContext:]):
1206         (-[JSObjCClassInfo constructorInContext:]):
1207         (-[JSObjCClassInfo prototypeInContext:]):
1208         (-[JSWrapperMap initWithGlobalContextRef:]):
1209         (-[JSWrapperMap classInfoForClass:]):
1210         (-[JSWrapperMap jsWrapperForObject:inContext:]):
1211         (-[JSWrapperMap objcWrapperForJSValueRef:inContext:]):
1212         (-[JSObjCClassInfo initWithContext:forClass:]): Deleted.
1213         (-[JSObjCClassInfo allocateConstructorAndPrototype]): Deleted.
1214         (-[JSObjCClassInfo wrapperForObject:]): Deleted.
1215         (-[JSObjCClassInfo constructor]): Deleted.
1216         (-[JSObjCClassInfo prototype]): Deleted.
1217         (-[JSWrapperMap initWithContext:]): Deleted.
1218         (-[JSWrapperMap jsWrapperForObject:]): Deleted.
1219         (-[JSWrapperMap objcWrapperForJSValueRef:]): Deleted.
1220         * API/tests/JSExportTests.mm:
1221         (wrapperLifetimeIsTiedToGlobalObject):
1222         (runJSExportTests):
1223         * API/tests/testapi.mm:
1224         * runtime/JSGlobalObject.h:
1225         (JSC::JSGlobalObject::wrapperMap):
1226         (JSC::JSGlobalObject::setWrapperMap):
1227
1228 2017-05-22  Filip Pizlo  <fpizlo@apple.com>
1229
1230         FTL stack overflow handling should not assume that B3 never selects callee-saves in the prologue
1231         https://bugs.webkit.org/show_bug.cgi?id=172455
1232
1233         Reviewed by Mark Lam.
1234
1235         The FTL needs to run B3's callee-save register restoration before it runs the exception
1236         handler's callee-save register restoration.  This exposes B3's callee-save register
1237         algorithm in AssemblyHelpers so that the FTL can call it.
1238
1239         * b3/air/AirGenerate.cpp:
1240         (JSC::B3::Air::generate):
1241         * ftl/FTLLowerDFGToB3.cpp:
1242         (JSC::FTL::DFG::LowerDFGToB3::lower): Fix the bug.
1243         * heap/Subspace.cpp: Added some debugging support.
1244         (JSC::Subspace::allocate):
1245         (JSC::Subspace::tryAllocate):
1246         (JSC::Subspace::didAllocate):
1247         * heap/Subspace.h:
1248         * jit/AssemblyHelpers.h:
1249         (JSC::AssemblyHelpers::addressFor):
1250         (JSC::AssemblyHelpers::emitSave):
1251         (JSC::AssemblyHelpers::emitRestore):
1252
1253 2017-05-20  Yusuke Suzuki  <utatane.tea@gmail.com>
1254
1255         [FTL] Support GetByVal with ArrayStorage and SlowPutArrayStorage
1256         https://bugs.webkit.org/show_bug.cgi?id=172216
1257
1258         Reviewed by Saam Barati.
1259
1260         This patch adds GetByVal support for ArrayStorage and SlowPutArrayStorage.
1261         To lower CheckInBounds in FTL, we add a new GetVectorLength op. It only accepts
1262         ArrayStorage and SlowPutArrayStorage, then it produces vector length.
1263         CheckInBounds uses this vector length to perform bound checking for ArrayStorage
1264         and SlowPutArrayStorage.
1265
1266         * dfg/DFGAbstractInterpreterInlines.h:
1267         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1268         * dfg/DFGArrayMode.cpp:
1269         (JSC::DFG::permitsBoundsCheckLowering):
1270         * dfg/DFGClobberize.h:
1271         (JSC::DFG::clobberize):
1272         * dfg/DFGDoesGC.cpp:
1273         (JSC::DFG::doesGC):
1274         * dfg/DFGFixupPhase.cpp:
1275         (JSC::DFG::FixupPhase::fixupNode):
1276         * dfg/DFGHeapLocation.cpp:
1277         (WTF::printInternal):
1278         * dfg/DFGHeapLocation.h:
1279         * dfg/DFGIntegerRangeOptimizationPhase.cpp:
1280         * dfg/DFGNode.h:
1281         (JSC::DFG::Node::hasArrayMode):
1282         * dfg/DFGNodeType.h:
1283         * dfg/DFGPredictionPropagationPhase.cpp:
1284         * dfg/DFGSSALoweringPhase.cpp:
1285         (JSC::DFG::SSALoweringPhase::lowerBoundsCheck):
1286         * dfg/DFGSafeToExecute.h:
1287         (JSC::DFG::safeToExecute):
1288         * dfg/DFGSpeculativeJIT32_64.cpp:
1289         (JSC::DFG::SpeculativeJIT::compile):
1290         * dfg/DFGSpeculativeJIT64.cpp:
1291         (JSC::DFG::SpeculativeJIT::compile):
1292         * ftl/FTLAbstractHeapRepository.h:
1293         (JSC::FTL::AbstractHeapRepository::forIndexingType):
1294         (JSC::FTL::AbstractHeapRepository::forArrayType):
1295         * ftl/FTLCapabilities.cpp:
1296         (JSC::FTL::canCompile):
1297         * ftl/FTLLowerDFGToB3.cpp:
1298         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1299         (JSC::FTL::DFG::LowerDFGToB3::compileGetVectorLength):
1300         (JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
1301         * jit/JITPropertyAccess.cpp:
1302         (JSC::JIT::emitArrayStoragePutByVal):
1303         * jit/JITPropertyAccess32_64.cpp:
1304         (JSC::JIT::emitArrayStorageLoad):
1305         (JSC::JIT::emitArrayStoragePutByVal):
1306
1307 2017-05-21  Saam Barati  <sbarati@apple.com>
1308
1309         We incorrectly throw a syntax error when declaring a top level for-loop iteration variable the same as a parameter
1310         https://bugs.webkit.org/show_bug.cgi?id=171041
1311         <rdar://problem/32082516>
1312
1313         Reviewed by Yusuke Suzuki.
1314
1315         We were treating a for-loop variable declaration potentially as a top
1316         level statement, e.g, in a program like this:
1317         ```
1318         function foo() {
1319             for (let variable of expr) { }
1320         }
1321         ```
1322         But we should not be. This had the consequence of making this type of program
1323         throw a syntax error:
1324         ```
1325         function foo(arg) {
1326             for (let arg of expr) { }
1327         }
1328         ```
1329         even though it should not. The fix is simple, we just need to increment the
1330         statement depth before parsing anything inside the for loop.
1331
1332         * parser/Parser.cpp:
1333         (JSC::Parser<LexerType>::parseForStatement):
1334
1335 2017-05-19  Yusuke Suzuki  <utatane.tea@gmail.com>
1336
1337         [JSC] Make get_by_val & string "499" to number 499
1338         https://bugs.webkit.org/show_bug.cgi?id=172225
1339
1340         Reviewed by Saam Barati.
1341
1342         Property subscript will be converted by ToString. So JS code is not aware of
1343         the original type of the subscript value. But our get_by_val can leverage
1344         information if the given subscript is number. Thus, passing number instead of
1345         string can improve the performance of get_by_val in all the tiers.
1346
1347         In this patch, we add BytecodeGenerator::emitNodeForProperty. It attempts to
1348         convert the given value to Int32 index constant if the given value is a string
1349         that can be converted to Int32.
1350
1351         This patch improves SixSpeed map-string.es5 by 9.8x. This accessing form can
1352         appear in some code like accessing the result of JSON.
1353
1354             map-string.es5     1640.6738+-110.9182   ^    167.4121+-23.8328       ^ definitely 9.8002x faster
1355
1356         * bytecompiler/BytecodeGenerator.h:
1357         (JSC::BytecodeGenerator::emitNodeForProperty):
1358         (JSC::BytecodeGenerator::emitNodeForLeftHandSideForProperty):
1359         * bytecompiler/NodesCodegen.cpp:
1360         (JSC::TaggedTemplateNode::emitBytecode):
1361         (JSC::BracketAccessorNode::emitBytecode):
1362         (JSC::BytecodeIntrinsicNode::emit_intrinsic_putByValDirect):
1363         (JSC::FunctionCallBracketNode::emitBytecode):
1364         (JSC::PostfixNode::emitBracket):
1365         (JSC::PrefixNode::emitBracket):
1366         (JSC::AssignBracketNode::emitBytecode):
1367         (JSC::ReadModifyBracketNode::emitBytecode):
1368         (JSC::ForInNode::emitLoopHeader):
1369         (JSC::ForOfNode::emitBytecode):
1370         (JSC::ObjectPatternNode::bindValue):
1371         (JSC::AssignmentElementNode::bindValue):
1372
1373 2017-05-21  Saam Barati  <sbarati@apple.com>
1374
1375         We overwrite the callee save space on the stack when throwing stack overflow from wasm
1376         https://bugs.webkit.org/show_bug.cgi?id=172316
1377
1378         Reviewed by Mark Lam.
1379
1380         When throwing a stack overflow exception, the overflow
1381         thunk would do the following:
1382           move fp, sp
1383           populate argument registers
1384           call C code
1385
1386         However, the C function is allowed to clobber our spilled
1387         callee saves that live below fp. The reason I did this move is that
1388         when we jump to this code, we've proven that sp is out of bounds on
1389         the stack. So we're not allowed to just use its value or keep growing
1390         the stack from that point. However, this patch revises this approach
1391         to be the same in spirit, but actually correct. We conservatively assume
1392         the B3 function we're coming from could have saved all callee saves.
1393         So we emit code like this now:
1394           add -maxNumCalleeSaveSpace, fp, sp
1395           populate argument registers
1396           call C code
1397
1398         This ensures our callee saves will not be overwritten. Note
1399         that fp is still in a valid stack range here, since the thing
1400         calling the wasm code did a stack check. Also note that maxNumCalleeSaveSpace
1401         is less than our redzone size, so it's safe to decrement sp by
1402         this amount.
1403
1404         The previously added wasm stack overflow test is an instance crash
1405         without this change on arm64. It also appears that this test crashed
1406         on some other x86 devices.
1407
1408         * wasm/WasmThunks.cpp:
1409         (JSC::Wasm::throwStackOverflowFromWasmThunkGenerator):
1410
1411 2017-05-20  Chris Dumez  <cdumez@apple.com>
1412
1413         Drop [NoInterfaceObject] from RTCDTMFSender and RTCStatsReport
1414         https://bugs.webkit.org/show_bug.cgi?id=172418
1415
1416         Reviewed by Youenn Fablet.
1417
1418         Add CommonIdentifiers that are now needed.
1419
1420         * runtime/CommonIdentifiers.h:
1421
1422 2017-05-20  Yusuke Suzuki  <utatane.tea@gmail.com>
1423
1424         Unreviewed, add scope.release() to propertyIsEnumerable functions.
1425         https://bugs.webkit.org/show_bug.cgi?id=172411
1426
1427         * runtime/JSGlobalObjectFunctions.cpp:
1428         (JSC::globalFuncPropertyIsEnumerable):
1429         * runtime/ObjectPrototype.cpp:
1430         (JSC::objectProtoFuncPropertyIsEnumerable):
1431
1432 2017-05-20  Yusuke Suzuki  <utatane.tea@gmail.com>
1433
1434         [JSC] Drop MapBase
1435         https://bugs.webkit.org/show_bug.cgi?id=172417
1436
1437         Reviewed by Sam Weinig.
1438
1439         MapBase is a purely additional indirection. JSMap and JSSet can directly inherit HashMapImpl.
1440         Thus MapBase is unnecessary. This patch drops it.
1441         It is good because we can eliminate one indirection when accessing to map implementation.
1442         Moreover, we can drop one unnecessary allocation per Map and Set.
1443
1444         * CMakeLists.txt:
1445         * JavaScriptCore.xcodeproj/project.pbxproj:
1446         * dfg/DFGSpeculativeJIT64.cpp:
1447         (JSC::DFG::SpeculativeJIT::compile):
1448         * ftl/FTLAbstractHeapRepository.h:
1449         * ftl/FTLLowerDFGToB3.cpp:
1450         (JSC::FTL::DFG::LowerDFGToB3::compileGetMapBucket):
1451         * runtime/HashMapImpl.cpp:
1452         (JSC::HashMapImpl<HashMapBucket>::estimatedSize):
1453         (JSC::getHashMapImplKeyClassInfo): Deleted.
1454         (JSC::getHashMapImplKeyValueClassInfo): Deleted.
1455         * runtime/HashMapImpl.h:
1456         (JSC::HashMapImpl::finishCreation):
1457         (JSC::HashMapImpl::get):
1458         (JSC::HashMapImpl::info): Deleted.
1459         (JSC::HashMapImpl::createStructure): Deleted.
1460         (JSC::HashMapImpl::create): Deleted.
1461         * runtime/JSMap.h:
1462         (JSC::JSMap::set):
1463         (JSC::JSMap::get): Deleted.
1464         * runtime/JSMapIterator.cpp:
1465         (JSC::JSMapIterator::finishCreation):
1466         * runtime/JSSet.h:
1467         (JSC::JSSet::add): Deleted.
1468         * runtime/JSSetIterator.cpp:
1469         (JSC::JSSetIterator::finishCreation):
1470         * runtime/MapBase.cpp: Removed.
1471         * runtime/MapBase.h: Removed.
1472         * runtime/MapPrototype.cpp:
1473         (JSC::mapProtoFuncSize):
1474         * runtime/SetConstructor.cpp:
1475         (JSC::constructSet):
1476         * runtime/SetPrototype.cpp:
1477         (JSC::setProtoFuncSize):
1478         * runtime/VM.cpp:
1479         (JSC::VM::VM):
1480
1481 2017-05-20  Yusuke Suzuki  <utatane.tea@gmail.com>
1482
1483         [JSC] Speedup Object.assign for slow case by using propertyIsEnumerable
1484         https://bugs.webkit.org/show_bug.cgi?id=172411
1485
1486         Reviewed by Sam Weinig.
1487
1488         We use @Reflect.@getOwnPropertyDescriptor() to check
1489
1490         1. the descriptor exists,
1491         2. and the descriptor.enumrable is true
1492
1493         But Object::propertyIsEnumerable does the completely same thing without
1494         allocating a new object for property descriptor.
1495
1496         In this patch, we add a new private function @propertyIsEnumerable, and
1497         use it in Object.assign implementation. It does not allocate unnecessary
1498         objects. It is good for GC-pressure and performance.
1499
1500         This patch improves SixSpeed object-assign.es6 by 1.7x. While this patch
1501         does not introduce a fast path for objects that do not have accessors,
1502         and it could speed up things further, this patch can speed up the common
1503         slow path cases that is the current implementation of Object.assign.
1504
1505             object-assign.es6     1103.2487+-21.5602    ^    621.8478+-34.9875       ^ definitely 1.7741x faster
1506
1507         * builtins/BuiltinNames.h:
1508         * builtins/ObjectConstructor.js:
1509         (globalPrivate.enumerableOwnProperties):
1510         (assign):
1511         * runtime/JSGlobalObject.cpp:
1512         (JSC::JSGlobalObject::init):
1513         * runtime/JSGlobalObjectFunctions.cpp:
1514         (JSC::globalFuncPropertyIsEnumerable):
1515         * runtime/JSGlobalObjectFunctions.h:
1516
1517 2017-05-19  Yusuke Suzuki  <utatane.tea@gmail.com>
1518
1519         [JSC] Enable testapi on Mac CMake build
1520         https://bugs.webkit.org/show_bug.cgi?id=172354
1521
1522         Reviewed by Alex Christensen.
1523
1524         This patch makes testapi buildable and runnable for Mac CMake port.
1525
1526         * API/tests/DateTests.mm:
1527         (+[DateTests JSDateToNSDateTest]):
1528         (+[DateTests roundTripThroughJSDateTest]):
1529         This test only works with the en_US locale.
1530
1531         * shell/CMakeLists.txt:
1532         * shell/PlatformMac.cmake:
1533         Some of tests rely on ARC. We enable ARC for those files.
1534
1535         * shell/PlatformWin.cmake:
1536         Clean up.
1537
1538 2017-05-19  Mark Lam  <mark.lam@apple.com>
1539
1540         [Re-landing] DFG::SpeculativeJIT::pickCanTrample() is wrongly ignoring result registers.
1541         https://bugs.webkit.org/show_bug.cgi?id=172383
1542         <rdar://problem/31418651>
1543
1544         Reviewed by Filip Pizlo.
1545
1546         pickCanTrample() is wrongly assuming that one of regT0 and regT1 is always
1547         available as a scratch register.  This assumption is wrong if this canTrample
1548         register is used for a silentFill() after an operation that returns a result in
1549         regT0 or regT1.
1550
1551         Turns out the only reason we need the canTrample register is for
1552         SetDoubleConstant.  We can remove the need for this canTrample register by
1553         introducing a moveDouble() pseudo instruction in the MacroAssembler to do the
1554         job using the scratchRegister() on X86_64 or the dataMemoryTempRegister() on
1555         ARM64.  In so doing, we can simplify the silentFill() code and eliminate the bug.
1556
1557         Update for re-landing: Changed ARM64 to use scratchRegister() as well.
1558         scratchRegister() is the proper way to get the underlying dataMemoryTempRegister()
1559         as a scratch register.
1560
1561         * assembler/MacroAssembler.h:
1562         (JSC::MacroAssembler::moveDouble):
1563         * dfg/DFGArrayifySlowPathGenerator.h:
1564         * dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
1565         (JSC::DFG::CallArrayAllocatorWithVariableStructureVariableSizeSlowPathGenerator::CallArrayAllocatorWithVariableStructureVariableSizeSlowPathGenerator):
1566         * dfg/DFGCallCreateDirectArgumentsSlowPathGenerator.h:
1567         * dfg/DFGSaneStringGetByValSlowPathGenerator.h:
1568         * dfg/DFGSlowPathGenerator.h:
1569         (JSC::DFG::CallSlowPathGenerator::tearDown):
1570         * dfg/DFGSpeculativeJIT.cpp:
1571         (JSC::DFG::SpeculativeJIT::silentFill):
1572         (JSC::DFG::SpeculativeJIT::compileToLowerCase):
1573         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
1574         (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
1575         (JSC::DFG::SpeculativeJIT::emitUntypedBitOp):
1576         (JSC::DFG::SpeculativeJIT::emitUntypedRightShiftBitOp):
1577         (JSC::DFG::SpeculativeJIT::compileArithDiv):
1578         (JSC::DFG::SpeculativeJIT::compileArraySlice):
1579         (JSC::DFG::SpeculativeJIT::emitSwitchImm):
1580         (JSC::DFG::SpeculativeJIT::emitSwitchStringOnString):
1581         (JSC::DFG::SpeculativeJIT::compileStoreBarrier):
1582         * dfg/DFGSpeculativeJIT.h:
1583         (JSC::DFG::SpeculativeJIT::silentFill):
1584         (JSC::DFG::SpeculativeJIT::silentSpillAllRegisters):
1585         (JSC::DFG::SpeculativeJIT::silentFillAllRegisters):
1586         (JSC::DFG::SpeculativeJIT::pickCanTrample): Deleted.
1587         * dfg/DFGSpeculativeJIT32_64.cpp:
1588         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
1589         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq):
1590         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq):
1591         (JSC::DFG::SpeculativeJIT::emitCall):
1592         (JSC::DFG::SpeculativeJIT::compile):
1593         * dfg/DFGSpeculativeJIT64.cpp:
1594         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
1595         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq):
1596         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq):
1597         (JSC::DFG::SpeculativeJIT::emitCall):
1598         (JSC::DFG::SpeculativeJIT::compile):
1599         (JSC::DFG::SpeculativeJIT::convertAnyInt):
1600
1601 2017-05-19  Ryan Haddad  <ryanhaddad@apple.com>
1602
1603         Unreviewed, rolling out r217156.
1604
1605         This change broke the iOS build.
1606
1607         Reverted changeset:
1608
1609         "DFG::SpeculativeJIT::pickCanTrample() is wrongly ignoring
1610         result registers."
1611         https://bugs.webkit.org/show_bug.cgi?id=172383
1612         http://trac.webkit.org/changeset/217156
1613
1614 2017-05-19  Mark Lam  <mark.lam@apple.com>
1615
1616         Add missing exception check.
1617         https://bugs.webkit.org/show_bug.cgi?id=172346
1618         <rdar://problem/32289640>
1619
1620         Reviewed by Geoffrey Garen.
1621
1622         * runtime/JSObject.cpp:
1623         (JSC::JSObject::hasInstance):
1624
1625 2017-05-19  Mark Lam  <mark.lam@apple.com>
1626
1627         DFG::SpeculativeJIT::pickCanTrample() is wrongly ignoring result registers.
1628         https://bugs.webkit.org/show_bug.cgi?id=172383
1629         <rdar://problem/31418651>
1630
1631         Reviewed by Filip Pizlo.
1632
1633         pickCanTrample() is wrongly assuming that one of regT0 and regT1 is always
1634         available as a scratch register.  This assumption is wrong if this canTrample
1635         register is used for a silentFill() after an operation that returns a result in
1636         regT0 or regT1.
1637
1638         Turns out the only reason we need the canTrample register is for
1639         SetDoubleConstant.  We can remove the need for this canTrample register by
1640         introducing a moveDouble() pseudo instruction in the MacroAssembler to do the
1641         job using the scratchRegister() on X86_64 or the dataMemoryTempRegister() on
1642         ARM64.  In so doing, we can simplify the silentFill() code and eliminate the bug.
1643
1644         * assembler/MacroAssembler.h:
1645         (JSC::MacroAssembler::moveDouble):
1646         * dfg/DFGArrayifySlowPathGenerator.h:
1647         * dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
1648         (JSC::DFG::CallArrayAllocatorWithVariableStructureVariableSizeSlowPathGenerator::CallArrayAllocatorWithVariableStructureVariableSizeSlowPathGenerator):
1649         * dfg/DFGCallCreateDirectArgumentsSlowPathGenerator.h:
1650         * dfg/DFGSaneStringGetByValSlowPathGenerator.h:
1651         * dfg/DFGSlowPathGenerator.h:
1652         (JSC::DFG::CallSlowPathGenerator::tearDown):
1653         * dfg/DFGSpeculativeJIT.cpp:
1654         (JSC::DFG::SpeculativeJIT::silentFill):
1655         (JSC::DFG::SpeculativeJIT::compileToLowerCase):
1656         (JSC::DFG::SpeculativeJIT::compileValueToInt32):
1657         (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
1658         (JSC::DFG::SpeculativeJIT::emitUntypedBitOp):
1659         (JSC::DFG::SpeculativeJIT::emitUntypedRightShiftBitOp):
1660         (JSC::DFG::SpeculativeJIT::compileArithDiv):
1661         (JSC::DFG::SpeculativeJIT::compileArraySlice):
1662         (JSC::DFG::SpeculativeJIT::emitSwitchImm):
1663         (JSC::DFG::SpeculativeJIT::emitSwitchStringOnString):
1664         (JSC::DFG::SpeculativeJIT::compileStoreBarrier):
1665         * dfg/DFGSpeculativeJIT.h:
1666         (JSC::DFG::SpeculativeJIT::silentFill):
1667         (JSC::DFG::SpeculativeJIT::silentSpillAllRegisters):
1668         (JSC::DFG::SpeculativeJIT::silentFillAllRegisters):
1669         (JSC::DFG::SpeculativeJIT::pickCanTrample): Deleted.
1670         * dfg/DFGSpeculativeJIT32_64.cpp:
1671         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
1672         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq):
1673         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq):
1674         (JSC::DFG::SpeculativeJIT::emitCall):
1675         (JSC::DFG::SpeculativeJIT::compile):
1676         * dfg/DFGSpeculativeJIT64.cpp:
1677         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch):
1678         (JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq):
1679         (JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq):
1680         (JSC::DFG::SpeculativeJIT::emitCall):
1681         (JSC::DFG::SpeculativeJIT::compile):
1682         (JSC::DFG::SpeculativeJIT::convertAnyInt):
1683
1684 2017-05-19  Filip Pizlo  <fpizlo@apple.com>
1685
1686         Deduplicate some code in arrayProtoPrivateFuncConcatMemcpy
1687         https://bugs.webkit.org/show_bug.cgi?id=172382
1688
1689         Reviewed by Saam Barati.
1690
1691         This is just a small clean-up - my last patch here created some unnecessary code duplication.
1692
1693         * runtime/ArrayPrototype.cpp:
1694         (JSC::arrayProtoPrivateFuncConcatMemcpy):
1695
1696 2017-05-19  Filip Pizlo  <fpizlo@apple.com>
1697
1698         arrayProtoPrivateFuncConcatMemcpy needs to be down with firstArray being undecided
1699         https://bugs.webkit.org/show_bug.cgi?id=172369
1700
1701         Reviewed by Mark Lam.
1702
1703         * heap/Subspace.cpp: Reshaped the code a bit to aid debugging.
1704         (JSC::Subspace::allocate):
1705         (JSC::Subspace::tryAllocate):
1706         * runtime/ArrayPrototype.cpp:
1707         (JSC::arrayProtoPrivateFuncConcatMemcpy): Fix the bug!
1708         * runtime/ObjectInitializationScope.cpp: Provide even better feedback.
1709         (JSC::ObjectInitializationScope::verifyPropertiesAreInitialized):
1710
1711 2017-05-18  Filip Pizlo  <fpizlo@apple.com>
1712
1713         B3::Value::effects() says that having a fence range implies the fence bit, but on x86_64 we lower loadAcq/storeRel to load/store so the store-before-load fence bit orderings won't be honored
1714         https://bugs.webkit.org/show_bug.cgi?id=172306
1715
1716         Reviewed by Michael Saboff.
1717
1718         This changes B3 to emit xchg and its variants for fenced stores on x86. This ensures that
1719         fenced stores cannot be reordered around other fenced instructions. Previously, B3 emitted
1720         normal store instructions for fenced stores. That's wrong because then you get reorderings
1721         that are possible in TSO but impossible in SC. Fenced instructions are supposed to be SC
1722         with respect for each other.
1723
1724         This is imprecise. If you really just wanted a store-release, then every X86 store does this.
1725         But, in B3, fenced stores are ARM-style store-release, meaning that they are fenced with
1726         respect to all other fences. If we ever did want to say that something is a store release in
1727         the traditional sense, then we'd want MemoryValue to have a fence flag. Then, having a fence
1728         range without the fence flag would mean the traditional store-release, which lowers to a
1729         normal store on x86. But to my knowledge, that traditional store-release is only useful for
1730         unlocking spinlocks. We don't use spinlocks in JSC. Adaptive locks require CAS for unlock,
1731         and B3 CAS is plenty fast. I think it's OK to have this small imprecision of giving clients
1732         an ARM-style store-release on x86 using xchg.
1733
1734         The implication of this change is that the FTL no longer violates the SAB memory model.
1735
1736         * assembler/MacroAssemblerX86Common.h:
1737         (JSC::MacroAssemblerX86Common::xchg8):
1738         (JSC::MacroAssemblerX86Common::xchg16):
1739         (JSC::MacroAssemblerX86Common::xchg32):
1740         (JSC::MacroAssemblerX86Common::loadAcq8): Deleted.
1741         (JSC::MacroAssemblerX86Common::loadAcq8SignedExtendTo32): Deleted.
1742         (JSC::MacroAssemblerX86Common::loadAcq16): Deleted.
1743         (JSC::MacroAssemblerX86Common::loadAcq16SignedExtendTo32): Deleted.
1744         (JSC::MacroAssemblerX86Common::loadAcq32): Deleted.
1745         (JSC::MacroAssemblerX86Common::storeRel8): Deleted.
1746         (JSC::MacroAssemblerX86Common::storeRel16): Deleted.
1747         (JSC::MacroAssemblerX86Common::storeRel32): Deleted.
1748         * assembler/MacroAssemblerX86_64.h:
1749         (JSC::MacroAssemblerX86_64::xchg64):
1750         (JSC::MacroAssemblerX86_64::loadAcq64): Deleted.
1751         (JSC::MacroAssemblerX86_64::storeRel64): Deleted.
1752         * b3/B3LowerToAir.cpp:
1753         (JSC::B3::Air::LowerToAir::ArgPromise::inst):
1754         (JSC::B3::Air::LowerToAir::trappingInst):
1755         (JSC::B3::Air::LowerToAir::tryAppendStoreBinOp):
1756         (JSC::B3::Air::LowerToAir::createStore):
1757         (JSC::B3::Air::LowerToAir::storeOpcode):
1758         (JSC::B3::Air::LowerToAir::appendStore):
1759         (JSC::B3::Air::LowerToAir::append):
1760         (JSC::B3::Air::LowerToAir::appendTrapping):
1761         (JSC::B3::Air::LowerToAir::fillStackmap):
1762         (JSC::B3::Air::LowerToAir::lower):
1763         * b3/air/AirKind.cpp:
1764         (JSC::B3::Air::Kind::dump):
1765         * b3/air/AirKind.h:
1766         (JSC::B3::Air::Kind::Kind):
1767         (JSC::B3::Air::Kind::operator==):
1768         (JSC::B3::Air::Kind::hash):
1769         * b3/air/AirLowerAfterRegAlloc.cpp:
1770         (JSC::B3::Air::lowerAfterRegAlloc):
1771         * b3/air/AirLowerMacros.cpp:
1772         (JSC::B3::Air::lowerMacros):
1773         * b3/air/AirOpcode.opcodes:
1774         * b3/air/AirValidate.cpp:
1775         * b3/air/opcode_generator.rb:
1776         * b3/testb3.cpp:
1777         (JSC::B3::correctSqrt):
1778         (JSC::B3::testSqrtArg):
1779         (JSC::B3::testSqrtImm):
1780         (JSC::B3::testSqrtMem):
1781         (JSC::B3::testSqrtArgWithUselessDoubleConversion):
1782         (JSC::B3::testSqrtArgWithEffectfulDoubleConversion):
1783         (JSC::B3::testStoreRelAddLoadAcq32):
1784         (JSC::B3::testTrappingLoad):
1785         (JSC::B3::testTrappingStore):
1786         (JSC::B3::testTrappingLoadAddStore):
1787         (JSC::B3::testTrappingLoadDCE):
1788
1789 2017-05-19  Don Olmstead  <don.olmstead@am.sony.com>
1790
1791         [JSC] Remove PLATFORM(WIN) references
1792         https://bugs.webkit.org/show_bug.cgi?id=172294
1793
1794         Reviewed by Yusuke Suzuki.
1795
1796         * heap/MachineStackMarker.cpp:
1797         (JSC::MachineThreads::removeThread):
1798         * llint/LLIntOfflineAsmConfig.h:
1799         * runtime/ConfigFile.h:
1800         * runtime/VM.cpp:
1801         (JSC::VM::updateStackLimits):
1802
1803 2017-05-19  Yusuke Suzuki  <utatane.tea@gmail.com>
1804
1805         [JSC][DFG][DOMJIT] Extend CheckDOM to CheckSubClass
1806         https://bugs.webkit.org/show_bug.cgi?id=172098
1807
1808         Reviewed by Saam Barati.
1809
1810         In this patch, we generalize CheckDOM to CheckSubClass.
1811         It can accept any ClassInfo and perform ClassInfo check
1812         in DFG / FTL. Now, we add a new function pointer to ClassInfo,
1813         checkSubClassPatchpoint. It can create DOMJIT patchpoint
1814         for that ClassInfo. It it natural that ClassInfo holds the
1815         way to emit DOMJIT::Patchpoint to perform CheckSubClass
1816         rather than having it in each DOMJIT getter / function
1817         signature annotation.
1818
1819         One problem is that it enlarges the size of ClassInfo.
1820         But this is the best place to put this function pointer.
1821         By doing so, we can add a patchpoint for CheckSubClass
1822         in an non-intrusive manner: WebCore can inject patchpoints
1823         without interactive JSC.
1824
1825         We still have a way to reduce the size of ClassInfo if
1826         we move ArrayBuffer related methods out to the other places.
1827
1828         This patch touches many files because we add a new function
1829         pointer to ClassInfo. But they are basically mechanical change.
1830
1831         * API/JSAPIWrapperObject.mm:
1832         * API/JSCallbackConstructor.cpp:
1833         * API/JSCallbackFunction.cpp:
1834         * API/JSCallbackObject.cpp:
1835         * API/ObjCCallbackFunction.mm:
1836         * CMakeLists.txt:
1837         * JavaScriptCore.xcodeproj/project.pbxproj:
1838         * bytecode/CodeBlock.cpp:
1839         * bytecode/DOMJITAccessCasePatchpointParams.h:
1840         (JSC::DOMJITAccessCasePatchpointParams::DOMJITAccessCasePatchpointParams):
1841         * bytecode/EvalCodeBlock.cpp:
1842         * bytecode/FunctionCodeBlock.cpp:
1843         * bytecode/GetterSetterAccessCase.cpp:
1844         (JSC::GetterSetterAccessCase::emitDOMJITGetter):
1845         * bytecode/ModuleProgramCodeBlock.cpp:
1846         * bytecode/ProgramCodeBlock.cpp:
1847         * bytecode/UnlinkedCodeBlock.cpp:
1848         * bytecode/UnlinkedEvalCodeBlock.cpp:
1849         * bytecode/UnlinkedFunctionCodeBlock.cpp:
1850         * bytecode/UnlinkedFunctionExecutable.cpp:
1851         * bytecode/UnlinkedModuleProgramCodeBlock.cpp:
1852         * bytecode/UnlinkedProgramCodeBlock.cpp:
1853         * debugger/DebuggerScope.cpp:
1854         * dfg/DFGAbstractInterpreterInlines.h:
1855         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1856         * dfg/DFGByteCodeParser.cpp:
1857         (JSC::DFG::ByteCodeParser::handleDOMJITGetter):
1858         * dfg/DFGClobberize.h:
1859         (JSC::DFG::clobberize):
1860         * dfg/DFGConstantFoldingPhase.cpp:
1861         (JSC::DFG::ConstantFoldingPhase::foldConstants):
1862         * dfg/DFGDOMJITPatchpointParams.h:
1863         (JSC::DFG::DOMJITPatchpointParams::DOMJITPatchpointParams):
1864         * dfg/DFGDoesGC.cpp:
1865         (JSC::DFG::doesGC):
1866         * dfg/DFGFixupPhase.cpp:
1867         (JSC::DFG::FixupPhase::fixupNode):
1868         (JSC::DFG::FixupPhase::attemptToMakeCallDOM):
1869         (JSC::DFG::FixupPhase::fixupCheckSubClass):
1870         (JSC::DFG::FixupPhase::fixupCheckDOM): Deleted.
1871         * dfg/DFGGraph.cpp:
1872         (JSC::DFG::Graph::dump):
1873         * dfg/DFGNode.h:
1874         (JSC::DFG::Node::hasClassInfo):
1875         (JSC::DFG::Node::classInfo):
1876         (JSC::DFG::Node::hasCheckDOMPatchpoint): Deleted.
1877         (JSC::DFG::Node::checkDOMPatchpoint): Deleted.
1878         * dfg/DFGNodeType.h:
1879         * dfg/DFGPredictionPropagationPhase.cpp:
1880         * dfg/DFGSafeToExecute.h:
1881         (JSC::DFG::safeToExecute):
1882         * dfg/DFGSpeculativeJIT.cpp:
1883         (JSC::DFG::SpeculativeJIT::compileCheckSubClass):
1884         (JSC::DFG::SpeculativeJIT::compileCheckDOM): Deleted.
1885         * dfg/DFGSpeculativeJIT.h:
1886         (JSC::DFG::SpeculativeJIT::vm):
1887         * dfg/DFGSpeculativeJIT32_64.cpp:
1888         (JSC::DFG::SpeculativeJIT::compile):
1889         * dfg/DFGSpeculativeJIT64.cpp:
1890         (JSC::DFG::SpeculativeJIT::compile):
1891         * domjit/DOMJITGetterSetter.h:
1892         * domjit/DOMJITPatchpointParams.h:
1893         (JSC::DOMJIT::PatchpointParams::PatchpointParams):
1894         (JSC::DOMJIT::PatchpointParams::vm):
1895         * domjit/DOMJITSignature.h:
1896         (JSC::DOMJIT::Signature::Signature):
1897         (JSC::DOMJIT::Signature::checkDOM): Deleted.
1898         * ftl/FTLAbstractHeapRepository.h:
1899         * ftl/FTLCapabilities.cpp:
1900         (JSC::FTL::canCompile):
1901         * ftl/FTLDOMJITPatchpointParams.h:
1902         (JSC::FTL::DOMJITPatchpointParams::DOMJITPatchpointParams):
1903         * ftl/FTLLowerDFGToB3.cpp:
1904         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1905         (JSC::FTL::DFG::LowerDFGToB3::compileCheckSubClass):
1906         (JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM): Deleted.
1907         * inspector/JSInjectedScriptHost.cpp:
1908         * inspector/JSInjectedScriptHostPrototype.cpp:
1909         * inspector/JSJavaScriptCallFrame.cpp:
1910         * inspector/JSJavaScriptCallFramePrototype.cpp:
1911         * jsc.cpp:
1912         (WTF::DOMJITNode::checkSubClassPatchpoint):
1913         (WTF::DOMJITFunctionObject::checkSubClassPatchpoint):
1914         (WTF::DOMJITFunctionObject::finishCreation):
1915         (WTF::DOMJITCheckSubClassObject::DOMJITCheckSubClassObject):
1916         (WTF::DOMJITCheckSubClassObject::createStructure):
1917         (WTF::DOMJITCheckSubClassObject::create):
1918         (WTF::DOMJITCheckSubClassObject::safeFunction):
1919         (WTF::DOMJITCheckSubClassObject::unsafeFunction):
1920         (WTF::DOMJITCheckSubClassObject::finishCreation):
1921         (GlobalObject::finishCreation):
1922         (functionCreateDOMJITCheckSubClassObject):
1923         (WTF::DOMJITNode::checkDOMJITNode): Deleted.
1924         (WTF::DOMJITFunctionObject::checkDOMJITNode): Deleted.
1925         * runtime/AbstractModuleRecord.cpp:
1926         * runtime/ArrayBufferNeuteringWatchpoint.cpp:
1927         * runtime/ArrayConstructor.cpp:
1928         * runtime/ArrayIteratorPrototype.cpp:
1929         * runtime/ArrayPrototype.cpp:
1930         * runtime/AsyncFunctionConstructor.cpp:
1931         * runtime/AsyncFunctionPrototype.cpp:
1932         * runtime/AtomicsObject.cpp:
1933         * runtime/BooleanConstructor.cpp:
1934         * runtime/BooleanObject.cpp:
1935         * runtime/BooleanPrototype.cpp:
1936         * runtime/ClassInfo.cpp: Copied from Source/JavaScriptCore/tools/JSDollarVM.cpp.
1937         (JSC::ClassInfo::dump):
1938         * runtime/ClassInfo.h:
1939         (JSC::ClassInfo::offsetOfParentClass):
1940         * runtime/ClonedArguments.cpp:
1941         * runtime/ConsoleObject.cpp:
1942         * runtime/CustomGetterSetter.cpp:
1943         * runtime/DateConstructor.cpp:
1944         * runtime/DateInstance.cpp:
1945         * runtime/DatePrototype.cpp:
1946         * runtime/DirectArguments.cpp:
1947         * runtime/Error.cpp:
1948         * runtime/ErrorConstructor.cpp:
1949         * runtime/ErrorInstance.cpp:
1950         * runtime/ErrorPrototype.cpp:
1951         * runtime/EvalExecutable.cpp:
1952         * runtime/Exception.cpp:
1953         * runtime/ExceptionHelpers.cpp:
1954         * runtime/ExecutableBase.cpp:
1955         * runtime/FunctionConstructor.cpp:
1956         * runtime/FunctionExecutable.cpp:
1957         * runtime/FunctionPrototype.cpp:
1958         * runtime/FunctionRareData.cpp:
1959         * runtime/GeneratorFunctionConstructor.cpp:
1960         * runtime/GeneratorFunctionPrototype.cpp:
1961         * runtime/GeneratorPrototype.cpp:
1962         * runtime/GetterSetter.cpp:
1963         * runtime/HashMapImpl.cpp:
1964         * runtime/HashMapImpl.h:
1965         * runtime/InferredType.cpp:
1966         (JSC::InferredType::create):
1967         * runtime/InferredTypeTable.cpp:
1968         * runtime/InferredValue.cpp:
1969         * runtime/InspectorInstrumentationObject.cpp:
1970         * runtime/InternalFunction.cpp:
1971         * runtime/IntlCollator.cpp:
1972         * runtime/IntlCollatorConstructor.cpp:
1973         * runtime/IntlCollatorPrototype.cpp:
1974         * runtime/IntlDateTimeFormat.cpp:
1975         * runtime/IntlDateTimeFormatConstructor.cpp:
1976         * runtime/IntlDateTimeFormatPrototype.cpp:
1977         * runtime/IntlNumberFormat.cpp:
1978         * runtime/IntlNumberFormatConstructor.cpp:
1979         * runtime/IntlNumberFormatPrototype.cpp:
1980         * runtime/IntlObject.cpp:
1981         * runtime/IteratorPrototype.cpp:
1982         * runtime/JSAPIValueWrapper.cpp:
1983         * runtime/JSArray.cpp:
1984         * runtime/JSArrayBuffer.cpp:
1985         * runtime/JSArrayBufferConstructor.cpp:
1986         * runtime/JSArrayBufferPrototype.cpp:
1987         * runtime/JSArrayBufferView.cpp:
1988         * runtime/JSAsyncFunction.cpp:
1989         * runtime/JSBoundFunction.cpp:
1990         * runtime/JSCallee.cpp:
1991         * runtime/JSCustomGetterSetterFunction.cpp:
1992         * runtime/JSDataView.cpp:
1993         * runtime/JSDataViewPrototype.cpp:
1994         * runtime/JSEnvironmentRecord.cpp:
1995         * runtime/JSFixedArray.cpp:
1996         * runtime/JSFunction.cpp:
1997         * runtime/JSGeneratorFunction.cpp:
1998         * runtime/JSGlobalLexicalEnvironment.cpp:
1999         * runtime/JSGlobalObject.cpp:
2000         * runtime/JSInternalPromise.cpp:
2001         * runtime/JSInternalPromiseConstructor.cpp:
2002         * runtime/JSInternalPromiseDeferred.cpp:
2003         * runtime/JSInternalPromisePrototype.cpp:
2004         * runtime/JSLexicalEnvironment.cpp:
2005         * runtime/JSMap.cpp:
2006         * runtime/JSMapIterator.cpp:
2007         * runtime/JSModuleEnvironment.cpp:
2008         * runtime/JSModuleLoader.cpp:
2009         * runtime/JSModuleNamespaceObject.cpp:
2010         * runtime/JSModuleRecord.cpp:
2011         * runtime/JSNativeStdFunction.cpp:
2012         * runtime/JSONObject.cpp:
2013         * runtime/JSObject.cpp:
2014         * runtime/JSPromise.cpp:
2015         * runtime/JSPromiseConstructor.cpp:
2016         * runtime/JSPromiseDeferred.cpp:
2017         * runtime/JSPromisePrototype.cpp:
2018         * runtime/JSPropertyNameEnumerator.cpp:
2019         * runtime/JSPropertyNameIterator.cpp:
2020         * runtime/JSProxy.cpp:
2021         * runtime/JSScriptFetcher.cpp:
2022         * runtime/JSSet.cpp:
2023         * runtime/JSSetIterator.cpp:
2024         * runtime/JSSourceCode.cpp:
2025         * runtime/JSString.cpp:
2026         * runtime/JSStringIterator.cpp:
2027         * runtime/JSSymbolTableObject.cpp:
2028         * runtime/JSTemplateRegistryKey.cpp:
2029         * runtime/JSTypedArrayConstructors.cpp:
2030         * runtime/JSTypedArrayPrototypes.cpp:
2031         * runtime/JSTypedArrayViewConstructor.cpp:
2032         * runtime/JSTypedArrays.cpp:
2033         * runtime/JSWeakMap.cpp:
2034         * runtime/JSWeakSet.cpp:
2035         * runtime/JSWithScope.cpp:
2036         * runtime/MapConstructor.cpp:
2037         * runtime/MapIteratorPrototype.cpp:
2038         * runtime/MapPrototype.cpp:
2039         * runtime/MathObject.cpp:
2040         * runtime/ModuleLoaderPrototype.cpp:
2041         * runtime/ModuleProgramExecutable.cpp:
2042         * runtime/NativeErrorConstructor.cpp:
2043         * runtime/NativeExecutable.cpp:
2044         * runtime/NativeStdFunctionCell.cpp:
2045         * runtime/NullGetterFunction.cpp:
2046         * runtime/NullSetterFunction.cpp:
2047         * runtime/NumberConstructor.cpp:
2048         * runtime/NumberObject.cpp:
2049         * runtime/NumberPrototype.cpp:
2050         * runtime/ObjectConstructor.cpp:
2051         * runtime/ObjectPrototype.cpp:
2052         * runtime/ProgramExecutable.cpp:
2053         * runtime/PropertyTable.cpp:
2054         * runtime/ProxyConstructor.cpp:
2055         * runtime/ProxyObject.cpp:
2056         * runtime/ProxyRevoke.cpp:
2057         * runtime/ReflectObject.cpp:
2058         * runtime/RegExp.cpp:
2059         * runtime/RegExpConstructor.cpp:
2060         * runtime/RegExpObject.cpp:
2061         * runtime/RegExpPrototype.cpp:
2062         * runtime/ScopedArguments.cpp:
2063         * runtime/ScopedArgumentsTable.cpp:
2064         * runtime/ScriptExecutable.cpp:
2065         * runtime/SetConstructor.cpp:
2066         * runtime/SetIteratorPrototype.cpp:
2067         * runtime/SetPrototype.cpp:
2068         * runtime/SparseArrayValueMap.cpp:
2069         * runtime/StrictEvalActivation.cpp:
2070         * runtime/StringConstructor.cpp:
2071         * runtime/StringIteratorPrototype.cpp:
2072         * runtime/StringObject.cpp:
2073         * runtime/StringPrototype.cpp:
2074         * runtime/Structure.cpp:
2075         * runtime/StructureChain.cpp:
2076         * runtime/StructureRareData.cpp:
2077         * runtime/Symbol.cpp:
2078         * runtime/SymbolConstructor.cpp:
2079         * runtime/SymbolObject.cpp:
2080         * runtime/SymbolPrototype.cpp:
2081         * runtime/SymbolTable.cpp:
2082         * runtime/WeakMapConstructor.cpp:
2083         * runtime/WeakMapData.cpp:
2084         * runtime/WeakMapPrototype.cpp:
2085         * runtime/WeakSetConstructor.cpp:
2086         * runtime/WeakSetPrototype.cpp:
2087         * testRegExp.cpp:
2088         * tools/JSDollarVM.cpp:
2089         * tools/JSDollarVMPrototype.cpp:
2090         * wasm/JSWebAssembly.cpp:
2091         * wasm/js/JSWebAssemblyCodeBlock.cpp:
2092         * wasm/js/JSWebAssemblyCompileError.cpp:
2093         * wasm/js/JSWebAssemblyInstance.cpp:
2094         * wasm/js/JSWebAssemblyLinkError.cpp:
2095         * wasm/js/JSWebAssemblyMemory.cpp:
2096         * wasm/js/JSWebAssemblyModule.cpp:
2097         * wasm/js/JSWebAssemblyRuntimeError.cpp:
2098         * wasm/js/JSWebAssemblyTable.cpp:
2099         * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
2100         * wasm/js/WebAssemblyCompileErrorPrototype.cpp:
2101         * wasm/js/WebAssemblyFunction.cpp:
2102         * wasm/js/WebAssemblyFunctionBase.cpp:
2103         * wasm/js/WebAssemblyInstanceConstructor.cpp:
2104         * wasm/js/WebAssemblyInstancePrototype.cpp:
2105         * wasm/js/WebAssemblyLinkErrorConstructor.cpp:
2106         * wasm/js/WebAssemblyLinkErrorPrototype.cpp:
2107         * wasm/js/WebAssemblyMemoryConstructor.cpp:
2108         * wasm/js/WebAssemblyMemoryPrototype.cpp:
2109         * wasm/js/WebAssemblyModuleConstructor.cpp:
2110         * wasm/js/WebAssemblyModulePrototype.cpp:
2111         * wasm/js/WebAssemblyModuleRecord.cpp:
2112         * wasm/js/WebAssemblyPrototype.cpp:
2113         * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
2114         * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp:
2115         * wasm/js/WebAssemblyTableConstructor.cpp:
2116         * wasm/js/WebAssemblyTablePrototype.cpp:
2117         * wasm/js/WebAssemblyToJSCallee.cpp:
2118         * wasm/js/WebAssemblyWrapperFunction.cpp:
2119
2120 2017-05-18  JF Bastien  <jfbastien@apple.com>
2121
2122         WebAssembly: exports is a getter
2123         https://bugs.webkit.org/show_bug.cgi?id=172129
2124
2125         Reviewed by Saam Barati.
2126
2127         As updated here: https://github.com/WebAssembly/design/pull/1062
2128
2129         * wasm/js/JSWebAssemblyInstance.cpp:
2130         (JSC::JSWebAssemblyInstance::finishCreation): don't putDirect here anymore
2131         * wasm/js/JSWebAssemblyInstance.h:
2132         (JSC::JSWebAssemblyInstance::moduleNamespaceObject): add accessor
2133         * wasm/js/WebAssemblyFunctionBase.cpp: squelch causing a warning
2134         * wasm/js/WebAssemblyInstancePrototype.cpp: use LUT
2135         (JSC::getInstance): helper, as in surrounding files
2136         (JSC::webAssemblyInstanceProtoFuncExports): instead of putDirect
2137         * wasm/js/WebAssemblyMemoryPrototype.cpp: pass VM around as for Table
2138         (JSC::getMemory):
2139         (JSC::webAssemblyMemoryProtoFuncGrow):
2140         (JSC::webAssemblyMemoryProtoFuncBuffer):
2141         * wasm/js/WebAssemblyTablePrototype.cpp: static everywhere as with other code
2142         (JSC::webAssemblyTableProtoFuncLength):
2143         (JSC::webAssemblyTableProtoFuncGrow):
2144         (JSC::webAssemblyTableProtoFuncGet):
2145         (JSC::webAssemblyTableProtoFuncSet):
2146
2147 2017-05-18  Saam Barati  <sbarati@apple.com>
2148
2149         Proxy's [[Get]] passes incorrect receiver
2150         https://bugs.webkit.org/show_bug.cgi?id=164849
2151         <rdar://problem/31767058>
2152
2153         Reviewed by Yusuke Suzuki.
2154
2155         * runtime/ProxyObject.cpp:
2156         (JSC::performProxyGet):
2157
2158 2017-05-18  Andy Estes  <aestes@apple.com>
2159
2160         ENABLE(APPLE_PAY_DELEGATE) should be NO on macOS Sierra and earlier
2161         https://bugs.webkit.org/show_bug.cgi?id=172305
2162
2163         Reviewed by Anders Carlsson.
2164
2165         * Configurations/FeatureDefines.xcconfig:
2166
2167 2017-05-18  Saam Barati  <sbarati@apple.com>
2168
2169         We need to destroy worker threads in jsc.cpp
2170         https://bugs.webkit.org/show_bug.cgi?id=170751
2171         <rdar://problem/31800412>
2172
2173         Reviewed by Filip Pizlo.
2174
2175         This patch fixes a bug where a $ agent worker would still
2176         have compilation threads running after the thread the worker
2177         was created on dies. This manifested itself inside DFG AI where
2178         we would notice a string constant is atomic, then the worker
2179         thread would die, destroying its atomic string table, then
2180         we'd notice the same string is no longer atomic, and we'd crash
2181         because we'd fail to see the same speculated type for the same
2182         JSValue.
2183
2184         This patch makes it so that $ agent workers destroy their VM when
2185         they're done executing. Before a VM gets destroyed, it ensures that
2186         all its compilation threads finish.
2187
2188         * jsc.cpp:
2189         (functionDollarAgentStart):
2190         (runJSC):
2191         (jscmain):
2192
2193 2017-05-18  Michael Saboff  <msaboff@apple.com>
2194
2195         Add FTL whitelist debugging option
2196         https://bugs.webkit.org/show_bug.cgi?id=172321
2197
2198         Reviewed by Saam Barati.
2199
2200         * dfg/DFGTierUpCheckInjectionPhase.cpp:
2201         (JSC::DFG::ensureGlobalFTLWhitelist):
2202         (JSC::DFG::TierUpCheckInjectionPhase::run):
2203         * runtime/Options.h:
2204         * tools/FunctionWhitelist.cpp:
2205         (JSC::FunctionWhitelist::contains):
2206
2207 2017-05-18  Filip Pizlo  <fpizlo@apple.com>
2208
2209         Constructor calls set this too early
2210         https://bugs.webkit.org/show_bug.cgi?id=172302
2211
2212         Reviewed by Saam Barati.
2213
2214         We were setting this before evaluating the arguments, so this code:
2215
2216             var x = 42;
2217             new x(x = function() { });
2218
2219         Would crash because we would pass 42 as this, and create_this would treat it as a cell.
2220         Dereferencing a non-cell is guaranteed to crash.
2221
2222         * bytecompiler/BytecodeGenerator.cpp:
2223         (JSC::BytecodeGenerator::emitConstruct):
2224         * bytecompiler/BytecodeGenerator.h:
2225         * bytecompiler/NodesCodegen.cpp:
2226         (JSC::NewExprNode::emitBytecode):
2227         (JSC::FunctionCallValueNode::emitBytecode):
2228
2229 2017-05-18  Saam Barati  <sbarati@apple.com>
2230
2231         WebAssembly: perform stack checks
2232         https://bugs.webkit.org/show_bug.cgi?id=165546
2233         <rdar://problem/29760307>
2234
2235         Reviewed by Filip Pizlo.
2236
2237         This patch adds stack checks to wasm. It implements it by storing the stack
2238         bounds on the Context.
2239
2240         Stack checking works as normal, except we do a small optimization for terminal
2241         nodes in the call tree (nodes that don't make any calls). These nodes will
2242         only do a stack check if their frame size is beyond 1024 bytes. Otherwise,
2243         it's assumed the parent that called them did their stack check for them.
2244         This is because all things that make calls make sure to do an extra 1024
2245         bytes whenever doing a stack check.
2246
2247         We also take into account stack size for potential JS calls when doing
2248         stack checks since our JS stubs don't do this on their own. Each frame
2249         will ensure it does a stack check large enough for any potential JS call
2250         stubs it'll execute.
2251
2252         Surprisingly, this patch is neutral on WasmBench and TitzerBench.
2253
2254         * llint/LLIntData.cpp:
2255         (JSC::LLInt::Data::performAssertions):
2256         * llint/LowLevelInterpreter.asm:
2257         * runtime/Error.cpp:
2258         (JSC::createRangeError):
2259         (JSC::addErrorInfoAndGetBytecodeOffset):
2260         I fixed a bug here where we assumed that the first frame that has line
2261         and column info would be in our stack trace. This is not correct
2262         since we limit our stack trace size. If everything in our limited
2263         size stack trace is Wasm, then we won't have any frames with line
2264         and column info.
2265         * runtime/Error.h:
2266         * runtime/ExceptionHelpers.cpp:
2267         (JSC::createStackOverflowError):
2268         * runtime/ExceptionHelpers.h:
2269         * runtime/JSGlobalObject.cpp:
2270         (JSC::JSGlobalObject::init):
2271         (JSC::JSGlobalObject::visitChildren):
2272         * runtime/JSGlobalObject.h:
2273         (JSC::JSGlobalObject::webAssemblyToJSCalleeStructure):
2274         * runtime/JSType.h:
2275         * runtime/Options.h: I've added a new option that controls
2276         whether or not we use fast TLS for the wasm context.
2277         * runtime/VM.cpp:
2278         (JSC::VM::VM):
2279         * runtime/VM.h:
2280         * wasm/WasmB3IRGenerator.cpp:
2281         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
2282         * wasm/WasmBinding.cpp:
2283         (JSC::Wasm::wasmToWasm):
2284         * wasm/WasmContext.cpp:
2285         (JSC::Wasm::loadContext):
2286         (JSC::Wasm::storeContext):
2287         * wasm/WasmContext.h:
2288         (JSC::Wasm::useFastTLSForContext):
2289         * wasm/WasmExceptionType.h:
2290         * wasm/WasmMemoryInformation.h:
2291         (JSC::Wasm::PinnedRegisterInfo::toSave):
2292         * wasm/WasmThunks.cpp:
2293         (JSC::Wasm::throwExceptionFromWasmThunkGenerator):
2294         (JSC::Wasm::throwStackOverflowFromWasmThunkGenerator):
2295         (JSC::Wasm::Thunks::stub):
2296         * wasm/WasmThunks.h:
2297         * wasm/js/JSWebAssemblyInstance.h:
2298         (JSC::JSWebAssemblyInstance::offsetOfCachedStackLimit):
2299         (JSC::JSWebAssemblyInstance::cachedStackLimit):
2300         (JSC::JSWebAssemblyInstance::setCachedStackLimit):
2301         * wasm/js/JSWebAssemblyModule.cpp:
2302         (JSC::JSWebAssemblyModule::finishCreation):
2303         * wasm/js/WebAssemblyFunction.cpp:
2304         (JSC::callWebAssemblyFunction):
2305         * wasm/js/WebAssemblyToJSCallee.cpp: Make this a descendent of object.
2306         This is needed for correctness because we may call into JS,
2307         and then the first JS frame could stack overflow. When it stack
2308         overflows, it rolls back one frame to the wasm->js call stub with
2309         the wasm->js callee. It gets the lexical global object from this
2310         frame, meaning it gets the global object from the callee. Therefore,
2311         we must make it an object since all objects have global objects.
2312         (JSC::WebAssemblyToJSCallee::create):
2313         * wasm/js/WebAssemblyToJSCallee.h:
2314
2315 2017-05-18  Keith Miller  <keith_miller@apple.com>
2316
2317         WebAssembly API: test with neutered inputs
2318         https://bugs.webkit.org/show_bug.cgi?id=163899
2319
2320         Reviewed by JF Bastien.
2321
2322         Add tests to check that we properly throw a type error when
2323         we get a transferred ArrayBuffer. Also, we should make sure
2324         we cannot post message a wasm memory's ArrayBuffer.
2325
2326         * API/JSTypedArray.cpp:
2327         (JSObjectGetArrayBufferBytesPtr):
2328         * runtime/ArrayBuffer.cpp:
2329         (JSC::ArrayBuffer::makeShared):
2330         (JSC::ArrayBuffer::makeWasmMemory):
2331         (JSC::ArrayBuffer::transferTo):
2332         (JSC::ArrayBuffer::neuter):
2333         (JSC::ArrayBuffer::notifyIncommingReferencesOfTransfer):
2334         (JSC::errorMesasgeForTransfer):
2335         * runtime/ArrayBuffer.h:
2336         (JSC::ArrayBuffer::isLocked):
2337         (JSC::ArrayBuffer::isWasmMemory):
2338         * wasm/js/JSWebAssemblyMemory.cpp:
2339         (JSC::JSWebAssemblyMemory::buffer):
2340         (JSC::JSWebAssemblyMemory::grow):
2341
2342 2017-05-18  Joseph Pecoraro  <pecoraro@apple.com>
2343
2344         Remote Inspector: Be stricter about checking message types
2345         https://bugs.webkit.org/show_bug.cgi?id=172259
2346         <rdar://problem/32264839>
2347
2348         Reviewed by Brian Burg.
2349
2350         * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
2351         (Inspector::RemoteInspector::receivedSetupMessage):
2352         (Inspector::RemoteInspector::receivedDataMessage):
2353         (Inspector::RemoteInspector::receivedDidCloseMessage):
2354         (Inspector::RemoteInspector::receivedIndicateMessage):
2355         (Inspector::RemoteInspector::receivedConnectionDiedMessage):
2356         (Inspector::RemoteInspector::receivedAutomaticInspectionConfigurationMessage):
2357         (Inspector::RemoteInspector::receivedAutomaticInspectionRejectMessage):
2358         (Inspector::RemoteInspector::receivedAutomationSessionRequestMessage):
2359         * inspector/remote/cocoa/RemoteInspectorXPCConnection.mm:
2360         (Inspector::RemoteInspectorXPCConnection::deserializeMessage):
2361         (Inspector::RemoteInspectorXPCConnection::handleEvent):
2362         (Inspector::RemoteInspectorXPCConnection::sendMessage):
2363         Bail if we don't receive the expected types for message data.
2364
2365 2017-05-18  Filip Pizlo  <fpizlo@apple.com>
2366
2367         DFG inlining should be hardened for the no-result case
2368         https://bugs.webkit.org/show_bug.cgi?id=172290
2369
2370         Reviewed by Saam Barati.
2371
2372         Previously, if we were inlining a setter call, we might have a bad time because the setter's
2373         result register is the invalid VirtualRegister(), and much of the intrinsic handling code
2374         assumes that the result register is valid.
2375
2376         This doesn't usually cause problems because people don't usually point a setter at something
2377         that we recognize as an intrinsic.
2378
2379         * CMakeLists.txt:
2380         * JavaScriptCore.xcodeproj/project.pbxproj:
2381         * b3/air/AirAllocateRegistersAndStackByLinearScan.cpp: Fix a comment.
2382         * dfg/DFGByteCodeParser.cpp: Make RELEASE_ASSERT give accurate stacks. I was getting an absurd stack from the assert I added in DelayedSetLocal.
2383         (JSC::DFG::ByteCodeParser::DelayedSetLocal::DelayedSetLocal): Assert so we catch the problem sooner.
2384         (JSC::DFG::ByteCodeParser::handleIntrinsicCall): Fix the bug.
2385         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction): Fix the bug if constant internal functions were setter-inlineable (they ain't, because the bytecode parser doesn't fold GetSetter).
2386         * runtime/Intrinsic.cpp: Added. I needed this to debug.
2387         (JSC::intrinsicName):
2388         (WTF::printInternal):
2389         * runtime/Intrinsic.h:
2390
2391 2017-05-18  Commit Queue  <commit-queue@webkit.org>
2392
2393         Unreviewed, rolling out r217031, r217032, and r217037.
2394         https://bugs.webkit.org/show_bug.cgi?id=172293
2395
2396         cause linking errors in Windows (Requested by yusukesuzuki on
2397         #webkit).
2398
2399         Reverted changesets:
2400
2401         "[JSC][DFG][DOMJIT] Extend CheckDOM to CheckSubClass"
2402         https://bugs.webkit.org/show_bug.cgi?id=172098
2403         http://trac.webkit.org/changeset/217031
2404
2405         "Unreviewed, rebaseline for newly added ClassInfo"
2406         https://bugs.webkit.org/show_bug.cgi?id=172098
2407         http://trac.webkit.org/changeset/217032
2408
2409         "Unreviewed, fix debug and non-JIT build"
2410         https://bugs.webkit.org/show_bug.cgi?id=172098
2411         http://trac.webkit.org/changeset/217037
2412
2413 2017-05-17  Yusuke Suzuki  <utatane.tea@gmail.com>
2414
2415         Unreviewed, fix debug and non-JIT build
2416         https://bugs.webkit.org/show_bug.cgi?id=172098
2417
2418         * jsc.cpp:
2419         (WTF::DOMJITFunctionObject::checkSubClassPatchpoint):
2420
2421 2017-05-17  Yusuke Suzuki  <utatane.tea@gmail.com>
2422
2423         Unreviewed, rebaseline for newly added ClassInfo
2424         https://bugs.webkit.org/show_bug.cgi?id=172098
2425
2426         * wasm/js/WebAssemblyFunctionBase.cpp:
2427
2428 2017-05-16  Yusuke Suzuki  <utatane.tea@gmail.com>
2429
2430         [JSC][DFG][DOMJIT] Extend CheckDOM to CheckSubClass
2431         https://bugs.webkit.org/show_bug.cgi?id=172098
2432
2433         Reviewed by Saam Barati.
2434
2435         In this patch, we generalize CheckDOM to CheckSubClass.
2436         It can accept any ClassInfo and perform ClassInfo check
2437         in DFG / FTL. Now, we add a new function pointer to ClassInfo,
2438         checkSubClassPatchpoint. It can create DOMJIT patchpoint
2439         for that ClassInfo. It it natural that ClassInfo holds the
2440         way to emit DOMJIT::Patchpoint to perform CheckSubClass
2441         rather than having it in each DOMJIT getter / function
2442         signature annotation.
2443
2444         One problem is that it enlarges the size of ClassInfo.
2445         But this is the best place to put this function pointer.
2446         By doing so, we can add a patchpoint for CheckSubClass
2447         in an non-intrusive manner: WebCore can inject patchpoints
2448         without interactive JSC.
2449
2450         We still have a way to reduce the size of ClassInfo if
2451         we move ArrayBuffer related methods out to the other places.
2452
2453         This patch touches many files because we add a new function
2454         pointer to ClassInfo. But they are basically mechanical change.
2455
2456         * API/JSAPIWrapperObject.mm:
2457         * API/JSCallbackConstructor.cpp:
2458         * API/JSCallbackFunction.cpp:
2459         * API/JSCallbackObject.cpp:
2460         * API/ObjCCallbackFunction.mm:
2461         * CMakeLists.txt:
2462         * JavaScriptCore.xcodeproj/project.pbxproj:
2463         * bytecode/CodeBlock.cpp:
2464         * bytecode/DOMJITAccessCasePatchpointParams.h:
2465         (JSC::DOMJITAccessCasePatchpointParams::DOMJITAccessCasePatchpointParams):
2466         * bytecode/EvalCodeBlock.cpp:
2467         * bytecode/FunctionCodeBlock.cpp:
2468         * bytecode/GetterSetterAccessCase.cpp:
2469         (JSC::GetterSetterAccessCase::emitDOMJITGetter):
2470         * bytecode/ModuleProgramCodeBlock.cpp:
2471         * bytecode/ProgramCodeBlock.cpp:
2472         * bytecode/UnlinkedCodeBlock.cpp:
2473         * bytecode/UnlinkedEvalCodeBlock.cpp:
2474         * bytecode/UnlinkedFunctionCodeBlock.cpp:
2475         * bytecode/UnlinkedFunctionExecutable.cpp:
2476         * bytecode/UnlinkedModuleProgramCodeBlock.cpp:
2477         * bytecode/UnlinkedProgramCodeBlock.cpp:
2478         * debugger/DebuggerScope.cpp:
2479         * dfg/DFGAbstractInterpreterInlines.h:
2480         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2481         * dfg/DFGByteCodeParser.cpp:
2482         (JSC::DFG::ByteCodeParser::handleDOMJITGetter):
2483         * dfg/DFGClobberize.h:
2484         (JSC::DFG::clobberize):
2485         * dfg/DFGConstantFoldingPhase.cpp:
2486         (JSC::DFG::ConstantFoldingPhase::foldConstants):
2487         * dfg/DFGDOMJITPatchpointParams.h:
2488         (JSC::DFG::DOMJITPatchpointParams::DOMJITPatchpointParams):
2489         * dfg/DFGDoesGC.cpp:
2490         (JSC::DFG::doesGC):
2491         * dfg/DFGFixupPhase.cpp:
2492         (JSC::DFG::FixupPhase::fixupNode):
2493         (JSC::DFG::FixupPhase::attemptToMakeCallDOM):
2494         (JSC::DFG::FixupPhase::fixupCheckSubClass):
2495         (JSC::DFG::FixupPhase::fixupCheckDOM): Deleted.
2496         * dfg/DFGGraph.cpp:
2497         (JSC::DFG::Graph::dump):
2498         * dfg/DFGNode.h:
2499         (JSC::DFG::Node::hasClassInfo):
2500         (JSC::DFG::Node::classInfo):
2501         (JSC::DFG::Node::hasCheckDOMPatchpoint): Deleted.
2502         (JSC::DFG::Node::checkDOMPatchpoint): Deleted.
2503         * dfg/DFGNodeType.h:
2504         * dfg/DFGPredictionPropagationPhase.cpp:
2505         * dfg/DFGSafeToExecute.h:
2506         (JSC::DFG::safeToExecute):
2507         * dfg/DFGSpeculativeJIT.cpp:
2508         (JSC::DFG::SpeculativeJIT::compileCheckSubClass):
2509         (JSC::DFG::SpeculativeJIT::compileCheckDOM): Deleted.
2510         * dfg/DFGSpeculativeJIT.h:
2511         (JSC::DFG::SpeculativeJIT::vm):
2512         * dfg/DFGSpeculativeJIT32_64.cpp:
2513         (JSC::DFG::SpeculativeJIT::compile):
2514         In DFG, we rename CheckDOM to CheckSubClass. It just holds ClassInfo.
2515         And ClassInfo knows how to perform CheckSubClass efficiently.
2516         If ClassInfo does not have a way to perform CheckSubClass efficiently,
2517         we just perform jsDynamicCast thing in ASM.
2518         * dfg/DFGSpeculativeJIT64.cpp:
2519         (JSC::DFG::SpeculativeJIT::compile):
2520         * domjit/DOMJITGetterSetter.h:
2521         * domjit/DOMJITPatchpointParams.h:
2522         (JSC::DOMJIT::PatchpointParams::PatchpointParams):
2523         (JSC::DOMJIT::PatchpointParams::vm):
2524         * domjit/DOMJITSignature.h:
2525         (JSC::DOMJIT::Signature::Signature):
2526         (JSC::DOMJIT::Signature::checkDOM): Deleted.
2527         * ftl/FTLAbstractHeapRepository.h:
2528         * ftl/FTLCapabilities.cpp:
2529         (JSC::FTL::canCompile):
2530         * ftl/FTLDOMJITPatchpointParams.h:
2531         (JSC::FTL::DOMJITPatchpointParams::DOMJITPatchpointParams):
2532         * ftl/FTLLowerDFGToB3.cpp:
2533         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2534         (JSC::FTL::DFG::LowerDFGToB3::compileCheckSubClass):
2535         (JSC::FTL::DFG::LowerDFGToB3::compileCheckDOM): Deleted.
2536         * inspector/JSInjectedScriptHost.cpp:
2537         * inspector/JSInjectedScriptHostPrototype.cpp:
2538         * inspector/JSJavaScriptCallFrame.cpp:
2539         * inspector/JSJavaScriptCallFramePrototype.cpp:
2540         * jsc.cpp:
2541         (WTF::DOMJITNode::checkSubClassPatchpoint):
2542         (WTF::DOMJITFunctionObject::checkSubClassPatchpoint):
2543         (WTF::DOMJITFunctionObject::finishCreation):
2544         (WTF::DOMJITCheckSubClassObject::DOMJITCheckSubClassObject):
2545         (WTF::DOMJITCheckSubClassObject::createStructure):
2546         (WTF::DOMJITCheckSubClassObject::create):
2547         (WTF::DOMJITCheckSubClassObject::safeFunction):
2548         (WTF::DOMJITCheckSubClassObject::unsafeFunction):
2549         (WTF::DOMJITCheckSubClassObject::finishCreation):
2550         (GlobalObject::finishCreation):
2551         (functionCreateDOMJITCheckSubClassObject):
2552         (WTF::DOMJITNode::checkDOMJITNode): Deleted.
2553         (WTF::DOMJITFunctionObject::checkDOMJITNode): Deleted.
2554         * runtime/AbstractModuleRecord.cpp:
2555         * runtime/ArrayBufferNeuteringWatchpoint.cpp:
2556         * runtime/ArrayConstructor.cpp:
2557         * runtime/ArrayIteratorPrototype.cpp:
2558         * runtime/ArrayPrototype.cpp:
2559         * runtime/AsyncFunctionConstructor.cpp:
2560         * runtime/AsyncFunctionPrototype.cpp:
2561         * runtime/AtomicsObject.cpp:
2562         * runtime/BooleanConstructor.cpp:
2563         * runtime/BooleanObject.cpp:
2564         * runtime/BooleanPrototype.cpp:
2565         * runtime/ClassInfo.cpp: Copied from Source/JavaScriptCore/tools/JSDollarVM.cpp.
2566         (JSC::ClassInfo::dump):
2567         * runtime/ClassInfo.h:
2568         (JSC::ClassInfo::offsetOfParentClass):
2569         * runtime/ClonedArguments.cpp:
2570         * runtime/ConsoleObject.cpp:
2571         * runtime/CustomGetterSetter.cpp:
2572         * runtime/DateConstructor.cpp:
2573         * runtime/DateInstance.cpp:
2574         * runtime/DatePrototype.cpp:
2575         * runtime/DirectArguments.cpp:
2576         * runtime/Error.cpp:
2577         * runtime/ErrorConstructor.cpp:
2578         * runtime/ErrorInstance.cpp:
2579         * runtime/ErrorPrototype.cpp:
2580         * runtime/EvalExecutable.cpp:
2581         * runtime/Exception.cpp:
2582         * runtime/ExceptionHelpers.cpp:
2583         * runtime/ExecutableBase.cpp:
2584         * runtime/FunctionConstructor.cpp:
2585         * runtime/FunctionExecutable.cpp:
2586         * runtime/FunctionPrototype.cpp:
2587         * runtime/FunctionRareData.cpp:
2588         * runtime/GeneratorFunctionConstructor.cpp:
2589         * runtime/GeneratorFunctionPrototype.cpp:
2590         * runtime/GeneratorPrototype.cpp:
2591         * runtime/GetterSetter.cpp:
2592         * runtime/HashMapImpl.cpp:
2593         * runtime/HashMapImpl.h:
2594         * runtime/InferredType.cpp:
2595         (JSC::InferredType::create):
2596         * runtime/InferredTypeTable.cpp:
2597         * runtime/InferredValue.cpp:
2598         * runtime/InspectorInstrumentationObject.cpp:
2599         * runtime/InternalFunction.cpp:
2600         * runtime/IntlCollator.cpp:
2601         * runtime/IntlCollatorConstructor.cpp:
2602         * runtime/IntlCollatorPrototype.cpp:
2603         * runtime/IntlDateTimeFormat.cpp:
2604         * runtime/IntlDateTimeFormatConstructor.cpp:
2605         * runtime/IntlDateTimeFormatPrototype.cpp:
2606         * runtime/IntlNumberFormat.cpp:
2607         * runtime/IntlNumberFormatConstructor.cpp:
2608         * runtime/IntlNumberFormatPrototype.cpp:
2609         * runtime/IntlObject.cpp:
2610         * runtime/IteratorPrototype.cpp:
2611         * runtime/JSAPIValueWrapper.cpp:
2612         * runtime/JSArray.cpp:
2613         * runtime/JSArrayBuffer.cpp:
2614         * runtime/JSArrayBufferConstructor.cpp:
2615         * runtime/JSArrayBufferPrototype.cpp:
2616         * runtime/JSArrayBufferView.cpp:
2617         * runtime/JSAsyncFunction.cpp:
2618         * runtime/JSBoundFunction.cpp:
2619         * runtime/JSCallee.cpp:
2620         * runtime/JSCustomGetterSetterFunction.cpp:
2621         * runtime/JSDataView.cpp:
2622         * runtime/JSDataViewPrototype.cpp:
2623         * runtime/JSEnvironmentRecord.cpp:
2624         * runtime/JSFixedArray.cpp:
2625         * runtime/JSFunction.cpp:
2626         * runtime/JSGeneratorFunction.cpp:
2627         * runtime/JSGlobalLexicalEnvironment.cpp:
2628         * runtime/JSGlobalObject.cpp:
2629         * runtime/JSInternalPromise.cpp:
2630         * runtime/JSInternalPromiseConstructor.cpp:
2631         * runtime/JSInternalPromiseDeferred.cpp:
2632         * runtime/JSInternalPromisePrototype.cpp:
2633         * runtime/JSLexicalEnvironment.cpp:
2634         * runtime/JSMap.cpp:
2635         * runtime/JSMapIterator.cpp:
2636         * runtime/JSModuleEnvironment.cpp:
2637         * runtime/JSModuleLoader.cpp:
2638         * runtime/JSModuleNamespaceObject.cpp:
2639         * runtime/JSModuleRecord.cpp:
2640         * runtime/JSNativeStdFunction.cpp:
2641         * runtime/JSONObject.cpp:
2642         * runtime/JSObject.cpp:
2643         * runtime/JSPromise.cpp:
2644         * runtime/JSPromiseConstructor.cpp:
2645         * runtime/JSPromiseDeferred.cpp:
2646         * runtime/JSPromisePrototype.cpp:
2647         * runtime/JSPropertyNameEnumerator.cpp:
2648         * runtime/JSPropertyNameIterator.cpp:
2649         * runtime/JSProxy.cpp:
2650         * runtime/JSScriptFetcher.cpp:
2651         * runtime/JSSet.cpp:
2652         * runtime/JSSetIterator.cpp:
2653         * runtime/JSSourceCode.cpp:
2654         * runtime/JSString.cpp:
2655         * runtime/JSStringIterator.cpp:
2656         * runtime/JSSymbolTableObject.cpp:
2657         * runtime/JSTemplateRegistryKey.cpp:
2658         * runtime/JSTypedArrayConstructors.cpp:
2659         * runtime/JSTypedArrayPrototypes.cpp:
2660         * runtime/JSTypedArrayViewConstructor.cpp:
2661         * runtime/JSTypedArrays.cpp:
2662         * runtime/JSWeakMap.cpp:
2663         * runtime/JSWeakSet.cpp:
2664         * runtime/JSWithScope.cpp:
2665         * runtime/MapConstructor.cpp:
2666         * runtime/MapIteratorPrototype.cpp:
2667         * runtime/MapPrototype.cpp:
2668         * runtime/MathObject.cpp:
2669         * runtime/ModuleLoaderPrototype.cpp:
2670         * runtime/ModuleProgramExecutable.cpp:
2671         * runtime/NativeErrorConstructor.cpp:
2672         * runtime/NativeExecutable.cpp:
2673         * runtime/NativeStdFunctionCell.cpp:
2674         * runtime/NullGetterFunction.cpp:
2675         * runtime/NullSetterFunction.cpp:
2676         * runtime/NumberConstructor.cpp:
2677         * runtime/NumberObject.cpp:
2678         * runtime/NumberPrototype.cpp:
2679         * runtime/ObjectConstructor.cpp:
2680         * runtime/ObjectPrototype.cpp:
2681         * runtime/ProgramExecutable.cpp:
2682         * runtime/PropertyTable.cpp:
2683         * runtime/ProxyConstructor.cpp:
2684         * runtime/ProxyObject.cpp:
2685         * runtime/ProxyRevoke.cpp:
2686         * runtime/ReflectObject.cpp:
2687         * runtime/RegExp.cpp:
2688         * runtime/RegExpConstructor.cpp:
2689         * runtime/RegExpObject.cpp:
2690         * runtime/RegExpPrototype.cpp:
2691         * runtime/ScopedArguments.cpp:
2692         * runtime/ScopedArgumentsTable.cpp:
2693         * runtime/ScriptExecutable.cpp:
2694         * runtime/SetConstructor.cpp:
2695         * runtime/SetIteratorPrototype.cpp:
2696         * runtime/SetPrototype.cpp:
2697         * runtime/SparseArrayValueMap.cpp:
2698         * runtime/StrictEvalActivation.cpp:
2699         * runtime/StringConstructor.cpp:
2700         * runtime/StringIteratorPrototype.cpp:
2701         * runtime/StringObject.cpp:
2702         * runtime/StringPrototype.cpp:
2703         * runtime/Structure.cpp:
2704         * runtime/StructureChain.cpp:
2705         * runtime/StructureRareData.cpp:
2706         * runtime/Symbol.cpp:
2707         * runtime/SymbolConstructor.cpp:
2708         * runtime/SymbolObject.cpp:
2709         * runtime/SymbolPrototype.cpp:
2710         * runtime/SymbolTable.cpp:
2711         * runtime/WeakMapConstructor.cpp:
2712         * runtime/WeakMapData.cpp:
2713         * runtime/WeakMapPrototype.cpp:
2714         * runtime/WeakSetConstructor.cpp:
2715         * runtime/WeakSetPrototype.cpp:
2716         * testRegExp.cpp:
2717         * tools/JSDollarVM.cpp:
2718         * tools/JSDollarVMPrototype.cpp:
2719         * wasm/JSWebAssembly.cpp:
2720         * wasm/js/JSWebAssemblyCodeBlock.cpp:
2721         * wasm/js/JSWebAssemblyCompileError.cpp:
2722         * wasm/js/JSWebAssemblyInstance.cpp:
2723         * wasm/js/JSWebAssemblyLinkError.cpp:
2724         * wasm/js/JSWebAssemblyMemory.cpp:
2725         * wasm/js/JSWebAssemblyModule.cpp:
2726         * wasm/js/JSWebAssemblyRuntimeError.cpp:
2727         * wasm/js/JSWebAssemblyTable.cpp:
2728         * wasm/js/WebAssemblyCompileErrorConstructor.cpp:
2729         * wasm/js/WebAssemblyCompileErrorPrototype.cpp:
2730         * wasm/js/WebAssemblyFunction.cpp:
2731         * wasm/js/WebAssemblyInstanceConstructor.cpp:
2732         * wasm/js/WebAssemblyInstancePrototype.cpp:
2733         * wasm/js/WebAssemblyLinkErrorConstructor.cpp:
2734         * wasm/js/WebAssemblyLinkErrorPrototype.cpp:
2735         * wasm/js/WebAssemblyMemoryConstructor.cpp:
2736         * wasm/js/WebAssemblyMemoryPrototype.cpp:
2737         * wasm/js/WebAssemblyModuleConstructor.cpp:
2738         * wasm/js/WebAssemblyModulePrototype.cpp:
2739         * wasm/js/WebAssemblyModuleRecord.cpp:
2740         * wasm/js/WebAssemblyPrototype.cpp:
2741         * wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
2742         * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp:
2743         * wasm/js/WebAssemblyTableConstructor.cpp:
2744         * wasm/js/WebAssemblyTablePrototype.cpp:
2745         * wasm/js/WebAssemblyToJSCallee.cpp:
2746         * wasm/js/WebAssemblyWrapperFunction.cpp:
2747
2748 2017-05-17  Saam Barati  <sbarati@apple.com>
2749
2750         We don't do context switches for Wasm->Wasm call indirect
2751         https://bugs.webkit.org/show_bug.cgi?id=172188
2752         <rdar://problem/32231828>
2753
2754         Reviewed by Keith Miller.
2755
2756         We did not do a context switch when doing an indirect call.
2757         This is clearly wrong, since the thing we're making an indirect
2758         call to could be from another instance. This patch fixes this
2759         oversight by doing a very simple context switch. I've also opened
2760         a bug to make indirect calls fast: https://bugs.webkit.org/show_bug.cgi?id=172197
2761         since this patch adds yet another branch to the indirect call path.
2762         I've also added tests that either throw or crash before this change.
2763
2764         * CMakeLists.txt:
2765         * JavaScriptCore.xcodeproj/project.pbxproj:
2766         * wasm/WasmB3IRGenerator.cpp:
2767         * wasm/js/JSWebAssemblyTable.h:
2768         (JSC::JSWebAssemblyTable::offsetOfJSFunctions):
2769         * wasm/js/WebAssemblyFunction.cpp:
2770         (JSC::WebAssemblyFunction::visitChildren):
2771         (JSC::WebAssemblyFunction::finishCreation): Deleted.
2772         * wasm/js/WebAssemblyFunction.h:
2773         (JSC::WebAssemblyFunction::instance): Deleted.
2774         (JSC::WebAssemblyFunction::offsetOfInstance): Deleted.
2775         * wasm/js/WebAssemblyFunctionBase.cpp: Added.
2776         (JSC::WebAssemblyFunctionBase::WebAssemblyFunctionBase):
2777         (JSC::WebAssemblyFunctionBase::visitChildren):
2778         (JSC::WebAssemblyFunctionBase::finishCreation):
2779         * wasm/js/WebAssemblyFunctionBase.h: Added.
2780         (JSC::WebAssemblyFunctionBase::instance):
2781         (JSC::WebAssemblyFunctionBase::offsetOfInstance):
2782         * wasm/js/WebAssemblyModuleRecord.cpp:
2783         (JSC::WebAssemblyModuleRecord::link):
2784         (JSC::WebAssemblyModuleRecord::evaluate):
2785         * wasm/js/WebAssemblyWrapperFunction.cpp:
2786         (JSC::WebAssemblyWrapperFunction::create):
2787         (JSC::WebAssemblyWrapperFunction::finishCreation):
2788         (JSC::WebAssemblyWrapperFunction::visitChildren):
2789         * wasm/js/WebAssemblyWrapperFunction.h:
2790
2791 2017-05-17  Filip Pizlo  <fpizlo@apple.com>
2792
2793         JSC: Incorrect LoadVarargs handling in ArgumentsEliminationPhase::transform
2794         https://bugs.webkit.org/show_bug.cgi?id=172208
2795
2796         Reviewed by Saam Barati.
2797
2798         * dfg/DFGArgumentsEliminationPhase.cpp:
2799
2800 2017-05-17  Don Olmstead  <don.olmstead@am.sony.com>
2801
2802         [Win] Support $vm.getpid()
2803         https://bugs.webkit.org/show_bug.cgi?id=172248
2804
2805         Reviewed by Mark Lam.
2806
2807         * tools/JSDollarVMPrototype.cpp:
2808         (JSC::functionGetPID):
2809         (JSC::JSDollarVMPrototype::finishCreation):
2810
2811 2017-05-17  Michael Saboff  <msaboff@apple.com>
2812
2813         [iOS] The Garbage Collector shouldn't rely on the bmalloc scavenger for up to date memory footprint info
2814         https://bugs.webkit.org/show_bug.cgi?id=172186
2815
2816         Reviewed by Geoffrey Garen.
2817
2818         The calls to bmalloc::api::memoryFootprint() and ::percentAvailableMemoryInUse() now call
2819         the OS to get up to date values.  In overCriticalMemoryThreshold(), we get the current value every
2820         100th call and use a cached value the rest of the time.  When colleciton is done, we start with
2821         a new overCriticalMemoryThreshold value for the next cycle.
2822
2823         The choice of 1 out of 100 calls was validated by using JetStream and verifying that it didn't impact
2824         performance and still provides timely memory footprint data.  With additional debug logging, I
2825         determined that we call overCriticalMemoryThreshold() over 20,000 times/second running JetStream.
2826         Other logging showed that there were over 1700 calls to overCriticalMemoryThreshold() on average per
2827         GC cycle.  Dividing both of these numbers by 100 seems reasonable.
2828
2829         * heap/Heap.cpp:
2830         (JSC::Heap::overCriticalMemoryThreshold):
2831         (JSC::Heap::updateAllocationLimits):
2832         (JSC::Heap::shouldDoFullCollection):
2833         * heap/Heap.h:
2834
2835 2017-05-17  Saam Barati  <sbarati@apple.com>
2836
2837         PinnedRegisters should be better modeled in IRC/Briggs
2838         https://bugs.webkit.org/show_bug.cgi?id=171955
2839
2840         Reviewed by Filip Pizlo.
2841
2842         This patch fixes a bug in Briggs/IRC with respect to pinned registers.
2843         Pinned registers were not part of the assignable register file in IRC/Briggs,
2844         and this would lead to an asymmetry because they were modeled in the
2845         interference graph. The bug is that we use registerCount() to move various
2846         Tmps between various lists in the different allocators, and if a Tmp
2847         interfered with a pinned register (usually via a Patchpoint's clobbered set),
2848         we'd have an interference edge modeled in the degree for that Tmp, but the registerCount()
2849         would make us think that this particular Tmp is not assignable. This would
2850         lead us to fail to color a colorable graph. Specifically, this happened in
2851         our various patchpoint tests that stress the register allocator by forcing
2852         the entire register file into arguments for the patchpoint and then doing
2853         interesting things with the result, arguments, etc.
2854
2855         This patch fixes the bug by coming up with an more natural way to model pinned
2856         registers. Pinned registers are now part of the register file. However,
2857         pinned registers are live at every point in the program (this is a defining
2858         property of a pinned register). In practice, this means that the only Tmps
2859         that can be assigned to pinned registers are ones that are coalescing
2860         candidates. This means the program has some number of defs for a Tmp T like:
2861         MoveType pinnedReg, T
2862
2863         Note, if any other defs for T happen, like:
2864         Add32, t1, t2, T
2865         T will have an interference edge with pinnedReg, since pinnedReg is live
2866         at every point in the program. Modeling pinned registers this way allows
2867         IRC/Briggs to have no special casing for them. It treats it like any other
2868         precolored Tmp. This allows us to do coalescing, biased coloring, etc, which
2869         could all lead to a Tmp being assigned to a pinned register.
2870
2871         Interestingly, we used to have special handling for the frame pointer
2872         register, which in many ways, acts like a pinned register, since FP is
2873         always live, and we wanted it to take place in coalescing. The allocator
2874         had a side-table interference graph with FP. Interestingly, we didn't even
2875         handle this properly everywhere since we could rely on a patchpoint never
2876         claiming to clobber FP (this would be illegal). So the code only handled
2877         the pseudo-pinned register properties of FP in various places. This patch
2878         drops this special casing and pins FP since all pinned registers can take
2879         part in coalescing.
2880
2881         * b3/B3PatchpointSpecial.h:
2882         * b3/B3Procedure.cpp:
2883         (JSC::B3::Procedure::mutableGPRs):
2884         (JSC::B3::Procedure::mutableFPRs):
2885         * b3/B3Procedure.h:
2886         * b3/air/AirAllocateRegistersByGraphColoring.cpp:
2887         * b3/air/AirCode.cpp:
2888         (JSC::B3::Air::Code::Code):
2889         (JSC::B3::Air::Code::pinRegister):
2890         (JSC::B3::Air::Code::mutableGPRs):
2891         (JSC::B3::Air::Code::mutableFPRs):
2892         * b3/air/AirCode.h:
2893         (JSC::B3::Air::Code::pinnedRegisters):
2894         * b3/air/AirSpecial.h:
2895         * b3/air/testair.cpp:
2896         * b3/testb3.cpp:
2897         (JSC::B3::testSimplePatchpointWithOuputClobbersGPArgs):
2898         (JSC::B3::testSpillDefSmallerThanUse):
2899         (JSC::B3::testLateRegister):
2900         (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled):
2901         (JSC::B3::testTerminalPatchpointThatNeedsToBeSpilled2):
2902         (JSC::B3::testMoveConstants):
2903
2904 2017-05-16  Yusuke Suzuki  <utatane.tea@gmail.com>
2905
2906         [DFG] Constant Folding Phase should convert MakeRope("", String) => Identity(String)
2907         https://bugs.webkit.org/show_bug.cgi?id=172115
2908
2909         Reviewed by Saam Barati.
2910
2911         In Fixup phase, we attempt to fold MakeRope to Identity (or reduce arguments) by dropping
2912         empty strings. However, when we are in Fixup phase, we do not have much information about
2913         constant values.
2914
2915         In ARES-6 Babylon, we find that we can constant-fold MakeRope by using constants figured
2916         out by CFA. Without it, Babylon repeatedly produces rope strings. To fix this, we introduce
2917         MakeRope handling in constant folding phase.
2918
2919         It shows 7.5% performance improvement in ARES-6 Babylon steadyState.
2920
2921             Before:
2922
2923             firstIteration:     50.02 +- 14.56 ms
2924             averageWorstCase:   26.52 +- 4.52 ms
2925             steadyState:        8.15 +- 0.23 ms
2926
2927             After:
2928
2929             firstIteration:     49.08 +- 12.90 ms
2930             averageWorstCase:   25.16 +- 3.82 ms
2931             steadyState:        7.58 +- 0.21 ms
2932
2933         * dfg/DFGAbstractInterpreterInlines.h:
2934         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2935         * dfg/DFGConstantFoldingPhase.cpp:
2936         (JSC::DFG::ConstantFoldingPhase::foldConstants):
2937
2938 2017-05-16  Yusuke Suzuki  <utatane.tea@gmail.com>
2939
2940         Unreviewed, add Objective C files to CMake Mac port
2941         https://bugs.webkit.org/show_bug.cgi?id=172103
2942
2943         * shell/PlatformMac.cmake: Added.
2944
2945 2017-05-16  JF Bastien  <jfbastien@apple.com>
2946
2947         WebAssembly: enforce size limits
2948         https://bugs.webkit.org/show_bug.cgi?id=165833
2949         <rdar://problem/29760219>
2950
2951         Reviewed by Keith Miller.
2952
2953         Use the same limits as V8.
2954
2955         * JavaScriptCore.xcodeproj/project.pbxproj:
2956         * wasm/WasmLimits.h: Added.
2957         * wasm/WasmModuleParser.cpp:
2958         * wasm/WasmParser.h:
2959         (JSC::Wasm::Parser<SuccessType>::consumeUTF8String):
2960
2961 2017-05-15  Yusuke Suzuki  <utatane.tea@gmail.com>
2962
2963         [JSC] Build testapi in non Apple ports
2964         https://bugs.webkit.org/show_bug.cgi?id=172103
2965
2966         Reviewed by Filip Pizlo.
2967
2968         This patch makes JSC testapi buildable in non-Apple ports.
2969         We isolate CF related tests in testapi.c. If we do not use
2970         CF, we include JavaScript.h instead of JavaScriptCore.h.
2971
2972         By running the testapi in Linux, we found that contraints
2973         test have a bug: If constraint marker runs after WeakRefs
2974         are destroyed, it accesses destroyed WeakRef. This patch
2975         also fixes it.
2976
2977         * API/tests/CurrentThisInsideBlockGetterTest.h:
2978         * API/tests/CustomGlobalObjectClassTest.c:
2979         * API/tests/ExecutionTimeLimitTest.cpp:
2980         * API/tests/FunctionOverridesTest.cpp:
2981         * API/tests/GlobalContextWithFinalizerTest.cpp:
2982         * API/tests/JSObjectGetProxyTargetTest.cpp:
2983         * API/tests/MultithreadedMultiVMExecutionTest.cpp:
2984         * API/tests/PingPongStackOverflowTest.cpp:
2985         * API/tests/TypedArrayCTest.cpp:
2986         * API/tests/testapi.c:
2987         (assertEqualsAsCharactersPtr):
2988         (markingConstraint):
2989         (testMarkingConstraintsAndHeapFinalizers):
2990         (testCFStrings):
2991         (main):
2992         * shell/CMakeLists.txt:
2993
2994 2017-05-16  JF Bastien  <jfbastien@apple.com>
2995
2996         WebAssembly: report Memory usage to GC
2997         https://bugs.webkit.org/show_bug.cgi?id=170690
2998         <rdar://problem/31965310>
2999
3000         Reviewed by Keith Miller.
3001
3002         * wasm/js/JSWebAssemblyMemory.cpp:
3003         (JSC::JSWebAssemblyMemory::grow):
3004         (JSC::JSWebAssemblyMemory::finishCreation):
3005         (JSC::JSWebAssemblyMemory::visitChildren):
3006
3007 2017-05-16  JF Bastien  <jfbastien@apple.com>
3008
3009         WebAssembly: validate load / store alignment
3010         https://bugs.webkit.org/show_bug.cgi?id=168836
3011         <rdar://problem/31965349>
3012
3013         Reviewed by Keith Miller.
3014
3015         * wasm/WasmFunctionParser.h: check the alignment
3016         * wasm/generateWasm.py: generate the log2 alignment helper
3017         (Wasm):
3018         (isSimple):
3019         (memoryLog2Alignment):
3020         * wasm/generateWasmOpsHeader.py:
3021         (memoryLog2AlignmentGenerator):
3022         * wasm/wasm.json: fix formatting
3023
3024 2017-05-15  Mark Lam  <mark.lam@apple.com>
3025
3026         Rolling out r214038 and r213697: Crashes when using computed properties with rest destructuring and object spread.
3027         https://bugs.webkit.org/show_bug.cgi?id=172147
3028
3029         Rubber-stamped by Saam Barati.
3030
3031         I rolled out every thing in those 2 patches except for the change to make
3032         CodeBlock::finishCreation() return a bool plus its clients that depend on this.
3033         I made this exception because r214931 relies on this change, and this part of
3034         the change looks correct.
3035
3036         * builtins/BuiltinNames.h:
3037         * builtins/GlobalOperations.js:
3038         (globalPrivate.speciesConstructor):
3039         (globalPrivate.copyDataProperties): Deleted.
3040         * bytecode/CodeBlock.cpp:
3041         (JSC::CodeBlock::finishCreation):
3042         (JSC::CodeBlock::setConstantIdentifierSetRegisters): Deleted.
3043         * bytecode/CodeBlock.h:
3044         * bytecode/UnlinkedCodeBlock.h:
3045         (JSC::UnlinkedCodeBlock::addBitVector):
3046         (JSC::UnlinkedCodeBlock::constantRegisters):
3047         (JSC::UnlinkedCodeBlock::addSetConstant): Deleted.
3048         (JSC::UnlinkedCodeBlock::constantIdentifierSets): Deleted.
3049         * bytecompiler/BytecodeGenerator.cpp:
3050         * bytecompiler/BytecodeGenerator.h:
3051         * bytecompiler/NodesCodegen.cpp:
3052         (JSC::PropertyListNode::emitBytecode):
3053         (JSC::ObjectPatternNode::bindValue):
3054         (JSC::ObjectSpreadExpressionNode::emitBytecode): Deleted.
3055         * parser/ASTBuilder.h:
3056         (JSC::ASTBuilder::createProperty):
3057         (JSC::ASTBuilder::appendObjectPatternEntry):
3058         (JSC::ASTBuilder::createObjectSpreadExpression): Deleted.
3059         (JSC::ASTBuilder::appendObjectPatternRestEntry): Deleted.
3060         (JSC::ASTBuilder::setContainsObjectRestElement): Deleted.
3061         * parser/NodeConstructors.h:
3062         (JSC::PropertyNode::PropertyNode):
3063         (JSC::SpreadExpressionNode::SpreadExpressionNode):
3064         (JSC::ObjectSpreadExpressionNode::ObjectSpreadExpressionNode): Deleted.
3065         * parser/Nodes.h:
3066         (JSC::ObjectPatternNode::appendEntry):
3067         (JSC::ObjectSpreadExpressionNode::expression): Deleted.
3068         (JSC::ObjectPatternNode::setContainsRestElement): Deleted.
3069         * parser/Parser.cpp:
3070         (JSC::Parser<LexerType>::parseDestructuringPattern):
3071         (JSC::Parser<LexerType>::parseProperty):
3072         * parser/SyntaxChecker.h:
3073         (JSC::SyntaxChecker::createSpreadExpression):
3074         (JSC::SyntaxChecker::createProperty):
3075         (JSC::SyntaxChecker::operatorStackPop):
3076         (JSC::SyntaxChecker::createObjectSpreadExpression): Deleted.
3077         * runtime/ObjectConstructor.cpp:
3078         (JSC::ObjectConstructor::finishCreation):
3079         * runtime/SetPrototype.cpp:
3080         (JSC::SetPrototype::finishCreation):
3081
3082 2017-05-15  David Kilzer  <ddkilzer@apple.com>
3083
3084         JSEnvironmentRecord::allocationSizeForScopeSize() and offsetOfVariable(ScopeOffset) should used checked arithmetic
3085         <https://webkit.org/b/172134>
3086
3087         Reviewed by Saam Barati.
3088
3089         * runtime/JSEnvironmentRecord.h:
3090         (JSC::JSEnvironmentRecord::offsetOfVariable): Change to return
3091         size_t and use checked arithmetic.
3092         (JSC::JSEnvironmentRecord::allocationSizeForScopeSize): Change
3093         to use checked arithmetic.
3094
3095 2017-05-15  Mark Lam  <mark.lam@apple.com>
3096
3097         WorkerRunLoop::Task::performTask() should check !scriptController->isTerminatingExecution().
3098         https://bugs.webkit.org/show_bug.cgi?id=171775
3099         <rdar://problem/30975761>
3100
3101         Reviewed by Filip Pizlo.
3102
3103         Increased the number of frames captured in VM::nativeStackTraceOfLastThrow()
3104         from 25 to 100.  From experience, I found that 25 is sometimes not sufficient
3105         for our debugging needs.
3106
3107         Also added VM::throwingThread() to track which thread an exception was thrown in.
3108         This may be useful if the client is entering the VM from different threads.
3109
3110         * runtime/ExceptionScope.cpp:
3111         (JSC::ExceptionScope::unexpectedExceptionMessage):
3112         * runtime/ExceptionScope.h:
3113         (JSC::ExceptionScope::exception):
3114         (JSC::ExceptionScope::unexpectedExceptionMessage):
3115         * runtime/Options.h:
3116         - Added the unexpectedExceptionStackTraceLimit option.
3117         * runtime/VM.cpp:
3118         (JSC::VM::throwException):
3119         * runtime/VM.h:
3120         (JSC::VM::throwingThread):
3121         (JSC::VM::clearException):
3122
3123 2017-05-13  David Kilzer  <ddkilzer@apple.com>
3124
3125         Unused lambda capture in JSContextGroupAddMarkingConstraint()
3126         <https://webkit.org/b/172084>
3127
3128         Reviewed by Saam Barati.
3129
3130         Fixes the following warning with newer clang:
3131
3132             Source/JavaScriptCore/API/JSMarkingConstraintPrivate.cpp:78:11: error: lambda capture 'vm' is not used [-Werror,-Wunused-lambda-capture]
3133                     [&vm, constraintCallback, userData]
3134                       ^
3135
3136         * API/JSMarkingConstraintPrivate.cpp:
3137         (JSContextGroupAddMarkingConstraint): Remove unused lambda
3138         capture for '&vm'.
3139
3140 2017-05-13  David Kilzer  <ddkilzer@apple.com>
3141
3142         [JSC] config.rb fails when checking some clang versions
3143         <https://webkit.org/b/172082>
3144
3145         Reviewed by Mark Lam.
3146
3147         * offlineasm/config.rb:
3148         - Add support for quad-dotted version of Apple clang (800.0.12.1).
3149         - Add support for checking open source clang version (5.0.0).
3150
3151 2017-05-13  Commit Queue  <commit-queue@webkit.org>
3152
3153         Unreviewed, rolling out r216808.
3154         https://bugs.webkit.org/show_bug.cgi?id=172075
3155
3156         caused lldb to hang when debugging (Requested by smfr on
3157         #webkit).
3158
3159         Reverted changeset:
3160
3161         "Use Mach exceptions instead of signals where possible"
3162         https://bugs.webkit.org/show_bug.cgi?id=171865
3163         http://trac.webkit.org/changeset/216808
3164
3165 2017-05-13  Commit Queue  <commit-queue@webkit.org>
3166
3167         Unreviewed, rolling out r216801.
3168         https://bugs.webkit.org/show_bug.cgi?id=172072
3169
3170         Many memory corruption crashes on worker threads (Requested by
3171         ap on #webkit).
3172
3173         Reverted changeset:
3174
3175         "WorkerRunLoop::Task::performTask() should check
3176         !scriptController->isTerminatingExecution()."
3177         https://bugs.webkit.org/show_bug.cgi?id=171775
3178         http://trac.webkit.org/changeset/216801
3179
3180 2017-05-12  Geoffrey Garen  <ggaren@apple.com>
3181
3182         [JSC] DFG::Node should not have its own allocator
3183         https://bugs.webkit.org/show_bug.cgi?id=160098
3184
3185         Reviewed by Saam Barati.
3186
3187         I just rebased the patch from <http://trac.webkit.org/changeset/203808>.
3188
3189         I ran Octane and JetStream locally on a MacBook Air and I wasn't able to
3190         reproduce a regression. Let's land this again and see what the bots say.
3191
3192         * JavaScriptCore.xcodeproj/project.pbxproj:
3193         * b3/B3SparseCollection.h:
3194         (JSC::B3::SparseCollection::packIndices):
3195         * dfg/DFGAllocator.h: Removed.
3196         * dfg/DFGDriver.cpp:
3197         (JSC::DFG::compileImpl):
3198         * dfg/DFGGraph.cpp:
3199         (JSC::DFG::Graph::Graph):
3200         (JSC::DFG::Graph::~Graph):
3201         (JSC::DFG::Graph::deleteNode):
3202         (JSC::DFG::Graph::packNodeIndices):
3203         (JSC::DFG::Graph::addNodeToMapByIndex): Deleted.
3204         * dfg/DFGGraph.h:
3205         (JSC::DFG::Graph::addNode):
3206         (JSC::DFG::Graph::maxNodeCount):
3207         (JSC::DFG::Graph::nodeAt):
3208         * dfg/DFGLongLivedState.cpp: Removed.
3209         * dfg/DFGLongLivedState.h: Removed.
3210         * dfg/DFGNode.h:
3211         * dfg/DFGNodeAllocator.h:
3212         * dfg/DFGPlan.cpp:
3213         (JSC::DFG::Plan::compileInThread):
3214         (JSC::DFG::Plan::compileInThreadImpl):
3215         * dfg/DFGPlan.h:
3216         * dfg/DFGWorklist.cpp:
3217         * runtime/VM.cpp:
3218         (JSC::VM::VM):
3219         * runtime/VM.h:
3220
3221 2017-05-12  Keith Miller  <keith_miller@apple.com>
3222
3223         Use Mach exceptions instead of signals where possible
3224         https://bugs.webkit.org/show_bug.cgi?id=171865
3225
3226         Reviewed by Mark Lam.
3227
3228         This patch adds some new JSC options. The first is an option that
3229         enables or disables web assembly tier up. The second controls
3230         whether or not we use mach exceptions (where available).
3231
3232         * API/tests/ExecutionTimeLimitTest.cpp:
3233         (dispatchTermitateCallback):
3234         (testExecutionTimeLimit):
3235         * runtime/JSLock.cpp:
3236         (JSC::JSLock::didAcquireLock):
3237         * runtime/Options.cpp:
3238         (JSC::overrideDefaults):
3239         (JSC::Options::initialize):
3240         * runtime/Options.h:
3241         * runtime/VMTraps.cpp:
3242         (JSC::SignalContext::SignalContext):
3243         (JSC::SignalContext::adjustPCToPointToTrappingInstruction):
3244         (JSC::installSignalHandler):
3245         (JSC::VMTraps::SignalSender::send):
3246         * tools/SigillCrashAnalyzer.cpp:
3247         (JSC::SignalContext::SignalContext):
3248         (JSC::SignalContext::dump):
3249         (JSC::installCrashHandler):
3250         * wasm/WasmBBQPlan.cpp:
3251         (JSC::Wasm::BBQPlan::compileFunctions):
3252         * wasm/WasmFaultSignalHandler.cpp:
3253         (JSC::Wasm::trapHandler):
3254         (JSC::Wasm::enableFastMemory):
3255         * wasm/WasmMachineThreads.cpp:
3256         (JSC::Wasm::resetInstructionCacheOnAllThreads):
3257
3258 2017-05-12  Mark Lam  <mark.lam@apple.com>
3259
3260         WorkerRunLoop::Task::performTask() should check !scriptController->isTerminatingExecution().
3261         https://bugs.webkit.org/show_bug.cgi?id=171775
3262         <rdar://problem/30975761>
3263
3264         Reviewed by Saam Barati.
3265
3266         Increased the number of frames captured in VM::nativeStackTraceOfLastThrow()
3267         from 25 to 100.  From experience, I found that 25 is sometimes not sufficient
3268         for our debugging needs.
3269
3270         Also added VM::throwingThread() to track which thread an exception was thrown in.
3271         This may be useful if the client is entering the VM from different threads.
3272
3273         * runtime/ExceptionScope.cpp:
3274         (JSC::ExceptionScope::unexpectedExceptionMessage):
3275         * runtime/ExceptionScope.h:
3276         (JSC::ExceptionScope::exception):
3277         (JSC::ExceptionScope::unexpectedExceptionMessage):
3278         * runtime/Options.h:
3279         - Added the unexpectedExceptionStackTraceLimit option.
3280         * runtime/VM.cpp:
3281         (JSC::VM::throwException):
3282         * runtime/VM.h:
3283         (JSC::VM::throwingThread):
3284         (JSC::VM::clearException):
3285
3286 2017-05-12  Daniel Bates  <dabates@apple.com>
3287
3288         Cleanup: Make QueueTaskToEventLoopFunctionPtr take JSGlobalObject&
3289         https://bugs.webkit.org/show_bug.cgi?id=172021
3290
3291         Reviewed by Mark Lam.
3292
3293         Change the function alias for QueueTaskToEventLoopFunctionPtr to take JSGlobalObject&
3294         instead of a const JSGlobalObject* as all implementations expect to be passed a non-
3295         const, non-null JSGlobalObject object.
3296
3297         * runtime/JSGlobalObject.cpp:
3298         (JSC::JSGlobalObject::queueMicrotask):
3299         * runtime/JSGlobalObject.h:
3300         * runtime/VM.cpp:
3301         (JSC::VM::queueMicrotask):
3302         * runtime/VM.h: Remove JS_EXPORT_PRIVATE annotation from queueMicrotask() as
3303         it is only called from JavaScriptCore code.
3304
3305 2017-05-12  Michael Saboff  <msaboff@apple.com>
3306
3307         [iOS] Use memory footprint to dynamically adjust behavior of allocators
3308         https://bugs.webkit.org/show_bug.cgi?id=171944
3309
3310         Reviewed by Filip Pizlo.
3311
3312         This change is iOS only.
3313
3314         Added the ability to react to when memory usage is critical.  This is defined as memory
3315         usage being above the newly added option criticalGCMemoryThreshold.  When we are in this
3316         critical state, all collections are Full and we limit the amount of memory we allocate
3317         between collections to 1/4th the memory above the critical threshold.
3318
3319         Changed the calculation of proportionalHeapSize to be based on process memory footprint
3320         and not how big the heap is.  Also, the values of Options::smallHeapRAMFraction and
3321         Options::mediumHeapRAMFraction are overriden so that most of the heap growth is happens
3322         using the more agressive Options::smallHeapGrowthFactor.
3323
3324         * heap/Heap.cpp:
3325         (JSC::Heap::Heap):
3326         (JSC::Heap::overCriticalMemoryThreshold):
3327         (JSC::Heap::shouldDoFullCollection):
3328         (JSC::Heap::collectIfNecessaryOrDefer):
3329         * heap/Heap.h:
3330         * runtime/Options.cpp:
3331         (JSC::overrideDefaults):
3332         (JSC::Options::initialize):
3333         * runtime/Options.h:
3334
3335 2017-05-11  Saam Barati  <sbarati@apple.com>
3336
3337         Computing optionalDefArgWidth in CheckSpecial should not consider Scratch roles
3338         https://bugs.webkit.org/show_bug.cgi?id=171962
3339
3340         Reviewed by Filip Pizlo.
3341
3342         The purpose of getting the result width is to get the width of
3343         the result of the arithmetic. It does not care about that the
3344         Check happens to define scratches.
3345
3346         * b3/B3CheckSpecial.cpp:
3347         (JSC::B3::CheckSpecial::forEachArg):
3348         * b3/testb3.cpp:
3349         (JSC::B3::testCheckMul):
3350         (JSC::B3::testCheckMulMemory):
3351         (JSC::B3::testCheckMul64):
3352         (JSC::B3::testCheckMulFold):
3353         (JSC::B3::testCheckMulFoldFail):
3354         (JSC::B3::testCheckMulArgumentAliasing64):
3355         (JSC::B3::testCheckMulArgumentAliasing32):
3356         (JSC::B3::testCheckMul64SShr):
3357
3358 2017-05-11  Saam Barati  <sbarati@apple.com>