Google Git
Sign in
chromium / external / github.com / WebKit / webkit / 2d3e1210eeb03add9f23d14fb69c46a4aff688ec / . / Source / JavaScriptCore / ChangeLog
blob: 03ed35777f7b33d874726f2897a9c75d50305da6 [file] [log] [blame]
2021-05-13 Chris Dumez <cdumez@apple.com>
Rename FileSystem::fileIsDirectory(path, followSymlinks) to isDirectory(path) / isDirectoryFollowingSymlinks(path)
https://bugs.webkit.org/show_bug.cgi?id=225772
Reviewed by Darin Adler.
Update code base due to API naming change.
* API/JSScript.mm:
(validateBytecodeCachePath):
2021-05-13 Darin Adler <darin@apple.com>
Remove StringBuilder::appendNumber
https://bugs.webkit.org/show_bug.cgi?id=225732
Reviewed by Sam Weinig.
* API/JSContextRef.cpp:
(BacktraceFunctor::operator() const): Use append instead of appendNumber.
* API/tests/PingPongStackOverflowTest.cpp:
(PingPongStackOverflowObject_hasInstance): Ditto.
* heap/HeapSnapshotBuilder.cpp:
(JSC::HeapSnapshotBuilder::json): Ditto.
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::Frame::toString const): Use makeString instead of StringBuilder.
* runtime/ConsoleClient.cpp:
(JSC::appendURLAndPosition): Ditto.
(JSC::ConsoleClient::printConsoleMessageWithArguments): Use append instead of appendNumber.
* runtime/JSONObject.cpp:
(JSC::Stringifier::appendStringifiedValue): Ditto.
* runtime/Options.cpp:
(JSC::OptionReader::Option::dump const): Ditto.
* runtime/StackFrame.cpp:
(JSC::StackFrame::toString const): Use makeString instead of StringBuilder.
2021-05-12 Geoffrey Garen <ggaren@apple.com>
ConservativeRoots triggers page demand on Speedometer
https://bugs.webkit.org/show_bug.cgi?id=225676
Reviewed by Filip Pizlo.
Use a 2048 item / 16kB inline buffer. That's about 10% bigger than the
max capacity observed on Speedometer, and small enough to reasonably fit
on the stack.
Removed the separate out of line capacity because it was smaller than
the new inline capacity.
* heap/ConservativeRoots.cpp:
(JSC::ConservativeRoots::grow):
* heap/ConservativeRoots.h:
2021-05-12 Mark Lam <mark.lam@apple.com>
Implement some common Baseline JIT slow paths using JIT thunks.
https://bugs.webkit.org/show_bug.cgi?id=225682
Reviewed by Filip Pizlo.
This patch implements the following changes:
1. Implement exception handling thunks:
a. handleExceptionGenerator, which calls operationLookupExceptionHandler().
b. handleExceptionWithCallFrameRollbackGenerator, which calls
operationLookupExceptionHandlerFromCallerFrame().
All the JIT tiers were emitting their own copy of these routines to call these
operation, one per CodeBlock. We now emit 2 thunks for these and have all the
tiers just jump to them.
PolymorphicAccess also now uses the handleExceptionGenerator thunk.
DFG::JITCompiler::compileExceptionHandlers() has one small behavior difference
before it calls operationLookupExceptionHandlerFromCallerFrame(): it first
re-sets the top of stack for the function where we are about to throw a
StackOverflowError from. This re-setting of top of stack is useless because
we're imminently unwinding out of at least this frame for the StackOverflowError.
Hence, it is ok to use the handleExceptionWithCallFrameRollbackGenerator thunk
here as well. Note that no other tiers does this re-setting of top of stack.
FTLLowerDFGToB3 has one case using operationLookupExceptionHandlerFromCallerFrame()
which cannot be refactored to use these thunks because it does additional
work to throw a StackOverflowError. A different thunk will be needed. I left
it alone for now.
2. Introduce JITThunks::existingCTIStub(ThunkGenerator, NoLockingNecessaryTag) so
that a thunk can get a pointer to another thunk without locking the JITThunks
lock. Otherwise, deadlock ensues.
3. Change SlowPathCall to emit and use thunks instead of emitting a blob of code
to call a slow path function for every bytecode in a CodeBlock.
4. Introduce JITThunks::ctiSlowPathFunctionStub() to manage these SlowPathFunction
thunks.
5. Introduce JITThunks::preinitializeAggressiveCTIThunks() to initialize these
thunks at VM initialization time. Pre-initializing them has multiple benefits:
a. the thunks are not scattered through out JIT memory, thereby reducing
fragmentation.
b. we don't spend time at runtime compiling them when the user is interacting
with the VM. Conceptually, these thunks can be VM independent and can be
shared by VMs process-wide. However, it will require some additional work.
For now, the thunks remain bound to a specific VM instance.
These changes are only enabled when ENABLE(EXTRA_CTI_THUNKS), which is currently
only available for ARM64 and non-Windows x86_64.
This patch has passed JSC tests on AS Mac.
With this patch, --dumpLinkBufferStats shows the following changes in emitted
JIT code size (using a single run of the CLI version of JetStream2 on AS Mac):
Base New Diff
BaselineJIT: 89089964 (84.962811 MB) 84624776 (80.704475 MB) 0.95x (reduction)
DFG: 39117360 (37.305222 MB) 36415264 (34.728302 MB) 0.93x (reduction)
Thunk: 23230968 (22.154778 MB) 23130336 (22.058807 MB) 1.00x
InlineCache: 22027416 (21.006981 MB) 21969728 (20.951965 MB) 1.00x
FTL: 6575772 (6.271145 MB) 6097336 (5.814873 MB) 0.93x (reduction)
Wasm: 2302724 (2.196049 MB) 2301956 (2.195316 MB) 1.00x
YarrJIT: 1538956 (1.467663 MB) 1522488 (1.451958 MB) 0.99x
CSSJIT: 0 0
Uncategorized: 0 0
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* bytecode/CodeBlock.h:
(JSC::CodeBlock::offsetOfInstructionsRawPointer):
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessGenerationState::emitExplicitExceptionHandler):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::compileExceptionHandlers):
(JSC::DFG::JITCompiler::link):
* dfg/DFGJITCompiler.h:
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
* ftl/FTLLink.cpp:
(JSC::FTL::link):
* jit/JIT.cpp:
(JSC::JIT::link):
(JSC::JIT::privateCompileExceptionHandlers):
* jit/JIT.h:
* jit/JITThunks.cpp:
(JSC::JITThunks::existingCTIStub):
(JSC::JITThunks::ctiSlowPathFunctionStub):
(JSC::JITThunks::preinitializeExtraCTIThunks):
* jit/JITThunks.h:
* jit/SlowPathCall.cpp: Added.
(JSC::JITSlowPathCall::call):
(JSC::JITSlowPathCall::generateThunk):
* jit/SlowPathCall.h:
* jit/ThunkGenerators.cpp:
(JSC::handleExceptionGenerator):
(JSC::handleExceptionWithCallFrameRollbackGenerator):
(JSC::popThunkStackPreservesAndHandleExceptionGenerator):
* jit/ThunkGenerators.h:
* runtime/CommonSlowPaths.h:
* runtime/SlowPathFunction.h: Added.
* runtime/VM.cpp:
(JSC::VM::VM):
2021-05-12 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r277346.
https://bugs.webkit.org/show_bug.cgi?id=225705
Introduced a (rare) deadlock
Reverted changeset:
"ConservativeRoots triggers page demand on Speedometer"
https://bugs.webkit.org/show_bug.cgi?id=225676
https://trac.webkit.org/changeset/277346
2021-05-12 Mark Lam <mark.lam@apple.com>
Remove dead code around ENABLE(OPCODE_SAMPLING) and ENABLE(CODEBLOCK_SAMPLING).
https://bugs.webkit.org/show_bug.cgi?id=225699
Reviewed by Tadeu Zagallo.
This code revolves around an Interpreter::sampler() method which returns a
SamplingTool*. Neither the Interpreter method nor the SamplingTool class exists
anymore.
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::compileWithoutLinking):
* jit/JIT.h:
* jit/JITCall.cpp:
(JSC::JIT::compileCallEval):
(JSC::JIT::compileCallEvalSlowCase):
(JSC::JIT::compileOpCall):
(JSC::JIT::compileOpCallSlowCase):
* jit/JITCall32_64.cpp:
(JSC::JIT::compileCallEval):
(JSC::JIT::compileCallEvalSlowCase):
(JSC::JIT::compileOpCall):
(JSC::JIT::compileOpCallSlowCase):
* jit/JITInlines.h:
(JSC::JIT::sampleInstruction): Deleted.
(JSC::JIT::sampleCodeBlock): Deleted.
* jit/JITOperations.cpp:
* jit/SlowPathCall.h:
(JSC::JITSlowPathCall::call):
* runtime/ScriptExecutable.h:
(JSC::ScriptExecutable::finishCreation): Deleted.
2021-05-11 Geoffrey Garen <ggaren@apple.com>
ConservativeRoots triggers page demand on Speedometer
https://bugs.webkit.org/show_bug.cgi?id=225676
Reviewed by Saam Barati.
Use a Vector instead of OSAllocator to avoid mmap() and page fault --
and, like, come on.
Bump default inlineCapacity up to 1024 because we seem to overflow
frequently.
* heap/ConservativeRoots.cpp:
(JSC::ConservativeRoots::ConservativeRoots):
(JSC::ConservativeRoots::~ConservativeRoots):
(JSC::ConservativeRoots::genericAddPointer):
(JSC::ConservativeRoots::grow): Deleted.
* heap/ConservativeRoots.h:
(JSC::ConservativeRoots::roots const):
(JSC::ConservativeRoots::size const): Deleted.
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::append):
* heap/VerifierSlotVisitor.cpp:
(JSC::VerifierSlotVisitor::append):
2021-05-10 Filip Pizlo <fpizlo@apple.com>
Tune number of threads for AS
https://bugs.webkit.org/show_bug.cgi?id=225635
Reviewed by Mark Lam.
Using 4 GC markers (which really means 3 parallel GC worker threads -- the mutator thread is
the 4th), 2 DFG threads, and 2 FTL threads seems to be more optimal than going off ncpu.
~1% JetStream2 speed-up, ~1% Speedometer2 speed-up.
* runtime/Options.cpp:
(JSC::overrideDefaults):
2021-05-10 Mark Lam <mark.lam@apple.com>
Removed unused CallRecord::bytecodeIndex field.
https://bugs.webkit.org/show_bug.cgi?id=225627
Reviewed by Yusuke Suzuki.
* jit/JIT.cpp:
(JSC::JIT::privateCompileExceptionHandlers):
* jit/JIT.h:
(JSC::CallRecord::CallRecord):
* jit/JITInlines.h:
(JSC::JIT::emitNakedNearCall):
(JSC::JIT::emitNakedNearTailCall):
2021-05-10 Mark Lam <mark.lam@apple.com>
Add support to collect stats on cumulative LinkBuffer linked sizes based on profiles.
https://bugs.webkit.org/show_bug.cgi?id=225617
Reviewed by Saam Barati.
There are 2 ways to dump the stats:
1. Specify --dumpLinkBufferStats as an argument to the jsc shell.
2. Call $vm.dumpLinkBufferStats() from your JS script to get the stats as a string.
e.g.
$vm.print($vm.dumpLinkBufferStats());
Here's an example of what the dump looks like:
Cummulative LinkBuffer profile sizes:
BaselineJIT: 79480320 (75.798340 MB)
DFG: 36108672 (34.435913 MB)
Thunk: 22495360 (21.453247 MB)
InlineCache: 19538521 (18.633386 MB)
FTL: 5186240 (4.945984 MB)
Wasm: 1998272 (1.905701 MB)
YarrJIT: 1331072 (1.269409 MB)
CSSJIT: 0
Uncategorized: 0
The stats are currently grouped into some coarse profiles. If needed, we can
break these down into more fine grain profiles later.
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::performFinalization):
(JSC::LinkBuffer::dumpProfileStatistics):
* assembler/LinkBuffer.h:
(JSC::LinkBuffer::LinkBuffer):
* bytecode/InlineAccess.cpp:
(JSC::linkCodeInline):
(JSC::InlineAccess::rewireStubAsJump):
* bytecode/PolymorphicAccess.cpp:
(JSC::PolymorphicAccess::regenerate):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::compile):
(JSC::DFG::JITCompiler::compileFunction):
* dfg/DFGOSRExit.cpp:
(JSC::DFG::JSC_DEFINE_JIT_OPERATION):
* dfg/DFGThunks.cpp:
(JSC::DFG::osrExitGenerationThunkGenerator):
(JSC::DFG::osrEntryThunkGenerator):
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
* ftl/FTLLazySlowPath.cpp:
(JSC::FTL::LazySlowPath::generate):
* ftl/FTLLink.cpp:
(JSC::FTL::link):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
* ftl/FTLThunks.cpp:
(JSC::FTL::genericGenerationThunkGenerator):
(JSC::FTL::slowPathCallThunkGenerator):
* jit/ExecutableAllocator.cpp:
(JSC::jitWriteThunkGenerator):
* jit/JIT.cpp:
(JSC::JIT::compileWithoutLinking):
* jit/JITMathIC.h:
(JSC::JITMathIC::generateOutOfLine):
* jit/JITOpcodes.cpp:
(JSC::JIT::privateCompileHasIndexedProperty):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::privateCompileHasIndexedProperty):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::privateCompilePutByVal):
(JSC::JIT::privateCompilePutPrivateNameWithCachedId):
(JSC::JIT::privateCompilePutByValWithCachedId):
* jit/Repatch.cpp:
(JSC::linkPolymorphicCall):
* jit/SpecializedThunkJIT.h:
(JSC::SpecializedThunkJIT::finalize):
* jit/ThunkGenerators.cpp:
(JSC::throwExceptionFromCallSlowPathGenerator):
(JSC::linkCallThunkGenerator):
(JSC::linkPolymorphicCallThunkGenerator):
(JSC::virtualThunkFor):
(JSC::nativeForGenerator):
(JSC::arityFixupGenerator):
(JSC::unreachableGenerator):
(JSC::stringGetByValGenerator):
(JSC::boundFunctionCallGenerator):
* jsc.cpp:
(CommandLine::parseArguments):
(jscmain):
* llint/LLIntThunks.cpp:
(JSC::LLInt::generateThunkWithJumpTo):
(JSC::LLInt::generateThunkWithJumpToPrologue):
(JSC::LLInt::generateThunkWithJumpToLLIntReturnPoint):
(JSC::LLInt::getHostCallReturnValueThunk):
(JSC::LLInt::createJSGateThunk):
(JSC::LLInt::createWasmGateThunk):
(JSC::LLInt::createTailCallGate):
(JSC::LLInt::loopOSREntryGateThunk):
(JSC::LLInt::entryOSREntryGateThunk):
(JSC::LLInt::wasmOSREntryGateThunk):
(JSC::LLInt::exceptionHandlerGateThunk):
(JSC::LLInt::returnFromLLIntGateThunk):
(JSC::LLInt::tagGateThunk):
(JSC::LLInt::untagGateThunk):
(JSC::LLInt::jitCagePtrThunk):
* tools/JSDollarVM.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::JSDollarVM::finishCreation):
* wasm/WasmBBQPlan.cpp:
(JSC::Wasm::BBQPlan::work):
(JSC::Wasm::BBQPlan::didCompleteCompilation):
* wasm/WasmBinding.cpp:
(JSC::Wasm::wasmToWasm):
* wasm/WasmLLIntPlan.cpp:
(JSC::Wasm::LLIntPlan::didCompleteCompilation):
* wasm/WasmOMGForOSREntryPlan.cpp:
(JSC::Wasm::OMGForOSREntryPlan::work):
* wasm/WasmOMGPlan.cpp:
(JSC::Wasm::OMGPlan::work):
* wasm/WasmThunks.cpp:
(JSC::Wasm::throwExceptionFromWasmThunkGenerator):
(JSC::Wasm::throwStackOverflowFromWasmThunkGenerator):
(JSC::Wasm::triggerOMGEntryTierUpThunkGenerator):
* wasm/js/WasmToJS.cpp:
(JSC::Wasm::wasmToJS):
* wasm/js/WebAssemblyFunction.cpp:
(JSC::WebAssemblyFunction::jsCallEntrypointSlow):
* yarr/YarrJIT.cpp:
2021-05-08 Darin Adler <darin@apple.com>
Remove calls to the String::toInt family of functions from JavaScriptCore
https://bugs.webkit.org/show_bug.cgi?id=225571
Reviewed by Sam Weinig.
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::parseLocation): Use parseIntegerAllowingTrailingJunk<JSC::SourceID>
instead of String::toIntPtr. There was no reason to parse the source ID as a
signed integer, and it's more elegant to parse the type we intend to store and
process, not a different but similar type.
(Inspector::InspectorDebuggerAgent::searchInContent): Ditto.
(Inspector::InspectorDebuggerAgent::getScriptSource): Ditto.
* inspector/agents/InspectorRuntimeAgent.cpp:
(Inspector::InspectorRuntimeAgent::getRuntimeTypesForVariablesAtOffsets): Use
parseInteger<uintptr_t> instead of String::toIntPtrStrict.
(Inspector::InspectorRuntimeAgent::getBasicBlocks): Use
parseIntegerAllowingTrailingJunk<uintptr_t> instead of String::toIntPtr.
* runtime/FuzzerPredictions.cpp:
(JSC::FuzzerPredictions::FuzzerPredictions): Use parseInteger<uint64_t>
instead of String::toUInt64Strict.
2021-05-08 Ross Kirsling <ross.kirsling@sony.com>
[JSC] Fix invalid exception checks after recent ErrorInstance changes
https://bugs.webkit.org/show_bug.cgi?id=225565
Reviewed by Alexey Shvayka.
r277221 and r277224 each introduced issues under validateExceptionChecks=1; this patch fixes them.
Of particular note:
The earlier patch sought to consolidate Error#cause logic under ErrorInstance::finishCreation.
This part must be undone as it is crucial that non-user-thrown errors be able to bypass that logic
(otherwise throwException itself would need to be exception-checked).
* runtime/AggregateError.cpp:
(JSC::createAggregateError):
* runtime/ArrayPrototype.cpp:
(JSC::getProperty):
* runtime/Error.cpp:
(JSC::createError):
(JSC::createEvalError):
(JSC::createRangeError):
(JSC::createReferenceError):
(JSC::createSyntaxError):
(JSC::createTypeError):
(JSC::createURIError):
(JSC::createGetterTypeError):
* runtime/ErrorInstance.cpp:
(JSC::ErrorInstance::create):
(JSC::ErrorInstance::finishCreation):
* runtime/ErrorInstance.h:
(JSC::ErrorInstance::create):
* runtime/JSObject.h:
* runtime/JSObjectInlines.h:
(JSC::JSObject::getIfPropertyExists):
* runtime/NullSetterFunction.cpp:
(JSC::NullSetterFunctionInternal::JSC_DEFINE_HOST_FUNCTION):
* wasm/js/JSWebAssemblyCompileError.cpp:
(JSC::createJSWebAssemblyCompileError):
* wasm/js/JSWebAssemblyLinkError.cpp:
(JSC::createJSWebAssemblyLinkError):
* wasm/js/JSWebAssemblyRuntimeError.cpp:
(JSC::createJSWebAssemblyRuntimeError):
2021-05-08 Chris Dumez <cdumez@apple.com>
Port Filesystem::pathByAppendingComponent() & Filesystem:: pathByAppendingComponents() to std::filesystem
https://bugs.webkit.org/show_bug.cgi?id=225550
Reviewed by Darin Adler.
Build fix.
* Configurations/JavaScriptCore.xcconfig:
2021-05-08 Ross Kirsling <ross.kirsling@sony.com>
Introduce JSObject::getIfPropertyExists helper
https://bugs.webkit.org/show_bug.cgi?id=225553
Reviewed by Alexey Shvayka.
Suggested by Alexey during review of r277221.
ArrayPrototype also has a "Has-guarded Get", so it's helpful for JSObject to house this functionality.
* runtime/ArrayPrototype.cpp:
(JSC::getProperty):
* runtime/ErrorInstance.cpp:
(JSC::ErrorInstance::finishCreation):
* runtime/JSObject.h:
* runtime/JSObjectInlines.h:
(JSC::JSObject::getIfPropertyExists):
2021-05-07 Ross Kirsling <ross.kirsling@sony.com>
[JSC] Error#cause must recognize explicit undefined
https://bugs.webkit.org/show_bug.cgi?id=225535
Reviewed by Alexey Shvayka.
Error#cause is specified such that `new Error(message, {})` and `new Error(message, { cause: undefined })`
are not the same -- namely, the latter should create a property descriptor with an undefined `value`.
This would seem absurd, but the reason is because the `cause` field is meant to store a thrown object,
and `throw undefined;` is valid code.
In aligning our implementation with the spec, this patch also consolidates the relevant logic in one place
(ErrorInstance::finishCreation) to minimize confusion.
* runtime/AggregateError.cpp:
(JSC::createAggregateError):
* runtime/ErrorInstance.cpp:
(JSC::ErrorInstance::create):
(JSC::ErrorInstance::finishCreation):
* runtime/ErrorInstance.h:
(JSC::ErrorInstance::create):
2021-05-06 Chris Dumez <cdumez@apple.com>
Port Filesystem::fileMetadata() & Filesystem::getFileModificationTime() to std::filesystem
https://bugs.webkit.org/show_bug.cgi?id=225362
Reviewed by Darin Adler.
Build fix.
* Configurations/JavaScriptCore.xcconfig:
2021-05-06 Eleni Maria Stea <estea@igalia.com>
Removed the assertion m_numParameters >= 0, it is always true as
m_numParameters is unsigned.
https://bugs.webkit.org/show_bug.cgi?id=225457
Reviewed by Yusuke Suzuki.
* bytecode/CodeBlock.h:
(JSC::CodeBlock::numberOfArgumentValueProfiles):
2021-05-06 Filip Pizlo <fpizlo@apple.com>
Make some things easier to dataLog in wasm
https://bugs.webkit.org/show_bug.cgi?id=225472
Reviewed by Yusuke Suzuki.
* wasm/WasmMemoryMode.cpp:
(WTF::printInternal):
* wasm/WasmMemoryMode.h:
* wasm/WasmWorklist.cpp:
(JSC::Wasm::Worklist::dump const):
* wasm/WasmWorklist.h:
2021-05-06 Filip Pizlo <fpizlo@apple.com>
Reduce use of dmb ish on ARM64
https://bugs.webkit.org/show_bug.cgi?id=225465
Reviewed by Keith Miller.
We use loadLoadFence a lot, often in situations like:
Foo* ptr = loadStuff;
loadLoadFence();
use ptr
On ARM64, we don't need a dmb ish here. This introduces a dependentLoadLoadFence() for these
cases; it's just a compiler fence on ARM64 and Intel.
We also used loadLoadFence in some places where I couldn't think of any good reason for the
fence other than paranoia. I got rid of those.
* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::computeFromCallLinkInfo):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::jitType const):
* bytecode/ObjectAllocationProfile.h:
(JSC::ObjectAllocationProfileBase::structure):
(JSC::ObjectAllocationProfileWithPrototype::prototype):
* bytecode/Watchpoint.h:
(JSC::WatchpointSet::state const):
(JSC::InlineWatchpointSet::state const):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::handlePutByVal):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileGetByValOnString):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
* runtime/GetterSetter.h:
* runtime/InferredValue.h:
(JSC::InferredValue::state const):
* runtime/Structure.h:
(JSC::Structure::tryRareData):
* runtime/StructureInlines.h:
(JSC::Structure::propertyReplacementWatchpointSet):
2021-05-06 Filip Pizlo <fpizlo@apple.com>
It should be possible to --logJIT=true
https://bugs.webkit.org/show_bug.cgi?id=225464
Reviewed by Mark Lam.
This makes it easy to just log when JITing happens. It's like --dumpDisassembly=true but
without the disassembly.
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::finalizeCodeWithDisassemblyImpl):
* assembler/LinkBuffer.h:
* runtime/Options.cpp:
(JSC::Options::recomputeDependentOptions):
* runtime/OptionsList.h:
2021-05-06 Mark Lam <mark.lam@apple.com>
Forbid further execution in jsc shell if execution is terminated.
https://bugs.webkit.org/show_bug.cgi?id=225410
rdar://77548608
Reviewed by Michael Saboff.
1. Introduce a VM::m_executionForbidden flag.
2. In the jsc shell, forbid further execution if termination was encountered.
* jsc.cpp:
(runWithOptions):
* runtime/VM.cpp:
(JSC::VM::drainMicrotasks):
* runtime/VM.h:
(JSC::VM::executionForbidden const):
(JSC::VM::setExecutionForbidden):
2021-05-06 Mark Lam <mark.lam@apple.com>
Fix missing exception check in objectConstructorGetOwnPropertyDescriptors().
https://bugs.webkit.org/show_bug.cgi?id=225413
rdar://77551530
Reviewed by Michael Saboff.
Need to handle TerminationException.
* runtime/ObjectConstructor.cpp:
(JSC::objectConstructorGetOwnPropertyDescriptors):
2021-05-05 Mark Lam <mark.lam@apple.com>
Introduce VM::hasPendingTerminationException() to make code a little more terse.
https://bugs.webkit.org/show_bug.cgi?id=225412
Reviewed by Michael Saboff.
This is purely a refactoring patch. There is no behavior change.
* interpreter/Interpreter.cpp:
(JSC::Interpreter::executeProgram):
* jit/JITOperations.cpp:
* runtime/ExceptionScope.h:
(JSC::ExceptionScope::assertNoExceptionExceptTermination):
(JSC::ExceptionScope::releaseAssertNoExceptionExceptTermination):
* runtime/JSObject.h:
(JSC::JSObject::get const):
* runtime/LazyPropertyInlines.h:
(JSC::ElementType>::callFunc):
* runtime/VM.cpp:
(JSC::VM::throwException):
* runtime/VM.h:
(JSC::VM::hasPendingTerminationException const):
* runtime/VMTraps.cpp:
(JSC::VMTraps::deferTerminationSlow):
2021-05-05 Mark Lam <mark.lam@apple.com>
Enable incremental sweeping of GCAwareJITStubRoutines.
https://bugs.webkit.org/show_bug.cgi?id=225376
Reviewed by Filip Pizlo.
This patch makes the following changes:
1. Enhance JITStubRoutineSet::deleteUnmarkedJettisonedStubRoutines() to be able to
run in an incremental time slice.
2. Added JITStubRoutineSet::notifyHaveRoutinesToDelete() so that
GCAwareJITStubRoutine::observeZeroRefCount() can flag that the GC may have
some dead GCAwareJITStubRoutines to delete.
3. Added JITStubRoutineSet::mayHaveRoutinesToDelete() so that clients can do
a cheap check ahead of time to determine if there's work to do, and avoid
calling JITStubRoutineSet::deleteUnmarkedJettisonedStubRoutines() altogether
if not needed.
4. Added Heap::mayHaveJITStubRoutinesToDelete() and Heap::deleteDeadJITStubRoutines()
as wrappers around JITStubRoutineSet::mayHaveRoutinesToDelete() and
JITStubRoutineSet::deleteUnmarkedJettisonedStubRoutines() because the use of
the JITStubRoutineSet is a heap internal implementation detail.
5. Enhanced the IncrementalSweeper to also call Heap::deleteDeadJITStubRoutines()
if needed.
6. Enhanced Heap::sweepSynchronously() to also call Heap::deleteDeadJITStubRoutines()
if needed.
7. Time slices for Heap::deleteDeadJITStubRoutines() is currently set at the
current values:
a. max of 1 ms (1/10 of the IncreamentalSweeper's time slice) when invoked from
the IncreamentalSweeper.
b. max of 5 ms when invoked from Heap::deleteUnmarkedCompiledCode().
c. unlimited time (with a sanity check) when called from Heap::sweepSynchronously().
The choices of 1ms and 5ms were picked to not be too long, but would still delete
the bulk of the dead GCAwareJITStubRoutines quickly enough based on data from my
instrumented runs the CLI version of JetStream2.
I think these hardcoded values will do for now. If need be, we can try something
more sophisticated later.
* CMakeLists.txt:
* heap/Heap.cpp:
(JSC::Heap::deleteUnmarkedCompiledCode):
(JSC::Heap::sweepSynchronously):
* heap/Heap.h:
* heap/HeapInlines.h:
(JSC::Heap::mayHaveJITStubRoutinesToDelete):
(JSC::Heap::deleteDeadJITStubRoutines):
* heap/IncrementalSweeper.cpp:
(JSC::IncrementalSweeper::doSweep):
* heap/JITStubRoutineSet.cpp:
(JSC::JITStubRoutineSet::deleteUnmarkedJettisonedStubRoutines):
* heap/JITStubRoutineSet.h:
(JSC::JITStubRoutineSet::mayHaveRoutinesToDelete):
(JSC::JITStubRoutineSet::notifyHaveRoutinesToDelete):
(JSC::JITStubRoutineSet::deleteUnmarkedJettisonedStubRoutines):
* jit/GCAwareJITStubRoutine.cpp:
(JSC::GCAwareJITStubRoutine::observeZeroRefCount):
* jit/JITStubRoutine.h:
(JSC::JITStubRoutine::createSelfManagedRoutine): Deleted.
2021-05-03 Mark Lam <mark.lam@apple.com>
Fix syntax error message for AUTOPLUSPLUS token.
https://bugs.webkit.org/show_bug.cgi?id=225308
rdar://76830934
Reviewed by Saam Barati.
For the record, it's not easy to tell from the code why AUTOPLUSPLUS is needed.
It's needed to distinguish this:
```
statement ++ stuff // ++ is a postfix operator applied to `statement`.
```
from this:
```
statement
++stuff // The `\n` before the ++ makes it a prefix operator applied to `stuff``.
```
If we merely tokenize the ++ as a PLUSPLUS token, then it's unclear whether it acts
as a postfix or prefix token in the 2nd case above.
This is why the correct fix is not to get rid of the AUTOPLUSPLUS token, but to
teach the syntax error message to be aware of the AUTOPLUSPLUS token.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseUnaryExpression):
2021-05-03 Chris Dumez <cdumez@apple.com>
Restore pre-r276879 behavior for FileSystem::deleteFile() and FileSystem::deleteEmptyDirectory()
https://bugs.webkit.org/show_bug.cgi?id=225289
Reviewed by Darin Adler.
Fix build.
* Configurations/JavaScriptCore.xcconfig:
2021-05-03 Mark Lam <mark.lam@apple.com>
Add some missing exception checks before some jsCasts.
https://bugs.webkit.org/show_bug.cgi?id=225264
rdar://77381608
Reviewed by Saam Barati.
Introducing JSObject::getAs() and JSValue::getAs() convenience methods that will
check for an exception before doing a jsCast on the get result. We only need this
to placate the assertion in jsCast in the event a pending exception exists at the
time of the jsCast. If ASSERTs are not enabled, this will be a no-op. All clients
that use jsCast this way (and now use getAs instead) will already be doing an
exception check immediately after. Hence, they are already doing the right thing
in terms of handling exceptions. We're only placating the jsCast assertion here.
* runtime/AbstractModuleRecord.cpp:
(JSC::AbstractModuleRecord::hostResolveImportedModule):
* runtime/JSCJSValue.h:
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::getAs const):
* runtime/JSInternalPromise.cpp:
(JSC::JSInternalPromise::then):
* runtime/JSModuleLoader.cpp:
(JSC::JSModuleLoader::dependencyKeysIfEvaluated):
(JSC::JSModuleLoader::provideFetch):
(JSC::JSModuleLoader::loadAndEvaluateModule):
(JSC::JSModuleLoader::loadModule):
(JSC::JSModuleLoader::linkAndEvaluateModule):
(JSC::JSModuleLoader::requestImportModule):
* runtime/JSObject.h:
(JSC::JSObject::getAs const):
* runtime/JSPromise.cpp:
(JSC::JSPromise::createDeferredData):
* runtime/VM.h:
2021-05-03 Dmitry Bezhetskov <dbezhetskov@igalia.com>
[WASM-Function-References] Add call_ref instruction
https://bugs.webkit.org/show_bug.cgi?id=222903
Reviewed by Yusuke Suzuki.
Add support for call_ref instruction from the typed function
references proposal: https://github.com/WebAssembly/function-references/blob/master/proposals/function-references/Overview.md.
call_ref calls the given function references from the stack
and it does almost the same stuff as call_indirect but
it doesn't check signatures because wasm types system guaranties
correctness.
* bytecode/BytecodeList.rb:
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* llint/LowLevelInterpreter.asm:
* llint/WebAssembly.asm:
* runtime/Gate.h:
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::addCallIndirect):
(JSC::Wasm::AirIRGenerator::addCallRef):
(JSC::Wasm::AirIRGenerator::emitIndirectCall):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::emitIndirectCall):
(JSC::Wasm::B3IRGenerator::addCallIndirect):
(JSC::Wasm::B3IRGenerator::addCallRef):
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseExpression):
(JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
* wasm/WasmLLIntGenerator.cpp:
(JSC::Wasm::LLIntGenerator::addCallRef):
* wasm/WasmSlowPaths.cpp:
(JSC::LLInt::doWasmCallRef):
(JSC::LLInt::WASM_SLOW_PATH_DECL):
* wasm/WasmSlowPaths.h:
* wasm/js/JSWebAssemblyTable.cpp:
* wasm/js/WebAssemblyFunction.cpp:
(JSC::WebAssemblyFunction::WebAssemblyFunction):
* wasm/js/WebAssemblyFunction.h:
* wasm/js/WebAssemblyFunctionBase.cpp:
(JSC::WebAssemblyFunctionBase::WebAssemblyFunctionBase):
* wasm/js/WebAssemblyFunctionBase.h:
(JSC::WebAssemblyFunctionBase::offsetOfEntrypointLoadLocation):
* wasm/js/WebAssemblyWrapperFunction.cpp:
(JSC::WebAssemblyWrapperFunction::WebAssemblyWrapperFunction):
* wasm/js/WebAssemblyWrapperFunction.h:
* wasm/wasm.json:
2021-05-01 Chris Dumez <cdumez@apple.com>
Start leveraging std::filesystem in WTF::FileSystem
https://bugs.webkit.org/show_bug.cgi?id=225255
Reviewed by Sam Weinig.
Unexport some symbols to fix build.
* Configurations/JavaScriptCore.xcconfig:
2021-04-30 Filip Pizlo <fpizlo@apple.com>
Make small JIT pool tests pass on AS
https://bugs.webkit.org/show_bug.cgi?id=225256
Reviewed by Mark Lam.
If we ask for a JIT pool that is smaller than the smallest possible "region" (thing with jump
island) that we can create -- i.e. smaller than a jump region, then assume that the user is
asking us to create a pool that has that much usable space plus a jump region.
I think that this makes the option easier to use when you're testing ridiculously small JIT
pools, which we happen to do in our test suite.
Also remove some dead options I didn't mean to commit.
* jit/ExecutableAllocator.cpp:
(JSC::initializeJITPageReservation):
* runtime/OptionsList.h:
2021-04-30 Filip Pizlo <fpizlo@apple.com>
Make the JIT pool smaller on AS
https://bugs.webkit.org/show_bug.cgi?id=225249
Reviewed by Saam Barati.
This adds three related features:
- Makes it easy to dump where the JIT pool was allocated.
- Makes it possible to override the JIT pool size with Options even with jump islands.
- Changes the default JIT pool size on AS to 512MB.
Estimated 2% speed-up on JetStream2, 1.5% speed-up on Speedometer2.
* jit/ExecutableAllocator.cpp:
(JSC::initializeJITPageReservation):
* runtime/OptionsList.h:
2021-04-29 Saam Barati <sbarati@apple.com>
Inlining property accesses inside constant folding should check Options::useAccessInlining
https://bugs.webkit.org/show_bug.cgi?id=225194
Reviewed by Mark Lam.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
(JSC::DFG::ConstantFoldingPhase::tryFoldAsPutByOffset):
2021-04-29 Saam Barati <sbarati@apple.com>
Sampling profiler should dump a tier breakdown, and add ability to see time spent in C code with sampleCCode=0, and fix bugs with frames having the wrong jitType if they're inlined
https://bugs.webkit.org/show_bug.cgi?id=225116
Reviewed by Yusuke Suzuki.
This patch makes it so we also dump time spent in each tier when dumping top
bytecodes. This can be helpful info when analyzing benchmarks.
This patch also makes it so we know when we're in C/C++ code when we're not
using the sampleCCode=true option. I found some weird performance pathologies
with that option that cause us to not sample code at all. I was seeing ~50
samples taken for ~7 seconds of code running time. It's worth figuring out
what's going on there eventually. But for now, I've made it so that we
recognize that the top frame is C/C++ when using the collectExtraSamplingProfilerData=1
option.
This patch also fixes a bug where we mis-attribute JITTypes for inline
frames. We'd attribute it to whatever the CodeBlock was compiled as, instead
of using the machine frame's JITType.
* jsc.cpp:
(CommandLine::parseArguments):
* runtime/OptionsList.h:
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::takeSample):
(JSC::SamplingProfiler::processUnverifiedStackTraces):
(JSC::SamplingProfiler::StackFrame::displayName):
(JSC::SamplingProfiler::reportTopBytecodes):
2021-04-28 Mark Lam <mark.lam@apple.com>
Fix exception assertions in light of the TerminationException.
https://bugs.webkit.org/show_bug.cgi?id=225128
rdar://76694909
Reviewed by Robin Morisset.
Some pre-existing functions assertNoException() or releaseAssertNoException().
These assertion may not be valid anymore in light of the TerminationException, and
require some fix up:
1. If it makes sense to convert the assertion into an exception check, then do so.
For example, see objectPrototypeToString(), slow_path_create_this().
2. If the assertion is at the end of a function just before it returns, or if the
remaining code in the function will not be affected by the pending exception,
then we can replace the assertion as follows:
assertNoException() => assertNoExceptionExceptTermination()
releaseAssertNoException() => releaseAssertNoExceptionExceptTermination()
For example, see objectPrototypeHasOwnProperty(), JSObject::getOwnNonIndexPropertyNames().
3. If the assertion is in a function where perf is not absolutely critical, and the
function isn't calling any other functions that will re-enter the VM or potentially
get stuck in an infinite loop, then we can use a DeferTermination scope to defer
termination.
For example, see Debugger::pauseIfNeeded(), SamplingProfiler::StackFrame::nameFromCallee().
4. If the assertion is in an initializer function is only run once and adding
exception checks would complicate the code more than it's worth (an engineering
judgement), then use a DeferTermination scope.
For example, see ProgramExecutable::initializeGlobalProperties(), setupAdaptiveWatchpoint().
Some leaf (or near-leaf) functions that currently DECLARE_CATCH_SCOPE() may also
fall under this category.
For example, see JSFunction::prototypeForConstruction().
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::addBigIntConstant):
* debugger/Debugger.cpp:
(JSC::Debugger::pauseIfNeeded):
* dfg/DFGOperations.cpp:
(JSC::DFG::JSC_DEFINE_JIT_OPERATION):
* interpreter/Interpreter.cpp:
(JSC::notifyDebuggerOfUnwinding):
(JSC::Interpreter::executeProgram):
(JSC::Interpreter::debug):
* interpreter/ShadowChicken.cpp:
(JSC::ShadowChicken::functionsOnStack):
* jsc.cpp:
(runWithOptions):
* parser/ParserArena.cpp:
(JSC::IdentifierArena::makeBigIntDecimalIdentifier):
* runtime/AbstractModuleRecord.cpp:
(JSC::AbstractModuleRecord::finishCreation):
* runtime/CommonSlowPaths.cpp:
(JSC::JSC_DEFINE_COMMON_SLOW_PATH):
* runtime/ErrorInstance.cpp:
(JSC::ErrorInstance::sanitizedMessageString):
(JSC::ErrorInstance::sanitizedNameString):
* runtime/ExceptionScope.h:
(JSC::ExceptionScope::assertNoExceptionExceptTermination):
(JSC::ExceptionScope::releaseAssertNoExceptionExceptTermination):
* runtime/JSFunction.cpp:
(JSC::JSFunction::prototypeForConstruction):
* runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
(JSC::genericTypedArrayViewProtoFuncIncludes):
(JSC::genericTypedArrayViewProtoFuncIndexOf):
(JSC::genericTypedArrayViewProtoFuncLastIndexOf):
(JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
* runtime/JSGlobalObject.cpp:
(JSC::setupAdaptiveWatchpoint):
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::defineOwnProperty):
(JSC::JSGlobalObject::tryInstallSpeciesWatchpoint):
* runtime/JSModuleLoader.cpp:
(JSC::printableModuleKey):
* runtime/JSModuleNamespaceObject.cpp:
(JSC::JSModuleNamespaceObject::finishCreation):
* runtime/JSObject.cpp:
(JSC::JSObject::ordinaryToPrimitive const):
(JSC::JSObject::getOwnNonIndexPropertyNames):
* runtime/JSTemplateObjectDescriptor.cpp:
(JSC::JSTemplateObjectDescriptor::createTemplateObject):
* runtime/JSTypedArrayViewPrototype.cpp:
* runtime/ObjectPrototype.cpp:
(JSC::objectPrototypeHasOwnProperty):
(JSC::objectPrototypeToString):
* runtime/ProgramExecutable.cpp:
(JSC::ProgramExecutable::initializeGlobalProperties):
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::StackFrame::nameFromCallee):
* tools/JSDollarVM.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
2021-04-28 Daniel Kolesa <dkolesa@igalia.com>
[WPE][GTK] More correct fixes for stack size issues on musl libc
https://bugs.webkit.org/show_bug.cgi?id=225099
Reviewed by Adrian Perez de Castro.
Partial revert https://bugs.webkit.org/show_bug.cgi?id=210068
After fixing the thread stack issues in WTF properly, we can revert
the JSC options changes, which are actually harmful since they result
in JSC being unstable. Previously, softReservedZoneSize was causing a
crash when set to 128K because of the main thread stack bounds, and
this is now fixed. We can keep the maxPerThreadStackUsage at 5M as
well; there is no fundamental difference from how things are done on
glibc anymore.
* runtime/OptionsList.h:
2021-04-27 Filip Pizlo <fpizlo@apple.com>
Get the bytecode profiler working again
https://bugs.webkit.org/show_bug.cgi?id=225129
Reviewed by Saam Barati.
The bytecode profiler was broken because it was trying to look at unset labels. This patch
improves our label discipline a bit so we don't try to look at unset labels.
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::linkOSRExits):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::emitInvalidationPoint):
2021-04-27 Mark Lam <mark.lam@apple.com>
Move ExceptionExpectation into its own .h file.
https://bugs.webkit.org/show_bug.cgi?id=225124
Reviewed by Robin Morisset.
Also fixed some compiler warnings.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* runtime/ExceptionExpectation.h: Added.
* runtime/ExceptionHelpers.h:
* runtime/HashMapImplInlines.h:
(JSC::jsMapHashImpl):
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::setWithSpecificType):
(JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlotByIndex):
2021-04-27 Alexey Shvayka <shvaikalesh@gmail.com>
[JSC] Remove defaultValue() from the method table
https://bugs.webkit.org/show_bug.cgi?id=225032
Reviewed by Darin Adler.
This patch not only removes the unnecessary method table entry, but also makes
the presence of custom ToPrimitive behavior observable to userland code.
To maintain object identity and (possibly) enable caching, Symbol.toPrimitive
method is stored on a structure. To avoid any potential breakage, it's made
replaceable and configurable, covering the case when its holder is a [[ProxyTarget]].
For JSCallbackObject, Symbol.toPrimitive method is created only if ConvertToType
callback is present, before initialization is performed.
Also, this change adds additional ordinaryToPrimitive() cast to fix the invariant
that toPrimitive() returns a primitive value, which was broken if ConvertToType
callback returned an object. The invariant is enforced by the spec [1][2] and is
validated via assertion in JSValue::toStringSlowCase().
[1]: https://tc39.es/ecma262/#sec-toprimitive (step 2.b.vi)
[2]: https://tc39.es/ecma262/#sec-ordinarytoprimitive (step 6)
* API/JSCallbackObject.h:
* API/JSCallbackObjectFunctions.h:
(JSC::JSCallbackObject<Parent>::init):
(JSC::JSCallbackObject<Parent>::customToPrimitive):
(JSC::JSCallbackObject<Parent>::defaultValue): Deleted.
* API/tests/testapiScripts/testapi.js:
* runtime/ClassInfo.h:
* runtime/JSCell.cpp:
(JSC::JSCell::defaultValue): Deleted.
* runtime/JSCell.h:
* runtime/JSObject.cpp:
(JSC::JSObject::toPrimitive const):
(JSC::JSObject::defaultValue): Deleted.
* runtime/JSObject.h:
* runtime/Operations.cpp:
(JSC::jsAddSlowCase):
2021-04-27 Keith Miller <keith_miller@apple.com>
StructureStubInfo and PolymorphicAccess should account for their non-GC memory
https://bugs.webkit.org/show_bug.cgi?id=225113
Reviewed by Mark Lam.
We don't pass the ConcurrentJSLocker to the helper methods here since the
DECLARE_VISIT_AGGREGATE macro does not allow for extra parameters to be passed.
I filed https://bugs.webkit.org/show_bug.cgi?id=225114 to track that.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::JITData::size const):
* bytecode/PolymorphicAccess.cpp:
(JSC::PolymorphicAccess::extraMemoryInBytes const):
* bytecode/PolymorphicAccess.h:
* bytecode/StructureStubInfo.cpp:
(JSC::StructureStubInfo::extraMemoryInBytes):
* bytecode/StructureStubInfo.h:
2021-04-26 Keith Miller <keith_miller@apple.com>
UnlinkedCodeBlock should have better accounting for extra memory
https://bugs.webkit.org/show_bug.cgi?id=225080
Reviewed by Mark Lam.
Right now we aren't telling the JS GC about the extra memory
attached to UnlinkedCodeBlocks. It looks like on at least some sites this
can be a fairly large percentage of the total memory retained by
the JS object graph. This is very similar to the change we made for
CodeBlocks in r276610.
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::visitChildrenImpl):
(JSC::UnlinkedCodeBlock::RareData::sizeInBytes const):
* bytecode/UnlinkedCodeBlock.h:
2021-04-26 Alex Christensen <achristensen@webkit.org>
Update Mac-specific CMake files
https://bugs.webkit.org/show_bug.cgi?id=225064
Rubber-stamped by Tim Horton.
* PlatformMac.cmake:
2021-04-26 Mark Lam <mark.lam@apple.com>
%TypedArray%.prototype.sort() should not use a regular array as a temp buffer.
https://bugs.webkit.org/show_bug.cgi?id=225062
rdar://77021547
Reviewed by Yusuke Suzuki.
%TypedArray%.prototype.sort() should not be affected by property changes in
Array.prototype.
References:
[1] https://tc39.es/ecma262/#sec-%typedarray%.prototype.sort
[2] https://tc39.es/ecma262/#sec-array.prototype.sort
[3] https://tc39.es/ecma262/#sec-sortcompare
* builtins/TypedArrayPrototype.js:
(globalPrivate.typedArrayMergeSort):
2021-04-26 Keith Miller <keith_miller@apple.com>
CodeBlock should do a better job accounting for extra memory it allocates.
https://bugs.webkit.org/show_bug.cgi?id=225068
Reviewed by Mark Lam.
Right now we aren't telling the JS GC about the extra memory
attached to CodeBlocks. It looks like on at least some sites this
can be a fairly large percentage of the total memory retained by
the JS object graph.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::visitChildren):
(JSC::CodeBlock::JITData::size const):
* bytecode/CodeBlock.h:
* jit/JITCodeMap.h:
(JSC::JITCodeMap::memorySize const):
2021-04-26 Keith Miller <keith_miller@apple.com>
numCalleeLocals, numParameters, and numVars should be unsigned
https://bugs.webkit.org/show_bug.cgi?id=224995
Reviewed by Mark Lam.
All of the various CodeBlock classes currently have the
numCalleeLocals and numVars marked as ints. I believe this is just
a historical artifact or because VirtualRegister's offset is an
int to make handling constants easier. Regardless, it's a bit
strange to not handle the sign conversion at the point of
comparison between a VirtualRegister offset and the local/var
count. This doesn't completely fix every place we use ints for
these values but starts on the right track. Lastly, I also added
some Check<unsigned>s to the wasm parser for sanity checking.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::setNumParameters):
(JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeIndexSlow):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::numParameters const):
(JSC::CodeBlock::numberOfArgumentsToSkip const):
(JSC::CodeBlock::numCalleeLocals const):
(JSC::CodeBlock::numVars const):
(JSC::CodeBlock::numTmps const):
(JSC::CodeBlock::addressOfNumParameters):
(JSC::CodeBlock::isTemporaryRegister):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::numCalleeLocals const):
(JSC::UnlinkedCodeBlock::numVars const):
* bytecode/UnlinkedCodeBlockGenerator.h:
(JSC::UnlinkedCodeBlockGenerator::numCalleeLocals const):
(JSC::UnlinkedCodeBlockGenerator::numVars const):
(JSC::UnlinkedCodeBlockGenerator::setNumCalleeLocals):
(JSC::UnlinkedCodeBlockGenerator::setNumVars):
(JSC::UnlinkedCodeBlockGenerator::setNumParameters):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::generate):
(JSC::BytecodeGenerator::emitPushFunctionNameScope):
* bytecompiler/BytecodeGeneratorBaseInlines.h:
(JSC::BytecodeGeneratorBase<Traits>::newRegister):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleRecursiveTailCall):
(JSC::DFG::ByteCodeParser::inliningCost):
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGOSREntrypointCreationPhase.cpp:
(JSC::DFG::OSREntrypointCreationPhase::run):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::checkArgumentTypes):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::lower):
* ftl/FTLOSREntry.cpp:
(JSC::FTL::prepareOSREntry):
* interpreter/CallFrameClosure.h:
* interpreter/ProtoCallFrameInlines.h:
(JSC::ProtoCallFrame::init):
* jit/JIT.cpp:
(JSC::JIT::compileWithoutLinking):
* runtime/CommonSlowPaths.h:
(JSC::CommonSlowPaths::numberOfStackPaddingSlots):
(JSC::CommonSlowPaths::numberOfStackPaddingSlotsWithExtraSlots):
* wasm/WasmFunctionCodeBlock.h:
(JSC::Wasm::FunctionCodeBlock::numVars const):
(JSC::Wasm::FunctionCodeBlock::numCalleeLocals const):
(JSC::Wasm::FunctionCodeBlock::setNumVars):
(JSC::Wasm::FunctionCodeBlock::setNumCalleeLocals):
* wasm/WasmLLIntGenerator.cpp:
(JSC::Wasm::LLIntGenerator::push):
(JSC::Wasm::LLIntGenerator::getDropKeepCount):
(JSC::Wasm::LLIntGenerator::walkExpressionStack):
(JSC::Wasm::LLIntGenerator::checkConsistency):
(JSC::Wasm::LLIntGenerator::materializeConstantsAndLocals):
(JSC::Wasm::LLIntGenerator::splitStack):
(JSC::Wasm::LLIntGenerator::finalize):
(JSC::Wasm::LLIntGenerator::callInformationForCaller):
(JSC::Wasm::LLIntGenerator::addLoop):
(JSC::Wasm::LLIntGenerator::addTopLevel):
(JSC::Wasm::LLIntGenerator::addBlock):
(JSC::Wasm::LLIntGenerator::addIf):
(JSC::Wasm::LLIntGenerator::addElseToUnreachable):
2021-04-26 Alexey Shvayka <shvaikalesh@gmail.com>
[JSC] OrdinarySet should invoke custom [[Set]] methods
https://bugs.webkit.org/show_bug.cgi?id=217916
Reviewed by Yusuke Suzuki.
This patch fixes putInlineSlow() to handle special properties (like JSFunction's "name"
and JSArray's "length") in prototype chain. When such property is encountered, prototype
chain traversal is stopped; if it's read-only, a TypeError is thrown in strict mode.
This change adds OverridesPut out of line type info flag, and utilizes it in putInlineSlow()
to invoke overriden methods. While this approach requires put() methods to be aware of
altered receivers, it renders several benefits:
1. put() method can be used for both "real" [[Set]] overrides and special properties,
with its return value remaining `bool`;
2. it is simpler, faster, and more predictable than calling [[GetOwnProperty]] in
putInlineSlow() or adding defineOwnPropertyViaPut() to the method table.
Removes ordinarySetSlow() for non-index properties, which didn't invoke some [[Set]]
methods as well. Instead, definePropertyOnReceiver() is introduced for altered receivers,
which performs correctly when reached because:
1. all special properties were already handled (unless it's Reflect.set);
2. performing putDirectInternal() is unobservable (unless ProxyObject was seen);
3. putDirectInternal() now fully implements property definition of OrdinarySet [1];
4. put() override is required if a spec defines custom [[DefineOwnProperty]].
Since indexed puts handle overrides / altered receivers quite differently, they will
be fixed in a follow-up, completely removing ordinarySetSlow().
Also, by merging putEntry() / putToPrimitive() into putInlineSlow() and introducing
putInlineFastReplacingStaticPropertyIfNeeded() helper, this patch fixes a few bugs:
1. Direct [[Set]] to non-reified static property now preserves its attributes when replacing [[Value]].
2. Prototype chain [[Set]] to non-reified static property now throws if receiver is non-extensible.
3. Non-reified static writable property now shadows read-only one that is further in prototype chain.
4. Non-reified static properties in prototype chain of a primitive are now considered.
Fixes a few issues that were previously unobservable:
1. PropertyAttribute::CustomValue is now unset when a setter-less property is reassigned.
2. uint64_t putByIndexInline() now calls put() via method table like uint32_t counterpart.
Other notable refactors:
1. Inlines callCustomSetter(), dropping weird TriState return value.
2. Simplifies initialization of StringPrototype.
3. Simplifies isThisValueAltered() to pointer comparisons at non-JSProxy call sites.
4. Removes doPutPropertySecurityCheck() methods as the same checks are performed by put() methods.
5. Removes prototypeChainMayInterceptStoreTo(), which pretty much duplicated canPerformFastPutInline().
6. Removes dummy JSArrayBufferView::put() method.
7. Removes now unused lookupPut().
Aligns JSC with V8 and SpiderMonkey.
This patch carefully preserves the current behavior of Reflect.set with CustomValue
and prototype chain [[Set]] to a JSCallbackObject / legacy platform object.
This change is performance-neutral on /put/ microbenchmarks as it doesn't affect
caching, only the slow path. Reflect.set with JSFinalObject receiver is 130% faster.
putInlineSlow() microbenchmarks progress by 4-18%.
[1]: https://tc39.es/ecma262/#sec-ordinarysetwithowndescriptor (step 3)
* API/JSCallbackObject.h:
* API/JSCallbackObjectFunctions.h:
(JSC::JSCallbackObject<Parent>::put):
* API/tests/testapiScripts/testapi.js:
* debugger/DebuggerScope.h:
* runtime/ClassInfo.h:
* runtime/ClonedArguments.h:
* runtime/CustomGetterSetter.cpp:
(JSC::callCustomSetter): Deleted.
* runtime/CustomGetterSetter.h:
* runtime/ErrorConstructor.h:
* runtime/ErrorInstance.h:
* runtime/GenericArguments.h:
* runtime/GenericArgumentsInlines.h:
(JSC::GenericArguments<Type>::put):
* runtime/GetterSetter.h:
* runtime/JSArray.cpp:
(JSC::JSArray::put):
* runtime/JSArray.h:
* runtime/JSArrayBufferView.cpp:
(JSC::JSArrayBufferView::put): Deleted.
* runtime/JSArrayBufferView.h:
* runtime/JSCJSValue.cpp:
(JSC::JSValue::putToPrimitive):
* runtime/JSCell.cpp:
(JSC::JSCell::doPutPropertySecurityCheck): Deleted.
* runtime/JSCell.h:
* runtime/JSFunction.cpp:
(JSC::JSFunction::put):
* runtime/JSFunction.h:
* runtime/JSGenericTypedArrayView.h:
* runtime/JSGlobalLexicalEnvironment.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::put):
* runtime/JSGlobalObject.h:
* runtime/JSLexicalEnvironment.h:
* runtime/JSModuleEnvironment.h:
* runtime/JSModuleNamespaceObject.h:
* runtime/JSObject.cpp:
(JSC::JSObject::getOwnPropertySlot):
(JSC::JSObject::putInlineSlow):
(JSC::definePropertyOnReceiverSlow):
(JSC::JSObject::definePropertyOnReceiver):
(JSC::JSObject::putInlineFastReplacingStaticPropertyIfNeeded):
(JSC::JSObject::doPutPropertySecurityCheck): Deleted.
(JSC::JSObject::prototypeChainMayInterceptStoreTo): Deleted.
* runtime/JSObject.h:
(JSC::JSObject::putByIndexInline):
(JSC::JSObject::hasNonReifiedStaticProperties):
(JSC::JSObject::getOwnPropertySlot):
(JSC::JSObject::putDirect):
(JSC::JSObject::doPutPropertySecurityCheck): Deleted.
* runtime/JSObjectInlines.h:
(JSC::JSObject::canPerformFastPutInlineExcludingProto):
(JSC::JSObject::putInlineForJSObject):
(JSC::JSObject::putInlineFast):
(JSC::JSObject::putDirectInternal):
* runtime/JSProxy.h:
* runtime/JSTypeInfo.h:
(JSC::TypeInfo::hasStaticPropertyTable const):
(JSC::TypeInfo::overridesPut const):
(JSC::TypeInfo::getOwnPropertySlotMayBeWrongAboutDontEnum const):
(JSC::TypeInfo::hasPutPropertySecurityCheck const): Deleted.
* runtime/Lookup.h:
(JSC::putEntry): Deleted.
(JSC::lookupPut): Deleted.
* runtime/PropertySlot.h:
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::put):
* runtime/ProxyObject.h:
* runtime/PutPropertySlot.h:
(JSC::PutPropertySlot::PutPropertySlot):
(JSC::PutPropertySlot::context const):
(JSC::PutPropertySlot::isTaintedByOpaqueObject const):
(JSC::PutPropertySlot::setIsTaintedByOpaqueObject):
* runtime/ReflectObject.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/RegExpObject.cpp:
(JSC::RegExpObject::put):
* runtime/RegExpObject.h:
* runtime/StringObject.cpp:
(JSC::StringObject::put):
* runtime/StringObject.h:
* runtime/StringPrototype.cpp:
(JSC::StringPrototype::finishCreation):
(JSC::StringPrototype::create):
* runtime/StringPrototype.h:
* runtime/Structure.cpp:
(JSC::Structure::validateFlags):
* runtime/Structure.h:
(JSC::Structure::hasNonReifiedStaticProperties const):
* tools/JSDollarVM.cpp:
2021-04-23 Michael Saboff <msaboff@apple.com>
[YARR Interpreter] Improper backtrack of parentheses with non-zero based greedy quantifiers
https://bugs.webkit.org/show_bug.cgi?id=224983
Reviewed by Mark Lam.
When we backtrack a parentheses with a greedy non zero based quantifier,
we don't properly restore for the case where we hadn't reached the minimum count.
We now save the input position on entry and restore it when we backtrack for
this case. We also properly release the allocated ParenthesesDisjunctionContext's.
* yarr/YarrInterpreter.cpp:
(JSC::Yarr::Interpreter::matchParentheses):
(JSC::Yarr::Interpreter::backtrackParentheses):
2021-04-23 Mark Lam <mark.lam@apple.com>
Fix B3 strength reduction for shl.
https://bugs.webkit.org/show_bug.cgi?id=224913
rdar://76978874
Reviewed by Michael Saboff.
If the operation can potentially either underflow or overflow, then the result
can be any value.
* b3/B3ReduceStrength.cpp:
2021-04-23 Fujii Hironori <Hironori.Fujii@sony.com>
[JSC][Win] callOperationNoExceptionCheck() also needs to support operations that return SlowPathReturnType
https://bugs.webkit.org/show_bug.cgi?id=224964
Reviewed by Yusuke Suzuki.
r229989 (Bug 183655) added the x64 Windows support only for
callOperation(), but for callOperationNoExceptionCheck().
callOperationNoExceptionCheck() also needs the x64 Windows
support.
This change is a preparation for Bug 224920 that is going to use
callOperationNoExceptionCheck instead of callOperation.
* jit/JIT.h:
(callOperation): Rewrote by using 'if constexpr' instead of SFINAE.
(callOperationNoExceptionCheck): Added a new implementation for
x64 Windows based on callOperation.
2021-04-23 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r276486.
https://bugs.webkit.org/show_bug.cgi?id=224973
broke windows build
Reverted changeset:
"[JSC][Win] callOperationNoExceptionCheck() also needs to
support operations that return SlowPathReturnType"
https://bugs.webkit.org/show_bug.cgi?id=224964
https://trac.webkit.org/changeset/276486
2021-04-22 Fujii Hironori <Hironori.Fujii@sony.com>
[JSC][Win] callOperationNoExceptionCheck() also needs to support operations that return SlowPathReturnType
https://bugs.webkit.org/show_bug.cgi?id=224964
Reviewed by Yusuke Suzuki.
r229989 (Bug 183655) added the x64 Windows support only for
callOperation(), but for callOperationNoExceptionCheck().
callOperationNoExceptionCheck() also needs the x64 Windows
support.
This change is a preparation for Bug 224920 that is going to use
callOperationNoExceptionCheck instead of callOperation.
* jit/JIT.h:
(callOperation): Rewrote by using 'if constexpr' instead of SFINAE.
(callOperationNoExceptionCheck): Added a new implementation for
x64 Windows based on callOperation.
2021-04-22 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r276456.
https://bugs.webkit.org/show_bug.cgi?id=224952
Windows specific crash
Reverted changeset:
"[JSC} Remove exception checks from non-throwing function
calls in Baseline JIT"
https://bugs.webkit.org/show_bug.cgi?id=224920
https://trac.webkit.org/changeset/276456
2021-04-22 Yusuke Suzuki <ysuzuki@apple.com>
[JSC} Remove exception checks from non-throwing function calls in Baseline JIT
https://bugs.webkit.org/show_bug.cgi?id=224920
Reviewed by Tadeu Zagallo.
These functions are not taking JSGlobalObject and will not throw an error.
Use callOperationNoExceptionCheck instead to avoid emitting unnecessary exception checks.
* jit/JIT.cpp:
(JSC::JIT::emitEnterOptimizationCheck):
* jit/JITOpcodes.cpp:
(JSC::JIT::emitSlow_op_new_object):
(JSC::JIT::emit_op_catch):
(JSC::JIT::emit_op_switch_imm):
(JSC::JIT::emitSlow_op_loop_hint):
(JSC::JIT::emit_op_profile_type):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emitSlow_op_new_object):
(JSC::JIT::emit_op_catch):
(JSC::JIT::emit_op_switch_imm):
(JSC::JIT::emit_op_profile_type):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitWriteBarrier):
2021-04-22 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Baseline should have fast path for switch_imm
https://bugs.webkit.org/show_bug.cgi?id=224521
Reviewed by Tadeu Zagallo.
This patch implements op_switch_imm fast path in Baseline.
We have this fast path in LLInt, DFG, and FTL. So only Baseline lacks this.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::emitSwitchIntJump):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_switch_imm):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_switch_imm):
2021-04-21 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] DFG / FTL should inline switch_string
https://bugs.webkit.org/show_bug.cgi?id=224578
Reviewed by Mark Lam.
Because of r275840 change, we no longer copy StringJumpTable when compiling DFG / FTL code.
Instead we are using a pointer to UnlinkedStringTable stored in UnlinkedCodeBlock.
This allows DFG / FTL to inline CodeBlock which includes op_switch_string. We were previously not able
to do that because we cannot copy StringImpl in DFG / FTL concurrent compiler thread.
1. We handle StringJumpTable / UnlinkedStringJumpTable in the same way as SimpleJumpTable / UnlinkedSimpleJumpTable.
2. We put m_ctiDefault of StringJumpTable in the last element of m_ctiOffsets vector of StringJumpTable to make
sizeof(StringJumpTable) small.
3. We use m_indexInTable instead of m_branchOffset in FTL switch generation to make switch table dense.
The microbenchmark shows 30% improvement because of unlocking inlining feature.
ToT Patched
switch-inlining 27.1238+-0.2708 ^ 20.2630+-0.1477 ^ definitely 1.3386x faster
<geometric> 27.1238+-0.2708 ^ 20.2630+-0.1477 ^ definitely 1.3386x faster
* bytecode/JumpTable.h:
(JSC::StringJumpTable::ensureCTITable):
(JSC::StringJumpTable::ctiForValue const):
(JSC::StringJumpTable::ctiDefault const):
(JSC::StringJumpTable::isEmpty const):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedStringJumpTable::indexForValue const):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGGraph.h:
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::link):
* dfg/DFGOperations.cpp:
(JSC::DFG::JSC_DEFINE_JIT_OPERATION):
* dfg/DFGOperations.h:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::emitSwitchStringOnString):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::switchStringSlow):
* ftl/FTLOperations.cpp:
(JSC::FTL::JSC_DEFINE_JIT_OPERATION):
* ftl/FTLOperations.h:
* jit/JIT.cpp:
(JSC::JIT::link):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_switch_string):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_switch_string):
* jit/JITOperations.cpp:
(JSC::JSC_DEFINE_JIT_OPERATION):
2021-04-21 Adrian Perez de Castro <aperez@igalia.com>
Non-unified build fixes, mid April 2021 edition
https://bugs.webkit.org/show_bug.cgi?id=222652
<rdar://problem/75262285>
Unreviewed non-unified build fixes.
* bytecode/JumpTable.cpp: Remove inclusion of wtf/text/StringHash.h
* bytecode/JumpTable.h: Add missing inclusions of wtf/FixedVector.h and
wtf/text/StringHash.h
* bytecode/SpeculatedType.cpp: Add missing includes JSCJSValueInlines.h and
JSCellInlines.h
* bytecompiler/BytecodeGenerator.cpp: Move template method to header, remove now uneeded
LinkTimeConstant.h include.
* bytecompiler/BytecodeGenerator.h: Add include for LinkTimeConstant.h
(JSC::BytecodeGenerator::emitDirectSetPrototypeOf): Template method moved here from
BytecodeGenerator.cpp to avoid compile errors due to usage of missing template body
definition.
* dfg/DFGDesiredGlobalProperties.cpp: Add missing DFGDesiredWatchpoints.h include.
* ftl/FTLAbstractHeap.cpp: Add missing JSCJSValueInlines.h include.
* runtime/JSCustomGetterFunction.cpp: Add missing IdentifierInlines.h include.
* runtime/JSCustomSetterFunction.cpp: Ditto.
* runtime/SetPrototype.cpp: Add missing HashMapImplInlines.h include.
* runtime/VMTraps.cpp: Add missing VMEntryScope.h include.
* runtime/WeakSetConstructor.cpp: Add missing WeakMapImplInlines.h include.
* runtime/WeakSetPrototype.cpp: Add missing includes for HashMapImplInlines.h and
WeakMapImplInlines.h
* wasm/js/JSWebAssemblyTable.cpp: Add missing ObjectConstructor.h include.
2021-04-20 Michael Catanzaro <mcatanzaro@gnome.org>
Static asserts in WasmAirIRGenerator.cpp and WasmB3IRGenerator.cpp trigger -Wnonnull warnings with GCC 11
https://bugs.webkit.org/show_bug.cgi?id=224826
Reviewed by Yusuke Suzuki.
Rewrite these static asserts to avoid warnings when built with GCC 11. Credit to Jonathan
Wakely for providing this mind-bending solution.
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState):
(JSC::Wasm::AirIRGenerator::addCurrentMemory):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::addCurrentMemory):
2021-04-20 Michael Catanzaro <mcatanzaro@gnome.org>
-Warray-bounds warning in AirAllocateRegistersByGraphColoring.cpp with GCC 11
https://bugs.webkit.org/show_bug.cgi?id=224782
Reviewed by Darin Adler.
These warnings don't make any sense to me. Suppress them.
* b3/air/AirAllocateRegistersByGraphColoring.cpp:
2021-04-20 Keith Miller <keith_miller@apple.com>
FullGCActivityCallback should use the percentage of pages uncompressed in RAM to determine deferral.
https://bugs.webkit.org/show_bug.cgi?id=224817
Reviewed by Filip Pizlo.
Right now we try to determine if too many pages are paged out by
dereferencing them and bailing out of the GC if we go over a
deadline. While this works if the only goal is to avoid causing
extensive thrashing on spinny disks (HDD), it doesn't prevent
thrashing when access to disk is fast (e.g. SSD). This is because
on fast disks the proportional time to load the memory from disk
is much lower. Additionally, on SSDs in particular we don't want
to load the pages into RAM then bail as that will force a
different page onto disk, increasing wear.
This patch switches to asking the OS if each MarkedBlock is paged
out. Then if we are over a threshold we wait until we would have
GC'd anyway. This patch uses the (maxVMGrowthFactor - 1) as the
percentage of "slow" pages (paged out or compressed) needed to
defer the GC. The idea behind that threshold is that if we add
that many pages then the same number of pages would be forced
out of RAM for us to do a GC anyway (in the limit).
* heap/BlockDirectory.cpp:
(JSC::BlockDirectory::updatePercentageOfPagedOutPages):
(JSC::BlockDirectory::isPagedOut): Deleted.
* heap/BlockDirectory.h:
* heap/FullGCActivityCallback.cpp:
(JSC::FullGCActivityCallback::doCollection):
* heap/Heap.cpp:
(JSC::Heap::isPagedOut):
* heap/Heap.h:
* heap/MarkedSpace.cpp:
(JSC::MarkedSpace::isPagedOut):
* heap/MarkedSpace.h:
* runtime/OptionsList.h:
2021-04-20 Don Olmstead <don.olmstead@sony.com>
[CMake] Don't use FORWARDING_HEADERS_DIR for JSC GLib headers
https://bugs.webkit.org/show_bug.cgi?id=224821
Reviewed by Michael Catanzaro.
Use JavaScriptCoreGLib_FRAMEWORK_HEADERS_DIR and JavaScriptCoreGLib_DERIVED_SOURCES_DIR
for GLib JSC headers instead of FORWARDING_HEADERS_DIR and DERIVED_SOURCES_DIR.
* GLib.cmake:
* PlatformGTK.cmake:
2021-04-20 Ben Nham <nham@apple.com>
LinkBuffer fails to build when MALLOC_HEAP_BREAKDOWN is enabled
https://bugs.webkit.org/show_bug.cgi?id=224722
Reviewed by Yusuke Suzuki.
When ENABLE_MALLOC_HEAP_BREAKDOWN is set, LinkBuffer causes a build failure at link time
since it never defines its debugHeap. Fix that.
* assembler/LinkBuffer.cpp:
2021-04-20 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Use FixedVector for LLIntPrototypeLoadAdaptiveStructureWatchpoint vector
https://bugs.webkit.org/show_bug.cgi?id=224729
Reviewed by Darin Adler.
Replace Vector<LLIntPrototypeLoadAdaptiveStructureWatchpoint> with FixedVector.
* bytecode/CodeBlock.h:
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::LLIntPrototypeLoadAdaptiveStructureWatchpoint):
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::initialize):
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::setupGetByIdPrototypeCache):
2021-04-19 Mark Lam <mark.lam@apple.com>
Build fix for Debug -O3 after r276162.
https://bugs.webkit.org/show_bug.cgi?id=224681
rdar://76698113
Not reviewed.
* runtime/JSObject.cpp:
2021-04-19 Kimmo Kinnunen <kkinnunen@apple.com>
Enable -Wthread-safety, add attributes to custom lock classes, and provide macros to declare guards
https://bugs.webkit.org/show_bug.cgi?id=221614
<rdar://problem/74396781>
Reviewed by David Kilzer.
Add -Wthread-safety to compile flags.
* Configurations/Base.xcconfig:
2021-04-18 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, build fix
https://bugs.webkit.org/show_bug.cgi?id=224715
* dfg/DFGDesiredWatchpoints.h:
2021-04-18 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Do not use Bag<> for DFG / FTL watchpoints
https://bugs.webkit.org/show_bug.cgi?id=224715
Reviewed by Darin Adler.
While Bag<> is useful since its allocated memory will not be moved,
this is really memory-inefficient data structure. Each entry gets a
tail pointer (so adding 8 bytes) and we allocate each entry separately.
In DFG and FTL, we are using Bag<> for watchpoints. But this is not necessary actually: thanks to
concurrent compilers, our watchpoint registration is batched at the end of compilation. This means
that we have a way to know how many watchpoints we should register at that point.
In this patch, we introduce WatchpointCollector. In DesiredGlobalProperties, we run reallyAdd twice
with WatchpointCollector. First time, we just count # of watchpoints. Then we allocate FixedVector<XXXWatchpoint>
and install them. Since we do not (cannot) grow this fixed vector, watchpoint's address will not be changed as required.
We also move DesiredGlobalProperties under DesiredWatchpoints since this basically registers watchpoints.
* bytecode/AdaptiveInferredPropertyValueWatchpointBase.cpp:
(JSC::AdaptiveInferredPropertyValueWatchpointBase::AdaptiveInferredPropertyValueWatchpointBase):
(JSC::AdaptiveInferredPropertyValueWatchpointBase::initialize):
* bytecode/AdaptiveInferredPropertyValueWatchpointBase.h:
* bytecode/CodeBlockJettisoningWatchpoint.h:
* dfg/DFGAdaptiveInferredPropertyValueWatchpoint.cpp:
(JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::AdaptiveInferredPropertyValueWatchpoint):
(JSC::DFG::AdaptiveInferredPropertyValueWatchpoint::initialize):
* dfg/DFGAdaptiveInferredPropertyValueWatchpoint.h:
* dfg/DFGAdaptiveStructureWatchpoint.cpp:
(JSC::DFG::AdaptiveStructureWatchpoint::AdaptiveStructureWatchpoint):
(JSC::DFG::AdaptiveStructureWatchpoint::initialize):
* dfg/DFGAdaptiveStructureWatchpoint.h:
* dfg/DFGCommonData.cpp:
(JSC::DFG::CommonData::validateReferences):
(JSC::DFG::CommonData::clearWatchpoints):
* dfg/DFGCommonData.h:
* dfg/DFGDesiredGlobalProperties.cpp:
(JSC::DFG::DesiredGlobalProperties::reallyAdd):
* dfg/DFGDesiredGlobalProperties.h:
* dfg/DFGDesiredWatchpoints.cpp:
(JSC::DFG::ArrayBufferViewWatchpointAdaptor::add):
(JSC::DFG::SymbolTableAdaptor::add):
(JSC::DFG::FunctionExecutableAdaptor::add):
(JSC::DFG::AdaptiveStructureWatchpointAdaptor::add):
(JSC::DFG::DesiredWatchpoints::addLazily):
(JSC::DFG::DesiredWatchpoints::reallyAdd):
(JSC::DFG::DesiredWatchpoints::areStillValidOnMainThread):
(JSC::DFG::WatchpointCollector::finalize):
* dfg/DFGDesiredWatchpoints.h:
(JSC::DFG::SetPointerAdaptor::add):
(JSC::DFG::GenericDesiredWatchpoints::reallyAdd):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::watchGlobalProperty):
* dfg/DFGGraph.h:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::reallyAdd):
(JSC::DFG::Plan::isStillValidOnMainThread):
(JSC::DFG::Plan::cancel):
* dfg/DFGPlan.h:
(JSC::DFG::Plan::transitions):
(JSC::DFG::Plan::globalProperties): Deleted.
2021-04-18 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Make more DFG/FTL data FixedVector/Vector
https://bugs.webkit.org/show_bug.cgi?id=224713
Reviewed by Darin Adler.
1. DFG::JITCode::m_osrEntry / DFG::JITCode::m_osrExit / DFG::JITCode::m_speculationRecovery are changed to FixedVector.
They are added at compiling time, and after that, these vectors are not modified. So when finalizing, we can easily make it FixedVector.
We also change OSREntry::{m_reshufflings,m_expectedValues} to FixedVector and FixedOperands.
2. FTL::JITCode::m_osrExit is changed from SegmentedVector to Vector. We are still using Vector since it also involves osrExitDescriptor.
But later, we should merge m_osrExit to osrExitDescriptor. Vector is still better than SegmentedVector since it wastes several entries
per segment. SegmentedVector was used to use a direct pointer of OSRExit (this is not possible in Vector since this pointer can be invalidated
after growing), but usage of that is fairly limited so that we can just replace them with m_index + osrExit vector.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::tallyFrequentExitSites):
* bytecode/Operands.h:
(JSC::Operands::Operands):
* dfg/DFGJITCode.cpp:
(JSC::DFG::JITCode::shrinkToFit):
(JSC::DFG::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
(JSC::DFG::JITCode::validateReferences):
(JSC::DFG::JITCode::findPC):
(JSC::DFG::JITCode::finalizeOSREntrypoints):
* dfg/DFGJITCode.h:
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::linkOSRExits):
(JSC::DFG::JITCompiler::link):
(JSC::DFG::JITCompiler::noticeOSREntry):
(JSC::DFG::JITCompiler::appendExceptionHandlingOSRExit):
* dfg/DFGJITCompiler.h:
(JSC::DFG::JITCompiler::appendOSRExit):
(JSC::DFG::JITCompiler::appendSpeculationRecovery):
* dfg/DFGOSREntry.h:
* dfg/DFGOSRExit.cpp:
(JSC::DFG::JSC_DEFINE_JIT_OPERATION):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::speculationCheck):
(JSC::DFG::SpeculativeJIT::emitInvalidationPoint):
(JSC::DFG::SpeculativeJIT::linkOSREntries):
* ftl/FTLJITCode.cpp:
(JSC::FTL::JITCode::shrinkToFit):
(JSC::FTL::JITCode::validateReferences):
(JSC::FTL::JITCode::liveRegistersToPreserveAtExceptionHandlingCallSite):
(JSC::FTL::JITCode::findPC):
* ftl/FTLJITCode.h:
* ftl/FTLOSRExit.cpp:
(JSC::FTL::OSRExitDescriptor::prepareOSRExitHandle):
(JSC::FTL::OSRExit::OSRExit):
* ftl/FTLOSRExit.h:
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::JSC_DEFINE_JIT_OPERATION):
* ftl/FTLOSRExitHandle.cpp:
(JSC::FTL::OSRExitHandle::emitExitThunk):
* ftl/FTLOSRExitHandle.h:
(JSC::FTL::OSRExitHandle::OSRExitHandle):
* ftl/FTLPatchpointExceptionHandle.cpp:
(JSC::FTL::PatchpointExceptionHandle::scheduleExitCreationForUnwind):
2021-04-17 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, suppress warnings
https://bugs.webkit.org/show_bug.cgi?id=224616
* runtime/HashMapImpl.h:
* runtime/HashMapImplInlines.h:
(JSC::areKeysEqual):
(JSC::wangsInt64Hash):
2021-04-16 Mark Lam <mark.lam@apple.com>
More changes to support the TerminationException.
https://bugs.webkit.org/show_bug.cgi?id=224681
rdar://76698113
Reviewed by Keith Miller.
* interpreter/Interpreter.cpp:
(JSC::Interpreter::executeProgram):
- ProgramExecutable::initializeGlobalProperties() can throw the TerminationException.
Add handling for that.
* runtime/JSObject.cpp:
(JSC::JSObject::defineOwnIndexedProperty):
- JSObject::defineOwnIndexedProperty() has a blob of assertion code that it verifying
that getOwnPropertyDescriptor() should succeed without throwing any exceptions if
the fast path is allowed. However, this is assertion is only true if there isn't
a termination being requested. So, use the DeferTermination scope to allow this
assertion to be tested without the complication of a TerminationException.
2021-04-16 Keith Miller <keith_miller@apple.com>
Before deleting a MarkedBlock we do not need to clear its m_directory pointer.
https://bugs.webkit.org/show_bug.cgi?id=224677
Reviewed by Yusuke Suzuki.
Right now when we are about to free a MarkedBlock we clear the
m_directory pointer in the MarkedBlock's Handle. This has the
downside, however, of potentially paging in the footer from disk /
the compressor, which some data we have seen shows is happening.
This patch prevents this uncessary store to hopefully reduce the
number of pageins/decompressions caused by Safari web content.
* heap/BlockDirectory.cpp:
(JSC::BlockDirectory::removeBlock):
(JSC::BlockDirectory::removeBlockForDeletion):
* heap/BlockDirectory.h:
* heap/MarkedBlock.cpp:
(JSC::MarkedBlock::Handle::~Handle):
* heap/MarkedSpace.cpp:
(JSC::MarkedSpace::freeBlock):
2021-04-16 Mark Lam <mark.lam@apple.com>
Build fix for Debug -O3 after r276069.
https://bugs.webkit.org/show_bug.cgi?id=224619
Not reviewed.
* runtime/HashMapImplInlines.h:
2021-04-15 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r276112.
https://bugs.webkit.org/show_bug.cgi?id=224646
.h files should not #include *Inlines.h files.
Reverted changeset:
"REGRESSION(r276039) [GTK] Build failures on Ubuntu 18.04"
https://bugs.webkit.org/show_bug.cgi?id=224644
https://trac.webkit.org/changeset/276112
2021-04-15 Lauro Moura <lmoura@igalia.com>
REGRESSION(r276039) [GTK] Build failures on Ubuntu 18.04
https://bugs.webkit.org/show_bug.cgi?id=224644
Unreviewed build fix.
* runtime/JSSet.h: Use HashMapImplInlines to include the base
finishCreation implementation. Somehow GCC 7.5 wasn't picking it up.
2021-04-15 Mark Lam <mark.lam@apple.com>
HashMapImpl::rehash() should use a version of jsMapHash that cannot throw.
https://bugs.webkit.org/show_bug.cgi?id=224610
rdar://76698910
Reviewed by Yusuke Suzuki.
For context, HashMapImpl::rehash()'s rehash operation relies on jsMapHash().
jsMapHash() can be interrupted by a TerminationException, and as a result, may
not return the string hash we are expecting. This in turn can lead to the
rehash operation hashing with wrong keys.
However, all the keys should have already been hashed. Hence, rehash() should
never see an exception thrown there. We can avoid this complication with the
TerminationException by simply calling an alternate version of jsMapHash() that
is guaranteed to never throw e.g. a jsMapHashForAlreadyHashedValue() function.
* runtime/ExceptionHelpers.h:
* runtime/HashMapImplInlines.h:
(JSC::jsMapHashImpl):
(JSC::jsMapHash):
(JSC::jsMapHashForAlreadyHashedValue):
(JSC::HashMapImpl<HashMapBucketType>::rehash):
2021-04-14 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Remove CodeBlock::RareData::m_catchProfiles
https://bugs.webkit.org/show_bug.cgi?id=224593
Reviewed by Mark Lam.
We are having this Vector just because we would like to destroy them when destroying the owner Baseline / LLInt CodeBlock.
But we are setting a pointer in OpCatch's metadata in Baseline / LLInt.
So we should just iterate metadata for that and destroy them in the destructor. No need to keep them separately.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::~CodeBlock):
(JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeIndex):
(JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeIndexSlow):
(JSC::CodeBlock::updateAllValueProfilePredictionsAndCountLiveness):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::createRareDataIfNecessary):
* bytecode/ValueProfile.h:
(JSC::ValueProfileAndVirtualRegisterBuffer::ValueProfileAndVirtualRegisterBuffer): Deleted.
(JSC::ValueProfileAndVirtualRegisterBuffer::~ValueProfileAndVirtualRegisterBuffer): Deleted.
(JSC::ValueProfileAndVirtualRegisterBuffer::forEach): Deleted.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
2021-04-15 Mark Lam <mark.lam@apple.com>
Optimize the DeferTermination scope to be more efficient.
https://bugs.webkit.org/show_bug.cgi?id=224619
Reviewed by Saam Barati.
This can be beneficial since we may be using DeferTermination in more places in
the code.
1. Added a VMTrapsInlines.h to hold the inline functions.
2. Split deferTermination() and undoDeferTermination() into fast and slow functions.
The fast functions are inlineable.
3. Remove the locking of VMTraps::m_lock in these functions. These functions only
modify the following:
a. VMTraps::m_deferTerminationCount
b. VMTraps::m_suspendedTerminationException
c. VMTraps::m_trapBits for setting the NeedTermination bit if needed.
d. VM::m_exception
Except for VMTraps::m_trapBits, all of these are only written to from the mutator
thread. VMTraps::m_trapBits is always written to using Atomics. There isn't
anything that needs to be guarded by VMTraps::m_lock.
4. Fix VMTraps::deferTermination() to only set m_suspendedTerminationException
and clear an existing TerminationException if it's being called from the
outermost DeferTermination (i.e. m_deferTerminationCount is 1 after incrementing).
These conditional operations are not done in VMTraps::deferTerminationSlow().
In practice, it wouldn't have mattered anyway because we would never throw a
TerminationException while a DeferTermination scope is in effect. The
the vm.isTerminationException() in the original deferTermination() would
always have prevented the slow path operations from being executed anyway.
However, for the purpose of this patch, we want to avoid as much unnecessary
work as possible in the fast path. Hence, it is good to skip the slow path
if deferTermination() isn't called from the outermost scope.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* jit/JITOperations.cpp:
* jsc.cpp:
* runtime/JSGlobalObject.cpp:
* runtime/VMTraps.cpp:
(JSC::VMTraps::deferTerminationSlow):
(JSC::VMTraps::undoDeferTerminationSlow):
(JSC::VMTraps::vm const): Deleted.
(JSC::VMTraps::deferTermination): Deleted.
(JSC::VMTraps::undoDeferTermination): Deleted.
* runtime/VMTraps.h:
* runtime/VMTrapsInlines.h: Added.
(JSC::VMTraps::vm const):
(JSC::VMTraps::deferTermination):
(JSC::VMTraps::undoDeferTermination):
2021-04-15 Mark Lam <mark.lam@apple.com>
Refactor inline functions out of HashMapImpl.h into HashMapImplInlines.h.
https://bugs.webkit.org/show_bug.cgi?id=224616
rdar://76713709
Reviewed by Yusuke Suzuki.
Also do the same for clients of HashMapImpl that require similar refactoring.
This fixes the #include of JSCJSValueInlines.h in HashMapImpl.h, as well as makes
it easier to use other inline functions from other classes in the implementation
of HashMapImpl's inline functions in the future.
This patch only moves inline functions out to their respective *Inlines.h.
There are no behavior changes.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGAbstractInterpreterInlines.h:
* dfg/DFGOperations.cpp:
* runtime/AbstractModuleRecord.cpp:
* runtime/HashMapImpl.cpp:
* runtime/HashMapImpl.h:
(JSC::areKeysEqual): Deleted.
(JSC::normalizeMapKey): Deleted.
(JSC::wangsInt64Hash): Deleted.
(JSC::jsMapHash): Deleted.
(JSC::concurrentJSMapHash): Deleted.
(JSC::shouldShrink): Deleted.
(JSC::shouldRehashAfterAdd): Deleted.
(JSC::nextCapacity): Deleted.
(JSC::HashMapImpl::finishCreation): Deleted.
(JSC::HashMapImpl::findBucket): Deleted.
(JSC::HashMapImpl::get): Deleted.
(JSC::HashMapImpl::has): Deleted.
(JSC::HashMapImpl::add): Deleted.
(JSC::HashMapImpl::addNormalized): Deleted.
(JSC::HashMapImpl::remove): Deleted.
(JSC::HashMapImpl::clear): Deleted.
(JSC::HashMapImpl::setUpHeadAndTail): Deleted.
(JSC::HashMapImpl::addNormalizedNonExistingForCloning): Deleted.
(JSC::HashMapImpl::addNormalizedInternal): Deleted.
(JSC::HashMapImpl::findBucketAlreadyHashedAndNormalized): Deleted.
(JSC::HashMapImpl::rehash): Deleted.
(JSC::HashMapImpl::checkConsistency const): Deleted.
(JSC::HashMapImpl::makeAndSetNewBuffer): Deleted.
(JSC::HashMapImpl::assertBufferIsEmpty const): Deleted.
* runtime/HashMapImplInlines.h: Added.
(JSC::areKeysEqual):
(JSC::normalizeMapKey):
(JSC::wangsInt64Hash):
(JSC::jsMapHash):
(JSC::concurrentJSMapHash):
(JSC::shouldShrink):
(JSC::shouldRehashAfterAdd):
(JSC::nextCapacity):
(JSC::HashMapImpl<HashMapBucketType>::finishCreation):
(JSC::HashMapImpl<HashMapBucketType>::findBucket):
(JSC::HashMapImpl<HashMapBucketType>::get):
(JSC::HashMapImpl<HashMapBucketType>::has):
(JSC::HashMapImpl<HashMapBucketType>::add):
(JSC::HashMapImpl<HashMapBucketType>::addNormalized):
(JSC::HashMapImpl<HashMapBucketType>::remove):
(JSC::HashMapImpl<HashMapBucketType>::clear):
(JSC::HashMapImpl<HashMapBucketType>::setUpHeadAndTail):
(JSC::HashMapImpl<HashMapBucketType>::addNormalizedNonExistingForCloning):
(JSC::HashMapImpl<HashMapBucketType>::addNormalizedInternal):
(JSC::HashMapImpl<HashMapBucketType>::findBucketAlreadyHashedAndNormalized):
(JSC::HashMapImpl<HashMapBucketType>::rehash):
(JSC::HashMapImpl<HashMapBucketType>::checkConsistency const):
(JSC::HashMapImpl<HashMapBucketType>::makeAndSetNewBuffer):
(JSC::HashMapImpl<HashMapBucketType>::assertBufferIsEmpty const):
* runtime/JSMap.h:
* runtime/JSMapInlines.h: Added.
(JSC::JSMap::set):
* runtime/JSSetInlines.h: Added.
* runtime/JSWeakMap.h:
* runtime/JSWeakMapInlines.h: Added.
(JSC::JSWeakMap::set):
* runtime/MapConstructor.cpp:
* runtime/MapPrototype.cpp:
* runtime/SetConstructor.cpp:
* runtime/WeakMapConstructor.cpp:
* runtime/WeakMapImpl.h:
(JSC::jsWeakMapHash): Deleted.
(JSC::nextCapacityAfterBatchRemoval): Deleted.
(JSC::WeakMapImpl::add): Deleted.
(JSC::WeakMapImpl::shouldRehashAfterAdd const): Deleted.
(JSC::WeakMapImpl::rehash): Deleted.
* runtime/WeakMapImplInlines.h:
(JSC::jsWeakMapHash):
(JSC::nextCapacityAfterBatchRemoval):
(JSC::WeakMapImpl<WeakMapBucket>::add):
(JSC::WeakMapImpl<WeakMapBucket>::rehash):
(JSC::WeakMapImpl<WeakMapBucket>::shouldRehashAfterAdd const):
* runtime/WeakMapPrototype.cpp:
2021-04-15 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Change Vector<> to FixedVector<> in DFG::CommonData if possible
https://bugs.webkit.org/show_bug.cgi?id=224588
Reviewed by Mark Lam.
DFG::CommonData is kept alive so long as DFG code exists. It includes a lot of Vectors while they are not mutable after the DFG code compilation.
This patch changes Vector<> to FixedVector<> if possible to shrink sizeof(DFG::CommonData). And this also removes the need of calling shrinkToFit
explicitly for them.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::propagateTransitions):
(JSC::CodeBlock::determineLiveness):
(JSC::CodeBlock::stronglyVisitWeakReferences):
(JSC::CodeBlock::jettison):
(JSC::CodeBlock::numberOfDFGIdentifiers const):
(JSC::CodeBlock::identifier const):
* bytecode/CodeBlock.h:
* dfg/DFGCommonData.cpp:
(JSC::DFG::CommonData::shrinkToFit):
(JSC::DFG::CommonData::invalidate):
(JSC::DFG::CommonData::~CommonData):
(JSC::DFG::CommonData::installVMTrapBreakpoints):
(JSC::DFG::CommonData::isVMTrapBreakpoint):
(JSC::DFG::CommonData::finalizeCatchEntrypoints):
(JSC::DFG::CommonData::notifyCompilingStructureTransition): Deleted.
* dfg/DFGCommonData.h:
(JSC::DFG::CommonData::catchOSREntryDataForBytecodeIndex):
(JSC::DFG::CommonData::appendCatchEntrypoint): Deleted.
* dfg/DFGDesiredIdentifiers.cpp:
(JSC::DFG::DesiredIdentifiers::reallyAdd):
* dfg/DFGDesiredTransitions.cpp:
(JSC::DFG::DesiredTransition::DesiredTransition):
(JSC::DFG::DesiredTransitions::DesiredTransitions):
(JSC::DFG::DesiredTransitions::addLazily):
(JSC::DFG::DesiredTransitions::reallyAdd):
(JSC::DFG::DesiredTransition::reallyAdd): Deleted.
* dfg/DFGDesiredTransitions.h:
* dfg/DFGDesiredWeakReferences.cpp:
(JSC::DFG::DesiredWeakReferences::reallyAdd):
* dfg/DFGGraph.h:
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::link):
(JSC::DFG::JITCompiler::noticeCatchEntrypoint):
* dfg/DFGOSREntry.h:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::Plan):
(JSC::DFG::Plan::finalizeWithoutNotifyingCallback):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::linkOSREntries):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compilePutStructure):
(JSC::FTL::DFG::LowerDFGToB3::compileMultiPutByOffset):
(JSC::FTL::DFG::LowerDFGToB3::compileInvalidationPoint):
2021-04-14 Mark Lam <mark.lam@apple.com>
Add missing exception check in operationGetPrivateNameOptimize().
https://bugs.webkit.org/show_bug.cgi?id=224592
rdar://76645873
Reviewed by Yusuke Suzuki.
Though the fieldNameValue.toPropertyKey() call in operationGetPrivateNameOptimize()
would not normally throw an exception, it still can throw a TerminationException
because it contains RETURN_IF_EXCEPTION checks.
* jit/JITOperations.cpp:
2021-04-14 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Do not copy SimpleJumpTable
https://bugs.webkit.org/show_bug.cgi?id=224472
Reviewed by Mark Lam.
This patch avoids copying UnlinkedSimpleJumpTable to SimpleJumpTable by decoupling CTI addresses from jump offset in SimpleJumpTable.
SimpleJumpTable and UnlinkedSimpleJumpTable are almost identical. SimpleJumpTable adds JIT jump target for each branch.
We should use data from UnlinkedSimpleJumpTable and jump via SimpleJumpTable. Do not need to have copy of branches from UnlinkedSimpleJumpTable.
This way removes Vector<SimpleJumpTable> from CodeBlock::RareData. And this is moved to CodeBlock::JITData. And it only includes jump target addresses,
and branch offset information is kept in UnlinkedSimpleJumpTable side. We no longer need to carefully copy these vectors in CodeBlock including DFG / FTL ones.
In LLInt, we instead use UnlinkedSimpleJumpTable for jumping.
In Baseline, we first allocate enough FixedVector<SimpleJumpTable> and fill content via SimpleJumpTable::ensureCTITable() call when compiling corresponding
switch opcode. Finally we fill these data structures with actual code locations in JIT::link function.
In DFG, we first collect UnlinkedSimpleJumpTable without copying. This is OK since it is kept by UnlinkedCodeBlock, and UnlinkedCodeBlock is kept by baseline CodeBlocks that
are handled by this DFG compilation. We hold Vector<const UnlinkedSimpleJumpTable*> in DFG::Graph and we materialize Vector<SimpleJumpTable> in DFG::Graph.
During DFG compilation, we touch this DFG::Graph's jump tables, and JIT compiler generates code via these tables. And when linking, we move the content to CodeBlock.
In FTL, while we use UnlinkedSimpleJumpTable in FTL code generation, FTL do not use SimpleJumpTable and instead FTL uses Switch in B3.
* bytecode/BytecodeDumper.cpp:
(JSC::CodeBlockBytecodeDumper<Block>::dumpSwitchJumpTables):
* bytecode/BytecodeDumper.h:
* bytecode/BytecodeGeneratorification.cpp:
(JSC::BytecodeGeneratorification::run):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::shrinkToFit):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::switchJumpTable):
(JSC::CodeBlock::numberOfUnlinkedSwitchJumpTables const):
(JSC::CodeBlock::unlinkedSwitchJumpTable):
(JSC::CodeBlock::numberOfSwitchJumpTables const): Deleted.
(JSC::CodeBlock::clearSwitchJumpTables): Deleted.
(JSC::CodeBlock::addSwitchJumpTableFromProfiledCodeBlock): Deleted.
* bytecode/JumpTable.cpp:
(JSC::SimpleJumpTable::offsetForValue): Deleted.
* bytecode/JumpTable.h:
(JSC::SimpleJumpTable::ensureCTITable):
(JSC::SimpleJumpTable::ctiForValue const):
(JSC::SimpleJumpTable::isEmpty const):
(): Deleted.
(JSC::SimpleJumpTable::cloneNonJITPart const): Deleted.
(JSC::SimpleJumpTable::ctiForValue): Deleted.
(JSC::SimpleJumpTable::clear): Deleted.
* bytecode/PreciseJumpTargetsInlines.h:
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedSimpleJumpTable::offsetForValue const):
(JSC::UnlinkedSimpleJumpTable::add):
(JSC::UnlinkedCodeBlock::numberOfUnlinkedSwitchJumpTables const):
(JSC::UnlinkedCodeBlock::unlinkedSwitchJumpTable const):
(JSC::UnlinkedCodeBlock::unlinkedStringSwitchJumpTable const):
(JSC::UnlinkedCodeBlock::numberOfSwitchJumpTables const): Deleted.
(JSC::UnlinkedCodeBlock::switchJumpTable): Deleted.
(JSC::UnlinkedCodeBlock::unlinkedStringSwitchJumpTable): Deleted.
* bytecode/UnlinkedCodeBlockGenerator.cpp:
(JSC::UnlinkedCodeBlockGenerator::finalize):
* bytecode/UnlinkedCodeBlockGenerator.h:
(JSC::UnlinkedCodeBlockGenerator::numberOfUnlinkedSwitchJumpTables const):
(JSC::UnlinkedCodeBlockGenerator::addUnlinkedSwitchJumpTable):
(JSC::UnlinkedCodeBlockGenerator::unlinkedSwitchJumpTable):
(JSC::UnlinkedCodeBlockGenerator::numberOfSwitchJumpTables const): Deleted.
(JSC::UnlinkedCodeBlockGenerator::addSwitchJumpTable): Deleted.
(JSC::UnlinkedCodeBlockGenerator::switchJumpTable): Deleted.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::beginSwitch):
(JSC::prepareJumpTableForSwitch):
(JSC::BytecodeGenerator::endSwitch):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
* dfg/DFGGraph.h:
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::link):
* dfg/DFGOperations.cpp:
(JSC::DFG::JSC_DEFINE_JIT_OPERATION):
* dfg/DFGOperations.h:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::emitSwitchIntJump):
(JSC::DFG::SpeculativeJIT::emitSwitchImm):
(JSC::DFG::SpeculativeJIT::emitSwitchChar):
(JSC::DFG::SpeculativeJIT::emitSwitchString):
* ftl/FTLLink.cpp:
(JSC::FTL::link):
* jit/JIT.cpp:
(JSC::JIT::compileWithoutLinking):
(JSC::JIT::link):
* jit/JIT.h:
(JSC::SwitchRecord::SwitchRecord):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_switch_imm):
(JSC::JIT::emit_op_switch_char):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_switch_imm):
(JSC::JIT::emit_op_switch_char):
* jit/JITOperations.cpp:
(JSC::JSC_DEFINE_JIT_OPERATION):
* jit/JITOperations.h:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CachedTypes.cpp:
(JSC::CachedSimpleJumpTable::encode):
(JSC::CachedSimpleJumpTable::decode const):
(JSC::CachedCodeBlockRareData::encode):
(JSC::CachedCodeBlockRareData::decode const):
2021-04-14 Alex Christensen <achristensen@webkit.org>
Keep UniqueRef<MathICGenerationState> instead of MathICGenerationState in HashTables
https://bugs.webkit.org/show_bug.cgi?id=224569
Reviewed by Geoffrey Garen.
sizeof(KeyValuePair<const Instruction*, MathICGenerationState>) is 136 on some platforms.
That's on the big side for sparse HashTable entries. I think using UniqueRef will help performance.
* jit/JIT.h:
* jit/JITArithmetic.cpp:
(JSC::JIT::emitMathICFast):
(JSC::JIT::emitMathICSlow):
* jit/JITMathIC.h:
2021-04-14 Mark Lam <mark.lam@apple.com>
Apply DeferTermination in some utility functions in the jsc shell.
https://bugs.webkit.org/show_bug.cgi?id=224572
rdar://76646089
Reviewed by Yusuke Suzuki.
This is to make sure that these functions don't get in the way of testing with
the watchdog. Since these are only test utility functions, just doing the simple
thing of using a DeferTermination scope is the right thing to do here.
* jsc.cpp:
2021-04-14 Mark Lam <mark.lam@apple.com>
Defer TerminationExceptions when evaluating ASSERT in HashMapIml::addNormalized().
https://bugs.webkit.org/show_bug.cgi?id=224565
rdar://76645980
Reviewed by Yusuke Suzuki.
HashMapImpl::addNormalized() has an ASSERT that calls jsMapHash(), which can
potentially throw exceptions. As a result, it has a RETURN_IF_EXCEPTION which
provides an opportunity to handle traps and throw a TerminationException. This
in turn causes the ASSERT to fail.
To fix this, we do:
1. Introduce VMTraps::DeferAction, which gives us DeferForAWhile and DeferUntilEndOfScope.
2. Templatize the DeferTermination RAII object on VMTraps::DeferAction.
Introduce DeferTerrminationForAWhile, which is DeferTermination<VMTraps::DeferAction::DeferForAWhile>.
DeferForAWhile means that the deferScope will not throw the TerminationException
on exit. Instead, it will re-set the NeedTermination bit in the traps, and let
the next trap check handle it.
3. Introduce DEFER_TERMINATION_AND_ASSERT_WITH_MESSAGE (and friends) which creates
a DeferTerrminationForAWhile scope before doing an ASSERT_WITH_MESSAGE.
4. Use DEFER_TERMINATION_AND_ASSERT_WITH_MESSAGE instead in HashMapImpl::addNormalized().
* runtime/DeferTermination.h:
(JSC::DeferTermination::DeferTermination):
(JSC::DeferTermination::~DeferTermination):
* runtime/ExceptionHelpers.h:
* runtime/HashMapImpl.h:
(JSC::HashMapImpl::addNormalized):
* runtime/VMTraps.cpp:
(JSC::VMTraps::deferTermination):
(JSC::VMTraps::undoDeferTermination):
* runtime/VMTraps.h:
2021-04-13 Mark Lam <mark.lam@apple.com>
The watchdog should not fire when it's not active.
https://bugs.webkit.org/show_bug.cgi?id=224494
rdar://76581259
Reviewed by Saam Barati and Yusuke Suzuki.
The watchdog is only active when we have entered the VM. If we haven't entered
the VM, we postpone starting the watchdog. For example, see Watchdog::enteredVM()
and Watchdog::exitedVM().
The underlying timer may still fire the NeedWatchdogCheck event after
Watchdog::stopTimer() is called. So, we need to just ignore the event if the
watchdog isn't active.
* runtime/VMTraps.cpp:
(JSC::VMTraps::handleTraps):
* runtime/Watchdog.h:
(JSC::Watchdog::isActive const):
2021-04-13 Ross Kirsling <ross.kirsling@sony.com>
Move cloneUBreakIterator declaration to IntlWorkaround.h
https://bugs.webkit.org/show_bug.cgi?id=224511
Reviewed by Yusuke Suzuki.
Follow up to r275856. There's ultimately no reason IntlWorkaround.cpp needs to be headerless;
this was tied to some confusion about how to successfully include ubrk.h in two different ways.
* JavaScriptCore.xcodeproj/project.pbxproj:
* runtime/IntlSegmenter.cpp:
* runtime/IntlSegmenter.h:
* runtime/IntlSegments.cpp:
* runtime/IntlWorkaround.cpp:
* runtime/IntlWorkaround.h: Added.
2021-04-13 Mark Lam <mark.lam@apple.com>
Use a JSString for the TerminationException value instead of a Symbol.
https://bugs.webkit.org/show_bug.cgi?id=224490
Reviewed by Yusuke Suzuki.
This makes it convertible to a String for clients that wish to report the exception.
Clients, in this case, does not apply to JS code, only C++ code that catches the
exception at the outermost point to handle the termination. The TerminationException
value is not visible to JS code because the TerminationException cannot be caught.
So, this change is transparent to JS code.
* runtime/VM.cpp:
(JSC::VM::ensureTerminationException):
2021-04-13 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r275867.
https://bugs.webkit.org/show_bug.cgi?id=224495
Need alternate fix.
Reverted changeset:
"Reduce functionWithHellaArguments3()'s number of arguments
from 5000 to 500."
https://bugs.webkit.org/show_bug.cgi?id=224474
https://trac.webkit.org/changeset/275867
2021-04-13 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, casting to unsigned long long to suppress warning
https://bugs.webkit.org/show_bug.cgi?id=224473
* b3/B3ConstDoubleValue.cpp:
(JSC::B3::ConstDoubleValue::dumpMeta const):
2021-04-13 Mark Lam <mark.lam@apple.com>
Reduce functionWithHellaArguments3()'s number of arguments from 5000 to 500.
https://bugs.webkit.org/show_bug.cgi?id=224474
rdar://73614896
Reviewed by Yusuke Suzuki.
Using 5000 arguments seems excessive, and may blow out the stack on more resource
constrained devices. 500 should be high enough.
* b3/testb3_5.cpp:
(JSC_DEFINE_JIT_OPERATION):
(testCallFunctionWithHellaArguments3):
2021-04-12 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Remove CodeBlock::m_constantsSourceCodeRepresentation
https://bugs.webkit.org/show_bug.cgi?id=224473
Reviewed by Mark Lam.
CodeBlock::m_constantsSourceCodeRepresentation is identical to UnlinkedCodeBlock::m_constantsSourceCodeRepresentation.
1. For all constants existing at bytecode compile time, elements of the above vectors are identical.
2. For lazily added constants from DFG, it is always SourceCodeRepresentation::Other.
And the array is effectively accessed only when compiling DFG code. So we should remove copy of that in CodeBlock, and
get SourceCodeRepresentation from UnlinkedCodeBlock.
* bytecode/BytecodeDumper.cpp:
(JSC::CodeBlockBytecodeDumper<Block>::dumpConstants):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::setConstantRegisters):
(JSC::CodeBlock::shrinkToFit):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::constants):
(JSC::CodeBlock::addConstant):
(JSC::CodeBlock::addConstantLazily):
(JSC::CodeBlock::constantSourceCodeRepresentation const):
(JSC::CodeBlock::constantsSourceCodeRepresentation): Deleted.
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::constantSourceCodeRepresentation const):
* bytecode/UnlinkedCodeBlockGenerator.h:
(JSC::UnlinkedCodeBlockGenerator::constantSourceCodeRepresentation const):
(JSC::UnlinkedCodeBlockGenerator::constantsSourceCodeRepresentation): Deleted.
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::registerFrozenValues):
2021-04-12 Mark Lam <mark.lam@apple.com>
Interpreter::executeProgram() should install its VMEntryScope at the top.
https://bugs.webkit.org/show_bug.cgi?id=224450
rdar://76530841
Reviewed by Yusuke Suzuki.
"top" includes before any VM code that can throw exceptions is run.
* interpreter/Interpreter.cpp:
(JSC::Interpreter::executeProgram):
2021-04-12 Ross Kirsling <ross.kirsling@sony.com>
ICU 69 deprecates ubrk_safeClone in favor of ubrk_clone
https://bugs.webkit.org/show_bug.cgi?id=224093
Reviewed by Yusuke Suzuki.
In a shining example of "disappointing library practices", ICU 69 deprecates ubrk_safeClone in favor of
a new *draft* API ubrk_clone, meaning that no function with this functionality is exposed by default.
This patch introduces a function cloneUBreakIterator to abstract over this change; however, since we need to:
1. confine the effects of disabling U_HIDE_DRAFT_API to a non-unified implementation file
2. still be able to include ubrk.h from IntlSegmenter.h to instantiate ICUDeleter<ubrk_close> (*not* `clone`!)
...the new helper function is introduced in a *headerless* implementation file, IntlWorkaround.cpp.
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* runtime/IntlSegmenter.cpp:
(JSC::IntlSegmenter::segment const):
* runtime/IntlSegmenter.h:
* runtime/IntlSegments.cpp:
(JSC::IntlSegments::createSegmentIterator):
* runtime/IntlWorkaround.cpp: Added.
(JSC::cloneUBreakIterator):
2021-04-12 Don Olmstead <don.olmstead@sony.com>
Inspector code is wrongly including some private headers
https://bugs.webkit.org/show_bug.cgi?id=224456
Reviewed by Alex Christensen.
These files were including some headers using #include <JavaScriptCore/Foo.h> style instead
of "Foo.h" style. This caused a build error when attempting to revive the Mac CMake build
since those headers were private and private headers are generated after the JavaScriptCore
build. No other ports were have ENABLE_INSPECTOR_ALTERNATE_DISPATCHERS turned on so the
issue hadn't manifested until now.
* API/JSContextRefInspectorSupport.h:
* inspector/augmentable/AlternateDispatchableAgent.h:
* inspector/augmentable/AugmentableInspectorController.h:
2021-04-12 BJ Burg <bburg@apple.com>
Modernize uses of ConsoleClient
https://bugs.webkit.org/show_bug.cgi?id=224398
Reviewed by David Kilzer.
ConsoleClient acts like a delegate, so its callers
should be using weak references to it.
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::consoleClient const):
* inspector/JSGlobalObjectInspectorController.h:
* runtime/ConsoleClient.h:
* runtime/ConsoleObject.cpp:
(JSC::consoleLogWithLevel):
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::setConsoleClient):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::consoleClient const):
(JSC::JSGlobalObject::setConsoleClient): Deleted.
2021-04-11 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Do not copy StringSwitchJumpTable
https://bugs.webkit.org/show_bug.cgi?id=224414
Reviewed by Keith Miller.
Previously, we were copying UnlinkedStringJumpTable to CodeBlock's StringJumpTable because we embed CodeLocation pointer
inside CodeBlock's StringJumpTable. This is copying a mostly identical hashtable to each CodeBlock even in DFG and FTL. This
even prevents us from inlining op_switch_string in DFG and FTL because (1) we don't want to copy this string tables collected from
each inlined CodeBlock into a new DFG / FTL CodeBlock and (2) we cannot ref/deref StringImpl inside DFG / FTL compilers so copying
these tables in the compiler threads need additional "DesiredStringSwitchJumpTable" etc.
In this patch, we stop copying StringSwitchJumpTable. We decouple CodeLocation pointers from the hashtable so that we can use
UnlinkedStringJumpTable in UnlinkedCodeBlock. UnlinkedStringJumpTable's hashtable inclues m_indexInTable in each entry so that
we can have array of CodeLocation pointers in CodeBlock's JITData to have JIT jump targets separately. This design prevents us
from copying unnecessary hashtables, and even this paves the way to inlining switch_string in DFG and FTL.
* bytecode/BytecodeDumper.cpp:
(JSC::CodeBlockBytecodeDumper<Block>::dumpStringSwitchJumpTables):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::shrinkToFit):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::stringSwitchJumpTable):
(JSC::CodeBlock::numberOfUnlinkedStringSwitchJumpTables const):
(JSC::CodeBlock::unlinkedStringSwitchJumpTable):
(JSC::CodeBlock::numberOfStringSwitchJumpTables const): Deleted.
* bytecode/JumpTable.h:
(JSC::StringJumpTable::ctiForValue const):
(JSC::StringJumpTable::offsetForValue): Deleted.
(JSC::StringJumpTable::ctiForValue): Deleted.
(JSC::StringJumpTable::clear): Deleted.
* bytecode/PreciseJumpTargetsInlines.h:
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedStringJumpTable::offsetForValue const):
(JSC::UnlinkedCodeBlock::numberOfUnlinkedStringSwitchJumpTables const):
(JSC::UnlinkedCodeBlock::unlinkedStringSwitchJumpTable):
(JSC::UnlinkedStringJumpTable::offsetForValue): Deleted.
(JSC::UnlinkedCodeBlock::numberOfStringSwitchJumpTables const): Deleted.
(JSC::UnlinkedCodeBlock::stringSwitchJumpTable): Deleted.
* bytecode/UnlinkedCodeBlockGenerator.cpp:
(JSC::UnlinkedCodeBlockGenerator::finalize):
* bytecode/UnlinkedCodeBlockGenerator.h:
(JSC::UnlinkedCodeBlockGenerator::numberOfUnlinkedStringSwitchJumpTables const):
(JSC::UnlinkedCodeBlockGenerator::addUnlinkedStringSwitchJumpTable):
(JSC::UnlinkedCodeBlockGenerator::unlinkedStringSwitchJumpTable):
(JSC::UnlinkedCodeBlockGenerator::numberOfStringSwitchJumpTables const): Deleted.
(JSC::UnlinkedCodeBlockGenerator::addStringSwitchJumpTable): Deleted.
(JSC::UnlinkedCodeBlockGenerator::stringSwitchJumpTable): Deleted.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::beginSwitch):
(JSC::prepareJumpTableForStringSwitch):
(JSC::BytecodeGenerator::endSwitch):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::link):
* dfg/DFGOperations.cpp:
(JSC::DFG::JSC_DEFINE_JIT_OPERATION):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::switchStringSlow):
* ftl/FTLOperations.cpp:
(JSC::FTL::JSC_DEFINE_JIT_OPERATION):
* jit/JIT.cpp:
(JSC::JIT::link):
* jit/JIT.h:
(JSC::SwitchRecord::SwitchRecord):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_switch_string):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_switch_string):
* jit/JITOperations.cpp:
(JSC::JSC_DEFINE_JIT_OPERATION):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/CachedTypes.cpp:
(JSC::CachedStringJumpTable::encode):
(JSC::CachedStringJumpTable::decode const):
(JSC::CachedCodeBlockRareData::encode):
(JSC::CachedCodeBlockRareData::decode const):
2021-04-10 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] B3 reduce-double-to-float should reduce only when constant double is canonical one to reduced float value
https://bugs.webkit.org/show_bug.cgi?id=224403
<rdar://problem/76259599>
Reviewed by Mark Lam.
When reducing double-constant value to float in B3, we should check whether the double value is a canonical one
which can be converted back from the reduced float value. For example, double 1.1 is not the one since it is truncated
into float 1.1 by removing some bits.
static_cast<double>(static_cast<float>(1.1)) != 1.1
Reducing such a double to float changes the semantics.
* b3/B3ConstDoubleValue.cpp:
(JSC::B3::ConstDoubleValue::dumpMeta const):
* b3/B3ConstFloatValue.cpp:
(JSC::B3::ConstFloatValue::dumpMeta const):
* b3/B3ReduceDoubleToFloat.cpp:
* b3/B3ReduceStrength.cpp:
* b3/testb3.h:
(populateWithInterestingValues):
* b3/testb3_1.cpp:
(run):
* b3/testb3_3.cpp:
(testConvertDoubleToFloatToDouble):
(testConvertDoubleToFloatEqual):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::JSC_DEFINE_JIT_OPERATION_WITH_ATTRIBUTES):
(JSC::FTL::DFG::LowerDFGToB3::crash):
(JSC::FTL::DFG::ftlUnreachable): Deleted.
2021-04-10 Mark Lam <mark.lam@apple.com>
Enable VMTraps checks in RETURN_IF_EXCEPTION.
https://bugs.webkit.org/show_bug.cgi?id=224078
rdar://75037057
Reviewed by Keith Miller.
In pre-existing code, termination of a VM's execution can already be requested
asynchronously (with respect to the mutator thread). For example, sources of such
a request can be a watchdog timer firing, or a request to stop execution issued
from a main web thread to a worker thread.
This request is made by firing the VMTraps::NeedTermination event on VMTraps.
Firing the event here only means setting a flag to indicate the presence of the
request. We still have to wait till the mutator thread reaches one of the
pre-designated polling check points to call VMTraps::handleTraps() in order to
service the request. As a result of this need to wait for a polling check point,
if the mutator is executing in a long running C++ loop, then a termination request
may not be serviced for a long time.
However, we observed that a lot of our C++ loops already have RETURN_IF_EXCEPTION
checks. Hence, if we can check VMTraps::needHandling() there, we can service the
VMTraps events more frequently even in a lot of C++ loops, and get a better response.
Full details of what this patch changes:
1. Shorten some type and methods names in the VMTraps class to make code easier to
read e.g. EventType => Event, needTrapHandling => needHandling.
2. Remove the VMTraps::Mask class. Mask was introduced so that we can express a
concatenation of multiple VMTraps events to form a bit mask in a simple way.
In the end, it isn't flexible enough but makes the code more complicated than
necessary. It is now replaced by the simpler solution of using macros to define
the Events as bit fields. Having Events as bit fields intrinsically make them
easy to concatenate (bitwise or) or filter (bitwise and).
Also removed the unused VMTraps::Error class.
3. Make VMTraps::BitField a uint32_t. There was always unused padding in VMTraps
to allow for this. So, we'll just extend it to a full 32-bit to make it easier
to add more events in the future for other uses.
4. Add NeedExceptionHandling as a VMTrap::Event.
5. Make VMTraps::m_trapBits Atomic. This makes it easier to set and clear the
NeedExceptionHandling bit from the mutator without a lock.
6. RETURN_IF_EXCEPTION now checks VMTraps::m_trapBits (via VMTraps::needHandling())
instead of checking VM::m_exception. If the VMTraps::m_trapBits is non-null,
the macro will call VM:hasExceptionsAfterHandlingTraps() to service VMTraps
events as appropriate before returning whether an exception is being thrown.
The result of VM:hasExceptionsAfterHandlingTraps() will determine if
RETURN_IF_EXCEPTION returns or not.
VM:hasExceptionsAfterHandlingTraps() is intentionally designed to take a minimum
of arguments (just the VM as this pointer). This is because RETURN_IF_EXCEPTION
is called from many places, and we would like to minimize code size bloating
from this change.
7. Simplify paramaters of VMTraps::handleTraps().
NeedDebuggerBreak's callFrame argument was always vm.topCallFrame anyway.
So, the patch makes it explicit, and removes the callFrame parameter.
NeedWatchdogCheck's globalObject argument should have always been
vm.entryScope->globalObject(), and we can remove the globalObject parameter.
Before this, we pass in whichever globalObject was convenient to grab hold of.
However, the idea of the watchdog is to time out the current script executing
on the stack. Hence, it makes sense to identify thay script by the globalObject
in use at VM entry.
So far, the only clients that uses the watchdog mechanism only operates in
scenarios with only one globalObject anyway. So this formalization to use
VMEntryScope's globalObject does not change the expected behavior.
8. Make the execution of termination more robust. Before reading this, please
read the description of the Events in VMTraps.h first, especially the section
on NeedTermination.
Here's the life cycle of a termination:
a. a client requests termination of the current execution stack by calling
VM::notifyNeedTermination(). notifyNeedTermination() does 2 things:
i. fire the NeedTermination event on VMTraps.
ii. set the VM::m_terminationInProgress flag.
b. Firing the NeedTermination event on VMTraps means setting the NeedTermination
bit on VMTraps::m_trapBits. This bit will be polled by the mutator thread
later at various designated points (including RETURN_IF_EXCEPTION, which we
added in this patch).
Once the mutator sees the NeedTermination bit is set, it will clear the bit
and throw the TerminationException (see VMTraps::handleTraps()). This is
unless the mutator thread is currently in a DeferTermination scope (see (8)
below). If in a DeferTermination scope, then it will not throw the
TerminationException.
Since the NeedTermination bit is cleared, the VM will no longer call
VMTraps::handleTraps() to service the event. If the mutator thread is in
a DeferTermination scope, then on exiting the scope (at scope destruction),
the scope will see that VM::m_terminationInProgress is set, and throw the
deferred TerminationException then.
c. The TerminationException will trigger unwinding out of the current stack
until we get to the outermost VMEntryScope.
d. At the the outermost VMEntryScope, we will clear VM::m_terminationInProgress
if the NeedTermination bit in VMtraps::m_trapBits is cleared.
If the NeedTermination bit is set, then that means we haven't thrown the
TerminationException yet. Currently, clients expect that we must throw the
TerminationException if NeedTermination was requested (again, read comments
at the top of VMTraps.h).
If the NeedTermination bit is set, we'll leave VM::m_terminationInProgress
set until the next time we re-enter the VM and exit to the outermost
VMEntryScope.
e. The purpose of VM::m_terminationInProgress is to provide a summary of the
fact that the VM is in a state of trying to terminate the current stack.
Note that this state is first indicated by the NeedTermination bit being set
in VMTraps::m_trapBits. Then, in VMTraps::handleTraps(), the state is
handed of with the NeedTermination bit being cleared, and the
TerminationException being thrown.
While the VM is in this termination state, we need to prevent new DFG/FTL
JIT code from being compiled and run. The reason is the firing of the
NeedTermination event has invalidated DFG/FTL code on the stack, thereby
allowing their baseline / LLInt versions which have VMTraps polling checks
to run. We don't want to compile new DFG / FTL code and possibly get stuck
in loops in there before the termination is complete.
In operationOptimize(), we check if VM::m_terminationInProgress is set, and
prevent new DFG (and therefore FTL) code from being compiled if needed.
Note: it is easier to check a single flag, VM::m_terminationInProgress,
then to check both if the NeedTermination bit is set or if the
TerminationException is being being thrown.
9. One complication of being able to service VMTraps in RETURN_IF_EXCEPTION checks
is that some of our code (usually for lengthier initializations and bootstrapping)
currently does not handle exceptions well, e.g. JSGlobalObject::init(). They
rely on the code crashing if an exception is thrown while still initializing.
However, for a worker thread, a TerminationException (requested by the main
thread) may arrive before the initialization is complete. This can lead to
crashes because part of the initialization may be aborted in the presence of
an exception, while other parts still expect everything prior to have been
initialized correctly. For resource exhaustion cases (which is abnormal), it
is OK to crash. For the TerminationException (which can be part of normal
operation), we should not be crashing.
To work around this, we introduce a DeferTermination RAII scope object that we
deploy in this type of initialization code. With the scope in effect,
a. if a TerminationException arrives but hasn't been thrown yet, it will be
deferred till the scope ends before being thrown.
b. if a TerminationException has already been thrown, the scope will stash
the exception, clear it from the VM so that the initialization code can
run to completion, and then re-throw the exception when the scope ends.
Currently, we only need to use the DeferTermination scope in a few places
where we know that initialization code will only run for a short period of time.
DeferTermination should not be used for code that can block waiting on an
external event for a long time. Obviously, doing so will prevent the VM
termination mechanism from working.
10. Replaced llint_slow_path_check_if_exception_is_uncatchable_and_notify_profiler
and operationCheckIfExceptionIsUncatchableAndNotifyProfiler with
llint_slow_path_retrieve_and_clear_exception_if_catchable and
operationRetrieveAndClearExceptionIfCatchable.
The 2 runtime functions doesn't actually do anything to notify a profiler.
So, we drop that part of the name.
After returning from these runtime functions respectively, the previous LLInt
and JIT code, which calls these runtimes functions, would go on to load
VM::m_exception, and then store a nullptr there to clear it. This is wasteful.
This patch changes the runtime function to clear and return the Exception
instead. As a result, the calling LLInt and JIT code is simplified a bit.
Note also that clearing an exception now also entails clearing the
NeedExceptionHandling bit in VMTraps::m_trapBits in an atomic way. The above
change makes it easy to do this clearing with C++ code.
11. Fix ScriptFunctionCall::call() to handle exceptions correctly. Previously,
it had one case where it propagates an exception, while another eats it.
Change this function to eat the exception in both cases. This is approproiate
because ScriptFunctionCall is only used to execute some Inspector instrumentation
calls. It doesn't make sense to propagate the exception back to user code.
12. Fix the lazy initialization of JSGlobalObject::m_defaultCollator to be able to
handle the TerminationException.
13. Not related to TerminationException, but this patch also fixes
MarkedArgumentBuffer::expandCapacity() to use Gigacage::tryMalloc() instead of
Gigacage::malloc(). This is needed as one of the fixes to make the
accompanying test case work.
This patch increases code size by 320K (144K for JSC, 176K for WebCore) measured
on x86_64.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::branchTest32):
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::branchTest32):
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::branchTest32):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::branchTest32):
* bindings/ScriptFunctionCall.cpp:
(Deprecated::ScriptFunctionCall::call):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCheckTraps):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCheckTraps):
* interpreter/Interpreter.cpp:
(JSC::Interpreter::executeProgram):
(JSC::Interpreter::executeCall):
(JSC::Interpreter::executeConstruct):
(JSC::Interpreter::execute):
(JSC::Interpreter::executeModuleProgram):
* interpreter/InterpreterInlines.h:
(JSC::Interpreter::execute):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_catch):
(JSC::JIT::emit_op_check_traps):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_catch):
* jit/JITOperations.cpp:
(JSC::JSC_DEFINE_JIT_OPERATION):
* jit/JITOperations.h:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LLIntSlowPaths.h:
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/ArgList.cpp:
(JSC::MarkedArgumentBuffer::expandCapacity):
* runtime/DeferTermination.h: Added.
(JSC::DeferTermination::DeferTermination):
(JSC::DeferTermination::~DeferTermination):
* runtime/ExceptionScope.h:
(JSC::ExceptionScope::exception const):
(JSC::ExceptionScope::exception): Deleted.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::finishCreation):
* runtime/LazyPropertyInlines.h:
(JSC::ElementType>::callFunc):
* runtime/StringPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/VM.cpp:
(JSC::VM::hasExceptionsAfterHandlingTraps):
(JSC::VM::clearException):
(JSC::VM::setException):
(JSC::VM::throwTerminationException):
(JSC::VM::throwException):
* runtime/VM.h:
(JSC::VM::terminationInProgress const):
(JSC::VM::setTerminationInProgress):
(JSC::VM::notifyNeedTermination):
(JSC::VM::DeferExceptionScope::DeferExceptionScope):
(JSC::VM::DeferExceptionScope::~DeferExceptionScope):
(JSC::VM::handleTraps): Deleted.
(JSC::VM::needTrapHandling): Deleted.
(JSC::VM::needTrapHandlingAddress): Deleted.
(JSC::VM::setException): Deleted.
(JSC::VM::clearException): Deleted.
* runtime/VMEntryScope.cpp:
(JSC::VMEntryScope::~VMEntryScope):
* runtime/VMTraps.cpp:
(JSC::VMTraps::tryInstallTrapBreakpoints):
(JSC::VMTraps::fireTrap):
(JSC::VMTraps::handleTraps):
(JSC::VMTraps::takeTopPriorityTrap):
(JSC::VMTraps::deferTermination):
(JSC::VMTraps::undoDeferTermination):
* runtime/VMTraps.h:
(JSC::VMTraps::onlyContainsAsyncEvents):
(JSC::VMTraps::needHandling const):
(JSC::VMTraps::trapBitsAddress):
(JSC::VMTraps::isDeferringTermination const):
(JSC::VMTraps::notifyGrabAllLocks):
(JSC::VMTraps::hasTrapBit):
(JSC::VMTraps::clearTrapBit):
(JSC::VMTraps::setTrapBit):
(JSC::VMTraps::Mask::Mask): Deleted.
(JSC::VMTraps::Mask::allEventTypes): Deleted.
(JSC::VMTraps::Mask::bits const): Deleted.
(JSC::VMTraps::Mask::init): Deleted.
(JSC::VMTraps::interruptingTraps): Deleted.
(JSC::VMTraps::needTrapHandling): Deleted.
(JSC::VMTraps::needTrapHandlingAddress): Deleted.
(JSC::VMTraps::hasTrapForEvent): Deleted.
(JSC::VMTraps::setTrapForEvent): Deleted.
(JSC::VMTraps::clearTrapForEvent): Deleted.
2021-04-09 Alexey Shvayka <shvaikalesh@gmail.com>
Remove className() and toStringName() from the method table
https://bugs.webkit.org/show_bug.cgi?id=224247
Reviewed by Darin Adler.
ES6 introduced Symbol.toStringTag to customize Object.prototype.toString return value.
It was adopted by WebIDL spec, Chrome's DevTools, Node.js etc. There is no reason to
keep 2 method table methods, each with only 1 call site, instead of using the symbol.
Also, it's a bit confusing that for some objects, method table's className() returns
different result than JSCell::className(VM&).
This change:
1. Removes JSProxy's className() / toStringName() methods because its target() is a
global object that never has these overrides and uses Symbol.toStringTag instead.
2. Removes DebuggerScope's className() / toStringName() overrides because its objectAtScope()
has these methods extremely rarely (e.g. `with (new Date) {}`), and its not displayed
by Web Inspector.
3. Merges JSCallbackObject's className() / toStringName() methods into Symbol.toStringTag
branch of getOwnPropertySlot(), with permissive property attributes. To avoid any possible
breakage, we make sure that it will be shadowed by a structure property.
4. Reworks JSObject::calculatedClassName() to rely on Symbol.toStringTag, matching Chrome's
DevTools behavior. On its own, it's a nice change for Web Inspector. We make sure to
lookup Symbol.toStringTag if `constructor.name` inference fails to avoid confusion when
extending builtins.
5. Removes now unused className() from the method table.
6. Removes toStringName() override from JSFinalizationRegistry because its builtin tag [1]
is already "Object".
7. Introduces BooleanObjectType for Boolean wrapper object, and Boolean.prototype as it's
also required to have a [[BooleanData]] internal slot [2].
8. Reworks Object.prototype.toString to determine builtin tag [1] based on JSType rather than
performing method table call. It's guaranteed that a) the set of types we are checking
against won't be expanded, and b) objects with these types have correct `className`.
9. Removes now unused toStringTag() from the method table.
This patch is performance-neutral and carefully preserves current behavior for API objects,
including isPokerBros() hack.
[1]: https://tc39.es/ecma262/#sec-object.prototype.tostring (steps 5-14)
[2]: https://tc39.es/ecma262/#sec-properties-of-the-boolean-prototype-object
* API/JSCallbackObject.h:
* API/JSCallbackObjectFunctions.h:
(JSC::JSCallbackObject<Parent>::getOwnPropertySlot):
(JSC::JSCallbackObject<Parent>::className): Deleted.
(JSC::JSCallbackObject<Parent>::toStringName): Deleted.
* API/tests/testapiScripts/testapi.js:
* debugger/DebuggerScope.cpp:
(JSC::DebuggerScope::className): Deleted.
(JSC::DebuggerScope::toStringName): Deleted.
* debugger/DebuggerScope.h:
* runtime/BooleanObject.cpp:
(JSC::BooleanObject::toStringName): Deleted.
* runtime/BooleanObject.h:
(JSC::BooleanObject::createStructure):
* runtime/BooleanPrototype.h:
* runtime/ClassInfo.h:
* runtime/DateInstance.cpp:
(JSC::DateInstance::toStringName): Deleted.
* runtime/DateInstance.h:
* runtime/ErrorInstance.cpp:
(JSC::ErrorInstance::toStringName): Deleted.
* runtime/ErrorInstance.h:
* runtime/JSCell.cpp:
(JSC::JSCell::className): Deleted.
(JSC::JSCell::toStringName): Deleted.
* runtime/JSCell.h:
* runtime/JSFinalizationRegistry.cpp:
(JSC::JSFinalizationRegistry::toStringName): Deleted.
* runtime/JSFinalizationRegistry.h:
* runtime/JSObject.cpp:
(JSC::JSObject::calculatedClassName):
(JSC::JSObject::className): Deleted.
(JSC::isPokerBros): Deleted.
(JSC::JSObject::toStringName): Deleted.
* runtime/JSObject.h:
* runtime/JSProxy.cpp:
(JSC::JSProxy::className): Deleted.
(JSC::JSProxy::toStringName): Deleted.
* runtime/JSProxy.h:
* runtime/JSType.cpp:
(WTF::printInternal):
* runtime/JSType.h:
* runtime/NumberObject.cpp:
(JSC::NumberObject::toStringName): Deleted.
* runtime/NumberObject.h:
(JSC::NumberObject::createStructure):
* runtime/ObjectPrototype.cpp:
(JSC::isPokerBros):
(JSC::inferBuiltinTag):
(JSC::objectPrototypeToString):
1. Removes jsNontrivialString() because it's assertion may fail in case of iOS hack.
2. Utilizes AtomStringImpl to avoid allocating StringImpl for a small fixed set of strings.
* runtime/RegExpObject.cpp:
(JSC::RegExpObject::toStringName): Deleted.
* runtime/RegExpObject.h:
* runtime/StringObject.cpp:
(JSC::StringObject::toStringName): Deleted.
* runtime/StringObject.h:
2021-04-08 Khem Raj <raj.khem@gmail.com>
[WPE] Build fixes for musl C library on Linux
https://bugs.webkit.org/show_bug.cgi?id=210068
Reviewed by Carlos Alberto Lopez Perez.
Use OS(LINUX) to include musl in platform test
for linux and consolidate all linux platfrom
under same test. Use smaller limits for JSC
stack size per thread and reserved zone size.
* runtime/MachineContext.h:
(JSC::MachineContext::stackPointerImpl):
(JSC::MachineContext::framePointerImpl):
(JSC::MachineContext::instructionPointerImpl):
(JSC::MachineContext::argumentPointer<1>):
(JSC::MachineContext::llintInstructionPointer):
* runtime/OptionsList.h:
2021-04-07 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] DUCET level-1 weighs are equal if characters are alphabets
https://bugs.webkit.org/show_bug.cgi?id=224047
Reviewed by Saam Barati and Mark Lam.
ASCII comparison optimization was based on that DUCET level-1 weights are all different (except for 0000 case), but this was wrong.
If we have the same latin letters with different capitalization, then they have the same level-1 weight ('A' v.s. 'a').
In this patch,
1. If we found that the result of level-1 weight comparison is equal, and characters are not equal, then we do level-3 weight comparison.
We do not perform level-2 since they are all the same weight in ASCII (excluding control characters) region.
2. We do not perform level-4 weight comparison since level-1 and level-3 comparison must distinguish the strings. Level-1 weights are equal
only when characters are the same latin letters. And level-3 weight puts different weights for capital latin letters. Since we already know
that these strings are different while they are equal in level-1 weight comparison, the only case is that they have same latin letters in
the same position. In that case, level-3 weight must say different results for these characters so that we never meet "equal" status in
level-3 weight comparison if characters are different.
* runtime/IntlObject.cpp:
* runtime/IntlObject.h:
* runtime/IntlObjectInlines.h:
(JSC::canUseASCIIUCADUCETComparison):
(JSC::compareASCIIWithUCADUCETLevel3):
(JSC::compareASCIIWithUCADUCET):
2021-04-02 Darin Adler <darin@apple.com>
Use Hasher more, remove IntegerHasher, fix hashing-related mistakes
https://bugs.webkit.org/show_bug.cgi?id=224138
Reviewed by Chris Dumez.
* bytecode/BytecodeIndex.h:
(JSC::BytecodeIndex::hash const): Remove unneeded WTF prefix on call
to intHash.
* ftl/FTLAbstractHeap.h: Use HashTraits instead of WTF::GenericHashTraits.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::validateAIState): Remove unneeded WTF
prefix on call to intHash.
* wasm/WasmLLIntGenerator.cpp: Use HashTraits instead of WTF::GenericHashTraits.
2021-04-07 Mark Lam <mark.lam@apple.com>
Rename and make the TerminationException a singleton.
https://bugs.webkit.org/show_bug.cgi?id=224295
Reviewed by Keith Miller.
We previously call it the TerminatedExecutionException, which is a mouthful but
adds no meaningful information. It's now renamed to TerminationException.
We can make it a singleton because the TerminationException is just a VM internal
mechanism for implementing the termination of the current execution stack. It
should never be exposed to user JS code, and therefore, there is no value in
making it a JS object. Making it a singleton simplifies the code.
A TerminationException is now implemented as an Exception cell which holds a
Symbol with the name "TerminationError". The TerminationException is only created
if needed e.g. if the JSC watchdog is created, or if the VM is for a Worker thread
which needs to be able to handle termination requests.
We'll also stop notifying the debugger when we throw the TerminationException.
This is because the TerminationException is not like ordinary exceptions that
should be reported to the debugger. The fact that the TerminationException uses
the exception handling mechanism is just a VM internal implementation detail.
It is not meaningful to report it to the debugger as an exception.
* API/JSContext.mm:
(-[JSContext evaluateJSScript:]):
* API/tests/ExecutionTimeLimitTest.cpp:
(testExecutionTimeLimit):
* bindings/ScriptFunctionCall.cpp:
(Deprecated::ScriptFunctionCall::call):
* heap/Heap.cpp:
(JSC::Heap::addCoreConstraints):
* inspector/InjectedScriptManager.cpp:
(Inspector::InjectedScriptManager::injectedScriptFor):
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::reportAPIException):
* interpreter/Interpreter.cpp:
(JSC::Interpreter::unwind):
(JSC::Interpreter::notifyDebuggerOfExceptionToBeThrown):
* jit/JITOperations.cpp:
(JSC::JSC_DEFINE_JIT_OPERATION):
* jsc.cpp:
(checkException):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/ExceptionHelpers.cpp:
(JSC::TerminatedExecutionError::defaultValue): Deleted.
(JSC::createTerminatedExecutionException): Deleted.
(JSC::isTerminatedExecutionException): Deleted.
(JSC::throwTerminatedExecutionException): Deleted.
* runtime/ExceptionHelpers.h:
(): Deleted.
* runtime/JSObject.h:
(JSC::JSObject::get const):
* runtime/JSPromise.cpp:
(JSC::JSPromise::rejectWithCaughtException):
* runtime/VM.cpp:
(JSC::VM::VM):
(JSC::VM::ensureWatchdog):
(JSC::VM::ensureTerminationException):
(JSC::VM::throwTerminationException):
(JSC::VM::throwException):
* runtime/VM.h:
(JSC::VM::terminationException const):
(JSC::VM::isTerminationException const):
* runtime/VMTraps.cpp:
(JSC::VMTraps::handleTraps):
2021-04-07 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Use FixedVector more in bytecode dir and JumpTable
https://bugs.webkit.org/show_bug.cgi?id=224275
Reviewed by Michael Saboff and Mark Lam.
1. Use FixedVector more in bytecode/ directory's long-living data structures.
2. Use FixedVector in SimpleJumpTable. This involves LLInt changes because we need to access FixedVector data from LLInt.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
* bytecode/InlineCallFrame.cpp:
(JSC::InlineCallFrame::dumpInContext const):
* bytecode/InlineCallFrame.h:
* bytecode/JumpTable.h:
(JSC::SimpleJumpTable::clear):
* bytecode/ObjectPropertyConditionSet.cpp:
(JSC::ObjectPropertyConditionSet::mergedWith const):
(JSC::ObjectPropertyConditionSet::dumpInContext const):
(JSC::ObjectPropertyConditionSet::isValidAndWatchable const):
* bytecode/ObjectPropertyConditionSet.h:
(JSC::ObjectPropertyConditionSet::create):
(JSC::ObjectPropertyConditionSet::isValid const):
(JSC::ObjectPropertyConditionSet::size const):
(JSC::ObjectPropertyConditionSet::begin const):
(JSC::ObjectPropertyConditionSet::end const):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::findArgumentPositionForLocal):
(JSC::DFG::ByteCodeParser::flushImpl):
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
* dfg/DFGCommonData.cpp:
(JSC::DFG::CommonData::validateReferences):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::isLiveInBytecode):
* dfg/DFGGraph.h:
* dfg/DFGPreciseLocalClobberize.h:
(JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
* dfg/DFGStackLayoutPhase.cpp:
(JSC::DFG::StackLayoutPhase::run):
* ftl/FTLCompile.cpp:
(JSC::FTL::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileGetMyArgumentByVal):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::argumentsStart):
* jit/SetupVarargsFrame.cpp:
(JSC::emitSetupVarargsFrameFastCase):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/ClonedArguments.cpp:
(JSC::ClonedArguments::createWithInlineFrame):
2021-04-07 Mark Lam <mark.lam@apple.com>
Fix a typo in JITUncoughtExceptionAfterCall.
https://bugs.webkit.org/show_bug.cgi?id=224290
Reviewed by Keith Miller.
* assembler/AbortReason.h:
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::jitReleaseAssertNoException):
2021-04-06 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] WasmMemory caging should care about nullptr
https://bugs.webkit.org/show_bug.cgi?id=224268
<rdar://problem/74654838>
Reviewed by Mark Lam.
1. Fix Wasm::MemoryHandle::boundsCheckingSize. We should just return m_mappedCapacity here since UINT32_MAX is not 4GB.
This checking size can include redzone for fast-memory, but this is OK: bounds-check pass in LLInt (in upper tiers, we
do not use bounds-check for fast-memory), and access to redzone, then fault occurs and signal handler can make it error
since signal handler is checking whether the access is within Memory::fastMappedBytes which includes redzone.
2. Fix caging of wasm memory-base pointer in LLInt. We should use pointer sized length since it can be larger than 4GB.
And we should handle nullptr case correctly: Wasm::MemoryHandle's memory can be nullptr when mapped size is zero.
caging needs to handle this case as we do in CagedPtr::getMayBeNull.
* assembler/MacroAssemblerARM64E.h:
(JSC::MacroAssemblerARM64E::untagArrayPtrLength32):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::cageTypedArrayStorage):
* llint/LowLevelInterpreter64.asm:
* llint/WebAssembly.asm:
* offlineasm/arm64e.rb:
* offlineasm/ast.rb:
* offlineasm/instructions.rb:
* runtime/CagedBarrierPtr.h:
(JSC::CagedBarrierPtr::CagedBarrierPtr):
(JSC::CagedBarrierPtr::set):
(JSC::CagedBarrierPtr::get const):
(JSC::CagedBarrierPtr::getMayBeNull const):
(JSC::CagedBarrierPtr::at const):
(JSC::CagedBarrierPtr::setWithoutBarrier):
* wasm/WasmInstance.h:
(JSC::Wasm::Instance::updateCachedMemory):
* wasm/WasmMemory.cpp:
(JSC::Wasm::MemoryHandle::MemoryHandle):
* wasm/WasmMemory.h:
2021-04-06 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Use FixedVector more in JSC
https://bugs.webkit.org/show_bug.cgi?id=224255
Reviewed by Mark Lam.
Use FixedVector more aggressively. This reduces sizeof(Holder) since sizeof(FixedVector) is 8
while sizeof(Vector) is 16. And since this allocates just-fit size, this does not waste memory.
* bytecode/BytecodeLivenessAnalysis.cpp:
(JSC::BytecodeLivenessAnalysis::computeFullLiveness):
* bytecode/BytecodeLivenessAnalysis.h:
* bytecode/FullBytecodeLiveness.h:
(JSC::FullBytecodeLiveness::FullBytecodeLiveness):
* bytecode/UnlinkedEvalCodeBlock.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::livenessFor):
* ftl/FTLForOSREntryJITCode.h:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::lower):
* ftl/FTLOSRExit.cpp:
(JSC::FTL::OSRExitDescriptor::prepareOSRExitHandle):
* ftl/FTLOSRExit.h:
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileRecovery):
* heap/MarkedSpace.cpp:
(JSC::MarkedSpace::sweepPreciseAllocations):
* jit/RegisterAtOffsetList.cpp:
(JSC::RegisterAtOffsetList::RegisterAtOffsetList):
* jit/RegisterAtOffsetList.h:
(JSC::RegisterAtOffsetList::begin const):
(JSC::RegisterAtOffsetList::end const):
(JSC::RegisterAtOffsetList::clear): Deleted.
* runtime/JSGlobalObject.h:
* runtime/JSModuleNamespaceObject.cpp:
(JSC::JSModuleNamespaceObject::finishCreation):
* runtime/JSModuleNamespaceObject.h:
* yarr/YarrPattern.h:
(JSC::Yarr::YarrPattern::resetForReparsing):
2021-04-06 Alexey Shvayka <shvaikalesh@gmail.com>
Symbol and BigInt wrapper objects should perform OrdinaryToPrimitive
https://bugs.webkit.org/show_bug.cgi?id=224208
Reviewed by Yusuke Suzuki.
ES6 introduced Symbol.toPrimitive as the only way to override ToPrimitive;
if it's nullish, OrdinaryToPrimitive [1] is performed unconditionally.
This patch removes two redundant defaultValue() overrides, fixing JSC to call
(possibly userland) toString() / valueOf() methods of a) Symbol objects whose
Symbol.toPrimitive was removed, and b) BigInt wrapper objects.
Aligns JSC with V8 and SpiderMonkey. Coercion of primitives is unaffected.
Also, removes dummy BigIntObject::internalValue() override.
[1]: https://tc39.es/ecma262/#sec-toprimitive (step 2.d)
* runtime/BigIntObject.cpp:
(JSC::BigIntObject::defaultValue): Deleted.
* runtime/BigIntObject.h:
* runtime/SymbolObject.cpp:
(JSC::SymbolObject::defaultValue): Deleted.
* runtime/SymbolObject.h:
2021-04-06 Alexey Shvayka <shvaikalesh@gmail.com>
Array's toString() is incorrect if join() is non-callable
https://bugs.webkit.org/show_bug.cgi?id=224215
Reviewed by Yusuke Suzuki.
This patch exposes objectPrototypeToString() to be used by Array.prototype.toString
if "join" lookup doesn't return a callable value [1].
Fixes Array's toString() to return the correct tag instead of internal `className`,
perform Symbol.toStringTag lookup, and throw for revoked Proxy objects.
Aligns JSC with V8 and SpiderMonkey.
Also, a few objectPrototypeToString() tweaks: a bit nicer `undefined` / `null`
checks and simpler toObject() exception handling.
[1]: https://tc39.es/ecma262/#sec-array.prototype.tostring (step 3)
* runtime/ArrayPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/ObjectPrototype.cpp:
(JSC::objectPrototypeToString):
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/ObjectPrototype.h:
2021-04-06 Yusuke Suzuki <ysuzuki@apple.com>
[WTF] Introduce FixedVector and use it for FixedOperands
https://bugs.webkit.org/show_bug.cgi?id=224171
Reviewed by Mark Lam.
Define FixedOperands<T> which uses FixedVector for its storage. We use FixedOperands in FTL::OSRExitDescriptor.
We also replace RefCountedArray<T> with FixedVector<T> if they are not requiring RefCountedArray<T>'s ref-counting
semantics.
* bytecode/BytecodeGeneratorification.cpp:
(JSC::BytecodeGeneratorification::run):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::setConstantRegisters):
(JSC::CodeBlock::setNumParameters):
(JSC::CodeBlock::setRareCaseProfiles):
(JSC::CodeBlock::insertBasicBlockBoundariesForControlFlowProfiler):
* bytecode/CodeBlock.h:
* bytecode/Operands.h:
(JSC::Operands::Operands):
* bytecode/OperandsInlines.h:
(JSC::U>::dumpInContext const):
(JSC::U>::dump const):
(JSC::Operands<T>::dumpInContext const): Deleted.
(JSC::Operands<T>::dump const): Deleted.
* bytecode/PolyProtoAccessChain.h:
* bytecode/PolymorphicAccess.cpp:
(JSC::PolymorphicAccess::regenerate):
* bytecode/PolymorphicAccess.h:
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::dumpExpressionRangeInfo):
(JSC::UnlinkedCodeBlock::expressionRangeForBytecodeIndex const):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::expressionInfo):
(JSC::UnlinkedCodeBlock::identifiers const):
(JSC::UnlinkedCodeBlock::constantRegisters):
(JSC::UnlinkedCodeBlock::constantsSourceCodeRepresentation):
(JSC::UnlinkedCodeBlock::constantIdentifierSets):
(JSC::UnlinkedCodeBlock::opProfileControlFlowBytecodeOffsets const):
* bytecode/UnlinkedFunctionExecutable.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::prepareJumpTableForSwitch):
* dfg/DFGJITCode.h:
* dfg/DFGPlan.h:
(JSC::DFG::Plan::tierUpInLoopHierarchy):
* ftl/FTLOSRExit.h:
* jit/GCAwareJITStubRoutine.h:
* jit/JIT.cpp:
(JSC::JIT::privateCompileSlowCases):
* jit/PolymorphicCallStubRoutine.h:
* llint/LLIntOffsetsExtractor.cpp:
* llint/LowLevelInterpreter.asm:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseInner):
(JSC::Parser<LexerType>::parseClassFieldInitializerSourceElements):
* parser/Parser.h:
(JSC::Parser<LexerType>::parse):
(JSC::parse):
* runtime/CachedTypes.cpp:
(JSC::CachedVector::encode):
(JSC::CachedVector::decode const):
* wasm/js/JSWebAssemblyInstance.h:
2021-04-05 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Shrink some of Vectors in JSC
https://bugs.webkit.org/show_bug.cgi?id=224162
Reviewed by Simon Fraser.
1. Add XXXStatus::shrinkToFit to shrink underlying dynamic Vectors.
2. Replace tierUpInLoopHierarchy's Vector with RefCountedArray since it is constructed-once-lookup-only data.
3. Use MemoryCompactLookupOnlyRobinHoodHashSet for StringTables since this is constructed-once-lookup-only data. We also add
MemoryCompactLookupOnlyRobinHoodHashSet support for CachedTypes.
4. Use resizeToFit for StringSwitchJumpTables and SwitchJumpTables.
5. JITStubRoutineSet's Vector should be shrunk.
6. BlockDirectoryBits's Vector's initial size should be small.
7. Make PolyProtoAccessChain RefCounted, and use RefCountedArray for its Vector<StructureID>. And remove PolyProtoAccessChain::clone.
Just having Ref is enough since this is immutable data.
8. Use RefCountedArray for UnlinkedFunctionExecutable's m_classFieldLocations.
9. Use RefCountedArray for JSWebAssemblyInstance.
* bytecode/AccessCase.cpp:
(JSC::AccessCase::AccessCase):
(JSC::AccessCase::create):
(JSC::AccessCase::createTransition):
* bytecode/AccessCase.h:
(JSC::AccessCase::AccessCase): Deleted.
* bytecode/CallLinkInfo.cpp:
(JSC::CallLinkInfo::setFrameShuffleData):
* bytecode/CheckPrivateBrandStatus.cpp:
(JSC::CheckPrivateBrandStatus::shrinkToFit):
(JSC::CheckPrivateBrandStatus::computeForStubInfoWithoutExitSiteFeedback):
(JSC::CheckPrivateBrandStatus::merge):
* bytecode/CheckPrivateBrandStatus.h:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
* bytecode/DeleteByStatus.cpp:
(JSC::DeleteByStatus::shrinkToFit):
(JSC::DeleteByStatus::computeForStubInfoWithoutExitSiteFeedback):
(JSC::DeleteByStatus::merge):
* bytecode/DeleteByStatus.h:
* bytecode/GetByStatus.cpp:
(JSC::GetByStatus::shrinkToFit):
(JSC::GetByStatus::computeForStubInfoWithoutExitSiteFeedback):
(JSC::GetByStatus::computeFor):
(JSC::GetByStatus::merge):
* bytecode/GetByStatus.h:
* bytecode/GetterSetterAccessCase.cpp:
(JSC::GetterSetterAccessCase::GetterSetterAccessCase):
(JSC::GetterSetterAccessCase::create):
* bytecode/GetterSetterAccessCase.h:
* bytecode/InByIdStatus.cpp:
(JSC::InByIdStatus::shrinkToFit):
(JSC::InByIdStatus::computeForStubInfoWithoutExitSiteFeedback):
(JSC::InByIdStatus::merge):
* bytecode/InByIdStatus.h:
* bytecode/InstanceOfStatus.cpp:
(JSC::InstanceOfStatus::shrinkToFit):
(JSC::InstanceOfStatus::computeForStubInfo):
* bytecode/InstanceOfStatus.h:
* bytecode/IntrinsicGetterAccessCase.cpp:
(JSC::IntrinsicGetterAccessCase::IntrinsicGetterAccessCase):
(JSC::IntrinsicGetterAccessCase::create):
* bytecode/IntrinsicGetterAccessCase.h:
* bytecode/JumpTable.h:
* bytecode/PolyProtoAccessChain.cpp:
(JSC::PolyProtoAccessChain::tryCreate):
(JSC::PolyProtoAccessChain::create): Deleted.
* bytecode/PolyProtoAccessChain.h:
(JSC::PolyProtoAccessChain::clone): Deleted.
(JSC::PolyProtoAccessChain::chain const): Deleted.
(JSC::PolyProtoAccessChain::operator!= const): Deleted.
(JSC::PolyProtoAccessChain::forEach const): Deleted.
(JSC::PolyProtoAccessChain::slotBaseStructure const): Deleted.
* bytecode/PolymorphicAccess.cpp:
(JSC::PolymorphicAccess::visitWeak const):
(JSC::PolymorphicAccess::regenerate):
* bytecode/PolymorphicAccess.h:
* bytecode/ProxyableAccessCase.cpp:
(JSC::ProxyableAccessCase::ProxyableAccessCase):
(JSC::ProxyableAccessCase::create):
* bytecode/ProxyableAccessCase.h:
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::shrinkToFit):
(JSC::PutByIdStatus::computeForStubInfo):
(JSC::PutByIdStatus::computeFor):
(JSC::PutByIdStatus::merge):
* bytecode/PutByIdStatus.h:
* bytecode/SetPrivateBrandStatus.cpp:
(JSC::SetPrivateBrandStatus::shrinkToFit):
(JSC::SetPrivateBrandStatus::computeForStubInfoWithoutExitSiteFeedback):
(JSC::SetPrivateBrandStatus::merge):
* bytecode/SetPrivateBrandStatus.h:
* bytecode/UnlinkedCodeBlock.h:
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::generateUnlinkedFunctionCodeBlock):
* bytecode/UnlinkedFunctionExecutable.h:
* dfg/DFGJITCode.h:
* dfg/DFGPlan.h:
(JSC::DFG::Plan::tierUpInLoopHierarchy):
* dfg/DFGTierUpCheckInjectionPhase.cpp:
(JSC::DFG::TierUpCheckInjectionPhase::run):
* heap/BlockDirectoryBits.h:
* heap/JITStubRoutineSet.cpp:
(JSC::JITStubRoutineSet::deleteUnmarkedJettisonedStubRoutines):
* jit/CallFrameShuffleData.h:
(JSC::CallFrameShuffleData::shrinkToFit):
* jit/GCAwareJITStubRoutine.h:
* jit/PolymorphicCallStubRoutine.h:
* jit/Repatch.cpp:
(JSC::tryCacheGetBy):
(JSC::tryCachePutByID):
(JSC::tryCacheInByID):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseInner):
(JSC::Parser<LexerType>::parseClassFieldInitializerSourceElements):
* parser/Parser.h:
(JSC::Parser<LexerType>::parse):
(JSC::parse):
* runtime/CachedTypes.cpp:
(JSC::CachedFunctionExecutableRareData::encode):
(JSC::CachedFunctionExecutableRareData::decode const):
* runtime/VM.cpp:
(JSC::VM::popAllCheckpointOSRSideStateUntil):
* wasm/js/JSWebAssemblyInstance.cpp:
(JSC::JSWebAssemblyInstance::visitChildrenImpl):
* wasm/js/JSWebAssemblyInstance.h:
2021-04-05 Alex Christensen <achristensen@webkit.org>
Resurrect Mac CMake build
https://bugs.webkit.org/show_bug.cgi?id=224084
Reviewed by Tim Horton.
* PlatformMac.cmake:
2021-04-05 Keith Miller <keith_miller@apple.com>
DFG arity fixup nodes should exit to the caller's call opcode
https://bugs.webkit.org/show_bug.cgi?id=223278
Reviewed by Saam Barati.
Right now when we do arity fixup in the DFG we model it in the
same way that it executes, which means all the nodes are part of
the callee. Unfortunately, this causes PhantomInsertionPhase to
think those nodes could be replacing previously defined
VirtualRegisters as they are part of the callee's header (always
alive). When PhantomInsertionPhase then inserts a Phantom it will
put that node in the caller's frame as that's the first ExitOK
node. The caller however may have no knowledge of that
VirtualRegister though. For example:
--> foo: loc10 is a local in foo.
...
1: MovHint(loc10)
2: SetLocal(loc10)
<-- foo // loc10 ten is now out of scope for the InlineCallFrame of the caller.
...
// Phantom will be inserted here refering to loc10, which doesn't make sense.
--> bar // loc10 is an argument to bar and needs arity fixup.
... // All of these nodes are ExitInvalid
3: MovHint(loc10, ExitInvalid)
4: SetLocal(loc10, ExitInvalid)
...
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::currentNodeOrigin):
(JSC::DFG::ByteCodeParser::inlineCall):
2021-04-02 Alexey Shvayka <shvaikalesh@gmail.com>
Reduce bytecode instruction count emitted for `class extends`
https://bugs.webkit.org/show_bug.cgi?id=223884
Reviewed by Yusuke Suzuki.
This patch adds a variant of globalFuncSetPrototypeDirect() that throws on
invalid [[Prototype]] values (instead of ignoring them) and utilizes it in
ClassExprNode::emitBytecode(), removing equivalent checks.
Throwing for invalid `superclass.prototype` value after setting the [[Prototype]]
of `constructor` is unobservable because it's a newly created extensible object
and `superclass` is a proven object.
The fact that [[Prototype]] set can throw only in case of `superclass.prototype`
allows keeping descriptive error message via custom appender. To find "extends"
in a source code, ClassExprNode is made an instance of ThrowableExpressionData.
This change reduces the number of emitted bytecodes by 4, and fixes IsConstructor's
error [1] to point to correct source code location.
[1]: https://tc39.es/ecma262/#sec-runtime-semantics-classdefinitionevaluation (step 5.f)
* builtins/BuiltinNames.h:
* bytecode/LinkTimeConstant.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitDirectSetPrototypeOf):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::PropertyListNode::emitPutConstantProperty):
(JSC::ClassExprNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createClassExpr):
* parser/Nodes.h:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseClass):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createClassExpr):
* runtime/ExceptionHelpers.cpp:
(JSC::invalidPrototypeSourceAppender):
(JSC::createInvalidPrototypeError):
* runtime/ExceptionHelpers.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/JSGlobalObjectFunctions.h:
2021-04-02 Jessica Tallon <jtallon@igalia.com>
Add type method to WebAssembly.Memory, WebAssembly.Table & WebAssembly.Global objects
https://bugs.webkit.org/show_bug.cgi?id=222412
Reviewed by Yusuke Suzuki.
This adds a type method to several WASM objects as part of the work to add WASM
type reflections to the JS-API. The methods return a JSON object which describes
the type of the object and can be passed to the constructor to create a new wasm
object of that type.
* wasm/js/JSWebAssemblyGlobal.cpp:
(JSC::JSWebAssemblyGlobal::type):
* wasm/js/JSWebAssemblyGlobal.h:
* wasm/js/JSWebAssemblyMemory.cpp:
(JSC::JSWebAssemblyMemory::type):
* wasm/js/JSWebAssemblyMemory.h:
* wasm/js/JSWebAssemblyTable.cpp:
(JSC::JSWebAssemblyTable::type):
* wasm/js/JSWebAssemblyTable.h:
* wasm/js/WebAssemblyGlobalPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* wasm/js/WebAssemblyGlobalPrototype.h:
* wasm/js/WebAssemblyMemoryPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* wasm/js/WebAssemblyTablePrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
2021-04-01 Yusuke Suzuki <ysuzuki@apple.com>
[WTF] Introduce RobinHoodHashTable
https://bugs.webkit.org/show_bug.cgi?id=223895
Reviewed by Fil Pizlo.
* builtins/BuiltinNames.cpp:
(JSC::lookUpPrivateNameImpl):
(JSC::lookUpWellKnownSymbolImpl):
* builtins/BuiltinNames.h:
* bytecode/BytecodeIntrinsicRegistry.h:
* runtime/Identifier.h:
* runtime/IntlCollator.cpp:
(JSC::IntlCollator::initializeCollator):
(JSC::IntlCollator::checkICULocaleInvariants):
* runtime/IntlCollator.h:
* runtime/IntlDateTimeFormat.cpp:
(JSC::IntlDateTimeFormat::initializeDateTimeFormat):
* runtime/IntlDateTimeFormatConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/IntlDisplayNames.cpp:
(JSC::IntlDisplayNames::initializeDisplayNames):
* runtime/IntlDisplayNamesConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/IntlListFormat.cpp:
(JSC::IntlListFormat::initializeListFormat):
* runtime/IntlListFormatConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/IntlNumberFormat.cpp:
(JSC::IntlNumberFormat::initializeNumberFormat):
* runtime/IntlNumberFormatConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/IntlObject.cpp:
(JSC::addScriptlessLocaleIfNeeded):
(JSC::intlAvailableLocales):
(JSC::intlCollatorAvailableLocales):
(JSC::intlSegmenterAvailableLocales):
(JSC::bestAvailableLocale):
(JSC::lookupMatcher):
(JSC::bestFitMatcher):
(JSC::resolveLocale):
(JSC::lookupSupportedLocales):
(JSC::bestFitSupportedLocales):
(JSC::supportedLocales):
* runtime/IntlObject.h:
(JSC::intlDateTimeFormatAvailableLocales):
(JSC::intlDisplayNamesAvailableLocales):
(JSC::intlNumberFormatAvailableLocales):
(JSC::intlPluralRulesAvailableLocales):
(JSC::intlRelativeTimeFormatAvailableLocales):
(JSC::intlListFormatAvailableLocales):
* runtime/IntlPluralRules.cpp:
(JSC::IntlPluralRules::initializePluralRules):
* runtime/IntlPluralRulesConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/IntlRelativeTimeFormat.cpp:
(JSC::IntlRelativeTimeFormat::initializeRelativeTimeFormat):
* runtime/IntlRelativeTimeFormatConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/IntlSegmenter.cpp:
(JSC::IntlSegmenter::initializeSegmenter):
* runtime/IntlSegmenterConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/RegExpCache.h:
* runtime/RegExpKey.h:
2021-04-01 Yusuke Suzuki <ysuzuki@apple.com>
REGRESSION(r274724): JITCage trampoline needs to be adjusted
https://bugs.webkit.org/show_bug.cgi?id=224065
Reviewed by Saam Barati.
r274724 introduced a new parameter to custom setters, but it didn't change the parameter recognization of JITCage trampolines for custom accessors.
As a result, we are jumping with the wrong pointer, and crash when custom setter is called with JITCage.
This patch fixes the above bug.
1. Now, custom getter and custom setter have different number of parameters. We should have two different trampolines to invoke it. We remove vmEntryCustomAccessor, and
add vmEntryCustomGetter/vmEntryCustomSetter.
2. vmEntryCustomSetter should use a4 parameter as a executable address for trampoline.
* bytecode/AccessCase.cpp:
(JSC::AccessCase::generateImpl):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCallDOMGetter):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCallDOMGetter):
* llint/LLIntThunks.cpp:
* llint/LLIntThunks.h:
* llint/LowLevelInterpreter.asm:
* offlineasm/arm64.rb:
* offlineasm/registers.rb:
* runtime/PropertySlot.h:
2021-04-01 Ross Kirsling <ross.kirsling@sony.com>
[JSC] Use ucal_getTimeZoneOffsetFromLocal if ICU 69 is present
https://bugs.webkit.org/show_bug.cgi?id=224075
Reviewed by Yusuke Suzuki.
Apple ICU 68 cherry picked ucal_getTimeZoneOffsetFromLocal (see r223783),
but now that ICU 69 is in RC, we can go ahead and update the #if for non-Apple platforms.
* runtime/JSDateMath.cpp:
2021-04-01 Tadeu Zagallo <tzagallo@apple.com>
Remove use of ENABLE from API header
https://bugs.webkit.org/show_bug.cgi?id=224060
<rdar://76111678>
Reviewed by Mark Lam.
The use of the ENABLE macro in these API headers has caused build failures. Instead of
conditionally exposing these API methods we make them into no-ops if DFG is disabled.
* API/JSVirtualMachine.mm:
(+[JSVirtualMachine setNumberOfDFGCompilerThreads:]):
(+[JSVirtualMachine setNumberOfFTLCompilerThreads:]):
* API/JSVirtualMachinePrivate.h:
2021-04-01 Alexey Shvayka <shvaikalesh@gmail.com>
Optimize createListFromArrayLike() and Proxy's [[OwnPropertyKeys]] method
https://bugs.webkit.org/show_bug.cgi?id=223928
Reviewed by Yusuke Suzuki.
createListFromArrayLike() changes:
1. Use toLength() / getIndex() methods that have fast paths.
2. Remove RuntimeTypeMask and error messages from its signature: type checks are better
performed in advance / inside a functor to keep the helper more versatile.
3. Invert functor's return value to align with Structure::forEachProperty() and friends.
4. Rename it to forEachInArrayLike() as no list is actually returned.
ProxyObject::performGetOwnPropertyNames() changes:
1. Remove RuntimeTypeMask filtering as it's already performed by PropertyNameArray::add().
2. Store target's keys in a HashSet for faster insertion / search.
3. Don't populate `targetConfigurableKeys` for extensible target as it won't be used [1].
4. Leverage return value of HashSet::remove() instead of using a helper.
This patch advances Proxy's [[OwnPropertyKeys]] microbenchmarks by 20-30%,
mainly due to createListFromArrayLike() changes. No behavior changes.
Also, utilizes forEachInArrayLike() for allow list of JSON.stringify().
[1]: https://tc39.es/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-ownpropertykeys (step 20)
* runtime/JSONObject.cpp:
(JSC::Stringifier::Stringifier):
* runtime/JSObject.h:
(JSC::JSObject::getIndex const):
* runtime/JSObjectInlines.h:
(JSC::forEachInArrayLike):
(JSC::createListFromArrayLike): Deleted.
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::performGetOwnPropertyNames):
* runtime/ReflectObject.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
2021-03-31 David Kilzer <ddkilzer@apple.com>
UBSan: JSC::Parser<LexerType>::parseProperty(): runtime error: load of value nnn, which is not a valid value for type 'bool'
<https://webkit.org/b/223896>
<rdar://problem/75970132>
Reviewed by Darin Adler.
Based on a suggestion by Darin Adler.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseProperty):
- Change 'escaped' to 'wasUnescapedIdent' to avoid the undefined
behavior since m_token.m_data.escaped is only set in the case
when an identifer is parsed (in Lexer<>::parseIdentifer()),
not a string (in Lexer<>::parseString()). This simplifies the
logic later in the method.
2021-03-31 Mark Lam <mark.lam@apple.com>
Missing exception check in HashMapImpl::add().
https://bugs.webkit.org/show_bug.cgi?id=224007
rdar://76053163
Reviewed by Saam Barati.
* runtime/HashMapImpl.h:
(JSC::HashMapImpl::add):
2021-03-31 Xan Lopez <xan@igalia.com>
[JSC] Remove warnings about unnecessary operator= for ARMv7Assembler LinkRecord
https://bugs.webkit.org/show_bug.cgi?id=223916
Reviewed by Darin Adler.
Many years ago we defined an assignment operator for LinkRecord in
order to speed up build times (see #90930). Recent GCC versions
tell us that if we do that we almost certainly want to define a
copy constructor too. The ARM64Assembler file already does it, so
do it too for ARMv7 to remove the warnings.
* assembler/ARM64Assembler.h:
* assembler/ARMv7Assembler.h:
(JSC::ARMv7Assembler::LinkRecord::LinkRecord):
(JSC::ARMv7Assembler::LinkRecord::operator=):
2021-03-31 Alexey Shvayka <shvaikalesh@gmail.com>
Optimize constructors of ES6 collections
https://bugs.webkit.org/show_bug.cgi?id=223953
Reviewed by Yusuke Suzuki.
This patch speeds up the constructors by avoiding call() for non-observable
"set" / "add" methods and using getIndex() for Map / WeakMap collections.
For Map / Set, this change leverages existing cloning helpers, which rely on
watchpoints, to avoid even a method lookup. However, slower path is used for
subclasses. Results in 1.9x speed-up for common case.
For WeakMap / WeakSet, adder function is checked by C++ pointer, which enables
fast path even for cross-realm subclasses. Results in 2.3x progression.
Both approaches require special handling of a cross-realm NewTarget to ensure
that raised exceptions (OOM / TypeError) belong to realm of the adder function,
and not to constructor's or NewTarget's.
Also, adds descriptve error messages for non-callable "set" / "add" properties.
* runtime/JSMap.cpp:
(JSC::JSMap::isSetFastAndNonObservable):
(JSC::JSMap::canCloneFastAndNonObservable): Deleted.
* runtime/JSMap.h:
* runtime/JSSet.cpp:
(JSC::JSSet::isAddFastAndNonObservable):
(JSC::JSSet::canCloneFastAndNonObservable): Deleted.
* runtime/JSSet.h:
* runtime/MapConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/SetConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/WeakMapConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/WeakMapPrototype.cpp:
(JSC::WeakMapPrototype::finishCreation):
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/WeakMapPrototype.h:
* runtime/WeakSetConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/WeakSetPrototype.cpp:
(JSC::WeakSetPrototype::finishCreation):
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/WeakSetPrototype.h:
2021-03-30 Devin Rousso <drousso@apple.com>
REGRESSION(r274607): media controls script is visible in Web Inspector even without the engineering "Show WebKit-internal scripts" enabled
https://bugs.webkit.org/show_bug.cgi?id=223961
Reviewed by Yusuke Suzuki.
It turns out that Web Inspector will only ignore scripts that have a source URL directive
that matches `__InjectedScript_*.js`, not those that have a (source) URL matching that.
In addition to Web Inspector ignoring these scripts in the UI, it will also cause the
`Debugger` to not pause in scripts with a matching source URL directive (unless the
local build engineering only "Pause in WebKit-internal scripts" is enabled).
* Scripts/make-js-file-arrays.py:
(main):
Add a `//# sourceURL=__InjectedScript_*.js` to the contents before it's encoded.
2021-03-30 Sam Weinig <weinig@apple.com>
JSGlobalObject's m_customGetterFunctionMap and m_customSetterFunctionMap should be sets, not maps, and should use both the identifier and function pointer as the key
https://bugs.webkit.org/show_bug.cgi?id=223613
Reviewed by Saam Barati.
- Adds a generic WeakGCSet class to go with the existing WeakGCMap.
- Renames WeakGCMapBase to WeakGCHashTable, moves it to its own file
and now uses it as the base class of both WeakGCSet and WeakGCMap.
- Replaces JSGlobalObject's customGetterFunctionMap/customSetterFunctionMap
with customGetterFunctionSet/customSetterFunctionSet, using the new
WeakGCSet, and updates them to use both the function pointer and
property name for the key, rather than just the function pointer which
is what the previous code did. This allows multiple custom functions
to use the same underlying function pointer as long as they have distinct
property names, which is going to be used to optimize the bindings for
CSSStyleDeclaration.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
Add new files.
* heap/Heap.cpp:
(JSC::Heap::runEndPhase):
(JSC::Heap::pruneStaleEntriesFromWeakGCHashTables):
(JSC::Heap::registerWeakGCHashTable):
(JSC::Heap::unregisterWeakGCHashTable):
(JSC::Heap::pruneStaleEntriesFromWeakGCMaps): Deleted.
(JSC::Heap::registerWeakGCMap): Deleted.
(JSC::Heap::unregisterWeakGCMap): Deleted.
* heap/Heap.h:
Update for new name. WeakGCMapBase -> WeakGCHashTable.
* runtime/JSCInlines.h:
Add WeakGCSetInlines.h
* runtime/JSCustomGetterFunction.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::JSCustomGetterFunction::JSCustomGetterFunction):
(JSC::JSCustomGetterFunction::create):
* runtime/JSCustomGetterFunction.h:
* runtime/JSCustomSetterFunction.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::JSCustomSetterFunction::JSCustomSetterFunction):
(JSC::JSCustomSetterFunction::create):
* runtime/JSCustomSetterFunction.h:
Add helper type CustomFunctionPointer and helper function customFunctionPointer()
to allow some generic hashing code to run on either JSCustomGetterFunction
or JSCustomSetterFunction.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::JSGlobalObject):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::WeakCustomGetterOrSetterHash::hash):
(JSC::JSGlobalObject::WeakCustomGetterOrSetterHash::equal):
(JSC::JSGlobalObject::customGetterFunctionSet):
(JSC::JSGlobalObject::customSetterFunctionSet):
(JSC::JSGlobalObject::customGetterFunctionMap): Deleted.
(JSC::JSGlobalObject::customSetterFunctionMap): Deleted.
Replace m_customGetterFunctionMap/m_customSetterFunctionMap with
m_customGetterFunctionSet/m_customSetterFunctionSet. As the key is included
in the value, it saves space to use a set rather than a map. We now also
hash and compare both the function pointer and the property name to allow
sharing implementations.
* runtime/JSObject.cpp:
(JSC::WeakCustomGetterOrSetterHashTranslator::hash):
(JSC::WeakCustomGetterOrSetterHashTranslator::equal):
(JSC::createCustomGetterFunction):
(JSC::createCustomSetterFunction):
Update creation functions to use the new sets, making use of the
ensureValue function and a HashTranslator allowing the use of a
std::pair<PropertyName, FunctionPointer> as an alternative lookup
key. This allows us to avoid creating the JSCustomGetterFunction/JSCustomSetterFunction
pointer if one with the same property name and function pointer are
already in the set.
* runtime/WeakGCHashTable.h: Added.
(JSC::WeakGCHashTable::~WeakGCHashTable):
Moved from WeakGCMap and renamed as it is now the base of both
WeakGCMap and WeakGCSet.
* runtime/WeakGCMap.h:
Update to use new WeakGCHashTable base class.
* runtime/WeakGCMapInlines.h:
(JSC::KeyTraitsArg>::WeakGCMap):
(JSC::KeyTraitsArg>::~WeakGCMap):
Update for new Heap function names for WeakGCHashTable.
* runtime/WeakGCSet.h: Added.
* runtime/WeakGCSetInlines.h: Added.
(JSC::TraitsArg>::WeakGCSet):
(JSC::TraitsArg>::~WeakGCSet):
(JSC::TraitsArg>::find):
(JSC::TraitsArg>::find const):
(JSC::TraitsArg>::contains const):
(JSC::TraitsArg>::pruneStaleEntries):
Added a minimal WeakGCSet based on WeakGCMap.
2021-03-30 Mark Lam <mark.lam@apple.com>
Add disableForwardingVPrintfStdErrToOSLog() and use it in the jsc shell.
https://bugs.webkit.org/show_bug.cgi?id=223963
Reviewed by Saam Barati.
This prevents automatic forwarding of vprintf_stderr_common() to os_log_with_args(),
which results in duplicate output when using the jsc shell. As a result, ASSERT
fail messages and crash stack traces will be more readable.
* jsc.cpp:
(main):
2021-03-30 Mark Lam <mark.lam@apple.com>
Add Options::exitOnResourceExhaustion() to enable exiting instead of crashing on resource exhaustion.
https://bugs.webkit.org/show_bug.cgi?id=223959
rdar://63934158
Reviewed by Tadeu Zagallo.
This is useful to unblock fuzzers from false positive crashes due to resource
exhaustion. Currently, this is only applied to StructureID exhaustion.
Since we're adding this facility, we might as well implement it in such a way that
it can be easily deployed for other types of resource exhaustion as well.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* runtime/OptionsList.h:
* runtime/ResourceExhaustion.cpp: Added.
(JSC::handleResourceExhaustion):
* runtime/ResourceExhaustion.h: Added.
* runtime/StructureIDTable.cpp:
(JSC::StructureIDTable::resize):
2021-03-30 Ryan Haddad <ryanhaddad@apple.com>
Ensure that GlobalPropertyInfo is allocated on the stack.
https://bugs.webkit.org/show_bug.cgi?id=223911
Unreviewed test gardening.
Rebaseline builtins generator tests after r275212.
* Scripts/tests/builtins/expected/WebCoreJSBuiltins.h-result:
2021-03-30 Mark Lam <mark.lam@apple.com>
Add more information to GC verifier verbose dumps.
https://bugs.webkit.org/show_bug.cgi?id=223951
Reviewed by Yusuke Suzuki.
* heap/VerifierSlotVisitor.cpp:
(JSC::VerifierSlotVisitor::dumpMarkerData):
2021-03-30 Mark Lam <mark.lam@apple.com>
Ensure that GlobalPropertyInfo is allocated on the stack.
https://bugs.webkit.org/show_bug.cgi?id=223911
rdar://75865742
Reviewed by Yusuke Suzuki.
We rely on GlobalPropertyInfo being allocated on the stack to allow its JSValue
value to be scanned by the GC. Unfortunately, an ASAN compilation would choose
to allocate the GlobalPropertyInfo on a side buffer instead of directly on the
stack. This prevents the GC from doing the needed scan.
We'll fix this by suppressing ASAN on the functions that allocated GlobalPropertyInfo
arrays. Also added an ASSERT in the GlobalPropertyInfo constructor to assert that
it is allocated on the stack.
* Scripts/wkbuiltins/builtins_generate_internals_wrapper_implementation.py:
(BuiltinsInternalsWrapperImplementationGenerator.generate_initialize_method):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::initStaticGlobals):
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::exposeDollarVM):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::GlobalPropertyInfo::GlobalPropertyInfo):
2021-03-29 Xan López <xan@igalia.com>
[JSC] Use helper method when possible to store data in the callframe header
https://bugs.webkit.org/show_bug.cgi?id=223432
Reviewed by Yusuke Suzuki.
A bunch of the direct stores to the callframe header are zeroing
out the codeblock slot. Create a helper method to do that and use
it accordingly. For the rest, use emitPutToCallFrameHeader, which
already does the right thing. Also, remove a lot of unused helper
methods in AssemblyHelpers (which have been updated for no reason
throughout the years).
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::emitPutToCallFrameHeaderBeforePrologue): Deleted.
(JSC::AssemblyHelpers::emitPutPayloadToCallFrameHeaderBeforePrologue): Deleted.
(JSC::AssemblyHelpers::emitPutTagToCallFrameHeaderBeforePrologue): Deleted.
* wasm/js/JSToWasm.cpp:
(JSC::Wasm::createJSToWasmWrapper):
* wasm/js/WasmToJS.cpp:
(JSC::Wasm::wasmToJS):
* wasm/js/WebAssemblyFunction.cpp:
(JSC::WebAssemblyFunction::jsCallEntrypointSlow):
2021-03-28 Sam Weinig <weinig@apple.com>
Remove ENABLE_INDEXED_DATABASE & ENABLE_INDEXED_DATABASE_IN_WORKERS, it seems like it is on for all ports
https://bugs.webkit.org/show_bug.cgi?id=223810
Reviewed by Simon Fraser.
* inspector/protocol/IndexedDB.json:
Update for remove ENABLE_INDEXED_DATABASE conditional.
2021-03-26 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Use AppleICU SPI for canonicalization
https://bugs.webkit.org/show_bug.cgi?id=223552
Reviewed by Ryosuke Niwa.
uloc_canonicalize does not perform alias mapping. This is different from ECMA402's canonicalization requirement.
ICU C++ icu::Locale can canonicalize locale ID with alias mapping, but this is not exposed to C API.
In this patch, we adopt AppleICU SPI "ualoc_canonicalForm" added in rdar://74314220. This canonicalization can perform
alias mapping too. We do not extend uloc_canonicalize since this API explicitly says "It does NOT map aliased names in any way."[1].
In [2], we are tracking upstreaming of this new SPI. Once it is upstreamed to the mainline ICU, we will switch to that.
[1]: https://unicode-org.github.io/icu-docs/apidoc/dev/icu4c/uloc_8h.html#a69b148194cf57ac40d4bb15c5b905260
[2]: https://unicode-org.atlassian.net/browse/ICU-21506
* runtime/IntlLocale.cpp:
(JSC::LocaleIDBuilder::initialize):
(JSC::LocaleIDBuilder::toCanonical):
* runtime/IntlObject.cpp:
(JSC::localeIDBufferForLanguageTagWithNullTerminator):
(JSC::canonicalizeLanguageTag):
(JSC::canonicalizeLocaleIDWithoutNullTerminator):
(JSC::localeIDBufferForLanguageTag): Deleted.
* runtime/IntlObject.h:
2021-03-26 Don Olmstead <don.olmstead@sony.com>
[CMake] Deprecate using DERIVED_SOURCES_DIR/FOWARDING_HEADERS_DIR directly
https://bugs.webkit.org/show_bug.cgi?id=223763
Reviewed by Michael Catanzaro.
Remove any usages of DERIVED_SOURCES_DIR and FOWARDING_HEADERS_DIR.
* CMakeLists.txt:
* PlatformMac.cmake:
2021-03-26 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Use new Apple ICU APIs to avoid C++ ICU API usage
https://bugs.webkit.org/show_bug.cgi?id=223783
<rdar://problem/75060240>
Reviewed by Mark Lam.
This patch adopts ICU 69's draft APIs to avoid using ICU C++ APIs in newer macOS build.
AppleICU adopts these draft APIs so that we can use it even in ICU 68 if ICU is AppleICU.
The API is ucal_getTimeZoneOffsetFromLocal, which is back-ported from ICU 69[1].
The purpose of this API is that calculating timezone offset and dst offset from *local* time.
[1]: https://github.com/unicode-org/icu/commit/53aa0505c5f95a8cebbd7b4421d474fd2a790b80
* runtime/IntlDateTimeFormat.cpp:
* runtime/JSDateMath.cpp:
(JSC::OpaqueICUTimeZoneDeleter::operator()):
(JSC::DateCache::calculateLocalTimeOffset):
(JSC::DateCache::defaultTimeZone):
(JSC::DateCache::timeZoneCacheSlow):
* runtime/JSDateMath.h:
2021-03-26 Jessie Berlin <jberlin@webkit.org>
Update the BEFORE/SINCE, SYSTEM_VERSION_PREFIX, and MACOSX_DEPLOYMENT_TARGET flags
https://bugs.webkit.org/show_bug.cgi?id=223779
Reviewed by Tim Horton.
* Configurations/DebugRelease.xcconfig:
* Configurations/Version.xcconfig:
* Configurations/WebKitTargetConditionals.xcconfig:
2021-03-25 Saam Barati <sbarati@apple.com>
validate untagArrayPtr
https://bugs.webkit.org/show_bug.cgi?id=214953
<rdar://problem/66391434>
Reviewed by Mark Lam.
This patch adds validation to untagArrayPtr along paths where we don't
immediately store/load from the result.
This patch also changes the removeArrayPtrTag macro assembler function to
use a bitwise and instead of xpacd to strip the tag, because it's faster.
* assembler/MacroAssemblerARM64E.h:
(JSC::MacroAssemblerARM64E::untagArrayPtr):
(JSC::MacroAssemblerARM64E::removeArrayPtrTag):
* assembler/testmasm.cpp:
(JSC::testCagePreservesPACFailureBit):
* bytecode/AccessCase.cpp:
(JSC::AccessCase::generateWithGuard):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::cageTypedArrayStorage):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::untagArrayPtr):
(JSC::FTL::DFG::LowerDFGToB3::caged):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::cageWithoutUntagging):
(JSC::AssemblyHelpers::cageConditionallyAndUntag):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::cageWithoutUntagging): Deleted.
(JSC::AssemblyHelpers::cageConditionally): Deleted.
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitIntTypedArrayPutByVal):
(JSC::JIT::emitFloatTypedArrayPutByVal):
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState):
(JSC::Wasm::AirIRGenerator::addCallIndirect):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
(JSC::Wasm::B3IRGenerator::addCallIndirect):
* wasm/WasmBinding.cpp:
(JSC::Wasm::wasmToWasm):
* wasm/js/JSToWasm.cpp:
(JSC::Wasm::createJSToWasmWrapper):
* wasm/js/WebAssemblyFunction.cpp:
(JSC::WebAssemblyFunction::jsCallEntrypointSlow):
2021-03-25 Jessie Berlin <jberlin@webkit.org>
Remove 10.13 DEPLOYMENT_TARGETs and SYSTEM_VERSION_PREFIXs
https://bugs.webkit.org/show_bug.cgi?id=223765
Reviewed by Tim Horton.
* Configurations/Base.xcconfig:
* Configurations/DebugRelease.xcconfig:
* Configurations/Version.xcconfig:
2021-03-25 Carlos Garcia Campos <cgarcia@igalia.com>
[GTK][WPE] JSC crashes if a function expects a parameter but doesn't receive any
https://bugs.webkit.org/show_bug.cgi?id=223646
Reviewed by Adrian Perez de Castro.
Handle the case of receiving fewer argumens than expected in function calls and constructors. We pass undefined
for the expected arguments that are missing. We were not correctly handling the case of converting undefined and
null values to JSCValue, so this patch fixes that case too.
* API/glib/JSCCallbackFunction.cpp:
(JSC::JSCCallbackFunction::call):
(JSC::JSCCallbackFunction::construct):
* API/glib/JSCContext.cpp:
(jscContextJSValueToWrappedObject):
(jscContextJSValueToGValue):
2021-03-24 Michael Saboff <msaboff@apple.com>
[YARR] Interpreter incorrectly matches non-BMP characters with multiple . w/dotAll flag
https://bugs.webkit.org/show_bug.cgi?id=223666
Reviewed by Mark Lam.
In checkCharacterClassDontAdvanceInputForNonBMP(), we need to check for input.readChecked() returning -1
and return that the character class didn't match.
* yarr/YarrInterpreter.cpp:
(JSC::Yarr::Interpreter::checkCharacterClassDontAdvanceInputForNonBMP):
2021-03-24 Saam Barati <sbarati@apple.com>
r271034 added code in constant folding phase that's unreachable given current invariants of our ICs and PutByIdStatus
https://bugs.webkit.org/show_bug.cgi?id=223625
Reviewed by Yusuke Suzuki.
The code was doing a lot of wrong things by making bad assumptions about the
invariants of PutByIdVariants. Replace PutByIdVariants never have object
property condition sets, since we always replace on the self object (and don't
look at the prototype chain). This patch clears up the code to make it
clearer what the invariants are.
With respect to the original fix about not emitting a PutByOffset for a
Replace on a Structure that has an unfired replacement watchpoint set,
that was already handled by the PutByIdStatus::computeFor variant we're
calling inside of constant folding. It will return TakesSlowPathif it
encounters a Replace where the Structure still has an unfired watchpoint.
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::tryFoldAsPutByOffset):
2021-03-24 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Rope string equal operation should first check length
https://bugs.webkit.org/show_bug.cgi?id=223678
Reviewed by Mark Lam.
This can avoid eagerly resolving rope strings if it is not necessary.
* runtime/JSString.cpp:
(JSC::JSString::equalSlowCase const):
2021-03-23 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Functor for WeakGCMap::ensureValue must not invoke GC
https://bugs.webkit.org/show_bug.cgi?id=223629
<rdar://problem/75619217>
Reviewed by Mark Lam.
The functor for WeakGCMap::ensureValue must not invoke GC. GC can prune entries in WeakGCMap.
So we can modify underlying HashMap while we are just touching it for HashMap::ensure. This
can corrupt HashMap. To ensure this invariant, we put DisallowGC for WeakGCMap::ensureValue.
So we cannot invoke GC in the functor of that function (otherwise, assertion hits).
And we use DeferGC in createCustomGetterFunction / createCustomSetterFunction to avoid invoking
GC in WeakGCMap::ensureValue. This defers GC invocation until this DeferGC scope is destroyed,
and ensures that functor invoked by WeakGCMap::ensureValue will not cause GC.
* runtime/JSObject.cpp:
(JSC::createCustomGetterFunction):
(JSC::createCustomSetterFunction):
(JSC::JSObject::getOwnPropertyDescriptor):
* runtime/WeakGCMap.h:
2021-03-23 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Use ErrorInstance for AggregateError
https://bugs.webkit.org/show_bug.cgi?id=223626
Reviewed by Darin Adler.
From r274609, WebAssembly errors start using normal ErrorInstance. We apply the same thing to AggregateError too.
This patch removes AggregateError class, and just generating ErrorInstance.
* runtime/AggregateError.cpp:
(JSC::createAggregateError):
(JSC::AggregateError::AggregateError): Deleted.
(JSC::AggregateError::finishCreation): Deleted.
(JSC::AggregateError::create): Deleted.
* runtime/AggregateError.h:
(): Deleted.
* runtime/AggregateErrorConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::initializeAggregateErrorConstructor):
2021-03-23 Robin Morisset <rmorisset@apple.com>
Object.freeze(this) at the global scope can lose a reference to a WatchpointSet
https://bugs.webkit.org/show_bug.cgi?id=223608
Reviewed by Yusuke Suzuki.
When freezing the global object, we should make a proper copy of symbol table entries, to keep any outstanding reference to the WatchpointSet.
We cannot use pack(), because it does not support FatEntries.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::defineOwnProperty):
* runtime/JSSymbolTableObject.h:
(JSC::symbolTableGet):
* runtime/SymbolTable.h:
(JSC::SymbolTableEntry::setReadOnly):
2021-03-22 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] JSCustomGetterFunction/JSCustomSetterFunction should use Identifier for their field
https://bugs.webkit.org/show_bug.cgi?id=223588
Reviewed by Mark Lam and Saam Barati.
PropertyName is the holder for passing it as an argument, and it does not ref/deref underlying UniqueStringImpl.
We should use Identifier to keep it strongly ref-ed in JSCustomGetterFunction/JSCustomSetterFunction.
And we should make JSCustomGetterFunction/JSCustomSetterFunction destructible objects since Identifier needs to
deref underlying UniqueStringImpl when destroying these functions.
* runtime/JSCustomGetterFunction.cpp:
(JSC::JSCustomGetterFunction::JSCustomGetterFunction):
(JSC::JSCustomGetterFunction::destroy):
* runtime/JSCustomGetterFunction.h:
* runtime/JSCustomSetterFunction.cpp:
(JSC::JSCustomSetterFunction::JSCustomSetterFunction):
(JSC::JSCustomSetterFunction::destroy):
* runtime/JSCustomSetterFunction.h:
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2021-03-22 Saam Barati <sbarati@apple.com>
LiteralParser shouldn't make error messages of length ~2^31
https://bugs.webkit.org/show_bug.cgi?id=223483
<rdar://75572255>
Reviewed by Robin Morisset.
* runtime/LiteralParser.cpp:
(JSC::LiteralParser<CharType>::parse):
2021-03-22 Michael Saboff <msaboff@apple.com>
[YARR] Interpreter incorrectly matches non-BMP characters with multiple .
https://bugs.webkit.org/show_bug.cgi?id=223498
Reviewed by Yusuke Suzuki.
We need to check that we read an actual character before seeing if it is part of a character class.
In the case where we are checking that a character is not in a character class, like .,
the failed to read result from input.readChecked(), -1, is not part of the newline character class.
This will allow regular expressions that require more than the number of characters in a string
to match.
* yarr/YarrInterpreter.cpp:
(JSC::Yarr::Interpreter::checkCharacterClass):
2021-03-22 Ross Kirsling <ross.kirsling@sony.com>
Unreviewed, fix Mac and non-unified JSCOnly builds
https://bugs.webkit.org/show_bug.cgi?id=223546
* wasm/WasmGlobal.h:
* wasm/WasmTable.h:
* wasm/js/JSWebAssemblyCompileError.cpp:
* wasm/js/JSWebAssemblyLinkError.cpp:
* wasm/js/JSWebAssemblyRuntimeError.cpp:
Add missing includes for non-unified JSC build.
2021-03-22 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Intl.Locale should not assume is8Bit
https://bugs.webkit.org/show_bug.cgi?id=223553
Reviewed by Ross Kirsling.
is8Bit or not is not guaranteed if it is an user-input. For example, "test日本語".substring(0, 3) should be non 8Bit string.
Intl.Locale has several places that assumed that input should be 8Bit if they are ASCII. This patch fixes it.
* runtime/IntlLocale.cpp:
(JSC::LocaleIDBuilder::overrideLanguageScriptRegion):
(JSC::LocaleIDBuilder::setKeywordValue):
2021-03-22 Sam Weinig <weinig@apple.com>
Use the PropertyName parameter passed to custom getters/setters rather than a redundant const char* in DOM attribute prologues
https://bugs.webkit.org/show_bug.cgi?id=223542
Reviewed by Alexey Shvayka.
Add throwVMDOMAttributeSetterTypeError to match existing throwVMDOMAttributeGetterTypeError and move
additional helpers used by WebCore here to avoid redundant work.
Removes some now unused functions.
* runtime/Error.cpp:
(JSC::createGetterTypeError):
(JSC::makeDOMAttributeGetterTypeErrorMessage):
(JSC::makeDOMAttributeSetterTypeErrorMessage):
(JSC::throwDOMAttributeGetterTypeError):
(JSC::throwDOMAttributeSetterTypeError):
(JSC::throwGetterTypeError): Deleted.
* runtime/Error.h:
(JSC::throwVMRangeError):
(JSC::throwVMDOMAttributeSetterTypeError):
(JSC::throwVMGetterTypeError): Deleted.
2021-03-22 Tyler Wilcock <twilco.o@protonmail.com>
AppleWin can't start due to "Failed to determine path to AAS directory." because iTunes changed the registry key
https://bugs.webkit.org/show_bug.cgi?id=219015
Reviewed by Alex Christensen.
It appears that iTunes no longer sets the Apple Application Support
registry entry. Fall back to trying to find the iTunes installation
directory if the AAS directory is not present.
* shell/DLLLauncherMain.cpp:
(iTunesDirectory): Added.
(modifyPath):
2021-03-19 Darin Adler <darin@apple.com>
[Cocoa] Make it possible to release a WKWebView on a non-main thread without a crash due to WKScriptMessage race
https://bugs.webkit.org/show_bug.cgi?id=222336
Reviewed by Chris Dumez.
* API/ObjcRuntimeExtras.h: Removed declarations of objc_initWeak and objc_destroyWeak, since
these are already in <wtf/spi/cocoa/objcSPI.h>.
2021-03-19 Mark Lam <mark.lam@apple.com>
BrandedStructure should keep its members alive.
https://bugs.webkit.org/show_bug.cgi?id=223495
rdar://75565765
Reviewed by Saam Barati.
Normally, each type of JSCell would have its own structure (and therefore, its own
ClassInfo, MethodTable, etc), which would have handled visiting m_parentBrand.
Similarly, it would have its own destructor, which would deref m_brand.
However, the design of BrandedStructure is not like other JSCells. As present,
we have chosen to go with having BrandedStructure look exactly like a regular
Structure, except that its isBrandedStructure flag is set to true.
This design has advantages because we do checks all over the system for whether
a cell is a Structure by simply comparing its structureID to structureStructure's
structureID. By virtue of BrandedStructure having the same structure as Structure,
none of this code need to change.
The downside is that we need to enhance Structure's methods to check if it is
actually working on an instance of BrandedStructure, and do some additional work.
This patch fixes 2 bugs:
1. m_parentBrand was not visited by visitChildren().
Structure::visitChildrenImpl() now calls BrandedStructure::visitAdditionalChildren()
to handle this.
2. m_brand needs to be ref'ed.
In Structure::setBrandTransition(), if the BrandedStructure is a dictionary,
then its m_transitionPropertyName will be cleared. m_transitionPropertyName
was the only means by which the UniqueStringImpl pointed to by m_brand was
ref'ed. The fix is to make m_brand a RefPtr.
Hence, it follows that we also need to deref m_brand on destruction.
Structure's destructor now calls BrandedStructure::destruct() to handle this.
* runtime/BrandedStructure.h:
* runtime/Structure.cpp:
(JSC::Structure::~Structure):
(JSC::Structure::visitChildrenImpl):
2021-03-19 Sam Weinig <weinig@apple.com>
Add PropertyName parameter to custom setters to allow shared implementations to do late name lookup
https://bugs.webkit.org/show_bug.cgi?id=223413
Reviewed by Alexey Shvayka.
Make custom setters match custom getters by adding a PropertyName parameter.
This will be used by the CSSStyleDeclaration bindings to avoid > 1000 copies
of the same getter/setter code, which will instead be able to differentiate
using the name.
* bytecode/AccessCase.cpp:
(JSC::AccessCase::generateImpl):
* jsc.cpp:
(JSC_DEFINE_CUSTOM_SETTER):
* runtime/CustomGetterSetter.cpp:
(JSC::callCustomSetter):
* runtime/CustomGetterSetter.h:
* runtime/JSCJSValue.cpp:
(JSC::JSValue::putToPrimitive):
* runtime/JSCustomSetterFunction.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::JSCustomSetterFunction::JSCustomSetterFunction):
(JSC::JSCustomSetterFunction::create):
* runtime/JSCustomSetterFunction.h:
* runtime/JSObject.cpp:
(JSC::JSObject::putInlineSlow):
* runtime/Lookup.h:
(JSC::putEntry):
* runtime/PropertySlot.h:
* runtime/RegExpConstructor.cpp:
(JSC::JSC_DEFINE_CUSTOM_SETTER):
* runtime/RegExpObject.cpp:
(JSC::JSC_DEFINE_CUSTOM_SETTER):
* tools/JSDollarVM.cpp:
== Rolled over to ChangeLog-2021-03-18 ==