Source/JavaScriptCore/ChangeLog

   1 2017-10-26  Michael Saboff  <msaboff@apple.com>
   2
   3         REGRESSION(r222601): We fail to properly backtrack into a sub pattern of a parenthesis with non-zero minimum
   4         https://bugs.webkit.org/show_bug.cgi?id=178890
   5
   6         Reviewed by Keith Miller.
   7
   8         We need to let a contained subpattern backtrack before declaring that the containing
   9         parenthesis doesn't match.  If the subpattern fails to match backtracking, then we
  10         can check to see if we trying to backtrack below the minimum match count.
  11
  12         * yarr/YarrInterpreter.cpp:
  13         (JSC::Yarr::Interpreter::backtrackParentheses):
  14
  15 2017-10-26  Mark Lam  <mark.lam@apple.com>
  16
  17         JSRopeString::RopeBuilder::append() should check for overflows.
  18         https://bugs.webkit.org/show_bug.cgi?id=178385
  19         <rdar://problem/35027468>
  20
  21         Reviewed by Saam Barati.
  22
  23         1. Made RopeString check for overflow like the Checked class does.
  24         2. Added a missing overflow check in objectProtoFuncToString().
  25
  26         * runtime/JSString.cpp:
  27         (JSC::JSRopeString::RopeBuilder<RecordOverflow>::expand):
  28         (JSC::JSRopeString::RopeBuilder::expand): Deleted.
  29         * runtime/JSString.h:
  30         * runtime/ObjectPrototype.cpp:
  31         (JSC::objectProtoFuncToString):
  32         * runtime/Operations.h:
  33         (JSC::jsStringFromRegisterArray):
  34         (JSC::jsStringFromArguments):
  35
  36 2017-10-26  JF Bastien  <jfbastien@apple.com>
  37
  38         WebAssembly: no VM / JS version of our implementation
  39         https://bugs.webkit.org/show_bug.cgi?id=177472
  40
  41         Reviewed by Michael Saboff.
  42
  43         This patch removes all appearances of "JS" and "VM" in the wasm
  44         directory. These now only appear in the wasm/js directory, which
  45         is only used in a JS embedding of wasm. It should therefore now be
  46         possible to create non-JS embeddings of wasm through JSC, though
  47         it'll still require:
  48
  49           - Mild codegen for wasm<->embedder calls;
  50           - A strategy for trap handling (no need for full unwind! Could kill).
  51           - Creation of the Wasm::* objects.
  52           - Calling convention handling to call the embedder.
  53           - Handling of multiple embedders (see #177475, this is optional).
  54
  55         Most of the patch consists in renaming JSWebAssemblyInstance to
  56         Instance, and removing temporary copies which I'd added to make
  57         this specific patch very simple.
  58
  59         * interpreter/CallFrame.cpp:
  60         (JSC::CallFrame::wasmAwareLexicalGlobalObject): this one place
  61         which needs to know about who "owns" the Wasm::Instance. In a JS
  62         embedding it's the JSWebAssemblyInstance.
  63         * wasm/WasmB3IRGenerator.cpp:
  64         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
  65         (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
  66         (JSC::Wasm::B3IRGenerator::addGrowMemory):
  67         (JSC::Wasm::B3IRGenerator::addCurrentMemory):
  68         (JSC::Wasm::B3IRGenerator::getGlobal):
  69         (JSC::Wasm::B3IRGenerator::setGlobal):
  70         (JSC::Wasm::B3IRGenerator::addCall):
  71         (JSC::Wasm::B3IRGenerator::addCallIndirect):
  72         * wasm/WasmBinding.cpp:
  73         (JSC::Wasm::wasmToWasm):
  74         * wasm/WasmContext.cpp:
  75         (JSC::Wasm::Context::load const):
  76         (JSC::Wasm::Context::store):
  77         * wasm/WasmContext.h:
  78         * wasm/WasmEmbedder.h:
  79         * wasm/WasmInstance.cpp:
  80         (JSC::Wasm::Instance::Instance):
  81         (JSC::Wasm::Instance::create):
  82         (JSC::Wasm::Instance::extraMemoryAllocated const):
  83         * wasm/WasmInstance.h: add an "owner", the Wasm::Context, move the
  84         "tail" import information from JSWebAssemblyInstance over to here.
  85         (JSC::Wasm::Instance::finalizeCreation):
  86         (JSC::Wasm::Instance::owner const):
  87         (JSC::Wasm::Instance::offsetOfOwner):
  88         (JSC::Wasm::Instance::context const):
  89         (JSC::Wasm::Instance::setMemory):
  90         (JSC::Wasm::Instance::setTable):
  91         (JSC::Wasm::Instance::offsetOfMemory):
  92         (JSC::Wasm::Instance::offsetOfGlobals):
  93         (JSC::Wasm::Instance::offsetOfTable):
  94         (JSC::Wasm::Instance::offsetOfTail):
  95         (JSC::Wasm::Instance::numImportFunctions const):
  96         (JSC::Wasm::Instance::importFunctionInfo):
  97         (JSC::Wasm::Instance::offsetOfTargetInstance):
  98         (JSC::Wasm::Instance::offsetOfWasmEntrypoint):
  99         (JSC::Wasm::Instance::offsetOfWasmToEmbedderStubExecutableAddress):
 100         (JSC::Wasm::Instance::offsetOfImportFunction):
 101         (JSC::Wasm::Instance::importFunction):
 102         (JSC::Wasm::Instance::allocationSize):
 103         (JSC::Wasm::Instance::create): Deleted.
 104         * wasm/WasmOMGPlan.cpp:
 105         (JSC::Wasm::OMGPlan::runForIndex):
 106         * wasm/WasmOMGPlan.h:
 107         * wasm/WasmTable.cpp:
 108         (JSC::Wasm::Table::Table):
 109         (JSC::Wasm::Table::setFunction):
 110         * wasm/WasmTable.h:
 111         * wasm/WasmThunks.cpp:
 112         (JSC::Wasm::throwExceptionFromWasmThunkGenerator):
 113         (JSC::Wasm::triggerOMGTierUpThunkGenerator):
 114         * wasm/js/JSToWasm.cpp:
 115         (JSC::Wasm::createJSToWasmWrapper):
 116         * wasm/js/JSWebAssemblyInstance.cpp: delete code that is now on Wasm::Instance
 117         (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance): The embedder
 118         decides what the import function is. Here we must properly
 119         placement-new it to what we've elected (and initialize it later).
 120         (JSC::JSWebAssemblyInstance::visitChildren):
 121         (JSC::JSWebAssemblyInstance::finalizeCreation):
 122         (JSC::JSWebAssemblyInstance::create):
 123         * wasm/js/JSWebAssemblyInstance.h: delete code that is now on Wasm::Instance
 124         (JSC::JSWebAssemblyInstance::instance):
 125         (JSC::JSWebAssemblyInstance::moduleNamespaceObject):
 126         (JSC::JSWebAssemblyInstance::setMemory):
 127         (JSC::JSWebAssemblyInstance::table):
 128         (JSC::JSWebAssemblyInstance::setTable):
 129         (JSC::JSWebAssemblyInstance::offsetOfInstance):
 130         (JSC::JSWebAssemblyInstance::offsetOfCallee):
 131         (JSC::JSWebAssemblyInstance::context const): Deleted.
 132         (JSC::JSWebAssemblyInstance::offsetOfTail): Deleted.
 133         (): Deleted.
 134         (JSC::JSWebAssemblyInstance::importFunctionInfo): Deleted.
 135         (JSC::JSWebAssemblyInstance::offsetOfTargetInstance): Deleted.
 136         (JSC::JSWebAssemblyInstance::offsetOfWasmEntrypoint): Deleted.
 137         (JSC::JSWebAssemblyInstance::offsetOfWasmToEmbedderStubExecutableAddress): Deleted.
 138         (JSC::JSWebAssemblyInstance::offsetOfImportFunction): Deleted.
 139         (JSC::JSWebAssemblyInstance::importFunction): Deleted.
 140         (JSC::JSWebAssemblyInstance::internalMemory): Deleted.
 141         (JSC::JSWebAssemblyInstance::wasmCodeBlock const): Deleted.
 142         (JSC::JSWebAssemblyInstance::offsetOfWasmTable): Deleted.
 143         (JSC::JSWebAssemblyInstance::offsetOfGlobals): Deleted.
 144         (JSC::JSWebAssemblyInstance::offsetOfCodeBlock): Deleted.
 145         (JSC::JSWebAssemblyInstance::offsetOfWasmCodeBlock): Deleted.
 146         (JSC::JSWebAssemblyInstance::offsetOfCachedStackLimit): Deleted.
 147         (JSC::JSWebAssemblyInstance::offsetOfWasmMemory): Deleted.
 148         (JSC::JSWebAssemblyInstance::offsetOfTopEntryFramePointer): Deleted.
 149         (JSC::JSWebAssemblyInstance::cachedStackLimit const): Deleted.
 150         (JSC::JSWebAssemblyInstance::setCachedStackLimit): Deleted.
 151         (JSC::JSWebAssemblyInstance::wasmMemory): Deleted.
 152         (JSC::JSWebAssemblyInstance::wasmModule): Deleted.
 153         (JSC::JSWebAssemblyInstance::allocationSize): Deleted.
 154         * wasm/js/JSWebAssemblyTable.cpp:
 155         (JSC::JSWebAssemblyTable::setFunction):
 156         * wasm/js/WasmToJS.cpp: One extra indirection to find the JSWebAssemblyInstance.
 157         (JSC::Wasm::materializeImportJSCell):
 158         (JSC::Wasm::handleBadI64Use):
 159         (JSC::Wasm::wasmToJS):
 160         (JSC::Wasm::wasmToJSException):
 161         * wasm/js/WasmToJS.h:
 162         * wasm/js/WebAssemblyFunction.cpp:
 163         (JSC::callWebAssemblyFunction):
 164         * wasm/js/WebAssemblyInstanceConstructor.cpp:
 165         (JSC::constructJSWebAssemblyInstance):
 166         * wasm/js/WebAssemblyModuleRecord.cpp:
 167         (JSC::WebAssemblyModuleRecord::link):
 168         (JSC::WebAssemblyModuleRecord::evaluate):
 169         * wasm/js/WebAssemblyPrototype.cpp:
 170         (JSC::instantiate):
 171         * wasm/js/WebAssemblyWrapperFunction.cpp:
 172         (JSC::WebAssemblyWrapperFunction::create):
 173
 174 2017-10-25  Devin Rousso  <webkit@devinrousso.com>
 175
 176         Web Inspector: provide a way to enable/disable event listeners
 177         https://bugs.webkit.org/show_bug.cgi?id=177451
 178         <rdar://problem/34994925>
 179
 180         Reviewed by Joseph Pecoraro.
 181
 182         * inspector/protocol/DOM.json:
 183         Add `setEventListenerDisabled` command that enables/disables a specific event listener
 184         during event dispatch. When a disabled event listener is fired, the listener's callback will
 185         not be called.
 186
 187 2017-10-25  Commit Queue  <commit-queue@webkit.org>
 188
 189         Unreviewed, rolling out r223691 and r223729.
 190         https://bugs.webkit.org/show_bug.cgi?id=178834
 191
 192         Broke Speedometer 2 React-Redux-TodoMVC test case (Requested
 193         by rniwa on #webkit).
 194
 195         Reverted changesets:
 196
 197         "Turn recursive tail calls into loops"
 198         https://bugs.webkit.org/show_bug.cgi?id=176601
 199         https://trac.webkit.org/changeset/223691
 200
 201         "REGRESSION(r223691): DFGByteCodeParser.cpp:1483:83: warning:
 202         comparison is always false due to limited range of data type
 203         [-Wtype-limits]"
 204         https://bugs.webkit.org/show_bug.cgi?id=178543
 205         https://trac.webkit.org/changeset/223729
 206
 207 2017-10-25  Michael Saboff  <msaboff@apple.com>
 208
 209         REGRESSION(r223937): Use of -fobjc-weak causes build failures with older compilers
 210         https://bugs.webkit.org/show_bug.cgi?id=178825
 211
 212         Reviewed by Mark Lam.
 213
 214         Enable ARC for ARM64_32.  This eliminate the need for setting CLANG_ENABLE_OBJC_WEAK.
 215
 216         * Configurations/ToolExecutable.xcconfig:
 217
 218 2017-10-25  Keith Miller  <keith_miller@apple.com>
 219
 220         Fix implicit cast of enum, which seems to break the windows build of unified sources.
 221         https://bugs.webkit.org/show_bug.cgi?id=178822
 222
 223         Reviewed by Saam Barati.
 224
 225         * bytecode/DFGExitProfile.h:
 226         (JSC::DFG::FrequentExitSite::hash const):
 227
 228 2017-10-24  Michael Saboff  <msaboff@apple.com>
 229
 230         Allow OjbC Weak References when building TestAPI
 231         https://bugs.webkit.org/show_bug.cgi?id=178748
 232
 233         Reviewed by Dan Bernstein.
 234
 235         Set TestAPI build flag Weak References in Manual Retain Release to true.
 236
 237         * JavaScriptCore.xcodeproj/project.pbxproj: Reverted.
 238         * Configurations/ToolExecutable.xcconfig: Changed the flag here instead.
 239
 240 2017-10-24  Eric Carlson  <eric.carlson@apple.com>
 241
 242         Web Inspector: Enable WebKit logging configuration and display
 243         https://bugs.webkit.org/show_bug.cgi?id=177027
 244         <rdar://problem/33964767>
 245
 246         Reviewed by Joseph Pecoraro.
 247
 248         * inspector/ConsoleMessage.cpp:
 249         (Inspector::messageSourceValue): Inspector::Protocol::Console::ConsoleMessage ->
 250             Inspector::Protocol::Console::ChannelSource.
 251         * inspector/agents/JSGlobalObjectConsoleAgent.cpp:
 252         (Inspector::JSGlobalObjectConsoleAgent::getLoggingChannels): There are no logging channels
 253             specific to a JSContext yet, so return an empty channel array.
 254         (Inspector::JSGlobalObjectConsoleAgent::setLoggingChannelLevel): No channels, return an error.
 255         * inspector/agents/JSGlobalObjectConsoleAgent.h:
 256
 257         * inspector/protocol/Console.json: Add ChannelSource, ChannelLevel, and Channel. Add getLoggingChannels
 258             and setLoggingChannelLevel.
 259
 260         * inspector/scripts/codegen/generator.py: Special case "webrtc"-> "WebRTC".
 261         * inspector/scripts/tests/generic/expected/enum-values.json-result:
 262         * inspector/scripts/tests/generic/expected/type-declaration-array-type.json-result:
 263         * inspector/scripts/tests/generic/expected/type-declaration-enum-type.json-result:
 264         * inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result:
 265         * inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result:
 266
 267         * runtime/ConsoleTypes.h: Add Media and WebRTC.
 268
 269 2017-10-24  Michael Saboff  <msaboff@apple.com>
 270
 271         Allow OjbC Weak References when building TestAPI
 272         https://bugs.webkit.org/show_bug.cgi?id=178748
 273
 274         Reviewed by Saam Barati.
 275
 276         Set TestAPI build flag Weak References in Manual Retain Release to true.
 277
 278         * JavaScriptCore.xcodeproj/project.pbxproj:
 279
 280 2017-10-24  Yusuke Suzuki  <utatane.tea@gmail.com>
 281
 282         [FTL] Support NewStringObject
 283         https://bugs.webkit.org/show_bug.cgi?id=178737
 284
 285         Reviewed by Saam Barati.
 286
 287         FTL should support NewStringObject and encourage use of NewStringObject in DFG pipeline.
 288         After this change, we can convert `CallObjectConstructor(String)` to `NewStringObject(String)`.
 289
 290         * ftl/FTLAbstractHeapRepository.h:
 291         * ftl/FTLCapabilities.cpp:
 292         (JSC::FTL::canCompile):
 293         * ftl/FTLLowerDFGToB3.cpp:
 294         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
 295         (JSC::FTL::DFG::LowerDFGToB3::compileNewStringObject):
 296
 297 2017-10-24  Guillaume Emont  <guijemont@igalia.com>
 298
 299         [mips] fix offsets of branches that have to go over a jump
 300         https://bugs.webkit.org/show_bug.cgi?id=153464
 301
 302         The jump() function creates 8 instructions, but the offsets of branches
 303         meant to go over them only account for 6. In most cases, this is not an
 304         issue as the last two instructions of jump() would be nops, but in the
 305         rarer case where the jump destination is in a different 256 MB segment,
 306         MIPSAssembler::linkWithOffset() will rewrite the code in a way in which
 307         the last 4 instructions would be a 2 instruction load (lui/ori) into
 308         $t9, a "j $t9" and then a nop. The wrong offset will mean that the
 309         previous branches meant to go over the whole jump will branch to the
 310         "j $t9" instruction, which would jump to whatever is currently in $t9
 311         (since lui/ori would not be executed).
 312
 313         Reviewed by Michael Catanzaro.
 314
 315         * assembler/MacroAssemblerMIPS.h:
 316         (JSC::MacroAssemblerMIPS::branchAdd32):
 317         (JSC::MacroAssemblerMIPS::branchMul32):
 318         (JSC::MacroAssemblerMIPS::branchSub32):
 319         Fix the offsets of branches meant to go over code generated by jump().
 320
 321 2017-10-24  JF Bastien  <jfbastien@apple.com>
 322
 323         WebAssembly: NFC renames of things that aren't JS-specific
 324         https://bugs.webkit.org/show_bug.cgi?id=178738
 325
 326         Reviewed by Saam Barati.
 327
 328         * wasm/WasmB3IRGenerator.cpp:
 329         (JSC::Wasm::parseAndCompile):
 330         * wasm/WasmB3IRGenerator.h:
 331         * wasm/WasmBBQPlan.cpp:
 332         (JSC::Wasm::BBQPlan::complete):
 333         * wasm/WasmCodeBlock.cpp:
 334         (JSC::Wasm::CodeBlock::CodeBlock):
 335         * wasm/WasmCodeBlock.h:
 336         (JSC::Wasm::CodeBlock::embedderEntrypointCalleeFromFunctionIndexSpace):
 337         (JSC::Wasm::CodeBlock::jsEntrypointCalleeFromFunctionIndexSpace): Deleted.
 338         * wasm/WasmFormat.h:
 339         * wasm/js/JSToWasm.cpp:
 340         (JSC::Wasm::createJSToWasmWrapper):
 341         * wasm/js/WebAssemblyModuleRecord.cpp:
 342         (JSC::WebAssemblyModuleRecord::link):
 343         (JSC::WebAssemblyModuleRecord::evaluate):
 344
 345 2017-10-24  Stephan Szabo  <stephan.szabo@sony.com>
 346
 347         [Win][JSCOnly] Make jsconly build testapi and dlls and copy dlls when running tests
 348         https://bugs.webkit.org/show_bug.cgi?id=177279
 349
 350         Reviewed by Yusuke Suzuki.
 351
 352         * shell/PlatformJSCOnly.cmake: Added.
 353
 354 2017-10-15  Yusuke Suzuki  <utatane.tea@gmail.com>
 355
 356         [JSC] modules can be visited more than once when resolving bindings through "star" exports as long as the exportName is different each time
 357         https://bugs.webkit.org/show_bug.cgi?id=178308
 358
 359         Reviewed by Mark Lam.
 360
 361         With the change of the spec[1], we now do not need to remember star resolution modules.
 362         We reflect this change to our implementation. Since this change is covered by test262,
 363         this patch improves the score of test262.
 364
 365         We also add logging to ResolveExport to debug it easily.
 366
 367         [1]: https://github.com/tc39/ecma262/commit/a865e778ff0fc60e26e3e1c589635103710766a1
 368
 369         * runtime/AbstractModuleRecord.cpp:
 370         (JSC::AbstractModuleRecord::ResolveQuery::dump const):
 371         (JSC::AbstractModuleRecord::resolveExportImpl):
 372
 373 2017-10-24  Yusuke Suzuki  <utatane.tea@gmail.com>
 374
 375         [JSC] Use emitDumbVirtualCall in 32bit JIT
 376         https://bugs.webkit.org/show_bug.cgi?id=178644
 377
 378         Reviewed by Mark Lam.
 379
 380         This patch aligns 32bit JIT op_call_eval slow case to 64bit version by using emitDumbVirtualCall.
 381
 382         * jit/JITCall32_64.cpp:
 383         (JSC::JIT::compileCallEvalSlowCase):
 384
 385 2017-10-22  Yusuke Suzuki  <utatane.tea@gmail.com>
 386
 387         [JSC] Drop ArityCheckData
 388         https://bugs.webkit.org/show_bug.cgi?id=178648
 389
 390         Reviewed by Mark Lam.
 391
 392         ArityCheckData is used to return a pair of `slotsToAdd` and `thunkToCall`.
 393         However, use of `thunkToCall` is removed in 64bit environment at r189575.
 394
 395         We remove `thunkToCall` and align 32bit implementation to 64bit implementation.
 396         Since we no longer need to have the above pair, we can remove ArityCheckData too.
 397
 398         * llint/LowLevelInterpreter32_64.asm:
 399         * llint/LowLevelInterpreter64.asm:
 400         * runtime/CommonSlowPaths.cpp:
 401         (JSC::SLOW_PATH_DECL):
 402         (JSC::setupArityCheckData): Deleted.
 403         * runtime/CommonSlowPaths.h:
 404         * runtime/VM.cpp:
 405         (JSC::VM::VM):
 406         * runtime/VM.h:
 407
 408 2017-10-23  Keith Miller  <keith_miller@apple.com>
 409
 410         Unreviewed, reland r223866
 411
 412         Didn't break the windows build...
 413
 414         Restored changeset:
 415
 416         "WebAssembly: topEntryFrame on Wasm::Instance"
 417         https://bugs.webkit.org/show_bug.cgi?id=178690
 418         https://trac.webkit.org/changeset/223866
 419
 420
 421 2017-10-23  Commit Queue  <commit-queue@webkit.org>
 422
 423         Unreviewed, rolling out r223866.
 424         https://bugs.webkit.org/show_bug.cgi?id=178699
 425
 426         Probably broke the windows build (Requested by keith_miller on
 427         #webkit).
 428
 429         Reverted changeset:
 430
 431         "WebAssembly: topEntryFrame on Wasm::Instance"
 432         https://bugs.webkit.org/show_bug.cgi?id=178690
 433         https://trac.webkit.org/changeset/223866
 434
 435 2017-10-23  Joseph Pecoraro  <pecoraro@apple.com>
 436
 437         Web Inspector: Remove unused Console.setMonitoringXHREnabled
 438         https://bugs.webkit.org/show_bug.cgi?id=178617
 439
 440         Reviewed by Sam Weinig.
 441
 442         * JavaScriptCore.xcodeproj/project.pbxproj:
 443         * Sources.txt:
 444         * inspector/agents/InspectorConsoleAgent.h:
 445         * inspector/agents/JSGlobalObjectConsoleAgent.cpp: Removed.
 446         * inspector/agents/JSGlobalObjectConsoleAgent.h: Removed.
 447         * inspector/protocol/Console.json:
 448         Removed files and method.
 449
 450         * inspector/JSGlobalObjectInspectorController.cpp:
 451         (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
 452         This can use the base ConsoleAgent now.
 453
 454 2017-10-23  JF Bastien  <jfbastien@apple.com>
 455
 456         WebAssembly: topEntryFrame on Wasm::Instance
 457         https://bugs.webkit.org/show_bug.cgi?id=178690
 458
 459         Reviewed by Saam Barati.
 460
 461         topEntryFrame is usually on VM, but for a no-VM WebAssembly we
 462         need to hold topEntryFrame elsewhere, and generated code cannot
 463         hard-code where topEntryFrame live. Do this at creation time of
 464         Wasm::Instance, and then generated code will just load from
 465         wherever Wasm::Instance was told topEntryFrame is. In a JavaScript
 466         embedding this is still from VM, so all of the unwinding machinery
 467         stays the same.
 468
 469         * dfg/DFGOSREntry.cpp:
 470         (JSC::DFG::prepareOSREntry):
 471         * dfg/DFGOSRExit.cpp:
 472         (JSC::DFG::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer):
 473         (JSC::DFG::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
 474         * ftl/FTLOSRExitCompiler.cpp:
 475         (JSC::FTL::compileStub):
 476         * interpreter/Interpreter.cpp:
 477         (JSC::UnwindFunctor::copyCalleeSavesToEntryFrameCalleeSavesBuffer const):
 478         * jit/AssemblyHelpers.cpp:
 479         (JSC::AssemblyHelpers::restoreCalleeSavesFromEntryFrameCalleeSavesBuffer):
 480         (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBufferImpl):
 481         * jit/AssemblyHelpers.h:
 482         (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBuffer):
 483         The default parameter was never non-defaulted from any of the
 484         callers. The new version calls the impl directly because it
 485         doesn't have VM and doesn't hard-code the address of
 486         topEntryFrame.
 487         * jit/RegisterSet.cpp:
 488         (JSC::RegisterSet::vmCalleeSaveRegisterOffsets): This was weird on
 489         VM because it's not really VM-specific.
 490         * jit/RegisterSet.h:
 491         * runtime/VM.cpp:
 492         (JSC::VM::getAllCalleeSaveRegisterOffsets): Deleted.
 493         * runtime/VM.h:
 494         (JSC::VM::getCTIStub):
 495         * wasm/WasmB3IRGenerator.cpp:
 496         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
 497         (JSC::Wasm::B3IRGenerator::addCall):
 498         (JSC::Wasm::B3IRGenerator::addCallIndirect):
 499         * wasm/WasmInstance.cpp:
 500         (JSC::Wasm::Instance::Instance):
 501         * wasm/WasmInstance.h: topEntryFramePointer will eventually live
 502         here for real. Right now it's mirrored in JSWebAssemblyInstance
 503         because that's the acting Context.
 504         (JSC::Wasm::Instance::create):
 505         (JSC::Wasm::Instance::offsetOfTopEntryFramePointer):
 506         * wasm/WasmThunks.cpp:
 507         (JSC::Wasm::throwExceptionFromWasmThunkGenerator):
 508         * wasm/js/JSWebAssemblyInstance.cpp:
 509         (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
 510         * wasm/js/JSWebAssemblyInstance.h: Mirror Wasm::Instance temporarily.
 511         (JSC::JSWebAssemblyInstance::offsetOfCallee):
 512         (JSC::JSWebAssemblyInstance::offsetOfTopEntryFramePointer):
 513         (JSC::JSWebAssemblyInstance::offsetOfVM): Deleted.
 514         * wasm/js/WebAssemblyInstanceConstructor.cpp:
 515         (JSC::constructJSWebAssemblyInstance):
 516         * wasm/js/WebAssemblyPrototype.cpp:
 517         (JSC::instantiate):
 518
 519 2017-10-23  Joseph Pecoraro  <pecoraro@apple.com>
 520
 521         Web Inspector: Please support HAR Export for network traffic
 522         https://bugs.webkit.org/show_bug.cgi?id=146692
 523         <rdar://problem/7463672>
 524
 525         Reviewed by Brian Burg.
 526
 527         * inspector/protocol/Network.json:
 528         Add a walltime to each send request.
 529
 530 2017-10-23  Matt Lewis  <jlewis3@apple.com>
 531
 532         Unreviewed, rolling out r223820.
 533
 534         This caused a build break on Windows.
 535
 536         Reverted changeset:
 537
 538         "Web Inspector: Remove unused Console.setMonitoringXHREnabled"
 539         https://bugs.webkit.org/show_bug.cgi?id=178617
 540         https://trac.webkit.org/changeset/223820
 541
 542 2017-10-23  Yusuke Suzuki  <utatane.tea@gmail.com>
 543
 544         [JSC] Use fastJoin in Array#toString
 545         https://bugs.webkit.org/show_bug.cgi?id=178062
 546
 547         Reviewed by Darin Adler.
 548
 549         Array#toString()'s fast path uses original join operation.
 550         But this should use fastJoin if possible.
 551         This patch adds a fast path using fastJoin in Array#toString.
 552         And we also extend fastJoin to perform fast joining for int32
 553         arrays.
 554
 555                                              baseline                  patched
 556
 557         double-array-to-string          126.6157+-5.8625     ^    103.7343+-4.4968        ^ definitely 1.2206x faster
 558         int32-array-to-string            64.7792+-2.6524           61.2390+-2.1749          might be 1.0578x faster
 559         contiguous-array-to-string       62.6224+-2.6388     ^     56.9899+-2.0852        ^ definitely 1.0988x faster
 560
 561
 562         * runtime/ArrayPrototype.cpp:
 563         (JSC::fastJoin):
 564         (JSC::arrayProtoFuncToString):
 565         (JSC::arrayProtoFuncToLocaleString):
 566         * runtime/JSStringJoiner.h:
 567         (JSC::JSStringJoiner::appendWithoutSideEffects):
 568         (JSC::JSStringJoiner::appendInt32):
 569         (JSC::JSStringJoiner::appendDouble):
 570
 571 2017-10-22  Zan Dobersek  <zdobersek@igalia.com>
 572
 573         [JSC] Remove !(OS(LINUX) && CPU(ARM64)) guards in RegisterState.h
 574         https://bugs.webkit.org/show_bug.cgi?id=178452
 575
 576         Reviewed by Yusuke Suzuki.
 577
 578         * heap/RegisterState.h: Re-enable the custom RegisterState and
 579         ALLOCATE_AND_GET_REGISTER_STATE definitions on ARM64 Linux. These don't
 580         cause any crashes nowadays.
 581
 582 2017-10-22  Yusuke Suzuki  <utatane.tea@gmail.com>
 583
 584         [JSC][Baseline] Use linkAllSlowCasesForBytecodeOffset as much as possible to simplify slow cases handling
 585         https://bugs.webkit.org/show_bug.cgi?id=178647
 586
 587         Reviewed by Saam Barati.
 588
 589         There is much code counting slow cases in fast paths to call `linkSlowCase` carefully. This is really error-prone
 590         since the number of slow cases depends on values of instruction's metadata. We have linkAllSlowCasesForBytecodeOffset,
 591         which drains all slow cases for a specified bytecode offset. In typical cases like just calling a slow path function,
 592         this is enough. We use linkAllSlowCasesForBytecodeOffset as much as possible. It significantly simplifies the code.
 593
 594         * jit/JIT.h:
 595         (JSC::JIT::linkAllSlowCases):
 596         * jit/JITArithmetic.cpp:
 597         (JSC::JIT::emitSlow_op_unsigned):
 598         (JSC::JIT::emit_compareAndJump):
 599         (JSC::JIT::emit_compareAndJumpSlow):
 600         (JSC::JIT::emitSlow_op_inc):
 601         (JSC::JIT::emitSlow_op_dec):
 602         (JSC::JIT::emitSlow_op_mod):
 603         (JSC::JIT::emitSlow_op_negate):
 604         (JSC::JIT::emitSlow_op_bitand):
 605         (JSC::JIT::emitSlow_op_bitor):
 606         (JSC::JIT::emitSlow_op_bitxor):
 607         (JSC::JIT::emitSlow_op_lshift):
 608         (JSC::JIT::emitSlow_op_rshift):
 609         (JSC::JIT::emitSlow_op_urshift):
 610         (JSC::JIT::emitSlow_op_add):
 611         (JSC::JIT::emitSlow_op_div):
 612         (JSC::JIT::emitSlow_op_mul):
 613         (JSC::JIT::emitSlow_op_sub):
 614         * jit/JITArithmetic32_64.cpp:
 615         (JSC::JIT::emit_compareAndJumpSlow):
 616         (JSC::JIT::emitSlow_op_unsigned):
 617         (JSC::JIT::emitSlow_op_inc):
 618         (JSC::JIT::emitSlow_op_dec):
 619         (JSC::JIT::emitSlow_op_mod):
 620         * jit/JITCall.cpp:
 621         (JSC::JIT::compileCallEvalSlowCase):
 622         (JSC::JIT::compileOpCallSlowCase):
 623         * jit/JITCall32_64.cpp:
 624         (JSC::JIT::compileCallEvalSlowCase):
 625         (JSC::JIT::compileOpCallSlowCase):
 626         * jit/JITInlines.h:
 627         (JSC::JIT::linkAllSlowCasesForBytecodeOffset):
 628         * jit/JITOpcodes.cpp:
 629         (JSC::JIT::emitSlow_op_new_object):
 630         (JSC::JIT::emitSlow_op_create_this):
 631         (JSC::JIT::emitSlow_op_check_tdz):
 632         (JSC::JIT::emitSlow_op_to_this):
 633         (JSC::JIT::emitSlow_op_to_primitive):
 634         (JSC::JIT::emitSlow_op_not):
 635         (JSC::JIT::emitSlow_op_eq):
 636         (JSC::JIT::emitSlow_op_neq):
 637         (JSC::JIT::emitSlow_op_stricteq):
 638         (JSC::JIT::emitSlow_op_nstricteq):
 639         (JSC::JIT::emitSlow_op_instanceof):
 640         (JSC::JIT::emitSlow_op_instanceof_custom):
 641         (JSC::JIT::emitSlow_op_to_number):
 642         (JSC::JIT::emitSlow_op_to_string):
 643         (JSC::JIT::emitSlow_op_loop_hint):
 644         (JSC::JIT::emitSlow_op_check_traps):
 645         (JSC::JIT::emitSlow_op_has_indexed_property):
 646         (JSC::JIT::emitSlow_op_get_direct_pname):
 647         (JSC::JIT::emitSlow_op_has_structure_property):
 648         * jit/JITOpcodes32_64.cpp:
 649         (JSC::JIT::emitSlow_op_new_object):
 650         (JSC::JIT::emitSlow_op_instanceof):
 651         (JSC::JIT::emitSlow_op_instanceof_custom):
 652         (JSC::JIT::emitSlow_op_to_primitive):
 653         (JSC::JIT::emitSlow_op_not):
 654         (JSC::JIT::emitSlow_op_stricteq):
 655         (JSC::JIT::emitSlow_op_nstricteq):
 656         (JSC::JIT::emitSlow_op_to_number):
 657         (JSC::JIT::emitSlow_op_to_string):
 658         (JSC::JIT::emitSlow_op_create_this):
 659         (JSC::JIT::emitSlow_op_to_this):
 660         (JSC::JIT::emitSlow_op_check_tdz):
 661         (JSC::JIT::emitSlow_op_has_indexed_property):
 662         (JSC::JIT::emitSlow_op_get_direct_pname):
 663         * jit/JITPropertyAccess.cpp:
 664         (JSC::JIT::emitSlow_op_try_get_by_id):
 665         (JSC::JIT::emitSlow_op_get_by_id):
 666         (JSC::JIT::emitSlow_op_get_by_id_with_this):
 667         (JSC::JIT::emitSlow_op_put_by_id):
 668         (JSC::JIT::emitSlow_op_resolve_scope):
 669         (JSC::JIT::emitSlow_op_get_from_scope):
 670         (JSC::JIT::emitSlow_op_put_to_scope):
 671         * jit/JITPropertyAccess32_64.cpp:
 672         (JSC::JIT::emitSlow_op_try_get_by_id):
 673         (JSC::JIT::emitSlow_op_get_by_id):
 674         (JSC::JIT::emitSlow_op_get_by_id_with_this):
 675         (JSC::JIT::emitSlow_op_put_by_id):
 676         (JSC::JIT::emitSlow_op_resolve_scope):
 677         (JSC::JIT::emitSlow_op_get_from_scope):
 678         (JSC::JIT::emitSlow_op_put_to_scope):
 679
 680 2017-10-22  Yusuke Suzuki  <utatane.tea@gmail.com>
 681
 682         [JSC] Clean up baseline slow path
 683         https://bugs.webkit.org/show_bug.cgi?id=178646
 684
 685         Reviewed by Saam Barati.
 686
 687         If the given op is just calling a slow path function, we should use DEFINE_SLOW_OP instead.
 688         It is good since (1) we can reduce the manual emitting code and (2) it can clarify which
 689         function is implemented as a slow path call. This patch is an attempt to reduce 32bit specific
 690         code in baseline JIT.
 691
 692         * jit/JIT.cpp:
 693         (JSC::JIT::privateCompileMainPass):
 694         * jit/JIT.h:
 695         * jit/JITArithmetic.cpp:
 696         (JSC::JIT::emit_op_pow): Deleted.
 697         * jit/JITArithmetic32_64.cpp:
 698         (JSC::JIT::emitSlow_op_mod):
 699         * jit/JITOpcodes.cpp:
 700         (JSC::JIT::emit_op_strcat): Deleted.
 701         (JSC::JIT::emit_op_push_with_scope): Deleted.
 702         (JSC::JIT::emit_op_assert): Deleted.
 703         (JSC::JIT::emit_op_create_lexical_environment): Deleted.
 704         (JSC::JIT::emit_op_throw_static_error): Deleted.
 705         (JSC::JIT::emit_op_new_array_with_spread): Deleted.
 706         (JSC::JIT::emit_op_spread): Deleted.
 707         (JSC::JIT::emit_op_get_enumerable_length): Deleted.
 708         (JSC::JIT::emit_op_has_generic_property): Deleted.
 709         (JSC::JIT::emit_op_get_property_enumerator): Deleted.
 710         (JSC::JIT::emit_op_to_index_string): Deleted.
 711         (JSC::JIT::emit_op_create_direct_arguments): Deleted.
 712         (JSC::JIT::emit_op_create_scoped_arguments): Deleted.
 713         (JSC::JIT::emit_op_create_cloned_arguments): Deleted.
 714         (JSC::JIT::emit_op_create_rest): Deleted.
 715         (JSC::JIT::emit_op_unreachable): Deleted.
 716         * jit/JITOpcodes32_64.cpp:
 717         (JSC::JIT::emit_op_strcat): Deleted.
 718         (JSC::JIT::emit_op_push_with_scope): Deleted.
 719         (JSC::JIT::emit_op_assert): Deleted.
 720         (JSC::JIT::emit_op_create_lexical_environment): Deleted.
 721         * jit/JITPropertyAccess.cpp:
 722         (JSC::JIT::emit_op_put_by_val_with_this): Deleted.
 723         (JSC::JIT::emit_op_get_by_val_with_this): Deleted.
 724         (JSC::JIT::emit_op_put_by_id_with_this): Deleted.
 725         (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval): Deleted.
 726         (JSC::JIT::emit_op_define_data_property): Deleted.
 727         (JSC::JIT::emit_op_define_accessor_property): Deleted.
 728         * jit/JITPropertyAccess32_64.cpp:
 729         (JSC::JIT::emit_op_resolve_scope_for_hoisting_func_decl_in_eval): Deleted.
 730         (JSC::JIT::emit_op_get_by_val_with_this): Deleted.
 731         (JSC::JIT::emit_op_put_by_id_with_this): Deleted.
 732         (JSC::JIT::emit_op_put_by_val_with_this): Deleted.
 733
 734 2017-10-21  Joseph Pecoraro  <pecoraro@apple.com>
 735
 736         Web Inspector: Remove unused Console.setMonitoringXHREnabled
 737         https://bugs.webkit.org/show_bug.cgi?id=178617
 738
 739         Reviewed by Sam Weinig.
 740
 741         * JavaScriptCore.xcodeproj/project.pbxproj:
 742         * Sources.txt:
 743         * inspector/agents/InspectorConsoleAgent.h:
 744         * inspector/agents/JSGlobalObjectConsoleAgent.cpp: Removed.
 745         * inspector/agents/JSGlobalObjectConsoleAgent.h: Removed.
 746         * inspector/protocol/Console.json:
 747         Removed files and method.
 748
 749         * inspector/JSGlobalObjectInspectorController.cpp:
 750         (Inspector::JSGlobalObjectInspectorController::JSGlobalObjectInspectorController):
 751         This can use the base ConsoleAgent now.
 752
 753 2017-10-21  Yusuke Suzuki  <utatane.tea@gmail.com>
 754
 755         [JSC] Remove per-host-function CTI stub in 32bit environment
 756         https://bugs.webkit.org/show_bug.cgi?id=178581
 757
 758         Reviewed by Saam Barati.
 759
 760         JIT::privateCompileCTINativeCall only exists in 32bit environment and it is almost the same to native call CTI stub.
 761         The only difference is that it embed the address of the host function directly in the generated stub. This means
 762         that we have per-host-function CTI stub only in 32bit environment.
 763
 764         This patch just removes it and use one CTI stub instead. This design is the same to the current 64bit implementation.
 765
 766         * jit/JIT.cpp:
 767         (JSC::JIT::compileCTINativeCall): Deleted.
 768         * jit/JIT.h:
 769         * jit/JITOpcodes.cpp:
 770         (JSC::JIT::privateCompileCTINativeCall): Deleted.
 771         * jit/JITOpcodes32_64.cpp:
 772         (JSC::JIT::privateCompileCTINativeCall): Deleted.
 773         * jit/JITThunks.cpp:
 774         (JSC::JITThunks::hostFunctionStub):
 775
 776 2017-10-20  Antoine Quint  <graouts@apple.com>
 777
 778         [Web Animations] Provide basic timeline and animation interfaces
 779         https://bugs.webkit.org/show_bug.cgi?id=178526
 780
 781         Reviewed by Dean Jackson.
 782
 783         Remove the WEB_ANIMATIONS compile-time flag.
 784
 785         * Configurations/FeatureDefines.xcconfig:
 786
 787 2017-10-20  Commit Queue  <commit-queue@webkit.org>
 788
 789         Unreviewed, rolling out r223744, r223750, and r223751.
 790         https://bugs.webkit.org/show_bug.cgi?id=178594
 791
 792         These caused consistent failures in test that existed and were
 793         added in the patches. (Requested by mlewis13 on #webkit).
 794
 795         Reverted changesets:
 796
 797         "[JSC] ScriptFetcher should be notified directly from module
 798         pipeline"
 799         https://bugs.webkit.org/show_bug.cgi?id=178340
 800         https://trac.webkit.org/changeset/223744
 801
 802         "Unreviewed, fix changed line number in test expect files"
 803         https://bugs.webkit.org/show_bug.cgi?id=178340
 804         https://trac.webkit.org/changeset/223750
 805
 806         "Unreviewed, follow up to reflect comments"
 807         https://bugs.webkit.org/show_bug.cgi?id=178340
 808         https://trac.webkit.org/changeset/223751
 809
 810 2017-10-20  Yusuke Suzuki  <utatane.tea@gmail.com>
 811
 812         Unreviewed, follow up to reflect comments
 813         https://bugs.webkit.org/show_bug.cgi?id=178340
 814
 815         * runtime/JSModuleLoader.cpp:
 816         (JSC::JSModuleLoader::notifyCompleted):
 817
 818 2017-10-20  Saam Barati  <sbarati@apple.com>
 819
 820         Optimize accesses to how we get the direct prototype
 821         https://bugs.webkit.org/show_bug.cgi?id=178548
 822
 823         Reviewed by Yusuke Suzuki.
 824
 825         This patch makes JSObject::getPrototypeDirect take VM& as a parameter
 826         so it can use the faster version of the structure accessor function.
 827         The reason for making this change is that JSObjet::getPrototypeDirect
 828         is called on the hot path in property lookup.
 829
 830         * API/JSObjectRef.cpp:
 831         (JSObjectGetPrototype):
 832         * jsc.cpp:
 833         (WTF::DOMJITGetterBaseJSObject::DOMJITAttribute::slowCall):
 834         (WTF::DOMJITGetterBaseJSObject::customGetter):
 835         (functionCreateProxy):
 836         * runtime/ArrayPrototype.cpp:
 837         (JSC::speciesWatchpointIsValid):
 838         * runtime/ErrorInstance.cpp:
 839         (JSC::ErrorInstance::sanitizedToString):
 840         * runtime/JSArray.cpp:
 841         (JSC::JSArray::isIteratorProtocolFastAndNonObservable):
 842         * runtime/JSGlobalObject.cpp:
 843         (JSC::JSGlobalObject::init):
 844         (JSC::lastInPrototypeChain):
 845         (JSC::JSGlobalObject::resetPrototype):
 846         (JSC::JSGlobalObject::finishCreation):
 847         * runtime/JSGlobalObjectInlines.h:
 848         (JSC::JSGlobalObject::objectPrototypeIsSane):
 849         (JSC::JSGlobalObject::arrayPrototypeChainIsSane):
 850         (JSC::JSGlobalObject::stringPrototypeChainIsSane):
 851         * runtime/JSLexicalEnvironment.cpp:
 852         (JSC::JSLexicalEnvironment::getOwnPropertySlot):
 853         * runtime/JSMap.cpp:
 854         (JSC::JSMap::isIteratorProtocolFastAndNonObservable):
 855         * runtime/JSObject.cpp:
 856         (JSC::JSObject::calculatedClassName):
 857         (JSC::JSObject::setPrototypeWithCycleCheck):
 858         (JSC::JSObject::getPrototype):
 859         (JSC::JSObject::attemptToInterceptPutByIndexOnHoleForPrototype):
 860         (JSC::JSObject::attemptToInterceptPutByIndexOnHole):
 861         (JSC::JSObject::anyObjectInChainMayInterceptIndexedAccesses const):
 862         (JSC::JSObject::prototypeChainMayInterceptStoreTo):
 863         * runtime/JSObject.h:
 864         (JSC::JSObject::finishCreation):
 865         (JSC::JSObject::getPrototypeDirect const):
 866         (JSC::JSObject::getPrototype):
 867         * runtime/JSObjectInlines.h:
 868         (JSC::JSObject::canPerformFastPutInline):
 869         (JSC::JSObject::getPropertySlot):
 870         (JSC::JSObject::getNonIndexPropertySlot):
 871         * runtime/JSProxy.cpp:
 872         (JSC::JSProxy::setTarget):
 873         * runtime/JSSet.cpp:
 874         (JSC::JSSet::isIteratorProtocolFastAndNonObservable):
 875         * runtime/ProgramExecutable.cpp:
 876         (JSC::ProgramExecutable::initializeGlobalProperties):
 877         * runtime/StructureInlines.h:
 878         (JSC::Structure::isValid const):
 879
 880 2017-10-20  Yusuke Suzuki  <utatane.tea@gmail.com>
 881
 882         [ARM64] static_cast<int32_t>() in BinaryOpNode::emitBytecode() prevents op_unsigned emission
 883         https://bugs.webkit.org/show_bug.cgi?id=178379
 884
 885         Reviewed by Saam Barati.
 886
 887         We reuse jsNumber's checking mechanism here to precisely check the generated number is within uint32_t
 888         in bytecode compiler. This is reasonable since the NumberNode will generate the exact this JSValue.
 889
 890         * bytecompiler/NodesCodegen.cpp:
 891         (JSC::BinaryOpNode::emitBytecode):
 892
 893 2017-10-20  Yusuke Suzuki  <utatane.tea@gmail.com>
 894
 895         [JSC] ScriptFetcher should be notified directly from module pipeline
 896         https://bugs.webkit.org/show_bug.cgi?id=178340
 897
 898         Reviewed by Sam Weinig.
 899
 900         Previously, we use JSStdFunction to let WebCore inform the module pipeline results.
 901         We setup JSStdFunction to the resulted promise of the module pipeline. It is super
 902         ad-hoc since JSStdFunction's lambda need extra-careful to make it non-cyclic-referenced.
 903         JSStdFunction's lambda can capture variables, but they are not able to be marked by GC.
 904
 905         But now, we have ScriptFetcher. It is introduced after we implemented the module pipeline
 906         notification mechanism by using JSStdFunction. But it is appropriate one to receive notification
 907         from the module pipeline by observer style.
 908
 909         This patch removes the above ad-hoc JSStdFunction use. And now ScriptFetcher receives
 910         completion/failure notifications from the module pipeline.
 911
 912         * builtins/ModuleLoaderPrototype.js:
 913         (loadModule):
 914         (loadAndEvaluateModule):
 915         * runtime/Completion.cpp:
 916         (JSC::loadModule):
 917         * runtime/Completion.h:
 918         * runtime/JSModuleLoader.cpp:
 919         (JSC::jsValueToModuleKey):
 920         (JSC::JSModuleLoader::notifyCompleted):
 921         (JSC::JSModuleLoader::notifyFailed):
 922         * runtime/JSModuleLoader.h:
 923         * runtime/ModuleLoaderPrototype.cpp:
 924         (JSC::moduleLoaderPrototypeNotifyCompleted):
 925         (JSC::moduleLoaderPrototypeNotifyFailed):
 926         * runtime/ScriptFetcher.h:
 927         (JSC::ScriptFetcher::notifyLoadCompleted):
 928         (JSC::ScriptFetcher::notifyLoadFailed):
 929
 930 2017-10-19  JF Bastien  <jfbastien@apple.com>
 931
 932         WebAssembly: no VM / JS version of everything but Instance
 933         https://bugs.webkit.org/show_bug.cgi?id=177473
 934
 935         Reviewed by Filip Pizlo, Saam Barati.
 936
 937         This change entails cleaning up and splitting a bunch of code which we had
 938         intertwined between C++ classes which represent JS objects, and pure C++
 939         implementation objects. This specific change goes most of the way towards
 940         allowing JSC's WebAssembly to work without VM / JS, up to but excluding
 941         JSWebAssemblyInstance (there's Wasm::Instance, but it's not *the* thing
 942         yet). Because of this we still have a few FIXME identifying places that need to
 943         change. A follow-up change will go the rest of the way.
 944
 945         I went about this change in the simplest way possible: grep the
 946         JavaScriptCore/wasm directory for "JS[^C_]" as well as "VM" and exclude the /js/
 947         sub-directory (which contains the JS implementation of WebAssembly).
 948
 949         None of this change removes the need for a JIT entitlement to be able to use
 950         WebAssembly. We don't have an interpreter, the process therefore still needs to
 951         be allowed to JIT to use these pure-C++ APIs.
 952
 953         Interesting things to note:
 954
 955           - Remove VM from Plan and associated places. It can just live as a capture in
 956             the callback lambda if it's needed.
 957           - Wasm::Memory shouldn't require a VM. It was only used to ask the GC to
 958             collect. We now instead pass two lambdas at construction time for this
 959             purpose: one to notify of memory pressure, and the other to ask for
 960             syncrhonous memory reclamation. This allows whoever creates the memory to
 961             dictate how to react to both these cases, and for a JS embedding that's to
 962             call the GC (async or sync, respectively).
 963           - Move grow logic from JSWebAssemblyMemory to Wasm::Memory::grow. Use Expected
 964             there, with an enum class for failure types.
 965           - Exceeding max on memory growth now returns a range error as per spec. This
 966             is a (very minor) breaking change: it used to throw OOM error. Update the
 967             corresponding test.
 968           - When generating the grow_memory opcode, no need to get the VM. Instead,
 969             reach directly for Wasm::Memory and grow it.
 970           - JSWebAssemblyMemory::grow can now always throw on failure, because it's only
 971             ever called from JS (not from grow_memory as before).
 972           - Wasm::Memory now takes a callback for successful growth. This allows JS
 973             wrappers to register themselves when growth succeeds without Wasm::Memory
 974             knowning anything about JS. It'll also allow creating a list of callbacks
 975             for when we add thread support (we'll want to notify many wrappers, all
 976             under a lock).
 977           - Wasm::Memory is now back to being the source of truth about address / size,
 978             used directly by generated code instead of JSWebAssemblyMemory.
 979           - Move wasmToJS from the general WasmBinding header to its own header under
 980             wasm/js. It's only used by wasm/js/JSWebAssemblyCodeBlock.cpp, and uses VM,
 981             and therefore isn't general WebAssembly.
 982           - Make Wasm::Context an actual type (just a struct holding a
 983             JSWebAssemlyInstance for now) instead of an alias for that. Notably this
 984             doesn't add anything to the Context and doesn't change what actually gets
 985             passed around in JIT code (fast TLS or registers) because these changes
 986             potentially impact performance. The entire purpose of this change is to
 987             allow passing Wasm::Context around without having to know about VM. Since VM
 988             contains a Wasm::Context the JS embedding is effectively the same, but with
 989             this setup a non-JS embedding is much better off.
 990           - Move JSWebAssembly into the JS folder.
 991           - OMGPlan: use Wasm::CodeBlock directly instead of JSWebAssemblyCodeBlock.
 992           - wasm->JS stubs are now on the instance's tail as raw pointers, instead of
 993             being on JSWebAssemblyCodeBlock, and are now called wasm->Embedder
 994             stubs. The owned reference is still on JSWebAssemblyCodeBlock, and is still
 995             called wasm->JS stub. This move means that the embedder must, after creating
 996             a Wasm::CodeBlock, somehow create the stubs to call back into the
 997             embedder. This removes an indirection in the generated code because
 998             the B3 IR generator now reaches into the instance instead of
 999             JSWebAssemblyCodeBlock.
1000           - Move more CodeBlock things. Compilation completion is now marked by its own
1001             atomic<bool> flag instead of a nullptr plan: that required using a lock, and
1002             was causing a deadlock in stack-trace.js because before my changes
1003             JSWebAssemblyCodeBlock did its own completion checking separately from
1004             Wasm::CodeBlock, without getting the lock. Now that everything points to
1005             Wasm::CodeBlock and there's no cached completion marker, the lock was being
1006             acquired in a sanity-check assertion.
1007           - Embedder -> Wasm wrappers are now generated through a function that's passed
1008             in at compilation time, instead of being hard-coded as a JS -> Wasm wrapper.
1009           - WasmMemory doens't need to know about fault handling thunks. Only the IR
1010             generator should know, and should make sure that the exception throwing
1011             thunk is generated if any memory is present (note: with signal handling not
1012             all of them generate an exception check).
1013           - Make exception throwing pluggable: instead of having a hard-coded
1014             JS-specific lambda we now have a regular C++ function being called from JIT
1015             code when a WebAssembly exception is thrown. This allows any embedder to get
1016             called as they wish. For now a process can only have a single of these
1017             functions (i.e. only one embedder per process) because the trap handler is a
1018             singleton. That can be fixed in in #177475.
1019           - Create WasmEmbedder.h where all embedder plugging will live.
1020           - Split up JSWebAssemblyTable into Wasm::Table which is
1021             refcounted. JSWebAssemblyTable now only contains the JS functions in the
1022             table, and Wasm::Table is what's used by the JIT code to lookup where to
1023             call and do the instance check (for context switch). Note that this creates
1024             an extra allocation for all the instances in Wasm::Table, and in exchange
1025             removes an indirection in JIT code because the instance used to be obtained
1026             off of the JS function. Also note that it's the embedder than keeps the
1027             instances alive, not Wasm::Table (which holds a dumb pointer to the
1028             instance), because doing otherwise would cause reference cycles.
1029            - Add WasmInstance. It doesn't do much for now, owns globals.
1030            - JSWebAssembly instance now doesn't just contain the imported functions as
1031              JSObjects, it also has the corresponding import's instance and wasm
1032              entrypoint. This triples the space allocated per instance's imported
1033              function, but there shouldn't be that many imports. This has two upsides: it
1034              creates smaller and faster code, and makes is easier to disassociate
1035              embedder-specific things from embedder-neutral things. The small / faster
1036              win is in two places: B3 IR generator only needs offsetOfImportFunction for
1037              the call opcode (when the called index is an import) to know whether the
1038              import is wasm->wasm or wasm->embedder (this isn't known at compile-time
1039              because it's dependent on the import object), this is now done by seeing if
1040              that import function has an associated target instance (only wasm->wasm
1041              does); the other place is wasmBinding which uses offsetOfImportFunction to
1042              figure out the wasm->wasm target instance, and then gets
1043              WebAssemblyFunction::offsetOfWasmEntrypointLoadLocation to do a tail
1044              call. The disassociation comes because the target instance can be
1045              Wasm::Instance once we change what the Context is, and
1046              WasmEntrypointLoadLocation is already embedder-independent. As a next step I
1047              can move this tail allocation from JSWebAssemblyInstance to Wasm::Instance,
1048              and leave importFunction in as an opaque pointer which is embedder-specific,
1049              and in JS will remain WriteBarrier<JSObject>.
1050            - Rename VMEntryFrame to EntryFrame, and in many places pass a pointer to it
1051              around instead of VM. This is a first step in allowing entry frames which
1052              aren't stored on VM, but which are instead stored in an embedder-specific
1053              location. That change won't really affect JS except through code churn, but
1054              will allow WebAssembly to use some machinery in a generic manner without
1055              having a VM.
1056
1057         * JavaScriptCore.xcodeproj/project.pbxproj:
1058         * Sources.txt:
1059         * bytecode/PolymorphicAccess.cpp:
1060         (JSC::AccessGenerationState::emitExplicitExceptionHandler):
1061         * debugger/Debugger.cpp:
1062         (JSC::Debugger::stepOutOfFunction):
1063         (JSC::Debugger::returnEvent):
1064         (JSC::Debugger::unwindEvent):
1065         (JSC::Debugger::didExecuteProgram):
1066         * dfg/DFGJITCompiler.cpp:
1067         (JSC::DFG::JITCompiler::compileExceptionHandlers):
1068         * dfg/DFGOSREntry.cpp:
1069         (JSC::DFG::prepareOSREntry):
1070         * dfg/DFGOSRExit.cpp:
1071         (JSC::DFG::OSRExit::compileOSRExit):
1072         (JSC::DFG::OSRExit::compileExit):
1073         * dfg/DFGThunks.cpp:
1074         (JSC::DFG::osrEntryThunkGenerator):
1075         * ftl/FTLCompile.cpp:
1076         (JSC::FTL::compile):
1077         * ftl/FTLLink.cpp:
1078         (JSC::FTL::link):
1079         * ftl/FTLLowerDFGToB3.cpp:
1080         (JSC::FTL::DFG::LowerDFGToB3::lower):
1081         * ftl/FTLOSRExitCompiler.cpp:
1082         (JSC::FTL::compileStub):
1083         * interpreter/CallFrame.cpp:
1084         (JSC::CallFrame::wasmAwareLexicalGlobalObject):
1085         (JSC::CallFrame::callerFrame):
1086         (JSC::CallFrame::unsafeCallerFrame):
1087         * interpreter/CallFrame.h:
1088         (JSC::ExecState::callerFrame const):
1089         (JSC::ExecState::callerFrameOrEntryFrame const):
1090         (JSC::ExecState::unsafeCallerFrameOrEntryFrame const):
1091         * interpreter/FrameTracers.h:
1092         (JSC::NativeCallFrameTracer::NativeCallFrameTracer):
1093         (JSC::NativeCallFrameTracerWithRestore::NativeCallFrameTracerWithRestore):
1094         (JSC::NativeCallFrameTracerWithRestore::~NativeCallFrameTracerWithRestore):
1095         * interpreter/Interpreter.cpp:
1096         (JSC::UnwindFunctor::operator() const):
1097         (JSC::UnwindFunctor::copyCalleeSavesToEntryFrameCalleeSavesBuffer const):
1098         (JSC::Interpreter::unwind):
1099         * interpreter/StackVisitor.cpp:
1100         (JSC::StackVisitor::StackVisitor):
1101         (JSC::StackVisitor::gotoNextFrame):
1102         (JSC::StackVisitor::readNonInlinedFrame):
1103         (JSC::StackVisitor::Frame::dump const):
1104         * interpreter/StackVisitor.h:
1105         (JSC::StackVisitor::Frame::callerIsEntryFrame const):
1106         * interpreter/VMEntryRecord.h:
1107         (JSC::VMEntryRecord::prevTopEntryFrame):
1108         (JSC::VMEntryRecord::unsafePrevTopEntryFrame):
1109         (JSC::EntryFrame::vmEntryRecordOffset):
1110         * jit/AssemblyHelpers.cpp:
1111         (JSC::AssemblyHelpers::restoreCalleeSavesFromEntryFrameCalleeSavesBuffer):
1112         (JSC::AssemblyHelpers::loadWasmContextInstance):
1113         (JSC::AssemblyHelpers::storeWasmContextInstance):
1114         (JSC::AssemblyHelpers::loadWasmContextInstanceNeedsMacroScratchRegister):
1115         (JSC::AssemblyHelpers::storeWasmContextInstanceNeedsMacroScratchRegister):
1116         (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBufferImpl):
1117         * jit/AssemblyHelpers.h:
1118         (JSC::AssemblyHelpers::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
1119         (JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBuffer):
1120         (JSC::AssemblyHelpers::copyCalleeSavesFromFrameOrRegisterToEntryFrameCalleeSavesBuffer):
1121         * jit/JIT.cpp:
1122         (JSC::JIT::emitEnterOptimizationCheck):
1123         (JSC::JIT::privateCompileExceptionHandlers):
1124         * jit/JITExceptions.cpp:
1125         (JSC::genericUnwind):
1126         * jit/JITOpcodes.cpp:
1127         (JSC::JIT::emit_op_throw):
1128         (JSC::JIT::emit_op_catch):
1129         (JSC::JIT::emitSlow_op_loop_hint):
1130         * jit/JITOpcodes32_64.cpp:
1131         (JSC::JIT::emit_op_throw):
1132         (JSC::JIT::emit_op_catch):
1133         * jit/JITOperations.cpp:
1134         * jit/ThunkGenerators.cpp:
1135         (JSC::throwExceptionFromCallSlowPathGenerator):
1136         (JSC::nativeForGenerator):
1137         * jsc.cpp:
1138         (functionDumpCallFrame):
1139         * llint/LLIntSlowPaths.cpp:
1140         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1141         * llint/LLIntThunks.cpp:
1142         (JSC::vmEntryRecord):
1143         * llint/LowLevelInterpreter.asm:
1144         * llint/LowLevelInterpreter32_64.asm:
1145         * llint/LowLevelInterpreter64.asm:
1146         * runtime/Options.cpp:
1147         (JSC::recomputeDependentOptions):
1148         * runtime/Options.h:
1149         * runtime/SamplingProfiler.cpp:
1150         (JSC::FrameWalker::FrameWalker):
1151         (JSC::FrameWalker::advanceToParentFrame):
1152         (JSC::SamplingProfiler::processUnverifiedStackTraces):
1153         * runtime/ThrowScope.cpp:
1154         (JSC::ThrowScope::~ThrowScope):
1155         * runtime/VM.cpp:
1156         (JSC::VM::VM):
1157         (JSC::VM::~VM):
1158         * runtime/VM.h:
1159         (JSC::VM::topEntryFrameOffset):
1160         * runtime/VMTraps.cpp:
1161         (JSC::isSaneFrame):
1162         (JSC::VMTraps::tryInstallTrapBreakpoints):
1163         (JSC::VMTraps::invalidateCodeBlocksOnStack):
1164         * wasm/WasmB3IRGenerator.cpp:
1165         (JSC::Wasm::B3IRGenerator::restoreWasmContextInstance):
1166         (JSC::Wasm::B3IRGenerator::B3IRGenerator):
1167         (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
1168         (JSC::Wasm::B3IRGenerator::addGrowMemory):
1169         (JSC::Wasm::B3IRGenerator::addCurrentMemory):
1170         (JSC::Wasm::B3IRGenerator::addCall):
1171         (JSC::Wasm::B3IRGenerator::addCallIndirect):
1172         (JSC::Wasm::parseAndCompile):
1173         * wasm/WasmB3IRGenerator.h:
1174         * wasm/WasmBBQPlan.cpp:
1175         (JSC::Wasm::BBQPlan::BBQPlan):
1176         (JSC::Wasm::BBQPlan::compileFunctions):
1177         (JSC::Wasm::BBQPlan::complete):
1178         * wasm/WasmBBQPlan.h:
1179         * wasm/WasmBBQPlanInlines.h:
1180         (JSC::Wasm::BBQPlan::initializeCallees):
1181         * wasm/WasmBinding.cpp:
1182         (JSC::Wasm::wasmToWasm):
1183         * wasm/WasmBinding.h:
1184         * wasm/WasmCodeBlock.cpp:
1185         (JSC::Wasm::CodeBlock::create):
1186         (JSC::Wasm::CodeBlock::CodeBlock):
1187         (JSC::Wasm::CodeBlock::compileAsync):
1188         (JSC::Wasm::CodeBlock::setCompilationFinished):
1189         * wasm/WasmCodeBlock.h:
1190         (JSC::Wasm::CodeBlock::offsetOfImportStubs):
1191         (JSC::Wasm::CodeBlock::allocationSize):
1192         (JSC::Wasm::CodeBlock::importWasmToEmbedderStub):
1193         (JSC::Wasm::CodeBlock::offsetOfImportWasmToEmbedderStub):
1194         (JSC::Wasm::CodeBlock::wasmToJSCallStubForImport):
1195         (JSC::Wasm::CodeBlock::compilationFinished):
1196         (JSC::Wasm::CodeBlock::jsEntrypointCalleeFromFunctionIndexSpace):
1197         (JSC::Wasm::CodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace):
1198         * wasm/WasmContext.cpp:
1199         (JSC::Wasm::Context::useFastTLS):
1200         (JSC::Wasm::Context::load const):
1201         (JSC::Wasm::Context::store):
1202         * wasm/WasmContext.h:
1203         * wasm/WasmEmbedder.h: Copied from Source/JavaScriptCore/wasm/WasmContext.h.
1204         * wasm/WasmFaultSignalHandler.cpp:
1205         * wasm/WasmFaultSignalHandler.h:
1206         * wasm/WasmFormat.h:
1207         * wasm/WasmInstance.cpp: Copied from Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h.
1208         (JSC::Wasm::Instance::Instance):
1209         (JSC::Wasm::Instance::~Instance):
1210         (JSC::Wasm::Instance::extraMemoryAllocated const):
1211         * wasm/WasmInstance.h: Added.
1212         (JSC::Wasm::Instance::create):
1213         (JSC::Wasm::Instance::finalizeCreation):
1214         (JSC::Wasm::Instance::module):
1215         (JSC::Wasm::Instance::codeBlock):
1216         (JSC::Wasm::Instance::memory):
1217         (JSC::Wasm::Instance::table):
1218         (JSC::Wasm::Instance::loadI32Global const):
1219         (JSC::Wasm::Instance::loadI64Global const):
1220         (JSC::Wasm::Instance::loadF32Global const):
1221         (JSC::Wasm::Instance::loadF64Global const):
1222         (JSC::Wasm::Instance::setGlobal):
1223         (JSC::Wasm::Instance::offsetOfCachedStackLimit):
1224         (JSC::Wasm::Instance::cachedStackLimit const):
1225         (JSC::Wasm::Instance::setCachedStackLimit):
1226         * wasm/WasmMemory.cpp:
1227         (JSC::Wasm::Memory::Memory):
1228         (JSC::Wasm::Memory::create):
1229         (JSC::Wasm::Memory::~Memory):
1230         (JSC::Wasm::Memory::grow):
1231         * wasm/WasmMemory.h:
1232         (JSC::Wasm::Memory::offsetOfMemory):
1233         (JSC::Wasm::Memory::offsetOfSize):
1234         * wasm/WasmMemoryInformation.cpp:
1235         (JSC::Wasm::PinnedRegisterInfo::get):
1236         (JSC::Wasm::PinnedRegisterInfo::PinnedRegisterInfo):
1237         * wasm/WasmMemoryInformation.h:
1238         (JSC::Wasm::PinnedRegisterInfo::toSave const):
1239         * wasm/WasmMemoryMode.cpp: Copied from Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h.
1240         (JSC::Wasm::makeString):
1241         * wasm/WasmMemoryMode.h: Copied from Source/JavaScriptCore/wasm/WasmFaultSignalHandler.h.
1242         * wasm/WasmModule.cpp:
1243         (JSC::Wasm::makeValidationCallback):
1244         (JSC::Wasm::Module::validateSync):
1245         (JSC::Wasm::Module::validateAsync):
1246         (JSC::Wasm::Module::getOrCreateCodeBlock):
1247         (JSC::Wasm::Module::compileSync):
1248         (JSC::Wasm::Module::compileAsync):
1249         * wasm/WasmModule.h:
1250         * wasm/WasmModuleParser.cpp:
1251         (JSC::Wasm::ModuleParser::parseTableHelper):
1252         * wasm/WasmOMGPlan.cpp:
1253         (JSC::Wasm::OMGPlan::OMGPlan):
1254         (JSC::Wasm::OMGPlan::runForIndex):
1255         * wasm/WasmOMGPlan.h:
1256         * wasm/WasmPageCount.h:
1257         (JSC::Wasm::PageCount::isValid const):
1258         * wasm/WasmPlan.cpp:
1259         (JSC::Wasm::Plan::Plan):
1260         (JSC::Wasm::Plan::runCompletionTasks):
1261         (JSC::Wasm::Plan::addCompletionTask):
1262         (JSC::Wasm::Plan::tryRemoveContextAndCancelIfLast):
1263         * wasm/WasmPlan.h:
1264         (JSC::Wasm::Plan::dontFinalize):
1265         * wasm/WasmSignature.cpp:
1266         * wasm/WasmSignature.h:
1267         * wasm/WasmTable.cpp: Added.
1268         (JSC::Wasm::Table::create):
1269         (JSC::Wasm::Table::~Table):
1270         (JSC::Wasm::Table::Table):
1271         (JSC::Wasm::Table::grow):
1272         (JSC::Wasm::Table::clearFunction):
1273         (JSC::Wasm::Table::setFunction):
1274         * wasm/WasmTable.h: Copied from Source/JavaScriptCore/wasm/js/JSWebAssemblyTable.h.
1275         (JSC::Wasm::Table::maximum const):
1276         (JSC::Wasm::Table::size const):
1277         (JSC::Wasm::Table::offsetOfSize):
1278         (JSC::Wasm::Table::offsetOfFunctions):
1279         (JSC::Wasm::Table::offsetOfInstances):
1280         (JSC::Wasm::Table::isValidSize):
1281         * wasm/WasmThunks.cpp:
1282         (JSC::Wasm::throwExceptionFromWasmThunkGenerator):
1283         (JSC::Wasm::triggerOMGTierUpThunkGenerator):
1284         (JSC::Wasm::Thunks::setThrowWasmException):
1285         (JSC::Wasm::Thunks::throwWasmException):
1286         * wasm/WasmThunks.h:
1287         * wasm/WasmWorklist.cpp:
1288         (JSC::Wasm::Worklist::stopAllPlansForContext):
1289         * wasm/WasmWorklist.h:
1290         * wasm/js/JSToWasm.cpp: Added.
1291         (JSC::Wasm::createJSToWasmWrapper):
1292         * wasm/js/JSToWasm.h: Copied from Source/JavaScriptCore/wasm/WasmBinding.h.
1293         * wasm/js/JSWebAssembly.cpp: Renamed from Source/JavaScriptCore/wasm/JSWebAssembly.cpp.
1294         * wasm/js/JSWebAssembly.h: Renamed from Source/JavaScriptCore/wasm/JSWebAssembly.h.
1295         * wasm/js/JSWebAssemblyCodeBlock.cpp:
1296         (JSC::JSWebAssemblyCodeBlock::create):
1297         (JSC::JSWebAssemblyCodeBlock::JSWebAssemblyCodeBlock):
1298         * wasm/js/JSWebAssemblyCodeBlock.h:
1299         * wasm/js/JSWebAssemblyInstance.cpp:
1300         (JSC::JSWebAssemblyInstance::JSWebAssemblyInstance):
1301         (JSC::JSWebAssemblyInstance::finishCreation):
1302         (JSC::JSWebAssemblyInstance::visitChildren):
1303         (JSC::JSWebAssemblyInstance::finalizeCreation):
1304         (JSC::JSWebAssemblyInstance::create):
1305         * wasm/js/JSWebAssemblyInstance.h:
1306         (JSC::JSWebAssemblyInstance::instance):
1307         (JSC::JSWebAssemblyInstance::context const):
1308         (JSC::JSWebAssemblyInstance::table):
1309         (JSC::JSWebAssemblyInstance::webAssemblyToJSCallee):
1310         (JSC::JSWebAssemblyInstance::setMemory):
1311         (JSC::JSWebAssemblyInstance::offsetOfTail):
1312         (JSC::JSWebAssemblyInstance::importFunctionInfo):
1313         (JSC::JSWebAssemblyInstance::offsetOfTargetInstance):
1314         (JSC::JSWebAssemblyInstance::offsetOfWasmEntrypoint):
1315         (JSC::JSWebAssemblyInstance::offsetOfImportFunction):
1316         (JSC::JSWebAssemblyInstance::importFunction):
1317         (JSC::JSWebAssemblyInstance::internalMemory):
1318         (JSC::JSWebAssemblyInstance::wasmCodeBlock const):
1319         (JSC::JSWebAssemblyInstance::offsetOfWasmTable):
1320         (JSC::JSWebAssemblyInstance::offsetOfCallee):
1321         (JSC::JSWebAssemblyInstance::offsetOfGlobals):
1322         (JSC::JSWebAssemblyInstance::offsetOfWasmCodeBlock):
1323         (JSC::JSWebAssemblyInstance::offsetOfWasmMemory):
1324         (JSC::JSWebAssemblyInstance::cachedStackLimit const):
1325         (JSC::JSWebAssemblyInstance::setCachedStackLimit):
1326         (JSC::JSWebAssemblyInstance::wasmMemory):
1327         (JSC::JSWebAssemblyInstance::wasmModule):
1328         (JSC::JSWebAssemblyInstance::allocationSize):
1329         (JSC::JSWebAssemblyInstance::module const):
1330         * wasm/js/JSWebAssemblyMemory.cpp:
1331         (JSC::JSWebAssemblyMemory::create):
1332         (JSC::JSWebAssemblyMemory::adopt):
1333         (JSC::JSWebAssemblyMemory::JSWebAssemblyMemory):
1334         (JSC::JSWebAssemblyMemory::grow):
1335         (JSC::JSWebAssemblyMemory::growSuccessCallback):
1336         * wasm/js/JSWebAssemblyMemory.h:
1337         * wasm/js/JSWebAssemblyModule.cpp:
1338         (JSC::JSWebAssemblyModule::moduleInformation const):
1339         (JSC::JSWebAssemblyModule::exportSymbolTable const):
1340         (JSC::JSWebAssemblyModule::signatureIndexFromFunctionIndexSpace const):
1341         (JSC::JSWebAssemblyModule::callee const):
1342         (JSC::JSWebAssemblyModule::codeBlock):
1343         (JSC::JSWebAssemblyModule::module):
1344         * wasm/js/JSWebAssemblyModule.h:
1345         * wasm/js/JSWebAssemblyTable.cpp:
1346         (JSC::JSWebAssemblyTable::create):
1347         (JSC::JSWebAssemblyTable::JSWebAssemblyTable):
1348         (JSC::JSWebAssemblyTable::visitChildren):
1349         (JSC::JSWebAssemblyTable::grow):
1350         (JSC::JSWebAssemblyTable::getFunction):
1351         (JSC::JSWebAssemblyTable::clearFunction):
1352         (JSC::JSWebAssemblyTable::setFunction):
1353         * wasm/js/JSWebAssemblyTable.h:
1354         (JSC::JSWebAssemblyTable::isValidSize):
1355         (JSC::JSWebAssemblyTable::maximum const):
1356         (JSC::JSWebAssemblyTable::size const):
1357         (JSC::JSWebAssemblyTable::table):
1358         * wasm/js/WasmToJS.cpp: Copied from Source/JavaScriptCore/wasm/WasmBinding.cpp.
1359         (JSC::Wasm::materializeImportJSCell):
1360         (JSC::Wasm::wasmToJS):
1361         (JSC::Wasm::wasmToJSException):
1362         * wasm/js/WasmToJS.h: Copied from Source/JavaScriptCore/wasm/WasmBinding.h.
1363         * wasm/js/WebAssemblyFunction.cpp:
1364         (JSC::callWebAssemblyFunction):
1365         * wasm/js/WebAssemblyInstanceConstructor.cpp:
1366         (JSC::constructJSWebAssemblyInstance):
1367         * wasm/js/WebAssemblyMemoryConstructor.cpp:
1368         (JSC::constructJSWebAssemblyMemory):
1369         * wasm/js/WebAssemblyMemoryPrototype.cpp:
1370         (JSC::webAssemblyMemoryProtoFuncGrow):
1371         * wasm/js/WebAssemblyModuleConstructor.cpp:
1372         (JSC::constructJSWebAssemblyModule):
1373         (JSC::WebAssemblyModuleConstructor::createModule):
1374         * wasm/js/WebAssemblyModuleConstructor.h:
1375         * wasm/js/WebAssemblyModuleRecord.cpp:
1376         (JSC::WebAssemblyModuleRecord::link):
1377         (JSC::WebAssemblyModuleRecord::evaluate):
1378         * wasm/js/WebAssemblyPrototype.cpp:
1379         (JSC::webAssemblyCompileFunc):
1380         (JSC::instantiate):
1381         (JSC::compileAndInstantiate):
1382         (JSC::webAssemblyValidateFunc):
1383         * wasm/js/WebAssemblyTableConstructor.cpp:
1384         (JSC::constructJSWebAssemblyTable):
1385         * wasm/js/WebAssemblyWrapperFunction.cpp:
1386         (JSC::WebAssemblyWrapperFunction::create):
1387
1388 2017-10-19  Mark Lam  <mark.lam@apple.com>
1389
1390         Stringifier::appendStringifiedValue() is missing an exception check.
1391         https://bugs.webkit.org/show_bug.cgi?id=178386
1392         <rdar://problem/35027610>
1393
1394         Reviewed by Saam Barati.
1395
1396         * runtime/JSONObject.cpp:
1397         (JSC::Stringifier::appendStringifiedValue):
1398
1399 2017-10-19  Saam Barati  <sbarati@apple.com>
1400
1401         REGRESSION(r223691): DFGByteCodeParser.cpp:1483:83: warning: comparison is always false due to limited range of data type [-Wtype-limits]
1402         https://bugs.webkit.org/show_bug.cgi?id=178543
1403
1404         Reviewed by Filip Pizlo.
1405
1406         * dfg/DFGByteCodeParser.cpp:
1407         (JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
1408
1409 2017-10-19  Saam Barati  <sbarati@apple.com>
1410
1411         re-inline ObjectAllocationProfile::initializeProfile
1412         https://bugs.webkit.org/show_bug.cgi?id=178532
1413
1414         Rubber stamped by Michael Saboff.
1415
1416         I un-inlined this function when implementing poly proto.
1417         This patch re-inlines it. In my testing, it looks like it
1418         might be a 0.5% speedometer progression to inline it.
1419
1420         * JavaScriptCore.xcodeproj/project.pbxproj:
1421         * Sources.txt:
1422         * bytecode/CodeBlock.cpp:
1423         * bytecode/ObjectAllocationProfile.cpp: Removed.
1424         * bytecode/ObjectAllocationProfileInlines.h: Copied from Source/JavaScriptCore/bytecode/ObjectAllocationProfile.cpp.
1425         (JSC::ObjectAllocationProfile::initializeProfile):
1426         (JSC::ObjectAllocationProfile::possibleDefaultPropertyCount):
1427         * runtime/FunctionRareData.cpp:
1428
1429 2017-10-19  Michael Saboff  <msaboff@apple.com>
1430
1431         Test262: RegExp/property-escapes/generated/Emoji_Component.js fails with current RegExp Unicode Properties implementation
1432         https://bugs.webkit.org/show_bug.cgi?id=178521
1433
1434         Reviewed by JF Bastien.
1435
1436         * ucd/emoji-data.txt: Replaced with the Unicode Emoji 5.0 version of the file as that is the most recent
1437         standard version.  The prior version was the draft 6.0 version.
1438
1439 2017-10-19  Saam Barati  <sbarati@apple.com>
1440
1441         We should hard code the poly proto offset
1442         https://bugs.webkit.org/show_bug.cgi?id=178531
1443
1444         Reviewed by Filip Pizlo.
1445
1446         This patch embraces that the poly proto offset is always zero. It's already
1447         the case that we would always get the inline offset zero for poly proto just
1448         by construction. This just hardcodes this assumption throughout the codebase.
1449         This appears to be a 1% speedometer progression in my testing.
1450
1451         The downside of this patch is that it may require changing how we do
1452         things when we implement poly proto when inheriting from builtin
1453         types. I think we can face this problem when we decide to implement
1454         that.
1455
1456         * bytecode/AccessCase.cpp:
1457         (JSC::AccessCase::generateWithGuard):
1458         * dfg/DFGOperations.cpp:
1459         * dfg/DFGSpeculativeJIT.cpp:
1460         (JSC::DFG::SpeculativeJIT::compileInstanceOfForObject):
1461         (JSC::DFG::SpeculativeJIT::compileGetPrototypeOf):
1462         * ftl/FTLLowerDFGToB3.cpp:
1463         (JSC::FTL::DFG::LowerDFGToB3::compileGetPrototypeOf):
1464         (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
1465         * jit/JITOpcodes.cpp:
1466         (JSC::JIT::emit_op_instanceof):
1467         * jit/JITOpcodes32_64.cpp:
1468         (JSC::JIT::emit_op_instanceof):
1469         * runtime/CommonSlowPaths.cpp:
1470         (JSC::SLOW_PATH_DECL):
1471         * runtime/JSObject.cpp:
1472         (JSC::JSObject::setPrototypeDirect):
1473         * runtime/JSObject.h:
1474         (JSC::JSObject::locationForOffset const):
1475         (JSC::JSObject::locationForOffset):
1476         (JSC::JSObject::getDirect const):
1477         * runtime/PropertyOffset.h:
1478         * runtime/Structure.cpp:
1479         (JSC::Structure::create):
1480         (JSC::Structure::dump const):
1481         * runtime/Structure.h:
1482         * runtime/StructureInlines.h:
1483         (JSC::Structure::storedPrototype const):
1484         (JSC::Structure::storedPrototypeObject const):
1485
1486 2017-10-19  Saam Barati  <sbarati@apple.com>
1487
1488         Turn various poly proto RELEASE_ASSERTs into ASSERTs because they're on the hot path in speedometer
1489         https://bugs.webkit.org/show_bug.cgi?id=178529
1490
1491         Reviewed by Mark Lam.
1492
1493         * runtime/Structure.h:
1494         * runtime/StructureInlines.h:
1495         (JSC::Structure::storedPrototypeObject const):
1496         (JSC::Structure::storedPrototypeStructure const):
1497         (JSC::Structure::storedPrototype const):
1498         (JSC::Structure::prototypeForLookup const):
1499         (JSC::Structure::prototypeChain const):
1500
1501 2017-10-19  Saam Barati  <sbarati@apple.com>
1502
1503         Turn poly proto back on by default and remove the option
1504         https://bugs.webkit.org/show_bug.cgi?id=178525
1505
1506         Reviewed by Mark Lam.
1507
1508         I added this option because I thought it'd speed speedometer up because the
1509         original poly proto patch slowed speedometer down. It turns out that
1510         allocating poly proto objects is not what slows speedometer down. It's
1511         other code I added in the runtime that needs to be poly proto aware. I'll
1512         be addressing these in follow up patches.
1513
1514         * runtime/Options.h:
1515         * runtime/StructureInlines.h:
1516         (JSC::Structure::shouldConvertToPolyProto):
1517
1518 2017-10-19  Robin Morisset  <rmorisset@apple.com>
1519
1520         Turn recursive tail calls into loops
1521         https://bugs.webkit.org/show_bug.cgi?id=176601
1522
1523         Reviewed by Saam Barati.
1524
1525         We want to turn recursive tail calls into loops early in the pipeline, so that the loops can then be optimized.
1526         One difficulty is that we need to split the entry block of the function we are jumping to in order to have somewhere to jump to.
1527         Worse: it is not necessarily the first block of the codeBlock, because of inlining! So we must do the splitting in the DFGByteCodeParser, at the same time as inlining.
1528         We do this part through modifying the computation of the jump targets.
1529         Importantly, we only do this splitting for functions that have tail calls.
1530         It is the only case where the optimisation is sound, and doing the splitting unconditionnaly destroys performance on Octane/raytrace.
1531
1532         We must then do the actual transformation also in DFGByteCodeParser, to avoid code motion moving code out of the body of what will become a loop.
1533         The transformation is entirely contained in handleRecursiveTailCall, which is hooked to the inlining machinery.
1534
1535         * bytecode/CodeBlock.h:
1536         (JSC::CodeBlock::hasTailCalls const):
1537         * bytecode/PreciseJumpTargets.cpp:
1538         (JSC::getJumpTargetsForBytecodeOffset):
1539         (JSC::computePreciseJumpTargetsInternal):
1540         * bytecode/UnlinkedCodeBlock.cpp:
1541         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
1542         * bytecode/UnlinkedCodeBlock.h:
1543         (JSC::UnlinkedCodeBlock::hasTailCalls const):
1544         (JSC::UnlinkedCodeBlock::setHasTailCalls):
1545         * bytecompiler/BytecodeGenerator.cpp:
1546         (JSC::BytecodeGenerator::emitEnter):
1547         (JSC::BytecodeGenerator::emitCallInTailPosition):
1548         * dfg/DFGByteCodeParser.cpp:
1549         (JSC::DFG::ByteCodeParser::allocateTargetableBlock):
1550         (JSC::DFG::ByteCodeParser::makeBlockTargetable):
1551         (JSC::DFG::ByteCodeParser::handleCall):
1552         (JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
1553         (JSC::DFG::ByteCodeParser::parseBlock):
1554         (JSC::DFG::ByteCodeParser::parse):
1555
1556 2017-10-18  Mark Lam  <mark.lam@apple.com>
1557
1558         RegExpObject::defineOwnProperty() does not need to compare values if no descriptor value is specified.
1559         https://bugs.webkit.org/show_bug.cgi?id=177600
1560         <rdar://problem/34710985>
1561
1562         Reviewed by Saam Barati.
1563
1564         According to http://www.ecma-international.org/ecma-262/8.0/#sec-validateandapplypropertydescriptor,
1565         section 9.1.6.3-7.a.ii, we should only check if the value is the same if the
1566         descriptor value is present.
1567
1568         * runtime/RegExpObject.cpp:
1569         (JSC::RegExpObject::defineOwnProperty):
1570
1571 2017-10-18  Keith Miller  <keith_miller@apple.com>
1572
1573         Setup WebCore build to start using unified sources.
1574         https://bugs.webkit.org/show_bug.cgi?id=178362
1575
1576         Reviewed by Tim Horton.
1577
1578         Change comments in source list files. Also, pass explicit names for build files.
1579
1580         * CMakeLists.txt:
1581         * PlatformGTK.cmake:
1582         * PlatformMac.cmake:
1583         * Sources.txt:
1584         * SourcesGTK.txt:
1585         * SourcesMac.txt:
1586
1587 2017-10-18  Commit Queue  <commit-queue@webkit.org>
1588
1589         Unreviewed, rolling out r223321.
1590         https://bugs.webkit.org/show_bug.cgi?id=178476
1591
1592         This protocol change broke some internal builds (Requested by
1593         brrian__ on #webkit).
1594
1595         Reverted changeset:
1596
1597         "Web Inspector: provide a way to enable/disable event
1598         listeners"
1599         https://bugs.webkit.org/show_bug.cgi?id=177451
1600         https://trac.webkit.org/changeset/223321
1601
1602 2017-10-18  Mark Lam  <mark.lam@apple.com>
1603
1604         The compiler should always register a structure when it adds its transitionWatchPointSet.
1605         https://bugs.webkit.org/show_bug.cgi?id=178420
1606         <rdar://problem/34814024>
1607
1608         Reviewed by Saam Barati and Filip Pizlo.
1609
1610         Instead of invoking addLazily() to add a structure's transitionWatchpointSet, we
1611         now invoke Graph::registerAndWatchStructureTransition() on the structure.
1612         registerAndWatchStructureTransition() both registers the structure and add its
1613         transitionWatchpointSet to the plan desired watchpoints.
1614
1615         Graph::registerAndWatchStructureTransition() is based on Graph::registerStructure()
1616         except registerAndWatchStructureTransition() adds the structure's
1617         transitionWatchpointSet unconditionally.
1618
1619         * dfg/DFGArgumentsEliminationPhase.cpp:
1620         * dfg/DFGArrayMode.cpp:
1621         (JSC::DFG::ArrayMode::refine const):
1622         * dfg/DFGByteCodeParser.cpp:
1623         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
1624         * dfg/DFGFixupPhase.cpp:
1625         (JSC::DFG::FixupPhase::fixupNode):
1626
1627         * dfg/DFGGraph.cpp:
1628         (JSC::DFG::Graph::registerAndWatchStructureTransition):
1629         * dfg/DFGGraph.h:
1630
1631         * dfg/DFGSpeculativeJIT.cpp:
1632         (JSC::DFG::SpeculativeJIT::compileGetByValOnString):
1633         - The second set of addLazily()s is redundant.  This set is executed only when
1634           prototypeChainIsSane is true, and prototypeChainIsSane can only be true if and
1635           only if we've executed the if statement above it.  That preceding if statement
1636           already registerAndWatchStructureTransition() the same 2 structures.  Hence,
1637           this second set can be deleted.
1638
1639         * dfg/DFGWatchpointCollectionPhase.cpp:
1640         (JSC::DFG::WatchpointCollectionPhase::addLazily):
1641         - Deleted an unused function.
1642
1643         * ftl/FTLLowerDFGToB3.cpp:
1644         (JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
1645
1646 2017-10-18  Yusuke Suzuki  <utatane.tea@gmail.com>
1647
1648         [JSC] Remove unused private name structure
1649         https://bugs.webkit.org/show_bug.cgi?id=178436
1650
1651         Reviewed by Sam Weinig.
1652
1653         It is no longer used. This patch just removes it.
1654
1655         * runtime/JSGlobalObject.h:
1656         (JSC::JSGlobalObject::numberObjectStructure const):
1657         (JSC::JSGlobalObject::privateNameStructure const): Deleted.
1658
1659 2017-10-18  Ryosuke Niwa  <rniwa@webkit.org>
1660
1661         Fix macOS and iOS builds after r223594.
1662
1663         * JavaScriptCore.xcodeproj/project.pbxproj:
1664
1665 2017-10-18  Yusuke Suzuki  <utatane.tea@gmail.com>
1666
1667         [JSC] __proto__ getter should be fast
1668         https://bugs.webkit.org/show_bug.cgi?id=178067
1669
1670         Reviewed by Saam Barati.
1671
1672         In our ES6 class implementation, we access __proto__ field to retrieve super constructor.
1673         Currently, it is handled as an usual getter call to a generic function. And DFG just emits
1674         Call node for this. It is inefficient since typically we know the `prototype` of the given
1675         object when accessing `object.__proto__` since we emit CheckStructure for this `object`.
1676         If Structure has mono proto, we can immediately fold it to constant value. If it is poly proto,
1677         we can still change this to efficient access to poly proto slot.
1678
1679         This patch implements GetPrototypeOf DFG node. This node efficiently accesses to prototype of
1680         the given object. And in AI and ByteCodeParser phase, we attempt to fold it to constant.
1681         ByteCodeParser's folding is a bit important since we have `callee.__proto__` code to get super
1682         constructor. If we can change this to constant, we can reify CallLinkInfo with this constant.
1683         This paves the way to optimizing ArrayConstructor super calls[1], which is particularly important
1684         for ARES-6 ML.
1685
1686         And we also optimize Reflect.getPrototypeOf and Object.getPrototypeOf with this GetPrototypeOf node.
1687
1688         Currently, __proto__ access for poly proto object is not handled well in IC. But we add code handling
1689         poly proto in GetPrototypeOf since Reflect.getPrototypeOf and Object.getPrototypeOf can use it.
1690         Once IC starts handling poly proto & intrinsic getter well, this code will be used for that too.
1691
1692         This patch improves SixSpeed super.es6 by 3.42x.
1693
1694                                  baseline                  patched
1695
1696         super.es6           123.6666+-3.9917     ^     36.1684+-1.0351        ^ definitely 3.4192x faster
1697
1698         [1]: https://bugs.webkit.org/show_bug.cgi?id=178064
1699
1700         * dfg/DFGAbstractInterpreterInlines.h:
1701         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1702         * dfg/DFGByteCodeParser.cpp:
1703         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
1704         (JSC::DFG::ByteCodeParser::handleIntrinsicGetter):
1705         (JSC::DFG::ByteCodeParser::handleGetById):
1706         * dfg/DFGClobberize.h:
1707         (JSC::DFG::clobberize):
1708         * dfg/DFGDoesGC.cpp:
1709         (JSC::DFG::doesGC):
1710         * dfg/DFGFixupPhase.cpp:
1711         (JSC::DFG::FixupPhase::fixupNode):
1712         (JSC::DFG::FixupPhase::fixupGetPrototypeOf):
1713         * dfg/DFGHeapLocation.cpp:
1714         (WTF::printInternal):
1715         * dfg/DFGHeapLocation.h:
1716         * dfg/DFGNode.h:
1717         (JSC::DFG::Node::hasHeapPrediction):
1718         (JSC::DFG::Node::shouldSpeculateFunction):
1719         * dfg/DFGNodeType.h:
1720         * dfg/DFGOperations.cpp:
1721         * dfg/DFGOperations.h:
1722         * dfg/DFGPredictionPropagationPhase.cpp:
1723         * dfg/DFGSafeToExecute.h:
1724         (JSC::DFG::safeToExecute):
1725         * dfg/DFGSpeculativeJIT.cpp:
1726         (JSC::DFG::SpeculativeJIT::speculateFunction):
1727         (JSC::DFG::SpeculativeJIT::speculateFinalObject):
1728         (JSC::DFG::SpeculativeJIT::compileGetPrototypeOf):
1729         * dfg/DFGSpeculativeJIT.h:
1730         (JSC::DFG::SpeculativeJIT::callOperation):
1731         * dfg/DFGSpeculativeJIT32_64.cpp:
1732         (JSC::DFG::SpeculativeJIT::compile):
1733         * dfg/DFGSpeculativeJIT64.cpp:
1734         (JSC::DFG::SpeculativeJIT::compile):
1735         * ftl/FTLCapabilities.cpp:
1736         (JSC::FTL::canCompile):
1737         * ftl/FTLLowerDFGToB3.cpp:
1738         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1739         (JSC::FTL::DFG::LowerDFGToB3::compileGetPrototypeOf):
1740         (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
1741         * jit/IntrinsicEmitter.cpp:
1742         (JSC::IntrinsicGetterAccessCase::canEmitIntrinsicGetter):
1743         (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter):
1744         * jit/JITOperations.h:
1745         * runtime/Intrinsic.cpp:
1746         (JSC::intrinsicName):
1747         * runtime/Intrinsic.h:
1748         * runtime/JSGlobalObject.cpp:
1749         (JSC::JSGlobalObject::init):
1750         * runtime/JSGlobalObject.h:
1751         (JSC::JSGlobalObject::booleanPrototype const):
1752         (JSC::JSGlobalObject::numberPrototype const):
1753         (JSC::JSGlobalObject::booleanObjectStructure const):
1754         * runtime/JSGlobalObjectFunctions.cpp:
1755         (JSC::globalFuncProtoGetter):
1756         * runtime/JSGlobalObjectFunctions.h:
1757         * runtime/ObjectConstructor.cpp:
1758         * runtime/ReflectObject.cpp:
1759
1760 2017-10-17  Ryan Haddad  <ryanhaddad@apple.com>
1761
1762         Unreviewed, rolling out r223523.
1763
1764         A test for this change is failing on debug JSC bots.
1765
1766         Reverted changeset:
1767
1768         "[JSC] __proto__ getter should be fast"
1769         https://bugs.webkit.org/show_bug.cgi?id=178067
1770         https://trac.webkit.org/changeset/223523
1771
1772 2017-10-17  Youenn Fablet  <youenn@apple.com>
1773
1774         Add preliminary support for fetch event
1775         https://bugs.webkit.org/show_bug.cgi?id=178171
1776
1777         Reviewed by Chris Dumez.
1778
1779         Adding events
1780
1781         * runtime/JSPromise.h:
1782
1783 2017-10-10  Yusuke Suzuki  <utatane.tea@gmail.com>
1784
1785         [JSC] __proto__ getter should be fast
1786         https://bugs.webkit.org/show_bug.cgi?id=178067
1787
1788         Reviewed by Saam Barati.
1789
1790         In our ES6 class implementation, we access __proto__ field to retrieve super constructor.
1791         Currently, it is handled as an usual getter call to a generic function. And DFG just emits
1792         Call node for this. It is inefficient since typically we know the `prototype` of the given
1793         object when accessing `object.__proto__` since we emit CheckStructure for this `object`.
1794         If Structure has mono proto, we can immediately fold it to constant value. If it is poly proto,
1795         we can still change this to efficient access to poly proto slot.
1796
1797         This patch implements GetPrototypeOf DFG node. This node efficiently accesses to prototype of
1798         the given object. And in AI and ByteCodeParser phase, we attempt to fold it to constant.
1799         ByteCodeParser's folding is a bit important since we have `callee.__proto__` code to get super
1800         constructor. If we can change this to constant, we can reify CallLinkInfo with this constant.
1801         This paves the way to optimizing ArrayConstructor super calls[1], which is particularly important
1802         for ARES-6 ML.
1803
1804         And we also optimize Reflect.getPrototypeOf and Object.getPrototypeOf with this GetPrototypeOf node.
1805
1806         Currently, __proto__ access for poly proto object is not handled well in IC. But we add code handling
1807         poly proto in GetPrototypeOf since Reflect.getPrototypeOf and Object.getPrototypeOf can use it.
1808         Once IC starts handling poly proto & intrinsic getter well, this code will be used for that too.
1809
1810         This patch improves SixSpeed super.es6 by 3.42x.
1811
1812                                  baseline                  patched
1813
1814         super.es6           123.6666+-3.9917     ^     36.1684+-1.0351        ^ definitely 3.4192x faster
1815
1816         [1]: https://bugs.webkit.org/show_bug.cgi?id=178064
1817
1818         * dfg/DFGAbstractInterpreterInlines.h:
1819         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
1820         * dfg/DFGByteCodeParser.cpp:
1821         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
1822         (JSC::DFG::ByteCodeParser::handleIntrinsicGetter):
1823         (JSC::DFG::ByteCodeParser::handleGetById):
1824         * dfg/DFGClobberize.h:
1825         (JSC::DFG::clobberize):
1826         * dfg/DFGDoesGC.cpp:
1827         (JSC::DFG::doesGC):
1828         * dfg/DFGFixupPhase.cpp:
1829         (JSC::DFG::FixupPhase::fixupNode):
1830         (JSC::DFG::FixupPhase::fixupGetPrototypeOf):
1831         * dfg/DFGHeapLocation.cpp:
1832         (WTF::printInternal):
1833         * dfg/DFGHeapLocation.h:
1834         * dfg/DFGNode.h:
1835         (JSC::DFG::Node::hasHeapPrediction):
1836         (JSC::DFG::Node::shouldSpeculateFunction):
1837         * dfg/DFGNodeType.h:
1838         * dfg/DFGOperations.cpp:
1839         * dfg/DFGOperations.h:
1840         * dfg/DFGPredictionPropagationPhase.cpp:
1841         * dfg/DFGSafeToExecute.h:
1842         (JSC::DFG::safeToExecute):
1843         * dfg/DFGSpeculativeJIT.cpp:
1844         (JSC::DFG::SpeculativeJIT::speculateFunction):
1845         (JSC::DFG::SpeculativeJIT::speculateFinalObject):
1846         (JSC::DFG::SpeculativeJIT::compileGetPrototypeOf):
1847         * dfg/DFGSpeculativeJIT.h:
1848         * dfg/DFGSpeculativeJIT32_64.cpp:
1849         (JSC::DFG::SpeculativeJIT::compile):
1850         * dfg/DFGSpeculativeJIT64.cpp:
1851         (JSC::DFG::SpeculativeJIT::compile):
1852         * ftl/FTLCapabilities.cpp:
1853         (JSC::FTL::canCompile):
1854         * ftl/FTLLowerDFGToB3.cpp:
1855         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
1856         (JSC::FTL::DFG::LowerDFGToB3::compileGetPrototypeOf):
1857         (JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
1858         * jit/IntrinsicEmitter.cpp:
1859         (JSC::IntrinsicGetterAccessCase::canEmitIntrinsicGetter):
1860         (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter):
1861         * runtime/Intrinsic.cpp:
1862         (JSC::intrinsicName):
1863         * runtime/Intrinsic.h:
1864         * runtime/JSGlobalObject.cpp:
1865         (JSC::JSGlobalObject::init):
1866         * runtime/JSGlobalObjectFunctions.cpp:
1867         (JSC::globalFuncProtoGetter):
1868         * runtime/JSGlobalObjectFunctions.h:
1869         * runtime/ObjectConstructor.cpp:
1870         * runtime/ReflectObject.cpp:
1871
1872 2017-10-17  Keith Miller  <keith_miller@apple.com>
1873
1874         Change WebCore sources to work with unified source builds
1875         https://bugs.webkit.org/show_bug.cgi?id=178229
1876
1877         Rubber stamped by Tim Horton.
1878
1879         * Configurations/FeatureDefines.xcconfig:
1880
1881 2017-10-15  Filip Pizlo  <fpizlo@apple.com>
1882
1883         Make some asserts into release asserts
1884         https://bugs.webkit.org/show_bug.cgi?id=178324
1885
1886         Reviewed by Saam Barati.
1887
1888         These asserts are not on perf critical paths, so they might as well be release asserts.
1889
1890         * runtime/DataView.h:
1891         (JSC::DataView::get):
1892         (JSC::DataView::set):
1893
1894 2017-10-16  JF Bastien  <jfbastien@apple.com>
1895
1896         JSRunLoopTimer: reduce likely race when used improperly
1897         https://bugs.webkit.org/show_bug.cgi?id=178298
1898         <rdar://problem/32899816>
1899
1900         Reviewed by Saam Barati.
1901
1902         If an API user sets a timer on JSRunLoopTimer, and then racily
1903         destroys the JSRunLoopTimer while the timer is firing then it's
1904         possible for timerDidFire to cause a use-after-free and / or crash
1905         because e.g. m_apiLock becomes a nullptr while timerDidFire is
1906         executing. That results from an invalid use of JSRunLoopTimer, but
1907         we should try to be more resilient for that type of misuse because
1908         it's not necessarily easy to catch by inspection.
1909
1910         With this change the only remaining race is if the timer fires,
1911         and then only timerDidFire's prologue executes, but not the load
1912         of the m_apiLock pointer from `this`. It's a much smaller race.
1913
1914         Separately, I'll reach out to API users who are seemingly misusing
1915         the API.
1916
1917         * runtime/JSRunLoopTimer.cpp:
1918         (JSC::JSRunLoopTimer::timerDidFire): put m_apiLock on the stack,
1919         and checks for nullptr. This prevents loading it twice off of
1920         `this` and turns a nullptr deref into "just" a use-after-free.
1921         (JSC::JSRunLoopTimer::~JSRunLoopTimer): acquire m_apiLock before
1922         calling m_vm->unregisterRunLoopTimer(this), which in turn does
1923         CFRunLoopRemoveTimer / CFRunLoopTimerInvalidate. This prevents
1924         timerDidFire from doing much while the timers are un-registered.
1925         ~JSRunLoopTimer also needs to set m_apiLock to nullptr before
1926         releasing the lock, so it needs its own local copy.
1927
1928 2017-10-15  Yusuke Suzuki  <utatane.tea@gmail.com>
1929
1930         [JSC] Perform module specifier validation at parsing time
1931         https://bugs.webkit.org/show_bug.cgi?id=178256
1932
1933         Reviewed by Darin Adler.
1934
1935         This patch make module loader's `resolve` operation synchronous. And we validate
1936         module's requested module names when instantiating the module instead of satisfying
1937         module's dependencies. This change is not observable to users. But this is precise
1938         to the spec and this optimizes & simplifies the current module loader a bit by
1939         reducing object allocations.
1940
1941         Previously, we have an object called pair in the module loader. This is pair of
1942         module's name and module's record. And we use it to link one module to dependent
1943         modules. Now, it is replaced with module's registry entry.
1944
1945         We also change our loader functions to take a registry entry instead of a module key.
1946         Previous design is due to the consideration that these APIs may be exposed to users
1947         in whatwg/loader spec. However, this won't happen. This change removes unnecessary
1948         repeatedly hash map lookups.
1949
1950         * builtins/ModuleLoaderPrototype.js:
1951         (globalPrivate.newRegistryEntry):
1952         (requestFetch):
1953         (requestInstantiate):
1954         (requestSatisfy):
1955         (link):
1956         (moduleEvaluation):
1957         (loadModule):
1958         * jsc.cpp:
1959         (GlobalObject::moduleLoaderResolve):
1960         * runtime/AbstractModuleRecord.cpp:
1961         (JSC::AbstractModuleRecord::finishCreation):
1962         (JSC::AbstractModuleRecord::hostResolveImportedModule):
1963         * runtime/JSGlobalObject.h:
1964         * runtime/JSModuleLoader.cpp:
1965         (JSC::JSModuleLoader::resolveSync):
1966         (JSC::JSModuleLoader::resolve):
1967         * runtime/JSModuleLoader.h:
1968         * runtime/ModuleLoaderPrototype.cpp:
1969         (JSC::moduleLoaderPrototypeResolveSync):
1970
1971 2017-10-14  Devin Rousso  <webkit@devinrousso.com>
1972
1973         Web Inspector: provide a way to enable/disable event listeners
1974         https://bugs.webkit.org/show_bug.cgi?id=177451
1975
1976         Reviewed by Joseph Pecoraro.
1977
1978         * inspector/protocol/DOM.json:
1979         Add `setEventListenerDisabled` command that enables/disables a specific event listener
1980         during event dispatch. When a disabled event listener is fired, the listener's callback will
1981         not be called.
1982
1983 2017-10-14  Yusuke Suzuki  <utatane.tea@gmail.com>
1984
1985         Reland "Add Above/Below comparisons for UInt32 patterns"
1986         https://bugs.webkit.org/show_bug.cgi?id=177281
1987
1988         Reviewed by Saam Barati.
1989
1990         We reland this patch without DFGStrengthReduction change to see what causes
1991         regression in the iOS bot.
1992
1993         Sometimes, we would like to have UInt32 operations in JS. While VM does
1994         not support UInt32 nicely, VM supports efficient Int32 operations. As long
1995         as signedness does not matter, we can just perform Int32 operations instead
1996         and recognize its bit pattern as UInt32.
1997
1998         But of course, some operations respect signedness. The most frequently
1999         used one is comparison. Octane/zlib performs UInt32 comparison by performing
2000         `val >>> 0`. It emits op_urshift and op_unsigned. op_urshift produces
2001         UInt32 in Int32 form. And op_unsigned will generate Double value if
2002         the generated Int32 is < 0 (which should be UInt32).
2003
2004         There is a chance for optimization. The given code pattern is the following.
2005
2006             op_unsigned(op_urshift(@1)) lessThan:< op_unsigned(op_urshift(@2))
2007
2008         This can be converted to the following.
2009
2010             op_urshift(@1) below:< op_urshift(@2)
2011
2012         The above conversion is nice since
2013
2014         1. We can avoid op_unsigned. This could be unsignedness check in DFG. Since
2015         this check depends on the value of Int32, dropping this check is not as easy as
2016         removing Int32 edge filters.
2017
2018         2. We can perform unsigned comparison in Int32 form. We do not need to convert
2019         them to DoubleRep.
2020
2021         Since the above comparison exists in Octane/zlib's *super* hot path, dropping
2022         op_unsigned offers huge win.
2023
2024         At first, my patch attempts to convert the above thing in DFG pipeline.
2025         However it poses several problems.
2026
2027         1. MovHint is not well removed. It makes UInt32ToNumber (which is for op_unsigned) live.
2028         2. UInt32ToNumber could cause an OSR exit. So if we have the following nodes,
2029
2030             2: UInt32ToNumber(@0)
2031             3: MovHint(@2, xxx)
2032             4: UInt32ToNumber(@1)
2033             5: MovHint(@1, xxx)
2034
2035         we could drop @5's MovHint. But @3 is difficult since @4 can exit.
2036
2037         So, instead, we start introducing a simple optimization in the bytecode compiler.
2038         It performs pattern matching for op_urshift and comparison to drop op_unsigned.
2039         We adds op_below and op_above families to bytecodes. They only accept Int32 and
2040         perform unsigned comparison.
2041
2042         This offers 4% performance improvement in Octane/zlib.
2043
2044                                     baseline                  patched
2045
2046         zlib           x2     431.07483+-16.28434       414.33407+-9.38375         might be 1.0404x faster
2047
2048         * bytecode/BytecodeDumper.cpp:
2049         (JSC::BytecodeDumper<Block>::printCompareJump):
2050         (JSC::BytecodeDumper<Block>::dumpBytecode):
2051         * bytecode/BytecodeDumper.h:
2052         * bytecode/BytecodeList.json:
2053         * bytecode/BytecodeUseDef.h:
2054         (JSC::computeUsesForBytecodeOffset):
2055         (JSC::computeDefsForBytecodeOffset):
2056         * bytecode/Opcode.h:
2057         (JSC::isBranch):
2058         * bytecode/PreciseJumpTargetsInlines.h:
2059         (JSC::extractStoredJumpTargetsForBytecodeOffset):
2060         * bytecompiler/BytecodeGenerator.cpp:
2061         (JSC::BytecodeGenerator::emitJumpIfTrue):
2062         (JSC::BytecodeGenerator::emitJumpIfFalse):
2063         * bytecompiler/NodesCodegen.cpp:
2064         (JSC::BinaryOpNode::emitBytecode):
2065         * dfg/DFGAbstractInterpreterInlines.h:
2066         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2067         * dfg/DFGByteCodeParser.cpp:
2068         (JSC::DFG::ByteCodeParser::parseBlock):
2069         * dfg/DFGCapabilities.cpp:
2070         (JSC::DFG::capabilityLevel):
2071         * dfg/DFGClobberize.h:
2072         (JSC::DFG::clobberize):
2073         * dfg/DFGDoesGC.cpp:
2074         (JSC::DFG::doesGC):
2075         * dfg/DFGFixupPhase.cpp:
2076         (JSC::DFG::FixupPhase::fixupNode):
2077         * dfg/DFGIntegerRangeOptimizationPhase.cpp:
2078         * dfg/DFGNodeType.h:
2079         * dfg/DFGPredictionPropagationPhase.cpp:
2080         * dfg/DFGSafeToExecute.h:
2081         (JSC::DFG::safeToExecute):
2082         * dfg/DFGSpeculativeJIT.cpp:
2083         (JSC::DFG::SpeculativeJIT::compileCompareUnsigned):
2084         * dfg/DFGSpeculativeJIT.h:
2085         * dfg/DFGSpeculativeJIT32_64.cpp:
2086         (JSC::DFG::SpeculativeJIT::compile):
2087         * dfg/DFGSpeculativeJIT64.cpp:
2088         (JSC::DFG::SpeculativeJIT::compile):
2089         * dfg/DFGValidate.cpp:
2090         * ftl/FTLCapabilities.cpp:
2091         (JSC::FTL::canCompile):
2092         * ftl/FTLLowerDFGToB3.cpp:
2093         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2094         (JSC::FTL::DFG::LowerDFGToB3::compileCompareBelow):
2095         (JSC::FTL::DFG::LowerDFGToB3::compileCompareBelowEq):
2096         * jit/JIT.cpp:
2097         (JSC::JIT::privateCompileMainPass):
2098         * jit/JIT.h:
2099         * jit/JITArithmetic.cpp:
2100         (JSC::JIT::emit_op_below):
2101         (JSC::JIT::emit_op_beloweq):
2102         (JSC::JIT::emit_op_jbelow):
2103         (JSC::JIT::emit_op_jbeloweq):
2104         (JSC::JIT::emit_compareUnsignedAndJump):
2105         (JSC::JIT::emit_compareUnsigned):
2106         * jit/JITArithmetic32_64.cpp:
2107         (JSC::JIT::emit_compareUnsignedAndJump):
2108         (JSC::JIT::emit_compareUnsigned):
2109         * llint/LowLevelInterpreter.asm:
2110         * llint/LowLevelInterpreter32_64.asm:
2111         * llint/LowLevelInterpreter64.asm:
2112         * parser/Nodes.h:
2113         (JSC::ExpressionNode::isBinaryOpNode const):
2114
2115 2017-10-12  Yusuke Suzuki  <utatane.tea@gmail.com>
2116
2117         WebAssembly: Wasm functions should have either JSFunctionType or TypeOfShouldCallGetCallData
2118         https://bugs.webkit.org/show_bug.cgi?id=178210
2119
2120         Reviewed by Saam Barati.
2121
2122         In Wasm, we have two JS functions exposed to users: WebAssemblyFunction and WebAssemblyWrapperFunction.
2123         The former is an exported wasm function and the latter is an imported & exported function. Since they
2124         have [[Call]], they should be categorized into "function" in typeof operation.
2125
2126         However, these functions do not implement our function protocol correctly. They inherit JSFunction.
2127         But JSType of WebAssemblyFunction is WebAssemblyFunctionType, and one of WebAssemblyWrapperFunction is
2128         ObjectType. Since both do not have TypeOfShouldCallGetCallData, they return "object" when performing
2129         typeof operation.
2130
2131         In this patch, we address the above issue by the following 2 fixes.
2132
2133         1. We add TypeOfShouldCallGetCallData to WebAssemblyFunction. This is the same way how we implement
2134         InternalFunction. Since WebAssemblyFunction requires WebAssemblyFunctionType for fast checking in Wasm
2135         implementation, we cannot make this JSFunctionType.
2136
2137         2. On the other hand, WebAssemblyWrapperFunction does not require a specific JSType. So this patch
2138         changes JSType of WebAssemblyWrapperFunction to JSFunctionType. JSFunctionType can be usable for derived
2139         classes of JSFunction (e.g. JSCustomGetterSetterFunction).
2140
2141         * wasm/js/WebAssemblyFunction.h:
2142         (JSC::WebAssemblyFunction::signatureIndex const): Deleted.
2143         (JSC::WebAssemblyFunction::wasmEntrypointLoadLocation const): Deleted.
2144         (JSC::WebAssemblyFunction::callableFunction const): Deleted.
2145         (JSC::WebAssemblyFunction::jsEntrypoint): Deleted.
2146         (JSC::WebAssemblyFunction::offsetOfWasmEntrypointLoadLocation): Deleted.
2147         * wasm/js/WebAssemblyWrapperFunction.cpp:
2148         (JSC::WebAssemblyWrapperFunction::createStructure):
2149         * wasm/js/WebAssemblyWrapperFunction.h:
2150         (JSC::WebAssemblyWrapperFunction::signatureIndex const): Deleted.
2151         (JSC::WebAssemblyWrapperFunction::wasmEntrypointLoadLocation const): Deleted.
2152         (JSC::WebAssemblyWrapperFunction::callableFunction const): Deleted.
2153         (JSC::WebAssemblyWrapperFunction::function): Deleted.
2154
2155 2017-10-12  Per Arne Vollan  <pvollan@apple.com>
2156
2157         [Win64] JSC compile error.
2158         https://bugs.webkit.org/show_bug.cgi?id=178213
2159
2160         Reviewed by Alex Christensen.
2161
2162         Add static cast from int64 to uintptr_t.
2163
2164         * dfg/DFGOSRExit.cpp:
2165         (JSC::DFG::OSRExit::executeOSRExit):
2166
2167 2017-09-29  Filip Pizlo  <fpizlo@apple.com>
2168
2169         Enable gigacage on iOS
2170         https://bugs.webkit.org/show_bug.cgi?id=177586
2171
2172         Reviewed by JF Bastien.
2173
2174         The hardest part of enabling Gigacage on iOS is that it requires loading global variables while
2175         executing JS, so the LLInt needs to know how to load from global variables on all platforms that
2176         have Gigacage. So, this teaches ARM64 how to load from global variables.
2177
2178         Also, this makes the code handle disabling the gigacage a bit better.
2179
2180         * ftl/FTLLowerDFGToB3.cpp:
2181         (JSC::FTL::DFG::LowerDFGToB3::caged):
2182         * jit/AssemblyHelpers.h:
2183         (JSC::AssemblyHelpers::cage):
2184         (JSC::AssemblyHelpers::cageConditionally):
2185         * offlineasm/arm64.rb:
2186         * offlineasm/asm.rb:
2187         * offlineasm/instructions.rb:
2188
2189 2017-10-11  Sam Weinig  <sam@webkit.org>
2190
2191         Remove out-parameter variants of copyToVector
2192         https://bugs.webkit.org/show_bug.cgi?id=178155
2193
2194         Reviewed by Tim Horton.
2195
2196         * inspector/ScriptDebugServer.cpp:
2197         (Inspector::ScriptDebugServer::dispatchBreakpointActionLog):
2198         (Inspector::ScriptDebugServer::dispatchBreakpointActionSound):
2199         (Inspector::ScriptDebugServer::dispatchBreakpointActionProbe):
2200         (Inspector::ScriptDebugServer::dispatchDidParseSource):
2201         (Inspector::ScriptDebugServer::dispatchFailedToParseSource):
2202         (Inspector::ScriptDebugServer::dispatchFunctionToListeners):
2203
2204             Replace out-parameter based copyToVector, with one that returns a Vector.
2205
2206 2017-10-12  Yusuke Suzuki  <utatane.tea@gmail.com>
2207
2208         Support integrity="" on module scripts
2209         https://bugs.webkit.org/show_bug.cgi?id=177959
2210
2211         Reviewed by Sam Weinig.
2212
2213         This patch adds Subresource Integrity check for module scripts. Currently,
2214         only top-level module can be verified with integrity parameter since there
2215         is no way to perform integrity check onto the imported modules.
2216
2217         In JSC side, we add `parameters` to the entry point of the module loader
2218         pipeline. This is fetching parameters and used when fetching modules.
2219
2220         We separately pass this parameters to the pipeline along with the script fetcher.
2221         The script fetcher is only one for module graph since this is the initiator of
2222         this module graph loading. On the other hand, this parameters is for each
2223         module fetching. While setting "integrity" parameters to this script fetcher is
2224         sufficient to pass parameters to top-level-module's fetching, it is not enough
2225         for the future extension.
2226
2227         In the future, we will investigate a way to pass parameters to each non-top-level
2228         module. At that time, this `parameters` should be per-module. This is because
2229         "integrity" value should be different for each module. For example, we will accept
2230         some form of syntax to add parameters to `import`. Some proposed syntax is like
2231         https://discourse.wicg.io/t/specifying-nonce-or-integrity-when-importing-modules/1861
2232
2233         import "./xxx.js" integrity "xxxxxxx"
2234
2235         In this case, this `parameters` will be passed to "./xxx.js" module fetching. This
2236         `parameters` should be different from the one of top-level-module's one. That's why
2237         we need per-module `parameters` and why this patch adds `parameters` to the module pipeline.
2238
2239         On the other hand, we also want to keep script fetcher. This `per-module-graph` thing
2240         is important to offer module-graph-wide information. For example, import.meta would
2241         have `import.meta.scriptElement`, which is the script element fetching the module graph
2242         including this. So, we keep the both, script fetcher and parameters.
2243         https://github.com/tc39/proposal-import-meta
2244
2245         This parameters will be finally used by pipeline's fetch hook, and WebCore side
2246         can use this parameters to fetch modules.
2247
2248         We also further clean up the module pipeline by dropping unnecessary features.
2249
2250         * JavaScriptCore.xcodeproj/project.pbxproj:
2251         * Sources.txt:
2252         * builtins/ModuleLoaderPrototype.js:
2253         (requestFetch):
2254         (requestInstantiate):
2255         (requestSatisfy):
2256         (loadModule):
2257         (loadAndEvaluateModule):
2258         This loadAndEvaluateModule should be implemented by just calling loadModule and
2259         linkAndEvaluateModule. We can drop requestReady and requestLink.
2260
2261         (requestLink): Deleted.
2262         (requestImportModule): Deleted.
2263         * jsc.cpp:
2264         (GlobalObject::moduleLoaderImportModule):
2265         (GlobalObject::moduleLoaderFetch):
2266         import and fetch hook takes parameters. Currently, we always pass `undefined` for
2267         import hook. When dynamic `import()` is extended to accept additional parameters
2268         like integrity, this parameters will be replaced with the actual value.
2269
2270         (functionLoadModule):
2271         (runWithOptions):
2272         * runtime/Completion.cpp:
2273         (JSC::loadAndEvaluateModule):
2274         (JSC::loadModule):
2275         (JSC::importModule):
2276         * runtime/Completion.h:
2277         * runtime/JSGlobalObject.h:
2278         * runtime/JSGlobalObjectFunctions.cpp:
2279         (JSC::globalFuncImportModule):
2280         * runtime/JSModuleLoader.cpp:
2281         (JSC::JSModuleLoader::loadAndEvaluateModule):
2282         (JSC::JSModuleLoader::loadModule):
2283         (JSC::JSModuleLoader::requestImportModule):
2284         (JSC::JSModuleLoader::importModule):
2285         (JSC::JSModuleLoader::fetch):
2286         * runtime/JSModuleLoader.h:
2287         * runtime/JSScriptFetchParameters.cpp: Added.
2288         (JSC::JSScriptFetchParameters::destroy):
2289         * runtime/JSScriptFetchParameters.h: Added.
2290         (JSC::JSScriptFetchParameters::createStructure):
2291         (JSC::JSScriptFetchParameters::create):
2292         (JSC::JSScriptFetchParameters::parameters const):
2293         (JSC::JSScriptFetchParameters::JSScriptFetchParameters):
2294         Add ScriptFetchParameters' JSCell wrapper, JSScriptFetchParameters.
2295         It is used in the module pipeline.
2296
2297         * runtime/JSType.h:
2298         * runtime/ModuleLoaderPrototype.cpp:
2299         (JSC::moduleLoaderPrototypeFetch):
2300         * runtime/ScriptFetchParameters.h: Added.
2301         (JSC::ScriptFetchParameters::~ScriptFetchParameters):
2302         Add ScriptFetchParameters. We can define our own custom ScriptFetchParameters
2303         by inheriting this class. WebCore creates ModuleFetchParameters by inheriting
2304         this.
2305
2306         * runtime/VM.cpp:
2307         (JSC::VM::VM):
2308         * runtime/VM.h:
2309
2310 2017-10-11  Yusuke Suzuki  <utatane.tea@gmail.com>
2311
2312         import.meta should not be assignable
2313         https://bugs.webkit.org/show_bug.cgi?id=178202
2314
2315         Reviewed by Saam Barati.
2316
2317         `import.meta` cannot be used for LHS. This patch adds MetaPropertyNode
2318         and make NewTargetNode and ImportMetaNode as derived classes of MetaPropertyNode.
2319         We change the parser not to allow assignments for MetaPropertyNode.
2320
2321         * bytecompiler/NodesCodegen.cpp:
2322         (JSC::ImportMetaNode::emitBytecode):
2323         * parser/ASTBuilder.h:
2324         (JSC::ASTBuilder::createImportMetaExpr):
2325         (JSC::ASTBuilder::isMetaProperty):
2326         (JSC::ASTBuilder::isImportMeta):
2327         * parser/NodeConstructors.h:
2328         (JSC::MetaPropertyNode::MetaPropertyNode):
2329         (JSC::NewTargetNode::NewTargetNode):
2330         (JSC::ImportMetaNode::ImportMetaNode):
2331         * parser/Nodes.h:
2332         (JSC::ExpressionNode::isMetaProperty const):
2333         (JSC::ExpressionNode::isImportMeta const):
2334         * parser/Parser.cpp:
2335         (JSC::Parser<LexerType>::metaPropertyName):
2336         (JSC::Parser<LexerType>::parseAssignmentExpression):
2337         (JSC::Parser<LexerType>::parseMemberExpression):
2338         (JSC::Parser<LexerType>::parseUnaryExpression):
2339         * parser/Parser.h:
2340         * parser/SyntaxChecker.h:
2341         (JSC::SyntaxChecker::createImportMetaExpr):
2342         (JSC::SyntaxChecker::isMetaProperty):
2343         (JSC::SyntaxChecker::isImportMeta):
2344
2345 2017-10-11  Saam Barati  <sbarati@apple.com>
2346
2347         Runtime disable poly proto because it may be a 3-4% Speedometer regression
2348         https://bugs.webkit.org/show_bug.cgi?id=178192
2349
2350         Reviewed by JF Bastien.
2351
2352         * runtime/Options.h:
2353         * runtime/StructureInlines.h:
2354         (JSC::Structure::shouldConvertToPolyProto):
2355
2356 2017-10-11  Commit Queue  <commit-queue@webkit.org>
2357
2358         Unreviewed, rolling out r223113 and r223121.
2359         https://bugs.webkit.org/show_bug.cgi?id=178182
2360
2361         Reintroduced 20% regression on Kraken (Requested by rniwa on
2362         #webkit).
2363
2364         Reverted changesets:
2365
2366         "Enable gigacage on iOS"
2367         https://bugs.webkit.org/show_bug.cgi?id=177586
2368         https://trac.webkit.org/changeset/223113
2369
2370         "Use one virtual allocation for all gigacages and their
2371         runways"
2372         https://bugs.webkit.org/show_bug.cgi?id=178050
2373         https://trac.webkit.org/changeset/223121
2374
2375 2017-10-11  Michael Saboff  <msaboff@apple.com>
2376
2377         Update JavaScriptCore/ucd/CaseFolding.txt to Unicode database 10.0
2378         https://bugs.webkit.org/show_bug.cgi?id=178106
2379
2380         Reviewed by Keith Miller.
2381
2382         * ucd/CaseFolding.txt:
2383
2384 2017-10-11  Caio Lima  <ticaiolima@gmail.com>
2385
2386         Object properties are undefined in super.call() but not in this.call()
2387         https://bugs.webkit.org/show_bug.cgi?id=177230
2388
2389         Reviewed by Saam Barati.
2390
2391         Bytecode generation for "super.call(...)" or "super.apply(...)"
2392         shouldn't be considered as CallFunctionCallDotNode or
2393         ApplyFunctionCallDotNode because they should be considered as common
2394         super property access as any other function. According to spec[1],
2395         "super" is not refering to parent constructor.
2396
2397         [1] - https://tc39.github.io/ecma262/#sec-super-keyword-runtime-semantics-evaluation
2398
2399         * parser/ASTBuilder.h:
2400         (JSC::ASTBuilder::makeFunctionCallNode):
2401         * parser/Parser.cpp:
2402         (JSC::Parser<LexerType>::parseMemberExpression):
2403         * parser/SyntaxChecker.h:
2404         (JSC::SyntaxChecker::makeFunctionCallNode):
2405
2406 2017-10-11  Yusuke Suzuki  <utatane.tea@gmail.com>
2407
2408         [JSC] Drop Instantiate hook in ES6 module loader
2409         https://bugs.webkit.org/show_bug.cgi?id=178162
2410
2411         Reviewed by Sam Weinig.
2412
2413         This patch is a part of patch series for module loader refactoring to adopt
2414         integrity="" parameters and introduce new whatwg module import mechanism.
2415
2416         In this patch, we drop instantiate hook in module loader. This hook is originally
2417         introduced because it is defined in whatwg/loader spec. But this hook is not
2418         used in our implementation, and this hook won't be used since (1) whatwg/loader
2419         spec is abandoned, and (2) this type of hooks should be done in Service Workers.
2420
2421         In addition, this patch applies some cleaning up of our module loader JS code
2422         to simplify things. This change paves the way to more efficient loader implementation
2423         with great flexibility to adopt integrity="" parameters.
2424
2425         * builtins/ModuleLoaderPrototype.js:
2426         (requestInstantiate):
2427         (provideFetch):
2428         provide is changed to provideFetch since we only used this function with Fetch stage parameter.
2429
2430         (fulfillInstantiate): Deleted.
2431         (commitInstantiated): Deleted.
2432         (instantiation): Deleted.
2433         They are merged into requestInstantiate code. This is simpler.
2434
2435         (provide): Deleted.
2436         * jsc.cpp:
2437         * runtime/Completion.cpp:
2438         (JSC::loadAndEvaluateModule):
2439         (JSC::loadModule):
2440         * runtime/JSGlobalObject.cpp:
2441         * runtime/JSGlobalObject.h:
2442         * runtime/JSModuleLoader.cpp:
2443         (JSC::JSModuleLoader::provideFetch):
2444         (JSC::JSModuleLoader::provide): Deleted.
2445         Changed to provideFetch.
2446
2447         (JSC::JSModuleLoader::instantiate): Deleted.
2448         Drop this hook.
2449
2450         * runtime/JSModuleLoader.h:
2451         * runtime/ModuleLoaderPrototype.cpp:
2452         (JSC::moduleLoaderPrototypeInstantiate): Deleted.
2453         Drop this hook.
2454
2455 2017-10-10  Saam Barati  <sbarati@apple.com>
2456
2457         Prototype structure transition should be a deferred transition
2458         https://bugs.webkit.org/show_bug.cgi?id=177734
2459
2460         Reviewed by Keith Miller.
2461
2462         Absence ObjectPropertyConditions work by verifying both that the Structure
2463         does not have a particular property and that its prototype has
2464         remained constant. However, the prototype transition was firing
2465         the transition watchpoint before setting the object's structure.
2466         This meant that isValid for Absence would never return false because
2467         the prototype changed. Clearly this is wrong. The reason this didn't
2468         break OPCs in general is that we'd also check if we could still watch
2469         the OPC. In this case, we can't still watch it because we're inspecting
2470         a structure with an invalidated transition watchpoint. To fix
2471         this weird quirk of the code, I'm making it so that doing a prototype
2472         transition uses the DeferredStructureTransitionWatchpointFire machinery.
2473
2474         This patch also fixes some dead code that I left in regarding
2475         poly proto in OPC.
2476
2477         * bytecode/PropertyCondition.cpp:
2478         (JSC::PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint const):
2479         * runtime/JSObject.cpp:
2480         (JSC::JSObject::setPrototypeDirect):
2481         * runtime/Structure.cpp:
2482         (JSC::Structure::changePrototypeTransition):
2483         * runtime/Structure.h:
2484
2485 2017-10-10  Robin Morisset  <rmorisset@apple.com>
2486
2487         Avoid allocating useless landingBlocks in DFGByteCodeParser::handleInlining()
2488         https://bugs.webkit.org/show_bug.cgi?id=177926
2489
2490         Reviewed by Saam Barati.
2491
2492         When doing polyvariant inlining, there used to be a landing block for each callee, each of which was then linked to a continuation block.
2493         With this change, we allocate the continuation block first, and pass it to the inlining routine so that op_ret in the callee link directly to it.
2494         The only subtlety is that when inlining an intrinsic we must do the jump by hand, and also remember to call processSetLocalQueue with nextOffset before it.
2495
2496         * dfg/DFGByteCodeParser.cpp:
2497         (JSC::DFG::ByteCodeParser::inlineCall):
2498         (JSC::DFG::ByteCodeParser::attemptToInlineCall):
2499         (JSC::DFG::ByteCodeParser::handleInlining):
2500         (JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
2501         (JSC::DFG::ByteCodeParser::parse):
2502
2503 2017-10-10  Guillaume Emont  <guijemont@igalia.com>
2504
2505         Fix compilation when MASM_PROBE (and therefore DFG) are disabled
2506         https://bugs.webkit.org/show_bug.cgi?id=178134
2507
2508         Reviewed by Saam Barati.
2509
2510         * bytecode/CodeBlock.cpp:
2511         * bytecode/CodeBlock.h:
2512         Disable some code when building without DFG_JIT.
2513
2514 2017-10-10  Sam Weinig  <sam@webkit.org>
2515
2516         Replace copyKeysToVector/copyValuesToVector with copyToVector(map.keys())/copyToVector(map.values())
2517         https://bugs.webkit.org/show_bug.cgi?id=178102
2518
2519         Reviewed by Tim Horton.
2520
2521         * inspector/agents/InspectorDebuggerAgent.cpp:
2522         (Inspector::InspectorDebuggerAgent::clearInspectorBreakpointState):
2523
2524 2017-10-10  Michael Saboff  <msaboff@apple.com>
2525
2526         Unreviewed build fix.
2527
2528         Removed unused lambda capture.
2529
2530         * yarr/YarrPattern.cpp:
2531         (JSC::Yarr::CharacterClassConstructor::appendInverted):
2532
2533 2017-10-10  Saam Barati  <sbarati@apple.com>
2534
2535         The prototype cache should be aware of the Executable it generates a Structure for
2536         https://bugs.webkit.org/show_bug.cgi?id=177907
2537
2538         Reviewed by Filip Pizlo.
2539
2540         This patch renames PrototypeMap to StructureCache because
2541         it is no longer a map of the prototypes in the VM. It's
2542         only used to cache Structures during object construction.
2543
2544         The main change of this patch is to guarantee that Structures generated
2545         by the create_this originating from different two different Executables'
2546         bytecode won't hash-cons to the same thing. Previously, we could hash-cons
2547         them depending on the JSObject* prototype pointer. This would cause the last
2548         thing that hash-consed to overwrite the Structure's poly proto watchpoint. This
2549         happened because when we initialize a JSFunction's ObjectAllocationProfile,
2550         we set the resulting Structure's poly proto watchpoint. This could cause a Structure
2551         generating from some Executable e1 to end up with the poly proto watchpoint
2552         for another Executable e2 simply because JSFunctions backed by e1 and e2
2553         shared the same prototype. Then, based on profiling information, we may fire the
2554         wrong Executable's poly proto watchpoint. This patch fixes this bug by
2555         guaranteeing that Structures generating from create_this for different
2556         Executables are unique even if they share the same prototype by adding
2557         the FunctionExecutable* as another field in PrototypeKey.
2558
2559         * JavaScriptCore.xcodeproj/project.pbxproj:
2560         * Sources.txt:
2561         * bytecode/InternalFunctionAllocationProfile.h:
2562         (JSC::InternalFunctionAllocationProfile::createAllocationStructureFromBase):
2563         * bytecode/ObjectAllocationProfile.cpp:
2564         (JSC::ObjectAllocationProfile::initializeProfile):
2565         * dfg/DFGOperations.cpp:
2566         * runtime/CommonSlowPaths.cpp:
2567         (JSC::SLOW_PATH_DECL):
2568         * runtime/InternalFunction.cpp:
2569         (JSC::InternalFunction::createSubclassStructureSlow):
2570         * runtime/IteratorOperations.cpp:
2571         (JSC::createIteratorResultObjectStructure):
2572         * runtime/JSBoundFunction.cpp:
2573         (JSC::getBoundFunctionStructure):
2574         * runtime/JSGlobalObject.cpp:
2575         (JSC::JSGlobalObject::init):
2576         * runtime/ObjectConstructor.h:
2577         (JSC::constructEmptyObject):
2578         * runtime/PrototypeKey.h:
2579         (JSC::PrototypeKey::PrototypeKey):
2580         (JSC::PrototypeKey::executable const):
2581         (JSC::PrototypeKey::operator== const):
2582         (JSC::PrototypeKey::hash const):
2583         * runtime/PrototypeMap.cpp: Removed.
2584         * runtime/PrototypeMap.h: Removed.
2585         * runtime/StructureCache.cpp: Copied from Source/JavaScriptCore/runtime/PrototypeMap.cpp.
2586         (JSC::StructureCache::createEmptyStructure):
2587         (JSC::StructureCache::emptyStructureForPrototypeFromBaseStructure):
2588         (JSC::StructureCache::emptyObjectStructureForPrototype):
2589         (JSC::PrototypeMap::createEmptyStructure): Deleted.
2590         (JSC::PrototypeMap::emptyStructureForPrototypeFromBaseStructure): Deleted.
2591         (JSC::PrototypeMap::emptyObjectStructureForPrototype): Deleted.
2592         * runtime/StructureCache.h: Copied from Source/JavaScriptCore/runtime/PrototypeMap.h.
2593         (JSC::StructureCache::StructureCache):
2594         (JSC::PrototypeMap::PrototypeMap): Deleted.
2595         * runtime/VM.cpp:
2596         (JSC::VM::VM):
2597         * runtime/VM.h:
2598
2599 2017-10-09  Yusuke Suzuki  <utatane.tea@gmail.com>
2600
2601         `async` should be able to be used as an imported binding name
2602         https://bugs.webkit.org/show_bug.cgi?id=176573
2603
2604         Reviewed by Saam Barati.
2605
2606         Previously, we have ASYNC keyword in the parser. This is introduced only for performance,
2607         and ECMA262 spec does not categorize "async" to keyword. This makes parser code complicated,
2608         since ASYNC should be handled as IDENT. If we missed this ASYNC keyword, we cause a bug.
2609         For example, import declaration failed to bind imported binding to the name "async" because
2610         the parser considered ASYNC as keyword.
2611
2612         This patch removes ASYNC keyword from the parser. By carefully handling ASYNC, we can keep
2613         the current performance without using this ASYNC keyword.
2614
2615         We also add `escaped` field to token data since contextual keyword is valid only if it does
2616         not contain any escape sequences. We fix bunch of contextual keyword use with this fix too
2617         e.g. `of in for-of`. This improves test262 score.
2618
2619         * parser/Keywords.table:
2620         * parser/Lexer.cpp:
2621         (JSC::Lexer<LChar>::parseIdentifier):
2622         (JSC::Lexer<UChar>::parseIdentifier):
2623         (JSC::Lexer<CharacterType>::parseIdentifierSlowCase):
2624         * parser/Parser.cpp:
2625         (JSC::Parser<LexerType>::parseStatementListItem):
2626         (JSC::Parser<LexerType>::parseForStatement):
2627         (JSC::Parser<LexerType>::parseStatement):
2628         (JSC::Parser<LexerType>::maybeParseAsyncFunctionDeclarationStatement):
2629         (JSC::Parser<LexerType>::parseClass):
2630         (JSC::Parser<LexerType>::parseExportDeclaration):
2631         (JSC::Parser<LexerType>::parseAssignmentExpression):
2632         (JSC::Parser<LexerType>::parseProperty):
2633         (JSC::Parser<LexerType>::parsePrimaryExpression):
2634         (JSC::Parser<LexerType>::parseMemberExpression):
2635         (JSC::Parser<LexerType>::printUnexpectedTokenText):
2636         * parser/Parser.h:
2637         (JSC::Parser::matchContextualKeyword):
2638         * parser/ParserTokens.h:
2639         * runtime/CommonIdentifiers.h:
2640
2641 2017-10-09  Saam Barati  <sbarati@apple.com>
2642
2643         We don't need to clearEmptyObjectStructureForPrototype because JSGlobalObject* is part of the cache's key
2644         https://bugs.webkit.org/show_bug.cgi?id=177987
2645
2646         Reviewed by Filip Pizlo.
2647
2648         * runtime/JSProxy.cpp:
2649         (JSC::JSProxy::setTarget):
2650         * runtime/PrototypeMap.cpp:
2651         (JSC::PrototypeMap::clearEmptyObjectStructureForPrototype): Deleted.
2652         * runtime/PrototypeMap.h:
2653
2654 2017-10-09  Filip Pizlo  <fpizlo@apple.com>
2655
2656         JSCell::didBecomePrototype is racy
2657         https://bugs.webkit.org/show_bug.cgi?id=178110
2658
2659         Reviewed by Saam Barati.
2660
2661         The indexing type can be modified by any thread using CAS. So, we need to use atomics when
2662         modifying it. We don't need to use atomics when reading it though (since it's just one field).
2663
2664         * runtime/JSCellInlines.h:
2665         (JSC::JSCell::didBecomePrototype):
2666
2667 2017-09-29  Filip Pizlo  <fpizlo@apple.com>
2668
2669         Enable gigacage on iOS
2670         https://bugs.webkit.org/show_bug.cgi?id=177586
2671
2672         Reviewed by JF Bastien.
2673
2674         The hardest part of enabling Gigacage on iOS is that it requires loading global variables while
2675         executing JS, so the LLInt needs to know how to load from global variables on all platforms that
2676         have Gigacage. So, this teaches ARM64 how to load from global variables.
2677
2678         Also, this makes the code handle disabling the gigacage a bit better.
2679
2680         * ftl/FTLLowerDFGToB3.cpp:
2681         (JSC::FTL::DFG::LowerDFGToB3::caged):
2682         * jit/AssemblyHelpers.h:
2683         (JSC::AssemblyHelpers::cage):
2684         (JSC::AssemblyHelpers::cageConditionally):
2685         * offlineasm/arm64.rb:
2686         * offlineasm/asm.rb:
2687         * offlineasm/instructions.rb:
2688
2689 2017-10-09  Robin Morisset  <rmorisset@apple.com>
2690
2691         Evaluate the benefit of skipping dead code in the DFGByteCodeParser when a function returns in its first block
2692         https://bugs.webkit.org/show_bug.cgi?id=177925
2693
2694         Reviewed by Saam Barati.
2695
2696         We used to do a rather weird "optimisation" in the bytecode parser: when a function would return in its first block,
2697         the rest of the function was skipped. Since it has no actual impact on any benchmarks from what I could see, I removed
2698         that code. It allows some changes to parseBlock(), since it now returns void and no-longer bool (it was returning a boolean that said whether that case happened or not).
2699
2700         * dfg/DFGByteCodeParser.cpp:
2701         (JSC::DFG::ByteCodeParser::parseBlock):
2702         (JSC::DFG::ByteCodeParser::parseCodeBlock):
2703
2704 2017-10-09  Robin Morisset  <rmorisset@apple.com>
2705
2706         Refactor the inliner to simplify block linking
2707         https://bugs.webkit.org/show_bug.cgi?id=177922
2708
2709         Reviewed by Saam Barati.
2710
2711         The biggest refactor changes the way blocks are linked. In DFGByteCodeParser, most terminals (such as Jump or Branch) jump to nullptr initially, and have
2712         some metadata indicating the bytecode index corresponding to their targets. They are later linked to the right basic block using two fields of InlineStackEntry:
2713         - m_unlinkedBlocks is just a worklist of blocks with a terminal that needs to be linked
2714         - m_linkingTargets is a dictionary from bytecode indices to BasicBlock*
2715         Before refactoring, every block was automatically added to both of these fields, for the InlineStackEntry of whatever function allocated it.
2716         This created a significant number of corner cases, such as blocks allocated in a caller, with a terminal written by an inlined callee and pointing to a block in the callee,
2717         or blocks allocated in an inline callee, with a terminal written by the caller after it returns and pointing to a block in the caller, or blocks with a manually linked
2718         terminal that needs to be taken off m_unlinkedBlocks.
2719         I changed things so that blocks are only added to m_unlinkedBlocks when their terminal gets written (see the LAST_OPCODE macro) making it a lot easier to be in the "right" InlineStackEntry,
2720         that is the one that holds their target in its m_linkingTargets field.
2721
2722         There are a few much smaller refactors in this patch:
2723         - parse() is now of type void insted of bool (it was always returning true)
2724         - The 7 and 8 arguments of handleCall were inlined in its 3 arguments version for readability
2725         - The 9 argument version was cleaned up and simplified
2726         - I made separate allocateBlock routines because the little dance with adoptRef(* new BasicBlock(...)) was being repeated in lots of places, and typos in that were a major source of bugs during other refactorings
2727         - Jumps are now created with explicit addJumpTo() functions, providing some sanity checking through asserts and didLink()
2728         - Blocks are only added to m_unlinkedBlocks if they end in a terminal that linkBlock works with (see LAST_OPCODE)
2729
2730         * dfg/DFGByteCodeParser.cpp:
2731         (JSC::DFG::ByteCodeParser::addToGraph):
2732         (JSC::DFG::ByteCodeParser::handleCall):
2733         (JSC::DFG::ByteCodeParser::refineStatically):
2734         (JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
2735         (JSC::DFG::ByteCodeParser::handleVarargsCall):
2736         (JSC::DFG::ByteCodeParser::inlineCall):
2737         (JSC::DFG::ByteCodeParser::attemptToInlineCall):
2738         (JSC::DFG::ByteCodeParser::handleInlining):
2739         (JSC::DFG::ByteCodeParser::handleIntrinsicCall):
2740         (JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
2741         (JSC::DFG::ByteCodeParser::parseBlock):
2742         (JSC::DFG::ByteCodeParser::parseCodeBlock):
2743         (JSC::DFG::ByteCodeParser::parse):
2744         (JSC::DFG::parse):
2745         (JSC::DFG::ByteCodeParser::cancelLinkingForBlock): Deleted.
2746         * dfg/DFGByteCodeParser.h:
2747         * dfg/DFGPlan.cpp:
2748         (JSC::DFG::Plan::compileInThreadImpl):
2749
2750 2017-10-09  Michael Saboff  <msaboff@apple.com>
2751
2752         Implement RegExp Unicode property escapes
2753         https://bugs.webkit.org/show_bug.cgi?id=172069
2754
2755         Reviewed by JF Bastien.
2756
2757         Added Unicode Properties by extending the existing CharacterClass processing.
2758
2759         Introduced a new Python script, generateYarrUnicodePropertyTables.py, that parses
2760         Unicode Database files to create character class data.  The result is a set of functions
2761         that return character classes, one for each of the required Unicode properties.
2762         There are many cases where many properties are handled by one function, primarily due to
2763         property aliases, but also due to Script_Extension properties that are the same as the
2764         Script property for the same script value.
2765
2766         Extended the BuiltInCharacterClassID enum so it can be used also for Unicode property
2767         character classes.  Unicode properties are the enum value BaseUnicodePropertyID plus a
2768         zero based value, that value being the index to the corrensponding character class
2769         function.  The generation script also creates static hashing tables similar to what we
2770         use for the generated .lut.h lookup table files.  These hashing tables map property
2771         names to the function index.  Using these hashing tables, we can lookup a property
2772         name and if present convert it to a function index.  We add that index to
2773         BaseUnicodePropertyID to create a BuiltInCharacterClassID.
2774
2775         When we do syntax parsing, we convert the property to its corresponding BuiltInCharacterClassID.
2776         When doing real parsing we takes the returned BuiltInCharacterClassID and use it to get
2777         the actual character class by calling the corresponding generated function.
2778
2779         Added a new CharacterClass constructor that can take literal arrays for ranges and matches
2780         to make the creation of large static character classes more efficent.
2781
2782         Since the Unicode character classes typically have more matches and ranges, the character
2783         class matching in the interpreter has been updated to use binary searching for matches and
2784         ranges with more than 6 entries.
2785
2786         * CMakeLists.txt:
2787         * DerivedSources.make:
2788         * JavaScriptCore.xcodeproj/project.pbxproj:
2789         * Scripts/generateYarrUnicodePropertyTables.py: Added.
2790         (openOrExit):
2791         (openUCDFileOrExit):
2792         (verifyUCDFilesExist):
2793         (ceilingToPowerOf2):
2794         (Aliases):
2795         (Aliases.__init__):
2796         (Aliases.parsePropertyAliasesFile):
2797         (Aliases.parsePropertyValueAliasesFile):
2798         (Aliases.globalAliasesFor):
2799         (Aliases.generalCategoryAliasesFor):
2800         (Aliases.generalCategoryForAlias):
2801         (Aliases.scriptAliasesFor):
2802         (Aliases.scriptNameForAlias):
2803         (PropertyData):
2804         (PropertyData.__init__):
2805         (PropertyData.setAliases):
2806         (PropertyData.makeCopy):
2807         (PropertyData.getIndex):
2808         (PropertyData.getCreateFuncName):
2809         (PropertyData.addMatch):
2810         (PropertyData.addRange):
2811         (PropertyData.addMatchUnorderedForMatchesAndRanges):
2812         (PropertyData.addRangeUnorderedForMatchesAndRanges):
2813         (PropertyData.addMatchUnordered):
2814         (PropertyData.addRangeUnordered):
2815         (PropertyData.removeMatchFromRanges):
2816         (PropertyData.removeMatch):
2817         (PropertyData.dumpMatchData):
2818         (PropertyData.dump):
2819         (PropertyData.dumpAll):
2820         (PropertyData.dumpAll.std):
2821         (PropertyData.createAndDumpHashTable):
2822         (Scripts):
2823         (Scripts.__init__):
2824         (Scripts.parseScriptsFile):
2825         (Scripts.parseScriptExtensionsFile):
2826         (Scripts.dump):
2827         (GeneralCategory):
2828         (GeneralCategory.__init__):
2829         (GeneralCategory.createSpecialPropertyData):
2830         (GeneralCategory.findPropertyGroupFor):
2831         (GeneralCategory.addNextCodePoints):
2832         (GeneralCategory.parse):
2833         (GeneralCategory.dump):
2834         (BinaryProperty):
2835         (BinaryProperty.__init__):
2836         (BinaryProperty.parsePropertyFile):
2837         (BinaryProperty.dump):
2838         * Scripts/hasher.py: Added.
2839         (stringHash):
2840         * Sources.txt:
2841         * ucd/DerivedBinaryProperties.txt: Added.
2842         * ucd/DerivedCoreProperties.txt: Added.
2843         * ucd/DerivedNormalizationProps.txt: Added.
2844         * ucd/PropList.txt: Added.
2845         * ucd/PropertyAliases.txt: Added.
2846         * ucd/PropertyValueAliases.txt: Added.
2847         * ucd/ScriptExtensions.txt: Added.
2848         * ucd/Scripts.txt: Added.
2849         * ucd/UnicodeData.txt: Added.
2850         * ucd/emoji-data.txt: Added.
2851         * yarr/Yarr.h:
2852         * yarr/YarrInterpreter.cpp:
2853         (JSC::Yarr::Interpreter::testCharacterClass):
2854         * yarr/YarrParser.h:
2855         (JSC::Yarr::Parser::parseEscape):
2856         (JSC::Yarr::Parser::parseTokens):
2857         (JSC::Yarr::Parser::isUnicodePropertyValueExpressionChar):
2858         (JSC::Yarr::Parser::tryConsumeUnicodePropertyExpression):
2859         * yarr/YarrPattern.cpp:
2860         (JSC::Yarr::CharacterClassConstructor::appendInverted):
2861         (JSC::Yarr::YarrPatternConstructor::atomBuiltInCharacterClass):
2862         (JSC::Yarr::YarrPatternConstructor::atomCharacterClassBuiltIn):
2863         (JSC::Yarr::YarrPattern::errorMessage):
2864         (JSC::Yarr::PatternTerm::dump):
2865         * yarr/YarrPattern.h:
2866         (JSC::Yarr::CharacterRange::CharacterRange):
2867         (JSC::Yarr::CharacterClass::CharacterClass):
2868         (JSC::Yarr::YarrPattern::reset):
2869         (JSC::Yarr::YarrPattern::unicodeCharacterClassFor):
2870         * yarr/YarrUnicodeProperties.cpp: Added.
2871         (JSC::Yarr::HashTable::entry const):
2872         (JSC::Yarr::unicodeMatchPropertyValue):
2873         (JSC::Yarr::unicodeMatchProperty):
2874         (JSC::Yarr::createUnicodeCharacterClassFor):
2875         * yarr/YarrUnicodeProperties.h: Added.
2876
2877 2017-10-09  Commit Queue  <commit-queue@webkit.org>
2878
2879         Unreviewed, rolling out r223015 and r223025.
2880         https://bugs.webkit.org/show_bug.cgi?id=178093
2881
2882         Regressed Kraken on iOS by 20% (Requested by keith_mi_ on
2883         #webkit).
2884
2885         Reverted changesets:
2886
2887         "Enable gigacage on iOS"
2888         https://bugs.webkit.org/show_bug.cgi?id=177586
2889         http://trac.webkit.org/changeset/223015
2890
2891         "Unreviewed, disable Gigacage on ARM64 Linux"
2892         https://bugs.webkit.org/show_bug.cgi?id=177586
2893         http://trac.webkit.org/changeset/223025
2894
2895 2017-10-09  Keith Miller  <keith_miller@apple.com>
2896
2897         Unreviewed, sort unified sources again now that they are numbered numerically rather than lexicographically.
2898
2899         * JavaScriptCore.xcodeproj/project.pbxproj:
2900
2901 2017-10-09  Ryan Haddad  <ryanhaddad@apple.com>
2902
2903         Unreviewed, rolling out r223022.
2904
2905         This change introduced 18 test262 failures.
2906
2907         Reverted changeset:
2908
2909         "`async` should be able to be used as an imported binding
2910         name"
2911         https://bugs.webkit.org/show_bug.cgi?id=176573
2912         http://trac.webkit.org/changeset/223022
2913
2914 2017-10-09  Robin Morisset  <rmorisset@apple.com>
2915
2916         Make the names of the options consistent
2917         https://bugs.webkit.org/show_bug.cgi?id=177933
2918
2919         Reviewed by Saam Barati.
2920
2921         I added an alias so the old spelling still works.
2922         I also fixed a bunch of typos in comments all around the codebase.
2923
2924         * b3/B3LowerToAir.cpp:
2925         * dfg/DFGByteCodeParser.cpp:
2926         (JSC::DFG::ByteCodeParser::parseBlock):
2927         * dfg/DFGIntegerRangeOptimizationPhase.cpp:
2928         * dfg/DFGOperations.h:
2929         * dfg/DFGSSAConversionPhase.h:
2930         * dfg/DFGSpeculativeJIT.h:
2931         * ftl/FTLLowerDFGToB3.cpp:
2932         (JSC::FTL::DFG::LowerDFGToB3::lower):
2933         * ftl/FTLOSREntry.cpp:
2934         (JSC::FTL::prepareOSREntry):
2935         * jit/CallFrameShuffler.cpp:
2936         (JSC::CallFrameShuffler::prepareForTailCall):
2937         * parser/Nodes.h:
2938         * parser/Parser.cpp:
2939         (JSC::Parser<LexerType>::parseExportDeclaration):
2940         * runtime/Options.h:
2941
2942 2017-10-09  Oleksandr Skachkov  <gskachkov@gmail.com>
2943
2944         Safari 10 /11 problem with if (!await get(something)).
2945         https://bugs.webkit.org/show_bug.cgi?id=176685
2946
2947         Reviewed by Saam Barati.
2948
2949         Using unary operator before `await` lead to count it as identifier.
2950         According to spec https://tc39.github.io/ecma262/#sec-async-function-definitions
2951         and Note 1 `await` is as AwaitExpression and it is allowed to use unary operator
2952
2953         * parser/Parser.cpp:
2954         (JSC::Parser<LexerType>::parsePrimaryExpression):
2955
2956 2017-10-07  Filip Pizlo  <fpizlo@apple.com>
2957
2958         direct-construct-arity-mismatch.js can have GCs that take ~70ms if you force poly proto and disable generational GC
2959         https://bugs.webkit.org/show_bug.cgi?id=178051
2960
2961         Reviewed by Saam Barati.
2962
2963         After I studied the profile of this test, I found two pathologies in our code relating to
2964         prototypes. I think that now that we support poly proto, it's more likely for these pathologies to
2965         happen. Also, the fact that we force poly proto in some tests, it's possible for one of our tests
2966         to trigger these pathologies.
2967
2968         - WeakGCMap::m_prototoypes is the set of all prototypes. That's super dangerous. This patch turns
2969           this into a bit in the JSCell header. It uses the last spare bit in indexingTypeAndMisc. Note
2970           that we still have 6 spare bits in cellState, but those are a bit more annoying to get at.
2971
2972         - WeakGCMap registers itself with GC using a std::function. That means allocating things in the
2973           malloc heap. This changes it to a virtual method on WeakGCMap. I don't know for sure that this is
2974           a problem area, but there are places where we could allocate a lot of WeakGCMaps, like if we have
2975           a lot of transition tables. It's good to reduce the amount of memory those require.
2976
2977         Also, I saw a FIXME about turning the std::tuple in PrototypeMap into a struct, so I did that while
2978         I was at it. I initially thought that this would have to be part of my solution, but it turned out
2979         not to be. I think it's worth landing anyway since it makes the code a lot more clear.
2980
2981         This fixes the timeout in that test and probably reduces memory consumption.
2982
2983         * JavaScriptCore.xcodeproj/project.pbxproj:
2984         * dfg/DFGOperations.cpp:
2985         * heap/Heap.cpp:
2986         (JSC::Heap::pruneStaleEntriesFromWeakGCMaps):
2987         (JSC::Heap::registerWeakGCMap):
2988         (JSC::Heap::unregisterWeakGCMap):
2989         * heap/Heap.h:
2990         * inspector/JSInjectedScriptHostPrototype.cpp:
2991         (Inspector::JSInjectedScriptHostPrototype::finishCreation):
2992         * inspector/JSJavaScriptCallFramePrototype.cpp:
2993         (Inspector::JSJavaScriptCallFramePrototype::finishCreation):
2994         * runtime/ArrayIteratorPrototype.cpp:
2995         (JSC::ArrayIteratorPrototype::finishCreation):
2996         * runtime/ArrayPrototype.cpp:
2997         (JSC::ArrayPrototype::finishCreation):
2998         * runtime/AsyncFromSyncIteratorPrototype.cpp:
2999         (JSC::AsyncFromSyncIteratorPrototype::finishCreation):
3000         * runtime/AsyncFunctionPrototype.cpp:
3001         (JSC::AsyncFunctionPrototype::finishCreation):
3002         * runtime/AsyncGeneratorFunctionPrototype.cpp:
3003         (JSC::AsyncGeneratorFunctionPrototype::finishCreation):
3004         * runtime/AsyncGeneratorPrototype.cpp:
3005         (JSC::AsyncGeneratorPrototype::finishCreation):
3006         * runtime/AsyncIteratorPrototype.cpp:
3007         (JSC::AsyncIteratorPrototype::finishCreation):
3008         * runtime/CommonSlowPaths.cpp:
3009         (JSC::SLOW_PATH_DECL):
3010         * runtime/GeneratorFunctionPrototype.cpp:
3011         (JSC::GeneratorFunctionPrototype::finishCreation):
3012         * runtime/GeneratorPrototype.cpp:
3013         (JSC::GeneratorPrototype::finishCreation):
3014         * runtime/IndexingType.h:
3015         * runtime/IteratorPrototype.cpp:
3016         (JSC::IteratorPrototype::finishCreation):
3017         * runtime/JSCInlines.h:
3018         * runtime/JSCell.h:
3019         * runtime/JSCellInlines.h:
3020         (JSC::JSCell::mayBePrototype const):
3021         (JSC::JSCell::didBecomePrototype):
3022         * runtime/JSObject.cpp:
3023         (JSC::JSObject::notifyPresenceOfIndexedAccessors):
3024         (JSC::JSObject::setPrototypeDirect):
3025         * runtime/JSProxy.cpp:
3026         (JSC::JSProxy::setTarget):
3027         * runtime/MapIteratorPrototype.cpp:
3028         (JSC::MapIteratorPrototype::finishCreation):
3029         * runtime/MapPrototype.cpp:
3030         (JSC::MapPrototype::finishCreation):
3031         * runtime/ObjectPrototype.cpp:
3032         (JSC::ObjectPrototype::finishCreation):
3033         * runtime/PrototypeKey.h: Added.
3034         (JSC::PrototypeKey::PrototypeKey):
3035         (JSC::PrototypeKey::prototype const):
3036         (JSC::PrototypeKey::inlineCapacity const):
3037         (JSC::PrototypeKey::classInfo const):
3038         (JSC::PrototypeKey::globalObject const):
3039         (JSC::PrototypeKey::operator== const):
3040         (JSC::PrototypeKey::operator!= const):
3041         (JSC::PrototypeKey::operator bool const):
3042         (JSC::PrototypeKey::isHashTableDeletedValue const):
3043         (JSC::PrototypeKey::hash const):
3044         (JSC::PrototypeKeyHash::hash):
3045         (JSC::PrototypeKeyHash::equal):
3046         * runtime/PrototypeMap.cpp:
3047         (JSC::PrototypeMap::createEmptyStructure):
3048         (JSC::PrototypeMap::clearEmptyObjectStructureForPrototype):
3049         * runtime/PrototypeMap.h:
3050         (JSC::PrototypeMap::PrototypeMap):
3051         * runtime/PrototypeMapInlines.h: Removed.
3052         * runtime/SetIteratorPrototype.cpp:
3053         (JSC::SetIteratorPrototype::finishCreation):
3054         * runtime/SetPrototype.cpp:
3055         (JSC::SetPrototype::finishCreation):
3056         * runtime/StringIteratorPrototype.cpp:
3057         (JSC::StringIteratorPrototype::finishCreation):
3058         * runtime/WeakGCMap.h:
3059         (JSC::WeakGCMapBase::~WeakGCMapBase):
3060         * runtime/WeakGCMapInlines.h:
3061         (JSC::KeyTraitsArg>::WeakGCMap):
3062         * runtime/WeakMapPrototype.cpp:
3063         (JSC::WeakMapPrototype::finishCreation):
3064         * runtime/WeakSetPrototype.cpp:
3065         (JSC::WeakSetPrototype::finishCreation):
3066
3067 2017-10-07  Filip Pizlo  <fpizlo@apple.com>
3068
3069         Octane/splay can leak memory due to stray pointers on the stack when run from the command line
3070         https://bugs.webkit.org/show_bug.cgi?id=178054
3071
3072         Reviewed by Saam Barati.
3073
3074         This throws in a bunch of sanitize calls. It fixes the problem. It's also performance-neutral. In
3075         most cases, calling the sanitize function is O(1), because it doesn't have anything to do if the stack
3076         height stays relatively constant.
3077
3078         * dfg/DFGOperations.cpp:
3079         * dfg/DFGTierUpCheckInjectionPhase.cpp:
3080         (JSC::DFG::TierUpCheckInjectionPhase::run):
3081         * ftl/FTLOSREntry.cpp:
3082         * heap/Heap.cpp:
3083         (JSC::Heap::runCurrentPhase):
3084         * heap/MarkedAllocatorInlines.h:
3085         (JSC::MarkedAllocator::tryAllocate):
3086         (JSC::MarkedAllocator::allocate):
3087         * heap/Subspace.cpp:
3088         (JSC::Subspace::tryAllocateSlow):
3089         * jit/AssemblyHelpers.h:
3090         (JSC::AssemblyHelpers::sanitizeStackInline):
3091         * jit/ThunkGenerators.cpp:
3092         (JSC::slowPathFor):
3093         * runtime/VM.h:
3094         (JSC::VM::addressOfLastStackTop):
3095
3096 2017-10-07  Yusuke Suzuki  <utatane.tea@gmail.com>
3097
3098         `async` should be able to be used as an imported binding name
3099         https://bugs.webkit.org/show_bug.cgi?id=176573
3100
3101         Reviewed by Darin Adler.
3102
3103         Previously, we have ASYNC keyword in the parser. This is introduced only for performance,
3104         and ECMA262 spec does not categorize "async" to keyword. This makes parser code complicated,
3105         since ASYNC should be handled as IDENT. If we missed this ASYNC keyword, we cause a bug.
3106         For example, import declaration failed to bind imported binding to the name "async" because
3107         the parser considered ASYNC as keyword.
3108
3109         This patch removes ASYNC keyword from the parser. By carefully handling ASYNC, we can keep
3110         the current performance without using this ASYNC keyword.
3111
3112         * parser/Keywords.table:
3113         * parser/Parser.cpp:
3114         (JSC::Parser<LexerType>::parseStatementListItem):
3115         (JSC::Parser<LexerType>::parseStatement):
3116         (JSC::Parser<LexerType>::maybeParseAsyncFunctionDeclarationStatement):
3117         (JSC::Parser<LexerType>::parseClass):
3118         (JSC::Parser<LexerType>::parseExportDeclaration):
3119         (JSC::Parser<LexerType>::parseAssignmentExpression):
3120         (JSC::Parser<LexerType>::parseProperty):
3121         (JSC::Parser<LexerType>::parsePrimaryExpression):
3122         (JSC::Parser<LexerType>::parseMemberExpression):
3123         (JSC::Parser<LexerType>::printUnexpectedTokenText):
3124         * parser/ParserTokens.h:
3125         * runtime/CommonIdentifiers.h:
3126
3127 2017-09-29  Filip Pizlo  <fpizlo@apple.com>
3128
3129         Enable gigacage on iOS
3130         https://bugs.webkit.org/show_bug.cgi?id=177586
3131
3132         Reviewed by JF Bastien.
3133
3134         The hardest part of enabling Gigacage on iOS is that it requires loading global variables while
3135         executing JS, so the LLInt needs to know how to load from global variables on all platforms that
3136         have Gigacage. So, this teaches ARM64 how to load from global variables.
3137
3138         Also, this makes the code handle disabling the gigacage a bit better.
3139
3140         * ftl/FTLLowerDFGToB3.cpp:
3141         (JSC::FTL::DFG::LowerDFGToB3::caged):
3142         * jit/AssemblyHelpers.h:
3143         (JSC::AssemblyHelpers::cage):
3144         (JSC::AssemblyHelpers::cageConditionally):
3145         * offlineasm/arm64.rb:
3146         * offlineasm/asm.rb:
3147         * offlineasm/instructions.rb:
3148
3149 2017-10-06  Michael Saboff  <msaboff@apple.com>
3150
3151         Enable RegExp JIT for match only Unicode RegExp's
3152         https://bugs.webkit.org/show_bug.cgi?id=178033
3153
3154         Reviewed by JF Bastien.
3155
3156         I forgot to turn on JIT'ing for match-only Unicode RegExp's in r221052.  Do it now.
3157
3158         * runtime/RegExp.cpp:
3159         (JSC::RegExp::compileMatchOnly):
3160
3161 2017-10-06  Alex Christensen  <achristensen@webkit.org>
3162
3163         Build fix after r223002.
3164
3165         * dfg/DFGOSRExit.cpp:
3166         (JSC::DFG::restoreCalleeSavesFromVMEntryFrameCalleeSavesBuffer):
3167         (JSC::DFG::copyCalleeSavesToVMEntryFrameCalleeSavesBuffer):
3168
3169 2017-10-06  Commit Queue  <commit-queue@webkit.org>
3170
3171         Unreviewed, rolling out r222791 and r222873.
3172         https://bugs.webkit.org/show_bug.cgi?id=178031
3173
3174         Caused crashes with workers/wasm LayoutTests (Requested by
3175         ryanhaddad on #webkit).
3176
3177         Reverted changesets:
3178
3179         "WebAssembly: no VM / JS version of everything but Instance"
3180         https://bugs.webkit.org/show_bug.cgi?id=177473
3181         http://trac.webkit.org/changeset/222791
3182
3183         "WebAssembly: address no VM / JS follow-ups"
3184         https://bugs.webkit.org/show_bug.cgi?id=177887
3185         http://trac.webkit.org/changeset/222873
3186
3187 2017-10-06  Robin Morisset  <rmorisset@apple.com>
3188
3189         Avoid integer overflow in DFGStrengthReduction.cpp
3190         https://bugs.webkit.org/show_bug.cgi?id=177944
3191
3192         Reviewed by Saam Barati.
3193
3194         The check that we won't do integer overflow by negating INT32_MIN was itself an integer overflow.
3195         I think that signed integer overflow is undefined behaviour in C, so I replace it by an explicit check that value != INT32_MIN instead.
3196
3197         * dfg/DFGStrengthReductionPhase.cpp:
3198         (JSC::DFG::StrengthReductionPhase::handleNode):
3199
3200 2017-10-05  Keith Miller  <keith_miller@apple.com>
3201
3202         JSC generate unified sources doesn't need to run during installhdrs.
3203         https://bugs.webkit.org/show_bug.cgi?id=177640
3204
3205         Reviewed by Dan Bernstein.
3206
3207         generate unified sources doesn't need to have a xcconfig file
3208         since we don't have any feature defines. Also, remove the plist
3209         because there's no plist for this...
3210
3211         * JavaScriptCore.xcodeproj/project.pbxproj:
3212
3213 2017-10-05  Jer Noble  <jer.noble@apple.com>
3214
3215         [Cocoa] Enable ENABLE_ENCRYPTED_MEDIA build-time setting
3216         https://bugs.webkit.org/show_bug.cgi?id=177261
3217
3218         Reviewed by Eric Carlson.
3219
3220         * Configurations/FeatureDefines.xcconfig:
3221
3222 2017-10-05  Ryan Haddad  <ryanhaddad@apple.com>
3223
3224         Unreviewed, rolling out r222929.
3225
3226         Caused assertion failures during LayoutTests.
3227
3228         Reverted changeset:
3229
3230         "Only add prototypes to the PrototypeMap if they're not
3231         already present"
3232         https://bugs.webkit.org/show_bug.cgi?id=177952
3233         http://trac.webkit.org/changeset/222929
3234
3235 2017-10-05  Carlos Alberto Lopez Perez  <clopez@igalia.com>
3236
3237         Generate a compile error if release is built without compiler optimizations
3238         https://bugs.webkit.org/show_bug.cgi?id=177665
3239
3240         Reviewed by Brian Burg.
3241
3242         Pass -DRELEASE_WITHOUT_OPTIMIZATIONS to testair.cpp and testb3.cpp because
3243         this files are compiled with -O0 for build speed reasons after r195639.
3244
3245         * JavaScriptCore.xcodeproj/project.pbxproj:
3246
3247 2017-10-05  Saam Barati  <sbarati@apple.com>
3248
3249         Only add prototypes to the PrototypeMap if they're not already present
3250         https://bugs.webkit.org/show_bug.cgi?id=177952
3251
3252         Reviewed by Michael Saboff and JF Bastien.
3253
3254         With poly proto, we need to call PrototypeMap::add more frequently since we don't
3255         know if the prototype is already in the map or not based solely on Structure.
3256         PrototypeMap::add was calling WeakMap::set unconditionally, which would unconditionally
3257         allocate a Weak handle. Allocating a Weak handle is expensive. It's at least 8x more
3258         expensive than just checking if the prototype is in the map prior to adding it. This
3259         patch makes the change to only add the prototype if it's not already in the map. To
3260         do this, I've added a WeakMap::add API that just forwards into HashMap's add API.
3261         This allows us to both only do a single hash table lookup and also to allocate only
3262         a single Weak handle when necessary.
3263
3264         * runtime/PrototypeMapInlines.h:
3265         (JSC::PrototypeMap::addPrototype):
3266         * runtime/WeakGCMap.h:
3267         (JSC::WeakGCMap::add):
3268
3269 2017-10-05  Saam Barati  <sbarati@apple.com>
3270
3271         Unreviewed. Disable probe OSR exit on 32-bit until it's fixed.
3272
3273         * runtime/Options.cpp:
3274         (JSC::recomputeDependentOptions):
3275
3276 2017-10-05  Saam Barati  <sbarati@apple.com>
3277
3278         Make sure all prototypes under poly proto get added into the VM's prototype map
3279         https://bugs.webkit.org/show_bug.cgi?id=177909
3280
3281         Reviewed by Keith Miller.
3282
3283         This is an invariant of prototypes that I broke when doing poly proto. This patch fixes it.
3284
3285         * JavaScriptCore.xcodeproj/project.pbxproj:
3286         * bytecode/BytecodeList.json:
3287         * dfg/DFGByteCodeParser.cpp:
3288         (JSC::DFG::ByteCodeParser::parseBlock):
3289         * dfg/DFGOperations.cpp:
3290         * runtime/CommonSlowPaths.cpp:
3291         (JSC::SLOW_PATH_DECL):
3292         * runtime/JSCInlines.h:
3293         * runtime/PrototypeMap.cpp:
3294         (JSC::PrototypeMap::addPrototype): Deleted.
3295         * runtime/PrototypeMap.h:
3296         * runtime/PrototypeMapInlines.h:
3297         (JSC::PrototypeMap::isPrototype const):
3298         (JSC::PrototypeMap::addPrototype):
3299
3300 2017-09-30  Yusuke Suzuki  <utatane.tea@gmail.com>
3301
3302         [JSC] Introduce import.meta
3303         https://bugs.webkit.org/show_bug.cgi?id=177703
3304
3305         Reviewed by Filip Pizlo.
3306
3307         This patch adds stage 3 `import.meta`[1].
3308         We add a new hook function moduleLoaderCreateImportMetaProperties, which creates
3309         import meta properties object to this module. And we set this object as @meta
3310         private variable in module environments. So module code can access this by accessing
3311         @meta private variable.
3312
3313         [1]: https://github.com/tc39/proposal-import-meta
3314
3315         * builtins/BuiltinNames.h:
3316         * builtins/ModuleLoaderPrototype.js:
3317         * bytecompiler/BytecodeGenerator.cpp:
3318         (JSC::BytecodeGenerator::BytecodeGenerator):
3319         * jsc.cpp:
3320         (GlobalObject::moduleLoaderCreateImportMetaProperties):
3321         * parser/Parser.cpp:
3322         (JSC::Parser<LexerType>::parseModuleSourceElements):
3323         (JSC::Parser<LexerType>::parseMemberExp