Source/JavaScriptCore/ChangeLog

   1 2019-06-04  Tadeu Zagallo  <tzagallo@apple.com>
   2
   3         Argument elimination should check transitive dependents for interference
   4         https://bugs.webkit.org/show_bug.cgi?id=198520
   5         <rdar://problem/50863343>
   6
   7         Reviewed by Filip Pizlo.
   8
   9         Consider the following program:
  10
  11             a: CreateRest
  12             -->
  13                 b: CreateRest
  14             <--
  15             c: Spread(@a)
  16             d: Spread(@b)
  17             e: NewArrayWithSpread(@a, @b)
  18             f: KillStack(locX)
  19             g: LoadVarargs(@e)
  20
  21         Suppose @b reads locX, then we cannot transform @e to PhantomNewArraySpread, since that would
  22         move the stack access from @b into @g, and that stack location is no longer valid at that point.
  23
  24         We fix that by computing a set of all inline call frames that any argument elimination candidate
  25         depends on and checking each of them for interference in `eliminateCandidatesThatInterfere`.
  26
  27         * dfg/DFGArgumentsEliminationPhase.cpp:
  28
  29 2019-06-04  Yusuke Suzuki  <ysuzuki@apple.com>
  30
  31         [JSC] InferredValue should not be a JSCell
  32         https://bugs.webkit.org/show_bug.cgi?id=198407
  33
  34         Reviewed by Filip Pizlo.
  35
  36         Allocating InferredValue as a JSCell is too costly in terms of memory. Gmail has 90000 FunctionExecutables. And each gets
  37         InferredValue, which takes 32 bytes. So it takes 2.7 MB memory footprint.
  38
  39         In this patch, we introduce a new container InferredValue<>. Which is similar to WriteBarrier<> container, but it replaces
  40         the existing InferredValue cells with one pointer size field. The implementation of InferredValue<> is similar to
  41         InlineWatchpointSet. But we encode JSCell* too to the pointer data of InlineWatchpointSet. So sizeof(InferredValue<>) is one
  42         pointer size while it keeps Watchpoint feature and JSCell holder feature.
  43
  44         InferredValue<> needs validation in GC finalize phase. So this patch also makes SymbolTable Iso-allocated.
  45
  46         * JavaScriptCore.xcodeproj/project.pbxproj:
  47         * Sources.txt:
  48         * bytecode/ObjectAllocationProfileInlines.h:
  49         (JSC::ObjectAllocationProfileBase<Derived>::initializeProfile):
  50         * bytecode/Watchpoint.h:
  51         * dfg/DFGAbstractInterpreterInlines.h:
  52         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
  53         * dfg/DFGByteCodeParser.cpp:
  54         (JSC::DFG::ByteCodeParser::get):
  55         (JSC::DFG::ByteCodeParser::parseBlock):
  56         * dfg/DFGClobberize.h:
  57         (JSC::DFG::clobberize):
  58         * dfg/DFGClobbersExitState.cpp:
  59         (JSC::DFG::clobbersExitState):
  60         * dfg/DFGDesiredWatchpoints.cpp:
  61         (JSC::DFG::SymbolTableAdaptor::add):
  62         (JSC::DFG::FunctionExecutableAdaptor::add):
  63         (JSC::DFG::DesiredWatchpoints::addLazily):
  64         (JSC::DFG::DesiredWatchpoints::reallyAdd):
  65         (JSC::DFG::DesiredWatchpoints::areStillValid const):
  66         (JSC::DFG::DesiredWatchpoints::dumpInContext const):
  67         (JSC::DFG::InferredValueAdaptor::add): Deleted.
  68         * dfg/DFGDesiredWatchpoints.h:
  69         (JSC::DFG::SymbolTableAdaptor::hasBeenInvalidated):
  70         (JSC::DFG::SymbolTableAdaptor::dumpInContext):
  71         (JSC::DFG::FunctionExecutableAdaptor::hasBeenInvalidated):
  72         (JSC::DFG::FunctionExecutableAdaptor::dumpInContext):
  73         (JSC::DFG::DesiredWatchpoints::isWatched):
  74         (JSC::DFG::InferredValueAdaptor::hasBeenInvalidated): Deleted.
  75         (JSC::DFG::InferredValueAdaptor::dumpInContext): Deleted.
  76         * dfg/DFGObjectAllocationSinkingPhase.cpp:
  77         * dfg/DFGSpeculativeJIT.cpp:
  78         (JSC::DFG::SpeculativeJIT::compileNewFunction):
  79         (JSC::DFG::SpeculativeJIT::compileCreateActivation):
  80         * ftl/FTLLowerDFGToB3.cpp:
  81         (JSC::FTL::DFG::LowerDFGToB3::compileCreateActivation):
  82         (JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
  83         * heap/Heap.cpp:
  84         (JSC::Heap::finalizeUnconditionalFinalizers):
  85         * runtime/FunctionExecutable.cpp:
  86         (JSC::FunctionExecutable::FunctionExecutable):
  87         (JSC::FunctionExecutable::finishCreation):
  88         (JSC::FunctionExecutable::visitChildren):
  89         * runtime/FunctionExecutable.h:
  90         * runtime/FunctionExecutableInlines.h: Copied from Source/JavaScriptCore/runtime/InferredValueInlines.h.
  91         (JSC::FunctionExecutable::finalizeUnconditionally):
  92         * runtime/InferredValue.cpp: Removed.
  93         * runtime/InferredValue.h:
  94         (JSC::InferredValue::inferredValue):
  95         (JSC::InferredValue::InferredValue):
  96         (JSC::InferredValue::~InferredValue):
  97         (JSC::InferredValue::stateOnJSThread const):
  98         (JSC::InferredValue::state const):
  99         (JSC::InferredValue::hasBeenInvalidated const):
 100         (JSC::InferredValue::isStillValid const):
 101         (JSC::InferredValue::invalidate):
 102         (JSC::InferredValue::isBeingWatched const):
 103         (JSC::InferredValue::notifyWrite):
 104         (JSC::InferredValue::isThin):
 105         (JSC::InferredValue::isFat):
 106         (JSC::InferredValue::decodeState):
 107         (JSC::InferredValue::encodeState):
 108         (JSC::InferredValue::isThin const):
 109         (JSC::InferredValue::isFat const):
 110         (JSC::InferredValue::fat):
 111         (JSC::InferredValue::fat const):
 112         (JSC::InferredValue::inflate):
 113         (JSC::InferredValue<JSCellType>::InferredValueWatchpointSet::notifyWriteSlow):
 114         (JSC::InferredValue<JSCellType>::notifyWriteSlow):
 115         (JSC::InferredValue<JSCellType>::add):
 116         (JSC::InferredValue<JSCellType>::inflateSlow):
 117         (JSC::InferredValue<JSCellType>::freeFat):
 118         * runtime/InferredValueInlines.h:
 119         (JSC::InferredValue<JSCellType>::finalizeUnconditionally):
 120         (JSC::InferredValue::finalizeUnconditionally): Deleted.
 121         * runtime/JSFunctionInlines.h:
 122         (JSC::JSFunction::createWithInvalidatedReallocationWatchpoint):
 123         * runtime/JSSymbolTableObject.h:
 124         (JSC::JSSymbolTableObject::setSymbolTable):
 125         * runtime/SymbolTable.cpp:
 126         (JSC::SymbolTable::finishCreation):
 127         (JSC::SymbolTable::visitChildren):
 128         * runtime/SymbolTable.h:
 129         * runtime/SymbolTableInlines.h: Copied from Source/JavaScriptCore/runtime/InferredValueInlines.h.
 130         (JSC::SymbolTable::finalizeUnconditionally):
 131         * runtime/VM.cpp:
 132         (JSC::VM::VM):
 133         * runtime/VM.h:
 134
 135 2019-06-04  Tadeu Zagallo  <tzagallo@apple.com>
 136
 137         Argument elimination should check for negative indices in GetByVal
 138         https://bugs.webkit.org/show_bug.cgi?id=198302
 139         <rdar://problem/51188095>
 140
 141         Reviewed by Filip Pizlo.
 142
 143         In DFG::ArgumentEliminationPhase, the index is treated as unsigned, but there's no check
 144         for overflow in the addition. In compileGetMyArgumentByVal, there's a check for overflow,
 145         but the index is treated as signed, resulting in an index lower than numberOfArgumentsToSkip.
 146
 147         * dfg/DFGArgumentsEliminationPhase.cpp:
 148         * ftl/FTLLowerDFGToB3.cpp:
 149         (JSC::FTL::DFG::LowerDFGToB3::compileGetMyArgumentByVal):
 150
 151 2019-06-04  Tadeu Zagallo  <tzagallo@apple.com>
 152
 153         JSScript should not keep bytecode cache in memory
 154         https://bugs.webkit.org/show_bug.cgi?id=198482
 155
 156         Reviewed by Saam Barati.
 157
 158         When JSScript writes to the cache, we keep the in-memory serialized bytecode alive.
 159         Instead, we should only ever hold the memory mapped bytecode cache to avoid using
 160         too much memory.
 161
 162         * API/JSScript.mm:
 163         (-[JSScript writeCache:]):
 164         * API/tests/testapi.mm:
 165         (testBytecodeCacheWithSyntaxError):
 166         * CMakeLists.txt:
 167         * JavaScriptCore.xcodeproj/project.pbxproj:
 168         * Sources.txt:
 169         * jsc.cpp:
 170         * parser/SourceProvider.h:
 171         * runtime/BytecodeCacheError.cpp: Added.
 172         (JSC::BytecodeCacheError::StandardError::isValid const):
 173         (JSC::BytecodeCacheError::StandardError::message const):
 174         (JSC::BytecodeCacheError::WriteError::isValid const):
 175         (JSC::BytecodeCacheError::WriteError::message const):
 176         (JSC::BytecodeCacheError::operator=):
 177         (JSC::BytecodeCacheError::isValid const):
 178         (JSC::BytecodeCacheError::message const):
 179         * runtime/BytecodeCacheError.h: Added.
 180         (JSC::BytecodeCacheError::StandardError::StandardError):
 181         (JSC::BytecodeCacheError::WriteError::WriteError):
 182         * runtime/CachedBytecode.h:
 183         (JSC::CachedBytecode::create):
 184         * runtime/CachedTypes.cpp:
 185         (JSC::Encoder::Encoder):
 186         (JSC::Encoder::release):
 187         (JSC::Encoder::releaseMapped):
 188         (JSC::encodeCodeBlock):
 189         (JSC::encodeFunctionCodeBlock):
 190         * runtime/CachedTypes.h:
 191         * runtime/CodeCache.cpp:
 192         (JSC::serializeBytecode):
 193         * runtime/CodeCache.h:
 194         * runtime/Completion.cpp:
 195         (JSC::generateProgramBytecode):
 196         (JSC::generateModuleBytecode):
 197         * runtime/Completion.h:
 198
 199 2019-06-03  Caio Lima  <ticaiolima@gmail.com>
 200
 201         [ESNext][BigInt] Implement support for "**"
 202         https://bugs.webkit.org/show_bug.cgi?id=190799
 203
 204         Reviewed by Saam Barati.
 205
 206         We are introducing support for BigInt into "**" operator. This Patch
 207         also includes changes into DFG, introducing a new node "ValuePow" that
 208         is responsible to handle UntypedUse and BigIntUse.
 209
 210         * dfg/DFGAbstractInterpreterInlines.h:
 211         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
 212
 213         ValuePow(Untyped, Untyped) still can propagate constant if AI proves
 214         it. We are doing so if AI proves rhs and lhs as numbers.
 215
 216         * dfg/DFGByteCodeParser.cpp:
 217         (JSC::DFG::ByteCodeParser::parseBlock):
 218
 219         When compiling op_pow, we first verify if rhs and lhs can be any Int
 220         or number. If this happen, we emit ArithPow, otherwise we fallback to
 221         ValuePow and rely on fixup to convert it to ArithPow if possible.
 222
 223         * dfg/DFGClobberize.h:
 224         (JSC::DFG::clobberize):
 225
 226         We only clobberize world if ValuePow is UntypedUse. Otherwise, we can
 227         properly support CSE.
 228
 229         * dfg/DFGDoesGC.cpp:
 230         (JSC::DFG::doesGC):
 231
 232         JSBigInt::exponentiate allocates JSBigInts to perform calculation and
 233         it can trigger GC. ValuePow(UntypedUse) can trigger GC because it can
 234         execute user code.
 235
 236         * dfg/DFGFixupPhase.cpp:
 237         (JSC::DFG::FixupPhase::fixupArithPow):
 238         (JSC::DFG::FixupPhase::fixupNode):
 239         * dfg/DFGNodeType.h:
 240         * dfg/DFGOperations.cpp:
 241         * dfg/DFGOperations.h:
 242         * dfg/DFGPredictionPropagationPhase.cpp:
 243         * dfg/DFGSafeToExecute.h:
 244         (JSC::DFG::safeToExecute):
 245         * dfg/DFGSpeculativeJIT.cpp:
 246         (JSC::DFG::SpeculativeJIT::compileValuePow):
 247         * dfg/DFGSpeculativeJIT.h:
 248         * dfg/DFGSpeculativeJIT32_64.cpp:
 249         (JSC::DFG::SpeculativeJIT::compile):
 250         * dfg/DFGSpeculativeJIT64.cpp:
 251         (JSC::DFG::SpeculativeJIT::compile):
 252         * dfg/DFGValidate.cpp:
 253         * ftl/FTLCapabilities.cpp:
 254         (JSC::FTL::canCompile):
 255         * ftl/FTLLowerDFGToB3.cpp:
 256         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
 257         (JSC::FTL::DFG::LowerDFGToB3::compileValuePow):
 258         * runtime/CommonSlowPaths.cpp:
 259         (JSC::SLOW_PATH_DECL):
 260
 261         We are adding proper support to BigInt on op_pow. The specification
 262         defines that we can only apply pow when both operands have the same
 263         type after calling ToNumeric().
 264
 265         * runtime/JSBigInt.cpp:
 266         (JSC::JSBigInt::exponentiate):
 267         * runtime/JSBigInt.h:
 268
 269 2019-06-03  Yusuke Suzuki  <ysuzuki@apple.com>
 270
 271         [JSC] JSObject::attemptToInterceptPutByIndexOnHole should use getPrototype instead of getPrototypeDirect
 272         https://bugs.webkit.org/show_bug.cgi?id=198477
 273         <rdar://problem/51299504>
 274
 275         Reviewed by Saam Barati.
 276
 277         JSObject::attemptToInterceptPutByIndexOnHole uses getPrototypeDirect, but it should use getPrototype to
 278         handle getPrototype methods in derived JSObject classes correctly.
 279
 280         * runtime/JSArrayInlines.h:
 281         (JSC::JSArray::pushInline):
 282         * runtime/JSObject.cpp:
 283         (JSC::JSObject::putByIndex):
 284         (JSC::JSObject::attemptToInterceptPutByIndexOnHoleForPrototype):
 285         (JSC::JSObject::attemptToInterceptPutByIndexOnHole):
 286         (JSC::JSObject::putByIndexBeyondVectorLength):
 287
 288 2019-06-03  Don Olmstead  <don.olmstead@sony.com>
 289
 290         [CMake] Add WebKit::JavaScriptCore target
 291         https://bugs.webkit.org/show_bug.cgi?id=198403
 292
 293         Reviewed by Konstantin Tokarev.
 294
 295         Create the WebKit::JavaScriptCore target and use that to propagate headers. Use
 296         WEBKIT_COPY_FILES instead of WEBKIT_MAKE_FORWARDING_HEADERS.
 297
 298         * CMakeLists.txt:
 299         * shell/CMakeLists.txt:
 300
 301 2019-06-03  Commit Queue  <commit-queue@webkit.org>
 302
 303         Unreviewed, rolling out r246022.
 304         https://bugs.webkit.org/show_bug.cgi?id=198486
 305
 306         Causing Internal build failures and JSC test failures
 307         (Requested by ShawnRoberts on #webkit).
 308
 309         Reverted changeset:
 310
 311         "Reenable Gigacage on ARM64."
 312         https://bugs.webkit.org/show_bug.cgi?id=198453
 313         https://trac.webkit.org/changeset/246022
 314
 315 2019-06-03  Darin Adler  <darin@apple.com>
 316
 317         Finish cleanup of String::number for floating point
 318         https://bugs.webkit.org/show_bug.cgi?id=198471
 319
 320         Reviewed by Yusuke Suzuki.
 321
 322         * dfg/DFGStrengthReductionPhase.cpp:
 323         (JSC::DFG::StrengthReductionPhase::handleNode): Use String::number instead of
 324         String::numberToStringECMAScript, since that's now the default.
 325         * parser/ParserArena.h:
 326         (JSC::IdentifierArena::makeNumericIdentifier): Ditto.
 327         * runtime/JSONObject.cpp:
 328         (JSC::Stringifier::appendStringifiedValue): Use appendNumber instead of
 329         builder.appendECMAScriptNumber, since that's now the default.
 330         * runtime/NumberPrototype.cpp:
 331         (JSC::toStringWithRadix): Use String::number instead of
 332         String::numberToStringECMAScript, since that's now the default.
 333         (JSC::numberProtoFuncToExponential): Ditto.
 334         (JSC::numberProtoFuncToFixed): Ditto.
 335         (JSC::numberProtoFuncToPrecision): Ditto.
 336         (JSC::numberToStringInternal): Ditto.
 337         * runtime/NumericStrings.h:
 338         (JSC::NumericStrings::add): Ditto.
 339         * wasm/WasmBBQPlan.cpp:
 340         (JSC::Wasm::BBQPlan::prepare): Ditto.
 341
 342 2019-06-02  Yusuke Suzuki  <ysuzuki@apple.com>
 343
 344         [JSC] Crash explicitly if StructureIDs are exhausted
 345         https://bugs.webkit.org/show_bug.cgi?id=198467
 346
 347         Reviewed by Sam Weinig.
 348
 349         When StructureIDTable::m_size reaches to s_maximumNumberOfStructures, newCapacity in resize function is also capped with s_maximumNumberOfStructures.
 350         So m_size == newCapacity. In that case, the following code in resize function, `makeFreeListFromRange(m_size, m_capacity - 1);` starts executing the
 351         wrong code.
 352
 353         Currently, this is safe. We immediately execute the wrong code in makeFreeListFromRange, and crash with zero division. But we should not rely on
 354         this crash, and instead we should explicitly crash because we exhaust StructureIDs.
 355
 356         This patch inserts RELEASE_ASSERT for `m_size < newCapacity` status to ensure that resize is always extending the table.
 357
 358         In practice, this crash does not happen in Safari because Safari has memory footprint limit. To exhaust StructureIDs, we need to allocate massive
 359         amount of Structures, and it exceeds the memory footprint limit and the process will be killed.
 360
 361         * runtime/StructureIDTable.cpp:
 362         (JSC::StructureIDTable::resize):
 363
 364 2019-06-02  Keith Miller  <keith_miller@apple.com>
 365
 366         Reenable Gigacage on ARM64.
 367         https://bugs.webkit.org/show_bug.cgi?id=198453
 368
 369         Reviewed by Filip Pizlo.
 370
 371         This patch adds back Gigacaging on Apple's ARM64 ports. Unlike the
 372         old Gigacage however, arm64e uses both Gigacaging and PAC. Since
 373         Gigacaging would otherwise strip a PAC failed authenticate bit we
 374         force a load of the pointer into some garbage register.
 375
 376         * dfg/DFGSpeculativeJIT.cpp:
 377         (JSC::DFG::SpeculativeJIT::jumpForTypedArrayIsNeuteredIfOutOfBounds):
 378         (JSC::DFG::SpeculativeJIT::cageTypedArrayStorage):
 379         * ftl/FTLLowerDFGToB3.cpp:
 380         (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
 381         (JSC::FTL::DFG::LowerDFGToB3::untagArrayPtr):
 382         (JSC::FTL::DFG::LowerDFGToB3::caged):
 383         * jit/AssemblyHelpers.h:
 384         (JSC::AssemblyHelpers::cageConditionally):
 385         * llint/LowLevelInterpreter64.asm:
 386
 387 2019-06-02  Tadeu Zagallo  <tzagallo@apple.com>
 388
 389         CachedMetadataTable::decode leaks empty tables
 390         https://bugs.webkit.org/show_bug.cgi?id=198465
 391         <rdar://problem/51307673>
 392
 393         Reviewed by Yusuke Suzuki.
 394
 395         CachedMetadataTable::decode creates the metadata and never calls finalize on it.
 396         This leaks the underlying UnlinkedMetadataTable buffer when m_hasMetadata is false,
 397         since the buffer would be freed in finalize instead of in the destructor.
 398
 399         * bytecode/UnlinkedMetadataTable.h:
 400         (JSC::UnlinkedMetadataTable::empty):
 401         * bytecode/UnlinkedMetadataTableInlines.h:
 402         (JSC::UnlinkedMetadataTable::UnlinkedMetadataTable):
 403         * runtime/CachedTypes.cpp:
 404         (JSC::CachedMetadataTable::decode const):
 405
 406 2019-05-31  Yusuke Suzuki  <ysuzuki@apple.com>
 407
 408         Unreviewed, fix setEntryAddressCommon register usage in LLInt ASM Windows 64
 409         https://bugs.webkit.org/show_bug.cgi?id=197979
 410
 411         * llint/LowLevelInterpreter.asm:
 412         * offlineasm/x86.rb:
 413
 414 2019-05-31  Stephan Szabo  <stephan.szabo@sony.com>
 415
 416         [PlayStation] Support internal test runner for JSC tests
 417         https://bugs.webkit.org/show_bug.cgi?id=198386
 418
 419         Reviewed by Alex Christensen.
 420
 421         Support using our test runner with our wrapper library
 422         to run multiple tests sequentially in one execution. With
 423         default arguments, will run as normal, but with special
 424         arguments will shift into this mode.
 425
 426         * runtime/Options.h:
 427         Export the default values of the JSC options similar
 428         to the values for resetting the values between tests.
 429         * shell/PlatformPlayStation.cmake:
 430         * shell/playstation/TestShell.cpp: Added.
 431         (setupTestRun): Function to set up the system before starting the tests
 432         (preTest): Function for setting up individual test
 433         (runTest): Function to run a test execution
 434         (postTest): Function for shutdown of individual test
 435         (shutdownTestRun): Function for shutting down the system after test run completes.
 436
 437 2019-05-31  Don Olmstead  <don.olmstead@sony.com>
 438
 439         [CMake] Add WebKit::WTF target
 440         https://bugs.webkit.org/show_bug.cgi?id=198400
 441
 442         Reviewed by Konstantin Tokarev.
 443
 444         Use the WebKit::WTF target.
 445
 446         * CMakeLists.txt:
 447         * shell/CMakeLists.txt:
 448
 449 2019-05-30  Devin Rousso  <drousso@apple.com>
 450
 451         Web Inspector: Audit: there should be a default test for WebInspectorAudit.Resources functionality
 452         https://bugs.webkit.org/show_bug.cgi?id=196710
 453         <rdar://problem/49712348>
 454
 455         Reviewed by Joseph Pecoraro.
 456
 457         * inspector/protocol/Audit.json:
 458         Increment Audit version.
 459
 460 2019-05-30  Devin Rousso  <drousso@apple.com>
 461
 462         Web Inspector: Audit: tests are unable to get the current Audit version
 463         https://bugs.webkit.org/show_bug.cgi?id=198270
 464
 465         Reviewed by Timothy Hatcher.
 466
 467         Expose the Audit version number through the `WebInspectorObject` that's injected into tests
 468         so that they can decide at runtime whether they're supported (e.g. the `unsupported` result).
 469
 470         * inspector/agents/InspectorAuditAgent.h:
 471         * inspector/agents/InspectorAuditAgent.cpp:
 472         (Inspector::InspectorAuditAgent::populateAuditObject):
 473
 474 2019-05-30  Tadeu Zagallo  <tzagallo@apple.com> and Yusuke Suzuki  <ysuzuki@apple.com>
 475
 476         [JSC] Implement op_wide16 / op_wide32 and introduce 16bit version bytecode
 477         https://bugs.webkit.org/show_bug.cgi?id=197979
 478
 479         Reviewed by Filip Pizlo.
 480
 481         This patch introduces 16bit bytecode size. Previously, we had two versions of bytecodes, 8bit and 32bit. However,
 482         in Gmail, we found that a lot of bytecodes get 32bit because they do not fit in 8bit. 8bit is very small and large
 483         function easily emits a lot of 32bit bytecodes because of large VirtualRegister number etc. But they almost always
 484         fit in 16bit. If we can have 16bit version of bytecode, we can make most of the current 32bit bytecodes 16bit and
 485         save memory.
 486
 487         We rename rename op_wide to op_wide32 and introduce op_wide16. The mechanism is similar to old op_wide. When we
 488         get op_wide16, the following bytecode data is 16bit, and we execute 16bit version of bytecode in LLInt.
 489
 490         We also disable this op_wide16 feature in Windows CLoop, which is used in AppleWin port. When the code size of
 491         CLoop::execute increases, MSVC starts generating CLoop::execute function with very large stack allocation
 492         requirement. Even before introducing this 16bit bytecode, CLoop::execute in AppleWin takes almost 100KB stack
 493         height. After introducing this, it becomes 160KB. While the semantics of the function is correctly compiled,
 494         such a large stack allocation is not essentially necessary, and this leads to stack overflow errors quite easily,
 495         and tests fail with AppleWin port because it starts throwing stack overflow range error in various places.
 496         In this patch, for now, we just disable op_wide16 feature for AppleWin so that CLoop::execute takes 100KB
 497         stack allocation because this patch is not focusing on fixing AppleWin's CLoop issue. We introduce a new backend
 498         type for LLInt, "C_LOOP_WIN". "C_LOOP_WIN" do not generate wide16 version of code to reduce the code size of
 499         CLoop::execute. In the future, we should investigate whether this MSVC issue is fixed in Visual Studio 2019.
 500         Or we should consider always enabling ASM LLInt for Windows.
 501
 502         This patch improves Gmail by 7MB at least.
 503
 504         * CMakeLists.txt:
 505         * bytecode/BytecodeConventions.h:
 506         * bytecode/BytecodeDumper.cpp:
 507         (JSC::BytecodeDumper<Block>::dumpBlock):
 508         * bytecode/BytecodeList.rb:
 509         * bytecode/BytecodeRewriter.h:
 510         (JSC::BytecodeRewriter::Fragment::align):
 511         * bytecode/BytecodeUseDef.h:
 512         (JSC::computeUsesForBytecodeOffset):
 513         (JSC::computeDefsForBytecodeOffset):
 514         * bytecode/CodeBlock.cpp:
 515         (JSC::CodeBlock::finishCreation):
 516         * bytecode/CodeBlock.h:
 517         (JSC::CodeBlock::metadataTable const):
 518         * bytecode/Fits.h:
 519         * bytecode/Instruction.h:
 520         (JSC::Instruction::opcodeID const):
 521         (JSC::Instruction::isWide16 const):
 522         (JSC::Instruction::isWide32 const):
 523         (JSC::Instruction::hasMetadata const):
 524         (JSC::Instruction::sizeShiftAmount const):
 525         (JSC::Instruction::size const):
 526         (JSC::Instruction::wide16 const):
 527         (JSC::Instruction::wide32 const):
 528         (JSC::Instruction::isWide const): Deleted.
 529         (JSC::Instruction::wide const): Deleted.
 530         * bytecode/InstructionStream.h:
 531         (JSC::InstructionStreamWriter::write):
 532         * bytecode/Opcode.h:
 533         * bytecode/OpcodeSize.h:
 534         * bytecompiler/BytecodeGenerator.cpp:
 535         (JSC::BytecodeGenerator::alignWideOpcode16):
 536         (JSC::BytecodeGenerator::alignWideOpcode32):
 537         (JSC::BytecodeGenerator::emitGetByVal): Previously, we always emit 32bit op_get_by_val for bytecodes in `for-in` context because
 538         its operand can be replaced to the other VirtualRegister later. But if we know that replacing VirtualRegister can fit in 8bit / 16bit
 539         a-priori, we should not emit 32bit version. We expose OpXXX::checkWithoutMetadataID to check whether we could potentially compact
 540         the bytecode for the given operands.
 541
 542         (JSC::BytecodeGenerator::emitYieldPoint):
 543         (JSC::StructureForInContext::finalize):
 544         (JSC::BytecodeGenerator::alignWideOpcode): Deleted.
 545         * bytecompiler/BytecodeGenerator.h:
 546         (JSC::BytecodeGenerator::write):
 547         * dfg/DFGCapabilities.cpp:
 548         (JSC::DFG::capabilityLevel):
 549         * generator/Argument.rb:
 550         * generator/DSL.rb:
 551         * generator/Metadata.rb:
 552         * generator/Opcode.rb: A little bit weird but checkImpl's argument must be reference. We are relying on that BoundLabel is once modified in
 553         this check phase, and the modified BoundLabel will be used when emitting the code. If checkImpl copies the passed BoundLabel, this modification
 554         will be discarded in this checkImpl function and make the code generation broken.
 555
 556         * generator/Section.rb:
 557         * jit/JITExceptions.cpp:
 558         (JSC::genericUnwind):
 559         * llint/LLIntData.cpp:
 560         (JSC::LLInt::initialize):
 561         * llint/LLIntData.h:
 562         (JSC::LLInt::opcodeMapWide16):
 563         (JSC::LLInt::opcodeMapWide32):
 564         (JSC::LLInt::getOpcodeWide16):
 565         (JSC::LLInt::getOpcodeWide32):
 566         (JSC::LLInt::getWide16CodePtr):
 567         (JSC::LLInt::getWide32CodePtr):
 568         (JSC::LLInt::opcodeMapWide): Deleted.
 569         (JSC::LLInt::getOpcodeWide): Deleted.
 570         (JSC::LLInt::getWideCodePtr): Deleted.
 571         * llint/LLIntOfflineAsmConfig.h:
 572         * llint/LLIntSlowPaths.cpp:
 573         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
 574         * llint/LLIntSlowPaths.h:
 575         * llint/LowLevelInterpreter.asm:
 576         * llint/LowLevelInterpreter.cpp:
 577         (JSC::CLoop::execute):
 578         * llint/LowLevelInterpreter32_64.asm:
 579         * llint/LowLevelInterpreter64.asm:
 580         * offlineasm/arm.rb:
 581         * offlineasm/arm64.rb:
 582         * offlineasm/asm.rb:
 583         * offlineasm/backends.rb:
 584         * offlineasm/cloop.rb:
 585         * offlineasm/instructions.rb:
 586         * offlineasm/mips.rb:
 587         * offlineasm/x86.rb: Load operation with sign extension should also have the extended size information. For example, loadbs should be
 588         converted to loadbsi for 32bit sign extension (and loadbsq for 64bit sign extension). And use loadbsq / loadhsq for loading VirtualRegister
 589         information in LowLevelInterpreter64 since they will be used for pointer arithmetic and they are using machine register width.
 590
 591         * parser/ResultType.h:
 592         (JSC::OperandTypes::OperandTypes):
 593         (JSC::OperandTypes::first const):
 594         (JSC::OperandTypes::second const):
 595         (JSC::OperandTypes::bits):
 596         (JSC::OperandTypes::fromBits):
 597         (): Deleted.
 598         (JSC::OperandTypes::toInt): Deleted.
 599         (JSC::OperandTypes::fromInt): Deleted.
 600         We reduce sizeof(OperandTypes) from unsigned to uint16_t, which guarantees that OperandTypes always fit in 16bit bytecode.
 601
 602 2019-05-30  Justin Michaud  <justin_michaud@apple.com>
 603
 604         oss-fuzz: jsc: Issue 15016: jsc: Abrt in JSC::Wasm::AirIRGenerator::addLocal (15016)
 605         https://bugs.webkit.org/show_bug.cgi?id=198355
 606
 607         Reviewed by Saam Barati.
 608
 609         Fix missing anyref case in addLocal.
 610
 611         * wasm/WasmAirIRGenerator.cpp:
 612         (JSC::Wasm::AirIRGenerator::addLocal):
 613
 614 2019-05-29  Don Olmstead  <don.olmstead@sony.com>
 615
 616         Remove ENABLE definitions from WebKit config files
 617         https://bugs.webkit.org/show_bug.cgi?id=197858
 618
 619         Reviewed by Simon Fraser.
 620
 621         Sync FeatureDefines.xcconfig.
 622
 623         * Configurations/FeatureDefines.xcconfig:
 624
 625 2019-05-28  Dean Jackson  <dino@apple.com>
 626
 627         Implement Promise.allSettled
 628         https://bugs.webkit.org/show_bug.cgi?id=197600
 629         <rdar://problem/50483885>
 630
 631         Reviewed by Keith Miller.
 632
 633         Implement Promise.allSettled
 634         https://github.com/tc39/proposal-promise-allSettled/
 635
 636         Shipping in Firefox since version 68.
 637         Shipping in V8 since https://chromium.googlesource.com/v8/v8.git/+/1f6d27e8df819b448712dface6ad367fb8de426b
 638
 639         * builtins/PromiseConstructor.js:
 640         (allSettled.newResolveRejectElements.resolveElement):
 641         (allSettled.newResolveRejectElements.rejectElement):
 642         (allSettled.newResolveRejectElements):
 643         (allSettled): Added.
 644         * runtime/JSPromiseConstructor.cpp: Add ref to allSettled.
 645
 646 2019-05-28  Michael Saboff  <msaboff@apple.com>
 647
 648         [YARR] Properly handle RegExp's that require large ParenContext space
 649         https://bugs.webkit.org/show_bug.cgi?id=198065
 650
 651         Reviewed by Keith Miller.
 652
 653         Changed what happens when we exceed VM::patternContextBufferSize when compiling a RegExp
 654         that needs ParenCOntextSpace to fail the RegExp JIT compilation and fall back to the YARR
 655         interpreter.  This can save large amounts of JIT memory for a
 656         JIT'ed function that cannot ever succeed.
 657
 658         * yarr/YarrJIT.cpp:
 659         (JSC::Yarr::YarrGenerator::initParenContextFreeList):
 660         (JSC::Yarr::YarrGenerator::compile):
 661
 662 2019-05-28  Tadeu Zagallo  <tzagallo@apple.com>
 663
 664         JITOperations putByVal should mark negative array indices as out-of-bounds
 665         https://bugs.webkit.org/show_bug.cgi?id=198271
 666
 667         Reviewed by Saam Barati.
 668
 669         Similar to what was done to getByVal in r245769, we should also mark put_by_val as out-of-bounds
 670         when we exit from DFG for putting to a negative index. This avoids the same scenario where we keep
 671         recompiling a CodeBlock with DFG and exiting at the same bytecode.
 672
 673         This is a 3.7x improvement in the microbenchmark being added: put-by-val-negative-array-index.js.
 674
 675         * jit/JITOperations.cpp:
 676
 677 2019-05-28  Yusuke Suzuki  <ysuzuki@apple.com>
 678
 679         Unreviewed, revert r242070 due to Membuster regression
 680         https://bugs.webkit.org/show_bug.cgi?id=195013
 681
 682         Membuster shows ~0.3% regression.
 683
 684         * heap/Heap.cpp:
 685         (JSC::Heap::Heap):
 686         (JSC::Heap::runBeginPhase):
 687         * heap/Heap.h:
 688         * heap/HeapInlines.h:
 689         (JSC::Heap::forEachSlotVisitor):
 690         (JSC::Heap::numberOfSlotVisitors): Deleted.
 691         * heap/MarkingConstraintSolver.cpp:
 692         (JSC::MarkingConstraintSolver::didVisitSomething const):
 693         * heap/SlotVisitor.h:
 694
 695 2019-05-27  Tadeu Zagallo  <tzagallo@apple.com>
 696
 697         Fix opensource build of testapi
 698         https://bugs.webkit.org/show_bug.cgi?id=198256
 699
 700         Reviewed by Alexey Proskuryakov.
 701
 702         In r245564, we added custom entitlements to testapi to allow caching
 703         bytecode in data vaults, but we should only use the entitlements for
 704         internal builds. Otherwises, testapi gets killed on launch. Also fix the
 705         formatting for the errors added in the same patch, according to comments
 706         in the bug after the patch had already landed.
 707
 708         * API/JSScript.mm:
 709         (validateBytecodeCachePath):
 710         * Configurations/ToolExecutable.xcconfig:
 711
 712 2019-05-25  Tadeu Zagallo  <tzagallo@apple.com>
 713
 714         JITOperations getByVal should mark negative array indices as out-of-bounds
 715         https://bugs.webkit.org/show_bug.cgi?id=198229
 716
 717         Reviewed by Saam Barati.
 718
 719         get_by_val with an array or string as base value and a negative index causes DFG to OSR exit,
 720         but baseline doesn't mark it as out-of-bounds, since it only considers positive indices. This
 721         leads to discarding DFG code, recompiling it and exiting at the same bytecode.
 722
 723         This is observed in the prepack-wtb subtest of JetStream2. In popContext#CdOhFJ, the last item
 724         of the array popped and the new last value is accessed using `array[array.length - 1]`, which
 725         is -1 when the array is empty. It shows a ~0.5% progression in JetStream2, but it's within the
 726         noise.
 727
 728         * jit/JITOperations.cpp:
 729         (JSC::getByVal):
 730
 731 2019-05-24  Justin Michaud  <justin_michaud@apple.com>
 732
 733         [WASM-References] Support Anyref in globals
 734         https://bugs.webkit.org/show_bug.cgi?id=198102
 735
 736         Reviewed by Saam Barati.
 737
 738         Support anyref for globals, imports and exports. This adds code in B3 and Air to emit a write barrier
 739         on the JSWebAssemblyWrapper whenever an anyref global is set. This also fixes a small bug in emitCCall
 740         for air where it adds code to the wrong block.
 741
 742         * wasm/WasmAirIRGenerator.cpp:
 743         (JSC::Wasm::AirIRGenerator::emitCCall):
 744         (JSC::Wasm::AirIRGenerator::moveOpForValueType):
 745         (JSC::Wasm::AirIRGenerator::setGlobal):
 746         (JSC::Wasm::AirIRGenerator::emitWriteBarrierForJSWrapper):
 747         * wasm/WasmB3IRGenerator.cpp:
 748         (JSC::Wasm::B3IRGenerator::setGlobal):
 749         (JSC::Wasm::B3IRGenerator::emitWriteBarrierForJSWrapper):
 750         * wasm/WasmInstance.cpp:
 751         (JSC::Wasm::Instance::Instance):
 752         (JSC::Wasm::Instance::setGlobal):
 753         * wasm/WasmInstance.h:
 754         (JSC::Wasm::Instance::loadI32Global const):
 755         (JSC::Wasm::Instance::loadI64Global const):
 756         (JSC::Wasm::Instance::setGlobal):
 757         (JSC::Wasm::Instance::shouldMarkGlobal):
 758         (JSC::Wasm::Instance::numGlobals const):
 759         * wasm/WasmSectionParser.cpp:
 760         (JSC::Wasm::SectionParser::parseInitExpr):
 761         * wasm/js/JSWebAssemblyInstance.cpp:
 762         (JSC::JSWebAssemblyInstance::visitChildren):
 763         * wasm/js/WebAssemblyModuleRecord.cpp:
 764         (JSC::WebAssemblyModuleRecord::link):
 765
 766 2019-05-23  Devin Rousso  <drousso@apple.com>
 767
 768         Web Inspector: Overlay: rulers/guides should be shown whenever element selection is enabled
 769         https://bugs.webkit.org/show_bug.cgi?id=198088
 770
 771         Reviewed by Timothy Hatcher.
 772
 773         When trying to "measure" the absolute position (to the viewport) or relative position (to
 774         another element) of a given element, often the easiest way is to enable Element Selection
 775         and Show Rulers at the same time.
 776
 777         This can have the undesired "side-effect" of having the rulers be always present, even when
 778         not highlighting any nodes.
 779
 780         The ideal functionality is to allow the rulers/guides to be shown when element selection is
 781         active and a node is hovered, regardless of whether "Show Rulers" is enabled.
 782
 783         * inspector/protocol/DOM.json:
 784         Add an optional `showRulers` parameter to `DOM.setInspectModeEnabled` that supersedes the
 785         current value of `Page.setShowRulers` as to whether rulers/guides are shown.
 786
 787 2019-05-23  Ross Kirsling  <ross.kirsling@sony.com>
 788
 789         Socket-based RWI should be able to inspect a JSContext
 790         https://bugs.webkit.org/show_bug.cgi?id=198197
 791
 792         Reviewed by Don Olmstead.
 793
 794         * inspector/remote/socket/RemoteInspectorSocket.cpp:
 795         (Inspector::RemoteInspector::listingForInspectionTarget const):
 796         Just use the debuggableType strings that WebInspectorUI ultimately wants.
 797
 798 2019-05-23  Tadeu Zagallo  <tzagallo@apple.com>
 799
 800         DFG::OSREntry should not perform arity check
 801         https://bugs.webkit.org/show_bug.cgi?id=198189
 802
 803         Reviewed by Saam Barati.
 804
 805         The check prevents OSR entering from hot loops inside functions that were called
 806         with too few arguments.
 807
 808         * dfg/DFGOSREntry.cpp:
 809         (JSC::DFG::prepareOSREntry):
 810
 811 2019-05-23  Ross Kirsling  <ross.kirsling@sony.com>
 812
 813         Lexer<T>::parseDecimal ought to ASSERT isASCIIDigit
 814         https://bugs.webkit.org/show_bug.cgi?id=198156
 815
 816         Reviewed by Keith Miller.
 817
 818         * parser/Lexer.cpp:
 819         (JSC::Lexer<T>::parseDecimal):
 820         Add ASSERT -- apparently the issue with doing so earlier was simply
 821         that m_current can be anything at all when m_buffer8 is non-empty.
 822
 823         (JSC::Lexer<T>::lexWithoutClearingLineTerminator):
 824         Clean up a few things in the vicinity of r245655:
 825          - fix token enum values in a couple of error cases added in the last patch
 826          - add UNLIKELY for existing error cases that forgot to use it
 827          - simplify some control flow
 828
 829 2019-05-23  Adrian Perez de Castro  <aperez@igalia.com>
 830
 831         Fix a few missing header inclusions often masked by by unified sources
 832         https://bugs.webkit.org/show_bug.cgi?id=198180
 833
 834         Reviewed by Eric Carlson.
 835
 836         * assembler/PerfLog.cpp: Add missing <array> header inclusion.
 837         * wasm/WasmBinding.cpp: Add missing "WasmCallingConvention.h" inclusion.
 838
 839 2019-05-23  Tadeu Zagallo  <tzagallo@apple.com>
 840
 841         createListFromArrayLike should throw if value is not an object
 842         https://bugs.webkit.org/show_bug.cgi?id=198138
 843
 844         Reviewed by Yusuke Suzuki.
 845
 846         According to the spec[1], createListFromArrayLike should throw a type error if the array-like value
 847         passed in is not an object.
 848         [1]: https://www.ecma-international.org/ecma-262/9.0/index.html#sec-createlistfromarraylike
 849
 850         * runtime/JSObjectInlines.h:
 851         (JSC::createListFromArrayLike):
 852         * runtime/ProxyObject.cpp:
 853         (JSC::ProxyObject::performGetOwnPropertyNames):
 854         * runtime/ReflectObject.cpp:
 855         (JSC::reflectObjectConstruct):
 856
 857 2019-05-22  Yusuke Suzuki  <ysuzuki@apple.com>
 858
 859         [JSC] UnlinkedMetadataTable's offset table should be small
 860         https://bugs.webkit.org/show_bug.cgi?id=197910
 861
 862         Reviewed by Saam Barati.
 863
 864         In Gmail, we found that massive # of UnlinkedMetadataTable (21979 - 24727) exists. Each UnlinkedMetadataTable takes at least 204 bytes
 865         because of large (unsinged) offset table. This patch reduces the size of offset table by introducing 16bit version offset table.
 866         Previously our code for looking up Metadata is like this.
 867
 868             offset = offsetTable32[opcode]
 869             metadata = (SomeOp::Metadata*)table[offset] + id
 870
 871         Instead, we introduce uint16_t offset table. The lookup code becomes like this.
 872
 873             offset = offsetTable16[opcode]
 874             if (!offset)
 875                 offset = offsetTable32[opcode]
 876             metadata = (SomeOp::Metadata*)table[offset] + id
 877
 878         We use 0 offset as a marker to indicate that we have 32bit offset table. This is OK since 0 offset does not appear since all the offsets
 879         included in this table is larger than s_offset16TableSize.
 880
 881         32bit offset table is allocated only when the offset exceeds 16bit range. It means that this will be used only when Metadata table is larger
 882         than almost 64KB. Even in Gmail, such MetadataTable is rare, and additional 32bit offset table size does not matter much in this case since
 883         MetadataTable is already so large.
 884
 885         Based on the # of UnlinkedMetadataTables, this optimization should improve Gmail steady state memory by 2MB.
 886
 887         * JavaScriptCore.xcodeproj/project.pbxproj:
 888         * Sources.txt:
 889         * bytecode/MetadataTable.cpp:
 890         (JSC::MetadataTable::~MetadataTable):
 891         (JSC::MetadataTable::destroy):
 892         * bytecode/MetadataTable.h:
 893         (JSC::MetadataTable::ref):
 894         (JSC::MetadataTable::deref):
 895         (JSC::MetadataTable::buffer):
 896         (JSC::MetadataTable::is32Bit const):
 897         (JSC::MetadataTable::offsetTable16 const):
 898         (JSC::MetadataTable::offsetTable32 const):
 899         (JSC::MetadataTable::totalSize const):
 900         (JSC::MetadataTable::getOffset const):
 901         (JSC::MetadataTable::getImpl):
 902         (JSC::MetadataTable::ref const): Deleted.
 903         (JSC::MetadataTable::deref const): Deleted.
 904         * bytecode/Opcode.cpp:
 905         * bytecode/UnlinkedMetadataTable.cpp: Added.
 906         (JSC::UnlinkedMetadataTable::finalize):
 907         * bytecode/UnlinkedMetadataTable.h:
 908         (JSC::UnlinkedMetadataTable::create):
 909         (JSC::UnlinkedMetadataTable::totalSize const):
 910         (JSC::UnlinkedMetadataTable::offsetTableSize const):
 911         (JSC::UnlinkedMetadataTable::preprocessBuffer const):
 912         (JSC::UnlinkedMetadataTable::buffer const):
 913         (JSC::UnlinkedMetadataTable::offsetTable16 const):
 914         (JSC::UnlinkedMetadataTable::offsetTable32 const):
 915         * bytecode/UnlinkedMetadataTableInlines.h:
 916         (JSC::UnlinkedMetadataTable::UnlinkedMetadataTable):
 917         (JSC::UnlinkedMetadataTable::addEntry):
 918         (JSC::UnlinkedMetadataTable::sizeInBytes):
 919         (JSC::UnlinkedMetadataTable::link):
 920         (JSC::UnlinkedMetadataTable::unlink):
 921         (JSC::UnlinkedMetadataTable::finalize): Deleted.
 922         * llint/LowLevelInterpreter.asm:
 923         * runtime/CachedTypes.cpp:
 924         (JSC::CachedMetadataTable::encode):
 925         (JSC::CachedMetadataTable::decode const):
 926
 927 2019-05-22  Yusuke Suzuki  <ysuzuki@apple.com>
 928
 929         [JSC] ArrayAllocationProfile should not access to butterfly in concurrent compiler
 930         https://bugs.webkit.org/show_bug.cgi?id=197809
 931
 932         Reviewed by Michael Saboff.
 933
 934         ArrayAllocationProfile assumes that Butterfly can be accessed concurrently. But this is not correct now
 935         since LargeAllocation Butterfly can be realloced. In this patch, we switch profiling array allocations
 936         only in the main thread. This allocation profiling is repeatedly called in the main thread's slow path,
 937         and it is also called when updating the profiles in the main thread.
 938
 939         We also rename updateAllPredictionsAndCountLiveness to updateAllValueProfilePredictionsAndCountLiveness
 940         since it only cares ValueProfiles.
 941
 942         * bytecode/ArrayAllocationProfile.cpp:
 943         (JSC::ArrayAllocationProfile::updateProfile):
 944         * bytecode/ArrayAllocationProfile.h:
 945         (JSC::ArrayAllocationProfile::selectIndexingTypeConcurrently):
 946         (JSC::ArrayAllocationProfile::selectIndexingType):
 947         (JSC::ArrayAllocationProfile::vectorLengthHintConcurrently):
 948         (JSC::ArrayAllocationProfile::vectorLengthHint):
 949         * bytecode/CodeBlock.cpp:
 950         (JSC::CodeBlock::updateAllValueProfilePredictionsAndCountLiveness):
 951         (JSC::CodeBlock::updateAllValueProfilePredictions):
 952         (JSC::CodeBlock::shouldOptimizeNow):
 953         (JSC::CodeBlock::updateAllPredictionsAndCountLiveness): Deleted.
 954         * bytecode/CodeBlock.h:
 955         * dfg/DFGByteCodeParser.cpp:
 956         (JSC::DFG::ByteCodeParser::parseBlock):
 957
 958 2019-05-22  Yusuke Suzuki  <ysuzuki@apple.com>
 959
 960         [JSC] Shrink Metadata
 961         https://bugs.webkit.org/show_bug.cgi?id=197940
 962
 963         Reviewed by Michael Saboff.
 964
 965         We get Metadata related data in Gmail and it turns out the following things.
 966
 967         1. At peak, MetadataTable eats a lot of bytes (30 MB - 50 MB, sometimes 70 MB while total Gmail footprint is 400 - 500 MB).
 968         2. After full GC happens, most of Metadata is destroyed while some are kept. Still keeps 1 MB. But after the GC, # of MetadataTable eventually grows again.
 969
 970         If we shrink Metadata, we can reduce the peak memory footprint in Gmail.
 971
 972         This patch shrinks Metadata. This patch first focus on low hanging fruits: it does not include the change removing OSR exit JSValue in ValueProfile.
 973         This patch uses fancy bit juggling & leverages nice data types to reduce Metadata, as follows.
 974
 975         1. ValueProfile is reduced from 32 to 24. It reduces Metadata using ValueProfile.
 976         2. ArrayProfile is reduced from 16 to 12. Ditto.
 977         3. OpCall::Metadata is reduced from 88 to 64.
 978         4. OpGetById::Metadata is reduced from 56 to 40.
 979         5. OpToThis::Metadata is reduced from 48 to 32.
 980         6. OpNewObject::Metadata is reduced from 32 to 16.
 981
 982         According to the gathered data, it should reduce 1-2MB in steady state in Gmail, much more in peak memory, ~1 MB in the state just after full GC.
 983         It also improves RAMification by 0.3% (6 runs).
 984
 985         * bytecode/ArrayProfile.cpp:
 986         * bytecode/ArrayProfile.h:
 987         (JSC::ArrayProfile::ArrayProfile):
 988         (JSC::ArrayProfile::bytecodeOffset const): Deleted.
 989         (JSC::ArrayProfile::isValid const): Deleted.
 990         * bytecode/BytecodeList.rb:
 991         * bytecode/CallLinkStatus.cpp:
 992         (JSC::CallLinkStatus::computeFromLLInt):
 993         * bytecode/CodeBlock.cpp:
 994         (JSC::CodeBlock::finishCreation):
 995         (JSC::CodeBlock::finalizeLLIntInlineCaches):
 996         (JSC::CodeBlock::getArrayProfile):
 997         (JSC::CodeBlock::updateAllPredictionsAndCountLiveness):
 998         (JSC::CodeBlock::dumpValueProfiles):
 999         * bytecode/CodeBlock.h:
1000         (JSC::CodeBlock::valueProfileForArgument):
1001         * bytecode/CodeBlockInlines.h:
1002         (JSC::CodeBlock::forEachValueProfile):
1003         (JSC::CodeBlock::forEachArrayProfile):
1004         * bytecode/GetByIdMetadata.h:
1005         We use ProtoLoad's JSObject's high bits to embed hitCountForLLIntCaching and mode, since they
1006         are always zero for ProtoLoad mode.
1007
1008         (): Deleted.
1009         * bytecode/GetByIdStatus.cpp:
1010         (JSC::GetByIdStatus::computeFromLLInt):
1011         * bytecode/LLIntCallLinkInfo.h:
1012         (JSC::LLIntCallLinkInfo::isLinked const):
1013         (JSC::LLIntCallLinkInfo::link):
1014         (JSC::LLIntCallLinkInfo::unlink):
1015         (JSC::LLIntCallLinkInfo::callee const):
1016         (JSC::LLIntCallLinkInfo::lastSeenCallee const):
1017         (JSC::LLIntCallLinkInfo::clearLastSeenCallee):
1018         (JSC::LLIntCallLinkInfo::LLIntCallLinkInfo): Deleted.
1019         (JSC::LLIntCallLinkInfo::isLinked): Deleted.
1020         In LLIntCallLinkInfo, we always set the same value to lastSeenCallee and callee. But later, callee can be cleared.
1021         It means that we can represent them in one value + cleared flag. We encode this flag into the lowest bit of the callee cell so
1022         that we can make them one pointer. We also use PackedRawSentinelNode to get some space, and embed ArrayProfile into this space
1023         to get further memory reduction.
1024
1025         * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
1026         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::clearLLIntGetByIdCache):
1027         * bytecode/LazyOperandValueProfile.h:
1028         (JSC::LazyOperandValueProfile::LazyOperandValueProfile):
1029         (JSC::LazyOperandValueProfile::key const):
1030         * bytecode/MetadataTable.h:
1031         (JSC::MetadataTable::buffer):
1032         * bytecode/ObjectAllocationProfile.h:
1033         (JSC::ObjectAllocationProfileBase::offsetOfAllocator):
1034         (JSC::ObjectAllocationProfileBase::offsetOfStructure):
1035         (JSC::ObjectAllocationProfileBase::clear):
1036         (JSC::ObjectAllocationProfileBase::visitAggregate):
1037         (JSC::ObjectAllocationProfile::setPrototype):
1038         (JSC::ObjectAllocationProfileWithPrototype::prototype):
1039         (JSC::ObjectAllocationProfileWithPrototype::clear):
1040         (JSC::ObjectAllocationProfileWithPrototype::visitAggregate):
1041         (JSC::ObjectAllocationProfileWithPrototype::setPrototype):
1042         (JSC::ObjectAllocationProfile::offsetOfAllocator): Deleted.
1043         (JSC::ObjectAllocationProfile::offsetOfStructure): Deleted.
1044         (JSC::ObjectAllocationProfile::offsetOfInlineCapacity): Deleted.
1045         (JSC::ObjectAllocationProfile::ObjectAllocationProfile): Deleted.
1046         (JSC::ObjectAllocationProfile::isNull): Deleted.
1047         (JSC::ObjectAllocationProfile::structure): Deleted.
1048         (JSC::ObjectAllocationProfile::prototype): Deleted.
1049         (JSC::ObjectAllocationProfile::inlineCapacity): Deleted.
1050         (JSC::ObjectAllocationProfile::clear): Deleted.
1051         (JSC::ObjectAllocationProfile::visitAggregate): Deleted.
1052         * bytecode/ObjectAllocationProfileInlines.h:
1053         (JSC::ObjectAllocationProfileBase<Derived>::initializeProfile):
1054         (JSC::ObjectAllocationProfileBase<Derived>::possibleDefaultPropertyCount):
1055         (JSC::ObjectAllocationProfile::initializeProfile): Deleted.
1056         (JSC::ObjectAllocationProfile::possibleDefaultPropertyCount): Deleted.
1057         OpNewObject's ObjectAllocationProfile does not need to hold prototype. So we have two versions now, ObjectAllocationProfile and ObjectAllocationProfileWithPrototype
1058         to cut one pointer. We also remove inline capacity since this can be retrieved from Structure.
1059
1060         * bytecode/Opcode.h:
1061         * bytecode/ValueProfile.h:
1062         (JSC::ValueProfileBase::ValueProfileBase):
1063         (JSC::ValueProfileBase::totalNumberOfSamples const):
1064         (JSC::ValueProfileBase::isSampledBefore const):
1065         (JSC::ValueProfileBase::dump):
1066         (JSC::ValueProfileBase::computeUpdatedPrediction):
1067         (JSC::MinimalValueProfile::MinimalValueProfile):
1068         (JSC::ValueProfileWithLogNumberOfBuckets::ValueProfileWithLogNumberOfBuckets):
1069         (JSC::ValueProfile::ValueProfile):
1070         (JSC::getValueProfileBytecodeOffset): Deleted.
1071         Bytecode offset is no longer used. And sample count is not used effectively.
1072
1073         * dfg/DFGByteCodeParser.cpp:
1074         (JSC::DFG::ByteCodeParser::parseBlock):
1075         * dfg/DFGOperations.cpp:
1076         * dfg/DFGSpeculativeJIT.cpp:
1077         (JSC::DFG::SpeculativeJIT::compileCreateThis):
1078         * ftl/FTLAbstractHeapRepository.h:
1079         * jit/JITCall.cpp:
1080         (JSC::JIT::compileSetupFrame):
1081         * jit/JITCall32_64.cpp:
1082         (JSC::JIT::compileSetupFrame):
1083         * jit/JITOpcodes.cpp:
1084         (JSC::JIT::emit_op_catch):
1085         (JSC::JIT::emit_op_to_this):
1086         (JSC::JIT::emit_op_create_this):
1087         * jit/JITOpcodes32_64.cpp:
1088         (JSC::JIT::emit_op_catch):
1089         (JSC::JIT::emit_op_create_this):
1090         (JSC::JIT::emit_op_to_this):
1091         * jit/JITOperations.cpp:
1092         * jit/JITPropertyAccess.cpp:
1093         (JSC::JIT::emit_op_get_by_id):
1094         * llint/LLIntSlowPaths.cpp:
1095         (JSC::LLInt::setupGetByIdPrototypeCache):
1096         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1097         (JSC::LLInt::setUpCall):
1098         * llint/LowLevelInterpreter32_64.asm:
1099         * llint/LowLevelInterpreter64.asm:
1100         * runtime/CommonSlowPaths.cpp:
1101         (JSC::SLOW_PATH_DECL):
1102         * runtime/FunctionRareData.h:
1103         * tools/HeapVerifier.cpp:
1104         (JSC::HeapVerifier::validateJSCell):
1105
1106 2019-05-22  Ross Kirsling  <ross.kirsling@sony.com>
1107
1108         [ESNext] Implement support for Numeric Separators
1109         https://bugs.webkit.org/show_bug.cgi?id=196351
1110
1111         Reviewed by Keith Miller.
1112
1113         Implement the following proposal, which is now Stage 3:
1114           https://github.com/tc39/proposal-numeric-separator
1115
1116         Specifically, this allows `_` to be used as a separator in numeric literals.
1117         It may be inserted arbitrarily without semantic effect, but it may not occur:
1118           - multiple times in a row
1119           - at the beginning or end of the literal
1120           - adjacent to `0x`, `0b`, `0o`, `.`, `e`, or `n`
1121           - after a leading zero (e.g. `0_123`), even in sloppy mode
1122
1123         * parser/Lexer.cpp:
1124         (JSC::isASCIIDigitOrSeparator): Added.
1125         (JSC::isASCIIHexDigitOrSeparator): Added.
1126         (JSC::isASCIIBinaryDigitOrSeparator): Added.
1127         (JSC::isASCIIOctalDigitOrSeparator): Added.
1128         (JSC::Lexer<T>::parseHex):
1129         (JSC::Lexer<T>::parseBinary):
1130         (JSC::Lexer<T>::parseOctal):
1131         (JSC::Lexer<T>::parseDecimal):
1132         (JSC::Lexer<T>::parseNumberAfterDecimalPoint):
1133         (JSC::Lexer<T>::parseNumberAfterExponentIndicator):
1134         (JSC::Lexer<T>::lexWithoutClearingLineTerminator):
1135         * parser/Lexer.h:
1136
1137 2019-05-22  Tadeu Zagallo  <tzagallo@apple.com>
1138
1139         llint_slow_path_get_by_id needs to hold the CodeBlock's lock to update the metadata's mode
1140         https://bugs.webkit.org/show_bug.cgi?id=198120
1141         <rdar://problem/49668795>
1142
1143         Reviewed by Michael Saboff.
1144
1145         There are two places in llint_slow_path_get_by_id where we change the
1146         metadata's mode without holding the CodeBlock's lock. This is an issue
1147         when switching to and from ArrayLength mode, since other places can
1148         either get a pointer to an array profile that will be overwritten or
1149         an array profile that hasn't yet been initialized.
1150
1151         * llint/LLIntSlowPaths.cpp:
1152         (JSC::LLInt::LLINT_SLOW_PATH_DECL):
1153
1154 2019-05-22  Commit Queue  <commit-queue@webkit.org>
1155
1156         Unreviewed, rolling out r245634.
1157         https://bugs.webkit.org/show_bug.cgi?id=198140
1158
1159         'This patch makes JSC crash on launch in debug builds'
1160         (Requested by tadeuzagallo on #webkit).
1161
1162         Reverted changeset:
1163
1164         "[ESNext] Implement support for Numeric Separators"
1165         https://bugs.webkit.org/show_bug.cgi?id=196351
1166         https://trac.webkit.org/changeset/245634
1167
1168 2019-05-22 Zagallo  <tzagallo@apple.com>
1169
1170         Fix validateExceptionChecks for CLoop
1171         https://bugs.webkit.org/show_bug.cgi?id=191253
1172
1173         Reviewed by Keith Miller.
1174
1175         validateExceptionChecks relies on the stack position to determine if
1176         an ExceptionScope was going to be handled by LLInt or JIT, but when
1177         running with CLoop, it was comparing VM::topEntryFrame, which was an
1178         address inside the CLoopStack to machine stack. This caused exceptions
1179         to never be checked on x86 and always fail on ARM.
1180
1181         * runtime/CatchScope.h:
1182         * runtime/ExceptionScope.h:
1183         * runtime/ThrowScope.h:
1184         * runtime/VM.cpp:
1185         (JSC::VM::currentCLoopStackPointer const):
1186         * runtime/VM.h:
1187
1188 2019-05-22  Tadeu Zagallo  <tzagallo@apple.com>
1189
1190         Stack-buffer-overflow in decodeURIComponent
1191         https://bugs.webkit.org/show_bug.cgi?id=198109
1192         <rdar://problem/50397550>
1193
1194         Reviewed by Michael Saboff.
1195
1196         Since r244828 we started using U8_MAX_LENGTH to determine the size of the buffer and
1197         U8_COUNT_TRAIL_BYTES when decoding UTF-8 sequences in JSC::decode. However, U8_MAX_LENGTH
1198         is defined as 4 and in pre-60 ICU U8_COUNT_TRAIL_BYTES returns 0..5.
1199
1200         * runtime/JSGlobalObjectFunctions.cpp:
1201         (JSC::decode):
1202
1203 2019-05-22  Yusuke Suzuki  <ysuzuki@apple.com>
1204
1205         Don't clear PropertyNameArray in Proxy code
1206         https://bugs.webkit.org/show_bug.cgi?id=197691
1207
1208         Reviewed by Saam Barati.
1209
1210         ProxyObject::performGetOwnPropertyNames clears the given PropertyNameArray to filter out non-enumerable keys.
1211         But this does not assume that PropertyNameArray already contains the keys collected in the different objects.
1212         We have an assumption that PropertyNameArray is always increasing, and JSPropertyNameEnumerator relies on this.
1213         Since ProxyObject::performGetOwnPropertyNames clears the passed PropertyNameArray which contained the other
1214         keys collected at some point of prototype hierarchy, this breaks JSPropertyNameEnumerator. Let's see the example.
1215
1216         var object = { __proto__: someProxy, someKey: 42 };
1217         // Here, we first collect "someKey" in object. And using the same PropertyNameArray to add more keys from __proto__.
1218         // But Proxy accidentally clears the passed PropertyNameArray, so "someKey" becomes missing.
1219         for (var key in object);
1220
1221         This patch fixes ProxyObject::performGetOwnPropertyNames. Using separate PropertyNameArray to collect keys, and
1222         filtering and adding them to the passed PropertyNameArray later. We also remove PropertyNameArray::reset method
1223         since this breaks JSPropertyNameEnumerator's assumption.
1224
1225         We also fix the issue by changing seenKeys' HashSet<UniquedStringImpl*> to HashSet<RefPtr<UniquedStringImpl>>.
1226         They can be deallocated if it is not added to trapResult later and it is toString-ed result from 'toPropertyKey()'.
1227
1228         * runtime/PropertyNameArray.h:
1229         (JSC::PropertyNameArray::reset): Deleted.
1230         * runtime/ProxyObject.cpp:
1231         (JSC::ProxyObject::performGetOwnPropertyNames):
1232
1233 2019-05-22  Ross Kirsling  <ross.kirsling@sony.com>
1234
1235         [ESNext] Implement support for Numeric Separators
1236         https://bugs.webkit.org/show_bug.cgi?id=196351
1237
1238         Reviewed by Keith Miller.
1239
1240         Implement the following proposal, which is now Stage 3:
1241           https://github.com/tc39/proposal-numeric-separator
1242
1243         Specifically, this allows `_` to be used as a separator in numeric literals.
1244         It may be inserted arbitrarily without semantic effect, but it may not occur:
1245           - multiple times in a row
1246           - at the beginning or end of the literal
1247           - adjacent to `0x`, `0b`, `0o`, `.`, `e`, or `n`
1248           - after a leading zero (e.g. `0_123`), even in sloppy mode
1249
1250         * parser/Lexer.cpp:
1251         (JSC::isASCIIDigitOrSeparator): Added.
1252         (JSC::isASCIIHexDigitOrSeparator): Added.
1253         (JSC::isASCIIBinaryDigitOrSeparator): Added.
1254         (JSC::isASCIIOctalDigitOrSeparator): Added.
1255         (JSC::Lexer<T>::parseHex):
1256         (JSC::Lexer<T>::parseBinary):
1257         (JSC::Lexer<T>::parseOctal):
1258         (JSC::Lexer<T>::parseDecimal):
1259         (JSC::Lexer<T>::parseNumberAfterDecimalPoint):
1260         (JSC::Lexer<T>::parseNumberAfterExponentIndicator):
1261         (JSC::Lexer<T>::lexWithoutClearingLineTerminator):
1262         * parser/Lexer.h:
1263
1264 2019-05-22  Yusuke Suzuki  <ysuzuki@apple.com>
1265
1266         [JSC] ArrayBufferContents::tryAllocate signs the pointer with allocation size and authenticates it with sizeInBytes
1267         https://bugs.webkit.org/show_bug.cgi?id=198101
1268
1269         Reviewed by Michael Saboff.
1270
1271         When we allocate 0-length ArrayBuffer, we allocate 1 byte storage instead because we would like to ensure that
1272         non-neutered ArrayBuffer always have non nullptr. While we allocate a 1 byte storage, this ArrayBuffer says
1273         sizeInBytes = 0. However, we accidentally configure the vector pointer with this 1 byte size in the constructor.
1274         In ARM64E device, we sign the vector pointer with modifier = 1 (1 byte size), and later we authenticate this
1275         pointer with modifier = 0 (sizeInBytes), and fail to authenticate the pointer.
1276
1277         In this patch, we sign the pointer with sizeInBytes so that we correctly authenticate the 0 bytes vector pointer.
1278
1279         * runtime/ArrayBuffer.cpp:
1280         (JSC::ArrayBufferContents::tryAllocate):
1281
1282 2019-05-21  Ross Kirsling  <ross.kirsling@sony.com>
1283
1284         [PlayStation] Don't call fcntl.
1285         https://bugs.webkit.org/show_bug.cgi?id=197961
1286
1287         Reviewed by Fujii Hironori.
1288
1289         * inspector/remote/socket/posix/RemoteInspectorSocketPOSIX.cpp:
1290         (Inspector::Socket::setup):
1291         Use WTF::setCloseOnExec and WTF::setNonBlock.
1292
1293 2019-05-21  Stephan Szabo  <stephan.szabo@sony.com>
1294
1295         [PlayStation] Update initializer for changed port options
1296         https://bugs.webkit.org/show_bug.cgi?id=198057
1297
1298         Reviewed by Ross Kirsling.
1299
1300         * shell/playstation/Initializer.cpp:
1301         (initializer): Remove loading of shared JavaScriptCore
1302         library.
1303
1304 2019-05-21  Tadeu Zagallo  <tzagallo@apple.com>
1305
1306         Fix production build after r245564
1307         https://bugs.webkit.org/show_bug.cgi?id=197898
1308
1309         Reviewed by Keith Miller.
1310
1311         The production configuration should not set CODE_SIGN_IDENTITY.
1312
1313         * Configurations/ToolExecutable.xcconfig:
1314
1315 2019-05-21  Keith Miller  <keith_miller@apple.com>
1316
1317         Unreviewed, add mistakenly ommited initializer.
1318
1319         * runtime/RegExpInlines.h:
1320
1321 2019-05-21  Keith Miller  <keith_miller@apple.com>
1322
1323         Unreviewed build fix add UNUSED_PARAM.
1324
1325         * runtime/RegExpInlines.h:
1326         (JSC::PatternContextBufferHolder::PatternContextBufferHolder):
1327
1328 2019-05-20  Keith Miller  <keith_miller@apple.com>
1329
1330         Cleanup Yarr regexp code around paren contexts.
1331         https://bugs.webkit.org/show_bug.cgi?id=198063
1332
1333         Reviewed by Yusuke Suzuki.
1334
1335         There are three refactoring changes around paren contexts:
1336         1. Make EncodedMatchResult the same type as MatchResult on X86_64 and arm64 and uint64_t elsewhere.
1337         2. All function pointer types for Yarr JIT generated code reserve space for paren contexts.
1338         3. initParenContextFreeList should bail based on VM::patternContextBufferSize as that's the buffer size anyway.
1339
1340         * runtime/MatchResult.h:
1341         (JSC::MatchResult::MatchResult):
1342         * runtime/RegExpInlines.h:
1343         (JSC::PatternContextBufferHolder::PatternContextBufferHolder):
1344         (JSC::PatternContextBufferHolder::~PatternContextBufferHolder):
1345         (JSC::PatternContextBufferHolder::size):
1346         (JSC::RegExp::matchInline):
1347         * runtime/VM.h:
1348         * yarr/YarrJIT.cpp:
1349         (JSC::Yarr::YarrGenerator::initParenContextFreeList):
1350         * yarr/YarrJIT.h:
1351         (JSC::Yarr::YarrCodeBlock::execute):
1352
1353 2019-05-20  Tadeu Zagallo  <tzagallo@apple.com>
1354
1355         Only cache bytecode for API clients in data vaults
1356         https://bugs.webkit.org/show_bug.cgi?id=197898
1357         <rdar://problem/45945449>
1358
1359         Reviewed by Keith Miller.
1360
1361         Enforce that API clients only store cached bytecode in data vaults. This prevents
1362         another process from compromising the current one by tampering with the bytecode.
1363
1364         * API/JSScript.mm:
1365         (validateBytecodeCachePath):
1366         (+[JSScript scriptOfType:withSource:andSourceURL:andBytecodeCache:inVirtualMachine:error:]):
1367         (+[JSScript scriptOfType:memoryMappedFromASCIIFile:withSourceURL:andBytecodeCache:inVirtualMachine:error:]):
1368         * API/tests/testapi.mm:
1369         (cacheFileInDataVault):
1370         (testModuleBytecodeCache):
1371         (testProgramBytecodeCache):
1372         (testBytecodeCacheWithSyntaxError):
1373         (testBytecodeCacheWithSameCacheFileAndDifferentScript):
1374         (testCacheFileFailsWhenItsAlreadyCached):
1375         (testCanCacheManyFilesWithTheSameVM):
1376         (testIsUsingBytecodeCacheAccessor):
1377         (testBytecodeCacheValidation):
1378         (testObjectiveCAPI):
1379         * Configurations/ToolExecutable.xcconfig:
1380         * JavaScriptCore.xcodeproj/project.pbxproj:
1381         * testapi.entitlements: Added.
1382
1383 2019-05-20  Tadeu Zagallo  <tzagallo@apple.com>
1384
1385         Fix 32-bit btyecode cache crashes
1386         https://bugs.webkit.org/show_bug.cgi?id=198035
1387         <rdar://problem/49905560>
1388
1389         Reviewed by Michael Saboff.
1390
1391         There were 2 32-bit issues with the bytecode cache:
1392         - UnlinkedFunctionExecutable::m_cachedCodeBlockForConstructOffset was not initialized.
1393           The code was relying on the other member of the union, `m_unlinkedCodeBlockForConstruct`,
1394           initializing both m_cachedCodeBlockForCallOffset and m_cachedCodeBlockForConstructOffset.
1395           This is undefined behavior and is also incorrect in 32-bit. Since m_unlinkedCodeBlockForConstruct
1396           is 32-bit, it only initializes the first member of the struct.
1397         - Encoder::Page was not aligned at the end. This lead to unaligned allocations on subsequent
1398           pages, since the start of the following page would not be aligned.
1399
1400         * runtime/CachedTypes.cpp:
1401         (JSC::Encoder::release):
1402         (JSC::Encoder::Page::alignEnd):
1403         (JSC::Encoder::allocateNewPage):
1404         (JSC::VariableLengthObject::buffer const):
1405         (JSC::VariableLengthObject::allocate):
1406         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
1407
1408 2019-05-20  Ross Kirsling  <ross.kirsling@sony.com>
1409
1410         [WinCairo] Implement Remote Web Inspector Client.
1411         https://bugs.webkit.org/show_bug.cgi?id=197434
1412
1413         Reviewed by Don Olmstead.
1414
1415         * inspector/remote/socket/RemoteInspectorConnectionClient.cpp:
1416         (Inspector::RemoteInspectorConnectionClient::didAccept): Deleted.
1417         * inspector/remote/socket/RemoteInspectorConnectionClient.h:
1418         (Inspector::RemoteInspectorConnectionClient::didAccept):
1419         * inspector/remote/socket/RemoteInspectorServer.cpp:
1420         (Inspector::RemoteInspectorServer::dispatchMap):
1421
1422 2019-05-20  Carlos Garcia Campos  <cgarcia@igalia.com>
1423
1424         [GLIB] Crash when instantiating a js object registered with jsc_context_register_class on window object cleared
1425         https://bugs.webkit.org/show_bug.cgi?id=198037
1426
1427         Reviewed by Michael Catanzaro.
1428
1429         This happens because JSCClass is keeping a pointer to the JSCContext used when the class is registered, and the
1430         context can be destroyed before the class. We can't a reference to the context, because we don't really want to
1431         keep it alive. The life of the JSCClass is not attached to the JSCContext, but to its wrapped global context, so
1432         we can keep a pointer to the JSGlobalContextRef instead and create a new JSCContext wrapping it when
1433         needed. This patch is also making the context property of JSCClass non-readable, which was always the intention,
1434         that's why there isn't a public getter in the API.
1435
1436         * API/glib/JSCCallbackFunction.cpp:
1437         (JSC::JSCCallbackFunction::construct): Pass the context to jscClassGetOrCreateJSWrapper().
1438         * API/glib/JSCClass.cpp:
1439         (jscClassGetProperty): Remove the getter for context property.
1440         (jscClassSetProperty): Get the JSGlobalContextRef from the given JSCContext.
1441         (jsc_class_class_init): Make context writable only.
1442         (jscClassCreate): Use the passed in context instead of the member.
1443         (jscClassGetOrCreateJSWrapper): It receives now the context as parameter.
1444         (jscClassCreateContextWithJSWrapper): Ditto.
1445         (jscClassCreateConstructor): Get or create a JSCContext for our JSGlobalContextRef.
1446         (jscClassAddMethod): Ditto.
1447         (jsc_class_add_property): Ditto.
1448         * API/glib/JSCClassPrivate.h:
1449         * API/glib/JSCContext.cpp:
1450         (jsc_context_evaluate_in_object): Pass the context to jscClassCreateContextWithJSWrapper().
1451         * API/glib/JSCValue.cpp:
1452         (jsc_value_new_object): Pass the context to jscClassGetOrCreateJSWrapper().
1453
1454 2019-05-19  Tadeu Zagallo  <tzagallo@apple.com>
1455
1456         Add support for %pid in dumpJITMemoryPath
1457         https://bugs.webkit.org/show_bug.cgi?id=198026
1458
1459         Reviewed by Saam Barati.
1460
1461         This is necessary when using dumpJITMemory with Safari. Otherwise, multiple WebContent
1462         processes will try to write to the same file at the same time, which will crash since
1463         the file is open with exclusive locking.
1464
1465         * jit/ExecutableAllocator.cpp:
1466         (JSC::dumpJITMemory):
1467
1468 2019-05-18  Tadeu Zagallo  <tzagallo@apple.com>
1469
1470         Add extra information to dumpJITMemory
1471         https://bugs.webkit.org/show_bug.cgi?id=197998
1472
1473         Reviewed by Saam Barati.
1474
1475         Add ktrace events around the memory dump and mach_absolute_time to link the
1476         events with the entries in the dump. Additionally, add a background queue
1477         to flush on a configurable interval, since the atexit callback does not work
1478         in every situation.
1479
1480         * jit/ExecutableAllocator.cpp:
1481         (JSC::dumpJITMemory):
1482         * runtime/Options.h:
1483
1484 2019-05-17  Justin Michaud  <justin_michaud@apple.com>
1485
1486         [WASM-References] Add support for Anyref in parameters and return types, Ref.null and Ref.is_null for Anyref values.
1487         https://bugs.webkit.org/show_bug.cgi?id=197969
1488
1489         Reviewed by Keith Miller.
1490
1491         Add a new runtime option for wasm references.
1492         Add support for Anyref as a value type.
1493         Add support for Anyref in parameters and return types of Wasm functions. JSValues are marshalled into/out of wasm Anyrefs
1494                 as a black box, except null which becomes a Nullref value. Nullref is not expressible in the bytecode or in the js API.
1495         Add Ref.null and Ref.is_null for Anyref values. Support for these functions with funcrefs is out of scope.
1496
1497         * runtime/Options.h:
1498         * wasm/WasmAirIRGenerator.cpp:
1499         (JSC::Wasm::AirIRGenerator::tmpForType):
1500         (JSC::Wasm::AirIRGenerator::AirIRGenerator):
1501         (JSC::Wasm::AirIRGenerator::addConstant):
1502         (JSC::Wasm::AirIRGenerator::addRefIsNull):
1503         (JSC::Wasm::AirIRGenerator::addReturn):
1504         * wasm/WasmB3IRGenerator.cpp:
1505         (JSC::Wasm::B3IRGenerator::addRefIsNull):
1506         * wasm/WasmCallingConvention.h:
1507         (JSC::Wasm::CallingConventionAir::marshallArgument const):
1508         (JSC::Wasm::CallingConventionAir::setupCall const):
1509         * wasm/WasmFormat.h:
1510         (JSC::Wasm::isValueType):
1511         * wasm/WasmFunctionParser.h:
1512         (JSC::Wasm::FunctionParser<Context>::FunctionParser):
1513         (JSC::Wasm::FunctionParser<Context>::parseExpression):
1514         (JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
1515         * wasm/WasmValidate.cpp:
1516         (JSC::Wasm::Validate::addRefIsNull):
1517         * wasm/generateWasmOpsHeader.py:
1518         (bitSet):
1519         * wasm/js/JSToWasm.cpp:
1520         (JSC::Wasm::createJSToWasmWrapper):
1521         * wasm/js/WasmToJS.cpp:
1522         (JSC::Wasm::wasmToJS):
1523         * wasm/js/WebAssemblyFunction.cpp:
1524         (JSC::callWebAssemblyFunction):
1525         (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
1526         * wasm/wasm.json:
1527
1528 2019-05-17  Don Olmstead  <don.olmstead@sony.com>
1529
1530         [CMake] Use builtin FindICU
1531         https://bugs.webkit.org/show_bug.cgi?id=197934
1532
1533         Reviewed by Michael Catanzaro.
1534
1535         Remove uses of ICU_INCLUDE_DIRS and ICU_LIBRARIES.
1536
1537         * CMakeLists.txt:
1538         * PlatformWin.cmake:
1539
1540 2019-05-17  Keith Rollin  <krollin@apple.com>
1541
1542         Re-enable generate-xcfilelists
1543         https://bugs.webkit.org/show_bug.cgi?id=197933
1544         <rdar://problem/50831677>
1545
1546         Reviewed by Jonathan Bedard.
1547
1548         The following two tasks have been completed, and we can re-enable
1549         generate-xcfilelists:
1550
1551         Bug 197619 <rdar://problem/50507392> Temporarily disable generate-xcfilelists (197619)
1552         Bug 197622 <rdar://problem/50508222> Rewrite generate-xcfilelists in Python (197622)
1553
1554         * Scripts/check-xcfilelists.sh:
1555
1556 2019-05-16  Keith Miller  <keith_miller@apple.com>
1557
1558         Wasm should cage the memory base pointers in structs
1559         https://bugs.webkit.org/show_bug.cgi?id=197620
1560
1561         Reviewed by Saam Barati.
1562
1563         Currently, we use cageConditionally; this only matters for API
1564         users since the web content process cannot disable primitive
1565         gigacage. This patch also adds a set helper for union/intersection
1566         of RegisterSets.
1567
1568         * assembler/CPU.h:
1569         (JSC::isARM64E):
1570         * jit/RegisterSet.h:
1571         (JSC::RegisterSet::set):
1572         * wasm/WasmAirIRGenerator.cpp:
1573         (JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState):
1574         (JSC::Wasm::AirIRGenerator::addCallIndirect):
1575         * wasm/WasmB3IRGenerator.cpp:
1576         (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
1577         (JSC::Wasm::B3IRGenerator::addCallIndirect):
1578         * wasm/WasmBinding.cpp:
1579         (JSC::Wasm::wasmToWasm):
1580         * wasm/WasmInstance.h:
1581         (JSC::Wasm::Instance::cachedMemory const):
1582         (JSC::Wasm::Instance::updateCachedMemory):
1583         * wasm/WasmMemory.cpp:
1584         (JSC::Wasm::Memory::grow):
1585         * wasm/WasmMemory.h:
1586         (JSC::Wasm::Memory::memory const):
1587         * wasm/js/JSToWasm.cpp:
1588         (JSC::Wasm::createJSToWasmWrapper):
1589         * wasm/js/WebAssemblyFunction.cpp:
1590         (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
1591
1592 2019-05-16  David Kilzer  <ddkilzer@apple.com>
1593
1594         REGRESSION (r15133): Fix leak of JSStringRef in minidom
1595         <https://webkit.org/b/197968>
1596         <rdar://problem/50872430>
1597
1598         Reviewed by Joseph Pecoraro.
1599
1600         * API/tests/minidom.c:
1601         (print): Call JSStringRelease() to fix the leak.
1602
1603 2019-05-16  Ross Kirsling  <ross.kirsling@sony.com>
1604
1605         [JSC] Invalid AssignmentTargetType should be an early error.
1606         https://bugs.webkit.org/show_bug.cgi?id=197603
1607
1608         Reviewed by Keith Miller.
1609
1610         Since ES6, expressions like 0++, ++0, 0 = 0, and 0 += 0 are all specified as early errors:
1611           https://tc39.github.io/ecma262/#sec-update-expressions-static-semantics-early-errors
1612           https://tc39.github.io/ecma262/#sec-assignment-operators-static-semantics-early-errors
1613
1614         We currently throw late ReferenceErrors for these -- let's turn them into early SyntaxErrors.
1615         (This is based on the expectation that https://github.com/tc39/ecma262/pull/1527 will be accepted;
1616         if that doesn't come to pass, we can subsequently introduce early ReferenceError and revise these.)
1617
1618         * bytecompiler/NodesCodegen.cpp:
1619         (JSC::PostfixNode::emitBytecode): Add an assert for "function call LHS" case.
1620         (JSC::PrefixNode::emitBytecode): Add an assert for "function call LHS" case.
1621
1622         * parser/ASTBuilder.h:
1623         (JSC::ASTBuilder::isLocation): Added.
1624         (JSC::ASTBuilder::isAssignmentLocation): Fix misleading parameter name.
1625         (JSC::ASTBuilder::isFunctionCall): Added.
1626         (JSC::ASTBuilder::makeAssignNode): Add an assert for "function call LHS" case.
1627         * parser/SyntaxChecker.h:
1628         (JSC::SyntaxChecker::isLocation): Added.
1629         (JSC::SyntaxChecker::isAssignmentLocation): Fix incorrect definition and align with ASTBuilder.
1630         (JSC::SyntaxChecker::isFunctionCall): Added.
1631         * parser/Nodes.h:
1632         (JSC::ExpressionNode::isFunctionCall const): Added.
1633         Ensure that the parser can check whether an expression node is a function call.
1634
1635         * parser/Parser.cpp:
1636         (JSC::Parser<LexerType>::isSimpleAssignmentTarget): Added.
1637         (JSC::Parser<LexerType>::parseAssignmentExpression):
1638         (JSC::Parser<LexerType>::parseUnaryExpression): See below.
1639         * parser/Parser.h:
1640         Throw SyntaxError whenever an assignment or update expression's target is invalid.
1641         Unfortunately, it seems that web compatibility obliges us to exempt the "function call LHS" case in sloppy mode.
1642         (https://github.com/tc39/ecma262/issues/257#issuecomment-195106880)
1643
1644         Additional cleanup items:
1645           - Make use of `semanticFailIfTrue` for `isMetaProperty` checks, as it's equivalent.
1646           - Rename `requiresLExpr` to `hasPrefixUpdateOp` since it's now confusing,
1647             and get rid of `modifiesExpr` since it refers to the exact same condition.
1648           - Stop setting `lastOperator` near the end -- one case was incorrect and regardless neither is used.
1649
1650 2019-05-15  Saam Barati  <sbarati@apple.com>
1651
1652         Bound liveness of SetArgumentMaybe nodes when maximal flush insertion phase is enabled
1653         https://bugs.webkit.org/show_bug.cgi?id=197855
1654         <rdar://problem/50236506>
1655
1656         Reviewed by Michael Saboff.
1657
1658         Maximal flush insertion phase assumes it can extend the live range of
1659         variables. However, this is not true with SetArgumentMaybe nodes, because
1660         they are not guaranteed to demarcate the birth of a variable in the way
1661         that SetArgumentDefinitely does. This caused things to break in SSA conversion
1662         when we wanted to use the result of a SetArgumentMaybe node. To obviate this,
1663         when we're done inlining something with SetArgumentMaybes, we SetLocal(undefined)
1664         to the same set of locals. This caps the live range of the SetArgumentMaybe
1665         and makes it so that extending the live range of the SetLocal is valid.
1666
1667         * dfg/DFGByteCodeParser.cpp:
1668         (JSC::DFG::ByteCodeParser::handleVarargsInlining):
1669
1670 2019-05-14  Keith Miller  <keith_miller@apple.com>
1671
1672         Fix issue with byteOffset on ARM64E
1673         https://bugs.webkit.org/show_bug.cgi?id=197884
1674
1675         Reviewed by Saam Barati.
1676
1677         We forgot to remove the tag from the ArrayBuffer's data
1678         pointer. This corrupted data when computing the offset.  We didn't
1679         catch this because we didn't run any with a non-zero byteOffset in
1680         the JITs.
1681
1682         * dfg/DFGSpeculativeJIT.cpp:
1683         (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
1684         * ftl/FTLLowerDFGToB3.cpp:
1685         (JSC::FTL::DFG::LowerDFGToB3::compileGetTypedArrayByteOffset):
1686         (JSC::FTL::DFG::LowerDFGToB3::untagArrayPtr):
1687         (JSC::FTL::DFG::LowerDFGToB3::removeArrayPtrTag):
1688         (JSC::FTL::DFG::LowerDFGToB3::speculateTypedArrayIsNotNeutered):
1689         * jit/IntrinsicEmitter.cpp:
1690         (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter):
1691
1692 2019-05-14  Tadeu Zagallo  <tzagallo@apple.com>
1693
1694         REGRESSION (r245249): ASSERTION FAILED: !m_needExceptionCheck seen with stress/proxy-delete.js and stress/proxy-property-descriptor.js
1695         https://bugs.webkit.org/show_bug.cgi?id=197885
1696         <rdar://problem/50770190>
1697
1698         Reviewed by Yusuke Suzuki.
1699
1700         In r245249 we added a throw scope to JSObject::getOwnPropertyDescriptor and its
1701         callers now need to check for exceptions.
1702
1703         * runtime/ProxyObject.cpp:
1704         (JSC::performProxyGet):
1705         (JSC::ProxyObject::performDelete):
1706
1707 2019-05-14  Ross Kirsling  <ross.kirsling@sony.com>
1708
1709         Unreviewed restoration of non-unified build.
1710
1711         * dfg/DFGMinifiedID.h:
1712         * runtime/ObjectToStringAdaptiveStructureWatchpoint.cpp:
1713
1714 2019-05-14  Yusuke Suzuki  <ysuzuki@apple.com>
1715
1716         [JSC] Shrink sizeof(UnlinkedFunctionExecutable) more
1717         https://bugs.webkit.org/show_bug.cgi?id=197833
1718
1719         Reviewed by Darin Adler.
1720
1721         It turns out that Gmail creates so many JSFunctions, FunctionExecutables, and UnlinkedFunctionExecutables.
1722         So we should shrink size of them to save memory. As a first step, this patch reduces the sizeof(UnlinkedFunctionExecutable) more by 16 bytes.
1723
1724         1. We reorder some fields to get 8 bytes. And we use 31 bits for xxx offset things since their maximum size should be within 31 bits due to
1725            String's length & int32_t representation in our parser.
1726
1727         2. We drop m_inferredName and prefer m_ecmaName. The inferred name is used to offer better function name when the function expression lacks
1728            the name, but now ECMAScript has a specified semantics to name those functions with intuitive names. We should use ecmaName consistently,
1729            and should not eat 8 bytes for inferred names in UnlinkedFunctionExecutable.
1730
1731         We also fix generator ecma name.
1732
1733         * bytecode/CodeBlock.cpp:
1734         (JSC::CodeBlock::inferredName const):
1735         * bytecode/InlineCallFrame.cpp:
1736         (JSC::InlineCallFrame::inferredName const):
1737         * bytecode/UnlinkedFunctionExecutable.cpp:
1738         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
1739         * bytecode/UnlinkedFunctionExecutable.h:
1740         * parser/ASTBuilder.h:
1741         (JSC::ASTBuilder::createAssignResolve):
1742         (JSC::ASTBuilder::createGeneratorFunctionBody):
1743         (JSC::ASTBuilder::createGetterOrSetterProperty):
1744         (JSC::ASTBuilder::createProperty):
1745         (JSC::ASTBuilder::tryInferNameInPatternWithIdentifier):
1746         (JSC::ASTBuilder::makeAssignNode):
1747         * parser/Nodes.cpp:
1748         (JSC::FunctionMetadataNode::operator== const):
1749         (JSC::FunctionMetadataNode::dump const):
1750         * parser/Nodes.h:
1751         * runtime/CachedTypes.cpp:
1752         (JSC::CachedFunctionExecutable::ecmaName const):
1753         (JSC::CachedFunctionExecutable::encode):
1754         (JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
1755         (JSC::CachedFunctionExecutable::inferredName const): Deleted.
1756         * runtime/FunctionExecutable.h:
1757         * runtime/FunctionExecutableDump.cpp:
1758         (JSC::FunctionExecutableDump::dump const):
1759         * runtime/JSFunction.cpp:
1760         (JSC::JSFunction::calculatedDisplayName):
1761         (JSC::getCalculatedDisplayName):
1762         * runtime/SamplingProfiler.cpp:
1763         (JSC::SamplingProfiler::StackFrame::displayName):
1764         (JSC::SamplingProfiler::StackFrame::displayNameForJSONTests):
1765
1766 2019-05-13  Yusuke Suzuki  <ysuzuki@apple.com>
1767
1768         [JSC] Compress JIT related data more by using Packed<>
1769         https://bugs.webkit.org/show_bug.cgi?id=197866
1770
1771         Reviewed by Saam Barati.
1772
1773         This patch leverages Packed<> more to reduce JIT related data size. When we measure memory usage on Gmail, we found that a lot of memory is
1774         consumed in DFG data. This patch attempts to reduce that size by using Packed<> to make various data structure's alignment 1.
1775
1776         * dfg/DFGCommonData.cpp:
1777         (JSC::DFG::CommonData::shrinkToFit): Add more shrinkToFit.
1778         * dfg/DFGMinifiedID.h: Make alignment = 1.
1779         (JSC::DFG::MinifiedID::operator! const):
1780         (JSC::DFG::MinifiedID::operator== const):
1781         (JSC::DFG::MinifiedID::operator!= const):
1782         (JSC::DFG::MinifiedID::operator< const):
1783         (JSC::DFG::MinifiedID::operator> const):
1784         (JSC::DFG::MinifiedID::operator<= const):
1785         (JSC::DFG::MinifiedID::operator>= const):
1786         (JSC::DFG::MinifiedID::hash const):
1787         (JSC::DFG::MinifiedID::dump const):
1788         (JSC::DFG::MinifiedID::isHashTableDeletedValue const):
1789         (JSC::DFG::MinifiedID::bits const):
1790         * dfg/DFGMinifiedIDInlines.h:
1791         (JSC::DFG::MinifiedID::MinifiedID):
1792         * dfg/DFGMinifiedNode.cpp:
1793         (JSC::DFG::MinifiedNode::fromNode): Make sizeof(MinifiedNode) from 16 to 13 with alignment = 1.
1794         * dfg/DFGMinifiedNode.h:
1795         (JSC::DFG::MinifiedNode::id const):
1796         (JSC::DFG::MinifiedNode::hasConstant const):
1797         (JSC::DFG::MinifiedNode::constant const):
1798         (JSC::DFG::MinifiedNode::isPhantomDirectArguments const):
1799         (JSC::DFG::MinifiedNode::isPhantomClonedArguments const):
1800         (JSC::DFG::MinifiedNode::hasInlineCallFrame const):
1801         (JSC::DFG::MinifiedNode::inlineCallFrame const):
1802         (JSC::DFG::MinifiedNode::op const): Deleted.
1803         (JSC::DFG::MinifiedNode::hasInlineCallFrame): Deleted.
1804         * dfg/DFGVariableEvent.h: Make sizeof(VariableEvent) from 12 to 10 with alignment = 1.
1805         (JSC::DFG::VariableEvent::fillGPR):
1806         (JSC::DFG::VariableEvent::fillPair):
1807         (JSC::DFG::VariableEvent::fillFPR):
1808         (JSC::DFG::VariableEvent::birth):
1809         (JSC::DFG::VariableEvent::spill):
1810         (JSC::DFG::VariableEvent::death):
1811         (JSC::DFG::VariableEvent::setLocal):
1812         (JSC::DFG::VariableEvent::movHint):
1813         (JSC::DFG::VariableEvent::id const):
1814         (JSC::DFG::VariableEvent::gpr const):
1815         (JSC::DFG::VariableEvent::tagGPR const):
1816         (JSC::DFG::VariableEvent::payloadGPR const):
1817         (JSC::DFG::VariableEvent::fpr const):
1818         (JSC::DFG::VariableEvent::spillRegister const):
1819         (JSC::DFG::VariableEvent::bytecodeRegister const):
1820         (JSC::DFG::VariableEvent::machineRegister const):
1821         (JSC::DFG::VariableEvent::variableRepresentation const):
1822         * dfg/DFGVariableEventStream.cpp:
1823         (JSC::DFG::tryToSetConstantRecovery):
1824
1825 2019-05-13  Yusuke Suzuki  <ysuzuki@apple.com>
1826
1827         [WTF] Simplify GCThread and CompilationThread flags by adding them to WTF::Thread
1828         https://bugs.webkit.org/show_bug.cgi?id=197146
1829
1830         Reviewed by Saam Barati.
1831
1832         Rename Heap::Thread to Heap::HeapThread to remove conflict between WTF::Thread.
1833
1834         * heap/AlignedMemoryAllocator.cpp:
1835         (JSC::AlignedMemoryAllocator::registerDirectory):
1836         * heap/Heap.cpp:
1837         (JSC::Heap::HeapThread::HeapThread):
1838         (JSC::Heap::Heap):
1839         (JSC::Heap::runCurrentPhase):
1840         (JSC::Heap::runBeginPhase):
1841         (JSC::Heap::resumeThePeriphery):
1842         (JSC::Heap::requestCollection):
1843         (JSC::Heap::isCurrentThreadBusy):
1844         (JSC::Heap::notifyIsSafeToCollect):
1845         (JSC::Heap::Thread::Thread): Deleted.
1846         * heap/Heap.h:
1847         * heap/HeapInlines.h:
1848         (JSC::Heap::incrementDeferralDepth):
1849         (JSC::Heap::decrementDeferralDepth):
1850         (JSC::Heap::decrementDeferralDepthAndGCIfNeeded):
1851         * heap/MarkedSpace.cpp:
1852         (JSC::MarkedSpace::prepareForAllocation):
1853
1854 2019-05-13  Saam Barati  <sbarati@apple.com>
1855
1856         macro assembler code-pointer tagging has its arguments backwards
1857         https://bugs.webkit.org/show_bug.cgi?id=197677
1858
1859         Reviewed by Michael Saboff.
1860
1861         We had the destination as the leftmost instead of the rightmost argument,
1862         which goes against the convention of how we order arguments in macro assembler
1863         methods.
1864
1865         * assembler/MacroAssemblerARM64E.h:
1866         (JSC::MacroAssemblerARM64E::tagReturnAddress):
1867         (JSC::MacroAssemblerARM64E::untagReturnAddress):
1868         (JSC::MacroAssemblerARM64E::tagPtr):
1869         (JSC::MacroAssemblerARM64E::untagPtr):
1870         * dfg/DFGOSRExitCompilerCommon.cpp:
1871         (JSC::DFG::reifyInlinedCallFrames):
1872         * ftl/FTLThunks.cpp:
1873         (JSC::FTL::genericGenerationThunkGenerator):
1874         * jit/CCallHelpers.h:
1875         (JSC::CCallHelpers::prepareForTailCallSlow):
1876         * jit/CallFrameShuffler.cpp:
1877         (JSC::CallFrameShuffler::prepareForTailCall):
1878         * jit/ThunkGenerators.cpp:
1879         (JSC::emitPointerValidation):
1880         (JSC::arityFixupGenerator):
1881         * wasm/js/WebAssemblyFunction.cpp:
1882         (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
1883
1884 2019-05-13  Tadeu Zagallo  <tzagallo@apple.com>
1885
1886         JSObject::getOwnPropertyDescriptor is missing an exception check
1887         https://bugs.webkit.org/show_bug.cgi?id=197693
1888         <rdar://problem/50441784>
1889
1890         Reviewed by Saam Barati.
1891
1892         The method table call to getOwnPropertySlot might throw, and JSObject::getOwnPropertyDescriptor
1893         must handle the exception before calling PropertySlot::getValue, which can also throw.
1894
1895         * runtime/JSObject.cpp:
1896         (JSC::JSObject::getOwnPropertyDescriptor):
1897
1898 2019-05-13  Yusuke Suzuki  <ysuzuki@apple.com>
1899
1900         [JSC] Compress miscelaneous JIT related data structures with Packed<>
1901         https://bugs.webkit.org/show_bug.cgi?id=197830
1902
1903         Reviewed by Saam Barati.
1904
1905         This patch leverages Packed<> to compress miscelaneous data structures related to JIT.
1906
1907         1. JIT IC data structures
1908
1909         2. ValueRecovery
1910
1911             We use Packed<> for EncodedJSValue in ValueRecovery. This means that conservative GC cannot find
1912             these values. But this is OK anyway since ValueRecovery's constant should be already registered
1913             in DFG graph. From 16 (alignment 8) to 9 (alignment 1).
1914
1915         3. FTL::ExitValue
1916
1917             We use Packed<> for EncodedJSValue in FTL::ExitValue. This is also OK since this constant should
1918             be already registered by DFG/FTL graph. From 16 (alignment 8) to 9 (alignment 1).
1919
1920         * assembler/CodeLocation.h:
1921         * bytecode/ByValInfo.h:
1922         * bytecode/CallLinkInfo.cpp:
1923         (JSC::CallLinkInfo::CallLinkInfo):
1924         (JSC::CallLinkInfo::callReturnLocation):
1925         * bytecode/CallLinkInfo.h:
1926         (JSC::CallLinkInfo::nearCallMode const):
1927         * bytecode/CodeBlock.cpp:
1928         (JSC::CodeBlock::addJITAddIC):
1929         (JSC::CodeBlock::addJITMulIC):
1930         (JSC::CodeBlock::addJITSubIC):
1931         (JSC::CodeBlock::addJITNegIC):
1932         * bytecode/CodeBlock.h:
1933         (JSC::CodeBlock::addMathIC):
1934         * bytecode/InlineCallFrame.h:
1935         (JSC::InlineCallFrame::InlineCallFrame):
1936         * bytecode/ValueRecovery.h:
1937         (JSC::ValueRecovery::inGPR):
1938         (JSC::ValueRecovery::inPair):
1939         (JSC::ValueRecovery::inFPR):
1940         (JSC::ValueRecovery::displacedInJSStack):
1941         (JSC::ValueRecovery::constant):
1942         (JSC::ValueRecovery::directArgumentsThatWereNotCreated):
1943         (JSC::ValueRecovery::clonedArgumentsThatWereNotCreated):
1944         (JSC::ValueRecovery::gpr const):
1945         (JSC::ValueRecovery::tagGPR const):
1946         (JSC::ValueRecovery::payloadGPR const):
1947         (JSC::ValueRecovery::fpr const):
1948         (JSC::ValueRecovery::virtualRegister const):
1949         (JSC::ValueRecovery::withLocalsOffset const):
1950         (JSC::ValueRecovery::constant const):
1951         (JSC::ValueRecovery::nodeID const):
1952         * dfg/DFGSpeculativeJIT.cpp:
1953         (JSC::DFG::SpeculativeJIT::compileValueAdd):
1954         (JSC::DFG::SpeculativeJIT::compileValueSub):
1955         (JSC::DFG::SpeculativeJIT::compileValueNegate):
1956         (JSC::DFG::SpeculativeJIT::compileValueMul):
1957         * ftl/FTLExitValue.cpp:
1958         (JSC::FTL::ExitValue::materializeNewObject):
1959         * ftl/FTLExitValue.h:
1960         (JSC::FTL::ExitValue::inJSStack):
1961         (JSC::FTL::ExitValue::inJSStackAsInt32):
1962         (JSC::FTL::ExitValue::inJSStackAsInt52):
1963         (JSC::FTL::ExitValue::inJSStackAsDouble):
1964         (JSC::FTL::ExitValue::constant):
1965         (JSC::FTL::ExitValue::exitArgument):
1966         (JSC::FTL::ExitValue::exitArgument const):
1967         (JSC::FTL::ExitValue::adjustStackmapLocationsIndexByOffset):
1968         (JSC::FTL::ExitValue::constant const):
1969         (JSC::FTL::ExitValue::virtualRegister const):
1970         (JSC::FTL::ExitValue::objectMaterialization const):
1971         (JSC::FTL::ExitValue::withVirtualRegister const):
1972         * ftl/FTLLowerDFGToB3.cpp:
1973         (JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
1974         (JSC::FTL::DFG::LowerDFGToB3::compileValueSub):
1975         (JSC::FTL::DFG::LowerDFGToB3::compileValueMul):
1976         (JSC::FTL::DFG::LowerDFGToB3::compileUnaryMathIC):
1977         (JSC::FTL::DFG::LowerDFGToB3::compileBinaryMathIC):
1978         (JSC::FTL::DFG::LowerDFGToB3::compileArithAddOrSub):
1979         (JSC::FTL::DFG::LowerDFGToB3::compileValueNegate):
1980         * jit/CachedRecovery.h:
1981         * jit/CallFrameShuffleData.h:
1982         * jit/JITArithmetic.cpp:
1983         (JSC::JIT::emit_op_negate):
1984         (JSC::JIT::emit_op_add):
1985         (JSC::JIT::emit_op_mul):
1986         (JSC::JIT::emit_op_sub):
1987         * jit/JITMathIC.h:
1988         (JSC::isProfileEmpty):
1989         (JSC::JITBinaryMathIC::JITBinaryMathIC):
1990         (JSC::JITUnaryMathIC::JITUnaryMathIC):
1991         * jit/PolymorphicCallStubRoutine.h:
1992         (JSC::PolymorphicCallNode::hasCallLinkInfo):
1993         * jit/SnippetOperand.h:
1994         (JSC::SnippetOperand::asRawBits const):
1995         (JSC::SnippetOperand::asConstInt32 const):
1996         (JSC::SnippetOperand::asConstDouble const):
1997         (JSC::SnippetOperand::setConstInt32):
1998         (JSC::SnippetOperand::setConstDouble):
1999
2000 2019-05-12  Yusuke Suzuki  <ysuzuki@apple.com>
2001
2002         [JSC] Compress Watchpoint size by using enum type and Packed<> data structure
2003         https://bugs.webkit.org/show_bug.cgi?id=197730
2004
2005         Reviewed by Filip Pizlo.
2006
2007         Watchpoint takes 5~ MB memory in Gmail (total memory starts with 400 - 500 MB), so 1~%. Since it is allocated massively,
2008         reducing each size of Watchpoint reduces memory footprint significantly.
2009
2010         As a first step, this patch uses Packed<> and enum to reduce the size of Watchpoint.
2011
2012         1. Watchpoint should have enum type and should not use vtable. vtable takes one pointer, and it is too costly for such a
2013            memory sensitive objects. We perform downcast and dispatch the method of the derived classes based on this enum. Since
2014            the # of derived Watchpoint classes are limited (Only 8), we can list up them easily. One unfortunate thing is that
2015            we cannot do this for destructor so long as we use "delete" for deleting objects. If we dispatch the destructor of derived
2016            class in the destructor of the base class, we call the destructor of the base class multiple times. delete operator override
2017            does not help since custom delete operator is called after the destructor is called. While we can fix this issue by always
2018            using custom deleter, currently we do not since all the watchpoints do not have members which have non trivial destructor.
2019            Once it is strongly required, we can start using custom deleter, but for now, we do not need to do this.
2020
2021         2. We use Packed<> to compact pointers in Watchpoint. Since Watchpoint is a node of doubly linked list, each one has two
2022            pointers for prev and next. This is also too costly. PackedPtr reduces the size and makes alignment 1.S
2023
2024         3. We use PackedCellPtr<> for JSCells in Watchpoint. This leverages alignment information and makes pointers smaller in
2025            Darwin ARM64. One important thing to note here is that since this pointer is packed, it cannot be found by conservative
2026            GC scan. It is OK for watchpoint since they are allocated in the heap anyway.
2027
2028         We applied this change to Watchpoint and get the following memory reduction. The highlight is that CodeBlockJettisoningWatchpoint in
2029         ARM64 only takes 2 pointers size.
2030
2031                                                                               ORIGINAL    X86_64   ARM64
2032             WatchpointSet:                                                    40          32       28
2033             CodeBlockJettisoningWatchpoint:                                   32          19       15
2034             StructureStubClearingWatchpoint:                                  56          48       40
2035             AdaptiveInferredPropertyValueWatchpointBase::StructureWatchpoint: 24          13       11
2036             AdaptiveInferredPropertyValueWatchpointBase::PropertyWatchpoint:  24          13       11
2037             FunctionRareData::AllocationProfileClearingWatchpoint:            32          19       15
2038             ObjectToStringAdaptiveStructureWatchpoint:                        56          48       40
2039             LLIntPrototypeLoadAdaptiveStructureWatchpoint:                    64          48       48
2040             DFG::AdaptiveStructureWatchpoint:                                 56          48       40
2041
2042         While we will re-architect the mechanism of Watchpoint, anyway Packed<> mechanism and enum types will be used too.
2043
2044         * CMakeLists.txt:
2045         * JavaScriptCore.xcodeproj/project.pbxproj:
2046         * Sources.txt:
2047         * bytecode/AdaptiveInferredPropertyValueWatchpointBase.h:
2048         * bytecode/CodeBlockJettisoningWatchpoint.h:
2049         * bytecode/CodeOrigin.h:
2050         * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
2051         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
2052         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
2053         * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
2054         * bytecode/StructureStubClearingWatchpoint.cpp:
2055         (JSC::StructureStubClearingWatchpoint::fireInternal):
2056         * bytecode/StructureStubClearingWatchpoint.h:
2057         * bytecode/Watchpoint.cpp:
2058         (JSC::Watchpoint::fire):
2059         * bytecode/Watchpoint.h:
2060         (JSC::Watchpoint::Watchpoint):
2061         * dfg/DFGAdaptiveStructureWatchpoint.cpp:
2062         (JSC::DFG::AdaptiveStructureWatchpoint::AdaptiveStructureWatchpoint):
2063         * dfg/DFGAdaptiveStructureWatchpoint.h:
2064         * heap/PackedCellPtr.h: Added.
2065         * runtime/FunctionRareData.h:
2066         * runtime/ObjectToStringAdaptiveStructureWatchpoint.cpp: Added.
2067         (JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint):
2068         (JSC::ObjectToStringAdaptiveStructureWatchpoint::install):
2069         (JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal):
2070         * runtime/ObjectToStringAdaptiveStructureWatchpoint.h: Added.
2071         * runtime/StructureRareData.cpp:
2072         (JSC::StructureRareData::clearObjectToStringValue):
2073         (JSC::ObjectToStringAdaptiveStructureWatchpoint::ObjectToStringAdaptiveStructureWatchpoint): Deleted.
2074         (JSC::ObjectToStringAdaptiveStructureWatchpoint::install): Deleted.
2075         (JSC::ObjectToStringAdaptiveStructureWatchpoint::fireInternal): Deleted.
2076         * runtime/StructureRareData.h:
2077
2078 2019-05-12  Yusuke Suzuki  <ysuzuki@apple.com>
2079
2080         [JSC] Compact generator code's bytecode size
2081         https://bugs.webkit.org/show_bug.cgi?id=197822
2082
2083         Reviewed by Michael Saboff.
2084
2085         op_put_to_scope's symbolTableOrScopeDepth is represented as int. This was OK for the old bytecode format since
2086         VirtualRegister / scope depth can be represented by int anyway. But it is problematic now since only int8_t range
2087         will be represented in narrow bytecode. When this field is used for symbol table constant index, it is always
2088         larger than FirstConstantRegisterIndex. So it always exceeds the range of int8_t, and results in wide bytecode.
2089         It makes all generator's op_put_to_scope wide bytecode.
2090
2091         In this patch, we introduce a new (logically) union type SymbolTableOrScopeDepth. It holds unsigned value, and we store the
2092         SymbolTableConstantIndex - FirstConstantRegisterIndex in this unsigned value to make op_put_to_scope narrow bytecode.
2093
2094         * CMakeLists.txt:
2095         * JavaScriptCore.xcodeproj/project.pbxproj:
2096         * bytecode/BytecodeGeneratorification.cpp:
2097         (JSC::BytecodeGeneratorification::run):
2098         * bytecode/BytecodeList.rb:
2099         * bytecode/CodeBlock.cpp:
2100         (JSC::CodeBlock::finishCreation):
2101         * bytecode/Fits.h:
2102         * bytecompiler/BytecodeGenerator.cpp:
2103         (JSC::BytecodeGenerator::BytecodeGenerator):
2104         (JSC::BytecodeGenerator::emitProfileType):
2105         (JSC::BytecodeGenerator::emitPutToScope):
2106         (JSC::BytecodeGenerator::localScopeDepth const):
2107         * bytecompiler/BytecodeGenerator.h:
2108         * runtime/SymbolTableOrScopeDepth.h: Added.
2109         (JSC::SymbolTableOrScopeDepth::symbolTable):
2110         (JSC::SymbolTableOrScopeDepth::scopeDepth):
2111         (JSC::SymbolTableOrScopeDepth::raw):
2112         (JSC::SymbolTableOrScopeDepth::symbolTable const):
2113         (JSC::SymbolTableOrScopeDepth::scopeDepth const):
2114         (JSC::SymbolTableOrScopeDepth::raw const):
2115         (JSC::SymbolTableOrScopeDepth::dump const):
2116         (JSC::SymbolTableOrScopeDepth::SymbolTableOrScopeDepth):
2117
2118 2019-05-10  Saam barati  <sbarati@apple.com>
2119
2120         Call to JSToWasmICCallee::createStructure passes in wrong prototype value
2121         https://bugs.webkit.org/show_bug.cgi?id=197807
2122         <rdar://problem/50530400>
2123
2124         Reviewed by Yusuke Suzuki.
2125
2126         We were passing the empty value instead of null. However, the empty
2127         value means the Structure is poly proto. That's definitely not the case
2128         here.
2129
2130         * runtime/JSGlobalObject.cpp:
2131         (JSC::JSGlobalObject::init):
2132
2133 2019-05-10  Yusuke Suzuki  <ysuzuki@apple.com>
2134
2135         [JSC] String substring operation should return ropes consistently
2136         https://bugs.webkit.org/show_bug.cgi?id=197765
2137         <rdar://problem/37689944>
2138
2139         Reviewed by Michael Saboff.
2140
2141         Currently we have different policies per string substring operation function.
2142
2143             1. String#slice returns the resolved non-rope string
2144             2. String#substring returns rope string
2145             3. String#substr returns rope string in runtime function, non-rope string in DFG and FTL
2146
2147         Due to (3), we see large memory use in the tested web page[1]. Non rope substring have a problem.
2148         First of all, that returned string seems not used immediately. It is possible that the resulted
2149         string is used as a part of the other ropes (like, xxx.substring(...) + "Hello"). To avoid the
2150         eager materialization of the string, we are using StringImpl::createSubstringSharingImpl for the
2151         resulted non rope string. StringImpl::createSubstringSharingImpl is StringImpl's substring feature: the
2152         substring is pointing the owner StringImpl. While this has memory saving benefit, it can retain owner
2153         StringImpl so long, and it could keep very large owner StringImpl alive.
2154
2155         The problem we are attempting to solve with StringImpl::createSubstringSharingImpl can be solved by
2156         the rope string simply. Rope string can share the underlying string. And good feature of the rope
2157         string is that, when resolving rope string, the rope string always create a new StringImpl instead of
2158         using StringImpl::createSubstringSharingImpl. So we allow the owner StringImpl to be destroyed. And this
2159         resolving only happens when we actually want to use the content of the rope string. In addition, we recently
2160         shrunk the sizeof(JSRopeString) from 48 to 32, so JSRopeString is cheap.
2161
2162         In this patch, we change (2) and (3) to (1), using rope String as a result of substring operations.
2163
2164         RAMification and JetStream2 are neutral. The web page[1] shows large memory footprint improvement from 776MB to 681MB.
2165
2166         [1]: https://beta.observablehq.com/@ldgardner/assignment-4-visualizations-and-multiple-views
2167
2168         * dfg/DFGOperations.cpp:
2169         * runtime/StringPrototype.cpp:
2170         (JSC::stringProtoFuncSlice):
2171         * runtime/StringPrototypeInlines.h:
2172         (JSC::stringSlice):
2173
2174 2019-05-10  Robin Morisset  <rmorisset@apple.com>
2175
2176         testb3 failing with crash in JSC::B3::BasicBlock::appendNonTerminal
2177         https://bugs.webkit.org/show_bug.cgi?id=197756
2178         <rdar://problem/50641659>
2179
2180         Reviewed by Saam Barati.
2181
2182         When I added https://bugs.webkit.org/show_bug.cgi?id=197265 I assumed that which block is the root does not change in the middle of strength reduction.
2183         But specializeSelect can use splitForward, which uses a new block for the first half of the given block.
2184         So if the block being split is the root block I must update m_root and erase the m_valueInConstant cache.
2185         Erasing the cache cannot cause wrong results: at most it can make us miss some optimization opportunities in this iteration of the fixpoint.
2186
2187         * b3/B3ReduceStrength.cpp:
2188
2189 2019-05-09  Keith Miller  <keith_miller@apple.com>
2190
2191         Fix crashes related to pointer authentication for primitive gigacage
2192         https://bugs.webkit.org/show_bug.cgi?id=197763
2193         <rdar://problem/50629257>
2194
2195         Reviewed by Saam Barati.
2196
2197         This fixes two bugs related to PAC for caging. The first is that
2198         we didn't clear the high bits of the size register going into the
2199         patchpoint to tag the new buffer for NewArrayBuffer. The second is
2200         that the GC needs to strip all stack pointers when considering
2201         them as a conservative root.
2202
2203         * ftl/FTLLowerDFGToB3.cpp:
2204         (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
2205         * heap/ConservativeRoots.cpp:
2206         (JSC::ConservativeRoots::genericAddPointer):
2207
2208 2019-05-09  Keith Miller  <keith_miller@apple.com>
2209
2210         parseStatementListItem needs a stack overflow check
2211         https://bugs.webkit.org/show_bug.cgi?id=197749
2212         <rdar://problem/50302697>
2213
2214         Reviewed by Saam Barati.
2215
2216         There currently exists a path in the parser where you can loop
2217         arbibrarily many times without a stack overflow check. This patch
2218         adds a check to parseStatementListItem to break that cycle.
2219
2220         * parser/Parser.cpp:
2221         (JSC::Parser<LexerType>::parseStatementListItem):
2222
2223 2019-05-09  Keith Miller  <keith_miller@apple.com>
2224
2225         REGRESSION (r245064): ASSERTION FAILED: m_ptr seen with wasm.yaml/wasm/js-api/test_Data.js.wasm-slow-memory
2226         https://bugs.webkit.org/show_bug.cgi?id=197740
2227
2228         Reviewed by Saam Barati.
2229
2230         If a TypedArray constructor is called with just 0 as the first argument, we don't allocate a backing vector.
2231         This means we need to handle null when calling vector() in ConstructionContext.
2232
2233         * runtime/JSArrayBufferView.h:
2234         (JSC::JSArrayBufferView::ConstructionContext::vector const):
2235
2236 2019-05-09  Xan López  <xan@igalia.com>
2237
2238         [CMake] Detect SSE2 at compile time
2239         https://bugs.webkit.org/show_bug.cgi?id=196488
2240
2241         Reviewed by Carlos Garcia Campos.
2242
2243         * assembler/MacroAssemblerX86Common.cpp: Remove unnecessary (and
2244         incorrect) static_assert.
2245         (JSC::MacroAssemblerX86Common::collectCPUFeatures):
2246         * assembler/MacroAssemblerX86Common.h: Remove SSE2 flags.
2247
2248 2019-05-08  Yusuke Suzuki  <ysuzuki@apple.com>
2249
2250         Unreviewed, build fix after r245064
2251         https://bugs.webkit.org/show_bug.cgi?id=197110
2252
2253         * runtime/GenericTypedArrayView.h:
2254
2255 2019-05-08  Saam barati  <sbarati@apple.com>
2256
2257         AccessGenerationState::emitExplicitExceptionHandler can clobber an in use register
2258         https://bugs.webkit.org/show_bug.cgi?id=197715
2259         <rdar://problem/50399252>
2260
2261         Reviewed by Filip Pizlo.
2262
2263         AccessGenerationState::emitExplicitExceptionHandler was always clobbering
2264         x86's r9 without considering if that register was needed to be preserved
2265         by the IC. This leads to bad things when the DFG/FTL need that register when
2266         OSR exitting after an exception from a GetById call.
2267
2268         * b3/air/AirCode.cpp:
2269         (JSC::B3::Air::Code::Code):
2270         * bytecode/PolymorphicAccess.cpp:
2271         (JSC::AccessGenerationState::emitExplicitExceptionHandler):
2272         * runtime/Options.h:
2273
2274 2019-05-08  Ryan Haddad  <ryanhaddad@apple.com>
2275
2276         Unreviewed, rolling out r245068.
2277
2278         Caused debug layout tests to exit early due to an assertion
2279         failure.
2280
2281         Reverted changeset:
2282
2283         "All prototypes should call didBecomePrototype()"
2284         https://bugs.webkit.org/show_bug.cgi?id=196315
2285         https://trac.webkit.org/changeset/245068
2286
2287 2019-05-08  Yusuke Suzuki  <ysuzuki@apple.com>
2288
2289         Invalid DFG JIT genereation in high CPU usage state
2290         https://bugs.webkit.org/show_bug.cgi?id=197453
2291
2292         Reviewed by Saam Barati.
2293
2294         We have a DFG graph like this.
2295
2296             a: JSConstant(rope JSString)
2297             b: CheckStringIdent(Check:StringUse:@a)
2298             ... AI think this is unreachable ...
2299
2300         When executing StringUse edge filter onto @a, AbstractValue::filterValueByType clears AbstractValue and makes it None.
2301         This is because @a constant produces SpecString (SpecStringVar | SpecStringIdent) while StringUse edge filter requires
2302         SpecStringIdent. AbstractValue::filterValueByType has an assumption that the JS constant always produces the same
2303         SpeculatedType. So it clears AbstractValue completely.
2304         But this assumption is wrong. JSString can produce SpecStringIdent later if the string is resolved to AtomicStringImpl.
2305         AI think that we always fail. But once the string is resolved to AtomicStringImpl, we pass this check. So we execute
2306         the breakpoint emitted by DFG since DFG think this is unreachable.
2307
2308         In this patch, we just clear the `m_value` if AbstractValue type filter fails with the held constant, since the constant
2309         may produce a narrower type which can meet the type filter later.
2310
2311         * dfg/DFGAbstractValue.cpp:
2312         (JSC::DFG::AbstractValue::filterValueByType):
2313
2314 2019-05-08  Robin Morisset  <rmorisset@apple.com>
2315
2316         All prototypes should call didBecomePrototype()
2317         https://bugs.webkit.org/show_bug.cgi?id=196315
2318
2319         Reviewed by Saam Barati.
2320
2321         This changelog already landed, but the commit was missing the actual changes.
2322
2323         Otherwise we won't remember to run haveABadTime() when someone adds to them an indexed accessor.
2324
2325         I added a check used in both Structure::finishCreation() and Structure::changePrototypeTransition to make sure we don't
2326         create structures with invalid prototypes.
2327         It found a lot of objects that are used as prototypes in JSGlobalObject and yet were missing didBecomePrototype() in their finishCreation().
2328         Somewhat surprisingly, some of them have names like FunctionConstructor and not only FooPrototype.
2329
2330         * runtime/BigIntPrototype.cpp:
2331         (JSC::BigIntPrototype::finishCreation):
2332         * runtime/BooleanPrototype.cpp:
2333         (JSC::BooleanPrototype::finishCreation):
2334         * runtime/DatePrototype.cpp:
2335         (JSC::DatePrototype::finishCreation):
2336         * runtime/ErrorConstructor.cpp:
2337         (JSC::ErrorConstructor::finishCreation):
2338         * runtime/ErrorPrototype.cpp:
2339         (JSC::ErrorPrototype::finishCreation):
2340         * runtime/FunctionConstructor.cpp:
2341         (JSC::FunctionConstructor::finishCreation):
2342         * runtime/FunctionPrototype.cpp:
2343         (JSC::FunctionPrototype::finishCreation):
2344         * runtime/IntlCollatorPrototype.cpp:
2345         (JSC::IntlCollatorPrototype::finishCreation):
2346         * runtime/IntlDateTimeFormatPrototype.cpp:
2347         (JSC::IntlDateTimeFormatPrototype::finishCreation):
2348         * runtime/IntlNumberFormatPrototype.cpp:
2349         (JSC::IntlNumberFormatPrototype::finishCreation):
2350         * runtime/IntlPluralRulesPrototype.cpp:
2351         (JSC::IntlPluralRulesPrototype::finishCreation):
2352         * runtime/JSArrayBufferPrototype.cpp:
2353         (JSC::JSArrayBufferPrototype::finishCreation):
2354         * runtime/JSDataViewPrototype.cpp:
2355         (JSC::JSDataViewPrototype::finishCreation):
2356         * runtime/JSGenericTypedArrayViewPrototypeInlines.h:
2357         (JSC::JSGenericTypedArrayViewPrototype<ViewClass>::finishCreation):
2358         * runtime/JSGlobalObject.cpp:
2359         (JSC::createConsoleProperty):
2360         * runtime/JSPromisePrototype.cpp:
2361         (JSC::JSPromisePrototype::finishCreation):
2362         * runtime/JSTypedArrayViewConstructor.cpp:
2363         (JSC::JSTypedArrayViewConstructor::finishCreation):
2364         * runtime/JSTypedArrayViewPrototype.cpp:
2365         (JSC::JSTypedArrayViewPrototype::finishCreation):
2366         * runtime/NumberPrototype.cpp:
2367         (JSC::NumberPrototype::finishCreation):
2368         * runtime/RegExpPrototype.cpp:
2369         (JSC::RegExpPrototype::finishCreation):
2370         * runtime/StringPrototype.cpp:
2371         (JSC::StringPrototype::finishCreation):
2372         * runtime/Structure.cpp:
2373         (JSC::Structure::isValidPrototype):
2374         (JSC::Structure::changePrototypeTransition):
2375         * runtime/Structure.h:
2376         * runtime/SymbolPrototype.cpp:
2377         (JSC::SymbolPrototype::finishCreation):
2378         * wasm/js/WebAssemblyCompileErrorPrototype.cpp:
2379         (JSC::WebAssemblyCompileErrorPrototype::finishCreation):
2380         * wasm/js/WebAssemblyInstancePrototype.cpp:
2381         (JSC::WebAssemblyInstancePrototype::finishCreation):
2382         * wasm/js/WebAssemblyLinkErrorPrototype.cpp:
2383         (JSC::WebAssemblyLinkErrorPrototype::finishCreation):
2384         * wasm/js/WebAssemblyMemoryPrototype.cpp:
2385         (JSC::WebAssemblyMemoryPrototype::finishCreation):
2386         * wasm/js/WebAssemblyModulePrototype.cpp:
2387         (JSC::WebAssemblyModulePrototype::finishCreation):
2388         * wasm/js/WebAssemblyPrototype.cpp:
2389         (JSC::WebAssemblyPrototype::finishCreation):
2390         * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp:
2391         (JSC::WebAssemblyRuntimeErrorPrototype::finishCreation):
2392         * wasm/js/WebAssemblyTablePrototype.cpp:
2393         (JSC::WebAssemblyTablePrototype::finishCreation):
2394
2395 2019-05-08  Keith Miller  <keith_miller@apple.com>
2396
2397         Remove Gigacage from arm64 and use PAC for arm64e instead
2398         https://bugs.webkit.org/show_bug.cgi?id=197110
2399
2400         Reviewed by Saam Barati.
2401
2402         This patch makes a bunch of changes. I'll start with global changes then go over changes to each tier and finish with bug fixes.
2403
2404         Global Changes:
2405         Change CagedBarrierPtr to work with PAC so constructors and accessors now expect to receive a length.
2406         Update assembler helper methods to use do PAC when caging.
2407
2408         LLInt:
2409         Add arm64e.rb backend as we missed that when originally open sourcing our arm64e code.
2410         Add a new optional t6 temporary, which is only used currently on arm64e for GetByVal on a TypedArray.
2411         Refactor caging into two helper macros for Primitive/JSValue cages.
2412
2413         Baseline/DFG:
2414         Add authentication where needed for GetByVal and inline object construction.
2415
2416         FTL:
2417         Add a new ValueRep that allows for a late register use. We want this for the authentication patchpoint since we use the length register at the same time as we are defing the authenticated pointer.
2418
2419         Wasm:
2420         Use the TaggedArrayStoragePtr class for the memory base pointer. In theory we should be caging those pointers but I don't want to risk introducing a performance regression with the rest of this change. I've filed https://bugs.webkit.org/show_bug.cgi?id=197620 to do this later.
2421         As we no longer have the Gigacage using most of our VA memory, we can enable fast memories on iOS.
2422         Using fast memories leads to roughly a 2% JetStream2 speedup.
2423
2424         * assembler/MacroAssemblerARM64E.h:
2425         (JSC::MacroAssemblerARM64E::tagArrayPtr):
2426         (JSC::MacroAssemblerARM64E::untagArrayPtr):
2427         (JSC::MacroAssemblerARM64E::removeArrayPtrTag):
2428         * b3/B3LowerToAir.cpp:
2429         * b3/B3PatchpointSpecial.cpp:
2430         (JSC::B3::PatchpointSpecial::admitsStack):
2431         * b3/B3StackmapSpecial.cpp:
2432         (JSC::B3::StackmapSpecial::forEachArgImpl):
2433         (JSC::B3::StackmapSpecial::isArgValidForRep):
2434         * b3/B3Validate.cpp:
2435         * b3/B3ValueRep.cpp:
2436         (JSC::B3::ValueRep::addUsedRegistersTo const):
2437         (JSC::B3::ValueRep::dump const):
2438         (WTF::printInternal):
2439         * b3/B3ValueRep.h:
2440         (JSC::B3::ValueRep::ValueRep):
2441         (JSC::B3::ValueRep::isReg const):
2442         * dfg/DFGOperations.cpp:
2443         (JSC::DFG::newTypedArrayWithSize):
2444         * dfg/DFGSpeculativeJIT.cpp:
2445         (JSC::DFG::SpeculativeJIT::jumpForTypedArrayIsNeuteredIfOutOfBounds):
2446         (JSC::DFG::SpeculativeJIT::cageTypedArrayStorage):
2447         (JSC::DFG::SpeculativeJIT::compileGetIndexedPropertyStorage):
2448         (JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
2449         (JSC::DFG::SpeculativeJIT::compileNewTypedArrayWithSize):
2450         * dfg/DFGSpeculativeJIT.h:
2451         * dfg/DFGSpeculativeJIT64.cpp:
2452         (JSC::DFG::SpeculativeJIT::compile):
2453         * ftl/FTLLowerDFGToB3.cpp:
2454         (JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage):
2455         (JSC::FTL::DFG::LowerDFGToB3::compileGetTypedArrayByteOffset):
2456         (JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
2457         (JSC::FTL::DFG::LowerDFGToB3::compileDataViewGet):
2458         (JSC::FTL::DFG::LowerDFGToB3::compileDataViewSet):
2459         (JSC::FTL::DFG::LowerDFGToB3::untagArrayPtr):
2460         (JSC::FTL::DFG::LowerDFGToB3::caged):
2461         (JSC::FTL::DFG::LowerDFGToB3::speculateTypedArrayIsNotNeutered):
2462         * jit/AssemblyHelpers.h:
2463         (JSC::AssemblyHelpers::cageConditionally):
2464         * jit/IntrinsicEmitter.cpp:
2465         (JSC::IntrinsicGetterAccessCase::emitIntrinsicGetter):
2466         * jit/JITPropertyAccess.cpp:
2467         (JSC::JIT::emitDirectArgumentsGetByVal):
2468         (JSC::JIT::emitIntTypedArrayGetByVal):
2469         (JSC::JIT::emitFloatTypedArrayGetByVal):
2470         (JSC::JIT::emitIntTypedArrayPutByVal):
2471         (JSC::JIT::emitFloatTypedArrayPutByVal):
2472         * jit/PolymorphicCallStubRoutine.cpp:
2473         (JSC::PolymorphicCallNode::clearCallLinkInfo):
2474         * llint/LowLevelInterpreter64.asm:
2475         * offlineasm/arm64.rb:
2476         * offlineasm/arm64e.rb: Added.
2477         * offlineasm/ast.rb:
2478         * offlineasm/instructions.rb:
2479         * offlineasm/registers.rb:
2480         * offlineasm/x86.rb:
2481         * runtime/ArrayBuffer.cpp:
2482         (JSC::SharedArrayBufferContents::SharedArrayBufferContents):
2483         (JSC::SharedArrayBufferContents::~SharedArrayBufferContents):
2484         (JSC::ArrayBufferContents::ArrayBufferContents):
2485         (JSC::ArrayBufferContents::destroy):
2486         (JSC::ArrayBufferContents::tryAllocate):
2487         (JSC::ArrayBufferContents::makeShared):
2488         (JSC::ArrayBufferContents::copyTo):
2489         * runtime/ArrayBuffer.h:
2490         (JSC::SharedArrayBufferContents::data const):
2491         (JSC::ArrayBufferContents::data const):
2492         (JSC::ArrayBuffer::data):
2493         (JSC::ArrayBuffer::data const):
2494         (JSC::ArrayBuffer::byteLength const):
2495         * runtime/ArrayBufferView.cpp:
2496         (JSC::ArrayBufferView::ArrayBufferView):
2497         * runtime/ArrayBufferView.h:
2498         (JSC::ArrayBufferView::baseAddress const):
2499         (JSC::ArrayBufferView::byteLength const):
2500         (JSC::ArrayBufferView::setRangeImpl):
2501         (JSC::ArrayBufferView::getRangeImpl):
2502         * runtime/CachedTypes.cpp:
2503         (JSC::CachedScopedArgumentsTable::encode):
2504         (JSC::CachedScopedArgumentsTable::decode const):
2505         * runtime/CagedBarrierPtr.h:
2506         (JSC::CagedBarrierPtr::CagedBarrierPtr):
2507         (JSC::CagedBarrierPtr::set):
2508         (JSC::CagedBarrierPtr::get const):
2509         (JSC::CagedBarrierPtr::getMayBeNull const):
2510         (JSC::CagedBarrierPtr::getUnsafe const):
2511         (JSC::CagedBarrierPtr::at const):
2512         (JSC::CagedBarrierPtr::operator== const):
2513         (JSC::CagedBarrierPtr::operator bool const):
2514         (JSC::CagedBarrierPtr::setWithoutBarrier):
2515         (JSC::CagedBarrierPtr::operator* const): Deleted.
2516         (JSC::CagedBarrierPtr::operator-> const): Deleted.
2517         (JSC::CagedBarrierPtr::operator[] const): Deleted.
2518         (): Deleted.
2519         * runtime/DataView.cpp:
2520         (JSC::DataView::DataView):
2521         * runtime/DataView.h:
2522         (JSC::DataView::get):
2523         (JSC::DataView::set):
2524         * runtime/DirectArguments.cpp:
2525         (JSC::DirectArguments::visitChildren):
2526         (JSC::DirectArguments::overrideThings):
2527         (JSC::DirectArguments::unmapArgument):
2528         * runtime/DirectArguments.h:
2529         * runtime/GenericArguments.h:
2530         * runtime/GenericArgumentsInlines.h:
2531         (JSC::GenericArguments<Type>::visitChildren):
2532         (JSC::GenericArguments<Type>::initModifiedArgumentsDescriptor):
2533         (JSC::GenericArguments<Type>::setModifiedArgumentDescriptor):
2534         (JSC::GenericArguments<Type>::isModifiedArgumentDescriptor):
2535         * runtime/GenericTypedArrayView.h:
2536         * runtime/GenericTypedArrayViewInlines.h:
2537         (JSC::GenericTypedArrayView<Adaptor>::GenericTypedArrayView):
2538         * runtime/JSArrayBufferView.cpp:
2539         (JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):
2540         (JSC::JSArrayBufferView::JSArrayBufferView):
2541         (JSC::JSArrayBufferView::finalize):
2542         (JSC::JSArrayBufferView::slowDownAndWasteMemory):
2543         * runtime/JSArrayBufferView.h:
2544         (JSC::JSArrayBufferView::ConstructionContext::vector const):
2545         (JSC::JSArrayBufferView::isNeutered):
2546         (JSC::JSArrayBufferView::hasVector const):
2547         (JSC::JSArrayBufferView::vector const):
2548         * runtime/JSGenericTypedArrayViewInlines.h:
2549         (JSC::JSGenericTypedArrayView<Adaptor>::createUninitialized):
2550         (JSC::JSGenericTypedArrayView<Adaptor>::estimatedSize):
2551         (JSC::JSGenericTypedArrayView<Adaptor>::visitChildren):
2552         * runtime/Options.h:
2553         * runtime/ScopedArgumentsTable.cpp:
2554         (JSC::ScopedArgumentsTable::clone):
2555         (JSC::ScopedArgumentsTable::setLength):
2556         * runtime/ScopedArgumentsTable.h:
2557         * runtime/SymbolTable.h:
2558         * wasm/WasmAirIRGenerator.cpp:
2559         (JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState):
2560         (JSC::Wasm::AirIRGenerator::addCallIndirect):
2561         * wasm/WasmB3IRGenerator.cpp:
2562         (JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
2563         (JSC::Wasm::B3IRGenerator::addCallIndirect):
2564         * wasm/WasmBBQPlan.cpp:
2565         (JSC::Wasm::BBQPlan::complete):
2566         * wasm/WasmBinding.cpp:
2567         (JSC::Wasm::wasmToWasm):
2568         * wasm/WasmInstance.h:
2569         (JSC::Wasm::Instance::cachedMemory const):
2570         (JSC::Wasm::Instance::updateCachedMemory):
2571         * wasm/WasmMemory.cpp:
2572         (JSC::Wasm::Memory::Memory):
2573         (JSC::Wasm::Memory::~Memory):
2574         (JSC::Wasm::Memory::grow):
2575         (JSC::Wasm::Memory::dump const):
2576         * wasm/WasmMemory.h:
2577         (JSC::Wasm::Memory::memory const):
2578         * wasm/js/JSToWasm.cpp:
2579         (JSC::Wasm::createJSToWasmWrapper):
2580         * wasm/js/WebAssemblyFunction.cpp:
2581         (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
2582
2583 2019-05-08  Caio Lima  <ticaiolima@gmail.com>
2584
2585         [BigInt] Add ValueMod into DFG
2586         https://bugs.webkit.org/show_bug.cgi?id=186174
2587
2588         Reviewed by Saam Barati.
2589
2590         This patch is introducing a new DFG node called ValueMod, that is
2591         responsible to handle BigInt and Untyped specialization of op_mod.
2592         With the introduction of BigInt, we think that cases with
2593         ValueMod(Untyped, Untyped) can be more common and we introduced
2594         support for such kind of node.
2595
2596         * dfg/DFGAbstractInterpreter.h:
2597         * dfg/DFGAbstractInterpreterInlines.h:
2598         (JSC::DFG::AbstractInterpreter<AbstractStateType>::handleConstantDivOp):
2599
2600         We are abstracting the constant rules of division operations. It
2601         includes ArithDiv, ValueDiv, ArithMod and ValueMod, since they perform
2602         the same analysis.
2603
2604         (JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2605         * dfg/DFGBackwardsPropagationPhase.cpp:
2606         (JSC::DFG::BackwardsPropagationPhase::propagate):
2607         * dfg/DFGByteCodeParser.cpp:
2608         (JSC::DFG::ByteCodeParser::makeSafe):
2609         (JSC::DFG::ByteCodeParser::parseBlock):
2610
2611         Here we check if lhs and rhs have number result to emit ArithMod.
2612         Otherwise, we need to fallback to ValueMod and let fixup replace this
2613         operation when possible.
2614
2615         * dfg/DFGClobberize.h:
2616         (JSC::DFG::clobberize):
2617
2618         ValueMod(BigIntUse) doesn't clobberize world because it only calls
2619         `operationModBigInt`.
2620
2621         * dfg/DFGDoesGC.cpp:
2622         (JSC::DFG::doesGC):
2623
2624         ValueMod(BigIntUse) can trigger GC since it allocates intermediate
2625         JSBigInt to perform calculation. ValueMod(UntypedUse) can trigger GC
2626         because it can execute arbritary code from user.
2627
2628         * dfg/DFGFixupPhase.cpp:
2629         (JSC::DFG::FixupPhase::fixupArithDivInt32):
2630
2631         Function created to simplify readability of ArithDiv/AirthMod fixup
2632         operation.
2633
2634         (JSC::DFG::FixupPhase::fixupArithDiv):
2635         (JSC::DFG::FixupPhase::fixupNode):
2636
2637         Following the same fixup rules of ArithDiv.
2638
2639         * dfg/DFGNodeType.h:
2640         * dfg/DFGOperations.cpp:
2641         (JSC::DFG::binaryOp):
2642         * dfg/DFGOperations.h:
2643         * dfg/DFGPredictionPropagationPhase.cpp:
2644
2645         ValueMod follows the same prediction propagation rules of ArithMod and
2646         the same rules for `doDoubleVoting`.
2647
2648         * dfg/DFGSafeToExecute.h:
2649         (JSC::DFG::safeToExecute):
2650         * dfg/DFGSpeculativeJIT.cpp:
2651         (JSC::DFG::SpeculativeJIT::compileValueMod):
2652         * dfg/DFGSpeculativeJIT.h:
2653         * dfg/DFGSpeculativeJIT32_64.cpp:
2654         (JSC::DFG::SpeculativeJIT::compile):
2655         * dfg/DFGSpeculativeJIT64.cpp:
2656         (JSC::DFG::SpeculativeJIT::compile):
2657         * dfg/DFGValidate.cpp:
2658         * ftl/FTLCapabilities.cpp:
2659         (JSC::FTL::canCompile):
2660         * ftl/FTLLowerDFGToB3.cpp:
2661         (JSC::FTL::DFG::LowerDFGToB3::compileNode):
2662         (JSC::FTL::DFG::LowerDFGToB3::compileValueMod):
2663
2664 2019-05-07  Yusuke Suzuki  <ysuzuki@apple.com>
2665
2666         [JSC] DFG_ASSERT failed in lowInt52
2667         https://bugs.webkit.org/show_bug.cgi?id=197569
2668
2669         Reviewed by Saam Barati.
2670
2671         GetStack with FlushedInt52 should load the flushed value in Int52 form and put the result in m_int52Values / m_strictInt52Values. Previously,
2672         we load it in JSValue / Int32 form and lowInt52 fails to get appropriate one since GetStack does not put the result in m_int52Values / m_strictInt52Values.
2673
2674         * ftl/FTLLowerDFGToB3.cpp:
2675         (JSC::FTL::DFG::LowerDFGToB3::compileGetStack):
2676
2677 2019-05-07  Yusuke Suzuki  <ysuzuki@apple.com>
2678
2679         [JSC] LLIntPrototypeLoadAdaptiveStructureWatchpoint does not require Bag<>
2680         https://bugs.webkit.org/show_bug.cgi?id=197645
2681
2682         Reviewed by Saam Barati.
2683
2684         We are using HashMap<std::tuple<Structure*, const Instruction*>, Bag<LLIntPrototypeLoadAdaptiveStructureWatchpoint>> for LLIntPrototypeLoadAdaptiveStructureWatchpoint,
2685         but this has several memory inefficiency.
2686
2687         1. Structure* and Instruction* are too large. We can just use StructureID and bytecodeOffset (unsigned).
2688         2. While we are using Bag<>, we do not add a new LLIntPrototypeLoadAdaptiveStructureWatchpoint after constructing this Bag first. So we can
2689            use Vector<LLIntPrototypeLoadAdaptiveStructureWatchpoint> instead. We ensure that new entry won't be added to this Vector by making Watchpoint
2690            non-movable.
2691         3. Instead of having OpGetById::Metadata&, we just hold `unsigned` bytecodeOffset, and get Metadata& from the owner CodeBlock when needed.
2692
2693         * bytecode/CodeBlock.cpp:
2694         (JSC::CodeBlock::finalizeLLIntInlineCaches):
2695         * bytecode/CodeBlock.h:
2696         * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
2697         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
2698         (JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
2699         * bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
2700         * bytecode/Watchpoint.h:
2701         * llint/LLIntSlowPaths.cpp:
2702         (JSC::LLInt::setupGetByIdPrototypeCache):
2703
2704 2019-05-07  Yusuke Suzuki  <ysuzuki@apple.com>
2705
2706         JSC: A bug in BytecodeGenerator::emitEqualityOpImpl
2707         https://bugs.webkit.org/show_bug.cgi?id=197479
2708
2709         Reviewed by Saam Barati.
2710
2711         Our peephole optimization in BytecodeGenerator is (1) rewinding the previous instruction and (2) emit optimized instruction instead.
2712         If we have jump target between the previous instruction and the subsequent instruction, this peephole optimization breaks the jump target.
2713         To prevent it, we had a mechanism disabling peephole optimization, setting m_lastOpcodeID = op_end and checking m_lastOpcodeID when performing
2714         peephole optimization. However, BytecodeGenerator::emitEqualityOpImpl checks `m_lastInstruction->is<OpTypeof>` instead of `m_lastOpcodeID == op_typeof`,
2715         and miss `op_end` case.
2716
2717         This patch makes the following changes.
2718
2719         1. Add canDoPeepholeOptimization method to clarify the intent of `m_lastInstruction = op_end`.
2720         2. Check canDoPeepholeOptimization status before performing peephole optimization in emitJumpIfTrue, emitJumpIfFalse, and emitEqualityOpImpl.
2721         3. Add `ASSERT(canDoPeepholeOptimization())` in fuseCompareAndJump and fuseTestAndJmp to ensure that peephole optimization is allowed.
2722
2723         * bytecompiler/BytecodeGenerator.cpp:
2724         (JSC::BytecodeGenerator::fuseCompareAndJump):
2725         (JSC::BytecodeGenerator::fuseTestAndJmp):
2726         (JSC::BytecodeGenerator::emitJumpIfTrue):
2727         (JSC::BytecodeGenerator::emitJumpIfFalse):
2728         (JSC::BytecodeGenerator::emitEqualityOpImpl):
2729         * bytecompiler/BytecodeGenerator.h:
2730         (JSC::BytecodeGenerator::canDoPeepholeOptimization const):
2731
2732 2019-05-07  Yusuke Suzuki  <ysuzuki@apple.com>
2733
2734         TemplateObject passed to template literal tags are not always identical for the same source location.
2735         https://bugs.webkit.org/show_bug.cgi?id=190756
2736
2737         Reviewed by Saam Barati.
2738
2739         Tagged template literal requires that the site object is allocated per source location. Previously, we create the site object
2740         when linking CodeBlock and cache it in CodeBlock. But this is wrong because,
2741
2742         1. CodeBlock can be jettisoned and regenerated. So every time CodeBlock is regenerated, we get the different site object.
2743         2. Call and Construct can have different CodeBlock. Even if the function is called in call-form or construct-form, we should return the same site object.
2744
2745         In this patch, we start caching these site objects in the top-level ScriptExecutable, this matches the spec's per source location since the only one top-level
2746         ScriptExecutable is created for the given script code. Each ScriptExecutable of JSFunction can be created multiple times because CodeBlock creates it.
2747         But the top-level one is not created by CodeBlock. This top-level ScriptExecutable is well-aligned to the Script itself. The top-level ScriptExecutable now has HashMap,
2748         which maps source locations to cached site objects.
2749
2750         1. This patch threads the top-level ScriptExecutable to each FunctionExecutable creation. Each FunctionExecutable has a reference to the top-level ScriptExecutable.
2751         2. We put TemplateObjectMap in ScriptExecutable, which manages cached template objects.
2752         3. We move FunctionExecutable::m_cachedPolyProtoStructure to the FunctionExecutable::RareDate to keep FunctionExecutable 128 bytes.
2753         4. TemplateObjectMap is indexed with endOffset of TaggedTemplate.
2754
2755         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
2756         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
2757         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
2758         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
2759         * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
2760         * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
2761         * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
2762         * Scripts/tests/builtins/expected/WebCore-AnotherGuardedInternalBuiltin-Separate.js-result:
2763         * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
2764         * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
2765         * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
2766         * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
2767         * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
2768         * Scripts/wkbuiltins/builtins_templates.py:
2769         * bytecode/CodeBlock.cpp:
2770         (JSC::CodeBlock::finishCreation):
2771         (JSC::CodeBlock::setConstantRegisters):
2772         * bytecode/CodeBlock.h:
2773         * bytecode/UnlinkedFunctionExecutable.cpp:
2774         (JSC::UnlinkedFunctionExecutable::link):
2775         * bytecode/UnlinkedFunctionExecutable.h:
2776         * bytecompiler/BytecodeGenerator.cpp:
2777         (JSC::BytecodeGenerator::addTemplateObjectConstant):
2778         (JSC::BytecodeGenerator::emitGetTemplateObject):
2779         * bytecompiler/BytecodeGenerator.h:
2780         * parser/ASTBuilder.h:
2781         (JSC::ASTBuilder::createTaggedTemplate):
2782         * runtime/CachedTypes.cpp:
2783         (JSC::CachedTemplateObjectDescriptor::encode):
2784         (JSC::CachedTemplateObjectDescriptor::decode const):
2785         (JSC::CachedJSValue::encode):
2786         (JSC::CachedJSValue::decode const):
2787         * runtime/EvalExecutable.cpp:
2788         (JSC::EvalExecutable::ensureTemplateObjectMap):
2789         (JSC::EvalExecutable::visitChildren):
2790         * runtime/EvalExecutable.h:
2791         * runtime/FunctionExecutable.cpp:
2792         (JSC::FunctionExecutable::finishCreation):
2793         (JSC::FunctionExecutable::visitChildren):
2794         (JSC::FunctionExecutable::fromGlobalCode):
2795         (JSC::FunctionExecutable::ensureRareDataSlow):
2796         (JSC::FunctionExecutable::ensureTemplateObjectMap):
2797         * runtime/FunctionExecutable.h:
2798         * runtime/JSModuleRecord.cpp:
2799         (JSC::JSModuleRecord::instantiateDeclarations):
2800         * runtime/JSTemplateObjectDescriptor.cpp:
2801         (JSC::JSTemplateObjectDescriptor::JSTemplateObjectDescriptor):
2802         (JSC::JSTemplateObjectDescriptor::create):
2803         * runtime/JSTemplateObjectDescriptor.h:
2804         * runtime/ModuleProgramExecutable.cpp:
2805         (JSC::ModuleProgramExecutable::ensureTemplateObjectMap):
2806         (JSC::ModuleProgramExecutable::visitChildren):
2807         * runtime/ModuleProgramExecutable.h:
2808         * runtime/ProgramExecutable.cpp:
2809         (JSC::ProgramExecutable::ensureTemplateObjectMap):
2810         (JSC::ProgramExecutable::visitChildren):
2811         * runtime/ProgramExecutable.h:
2812         * runtime/ScriptExecutable.cpp:
2813         (JSC::ScriptExecutable::topLevelExecutable):
2814         (JSC::ScriptExecutable::createTemplateObject):
2815         (JSC::ScriptExecutable::ensureTemplateObjectMapImpl):
2816         (JSC::ScriptExecutable::ensureTemplateObjectMap):
2817         * runtime/ScriptExecutable.h:
2818         * tools/JSDollarVM.cpp:
2819         (JSC::functionCreateBuiltin):
2820         (JSC::functionDeleteAllCodeWhenIdle):
2821         (JSC::JSDollarVM::finishCreation):
2822
2823 2019-05-07  Robin Morisset  <rmorisset@apple.com>
2824
2825         [B3] Constants should be hoisted to the root block until moveConstants
2826         https://bugs.webkit.org/show_bug.cgi?id=197265
2827
2828         Reviewed by Saam Barati.
2829
2830         This patch does the following:
2831         - B3ReduceStrength now hoists all constants to the root BB, and de-duplicates them along the way
2832         - B3PureCSE no longer bothers with constants, since they are already de-duplicated by the time it gets to see them
2833         - We now run eliminateDeadCode just after moveConstants, so that the Nops that moveConstants generates are freed instead of staying live throughout Air compilation, reducing memory pressure.
2834         - I also took the opportunity to fix typos in comments in various parts of the code base.
2835
2836         Here are a few numbers to justify this patch:
2837         - In JetStream2, about 27% of values at the beginning of B3 are constants
2838         - In JetStream2, about 11% of values at the end of B3 are Nops
2839         - In JetStream2, this patch increases the number of times that tail duplication happens from a bit less than 24k to a bit more than 25k (hoisting constants makes blocks smaller).
2840
2841         When I tried measuring the total effect on JetStream2 I got a tiny and almost certainly non-significant progression.
2842
2843         * b3/B3Generate.cpp:
2844         (JSC::B3::generateToAir):
2845         * b3/B3MoveConstants.cpp:
2846         * b3/B3PureCSE.cpp:
2847         (JSC::B3::PureCSE::process):
2848         * b3/B3PureCSE.h:
2849         * b3/B3ReduceStrength.cpp:
2850         * bytecode/GetByIdStatus.cpp:
2851         (JSC::GetByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
2852         * dfg/DFGCSEPhase.cpp:
2853         * dfg/DFGOSRAvailabilityAnalysisPhase.h:
2854         * dfg/DFGOSRExit.cpp:
2855         (JSC::DFG::OSRExit::executeOSRExit):
2856
2857 2019-05-07  Robin Morisset  <rmorisset@apple.com>
2858
2859         All prototypes should call didBecomePrototype()
2860         https://bugs.webkit.org/show_bug.cgi?id=196315
2861
2862         Reviewed by Saam Barati.
2863
2864         Otherwise we won't remember to run haveABadTime() when someone adds to them an indexed accessor.
2865
2866         I added a check used in both Structure::finishCreation() and Structure::changePrototypeTransition to make sure we don't
2867         create structures with invalid prototypes.
2868         It found a lot of objects that are used as prototypes in JSGlobalObject and yet were missing didBecomePrototype() in their finishCreation().
2869         Somewhat surprisingly, some of them have names like FunctionConstructor and not only FooPrototype.
2870
2871         * runtime/BigIntPrototype.cpp:
2872         (JSC::BigIntPrototype::finishCreation):
2873         * runtime/BooleanPrototype.cpp:
2874         (JSC::BooleanPrototype::finishCreation):
2875         * runtime/DatePrototype.cpp:
2876         (JSC::DatePrototype::finishCreation):
2877         * runtime/ErrorConstructor.cpp:
2878         (JSC::ErrorConstructor::finishCreation):
2879         * runtime/ErrorPrototype.cpp:
2880         (JSC::ErrorPrototype::finishCreation):
2881         * runtime/FunctionConstructor.cpp:
2882         (JSC::FunctionConstructor::finishCreation):
2883         * runtime/FunctionPrototype.cpp:
2884         (JSC::FunctionPrototype::finishCreation):
2885         * runtime/IntlCollatorPrototype.cpp:
2886         (JSC::IntlCollatorPrototype::finishCreation):
2887         * runtime/IntlDateTimeFormatPrototype.cpp:
2888         (JSC::IntlDateTimeFormatPrototype::finishCreation):
2889         * runtime/IntlNumberFormatPrototype.cpp:
2890         (JSC::IntlNumberFormatPrototype::finishCreation):
2891         * runtime/IntlPluralRulesPrototype.cpp:
2892         (JSC::IntlPluralRulesPrototype::finishCreation):
2893         * runtime/JSArrayBufferPrototype.cpp:
2894         (JSC::JSArrayBufferPrototype::finishCreation):
2895         * runtime/JSDataViewPrototype.cpp:
2896         (JSC::JSDataViewPrototype::finishCreation):
2897         * runtime/JSGenericTypedArrayViewPrototypeInlines.h:
2898         (JSC::JSGenericTypedArrayViewPrototype<ViewClass>::finishCreation):
2899         * runtime/JSGlobalObject.cpp:
2900         (JSC::createConsoleProperty):
2901         * runtime/JSPromisePrototype.cpp:
2902         (JSC::JSPromisePrototype::finishCreation):
2903         * runtime/JSTypedArrayViewConstructor.cpp:
2904         (JSC::JSTypedArrayViewConstructor::finishCreation):
2905         * runtime/JSTypedArrayViewPrototype.cpp:
2906         (JSC::JSTypedArrayViewPrototype::finishCreation):
2907         * runtime/NumberPrototype.cpp:
2908         (JSC::NumberPrototype::finishCreation):
2909         * runtime/RegExpPrototype.cpp:
2910         (JSC::RegExpPrototype::finishCreation):
2911         * runtime/StringPrototype.cpp:
2912         (JSC::StringPrototype::finishCreation):
2913         * runtime/Structure.cpp:
2914         (JSC::Structure::isValidPrototype):
2915         (JSC::Structure::changePrototypeTransition):
2916         * runtime/Structure.h:
2917         * runtime/SymbolPrototype.cpp:
2918         (JSC::SymbolPrototype::finishCreation):
2919         * wasm/js/WebAssemblyCompileErrorPrototype.cpp:
2920         (JSC::WebAssemblyCompileErrorPrototype::finishCreation):
2921         * wasm/js/WebAssemblyInstancePrototype.cpp:
2922         (JSC::WebAssemblyInstancePrototype::finishCreation):
2923         * wasm/js/WebAssemblyLinkErrorPrototype.cpp:
2924         (JSC::WebAssemblyLinkErrorPrototype::finishCreation):
2925         * wasm/js/WebAssemblyMemoryPrototype.cpp:
2926         (JSC::WebAssemblyMemoryPrototype::finishCreation):
2927         * wasm/js/WebAssemblyModulePrototype.cpp:
2928         (JSC::WebAssemblyModulePrototype::finishCreation):
2929         * wasm/js/WebAssemblyPrototype.cpp:
2930         (JSC::WebAssemblyPrototype::finishCreation):
2931         * wasm/js/WebAssemblyRuntimeErrorPrototype.cpp:
2932         (JSC::WebAssemblyRuntimeErrorPrototype::finishCreation):
2933         * wasm/js/WebAssemblyTablePrototype.cpp:
2934         (JSC::WebAssemblyTablePrototype::finishCreation):
2935
2936 2019-05-07  Robin Morisset  <rmorisset@apple.com>
2937
2938         WTF::BitVector should have an isEmpty() method
2939         https://bugs.webkit.org/show_bug.cgi?id=197637
2940
2941         Reviewed by Keith Miller.
2942
2943         Just replaces some comparison of bitCount() to 0 by calls to isEmpty()
2944
2945         * b3/air/AirAllocateRegistersByGraphColoring.cpp:
2946
2947 2019-05-07  Commit Queue  <commit-queue@webkit.org>
2948
2949         Unreviewed, rolling out r244978.
2950         https://bugs.webkit.org/show_bug.cgi?id=197671
2951
2952         TemplateObject map should use start/end offsets (Requested by
2953         yusukesuzuki on #webkit).
2954
2955         Reverted changeset:
2956
2957         "TemplateObject passed to template literal tags are not always
2958         identical for the same source location."
2959         https://bugs.webkit.org/show_bug.cgi?id=190756
2960         https://trac.webkit.org/changeset/244978
2961
2962 2019-05-07  Tadeu Zagallo  <tzagallo@apple.com>
2963
2964         tryCachePutByID should not crash if target offset changes
2965         https://bugs.webkit.org/show_bug.cgi?id=197311
2966         <rdar://problem/48033612>
2967
2968         Reviewed by Filip Pizlo.
2969
2970         When tryCachePutID is called with a cacheable setter, if the target object where the setter was
2971         found is still in the prototype chain and there's no poly protos in the chain, we use
2972         generateConditionsForPrototypePropertyHit to validate that the target object remains the same.
2973         It checks for the absence of the property in every object in the prototype chain from the base
2974         down to the target object and checks that the property is still present in the target object. It
2975         also bails if there are any uncacheable objects, proxies or dictionary objects in the prototype
2976         chain. However, it does not consider two edge cases:
2977         - It asserts that the property should still be at the same offset in the target object, but this
2978         assertion does not hold if the setter deletes properties of the object and causes the structure
2979         to be flattened after the deletion. Instead of asserting, we just use the updated offset.
2980         - It does not check whether the new slot is also a setter, which leads to a crash in case it's not.
2981
2982         * jit/Repatch.cpp:
2983         (JSC::tryCachePutByID):
2984
2985 2019-05-07  Saam Barati  <sbarati@apple.com>
2986
2987         Don't OSR enter into an FTL CodeBlock that has been jettisoned
2988         https://bugs.webkit.org/show_bug.cgi?id=197531
2989         <rdar://problem/50162379>
2990
2991         Reviewed by Yusuke Suzuki.
2992
2993         Sometimes we make silly mistakes. This is one of those times. It's invalid to OSR
2994         enter into an FTL OSR entry code block that has been jettisoned already.
2995
2996         * dfg/DFGJITCode.cpp:
2997         (JSC::DFG::JITCode::clearOSREntryBlockAndResetThresholds):
2998         * dfg/DFGJITCode.h:
2999         (JSC::DFG::JITCode::clearOSREntryBlock): Deleted.
3000         * dfg/DFGOSREntry.cpp:
3001         (JSC::DFG::prepareOSREntry):
3002         (JSC::DFG::prepareCatchOSREntry):
3003         * dfg/DFGOperations.cpp:
3004         * ftl/FTLOSREntry.cpp:
3005         (JSC::FTL::prepareOSREntry):
3006
3007 2019-05-06  Keith Miller  <keith_miller@apple.com>
3008
3009         JSWrapperMap should check if existing prototype properties are wrappers when copying exported methods.
3010         https://bugs.webkit.org/show_bug.cgi?id=197324
3011         <rdar://problem/50253144>
3012
3013         Reviewed by Saam Barati.
3014
3015         The current implementation prevents using JSExport to shadow a
3016         method from a super class. This was because we would only add a
3017         method if the prototype didn't already claim to have the
3018         property. Normally this would only happen if an Objective-C super
3019         class already exported a ObjCCallbackFunction for the method,
3020         however, if the user exports a property that is already on
3021         Object.prototype the overriden method won't be exported.
3022
3023         This patch fixes the object prototype issue by checking if the
3024         property on the prototype chain is an ObjCCallbackFunction, if
3025         it's not then it adds an override.
3026
3027         * API/JSWrapperMap.mm:
3028         (copyMethodsToObject):
3029         * API/tests/testapi.mm:
3030         (-[ToStringClass toString]):
3031         (-[ToStringClass other]):
3032         (-[ToStringSubclass toString]):
3033         (-[ToStringSubclassNoProtocol toString]):
3034         (testToString):
3035         (testObjectiveCAPI):
3036
3037 2019-05-06  Yusuke Suzuki  <ysuzuki@apple.com>
3038
3039         [JSC] We should check OOM for description string of Symbol
3040         https://bugs.webkit.org/show_bug.cgi?id=197634
3041
3042         Reviewed by Keith Miller.
3043
3044         When resoling JSString for description of Symbol, we should check OOM error.
3045         We also change JSValueMakeSymbol(..., nullptr) to returning a symbol value
3046         without description, (1) to simplify the code and (2) give a way for JSC API
3047         to create a symbol value without description.
3048
3049         * API/JSValueRef.cpp:
3050         (JSValueMakeSymbol):
3051         * API/tests/testapi.cpp:
3052         (TestAPI::symbolsTypeof):
3053         (TestAPI::symbolsDescription):
3054         (testCAPIViaCpp):
3055         * dfg/DFGOperations.cpp:
3056         * runtime/Symbol.cpp:
3057         (JSC::Symbol::createWithDescription):
3058         * runtime/Symbol.h:
3059         * runtime/SymbolConstructor.cpp:
3060         (JSC::callSymbol):
3061
3062 2019-05-06  Keith Rollin  <krollin@apple.com>
3063
3064         Temporarily disable generate-xcfilelists
3065         https://bugs.webkit.org/show_bug.cgi?id=197619
3066         <rdar://problem/50507392>
3067
3068         Reviewed by Alex Christensen.
3069
3070         We need to perform a significant update to the generate-xcfilelist
3071         scripts. This work involves coordinated work with another facility. If
3072         the work does not occur in tandem, the build will be broken. To avoid
3073         this, disable the invoking of the scripts during the transition. The
3074         checking will be restored once the new scripts are in place.
3075
3076         * Scripts/check-xcfilelists.sh:
3077
3078 2019-05-06  Basuke Suzuki  <Basuke.Suzuki@sony.com>
3079
3080         [PlayStation] Fix build break since r244919
3081         https://bugs.webkit.org/show_bug.cgi?id=197627
3082
3083         Reviewed by Ross Kirsling.
3084
3085         Bugfix for POSIX socket implementation and suppress warnings.
3086
3087         * inspector/remote/socket/RemoteInspectorConnectionClient.h:
3088         (Inspector::RemoteInspectorConnectionClient::didAccept):
3089         * inspector/remote/socket/posix/RemoteInspectorSocketPOSIX.cpp:
3090         (Inspector::Socket::getPort):
3091
3092 2019-05-06  Yusuke Suzuki  <ysuzuki@apple.com>
3093
3094         TemplateObject passed to template literal tags are not always identical for the same source location.
3095         https://bugs.webkit.org/show_bug.cgi?id=190756
3096
3097         Reviewed by Saam Barati.
3098
3099         Tagged template literal requires that the site object is allocated per source location. Previously, we create the site object
3100         when linking CodeBlock and cache it in CodeBlock. But this is wrong because,
3101
3102         1. CodeBlock can be jettisoned and regenerated. So every time CodeBlock is regenerated, we get the different site object.
3103         2. Call and Construct can have different CodeBlock. Even if the function is called in call-form or construct-form, we should return the same site object.
3104
3105         In this patch, we start caching these site objects in the top-level ScriptExecutable, this matches the spec's per source location since the only one top-level
3106         ScriptExecutable is created for the given script code. Each ScriptExecutable of JSFunction can be created multiple times because CodeBlock creates it.
3107         But the top-level one is not created by CodeBlock. This top-level ScriptExecutable is well-aligned to the Script itself. The top-level ScriptExecutable now has HashMap,
3108         which maps source locations to cached site objects.
3109
3110         1. This patch threads the top-level ScriptExecutable to each FunctionExecutable creation. Each FunctionExecutable has a reference to the top-level ScriptExecutable.
3111         2. We put TemplateObjectMap in ScriptExecutable, which manages cached template objects.
3112         3. We move FunctionExecutable::m_cachedPolyProtoStructure to the FunctionExecutable::RareDate to keep FunctionExecutable 128 bytes.
3113
3114         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
3115         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
3116         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Combined.js-result:
3117         * Scripts/tests/builtins/expected/JavaScriptCore-Builtin.prototype-Separate.js-result:
3118         * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Combined.js-result:
3119         * Scripts/tests/builtins/expected/JavaScriptCore-BuiltinConstructor-Separate.js-result:
3120         * Scripts/tests/builtins/expected/JavaScriptCore-InternalClashingNames-Combined.js-result:
3121         * Scripts/tests/builtins/expected/WebCore-AnotherGuardedInternalBuiltin-Separate.js-result:
3122         * Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
3123         * Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
3124         * Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
3125         * Scripts/tests/builtins/expected/WebCore-UnguardedBuiltin-Separate.js-result:
3126         * Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
3127         * Scripts/wkbuiltins/builtins_templates.py:
3128         * bytecode/CodeBlock.cpp:
3129         (JSC::CodeBlock::finishCreation):
3130         (JSC::CodeBlock::setConstantRegisters):
3131         * bytecode/CodeBlock.h:
3132         * bytecode/UnlinkedFunctionExecutable.cpp:
3133         (JSC::UnlinkedFunctionExecutable::link):
3134         * bytecode/UnlinkedFunctionExecutable.h:
3135         * bytecompiler/BytecodeGenerator.cpp:
3136         (JSC::BytecodeGenerator::addTemplateObjectConstant):
3137         (JSC::BytecodeGenerator::emitGetTemplateObject):
3138         * bytecompiler/BytecodeGenerator.h:
3139         * runtime/CachedTypes.cpp:
3140         (JSC::CachedTemplateObjectDescriptor::encode):
3141         (JSC::CachedTemplateObjectDescriptor::decode const):
3142         (JSC::CachedJSValue::encode):
3143         (JSC::CachedJSValue::decode const):
3144         * runtime/EvalExecutable.cpp:
3145         (JSC::EvalExecutable::ensureTemplateObjectMap):
3146         (JSC::EvalExecutable::visitChildren):
3147         * runtime/EvalExecutable.h:
3148         * runtime/FunctionExecutable.cpp:
3149         (JSC::FunctionExecutable::finishCreation):
3150         (JSC::FunctionExecutable::visitChildren):
3151         (JSC::FunctionExecutable::fromGlobalCode):
3152         (JSC::FunctionExecutable::ensureRareDataSlow):
3153         (JSC::FunctionExecutable::ensureTemplateObjectMap):
3154         * runtime/FunctionExecutable.h:
3155         * runtime/JSModuleRecord.cpp:
3156         (JSC::JSModuleRecord::instantiateDeclarations):
3157         * runtime/JSTemplateObjectDescriptor.cpp:
3158         (JSC::JSTemplateObjectDescriptor::JSTemplateObjectDescriptor):
3159         (JSC::JSTemplateObjectDescriptor::create):
3160         * runtime/JSTemplateObjectDescriptor.h:
3161         * runtime/ModuleProgramExecutable.cpp:
3162         (JSC::ModuleProgramExecutable::ensureTemplateObjectMap):
3163         (JSC::ModuleProgramExecutable::visitChildren):
3164         * runtime/ModuleProgramExecutable.h:
3165         * runtime/ProgramExecutable.cpp:
3166         (JSC::ProgramExecutable::ensureTemplateObjectMap):
3167         (JSC::ProgramExecutable::visitChildren):
3168         * runtime/ProgramExecutable.h:
3169         * runtime/ScriptExecutable.cpp:
3170         (JSC::ScriptExecutable::topLevelExecutable):
3171         (JSC::ScriptExecutable::createTemplateObject):
3172         (JSC::ScriptExecutable::ensureTemplateObjectMap):
3173         * runtime/ScriptExecutable.h:
3174         * tools/JSDollarVM.cpp:
3175         (JSC::functionCreateBuiltin):
3176         (JSC::functionDeleteAllCodeWhenIdle):
3177         (JSC::JSDollarVM::finishCreation):
3178
3179 2019-05-04  Tadeu Zagallo  <tzagallo@apple.com>
3180
3181         TypedArrays should not store properties that are canonical numeric indices
3182         https://bugs.webkit.org/show_bug.cgi?id=197228
3183         <rdar://problem/49557381>
3184
3185         Reviewed by Saam Barati.
3186
3187         According to the spec[1]:
3188         - TypedArrays should not perform an ordinary GetOwnProperty/SetOwnProperty if the index is a
3189         CanonicalNumericIndexString, but invalid according to IntegerIndexedElementGet and similar
3190         functions. I.e., there are a few properties that should not be set in a TypedArray, like NaN,
3191         Infinity and -0.
3192         - On DefineOwnProperty, the out-of-bounds check should be performed before validating the property
3193         descriptor.
3194         - On GetOwnProperty, the returned descriptor for numeric properties should have writable set to true.
3195
3196         [1]: https://www.ecma-international.org/ecma-262/9.0/index.html#sec-integer-indexed-exotic-objects-defineownproperty-p-desc
3197
3198         * CMakeLists.txt:
3199         * JavaScriptCore.xcodeproj/project.pbxproj:
3200         * runtime/JSGenericTypedArrayViewInlines.h:
3201         (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlot):
3202         (JSC::JSGenericTypedArrayView<Adaptor>::put):
3203         (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
3204         (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlotByIndex):
3205         (JSC::JSGenericTypedArrayView<Adaptor>::putByIndex):
3206         * runtime/PropertyName.h:
3207         (JSC::isCanonicalNumericIndexString):
3208
3209 2019-05-03  Yusuke Suzuki  <ysuzuki@apple.com>
3210
3211         [JSC] Need to emit SetLocal if we emit MovHint in DFGByteCodeParser
3212         https://bugs.webkit.org/show_bug.cgi?id=197584
3213
3214         Reviewed by Saam Barati.
3215
3216         In r244864, we emit MovHint for adhocly created GetterCall/SetterCall frame locals in the callee side to make OSR availability analysis's pruning correct.
3217         However, we just emit MovHint, and we do not emit SetLocal since we ensured that these locals are already flushed in the same place before. However, MovHint
3218         and SetLocal are needed to be a pair in DFGByteCodeParser because we rely on this assumption in SSA conversion phase. SSA conversion phase always emit KillStack
3219         just before MovHint's target location even if the MovHint's target is the same to the previously emitted MovHint and SetLocal.
3220         This patch emits SetLocal too when emitting MovHint for GetterCall/SetterCall frame locals.
3221
3222         The example is like this.
3223
3224             a:  SomeValueNode
3225              :  MovHint(@a, loc10)
3226             b:  SetLocal(@a, loc10)
3227                 ...
3228             c:  MovHint(@a, loc10)
3229
3230         Then, this will be converted to the style in SSA conversion.
3231
3232             a:  SomeValueNode
3233              :  KillStack(loc10)
3234             b:  PutStack(@a, loc10)
3235                 ...
3236             c:  KillStack(loc10)
3237
3238         Then, @b will be removed later since @c kills it.
3239
3240         * dfg/DFGByteCodeParser.cpp:
3241         (JSC::DFG::ByteCodeParser::inlineCall):
3242         * heap/MarkedBlock.cpp:
3243         (JSC::MarkedBlock::MarkedBlock):
3244         (JSC::MarkedBlock::Handle::stopAllocating):
3245         (JSC::MarkedBlock::Handle::resumeAllocating):
3246         (JSC::MarkedBlock::aboutToMarkSlow):
3247         (JSC::MarkedBlock::Handle::didConsumeFreeList):
3248
3249 2019-05-03  Devin Rousso  <drousso@apple.com>
3250
3251         Web Inspector: DOM: rename "low power" to "display composited"
3252         https://bugs.webkit.org/show_bug.cgi?id=197296
3253
3254         Reviewed by Joseph Pecoraro.
3255
3256         Removed specific ChangeLog entries since it is almost entirely mechanical changes.
3257
3258         * inspector/protocol/DOM.json:
3259
3260 2019-05-03  Basuke Suzuki  <Basuke.Suzuki@sony.com>
3261
3262         [WinCairo] Implement and enable RemoteInspector Server.
3263         https://bugs.webkit.org/show_bug.cgi?id=197432
3264
3265         Reviewed by Ross Kirsling.
3266
3267         Implement Windows implementation for Socket Backend of RemoteInspector and enable it on WinCairo
3268         for experimental feature.
3269
3270         Also add listener interface for connection between RemoteInspector and RemoteInspectorServer
3271         for flexible configuration.
3272
3273         * PlatformWin.cmake:
3274         * inspector/remote/RemoteInspector.h:
3275         * inspector/remote/socket/RemoteInspectorConnectionClient.h:
3276         (Inspector::RemoteInspectorConnectionClient::didAccept):
3277         * inspector/remote/socket/RemoteInspectorServer.cpp:
3278         (Inspector::RemoteInspectorServer::connect):
3279         (Inspector::RemoteInspectorServer::listenForTargets):
3280         (Inspector::RemoteInspectorServer::didAccept):
3281         (Inspector::RemoteInspectorServer::dispatchMap):
3282         (Inspector::RemoteInspectorServer::start):
3283         (Inspector::RemoteInspectorServer::addServerConnection): Deleted.
3284         * inspector/remote/socket/RemoteInspectorServer.h:
3285         (Inspector::RemoteInspectorServer::RemoteInspectorServer):
3286         * inspector/remote/socket/RemoteInspectorSocket.cpp:
3287         (Inspector::RemoteInspector::RemoteInspector):
3288         (Inspector::RemoteInspector::dispatchMap):
3289         (Inspector::RemoteInspector::start):
3290         (Inspector::RemoteInspector::stopInternal):
3291         (Inspector::RemoteInspector::setServerPort):
3292         * inspector/remote/socket/RemoteInspectorSocket.h:
3293         * inspector/remote/socket/RemoteInspectorSocketEndpoint.cpp:
3294         (Inspector::RemoteInspectorSocketEndpoint::listenInet):
3295         (Inspector::RemoteInspectorSocketEndpoint::getPort const):
3296         (Inspector::RemoteInspectorSocketEndpoint::acceptInetSocketIfEnabled):
3297         * inspector/remote/socket/RemoteInspectorSocketEndpoint.h:
3298         * inspector/remote/socket/posix/RemoteInspectorSocketPOSIX.cpp:
3299         (Inspector::Socket::init): Added.
3300         (Inspector::Socket::listen): Signature changed.
3301         (Inspector::Socket::getPort): Added.
3302         * inspector/remote/socket/win/RemoteInspectorSocketWin.cpp: Added.
3303         (Inspector::Socket::init):
3304         (Inspector::Socket::Socket::Socket):
3305         (Inspector::Socket::Socket::~Socket):
3306         (Inspector::Socket::Socket::close):
3307         (Inspector::Socket::Socket::operator PlatformSocketType const):
3308         (Inspector::Socket::Socket::operator bool const):
3309         (Inspector::Socket::Socket::leak):
3310         (Inspector::Socket::Socket::create):
3311         (Inspector::Socket::setOpt):
3312         (Inspector::Socket::setOptEnabled):
3313         (Inspector::Socket::enableOpt):
3314         (Inspector::Socket::connectTo):
3315         (Inspector::Socket::bindAndListen):
3316         (Inspector::Socket::connect):
3317         (Inspector::Socket::listen):
3318         (Inspector::Socket::accept):
3319         (Inspector::Socket::createPair):
3320         (Inspector::Socket::setup):
3321         (Inspector::Socket::isValid):
3322         (Inspector::Socket::isListening):
3323         (Inspector::Socket::getPort):
3324         (Inspector::Socket::read):
3325         (Inspector::Socket::write):
3326         (Inspector::Socket::close):
3327         (Inspector::Socket::preparePolling):
3328         (Inspector::Socket::poll):
3329         (Inspector::Socket::isReadable):
3330         (Inspector::Socket::isWritable):
3331         (Inspector::Socket::markWaitingWritable):
3332         (Inspector::Socket::clearWaitingWritable):
3333
3334 2019-05-03  Yusuke Suzuki  <ysuzuki@apple.com>
3335
3336         [JSC] Generator CodeBlock generation should be idempotent
3337         https://bugs.webkit.org/show_bug.cgi?id=197552
3338
3339         Reviewed by Keith Miller.
3340
3341         ES6 Generator saves and resumes the current execution state. Since ES6 generator can save the execution state at expression
3342         granularity (not statement granularity), the saved state involves locals. But if the underlying CodeBlock is jettisoned and
3343         recompiled with different code generation option (like, debugger, type profiler etc.), the generated instructions can be largely
3344         different and it does not have the same state previously used. If we resume the previously created generator with the newly
3345         generator function, resuming is messed up.
3346
3347             function* gen () { ... }
3348             var g = gen();
3349             g.next();
3350
3351             // CodeBlock is destroyed & Debugger is enabled.
3352
3353             g.next();
3354
3355         In this patch,
3356
3357         1. In generatorification, we use index Identifier (localN => Identifier("N")) instead of private symbols to generate the same
3358            instructions every time we regenerate the CodeBlock.
3359
3360         2. We decouple the options which can affect on the generated code (Debugger, TypeProfiler, ControlFlowProfiler) from the BytecodeGenerator,
3361            and pass them as a parameter, OptionSet<CodeGeneratorMode>.
3362
3363         3. Generator ScriptExecutable remembers the previous CodeGeneratorMode and reuses this parameter to regenerate CodeBlock. It means that,
3364            even if the debugger is enabled, previously created generators are not debuggable. But newly created generators are debuggable.
3365
3366         * bytecode/BytecodeGeneratorification.cpp:
3367         (JSC::BytecodeGeneratorification::storageForGeneratorLocal):
3368         (JSC::BytecodeGeneratorification::run):
3369         * bytecode/CodeBlock.cpp:
3370         (JSC::CodeBlock::finishCreation):
3371         (JSC::CodeBlock::setConstantRegisters):
3372         * bytecode/UnlinkedCodeBlock.cpp:
3373         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
3374         * bytecode/UnlinkedCodeBlock.h:
3375         (JSC::UnlinkedCodeBlock::wasCompiledWithDebuggingOpcodes const):
3376         (JSC::UnlinkedCodeBlock::wasCompiledWithTypeProfilerOpcodes const):
3377         (JSC::UnlinkedCodeBlock::wasCompiledWithControlFlowProfilerOpcodes const):
3378         (JSC::UnlinkedCodeBlock::codeGenerationMode const):
3379         * bytecode/UnlinkedEvalCodeBlock.h:
3380         * bytecode/UnlinkedFunctionCodeBlock.h:
3381         * bytecode/UnlinkedFunctionExecutable.cpp:
3382         (JSC::generateUnlinkedFunctionCodeBlock):
3383         (JSC::UnlinkedFunctionExecutable::fromGlobalCode):
3384         (JSC::UnlinkedFunctionExecutable::unlinkedCodeBlockFor):
3385         * bytecode/UnlinkedFunctionExecutable.h:
3386         * bytecode/UnlinkedGlobalCodeBlock.h:
3387         (JSC::UnlinkedGlobalCodeBlock::UnlinkedGlobalCodeBlock):
3388         * bytecode/UnlinkedModuleProgramCodeBlock.h:
3389         * bytecode/UnlinkedProgramCodeBlock.h:
3390         * bytecompiler/BytecodeGenerator.cpp:
3391         (JSC::BytecodeGenerator::BytecodeGenerator):
3392         (JSC::BytecodeGenerator::emitTypeProfilerExpressionInfo):
3393         (JSC::BytecodeGenerator::emitProfileType):
3394         (JSC::BytecodeGenerator::emitProfileControlFlow):
3395         (JSC::BytecodeGenerator::pushLexicalScopeInternal):
3396         (JSC::BytecodeGenerator::popLexicalScopeInternal):
3397         (JSC::BytecodeGenerator::prepareLexicalScopeForNextForLoopIteration):
3398         (JSC::BytecodeGenerator::emitCall):
3399         (JSC::BytecodeGenerator::emitCallVarargs):
3400         (JSC::BytecodeGenerator::emitLogShadowChickenPrologueIfNecessary):
3401         (JSC::BytecodeGenerator::emitLogShadowChickenTailIfNecessary):
3402         (JSC::BytecodeGenerator::emitDebugHook):
3403         * bytecompiler/BytecodeGenerator.h:
3404         (JSC::BytecodeGenerator::generate):
3405         (JSC::BytecodeGenerator::shouldEmitDebugHooks const):
3406         (JSC::BytecodeGenerator::shouldEmitTypeProfilerHooks const):
3407         (JSC::BytecodeGenerator::shouldEmitControlFlowProfilerHooks const):
3408         * bytecompiler/NodesCodegen.cpp:
3409         (JSC::PrefixNode::emitResolve):
3410         (JSC::EmptyVarExpression::emitBytecode):
3411         (JSC::ReturnNode::emitBytecode):
3412         (JSC::FunctionNode::emitBytecode):
3413         * parser/ParserModes.h:
3414         (): Deleted.
3415         * parser/SourceCodeKey.h:
3416         (JSC::SourceCodeFlags::SourceCodeFlags):
3417         (JSC::SourceCodeKey::SourceCodeKey):
3418         * runtime/CachedTypes.cpp:
3419         (JSC::CachedCodeBlock::isClassContext const):
3420         (JSC::CachedCodeBlock::codeGenerationMode const):
3421         (JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
3422         (JSC::CachedCodeBlock<CodeBlockType>::encode):
3423         (JSC::CachedCodeBlock::wasCompiledWithDebuggingOpcodes const): Deleted.
3424         * runtime/CodeCache.cpp:
3425         (JSC::CodeCache::getUnlinkedGlobalCodeBlock):
3426         (JSC::CodeCache::getUnlinkedProgramCodeBlock):
3427         (JSC::CodeCache::getUnlinkedEvalCodeBlock):
3428         (JSC::CodeCache::getUnlinkedModuleProgramCodeBlock):
3429         (JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
3430         (JSC::generateUnlinkedCodeBlockForFunctions):
3431         (JSC::sourceCodeKeyForSerializedBytecode):
3432         (JSC::sourceCodeKeyForSerializedProgram):
3433         (JSC::sourceCodeKeyForSerializedModule):
3434         (JSC::serializeBytecode):
3435         * runtime/CodeCache.h:
3436         (JSC::generateUnlinkedCodeBlockImpl):
3437         (JSC::generateUnlinkedCodeBlock):
3438         * runtime/Completion.cpp:
3439         (JSC::generateProgramBytecode):
3440         (JSC::generateModuleBytecode):
3441         * runtime/DirectEvalExecutable.cpp:
3442         (JSC::DirectEvalExecutable::create):
3443         * runtime/IndirectEvalExecutable.cpp:
3444         (JSC::IndirectEvalExecutable::create):
3445         * runtime/JSGlobalObject.h:
3446         (JSC::JSGlobalObject::defaultCodeGenerationMode const):
3447         * runtime/ModuleProgramExecutable.cpp:
3448         (JSC::ModuleProgramExecutable::create):
3449         * runtime/ProgramExecutable.cpp:
3450         (JSC::ProgramExecutable::initializeGlobalProperties):
3451         * runtime/ScriptExecutable.cpp:
3452         (JSC::ScriptExecutable::ScriptExecutable):
3453         (JSC::ScriptExecutable::newCodeBlockFor):
3454         * runtime/ScriptExecutable.h:
3455         * tools/JSDollarVM.cpp:
3456         (JSC::changeDebuggerModeWhenIdle):
3457         (JSC::functionEnableDebuggerModeWhenIdle):
3458         (JSC::functionDisableDebuggerModeWhenIdle):
3459
3460 2019-05-03  Devin Rousso  <drousso@apple.com>
3461
3462         Web Inspector: Record actions performed on WebGL2RenderingContext
3463         https://bugs.webkit.org/show_bug.cgi?id=176008
3464         <rdar://problem/34213884>
3465
3466         Reviewed by Joseph Pecoraro.
3467
3468         * inspector/protocol/Recording.json:
3469         * inspector/scripts/codegen/generator.py:
3470         Add `canvas-webgl2` as a `Type`.
3471
3472 2019-05-03  Commit Queue  <commit-queue@webkit.org>
3473
3474         Unreviewed, rolling out r244881.
3475         https://bugs.webkit.org/show_bug.cgi?id=197559
3476
3477         Breaks compilation of jsconly on linux, breaking compilation
3478         for jsc-i386-ews, jsc-mips-ews and jsc-armv7-ews (Requested by
3479         guijemont on #webkit).
3480
3481         Reverted changeset:
3482
3483         "[CMake] Refactor WEBKIT_MAKE_FORWARDING_HEADERS into
3484         WEBKIT_COPY_FILES"
3485         https://bugs.webkit.org/show_bug.cgi?id=197174
3486         https://trac.webkit.org/changeset/244881
3487
3488 2019-05-02  Don Olmstead  <don.olmstead@sony.com>
3489
3490         [CMake] Refactor WEBKIT_MAKE_FORWARDING_HEADERS into WEBKIT_COPY_FILES
3491         https://bugs.webkit.org/show_bug.cgi?id=197174
3492
3493         Reviewed by Alex Christensen.
3494
3495         Replace WEBKIT_MAKE_FORWARDING_HEADERS with WEBKIT_COPY_FILES and make dependencies
3496         for framework headers explicit.
3497
3498         * CMakeLists.txt:
3499
3500 2019-05-02  Michael Saboff  <msaboff@apple.com>
3501
3502         Unreviewed rollout of r244862.
3503
3504         * runtime/JSObject.cpp:
3505         (JSC::JSObject::getOwnPropertyDescriptor):
3506
3507 2019-05-01  Saam barati  <sbarati@apple.com>
3508
3509         Baseline JIT should do argument value profiling after checking for stack overflow
3510         https://bugs.webkit.org/show_bug.cgi?id=197052
3511         <rdar://problem/50009602>
3512
3513         Reviewed by Yusuke Suzuki.
3514
3515         Otherwise, we may do value profiling without running a write barrier, which
3516         is against the rules of how we do value profiling.
3517
3518         * jit/JIT.cpp:
3519         (JSC::JIT::compileWithoutLinking):
3520
3521 2019-05-01  Yusuke Suzuki  <ysuzuki@apple.com>
3522
3523         [JSC] Inlining Getter/Setter should care availability of ad-hocly constructed frame
3524         https://bugs.webkit.org/show_bug.cgi?id=197405
3525
3526         Reviewed by Saam Barati.
3527
3528         When inlining getter and setter calls, we setup a stack frame which does not appear in the bytecode.
3529         Because Inlining can switch on executable, we could have a graph like this.
3530
3531         BB#0
3532             ...
3533             30: GetSetter
3534             31: MovHint(loc10)
3535             32: SetLocal(loc10)
3536             33: MovHint(loc9)
3537             34: SetLocal(loc9)
3538             ...
3539             37: GetExecutable(@30)
3540             ...
3541             41: Switch(@37)
3542
3543         BB#2
3544             42: GetLocal(loc12, bc#7 of caller)
3545             ...
3546             --> callee: loc9 and loc10 are arguments of callee.
3547               ...
3548               <HERE, exit to callee, loc9 and loc10 are required in the bytecode>
3549
3550         When we prune OSR availability at the beginning of BB#2 (bc#7 in the caller), we prune loc9 and loc10's liveness because the caller does not actually have loc9 and loc10.
3551         However, when we begin executing the callee, we need OSR exit to be aware of where it can recover the arguments to the setter, loc9 and loc10.
3552
3553         This patch inserts MovHint at the beginning of callee for a getter / setter stack frame to make arguments (loc9 and loc10 in the above example) recoverable from OSR exit.
3554         We also move arity fixup DFG nodes from the caller to the callee, since moved arguments are not live in the caller too.
3555
3556         Interestingly, this fix also reveals the existing issue in LiveCatchVariablePreservationPhase. We emitted Flush for |this| of InlineCallFrame blindly if we saw InlineCallFrame
3557         inside a block which is covered by catch handler. But this is wrong because inlined function can finish its execution within the block, and |this| is completely unrelated to
3558         the catch handler if the catch handler is in the outer callee. We already collect all the live locals at the catch handler. And this locals must include arguments too if the
3559         catch handler is in inlined function. So, we should not emit Flush for each |this| of seen InlineCallFrame. This emitted Flush may connect unrelated locals in the catch handler
3560         to the locals that is only defined and used in the inlined function, and it leads to the results like DFG says the local is live while the bytecode says the local is dead.
3561         This results in reading and using garbage in OSR entry because DFG OSR entry needs to fill live DFG values from the stack.
3562
3563         * dfg/DFGByteCodeParser.cpp:
3564         (JSC::DFG::ByteCodeParser::inlineCall):
3565         (JSC::DFG::ByteCodeParser::handleGetById):
3566         (JSC::DFG::ByteCodeParser::handlePutById):
3567         * dfg/DFGLiveCatchVariablePreservationPhase.cpp:
3568         (JSC::DFG::LiveCatchVariablePreservationPhase::handleBlockForTryCatch):
3569
3570 2019-05-01  Michael Saboff  <msaboff@apple.com>
3571
3572         ASSERTION FAILED: !m_needExceptionCheck with --validateExceptionChecks=1; ProxyObject.getOwnPropertySlotCommon/JSFunction.callerGetter
3573         https://bugs.webkit.org/show_bug.cgi?id=197485
3574
3575         Reviewed by Saam Barati.
3576
3577         Added an EXCEPTION_ASSERT after call to getOwnPropertySlot().
3578
3579         * runtime/JSObject.cpp:
3580         (JSC::JSObject::getOwnPropertyDescriptor):
3581
3582 2019-05-01  Ross Kirsling  <ross.kirsling@sony.com>
3583
3584         RemoteInspector::updateAutomaticInspectionCandidate should have a default implementation.
3585         https://bugs.webkit.org/show_bug.cgi?id=197439
3586
3587         Reviewed by Devin Rousso.
3588
3589         On non-Cocoa platforms, automatic inspection is not currently implemented,
3590         so updateAutomaticInspectionCandidate falls back to the logic of updateTarget.
3591         This logic already existed in three places, so refactor it into a common private method
3592         and allow our websocket-based RWI implementation to make use of it too.
3593
3594         * inspector/remote/RemoteInspector.cpp:
3595         (Inspector::RemoteInspector::updateTarget):
3596         (Inspector::RemoteInspector::updateTargetMap):
3597         (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
3598         * inspector/remote/RemoteInspector.h:
3599         * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
3600         (Inspector::RemoteInspector::updateAutomaticInspectionCandidate):
3601         * inspector/remote/glib/RemoteInspectorGlib.cpp:
3602         (Inspector::RemoteInspector::updateAutomaticInspectionCandidate): Deleted.
3603         * inspector/remote/socket/RemoteInspectorSocket.cpp:
3604         (Inspector::RemoteInspector::updateAutomaticInspectionCandidate): Deleted.
3605
3606 2019-05-01  Darin Adler  <darin@apple.com>
3607
3608         WebKit has too much of its own UTF-8 code and should rely more on ICU's UTF-8 support
3609         https://bugs.webkit.org/show_bug.cgi?id=195535
3610
3611         Reviewed by Alexey Proskuryakov.
3612
3613         * API/JSClassRef.cpp: Removed uneeded include of UTF8Conversion.h.
3614
3615         * API/JSStringRef.cpp:
3616         (JSStringCreateWithUTF8CString): Updated for changes to convertUTF8ToUTF16.
3617         (JSStringGetUTF8CString): Updated for changes to convertLatin1ToUTF8.
3618         Removed unneeded "true" to get the strict version of convertUTF16ToUTF8,
3619         since that is the default. Also updated for changes to CompletionResult.
3620
3621         * runtime/JSGlobalObjectFunctions.cpp:
3622         (JSC::decode): Stop using UTF8SequenceLength, and instead use U8_COUNT_TRAIL_BYTES
3623         and U8_MAX_LENGTH. Instead of decodeUTF8Sequence, use U8_NEXT. Also use U_IS_BMP,
3624         U_IS_SUPPLEMENTARY, U16_LEAD, U16_TRAIL, and U_IS_SURROGATE instead of our own
3625         equivalents, since these macros from ICU are correct and efficient.
3626
3627         * wasm/WasmParser.h:
3628         (JSC::Wasm::Parser<SuccessType>::consumeUTF8String): Updated for changes to
3629         convertUTF8ToUTF16.
3630
3631 2019-05-01  Shawn Roberts  <sroberts@apple.com>
3632
3633         Unreviewed, rolling out r244821.
3634
3635         Causing
3636
3637         Reverted changeset:
3638
3639         "WebKit has too much of its own UTF-8 code and should rely
3640         more on ICU's UTF-8 support"
3641         https://bugs.webkit.org/show_bug.cgi?id=195535
3642         https://trac.webkit.org/changeset/244821
3643
3644 2019-04-29  Darin Adler  <darin@apple.com>
3645
3646         WebKit has too much of its own UTF-8 code and should rely more on ICU's UTF-8 support
3647         https://bugs.webkit.org/show_bug.cgi?id=195535
3648
3649         Reviewed by Alexey Proskuryakov.
3650
3651         * API/JSClassRef.cpp: Removed uneeded include of UTF8Conversion.h.
3652
3653         * API/JSStringRef.cpp:
3654         (JSStringCreateWithUTF8CString): Updated for changes to convertUTF8ToUTF16.
3655         (JSStringGetUTF8CString): Updated for changes to convertLatin1ToUTF8.
3656         Removed unneeded "true" to get the strict version of convertUTF16ToUTF8,
3657         since that is the default. Also updated for changes to CompletionResult.
3658
3659         * runtime/JSGlobalObjectFunctions.cpp:
3660         (JSC::decode): Stop using UTF8SequenceLength, and instead use U8_COUNT_TRAIL_BYTES
3661         and U8_MAX_LENGTH. Instead of decodeUTF8Sequence, use U8_NEXT. Also use U_IS_BMP,
3662         U_IS_SUPPLEMENTARY, U16_LEAD, U16_TRAIL, and U_IS_SURROGATE instead of our own
3663         equivalents, since these macros from ICU are correct and efficient.
3664
3665         * wasm/WasmParser.h:
3666         (JSC::Wasm::Parser<SuccessType>::consumeUTF8String): Updated for changes to
3667         convertUTF8ToUTF16.
3668
3669 2019-04-30  Commit Queue  <commit-queue@webkit.org>
3670
3671         Unreviewed, rolling out r244806.
3672         https://bugs.webkit.org/show_bug.cgi?id=197446
3673
3674         Causing Test262 and JSC test failures on multiple builds
3675         (Requested by ShawnRoberts on #webkit).
3676
3677         Reverted changeset:
3678
3679         "TypeArrays should not store properties that are canonical
3680         numeric indices"
3681         https://bugs.webkit.org/show_bug.cgi?id=197228
3682         https://trac.webkit.org/changeset/244806
3683
3684 2019-04-30  Saam barati  <sbarati@apple.com>
3685
3686         CodeBlock::m_instructionCount is wrong
3687         https://bugs.webkit.org/show_bug.cgi?id=197304
3688
3689         Reviewed by Yusuke Suzuki.
3690
3691         What we were calling instructionCount() was wrong, as evidenced by
3692         us using it incorrectly both in the sampling profiler and when we
3693         dumped bytecode for a given CodeBlock. Prior to the bytecode rewrite,
3694         instructionCount() was probably valid to do bounds checks against.
3695         However, this is no longer the case. This patch renames what we called
3696         instructionCount() to bytecodeCost(). It is now only used to make decisions
3697         about inlining and tier up heuristics. I've also named options related to
3698         this appropriately.
3699
3700         This patch also introduces instructionsSize(). The result of this method
3701         is valid to do bounds checks against.
3702
3703         * bytecode/CodeBlock.cpp:
3704         (JSC::CodeBlock::dumpAssumingJITType const):
3705         (JSC::CodeBlock::CodeBlock):
3706         (JSC::CodeBlock::finishCreation):
3707         (JSC::CodeBlock::optimizationThresholdScalingFactor):
3708         (JSC::CodeBlock::predictedMachineCodeSize):
3709         * bytecode/CodeBlock.h:
3710         (JSC::CodeBlock::instructionsSize const):
3711         (JSC::CodeBlock::bytecodeCost const):
3712         (JSC::CodeBlock::instructionCount const): Deleted.
3713         * dfg/DFGByteCodeParser.cpp:
3714         (JSC::DFG::ByteCodeParser::inliningCost):
3715         (JSC::DFG::ByteCodeParser::getInliningBalance):
3716         * dfg/DFGCapabilities.cpp:
3717         (JSC::DFG::mightCompileEval):
3718         (JSC::DFG::mightCompileProgram):
3719         (JSC::DFG::mightCompileFunctionForCall):
3720         (JSC::DFG::mightCompileFunctionForConstruct):
3721         (JSC::DFG::mightInlineFunctionForCall):
3722         (JSC::DFG::mightInlineFunctionForClosureCall):
3723         (JSC::DFG::mightInlineFunctionForConstruct):
3724         * dfg/DFGCapabilities.h:
3725         (JSC::DFG::isSmallEnoughToInlineCodeInto):
3726         * dfg/DFGDisassembler.cpp:
3727         (JSC::DFG::Disassembler::dumpHeader):
3728         * dfg/DFGDriver.cpp:
3729         (JSC::DFG::compileImpl):
3730         * dfg/DFGPlan.cpp:
3731         (JSC::DFG::Plan::compileInThread):
3732         * dfg/DFGTierUpCheckInjectionPhase.cpp:
3733         (JSC::DFG::TierUpCheckInjectionPhase::run):
3734         * ftl/FTLCapabilities.cpp:
3735         (JSC::FTL::canCompile):
3736         * ftl/FTLCompile.cpp:
3737         (JSC::FTL::compile):
3738         * ftl/FTLLink.cpp:
3739         (JSC::FTL::link):
3740         * jit/JIT.cpp:
3741         (JSC::JIT::link):
3742         * jit/JITDisassembler.cpp:
3743         (JSC::JITDisassembler::dumpHeader):
3744         * llint/LLIntSlowPaths.cpp:
3745         (JSC::LLInt::shouldJIT):
3746         * profiler/ProfilerBytecodes.cpp:
3747         (JSC::Profiler::Bytecodes::Bytecodes):
3748         * runtime/Options.h:
3749         * runtime/SamplingProfiler.cpp:
3750         (JSC::tryGetBytecodeIndex):
3751         (JSC::SamplingProfiler::processUnverifiedStackTraces):
3752
3753 2019-04-30  Tadeu Zagallo  <tzagallo@apple.com>
3754
3755         TypeArrays should not store properties that are canonical numeric indices
3756         https://bugs.webkit.org/show_bug.cgi?id=197228
3757         <rdar://problem/49557381>
3758
3759         Reviewed by Darin Adler.
3760
3761         According to the spec[1], TypedArrays should not perform an ordinary GetOwnProperty/SetOwnProperty
3762         if the index is a CanonicalNumericIndexString, but invalid according toIntegerIndexedElementGet
3763         and similar functions. I.e., there are a few properties that should not be set in a TypedArray,
3764         like NaN, Infinity and -0.
3765
3766         [1]: https://www.ecma-international.org/ecma-262/9.0/index.html#sec-integer-indexed-exotic-objects-defineownproperty-p-desc
3767
3768         * CMakeLists.txt:
3769         * JavaScriptCore.xcodeproj/project.pbxproj:
3770         * runtime/JSGenericTypedArrayViewInlines.h:
3771         (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlot):
3772         (JSC::JSGenericTypedArrayView<Adaptor>::put):
3773         (JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
3774         (JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlotByIndex):
3775         (JSC::JSGenericTypedArrayView<Adaptor>::putByIndex):
3776         * runtime/JSTypedArrays.cpp:
3777         * runtime/PropertyName.h:
3778         (JSC::canonicalNumericIndexString):
3779
3780 2019-04-30  Brian Burg  <bburg@apple.com>
3781
3782         Web Automation: use a more informative key to indicate automation availability
3783         https://bugs.webkit.org/show_bug.cgi?id=197377
3784         <rdar://problem/50258069>
3785
3786         Reviewed by Devin Rousso.
3787
3788         The existing WIRAutomationEnabledKey does not encode uncertainty.
3789         Add a new key that provides an 'Unknown' state, and prefer to use it.
3790
3791         Since an application's initial listing is sent from a background dispatch queue
3792         on Cocoa platforms, this can race with main thread initialization that sets up
3793         RemoteInspector::Client. Therefore, the initial listing may not properly represent
3794         the client's capabilites because the client is not yet available. Allowing for
3795         an "Unknown" state that is later upgraded to Available or Not Available makes it
3796         possible to work around this potential race.
3797
3798         * inspector/remote/RemoteInspectorConstants.h:
3799         * inspector/remote/cocoa/RemoteInspectorCocoa.mm:
3800         (Inspector::RemoteInspector::pushListingsNow):
3801
3802 2019-04-30  Keith Miller  <keith_miller@apple.com>
3803
3804         Fix failing ARM64E wasm tests
3805         https://bugs.webkit.org/show_bug.cgi?id=197420
3806
3807         Reviewed by Saam Barati.
3808
3809         This patch fixes a bug in the slow path of our JS->Wasm IC bridge
3810         where we wouldn't untag the link register before tail calling.
3811
3812         Additionally, this patch fixes a broken assert when using setting
3813         Options::useTailCalls=false.
3814
3815         * bytecompiler/BytecodeGenerator.cpp:
3816         (JSC::BytecodeGenerator::emitCallForwardArgumentsInTailPosition):
3817         * wasm/js/WebAssemblyFunction.cpp:
3818         (JSC::WebAssemblyFunction::jsCallEntrypointSlow):
3819
3820 2019-04-29  Saam Barati  <sbarati@apple.com>
3821
3822         Make JITType an enum class
3823         https://bugs.webkit.org/show_bug.cgi?id=197394
3824
3825         Reviewed by Yusuke Suzuki.
3826
3827         This makes the code more easily searchable.
3828
3829         * bytecode/CallLinkStatus.cpp:
3830         (JSC::CallLinkStatus::computeFor):
3831         * bytecode/CodeBlock.cpp:
3832         (JSC::CodeBlock::dumpAssumingJITType const):
3833         (JSC::CodeBlock::specialOSREntryBlockOrNull):
3834         (JSC::timeToLive):
3835         (JSC::CodeBlock::propagateTransitions):
3836         (JSC::CodeBlock::baselineAlternative):
3837         (JSC::CodeBlock::baselineVersion):
3838         (JSC::CodeBlock::hasOptimizedReplacement):
3839         (JSC::CodeBlock::noticeIncomingCall):
3840         (JSC::CodeBlock::setOptimizationThresholdBasedOnCompilationResult):
3841         (JSC::CodeBlock::tallyFrequentExitSites):
3842         (JSC::CodeBlock::frameRegisterCount):
3843         (JSC::CodeBlock::bytecodeOffsetFromCallSiteIndex):
3844         * bytecode/CodeBlock.h:
3845         (JSC::CodeBlock::jitType const):
3846         (JSC::CodeBlock::hasBaselineJITProfiling const):
3847         * bytecode/CodeBlockWithJITType.h:
3848         (JSC::CodeBlockWithJITType::CodeBlockWithJITType):
3849         * bytecode/DeferredSourceDump.cpp:
3850         (JSC::DeferredSourceDump::DeferredSourceDump):