Source/JavaScriptCore/ChangeLog

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