Source/JavaScriptCore/ChangeLog

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