Source/JavaScriptCore/ChangeLog

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