Google Git
Sign in
webkit / WebKit / 15e4da4b5ce83fcfe6de6863df44c60571019d5f / . / Source / JavaScriptCore / ChangeLog-2021-03-18
blob: 38b77e6cf51b4be184f3372c099522e35dcd3296 [file] [log] [blame]
2021-03-18 Saam Barati <sbarati@apple.com>
JS->Wasm IC must save the tag registers if it uses them
https://bugs.webkit.org/show_bug.cgi?id=223491
<rdar://66445108>
Reviewed by Yusuke Suzuki.
It turns out, that when you use a callee save register, you should save it.
* wasm/js/WebAssemblyFunction.cpp:
(JSC::WebAssemblyFunction::usesTagRegisters const):
(JSC::WebAssemblyFunction::calleeSaves const):
(JSC::WebAssemblyFunction::jsCallEntrypointSlow):
(JSC::WebAssemblyFunction::useTagRegisters const): Deleted.
* wasm/js/WebAssemblyFunction.h:
2021-03-17 Ross Kirsling <ross.kirsling@sony.com>
[JSC] Error#cause should apply to WebAssembly error constructors too
https://bugs.webkit.org/show_bug.cgi?id=223404
Reviewed by Yusuke Suzuki.
Per https://www.w3.org/TR/wasm-js-api-1/#error-objects:
> The constructor and properties of WebAssembly errors is as specified for NativeError.
So Error#cause should "just work" for WebAssembly.{CompileError, LinkError, RuntimeError} too.
In the process:
- Eliminate JSWebAssemblyCompileError and kin since they add no functionality on top of ErrorInstance.
- Add an on-by-default feature flag (belated from the last patch).
* API/JSObjectRef.cpp:
(JSObjectMakeError):
* runtime/AggregateErrorConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/ErrorConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/JSGlobalObject.h:
* runtime/NativeErrorConstructor.cpp:
(JSC::NativeErrorConstructor<errorType>::constructImpl):
(JSC::NativeErrorConstructor<errorType>::callImpl):
* runtime/OptionsList.h:
* wasm/WasmOperations.cpp:
(JSC::Wasm::JSC_DEFINE_JIT_OPERATION):
* wasm/js/JSWebAssemblyCompileError.cpp:
(JSC::createJSWebAssemblyCompileError):
(JSC::JSWebAssemblyCompileError::create): Deleted.
(JSC::JSWebAssemblyCompileError::JSWebAssemblyCompileError): Deleted.
* wasm/js/JSWebAssemblyCompileError.h:
(): Deleted.
* wasm/js/JSWebAssemblyInstance.cpp:
(JSC::JSWebAssemblyInstance::finalizeCreation):
* wasm/js/JSWebAssemblyLinkError.cpp:
(JSC::createJSWebAssemblyLinkError):
(JSC::JSWebAssemblyLinkError::create): Deleted.
(JSC::JSWebAssemblyLinkError::JSWebAssemblyLinkError): Deleted.
* wasm/js/JSWebAssemblyLinkError.h:
(): Deleted.
* wasm/js/JSWebAssemblyModule.cpp:
(JSC::JSWebAssemblyModule::createStub):
* wasm/js/JSWebAssemblyRuntimeError.cpp:
(JSC::createJSWebAssemblyRuntimeError):
(JSC::JSWebAssemblyRuntimeError::create): Deleted.
(JSC::JSWebAssemblyRuntimeError::JSWebAssemblyRuntimeError): Deleted.
* wasm/js/JSWebAssemblyRuntimeError.h:
(): Deleted.
* wasm/js/WebAssemblyCompileErrorConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* wasm/js/WebAssemblyLinkErrorConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
2021-03-17 Yusuke Suzuki <ysuzuki@apple.com>
modern-media-controls script should not be allocated in heap
https://bugs.webkit.org/show_bug.cgi?id=223309
Reviewed by Devin Rousso.
Add --fail-if-non-ascii flag to ensure that input files do not include non-ASCII characters.
* Scripts/make-js-file-arrays.py:
(main):
2021-03-17 Saam Barati <sbarati@apple.com>
Determine if we have useFastJITPermissions on arm64e at runtime instead of hardcoding it as always enabled
https://bugs.webkit.org/show_bug.cgi?id=223388
<rdar://74819266>
Reviewed by Mark Lam.
* assembler/FastJITPermissions.h:
(threadSelfRestrictRWXToRW):
(threadSelfRestrictRWXToRX):
(useFastJITPermissions): Deleted.
(fastJITPermissionsIsSupported): Deleted.
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::copyCompactAndLinkCode):
* jit/ExecutableAllocator.cpp:
(JSC::initializeJITPageReservation):
* jit/ExecutableAllocator.h:
(JSC::performJITMemcpy):
* runtime/JSCConfig.h:
2021-03-17 Mark Lam <mark.lam@apple.com>
Enhance --verboseVerifyGC=true to make it easier to debug GC verifier errors.
https://bugs.webkit.org/show_bug.cgi?id=223401
Reviewed by Saam Barati.
Previously, --verboseVerifyGC=true only dumps the stack trace of the immediate code
path (in the verifier GC) that marked the object that the real GC did not. With
this patch, we'll also dump the trace of the marking chain all the way back to a
GC root. This patch also adds support for tracing the marking chain through opaque
roots.
The marking chain provided is the one that the verifier GC walked. To debug the
error, we use this info and check where the real GC deviates.
Here's an example of the new dump of a GC verifier error:
GC Verifier: ERROR cell 0x12c570500 was not marked
Object: 0x12c570500 with butterfly 0x0 (Structure 0x108eb6d10:[0x3ba8, ArrayBuffer, {}, NonArray, Proto:0x108ed7d90, Leaf]), StructureID: 15272
Cell 0x12c570500 was visited via opaque root 0x10e4b52c0 at:
1 0x100acccdc JSC::VerifierSlotVisitor::appendUnbarriered(JSC::JSCell*)
2 0x100ad0c2f void JSC::WeakBlock::specializedVisit<JSC::MarkedBlock, JSC::AbstractSlotVisitor>(JSC::MarkedBlock&, JSC::AbstractSlotVisitor&)
3 0x100abec2b void JSC::MarkedSpace::visitWeakSets<JSC::AbstractSlotVisitor>(JSC::AbstractSlotVisitor&)
4 0x100aa5167 WTF::Detail::CallableWrapper<JSC::Heap::addCoreConstraints()::$_38, void, JSC::AbstractSlotVisitor&>::call(JSC::AbstractSlotVisitor&)
5 0x100ac1411 JSC::MarkingConstraintSet::executeAllSynchronously(JSC::AbstractSlotVisitor&)
6 0x100a9bd7b JSC::Heap::verifyGC()
7 0x100a9b2f7 JSC::Heap::runEndPhase(JSC::GCConductor)
8 0x100a99434 JSC::Heap::runCurrentPhase(JSC::GCConductor, JSC::CurrentThreadState*)
9 0x100aa332d WTF::ScopedLambdaFunctor<void (JSC::CurrentThreadState&), JSC::Heap::collectInMutatorThread()::$_0>::implFunction(void*, JSC::CurrentThreadState&)
10 0x100ab8794 JSC::callWithCurrentThreadState(WTF::ScopedLambda<void (JSC::CurrentThreadState&)> const&)
11 0x100a9d2cd JSC::Heap::collectInMutatorThread()
12 0x100a99217 JSC::Heap::waitForCollection(unsigned long long)
13 0x100a98cb1 JSC::Heap::collectNow(JSC::Synchronousness, JSC::GCRequest)
14 0x100ab7b4d JSC::LocalAllocator::allocateSlowCase(JSC::Heap&, JSC::GCDeferralContext*, JSC::AllocationFailureMode)
15 0x100ec0785 void* JSC::allocateCell<JSC::JSDataView>(JSC::Heap&, unsigned long)
16 0x100ec0629 JSC::JSDataView::create(JSC::JSGlobalObject*, JSC::Structure*, WTF::RefPtr<JSC::ArrayBuffer, WTF::RawPtrTraits<JSC::ArrayBuffer>, WTF::DefaultRefDerefTraits<JSC::ArrayBuffer> >&&, unsigned int, unsigned int)
17 0x100f893d6 JSC::JSObject* JSC::constructGenericTypedArrayViewWithArguments<JSC::JSDataView>(JSC::JSGlobalObject*, JSC::Structure*, long long, unsigned int, WTF::Optional<unsigned int>)
18 0x100f731dc JSC::constructDataView(JSC::JSGlobalObject*, JSC::CallFrame*)
19 0x5e4a38a010c7
20 0x5e4a38a02095
21 0x1004888d6 vmEntryToJavaScript
22 0x100b83690 JSC::Interpreter::executeProgram(JSC::SourceCode const&, JSC::JSGlobalObject*, JSC::JSObject*)
23 0x100e39a82 JSC::evaluate(JSC::JSGlobalObject*, JSC::SourceCode const&, JSC::JSValue, WTF::NakedPtr<JSC::Exception>&)
24 0x100007606 jscmain(int, char**)
25 0x10000644b main
In the real GC, opaque root0x10e4b52c0 was NOT added to the heap's opaque roots.
Opaque root 0x10e4b52c0 was added via cell 0x12c577720 at:
1 0x100ea4fc9 JSC::JSArrayBufferView::visitChildren(JSC::JSCell*, JSC::AbstractSlotVisitor&)
2 0x100acd4e9 JSC::VerifierSlotVisitor::drain()
3 0x100a9bd48 JSC::Heap::verifyGC()
4 0x100a9b2f7 JSC::Heap::runEndPhase(JSC::GCConductor)
5 0x100a99434 JSC::Heap::runCurrentPhase(JSC::GCConductor, JSC::CurrentThreadState*)
6 0x100aa332d WTF::ScopedLambdaFunctor<void (JSC::CurrentThreadState&), JSC::Heap::collectInMutatorThread()::$_0>::implFunction(void*, JSC::CurrentThreadState&)
7 0x100ab8794 JSC::callWithCurrentThreadState(WTF::ScopedLambda<void (JSC::CurrentThreadState&)> const&)
8 0x100a9d2cd JSC::Heap::collectInMutatorThread()
9 0x100a99217 JSC::Heap::waitForCollection(unsigned long long)
10 0x100a98cb1 JSC::Heap::collectNow(JSC::Synchronousness, JSC::GCRequest)
11 0x100ab7b4d JSC::LocalAllocator::allocateSlowCase(JSC::Heap&, JSC::GCDeferralContext*, JSC::AllocationFailureMode)
12 0x100ec0785 void* JSC::allocateCell<JSC::JSDataView>(JSC::Heap&, unsigned long)
13 0x100ec0629 JSC::JSDataView::create(JSC::JSGlobalObject*, JSC::Structure*, WTF::RefPtr<JSC::ArrayBuffer, WTF::RawPtrTraits<JSC::ArrayBuffer>, WTF::DefaultRefDerefTraits<JSC::ArrayBuffer> >&&, unsigned int, unsigned int)
14 0x100f893d6 JSC::JSObject* JSC::constructGenericTypedArrayViewWithArguments<JSC::JSDataView>(JSC::JSGlobalObject*, JSC::Structure*, long long, unsigned int, WTF::Optional<unsigned int>)
15 0x100f731dc JSC::constructDataView(JSC::JSGlobalObject*, JSC::CallFrame*)
16 0x5e4a38a010c7
17 0x5e4a38a02095
18 0x1004888d6 vmEntryToJavaScript
19 0x100b83690 JSC::Interpreter::executeProgram(JSC::SourceCode const&, JSC::JSGlobalObject*, JSC::JSObject*)
20 0x100e39a82 JSC::evaluate(JSC::JSGlobalObject*, JSC::SourceCode const&, JSC::JSValue, WTF::NakedPtr<JSC::Exception>&)
21 0x100007606 jscmain(int, char**)
22 0x10000644b main
23 0x7fff203b4f3d start
Object: 0x12c577720 with butterfly 0x0 (Structure 0x108eb6e60:[0xe135, DataView, {}, NonArray, Proto:0x108ed7da0, Leaf]), StructureID: 57653
Cell 0x12c577720 was visited via cell 0x108b528e8 at:
1 0x100acccdc JSC::VerifierSlotVisitor::appendUnbarriered(JSC::JSCell*)
2 0x100f1623c JSC::JSObject::visitChildren(JSC::JSCell*, JSC::AbstractSlotVisitor&)
3 0x100acd4e9 JSC::VerifierSlotVisitor::drain()
4 0x100a9bd48 JSC::Heap::verifyGC()
5 0x100a9b2f7 JSC::Heap::runEndPhase(JSC::GCConductor)
6 0x100a99434 JSC::Heap::runCurrentPhase(JSC::GCConductor, JSC::CurrentThreadState*)
7 0x100aa332d WTF::ScopedLambdaFunctor<void (JSC::CurrentThreadState&), JSC::Heap::collectInMutatorThread()::$_0>::implFunction(void*, JSC::CurrentThreadState&)
8 0x100ab8794 JSC::callWithCurrentThreadState(WTF::ScopedLambda<void (JSC::CurrentThreadState&)> const&)
9 0x100a9d2cd JSC::Heap::collectInMutatorThread()
10 0x100a99217 JSC::Heap::waitForCollection(unsigned long long)
11 0x100a98cb1 JSC::Heap::collectNow(JSC::Synchronousness, JSC::GCRequest)
12 0x100ab7b4d JSC::LocalAllocator::allocateSlowCase(JSC::Heap&, JSC::GCDeferralContext*, JSC::AllocationFailureMode)
13 0x100ec0785 void* JSC::allocateCell<JSC::JSDataView>(JSC::Heap&, unsigned long)
14 0x100ec0629 JSC::JSDataView::create(JSC::JSGlobalObject*, JSC::Structure*, WTF::RefPtr<JSC::ArrayBuffer, WTF::RawPtrTraits<JSC::ArrayBuffer>, WTF::DefaultRefDerefTraits<JSC::ArrayBuffer> >&&, unsigned int, unsigned int)
15 0x100f893d6 JSC::JSObject* JSC::constructGenericTypedArrayViewWithArguments<JSC::JSDataView>(JSC::JSGlobalObject*, JSC::Structure*, long long, unsigned int, WTF::Optional<unsigned int>)
16 0x100f731dc JSC::constructDataView(JSC::JSGlobalObject*, JSC::CallFrame*)
17 0x5e4a38a010c7
18 0x5e4a38a02095
19 0x1004888d6 vmEntryToJavaScript
20 0x100b83690 JSC::Interpreter::executeProgram(JSC::SourceCode const&, JSC::JSGlobalObject*, JSC::JSObject*)
21 0x100e39a82 JSC::evaluate(JSC::JSGlobalObject*, JSC::SourceCode const&, JSC::JSValue, WTF::NakedPtr<JSC::Exception>&)
22 0x100007606 jscmain(int, char**)
23 0x10000644b main
Object: 0x108b528e8 with butterfly 0x1806e93070 (Structure 0x108efb090:[0xde87, Array, {}, ArrayWithContiguous, Proto:0x108baf5e8]), StructureID: 56967
Cell 0x108b528e8 was visited via cell 0x108e8fcc0 at:
1 0x100accdd8 JSC::VerifierSlotVisitor::appendUnbarriered(JSC::JSCell*)
2 0x10070634e void JSC::CodeBlock::stronglyVisitWeakReferences<JSC::AbstractSlotVisitor>(JSC::ConcurrentJSLocker const&, JSC::AbstractSlotVisitor&)
3 0x1006eacd7 JSC::CodeBlock::visitChildren(JSC::JSCell*, JSC::AbstractSlotVisitor&)
4 0x100acd4e9 JSC::VerifierSlotVisitor::drain()
5 0x100a9bd48 JSC::Heap::verifyGC()
6 0x100a9b2f7 JSC::Heap::runEndPhase(JSC::GCConductor)
7 0x100a99434 JSC::Heap::runCurrentPhase(JSC::GCConductor, JSC::CurrentThreadState*)
8 0x100aa332d WTF::ScopedLambdaFunctor<void (JSC::CurrentThreadState&), JSC::Heap::collectInMutatorThread()::$_0>::implFunction(void*, JSC::CurrentThreadState&)
9 0x100ab8794 JSC::callWithCurrentThreadState(WTF::ScopedLambda<void (JSC::CurrentThreadState&)> const&)
10 0x100a9d2cd JSC::Heap::collectInMutatorThread()
11 0x100a99217 JSC::Heap::waitForCollection(unsigned long long)
12 0x100a98cb1 JSC::Heap::collectNow(JSC::Synchronousness, JSC::GCRequest)
13 0x100ab7b4d JSC::LocalAllocator::allocateSlowCase(JSC::Heap&, JSC::GCDeferralContext*, JSC::AllocationFailureMode)
14 0x100ec0785 void* JSC::allocateCell<JSC::JSDataView>(JSC::Heap&, unsigned long)
15 0x100ec0629 JSC::JSDataView::create(JSC::JSGlobalObject*, JSC::Structure*, WTF::RefPtr<JSC::ArrayBuffer, WTF::RawPtrTraits<JSC::ArrayBuffer>, WTF::DefaultRefDerefTraits<JSC::ArrayBuffer> >&&, unsigned int, unsigned int)
16 0x100f893d6 JSC::JSObject* JSC::constructGenericTypedArrayViewWithArguments<JSC::JSDataView>(JSC::JSGlobalObject*, JSC::Structure*, long long, unsigned int, WTF::Optional<unsigned int>)
17 0x100f731dc JSC::constructDataView(JSC::JSGlobalObject*, JSC::CallFrame*)
18 0x5e4a38a010c7
19 0x5e4a38a02095
20 0x1004888d6 vmEntryToJavaScript
21 0x100b83690 JSC::Interpreter::executeProgram(JSC::SourceCode const&, JSC::JSGlobalObject*, JSC::JSObject*)
22 0x100e39a82 JSC::evaluate(JSC::JSGlobalObject*, JSC::SourceCode const&, JSC::JSValue, WTF::NakedPtr<JSC::Exception>&)
23 0x100007606 jscmain(int, char**)
24 0x10000644b main
Cell: 0x108e8fcc0 (0x108ef8c40:[0xc0e7, ProgramCodeBlock, {}, NonArray, Leaf]), StructureID: 49383
Cell 0x108e8fcc0 was visited from scan of ConservativeScan roots at:
1 0x100accaf8 JSC::VerifierSlotVisitor::append(JSC::ConservativeRoots const&)
2 0x100aa42a2 WTF::Detail::CallableWrapper<JSC::Heap::addCoreConstraints()::$_31, void, JSC::SlotVisitor&>::call(JSC::SlotVisitor&)
3 0x100ac1db2 JSC::MarkingConstraintSolver::runExecutionThread(JSC::SlotVisitor&, JSC::MarkingConstraintSolver::SchedulerPreference, WTF::ScopedLambda<WTF::Optional<unsigned int> ()>)
4 0x100a9f2de JSC::Heap::runTaskInParallel(WTF::RefPtr<WTF::SharedTask<void (JSC::SlotVisitor&)>, WTF::RawPtrTraits<WTF::SharedTask<void (JSC::SlotVisitor&)> >, WTF::DefaultRefDerefTraits<WTF::SharedTask<void (JSC::SlotVisitor&)> > >)
5 0x100ac188f JSC::MarkingConstraintSolver::execute(JSC::MarkingConstraintSolver::SchedulerPreference, WTF::ScopedLambda<WTF::Optional<unsigned int> ()>)
6 0x100ac125c JSC::MarkingConstraintSet::executeConvergenceImpl(JSC::SlotVisitor&)
7 0x100ac0f9b JSC::MarkingConstraintSet::executeConvergence(JSC::SlotVisitor&)
8 0x100a99f24 JSC::Heap::runFixpointPhase(JSC::GCConductor)
9 0x100a99418 JSC::Heap::runCurrentPhase(JSC::GCConductor, JSC::CurrentThreadState*)
10 0x100aa332d WTF::ScopedLambdaFunctor<void (JSC::CurrentThreadState&), JSC::Heap::collectInMutatorThread()::$_0>::implFunction(void*, JSC::CurrentThreadState&)
11 0x100ab8794 JSC::callWithCurrentThreadState(WTF::ScopedLambda<void (JSC::CurrentThreadState&)> const&)
12 0x100a9d2cd JSC::Heap::collectInMutatorThread()
13 0x100a99217 JSC::Heap::waitForCollection(unsigned long long)
14 0x100a98cb1 JSC::Heap::collectNow(JSC::Synchronousness, JSC::GCRequest)
15 0x100ab7b4d JSC::LocalAllocator::allocateSlowCase(JSC::Heap&, JSC::GCDeferralContext*, JSC::AllocationFailureMode)
16 0x100ec0785 void* JSC::allocateCell<JSC::JSDataView>(JSC::Heap&, unsigned long)
17 0x100ec0629 JSC::JSDataView::create(JSC::JSGlobalObject*, JSC::Structure*, WTF::RefPtr<JSC::ArrayBuffer, WTF::RawPtrTraits<JSC::ArrayBuffer>, WTF::DefaultRefDerefTraits<JSC::ArrayBuffer> >&&, unsigned int, unsigned int)
18 0x100f893d6 JSC::JSObject* JSC::constructGenericTypedArrayViewWithArguments<JSC::JSDataView>(JSC::JSGlobalObject*, JSC::Structure*, long long, unsigned int, WTF::Optional<unsigned int>)
19 0x100f731dc JSC::constructDataView(JSC::JSGlobalObject*, JSC::CallFrame*)
20 0x5e4a38a010c7
21 0x5e4a38a02095
22 0x1004888d6 vmEntryToJavaScript
23 0x100b83690 JSC::Interpreter::executeProgram(JSC::SourceCode const&, JSC::JSGlobalObject*, JSC::JSObject*)
24 0x100e39a82 JSC::evaluate(JSC::JSGlobalObject*, JSC::SourceCode const&, JSC::JSValue, WTF::NakedPtr<JSC::Exception>&)
25 0x100007606 jscmain(int, char**)
26 0x10000644b main
Note that in this example, the 2nd stack trace was for an opaque root. The verifier
also noted that the opaque root (which was added for the verifier GC) was not added
for the real GC. This pointed to the bug that caused the error (this bug was fixed
in https://bugs.webkit.org/show_bug.cgi?id=223241).
Additional changes in this patch:
1. Renamed AbstractSlotVisitor::Context to ReferrerContext.
2. Introduced AbstractSlotVisitor::ReferrerToken, which is an abstraction for
either a HeapCell*, an opaque root, or a GC root. ReferrerContext now tracks
a ReferrerToken instead of a HeapCell*.
* heap/AbstractSlotVisitor.h:
(JSC::AbstractSlotVisitor::ReferrerToken::ReferrerToken):
(JSC::AbstractSlotVisitor::ReferrerToken::operator bool const):
(JSC::AbstractSlotVisitor::ReferrerToken::operator! const):
(JSC::AbstractSlotVisitor::ReferrerToken::isHeapCell const):
(JSC::AbstractSlotVisitor::ReferrerToken::isOpaqueRoot const):
(JSC::AbstractSlotVisitor::ReferrerToken::isRootMarkReason const):
(JSC::AbstractSlotVisitor::ReferrerContext::referrer const):
(JSC::AbstractSlotVisitor::ReferrerContext::setReferrer):
(JSC::AbstractSlotVisitor::ReferrerContext::isOpaqueRootContext const):
(JSC::AbstractSlotVisitor::didAddOpaqueRoot):
(JSC::AbstractSlotVisitor::didFindOpaqueRoot):
(JSC::SetRootMarkReasonScope::SetRootMarkReasonScope):
(JSC::AbstractSlotVisitor::Context::cell const): Deleted.
* heap/AbstractSlotVisitorInlines.h:
(JSC::ReferrerToken::ReferrerToken):
(JSC::ReferrerToken::asCell const):
(JSC::ReferrerToken::asOpaqueRoot const):
(JSC::ReferrerToken::asRootMarkReason const):
(JSC::AbstractSlotVisitor::ReferrerContext::ReferrerContext):
(JSC::AbstractSlotVisitor::ReferrerContext::~ReferrerContext):
(JSC::AbstractSlotVisitor::addOpaqueRoot):
(JSC::AbstractSlotVisitor::containsOpaqueRoot const):
(JSC::AbstractSlotVisitor::referrer const):
(JSC::AbstractSlotVisitor::Context::Context): Deleted.
(JSC::AbstractSlotVisitor::Context::~Context): Deleted.
(JSC::AbstractSlotVisitor::parentCell const): Deleted.
* heap/Heap.cpp:
(JSC::Heap::addCoreConstraints):
* heap/Heap.h:
* heap/SlotVisitor.h:
* heap/SlotVisitorMacros.h:
* heap/VerifierSlotVisitor.cpp:
(JSC::MarkerData::MarkerData):
(JSC::VerifierSlotVisitor::MarkedBlockData::markerData const):
(JSC::VerifierSlotVisitor::PreciseAllocationData::markerData const):
(JSC::VerifierSlotVisitor::OpaqueRootData::markerData const):
(JSC::VerifierSlotVisitor::OpaqueRootData::addMarkerData):
(JSC::VerifierSlotVisitor::VerifierSlotVisitor):
(JSC::VerifierSlotVisitor::didAddOpaqueRoot):
(JSC::VerifierSlotVisitor::didFindOpaqueRoot):
(JSC::VerifierSlotVisitor::dump const):
(JSC::VerifierSlotVisitor::dumpMarkerData):
(JSC::VerifierSlotVisitor::testAndSetMarked):
* heap/VerifierSlotVisitor.h:
(JSC::VerifierSlotVisitor::MarkerData::referrer const):
(JSC::VerifierSlotVisitor::MarkerData::stack const):
* heap/WeakBlock.cpp:
(JSC::WeakBlock::specializedVisit):
2021-03-17 Alexey Shvayka <shvaikalesh@gmail.com>
[WebIDL] Fix convertRecord() to throw on enumerable symbol |key|
https://bugs.webkit.org/show_bug.cgi?id=223231
Reviewed by Darin Adler.
Export SymbolCoercionError.
* runtime/JSCJSValue.cpp:
(JSC::JSValue::toStringSlowCase const):
* runtime/JSCJSValue.h:
2021-03-16 Ross Kirsling <ross.kirsling@sony.com>
[JSC] Implement Error#cause
https://bugs.webkit.org/show_bug.cgi?id=223302
Reviewed by Yusuke Suzuki.
This patch implements the Error.prototype.cause proposal, which reached Stage 3 at last week's TC39 meeting:
https://github.com/tc39/proposal-error-cause
This very simple proposal allows to one reference the "error that caused this one" in a cascading scenario.
It does so by adding an options bag parameter to the Error, _NativeError_, and AggregateError constructors.
If it is an object with a `cause` property, the property will be used; if not, nothing happens at all.
* API/JSObjectRef.cpp:
(JSObjectMakeError):
* runtime/AggregateError.cpp:
(JSC::AggregateError::finishCreation):
(JSC::AggregateError::create):
* runtime/AggregateError.h:
* runtime/AggregateErrorConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/CommonIdentifiers.h:
* runtime/Error.cpp:
(JSC::createError):
(JSC::createEvalError):
(JSC::createRangeError):
(JSC::createReferenceError):
(JSC::createSyntaxError):
(JSC::createTypeError):
(JSC::createURIError):
(JSC::createGetterTypeError):
* runtime/ErrorConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/ErrorInstance.cpp:
(JSC::ErrorInstance::create):
(JSC::ErrorInstance::finishCreation):
* runtime/ErrorInstance.h:
(JSC::ErrorInstance::create):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/NativeErrorConstructor.cpp:
(JSC::NativeErrorConstructor<errorType>::constructImpl):
(JSC::NativeErrorConstructor<errorType>::callImpl):
* runtime/NullSetterFunction.cpp:
(JSC::NullSetterFunctionInternal::JSC_DEFINE_HOST_FUNCTION):
* wasm/js/JSWebAssemblyCompileError.cpp:
(JSC::JSWebAssemblyCompileError::create):
* wasm/js/JSWebAssemblyLinkError.cpp:
(JSC::JSWebAssemblyLinkError::create):
* wasm/js/JSWebAssemblyRuntimeError.cpp:
(JSC::JSWebAssemblyRuntimeError::create):
* wasm/js/WebAssemblyCompileErrorConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* wasm/js/WebAssemblyLinkErrorConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
2021-03-16 Saam Barati <sbarati@apple.com>
Object allocation sinking phase should prioritize materializations with no dependencies before materializations with no reverse dependencies
https://bugs.webkit.org/show_bug.cgi?id=221069
<rdar://problem/73686589>
Reviewed by Yusuke Suzuki.
Suppose we have two scope objects, A and B. Let's say A points to B, so B is
A's parent scope. A then depends on B. B has no dependencies here. When deciding
an order to materialize scope objects, we should always do it in reverse dependency
order. So above, we should materialize B, then A.
Inside object allocation sinking phase, when at an object materialization
site, we do track both dependencies and reverse dependencies. In the above
object graph, we'd attempt to materialize the objects in the right order,
always picking things with no dependencies first (and updating the list of
dependencies as we materialzed objects).
The code was using an std::list to track things to materialize, and it had
notions for materializing something first, and materializing something last.
However, there was a bug in how the code managed to insert things when
it first inserted last followed by inserting first. This patch simplifies
the code and makes it do the right thing.
* dfg/DFGObjectAllocationSinkingPhase.cpp:
2021-03-16 Mark Lam <mark.lam@apple.com>
Fixed undefined behavior bug in Const32Value::checkNegConstant().
https://bugs.webkit.org/show_bug.cgi?id=223284
Reviewed by Darin Adler.
This was causing a failure in testb3 on a release build.
Also do the same for Const64Value::checkNegConstant().
* b3/B3Const32Value.cpp:
(JSC::B3::Const32Value::checkNegConstant const):
* b3/B3Const64Value.cpp:
(JSC::B3::Const64Value::checkNegConstant const):
2021-03-16 Alexey Shvayka <shvaikalesh@gmail.com>
Cache cross-origin methods / accessors of Window and Location per lexical global object
https://bugs.webkit.org/show_bug.cgi?id=222739
Reviewed by Darin Adler.
1. Introduce WeakGCMap::ensureValue() to clean up JSObject::getOwnPropertyDescriptor() and
avoid double hashing. It decorates HashMap::ensure() to guarantee non-null return value.
2. Assert early that JSCustom{Getter,Setter}Function is created with non-null function pointer.
3. Rename getCustom{Getter,Setter}Function() to align with newly-added JSDOMGlobalObject methods.
* runtime/JSCustomGetterFunction.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::JSCustomGetterFunction::create):
* runtime/JSCustomSetterFunction.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::JSCustomSetterFunction::create):
* runtime/JSObject.cpp:
(JSC::createCustomGetterFunction):
(JSC::createCustomSetterFunction):
(JSC::JSObject::getOwnPropertyDescriptor):
(JSC::getCustomGetterFunction): Deleted.
(JSC::getCustomSetterFunction): Deleted.
* runtime/Lookup.h:
(JSC::nonCachingStaticFunctionGetterImpl): Deleted.
* runtime/WeakGCMap.h:
2021-03-16 Mark Lam <mark.lam@apple.com>
Add a RootMarkReason printer and also add a few additional reasons.
https://bugs.webkit.org/show_bug.cgi?id=223263
Reviewed by Michael Saboff.
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* heap/Heap.cpp:
(JSC::Heap::addCoreConstraints):
* heap/HeapSnapshotBuilder.cpp:
(JSC::HeapSnapshotBuilder::json):
(JSC::rootTypeToString): Deleted.
* heap/RootMarkReason.cpp: Added.
(JSC::rootMarkReasonDescription):
(WTF::printInternal):
* heap/RootMarkReason.h:
2021-03-16 Khem Raj <raj.khem@gmail.com>
[CMake] Build fails on RISC-V with GCC 11
https://bugs.webkit.org/show_bug.cgi?id=222959
Reviewed by Carlos Alberto Lopez Perez.
Use renamed variable ATOMICS_REQUIRE_LIBATOMIC instead of ATOMIC_INT64_REQUIRES_LIBATOMIC
* CMakeLists.txt:
2021-03-15 Angelos Oikonomopoulos <angelos@igalia.com>
postprocess-asm/resolve-asm-file-conflicts.rb build failure after upgrading to F34
https://bugs.webkit.org/show_bug.cgi?id=223136
Reviewed by Michael Catanzaro.
When parsing .file assembler directives (for the purpose of
deduplicating the file slots), also accept
.file "path/to/CWD" "path/to/include"
that seems to be emitted by GCC in some configurations. This also
uses Pathname.cleanpath on the resulting path to canonicalize the
paths. We could use .realpath, but since we only run this on the
paths in a single compilation unit and the first component is
supposed to be the CWD, this both seems unnecessary and would
complicate our selftests.
* Scripts/resolve-asm-file-conflicts.rb:
2021-03-14 Alexey Shvayka <shvaikalesh@gmail.com>
REGRESSION (r274308): Two assertions in JSGlobalObject::defineOwnProperty() are failing
https://bugs.webkit.org/show_bug.cgi?id=223134
Reviewed by Yusuke Suzuki.
This patch:
1. Simplifies exception check after validateAndApplyPropertyDescriptor() as it
conditionally throws on failure.
2. Creates new SymbolTableEntry when global variable is redefined as read-only
because setAttributes() performs pack(), which doesn't support fat entries.
Due to #2, symbolTableGet() overload is simplified to return fast entry, and
setAttributes() is removed as unused.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::defineOwnProperty):
* runtime/JSSymbolTableObject.h:
(JSC::symbolTableGet):
* runtime/SymbolTable.h:
(JSC::SymbolTableEntry::getAttributes const):
(JSC::SymbolTableEntry::setAttributes): Deleted.
2021-03-14 Yusuke Suzuki <ysuzuki@apple.com>
[Big Sur arm64] testb3 crashing
https://bugs.webkit.org/show_bug.cgi?id=222815
Reviewed by Mark Lam.
Fix dmb ish and dmb ishst's formats.
* b3/testb3_6.cpp:
(testMemoryFence):
(testStoreFence):
(testLoadFence):
2021-03-14 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] ARM64 branchAtomicWeakCAS should not use sign-extension
https://bugs.webkit.org/show_bug.cgi?id=222813
Reviewed by Mark Lam.
ARM64 branchAtomicWeakCAS implementation should not use sign-extension. Instead, it should use zero-extension.
This is because loadLinkAcq (ldaxr) will load a value with zero-extension. If we use sign-extension, we will
encounter the state where LL/SC never succeeds just because we are comparing sign-extended value and zero-extended
value. This implementation is aligned to how X86 implementation works: X86 only cares the effective bit width of branchAtomicWeakCAS.
This is already tested by stress/atomics-store-result-int52.js.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::zeroExtend):
(JSC::MacroAssemblerARM64::atomicStrongCAS):
(JSC::MacroAssemblerARM64::atomicRelaxedStrongCAS):
(JSC::MacroAssemblerARM64::branchAtomicWeakCAS):
(JSC::MacroAssemblerARM64::branchAtomicRelaxedWeakCAS):
(JSC::MacroAssemblerARM64::signExtend): Deleted.
(JSC::MacroAssemblerARM64::signExtend<8>): Deleted.
(JSC::MacroAssemblerARM64::signExtend<16>): Deleted.
2021-03-14 Mark Lam <mark.lam@apple.com>
GCSegmentedArray's size() and isEmpty() methods should be const.
https://bugs.webkit.org/show_bug.cgi?id=223156
Reviewed by Keith Miller.
* heap/GCSegmentedArray.h:
* heap/GCSegmentedArrayInlines.h:
(JSC::GCSegmentedArray<T>::isEmpty const):
(JSC::GCSegmentedArray<T>::size const):
(JSC::GCSegmentedArray<T>::isEmpty): Deleted.
(JSC::GCSegmentedArray<T>::size): Deleted.
2021-03-14 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] wasm atomic wait offset is not index
https://bugs.webkit.org/show_bug.cgi?id=223159
Reviewed by Mark Lam.
While JS Atomics.wait's argument is "index" in the typed-array, argument of wasm wait and notify is address.
But we are handling it as an index incorrectly.
This patch uses it as an address.
* wasm/WasmOperations.cpp:
(JSC::Wasm::JSC_DEFINE_JIT_OPERATION):
2021-03-13 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r274379.
https://bugs.webkit.org/show_bug.cgi?id=223154
Some LayoutTests are crashing
Reverted changeset:
"Cache cross-origin methods / accessors of Window and Location
per lexical global object"
https://bugs.webkit.org/show_bug.cgi?id=222739
https://trac.webkit.org/changeset/274379
2021-03-13 Alexey Shvayka <shvaikalesh@gmail.com>
Cache cross-origin methods / accessors of Window and Location per lexical global object
https://bugs.webkit.org/show_bug.cgi?id=222739
Reviewed by Darin Adler.
1. Add WeakGCMap::ensure() to avoid double hashing and clean up JSObject::getOwnPropertyDescriptor().
2. Assert early that JSCustom{Getter,Setter}Function is created with non-null function pointer.
3. Rename getCustom{Getter,Setter}Function() to align with newly-added JSDOMGlobalObject methods.
* runtime/JSCustomGetterFunction.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::JSCustomGetterFunction::create):
* runtime/JSCustomSetterFunction.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::JSCustomSetterFunction::create):
* runtime/JSObject.cpp:
(JSC::createCustomGetterFunction):
(JSC::createCustomSetterFunction):
(JSC::JSObject::getOwnPropertyDescriptor):
(JSC::getCustomGetterFunction): Deleted.
(JSC::getCustomSetterFunction): Deleted.
* runtime/Lookup.h:
(JSC::nonCachingStaticFunctionGetterImpl): Deleted.
* runtime/WeakGCMap.h:
2021-03-12 Carlos Garcia Campos <cgarcia@igalia.com>
[GTK] Bump API version when building with libsoup3
https://bugs.webkit.org/show_bug.cgi?id=223067
Reviewed by Adrian Perez de Castro.
Use WEBKITGTK_API_DOC_VERSION instead of WEBKITGTK_API_VERSION for the gtkdoc configuration file.
* PlatformGTK.cmake:
2021-03-11 Saam Barati <sbarati@apple.com>
Adopt VM_FLAGS_PERMANENT for the config vm mapping
https://bugs.webkit.org/show_bug.cgi?id=222086
<rdar://74402690>
Reviewed by Yusuke Suzuki and Mark Lam.
* runtime/JSCConfig.h:
(JSC::Config::configureForTesting):
2021-03-11 Tadeu Zagallo <tzagallo@apple.com>
AI validator patchpoint should read heap top
https://bugs.webkit.org/show_bug.cgi?id=223052
<rdar://75087095>
Reviewed by Yusuke Suzuki.
Currently, the patchpoint doesn't specify any reads, which allows it to be moved around by B3
and can cause false positives since it at least read the structure ID for comparing values.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::validateAIState):
2021-03-11 Alexey Shvayka <shvaikalesh@gmail.com>
Align JSGlobalObject::defineOwnProperty() with the spec and other runtimes
https://bugs.webkit.org/show_bug.cgi?id=203456
Reviewed by Robin Morisset.
Per spec, top-level `var` bindings are non-configurable properties of the global
object [1], while `undefined` / `NaN` / `Infinity` are also non-writable [2].
Prior to this change, redefining global `var` binding with accessor descriptor
failed silently (rather than throwing a TypeError); redefining with data or
generic descriptor created a structure property, which took precedence over
symbol table entry in JSGlobalObject::getOwnPropertySlot(), effectively
destroying live binding between `global.foo` and `var foo`.
This patch re-engineers JSGlobalObject::defineOwnProperty(), fixing both issues
mentioned above. If defineOwnProperty() override is removed, there is no way
a live binding can be maintained.
In a follow-up change, JSGlobalObject::getOwnPropertySlot() will be updated to
search symbol table first, aligning it with the spec [3], put(), and
defineOwnProperty(). Apart from consistency, this will bring a mild speed-up.
To accomodate global `var` binding reassignment right after it becomes read-only
(in the same scope), this patch introduces a watchpoint that can be fired by
JSGlobalObject::defineOwnProperty(). put_to_scope performance is neutral.
Also, this patch removes unused symbolTableGet() overload and orphaned
JSGlobalObject::defineGetter() / JSGlobalObject::defineSetter() declarations.
[1]: https://tc39.es/ecma262/#sec-object-environment-records-createmutablebinding-n-d
[2]: https://tc39.es/ecma262/#sec-value-properties-of-the-global-object
[3]: https://tc39.es/ecma262/#sec-global-environment-records-getbindingvalue-n-s
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::needsDynamicLookup):
(JSC::DFG::ByteCodeParser::parseBlock):
* jit/JIT.cpp:
(JSC::JIT::emitVarReadOnlyCheck):
* jit/JIT.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_put_to_scope):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_put_to_scope):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::JSGlobalObject):
(JSC::JSGlobalObject::defineOwnProperty):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::varReadOnlyWatchpoint):
* runtime/JSSymbolTableObject.h:
(JSC::symbolTableGet):
2021-03-11 BJ Burg <bburg@apple.com>
Web Inspector: Occasional crash under RemoteConnectionToTargetCocoa::close()
https://bugs.webkit.org/show_bug.cgi?id=223038
<rdar://74920246>
Reviewed by Alex Christensen.
* inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm:
(Inspector::RemoteConnectionToTarget::setup):
(Inspector::RemoteConnectionToTarget::close):
Don't use a capture default, and copy the targetIdentifier.
2021-03-11 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r274263.
https://bugs.webkit.org/show_bug.cgi?id=223064
Added few broken tests
Reverted changeset:
"AI validator patchpoint should read heap top"
https://bugs.webkit.org/show_bug.cgi?id=223052
https://trac.webkit.org/changeset/274263
2021-03-10 Tadeu Zagallo <tzagallo@apple.com>
AI validator patchpoint should read heap top
https://bugs.webkit.org/show_bug.cgi?id=223052
<rdar://75087095>
Reviewed by Saam Barati.
Currently, the patchpoint doesn't specify any reads, which allows it to be moved around by B3
and can cause false positives since it at least read the structure ID for comparing values.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::validateAIState):
2021-03-10 Chris Dumez <cdumez@apple.com>
Use RetainPtr<> / OSObjectPtr<> more in WebKit
https://bugs.webkit.org/show_bug.cgi?id=223030
Reviewed by Darin Adler.
* inspector/remote/cocoa/RemoteInspectorCocoa.mm:
(Inspector::RemoteInspector::setupXPCConnectionIfNeeded):
* inspector/remote/cocoa/RemoteInspectorXPCConnection.h:
* inspector/remote/cocoa/RemoteInspectorXPCConnection.mm:
(Inspector::RemoteInspectorXPCConnection::RemoteInspectorXPCConnection):
(Inspector::RemoteInspectorXPCConnection::closeFromMessage):
(Inspector::RemoteInspectorXPCConnection::closeOnQueue):
(Inspector::RemoteInspectorXPCConnection::handleEvent):
(Inspector::RemoteInspectorXPCConnection::sendMessage):
* jsc.cpp:
(jscmain):
2021-03-10 Keith Miller <keith_miller@apple.com>
executeModuleProgram needs to ensure module argument array is still in scope
https://bugs.webkit.org/show_bug.cgi?id=223039
Reviewed by Saam Barati.
This was causing testing builds to crash for wasm tests.
* interpreter/Interpreter.cpp:
(JSC::Interpreter::executeModuleProgram):
2021-03-10 Michael Catanzaro <mcatanzaro@gnome.org>
[GTK] Reenable -fvisibility=hidden
https://bugs.webkit.org/show_bug.cgi?id=181916
Reviewed by Don Olmstead.
We need to export the destructor of IsoHeapCellType.
* heap/IsoHeapCellType.cpp:
* heap/IsoHeapCellType.h:
2021-03-09 Don Olmstead <don.olmstead@sony.com>
GLib JSC API headers should only include other GLib JSC API headers
https://bugs.webkit.org/show_bug.cgi?id=222803
Reviewed by Michael Catanzaro.
A number of private GLib JSC headers are directly including private JavaScriptCore headers.
To get this to compile ${FORWARDING_HEADERS_DIR}/JavaScriptCore was added to the list of
includes in targets that needed the JSC headers. This is incorrect because they are being
distributed in different directories.
The private JSC headers being used were replaced with forward declarations. The source
files were then updated accordingly.
Also the include directories that contained the <jsc/Foo.h> headers were added to
JavaScriptCore_INTERFACE_INCLUDE_DIRECTORIES so they're properly propagated to dependants.
* API/glib/JSCClassPrivate.h:
* API/glib/JSCContext.cpp:
* API/glib/JSCContextPrivate.h:
* API/glib/JSCVirtualMachine.cpp:
* API/glib/JSCVirtualMachinePrivate.h:
* API/glib/JSCWrapperMap.cpp:
* GLib.cmake:
* PlatformGTK.cmake:
2021-03-09 Keith Miller <keith_miller@apple.com>
JSC Crash in makeString() while creating Error object.
https://bugs.webkit.org/show_bug.cgi?id=222452
Reviewed by Mark Lam.
This patch clamps the user provided part of error messages to
2-KB of characters. Technically, it could actually be 4-KB of
data for 16-bit strings. This is a somewhat randomly picked length
but seems like it should be sufficient for any normal use case I
can think of.
* runtime/ExceptionHelpers.cpp:
(JSC::clampErrorMessage):
(JSC::defaultApproximateSourceError):
(JSC::defaultSourceAppender):
2021-03-08 Saam Barati <sbarati@apple.com>
Using an undeclared private field inside eval shouldn't crash
https://bugs.webkit.org/show_bug.cgi?id=222834
<rdar://75035388>
Reviewed by Yusuke Suzuki.
The private methods patch regressed our behavior when using undeclared private
fields or methods from an inner eval inside a class. That patch made us crash.
This patch aligns us with the spec to throw a Syntax Error during eval parsing.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseInner):
(JSC::Parser<LexerType>::parseMemberExpression):
* parser/Parser.h:
(JSC::Parser<LexerType>::parse):
2021-03-06 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r274041.
https://bugs.webkit.org/show_bug.cgi?id=222873
Broke the build instead of fixing it
Reverted changeset:
"Fix the build"
https://trac.webkit.org/changeset/274041
2021-03-06 Myles C. Maxfield <mmaxfield@apple.com>
Fix the build
Unreviewed.
* dfg/DFGOSRExit.cpp:
(JSC::DFG::JSC_DEFINE_JIT_OPERATION):
2021-03-06 Alexey Shvayka <shvaikalesh@gmail.com>
BooleanConstructor should be inlined in DFG / FTL
https://bugs.webkit.org/show_bug.cgi?id=220322
Reviewed by Yusuke Suzuki.
`array.filter(Boolean)` is a rather popular idiom for removing falsy items from an array.
Also, `Boolean(X)` is sometimes used for explicit type casting.
This patch introduces ToBoolean DFG node and reorganizes compileLogicalNot(node) into
compileToBoolean(node, bool invert), leveraging already existing emitConvertValueToBoolean().
This approach is better than emitting LogicalNot<KnownBooleanUse>(LogicalNot(X)) as it results
in cleaner DFG node tree and is ~7% faster w/o FTL. Also, it enables adding a op_to_boolean
bytecode that will be generated for very common `!!X` patterns, reducing instruction count.
Just as LogicalNot, BooleanConstructor should handle masquerader objects, because Annex B
patches ToBoolean abstract op [1], preventing us from emitting simpler code.
This change advances provided microbenchmark by 110%, and is neutral for other ToBoolean cases.
[1]: https://tc39.es/ecma262/#sec-IsHTMLDDA-internal-slot-to-boolean
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGMayExit.cpp:
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileToBooleanString):
(JSC::DFG::SpeculativeJIT::compileToBooleanStringOrOther):
(JSC::DFG::SpeculativeJIT::compileStringZeroLength): Deleted.
(JSC::DFG::SpeculativeJIT::compileLogicalNotStringOrOther): Deleted.
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compileToBooleanObjectOrOther):
(JSC::DFG::SpeculativeJIT::compileToBoolean):
(JSC::DFG::SpeculativeJIT::compile):
(JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot): Deleted.
(JSC::DFG::SpeculativeJIT::compileLogicalNot): Deleted.
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compileToBooleanObjectOrOther):
(JSC::DFG::SpeculativeJIT::compileToBoolean):
(JSC::DFG::SpeculativeJIT::compile):
(JSC::DFG::SpeculativeJIT::compileObjectOrOtherLogicalNot): Deleted.
(JSC::DFG::SpeculativeJIT::compileLogicalNot): Deleted.
* dfg/DFGWatchpointCollectionPhase.cpp:
(JSC::DFG::WatchpointCollectionPhase::handle):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileToBoolean):
2021-03-06 Tim Horton <timothy_horton@apple.com>
<model> should create a model-owning compositing layer
https://bugs.webkit.org/show_bug.cgi?id=222798
Reviewed by Simon Fraser.
* inspector/protocol/LayerTree.json:
Add a compositing reason for <model>.
2021-03-05 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, suppress warning as it is done in DFGOperations.cpp
We are intentionally using this feature to reduce size of JIT memory.
* dfg/DFGOSRExit.cpp:
2021-03-05 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Simplify OSRExit side state materialization
https://bugs.webkit.org/show_bug.cgi?id=222648
Reviewed by Keith Miller.
Currently, JIT probe with lambda function has memory leaking issue. So we must not use it in production code.
To avoid the future use, we rename probe to probeDebug.
And to avoid using probe function in OSR exit side state materialization, we simplify the OSRExit side state materialization code,
and making it just a function call. To achieve that, we materialize exit values into scratch buffer before restoring them to
the stack. This aligns DFG to what FTL is doing. And DFG and FTL can use the same materialization operation function.
Caio helped me to fix 32bit issue in DFG.
* assembler/MacroAssembler.cpp:
(JSC::MacroAssembler::probeDebug):
(JSC::MacroAssembler::probe): Deleted.
* assembler/MacroAssembler.h:
* assembler/testmasm.cpp:
(JSC::testClearBits64WithMask):
(JSC::testClearBits64WithMaskTernary):
(JSC::testShiftAndAdd):
(JSC::testProbeReadsArgumentRegisters):
(JSC::testProbeWritesArgumentRegisters):
(JSC::testProbePreservesGPRS):
(JSC::testProbeModifiesStackPointer):
(JSC::testProbeModifiesProgramCounter):
(JSC::testProbeModifiesStackValues):
* b3/air/testair.cpp:
* dfg/DFGOSRExit.cpp:
(JSC::DFG::JSC_DEFINE_JIT_OPERATION):
(JSC::DFG::OSRExit::compileExit):
* dfg/DFGOSRExit.h:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::validateAIState):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
2021-03-05 Don Olmstead <don.olmstead@sony.com>
[CMake] Bump cmake_minimum_required version to 3.12 or later
https://bugs.webkit.org/show_bug.cgi?id=221727
<rdar://problem/74454980>
Reviewed by Konstantin Tokarev.
Sync cmake_minimum_required version for AppleWin internal builds.
* CMakeLists.txt:
2021-03-05 Tadeu Zagallo <tzagallo@apple.com>
OpGetPrivateName needs to be listed in FOR_EACH_OPCODE_WITH_VALUE_PROFILE
https://bugs.webkit.org/show_bug.cgi?id=222775
<rdar://74982634>
Reviewed by Michael Saboff.
Right now valueProfileForBytecodeIndex incorrectly returns null for op_get_private_name.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::valueProfileForBytecodeIndex):
* bytecode/Opcode.h:
2021-03-05 Chris Dumez <cdumez@apple.com>
Reduce use of CFRetain() / CFRelease() / CFAutoRelease() in WebKit
https://bugs.webkit.org/show_bug.cgi?id=222760
Reviewed by Darin Adler.
Reduce use of CFRetain() / CFRelease() / CFAutoRelease() in WebKit by using RetainPtr<>.
* API/JSContext.mm:
(-[JSContext name]):
* API/JSValue.mm:
(valueToObjectWithoutCopy):
(valueToString):
* inspector/remote/cocoa/RemoteInspectorXPCConnection.mm:
(Inspector::RemoteInspectorXPCConnection::deserializeMessage):
2021-03-05 Dmitry Bezhetskov <dbezhetskov@igalia.com>
[WASM-Function-References] Update ref.func to produce (ref $t)
https://bugs.webkit.org/show_bug.cgi?id=222779
Reviewed by Yusuke Suzuki.
Make ref.func to produce non nullable reference type which
incorporates signature index. Since in JSC signature index represents
type of the function from Type section we use it instead of type_idx
for representing type of function references.
* runtime/OptionsList.h:
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::addTableGrow):
(JSC::Wasm::AirIRGenerator::addTableFill):
(JSC::Wasm::AirIRGenerator::unify):
* wasm/WasmFormat.h:
(JSC::Wasm::isValueType):
(JSC::Wasm::isSubtype):
(JSC::Wasm::isRefType):
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::checkBranchTarget):
(JSC::Wasm::FunctionParser<Context>::unify):
(JSC::Wasm::FunctionParser<Context>::parseExpression):
* wasm/WasmLLIntGenerator.cpp:
(JSC::Wasm::LLIntGenerator::callInformationForCaller):
(JSC::Wasm::LLIntGenerator::callInformationForCallee):
(JSC::Wasm::LLIntGenerator::addArguments):
* wasm/WasmSectionParser.cpp:
(JSC::Wasm::SectionParser::parseGlobal):
* wasm/generateWasmOpsHeader.py:
* wasm/js/WasmToJS.cpp:
(JSC::Wasm::wasmToJS):
* wasm/js/WebAssemblyFunction.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* wasm/wasm.json:
2021-03-04 Alex Christensen <achristensen@webkit.org>
[Cocoa] REGRESSION(r272752): fix some internal builds that use WTFString::WTFString(NSString *)
https://bugs.webkit.org/show_bug.cgi?id=222610
Reviewed by Chris Dumez.
* inspector/scripts/codegen/objc_generator.py:
(ObjCGenerator.objc_protocol_import_expression_for_member):
(ObjCGenerator.objc_protocol_import_expression_for_parameter):
(ObjCGenerator.protocol_to_objc_expression_for_member):
(ObjCGenerator.payload_to_objc_expression_for_member):
2021-03-04 Saam Barati <sbarati@apple.com>
Don't trust parsing information to tell us if we've emitted op_call_eval
https://bugs.webkit.org/show_bug.cgi?id=222694
rdar://74778016
Reviewed by Yusuke Suzuki.
In the DFG, op_call_eval can't be inlined. Not inlining is required for how
eval is currently implemented in the DFG. For CodeBlocks with eval in them,
the scope register is also alive everywhere.
When doing spread of arguments in eval, we end up emitting a call varargs
instead of a direct eval. This seems like a spec bug:
https://bugs.webkit.org/show_bug.cgi?id=222671
However, this leads to something that had eval textually in it leading to
us reporting the scope register is always alive, even if op_call_eval isn't
in the bytecode stream. This leads to a validation error, since the DFG
isn't actually keeping this scope register alive everywhere, because
op_call_eval isn't in the bytecode stream.
This patch fixes this by having a bit indicating if op_call_eval is in
the bytecode stream or not.
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeIndex):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::usesCallEval const):
(JSC::CodeBlock::usesEval const): Deleted.
* bytecode/ExecutableInfo.h:
(JSC::ExecutableInfo::ExecutableInfo):
(JSC::ExecutableInfo::usesEval const): Deleted.
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::usesCallEval const):
(JSC::UnlinkedCodeBlock::setUsesCallEval):
(JSC::UnlinkedCodeBlock::usesEval const): Deleted.
* bytecode/UnlinkedCodeBlockGenerator.h:
(JSC::UnlinkedCodeBlockGenerator::usesCallEval const):
(JSC::UnlinkedCodeBlockGenerator::setUsesCallEval):
(JSC::UnlinkedCodeBlockGenerator::usesEval const): Deleted.
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::generateUnlinkedFunctionCodeBlock):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::emitCall):
(JSC::BytecodeGenerator::isThisUsedInInnerArrowFunction):
(JSC::BytecodeGenerator::isNewTargetUsedInInnerArrowFunction):
(JSC::BytecodeGenerator::isSuperUsedInInnerArrowFunction):
(JSC::BytecodeGenerator::isSuperCallUsedInInnerArrowFunction):
* dfg/DFGGraph.h:
* runtime/CachedTypes.cpp:
(JSC::CachedCodeBlock::usesCallEval const):
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
(JSC::CachedCodeBlock<CodeBlockType>::encode):
(JSC::CachedCodeBlock::usesEval const): Deleted.
* runtime/CodeCache.cpp:
(JSC::generateUnlinkedCodeBlockImpl):
* runtime/EvalExecutable.h:
(JSC::EvalExecutable::executableInfo const): Deleted.
* runtime/ModuleProgramExecutable.h:
* runtime/ProgramExecutable.h:
* runtime/ScriptExecutable.h:
(JSC::ScriptExecutable::usesEval const): Deleted.
2021-03-04 Alex Christensen <achristensen@webkit.org>
Unreviewed, reverting r273906.
Broke internal build
Reverted changeset:
"[Cocoa] REGRESSION(r272752): fix some internal builds that
use WTFString::WTFString(NSString *)"
https://bugs.webkit.org/show_bug.cgi?id=222610
https://commits.webkit.org/r273906
2021-03-04 Alex Christensen <achristensen@webkit.org>
[Cocoa] REGRESSION(r272752): fix some internal builds that use WTFString::WTFString(NSString *)
https://bugs.webkit.org/show_bug.cgi?id=222610
Reviewed by Chris Dumez.
* inspector/scripts/codegen/objc_generator.py:
(ObjCGenerator.objc_protocol_import_expression_for_member):
(ObjCGenerator.objc_protocol_import_expression_for_parameter):
(ObjCGenerator.protocol_to_objc_expression_for_member):
(ObjCGenerator.payload_to_objc_expression_for_member):
2021-03-03 Devin Rousso <drousso@apple.com>
Web Inspector: `RecordCanvasActionVariant` causes a huge symbol to be created in WebCore
https://bugs.webkit.org/show_bug.cgi?id=222639
<rdar://problem/73728057>
Reviewed by Tim Horton and Brian Burg.
* inspector/protocol/Recording.json:
Drive-by: Add info about `snapshot` to the `"description"` of `"actions"` in `"Frame"`.
2021-03-03 Caio Lima <ticaiolima@gmail.com>
[ESNext] Private methods can't be named as '#constructor'
https://bugs.webkit.org/show_bug.cgi?id=222680
Reviewed by Yusuke Suzuki.
It's a `SyntaxError` when we try to use `#constructor` as private name
for methods, accessors, and fields. This patch is fixing such bug for
methods and accessors.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseClass):
(JSC::Parser<LexerType>::parseGetterSetter):
2021-03-03 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r273814.
https://bugs.webkit.org/show_bug.cgi?id=222676
Unresolved types in JavaScriptCore-4.0.gir
Reverted changeset:
"[CMake] JavaScriptCore GLib headers should be copies"
https://bugs.webkit.org/show_bug.cgi?id=222625
https://trac.webkit.org/changeset/273814
2021-03-03 Alexey Shvayka <shvaikalesh@gmail.com>
Add JSModuleNamespaceObject::deletePropertyByIndex() method
https://bugs.webkit.org/show_bug.cgi?id=222611
Reviewed by Yusuke Suzuki.
r270923 introduced arbitrary module namespace identifiers, enabling indexed identifiers
to be exported. While they were already handled by getOwnPropertySlotByIndex(), indexed
[[Delete]] override was absent, which prevented TypeError from being thrown.
This patch adds the missing method, aligning JSC with the spec [1].
[1]: https://tc39.es/ecma262/#sec-module-namespace-exotic-objects-delete-p
* runtime/JSModuleNamespaceObject.cpp:
(JSC::JSModuleNamespaceObject::deleteProperty):
(JSC::JSModuleNamespaceObject::deletePropertyByIndex):
* runtime/JSModuleNamespaceObject.h:
2021-03-03 Don Olmstead <don.olmstead@sony.com>
[CMake] JavaScriptCore GLib headers should be copies
https://bugs.webkit.org/show_bug.cgi?id=222625
Reviewed by Michael Catanzaro.
Copy the headers rather than creating a symbolic link to structure the JavaScriptCore Glib
headers into a jsc directory. This follows the convention used in JavaScriptCore where
there are public and private headers.
The public JavaScriptCore GLib headers are copied before building JavaScriptCore. The
private JavaScriptCore were modified to include the public GLib headers through
<jsc/Header.h> rather than "Header.h" which is convention for the private C APIs in
JavaScriptCore.
APICast.h was being erroneously included in JSCClassPrivate.h because its not a
JavaScriptCore GLib header. Instead forward declarations were added to the private headers
and APICast.h was used as necessary in the .cpp files.
* API/glib/JSCClassPrivate.h:
* API/glib/JSCContext.cpp:
* API/glib/JSCContextPrivate.h:
* API/glib/JSCExceptionPrivate.h:
* API/glib/JSCValuePrivate.h:
* API/glib/JSCVirtualMachine.cpp:
* API/glib/JSCVirtualMachinePrivate.h:
* API/glib/JSCWrapperMap.cpp:
* GLib.cmake:
* PlatformGTK.cmake:
2021-03-03 Dmitry Bezhetskov <dbezhetskov@igalia.com>
[WASM-Function-References] Extend wasm type with type index
https://bugs.webkit.org/show_bug.cgi?id=222351
Reviewed by Keith Miller.
Extend wasm type with type index to represent
new reference types from typed function references
proposal: https://github.com/WebAssembly/function-references/blob/master/proposals/function-references/Overview.md.
* bytecode/BytecodeDumper.cpp:
(JSC::Wasm::BytecodeDumper::dumpConstants):
(JSC::Wasm::BytecodeDumper::formatConstant const):
* bytecode/BytecodeDumper.h:
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::TypedTmp::TypedTmp):
(JSC::Wasm::TypedTmp::dump const):
(JSC::Wasm::AirIRGenerator::g32):
(JSC::Wasm::AirIRGenerator::g64):
(JSC::Wasm::AirIRGenerator::gExternref):
(JSC::Wasm::AirIRGenerator::gFuncref):
(JSC::Wasm::AirIRGenerator::f32):
(JSC::Wasm::AirIRGenerator::f64):
(JSC::Wasm::AirIRGenerator::tmpForType):
(JSC::Wasm::AirIRGenerator::emitCCall):
(JSC::Wasm::AirIRGenerator::moveOpForValueType):
(JSC::Wasm::AirIRGenerator::AirIRGenerator):
(JSC::Wasm::AirIRGenerator::addLocal):
(JSC::Wasm::AirIRGenerator::addConstant):
(JSC::Wasm::AirIRGenerator::addRefIsNull):
(JSC::Wasm::AirIRGenerator::addRefFunc):
(JSC::Wasm::AirIRGenerator::addTableGet):
(JSC::Wasm::AirIRGenerator::addTableSet):
(JSC::Wasm::AirIRGenerator::addTableInit):
(JSC::Wasm::AirIRGenerator::addElemDrop):
(JSC::Wasm::AirIRGenerator::addTableSize):
(JSC::Wasm::AirIRGenerator::addTableGrow):
(JSC::Wasm::AirIRGenerator::addTableFill):
(JSC::Wasm::AirIRGenerator::addTableCopy):
(JSC::Wasm::AirIRGenerator::addGrowMemory):
(JSC::Wasm::AirIRGenerator::addCurrentMemory):
(JSC::Wasm::AirIRGenerator::addMemoryFill):
(JSC::Wasm::AirIRGenerator::addMemoryCopy):
(JSC::Wasm::AirIRGenerator::addMemoryInit):
(JSC::Wasm::AirIRGenerator::addDataDrop):
(JSC::Wasm::AirIRGenerator::emitCheckAndPreparePointer):
(JSC::Wasm::AirIRGenerator::sanitizeAtomicResult):
(JSC::Wasm::AirIRGenerator::appendGeneralAtomic):
(JSC::Wasm::AirIRGenerator::appendStrongCAS):
(JSC::Wasm::AirIRGenerator::emitAtomicLoadOp):
(JSC::Wasm::AirIRGenerator::atomicLoad):
(JSC::Wasm::AirIRGenerator::emitAtomicStoreOp):
(JSC::Wasm::AirIRGenerator::emitAtomicBinaryRMWOp):
(JSC::Wasm::AirIRGenerator::atomicBinaryRMW):
(JSC::Wasm::AirIRGenerator::emitAtomicCompareExchange):
(JSC::Wasm::AirIRGenerator::atomicCompareExchange):
(JSC::Wasm::AirIRGenerator::atomicWait):
(JSC::Wasm::AirIRGenerator::atomicNotify):
(JSC::Wasm::AirIRGenerator::truncSaturated):
(JSC::Wasm::AirIRGenerator::addReturn):
(JSC::Wasm::AirIRGenerator::addSwitch):
(JSC::Wasm::AirIRGenerator::emitModOrDiv):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32TruncSF64>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32TruncSF32>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32TruncUF64>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32TruncUF32>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64TruncSF64>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64TruncUF64>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64TruncSF32>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64TruncUF32>):
(JSC::Wasm::AirIRGenerator::addShift):
(JSC::Wasm::AirIRGenerator::addFloatingPointBinOp):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Min>):
(JSC::Wasm::AirIRGenerator::addFloatingPointMinOrMax):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Max>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Mul>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Div>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Div>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F32Neg>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64Rotr>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64Rotl>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32ShrU>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32ShrS>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32Shl>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Min>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Sub>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64ShrS>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64ShrU>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64Shl>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32Rotl>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32Rotr>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Neg>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::F64Max>):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::addTableGet):
(JSC::Wasm::B3IRGenerator::addRefFunc):
(JSC::Wasm::B3IRGenerator::addTableInit):
(JSC::Wasm::B3IRGenerator::addTableSize):
(JSC::Wasm::B3IRGenerator::addTableGrow):
(JSC::Wasm::B3IRGenerator::addTableFill):
(JSC::Wasm::B3IRGenerator::addTableCopy):
(JSC::Wasm::B3IRGenerator::addMemoryFill):
(JSC::Wasm::B3IRGenerator::addMemoryInit):
(JSC::Wasm::B3IRGenerator::addMemoryCopy):
(JSC::Wasm::B3IRGenerator::sanitizeAtomicResult):
(JSC::Wasm::B3IRGenerator::atomicLoad):
(JSC::Wasm::B3IRGenerator::emitAtomicStoreOp):
(JSC::Wasm::B3IRGenerator::emitAtomicBinaryRMWOp):
(JSC::Wasm::B3IRGenerator::atomicBinaryRMW):
(JSC::Wasm::B3IRGenerator::emitAtomicCompareExchange):
(JSC::Wasm::B3IRGenerator::atomicCompareExchange):
* wasm/WasmCallingConvention.h:
(JSC::Wasm::WasmCallingConvention::marshallLocation const):
(JSC::Wasm::WasmCallingConvention::callInformationFor const):
(JSC::Wasm::JSCallingConvention::marshallLocation const):
* wasm/WasmFormat.h:
(JSC::Wasm::isValueType):
(JSC::Wasm::isRefType):
(JSC::Wasm::TableInformation::wasmType const):
* wasm/WasmFunctionCodeBlock.h:
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser::TypedExpression::TypedExpression):
(JSC::Wasm::FunctionParser<Context>::load):
(JSC::Wasm::FunctionParser<Context>::store):
(JSC::Wasm::FunctionParser<Context>::atomicLoad):
(JSC::Wasm::FunctionParser<Context>::atomicStore):
(JSC::Wasm::FunctionParser<Context>::atomicBinaryRMW):
(JSC::Wasm::FunctionParser<Context>::atomicCompareExchange):
(JSC::Wasm::FunctionParser<Context>::atomicWait):
(JSC::Wasm::FunctionParser<Context>::atomicNotify):
(JSC::Wasm::FunctionParser<Context>::checkBranchTarget):
(JSC::Wasm::FunctionParser<Context>::unify):
(JSC::Wasm::FunctionParser<Context>::parseExpression):
* wasm/WasmGlobal.cpp:
(JSC::Wasm::Global::get const):
(JSC::Wasm::Global::set):
(JSC::Wasm::Global::visitAggregateImpl):
* wasm/WasmLLIntGenerator.cpp:
(JSC::Wasm::LLIntGenerator::jsNullConstant):
(JSC::Wasm::LLIntGenerator::zeroConstant):
(JSC::Wasm::LLIntGenerator::callInformationForCaller):
(JSC::Wasm::LLIntGenerator::callInformationForCallee):
(JSC::Wasm::LLIntGenerator::addArguments):
(JSC::Wasm::LLIntGenerator::addLocal):
* wasm/WasmOperations.cpp:
(JSC::Wasm::JSC_DEFINE_JIT_OPERATION):
* wasm/WasmParser.h:
(JSC::Wasm::Parser<SuccessType>::parseBlockSignature):
(JSC::Wasm::Parser<SuccessType>::parseValueType):
* wasm/WasmSectionParser.cpp:
(JSC::Wasm::SectionParser::parseType):
(JSC::Wasm::SectionParser::parseTableHelper):
(JSC::Wasm::SectionParser::parseGlobal):
(JSC::Wasm::SectionParser::parseElement):
(JSC::Wasm::SectionParser::parseInitExpr):
(JSC::Wasm::SectionParser::parseI32InitExpr):
(JSC::Wasm::SectionParser::parseElementSegmentVectorOfExpressions):
* wasm/WasmSignature.cpp:
(JSC::Wasm::Signature::dump const):
(JSC::Wasm::computeHash):
(JSC::Wasm::SignatureInformation::SignatureInformation):
* wasm/WasmSignature.h:
(JSC::Wasm::SignatureInformation::thunkFor const):
* wasm/WasmTable.cpp:
(JSC::Wasm::Table::wasmType const):
* wasm/generateWasmOpsHeader.py:
(TypeKind):
* wasm/js/JSToWasm.cpp:
(JSC::Wasm::marshallJSResult):
(JSC::Wasm::createJSToWasmWrapper):
* wasm/js/JSWebAssemblyHelpers.h:
(JSC::defaultValueForReferenceType):
* wasm/js/WasmToJS.cpp:
(JSC::Wasm::wasmToJS):
* wasm/js/WebAssemblyFunction.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::WebAssemblyFunction::jsCallEntrypointSlow):
* wasm/js/WebAssemblyGlobalConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::linkImpl):
2021-03-02 Yusuke Suzuki <ysuzuki@apple.com>
Flaky JSC test: stress/shared-array-buffer-sort-while-different-thread-is-modifying.js.default
https://bugs.webkit.org/show_bug.cgi?id=221129
Reviewed by Saam Barati.
Speculative fix for JSC shell's termination handling change.
* jsc.cpp:
(CommandLine::CommandLine):
(jscmain):
2021-03-02 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Remove ImpureProxyType
https://bugs.webkit.org/show_bug.cgi?id=222626
Reviewed by Alexey Shvayka.
ImpureProxyType is no longer used. This patch just removes it.
* API/tests/JSObjectGetProxyTargetTest.cpp:
(testJSObjectGetProxyTarget):
* runtime/HasOwnPropertyCache.h:
(JSC::HasOwnPropertyCache::tryAdd):
* runtime/JSCast.h:
* runtime/JSCellInlines.h:
(JSC::JSCell::isProxy const):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::resetPrototype):
(JSC::JSGlobalObject::finishCreation):
* runtime/JSProxy.h:
(JSC::JSProxy::createStructure):
* runtime/JSType.cpp:
(WTF::printInternal):
* runtime/JSType.h:
* runtime/Structure.h:
(JSC::Structure::isProxy const):
* tools/JSDollarVM.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
2021-03-02 Saam Barati <sbarati@apple.com>
Improve logging of OSR availability analysis validation failures
https://bugs.webkit.org/show_bug.cgi?id=222612
Reviewed by Yusuke Suzuki.
* dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
(JSC::DFG::OSRAvailabilityAnalysisPhase::run):
2021-03-02 Devin Rousso <drousso@apple.com>
Allow IDL `Date` to be parsed from a string in addition to a number and actual JS `Date`
https://bugs.webkit.org/show_bug.cgi?id=222605
<rdar://problem/74502335>
Reviewed by Yusuke Suzuki.
JS `Date` can be stringified into JSON, but cannot be parsed back into a JS `Date` without
additional logic since the stringified value is indistinguishable from a regular string.
* runtime/JSDateMath.h:
Export `DateCache::parseDate` so it can be used in WebCore bindings code.
2021-03-02 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Optimize getEnumerableLength
https://bugs.webkit.org/show_bug.cgi?id=222539
Reviewed by Alexey Shvayka.
Now getEnumerableLength is only overridden by JSProxy. And this is called in the critical path of propertyNameEnumerator.
We should not use indirect call for getEnumerableLength. We remove indirect functions for getEnumerableLength. For JSProxy,
any results is OK since anyway JSProxy does not utilize the result of this function since it cannot use fast index enumerator.
We also avoid calling holesMustForwardToPrototype in getEnumerableLength when it is meaningless. For example,
if the object is ALL_BLANK_INDEXING_TYPES, then regardless of the condition of holesMustForwardToPrototype, the result of
getEnumerableLength is zero.
* runtime/ClassInfo.h:
* runtime/JSCast.h:
* runtime/JSCell.cpp:
(JSC::JSCell::getEnumerableLength): Deleted.
* runtime/JSCell.h:
* runtime/JSObject.cpp:
(JSC::JSObject::getEnumerableLength):
* runtime/JSObject.h:
* runtime/JSPropertyNameEnumerator.h:
(JSC::propertyNameEnumerator):
* runtime/JSProxy.cpp:
(JSC::JSProxy::getEnumerableLength): Deleted.
* runtime/JSProxy.h:
2021-03-02 BJ Burg <bburg@apple.com>
[Cocoa] REGRESSION(r272752): fix some internal builds that use WTFString::WTFString(NSString *)
https://bugs.webkit.org/show_bug.cgi?id=222610
<rdar://74938249>
Unreviewed build fix.
* inspector/scripts/codegen/generate_objc_protocol_type_conversions_implementation.py:
(ObjCProtocolTypeConversionsImplementationGenerator._generate_type_factory_method_implementation):
Some builders seem to find the new version of the header (without the exported NSString constructor)
whereas others don't find the new version (expecting the symbol to be exported), causing a linker error later on.
As a workaround, force usage of the CFStringRef constructor, which is always exported.
* inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/expected/enum-values.json-result:
* inspector/scripts/tests/expected/type-declaration-array-type.json-result:
* inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
* inspector/scripts/tests/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
Rebaseline generator test results.
2021-03-02 Alexey Shvayka <shvaikalesh@gmail.com>
TypedArray's [[DefineOwnProperty]] should throw in case of failure
https://bugs.webkit.org/show_bug.cgi?id=220492
Reviewed by Darin Adler.
While web reality [1] requires failures of the most TypeArray internal methods to be
silent, [[DefineOwnProperty]] can fail loudly if called via Object.defineProperty.
With this patch, TypeError is thrown for detached buffer, out-of-bounds index, and
non-index canonical numeric string key. Aligns JSC with the spec [2], V8, and SM.
[1]: https://github.com/tc39/ecma262/pull/2164
[2]: https://tc39.es/ecma262/#sec-integer-indexed-exotic-objects-defineownproperty-p-desc (step 3.b)
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
2021-03-01 Keith Miller <keith_miller@apple.com>
Reduce promise reaction memory usage when there are multiple reactions
https://bugs.webkit.org/show_bug.cgi?id=222533
Reviewed by Yusuke Suzuki.
Previously, we would store each reaction in a linked list. This
meant each reaction required 8 bytes to point to the next
reaction. Instead, this patch makes it so the first reaction is
store inline an object and any additional reactions are store into
index storage for that object. This doesn't save memory for the
first reaction since we now need to have a count of all the out of
line reactions but extra reactions use 8 bytes less each.
* builtins/BuiltinNames.h:
* builtins/PromiseOperations.js:
(globalPrivate.pushNewPromiseReaction):
(globalPrivate.triggerPromiseReactions):
(globalPrivate.newPromiseReaction): Deleted.
(globalPrivate.resolvePromise): Deleted.
(globalPrivate.rejectPromise): Deleted.
(globalPrivate.fulfillPromise): Deleted.
(globalPrivate.resolvePromiseWithFirstResolvingFunctionCallCheck): Deleted.
(globalPrivate.fulfillPromiseWithFirstResolvingFunctionCallCheck): Deleted.
(globalPrivate.rejectPromiseWithFirstResolvingFunctionCallCheck): Deleted.
(globalPrivate.createResolvingFunctions): Deleted.
(globalPrivate.promiseReactionJobWithoutPromise): Deleted.
(globalPrivate.resolveWithoutPromise): Deleted.
(globalPrivate.rejectWithoutPromise): Deleted.
(globalPrivate.fulfillWithoutPromise): Deleted.
(globalPrivate.createResolvingFunctionsWithoutPromise): Deleted.
(globalPrivate.promiseReactionJob): Deleted.
(globalPrivate.promiseResolveThenableJobFast): Deleted.
(globalPrivate.promiseResolveThenableJobWithoutPromiseFast): Deleted.
(globalPrivate.promiseResolveThenableJob): Deleted.
(globalPrivate.promiseResolveThenableJobWithDerivedPromise): Deleted.
(onFulfilled): Deleted.
(onRejected): Deleted.
(globalPrivate.performPromiseThen): Deleted.
* runtime/JSGlobalObject.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/JSMicrotask.cpp:
(JSC::createJSMicrotask):
* runtime/JSMicrotask.h:
2021-03-01 Yusuke Suzuki <ysuzuki@apple.com>
REGRESSION: Object.defineProperties triggering a setter
https://bugs.webkit.org/show_bug.cgi?id=222538
Reviewed by Keith Miller.
DFG's compilePutByValForCellWithString and compilePutByValForCellWithSymbol do not care about "Direct" flag.
This patch fixes that to call appropriate function if node is PutByValDirect.
FTL does not have this issue.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compilePutByValForCellWithString):
(JSC::DFG::SpeculativeJIT::compilePutByValForCellWithSymbol):
2021-03-01 Xan Lopez <xan@igalia.com>
[JSC] WebAssembly: make Wasm::Signature 32bit friendly
https://bugs.webkit.org/show_bug.cgi?id=222543
Reviewed by Yusuke Suzuki.
The Wasm code uses the address of a Signature object as its
index. To make this work in 32bit just change Wasm::SignatureIndex
to be a uintptr_t instead of uint64_t. Also, remove some
unnecessary includes while we are at it.
* wasm/WasmModule.h:
* wasm/WasmSignature.h:
* wasm/js/JSWebAssemblyModule.h:
2021-03-01 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Throw TypeError when getFunctionRealm hits revoked Proxy
https://bugs.webkit.org/show_bug.cgi?id=222523
Reviewed by Alexey Shvayka.
This patch throws TypeError when getFunctionRealm encounters revoked Proxy. However,
this makes derived structure creation code difficult to be written inlinely.
The fast path of derived structure creation must be inlined since this is critical
path of every builtin constructors.
So, this patch introduces JSC_GET_DERIVED_STRUCTURE macro which streamlines the derived
structure creation code while keeping the fast path inlined. And it inserts appropriate
error checks after this new getFunctionRealm call.
Then, we appropriately use getFunctionRealm in op_create_this implementation.
* dfg/DFGOperations.cpp:
(JSC::DFG::JSC_DEFINE_JIT_OPERATION):
* runtime/AggregateErrorConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/BooleanConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/CommonSlowPaths.cpp:
(JSC::JSC_DEFINE_COMMON_SLOW_PATH):
* runtime/DateConstructor.cpp:
(JSC::constructDate):
* runtime/ErrorConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/FinalizationRegistryConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/InternalFunction.cpp:
(JSC::getFunctionRealm):
* runtime/InternalFunction.h:
* runtime/IntlCollatorConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/IntlDateTimeFormatConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/IntlDisplayNamesConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/IntlListFormatConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/IntlLocaleConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/IntlNumberFormatConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/IntlPluralRulesConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/IntlRelativeTimeFormatConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/IntlSegmenterConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/JSArrayBufferConstructor.cpp:
(JSC::JSGenericArrayBufferConstructor<sharingMode>::constructImpl):
* runtime/JSGenericTypedArrayViewConstructorInlines.h:
(JSC::constructCustomArrayBufferIfNeeded):
(JSC::constructGenericTypedArrayViewImpl):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::errorStructureWithErrorType const):
(JSC::JSGlobalObject::arrayBufferStructureWithSharingMode const):
(JSC::JSGlobalObject::typedArrayStructureWithTypedArrayType const):
* runtime/JSGlobalObjectInlines.h:
(JSC::JSGlobalObject::arrayStructureForIndexingTypeDuringAllocation const):
* runtime/MapConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/NativeErrorConstructor.cpp:
(JSC::NativeErrorConstructor<errorType>::constructImpl):
* runtime/NumberConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/ObjectConstructor.cpp:
(JSC::constructObjectWithNewTarget):
* runtime/ProxyConstructor.cpp:
(JSC::ProxyConstructor::create):
(JSC::ProxyConstructor::finishCreation):
* runtime/ProxyConstructor.h:
* runtime/RegExpConstructor.cpp:
(JSC::getRegExpStructure):
* runtime/SetConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/StringConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/WeakMapConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/WeakObjectRefConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/WeakSetConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* wasm/js/WebAssemblyCompileErrorConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* wasm/js/WebAssemblyGlobalConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* wasm/js/WebAssemblyInstanceConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* wasm/js/WebAssemblyLinkErrorConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* wasm/js/WebAssemblyMemoryConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* wasm/js/WebAssemblyModuleConstructor.cpp:
(JSC::WebAssemblyModuleConstructor::createModule):
* wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* wasm/js/WebAssemblyTableConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
2021-03-01 Alexey Shvayka <shvaikalesh@gmail.com>
BytecodeGenerator::fuseCompareAndJump() fails for some language constructs
https://bugs.webkit.org/show_bug.cgi?id=221927
Reviewed by Yusuke Suzuki.
For BytecodeGenerator::fuseCompareAndJump() to merge two ops into one, condition's `dst`
register should not be referenced from elsewhere. This change tracks down and eliminates
all such cases, which reduces bytecode size for a few language constructs:
-1 per every `case` of a `switch`;
-2 per generator function, -2 per every `yield` / `yield*`;
-2 per `class extends`;
-2 per `finally`, -1 per every `break` / `continue` / `return` inside;
-3 per Function.prototype.apply() with `...spread` as a single argument.
Instead of mixing RefPtr with raw C++ pointers, single-line branches were preferred.
To keep them cleaner, this patch introduces emitLoad() override for JSGenerator::ResumeMode
enum, and tweaks existing override for CompletionType.
A few drive-by improvements:
* to enable future optimizations, replaces emitBinaryOp() with emitEqualityOp()
for OpEq / OpStricteq (adds an assert), and vice-versa for other comparison ops;
* removes OperandTypes for comparison ops as it was ignored
(let's re-introduce them consistently once supported);
* inlines too specific BytecodeGenerator::emitJumpIf();
* replaces `eq` with `stricteq` in ApplyFunctionCallDotNode.
No behavior change, no callee registers count grow.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitYield):
(JSC::BytecodeGenerator::emitDelegateYield):
(JSC::BytecodeGenerator::emitFinallyCompletion):
(JSC::BytecodeGenerator::emitJumpIf): Deleted.
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::emitEqualityOp):
(JSC::BytecodeGenerator::emitLoad):
* bytecompiler/NodesCodegen.cpp:
(JSC::ApplyFunctionCallDotNode::emitBytecode):
(JSC::ForInNode::emitBytecode):
(JSC::CaseBlockNode::emitBytecodeForBlock):
(JSC::FunctionNode::emitBytecode):
(JSC::ClassExprNode::emitBytecode):
2021-02-28 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Add gc and clearKeptObjects to $262
https://bugs.webkit.org/show_bug.cgi?id=222527
Reviewed by Ross Kirsling.
Add $262.gc and $262.clearKeptObjects functions. They are required for test262 host-gc-required.
Since all the tests using "host-gc-required" are currently also marked with cleanupSome, we are currently not running them.
But if some more tests are landed in test262 with "host-gc-required", we will run them with these functions.
* jsc.cpp:
(JSC_DEFINE_HOST_FUNCTION):
2021-02-28 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Update test262 host environments
https://bugs.webkit.org/show_bug.cgi?id=222525
Reviewed by Ross Kirsling.
1. $262.global should be `globalThis` of the realm according to test/built-ins/Function/call-bind-this-realm-undef.js
2. $262.evalScript should uwrap JSProxy to get GlobalObject.
This fixes test262 test/built-ins/Function/call-bind-this-realm-undef.js, it was wrongly tested and failing.
* jsc.cpp:
(JSC_DEFINE_HOST_FUNCTION):
2021-02-27 Rob Buis <rbuis@igalia.com>
Null check ArrayBufferView RefPtr
https://bugs.webkit.org/show_bug.cgi?id=221569
Reviewed by Ryosuke Niwa.
Null check ArrayBufferView RefPtr before using it.
* runtime/JSArrayBufferViewInlines.h:
(JSC::JSArrayBufferView::unsharedImpl):
2021-02-26 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Avoid creating functions unnecessarily in builtins
https://bugs.webkit.org/show_bug.cgi?id=222509
Reviewed by Ross Kirsling.
Avoid unnecessary function creation and make them @globalPrivate.
* builtins/ArrayPrototype.js:
(globalPrivate.maxWithPositives):
(globalPrivate.minWithMaybeNegativeZeroAndPositive):
(copyWithin):
(maxWithPositives): Deleted.
(minWithMaybeNegativeZeroAndPositive): Deleted.
* builtins/DatePrototype.js:
(globalPrivate.toDateTimeOptionsAnyAll):
(toLocaleString):
(globalPrivate.toDateTimeOptionsDateDate):
(toLocaleDateString):
(globalPrivate.toDateTimeOptionsTimeTime):
(toLocaleTimeString):
(toLocaleString.toDateTimeOptionsAnyAll): Deleted.
(toLocaleDateString.toDateTimeOptionsDateDate): Deleted.
(toLocaleTimeString.toDateTimeOptionsTimeTime): Deleted.
* builtins/RegExpPrototype.js:
(globalPrivate.getSubstitution):
(overriddenName.string_appeared_here.replace):
(getSubstitution): Deleted.
2021-02-26 Saam Barati <sbarati@apple.com>
Remove bad assertion of AI ArrayMode state in various "by val" opcodes
https://bugs.webkit.org/show_bug.cgi?id=222494
<rdar://73613460>
Reviewed by Filip Pizlo.
It's invalid to ever assert that AI must have proved something. We've been
slowly removing these faulty asserts from the compiler, and this patch
removes some more of them. AI is conservative, and it's not guaranteed
that it will prove X, even if X must be true.
In this particular test case, we are looking at a race between the concurrent
compiler thread and the main thread, and the compilation will be thrown away
because of a Structure transition.
What happened in this particular program is we had a CheckStructure that was
proved to exit in an early run of AI, that is not shown to exit during a later
run of AI. Because of that, in the earlier AI run, we have some narrower type
info (because fewer predecessory type info). This narrower type info allowed
us to elide a CheckArray. The later runs don't have this narrower type info,
because the CheckStructure doesn't exit. The safety of all of this is
guaranteed by the compilation being thrown away because we fired the transition
watchpoint from the earlier Structure seen by AI.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileGetByValOnString):
(JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray):
(JSC::DFG::SpeculativeJIT::compileGetByValOnDirectArguments):
(JSC::DFG::SpeculativeJIT::compileGetByValOnScopedArguments):
(JSC::DFG::SpeculativeJIT::compileGetArrayLength):
2021-02-26 Chris Dumez <cdumez@apple.com>
Reduce explicit usage of [objC retain] in WebKit
https://bugs.webkit.org/show_bug.cgi?id=222439
Reviewed by Darin Adler.
Reduce explicit usage of [objC retain] in WebKit by using RetainPtr<>.
* API/JSContext.mm:
(+[JSContext currentArguments]):
(-[JSContext beginCallbackWithData:calleeValue:thisValue:argumentCount:arguments:]):
(-[JSContext endCallbackWithData:]):
* API/JSContextInternal.h:
* API/tests/testapi.mm:
(-[TinyDOMNode initWithVirtualMachine:]):
2021-02-26 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Avoid function allocations for non-user-provided Promise then callbacks
https://bugs.webkit.org/show_bug.cgi?id=222490
Reviewed by Keith Miller.
At @performPromiseThen point, callback function objects themselves are not accessible from users
if they are not passed from users. So, we can reuse functions if users do not pass functions.
* builtins/PromiseOperations.js:
(globalPrivate.promiseEmptyOnFulfilled):
(globalPrivate.promiseEmptyOnRejected):
(globalPrivate.performPromiseThen):
(onFulfilled): Deleted.
(onRejected): Deleted.
2021-02-26 Michael Saboff <msaboff@apple.com>
unexpected minimumInputSize in setupDisjunctionOffsets for regexp engine(yarr)
https://bugs.webkit.org/show_bug.cgi?id=220357
Reviewed by Saam Barati.
Removed an unnecessary ASSERT.
This assert checked that the minimum size wasn't UINT_MAX which I believe was
intended to make sure the minimum size was changed while computing the
disjunction's size and offsets. Those calculations involve checked arithmetic,
which would catch any overflow.
The other part of this patch adds a test that checks this condition as well
as the case where the pattern is one character longer, 2^32, which triggers
the arithmetic overflow.
* yarr/YarrPattern.cpp:
(JSC::Yarr::YarrPatternConstructor::setupDisjunctionOffsets):
2021-02-26 Yusuke Suzuki <ysuzuki@apple.com>
Flaky JSC test: stress/atomic-increment-bigint64.js
https://bugs.webkit.org/show_bug.cgi?id=221904
Reviewed by Keith Miller.
bytecode-cache test assumes that code can be cached once it is executed. But this
is not correct for threading tests using JSC shell's agent feature: code is running
different VM in the different thread. And we have no guarantee that this thread destroys
VM when the main thread is finished. So this is possible that bytecode used in that thread
is not committed.
We use Options::forceDiskCache's RELEASE_ASSERT only if it is in main thread.
* runtime/CodeCache.h:
2021-02-25 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Fix typo in wasm error message
https://bugs.webkit.org/show_bug.cgi?id=222444
Reviewed by Saam Barati.
* wasm/WasmStreamingParser.cpp:
(JSC::Wasm::StreamingParser::parseModuleHeader):
2021-02-25 Alex Christensen <achristensen@webkit.org>
Add stubs to enable SafariForWebKitDevelopment to launch
https://bugs.webkit.org/show_bug.cgi?id=222388
Reviewed by Myles Maxfield.
* JavaScriptCore.xcodeproj/project.pbxproj:
* runtime/SymbolStubsForSafariCompatibility.mm: Added.
(WTF::String::String):
(WTF::JSONImpl::ObjectBase::getArray const):
(WTF::JSONImpl::ObjectBase::getValue const):
(WTF::JSONImpl::ObjectBase::getObject const):
(Inspector::BackendDispatcher::sendResponse):
2021-02-25 Razvan Caliman <rcaliman@apple.com>
Web Inspector: List of grid nodes is incomplete in Layout sidebar panel
https://bugs.webkit.org/show_bug.cgi?id=222364
<rdar://problem/74700960>
Reviewed by Devin Rousso.
Update inspector protocol description for CSS domain to mention default value for
`layoutContextTypeChangedMode` ("observed") and clarify behavior of "all" value.
* inspector/protocol/CSS.json:
2021-02-25 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r273469.
https://bugs.webkit.org/show_bug.cgi?id=222417
Broke 30+ debug layout tests
Reverted changeset:
"Add stubs to enable SafariForWebKitDevelopment to launch"
https://bugs.webkit.org/show_bug.cgi?id=222388
https://trac.webkit.org/changeset/273469
2021-02-25 Dmitry Bezhetskov <dbezhetskov@igalia.com>
Fix signed vs unsigned comparision warning in JSBigInt
https://bugs.webkit.org/show_bug.cgi?id=222400
Reviewed by Yusuke Suzuki.
Fix the warning about comparing uint64_t with int64_t in JSBigInt.
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::parseInt):
2021-02-24 Alex Christensen <achristensen@webkit.org>
Add stubs to enable SafariForWebKitDevelopment to launch
https://bugs.webkit.org/show_bug.cgi?id=222388
Reviewed by Myles Maxfield.
* JavaScriptCore.xcodeproj/project.pbxproj:
* runtime/SymbolStubsForSafariCompatibility.mm: Added.
(WTF::String::String):
(WTF::JSONImpl::ObjectBase::getArray const):
(WTF::JSONImpl::ObjectBase::getValue const):
(WTF::JSONImpl::ObjectBase::getObject const):
(Inspector::BackendDispatcher::sendResponse):
2021-02-24 Ryan Haddad <ryanhaddad@apple.com>
Unreviewed, reverting r273373.
The test added with this change is frequently failing
Reverted changeset:
"Null check ArrayBufferView RefPtr"
https://bugs.webkit.org/show_bug.cgi?id=221569
https://commits.webkit.org/r273373
2021-02-24 Rob Buis <rbuis@igalia.com>
Null check ArrayBufferView RefPtr
https://bugs.webkit.org/show_bug.cgi?id=221569
Reviewed by Yusuke Suzuki.
Null check ArrayBufferView RefPtr before using it.
* runtime/JSArrayBufferViewInlines.h:
(JSC::JSArrayBufferView::unsharedImpl):
2021-02-23 Michael Saboff <msaboff@apple.com>
[YARR JIT] Crash on overflow when compiling /(a{1000000000}b{1000000000}|c{1000000000}|)d{1000000000}e{1000000000}/.test();
https://bugs.webkit.org/show_bug.cgi?id=220130
Reviewed by Yusuke Suzuki.
Changed code to subtract out the offset of a current op before adding the offset
of the prior op when backtracking to avoid overflowing checked arithmetic.
It looks like the code had this wrong for some time.
* yarr/YarrJIT.cpp:
2021-02-22 Don Olmstead <don.olmstead@sony.com>
Non-unified build fixes late February 2021 edition
https://bugs.webkit.org/show_bug.cgi?id=222303
Unreviewed non-unified build fixes.
* API/JSAPIValueWrapper.cpp:
* bytecode/SetPrivateBrandVariant.h:
* heap/HeapAnalyzer.h:
* heap/HeapProfiler.cpp:
* parser/ParserTokens.h:
* runtime/DOMAttributeGetterSetter.cpp:
* runtime/GlobalExecutable.cpp:
* runtime/JSScriptFetchParameters.cpp:
2021-02-22 Keith Miller <keith_miller@apple.com>
Move asyncModuleEvaluation into its own function and use intrinsic constants
https://bugs.webkit.org/show_bug.cgi?id=222281
Reviewed by Yusuke Suzuki.
Also delete an unused field on the module entry.
* builtins/ModuleLoader.js:
(globalPrivate.newRegistryEntry):
(moduleEvaluation):
(async asyncModuleEvaluation):
* runtime/JSModuleLoader.cpp:
2021-02-22 Keith Miller <keith_miller@apple.com>
Remove unused internal fields from AbstractModuleLoader
https://bugs.webkit.org/show_bug.cgi?id=222256
Reviewed by Saam Barati.
* runtime/AbstractModuleRecord.h:
(JSC::AbstractModuleRecord::initialValues):
2021-02-21 Lauro Moura <lmoura@igalia.com>
Fix warning after r273225
https://bugs.webkit.org/show_bug.cgi?id=222257
Reviewed by Keith Miller.
The UNLIKELY condition raises a warn with "suggest parentheses around
‘&&’ within ‘||’" for the last pair.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseUnaryExpression):
2021-02-21 Keith Miller <keith_miller@apple.com>
Unreviewed, fix CMake build.
* CMakeLists.txt:
2021-02-21 Keith Miller <keith_miller@apple.com>
Implement the Top-level await proposal
https://bugs.webkit.org/show_bug.cgi?id=202484
Reviewed by Yusuke Suzuki.
This patch adds support for the TLA proposal. The bulk of this patch is adding a couple of main parts.
1) converting the AbstractModuleRecord to contain many of same internal fields as JSGenerator so much of the async codegen can be shared.
2) having the link phase of the module loader record whether a module subgraph is async.
3) teaching the module loader that evaluating a module may require more than one vm entry and forwarding the awaited value as well as the resume mode to the VM.
One thing particularly interesting about this patch is that moduleEvaluation now *sometimes* (when a strongly connected subgraph is async) will return a promise. This happened to already be awaited when called from loadAndEvaluateModule (unnecessarily before) but now also needs to be handled by requestImportModule.
No new tests because every test I came up with was subsumed by tests already in test262.
* API/JSAPIGlobalObject.h:
* API/JSAPIGlobalObject.mm:
(JSC::JSAPIGlobalObject::moduleLoaderEvaluate):
* JavaScriptCore.xcodeproj/project.pbxproj:
* builtins/ModuleLoader.js:
(globalPrivate.newRegistryEntry):
(link):
(async requestImportModule):
(moduleEvaluation): Deleted.
(requestImportModule): Deleted.
* bytecode/BytecodeGeneratorification.cpp:
(JSC::BytecodeGeneratorification::run):
(JSC::performGeneratorification):
* bytecode/BytecodeIntrinsicRegistry.cpp:
(JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
* bytecode/BytecodeIntrinsicRegistry.h:
* bytecode/BytecodeList.rb:
* bytecode/BytecodeUseDef.cpp:
(JSC::computeUsesForBytecodeIndexImpl):
* bytecode/UnlinkedModuleProgramCodeBlock.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::generate):
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::emitWillLeaveCallFrameDebugHook):
(JSC::BytecodeGenerator::emitGenericEnumeration):
(JSC::BytecodeGenerator::emitYieldPoint):
(JSC::BytecodeGenerator::emitYield):
(JSC::BytecodeGenerator::emitDelegateYield):
(JSC::BytecodeGenerator::emitGeneratorStateChange):
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::generatorStateRegister):
(JSC::BytecodeGenerator::generatorValueRegister):
(JSC::BytecodeGenerator::generatorResumeModeRegister):
(JSC::BytecodeGenerator::generatorFrameRegister):
* bytecompiler/NodesCodegen.cpp:
(JSC::abstractModuleRecordInternalFieldIndex):
(JSC::BytecodeIntrinsicNode::emit_intrinsic_getAbstractModuleRecordInternalField):
(JSC::FunctionNode::emitBytecode):
* interpreter/Interpreter.cpp:
(JSC::Interpreter::executeModuleProgram):
* interpreter/Interpreter.h:
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createAwait):
(JSC::ASTBuilder::usesAwait):
* parser/Nodes.cpp:
(JSC::ModuleProgramNode::ModuleProgramNode):
* parser/Nodes.h:
* parser/Parser.cpp:
(JSC::JSToken::dump const):
(JSC::Parser<LexerType>::parseForStatement):
(JSC::Parser<LexerType>::parseAwaitExpression):
(JSC::Parser<LexerType>::parsePrimaryExpression):
(JSC::Parser<LexerType>::parseUnaryExpression):
* parser/ParserModes.h:
* parser/ParserTokens.h:
* runtime/AbstractModuleRecord.cpp:
(JSC::AbstractModuleRecord::finishCreation):
(JSC::AbstractModuleRecord::link):
(JSC::AbstractModuleRecord::evaluate):
* runtime/AbstractModuleRecord.h:
(JSC::AbstractModuleRecord::initialValues):
(JSC::AbstractModuleRecord::internalField):
(JSC::AbstractModuleRecord::internalField const):
* runtime/JSAsyncGenerator.h:
* runtime/JSGenerator.h:
* runtime/JSGlobalObject.h:
* runtime/JSModuleLoader.cpp:
(JSC::JSModuleLoader::evaluate):
(JSC::JSModuleLoader::evaluateNonVirtual):
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/JSModuleLoader.h:
* runtime/JSModuleRecord.cpp:
(JSC::JSModuleRecord::link):
(JSC::JSModuleRecord::evaluate):
* runtime/JSModuleRecord.h:
* runtime/ModuleProgramExecutable.h:
* runtime/OptionsList.h:
* runtime/SymbolTable.cpp:
(JSC::SymbolTable::dump const):
* runtime/SymbolTable.h:
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::link):
(JSC::WebAssemblyModuleRecord::linkImpl):
* wasm/js/WebAssemblyModuleRecord.h:
2021-02-21 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] JSInternalPromise::then can fail if execution is terminated
https://bugs.webkit.org/show_bug.cgi?id=222244
Reviewed by Mark Lam.
JSInternalPromise::then assumed that call's result is always JSInternalPromise.
But this is wrong if termination exception is thrown. In that case, this call fails.
This patch makes it robust against this behavior.
* runtime/JSInternalPromise.cpp:
(JSC::JSInternalPromise::then):
2021-02-21 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Remove vm.topCallFrame storing in Baseline JIT
https://bugs.webkit.org/show_bug.cgi?id=222162
Reviewed by Mark Lam.
This patch removes vm.topCallFrame storing in the Baseline JIT for ports that can USE(BUILTIN_FRAME_ADDRESS).
Also refactored some CommonSlowPath functions so that they can start using __builtin_frame_address later
instead of requiring that CallFrame be passed in.
* jit/JITInlines.h:
(JSC::JIT::updateTopCallFrame):
* runtime/CommonSlowPaths.cpp:
(JSC::iteratorOpenTryFastImpl):
(JSC::JSC_DEFINE_COMMON_SLOW_PATH):
(JSC::iteratorNextTryFastImpl):
2021-02-19 Yusuke Suzuki <ysuzuki@apple.com>
JS Modules in Workers
https://bugs.webkit.org/show_bug.cgi?id=164860
Reviewed by Saam Barati.
Add error information to extract this in WebCore's module loader.
Currently, we are using Promise pipeline, and this makes it a bit difficult to extract error information.
This error information attached in this patch allows us to extract SyntaxError in WebCore, and throwing
JS SyntaxError instead of AbortError.
We are planning to update our module pipieline not using Promises in the future. The current design derived
from the original module loader pipeline where using Promises is critical. But now, that proposal was abandoned,
so we can just simplify the module loader.
* runtime/AggregateError.cpp:
(JSC::AggregateError::AggregateError):
* runtime/Error.cpp:
(JSC::createError):
(JSC::createEvalError):
(JSC::createRangeError):
(JSC::createReferenceError):
(JSC::createSyntaxError):
(JSC::createTypeError):
(JSC::createURIError):
(JSC::createGetterTypeError):
(JSC::throwSyntaxError):
* runtime/Error.h:
* runtime/ErrorConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/ErrorInstance.cpp:
(JSC::ErrorInstance::ErrorInstance):
(JSC::ErrorInstance::create):
(JSC::ErrorInstance::sanitizedMessageString):
(JSC::ErrorInstance::sanitizedNameString):
(JSC::ErrorInstance::sanitizedToString):
* runtime/ErrorInstance.h:
(JSC::ErrorInstance::create):
(JSC::ErrorInstance::errorType const):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/NativeErrorConstructor.cpp:
(JSC::NativeErrorConstructor<errorType>::constructImpl):
(JSC::NativeErrorConstructor<errorType>::callImpl):
* runtime/NullSetterFunction.cpp:
(JSC::NullSetterFunctionInternal::JSC_DEFINE_HOST_FUNCTION):
* wasm/js/JSWebAssemblyCompileError.cpp:
(JSC::JSWebAssemblyCompileError::JSWebAssemblyCompileError):
* wasm/js/JSWebAssemblyLinkError.cpp:
(JSC::JSWebAssemblyLinkError::JSWebAssemblyLinkError):
* wasm/js/JSWebAssemblyRuntimeError.cpp:
(JSC::JSWebAssemblyRuntimeError::JSWebAssemblyRuntimeError):
* wasm/js/WebAssemblyCompileErrorConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* wasm/js/WebAssemblyLinkErrorConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
2021-02-19 Chris Dumez <cdumez@apple.com>
Review remaining usage of autorelease to make sure it is necessary
https://bugs.webkit.org/show_bug.cgi?id=222177
Reviewed by Geoffrey Garen.
* API/JSContext.mm:
(+[JSContext contextWithJSGlobalContextRef:]):
* API/JSVirtualMachine.mm:
(+[JSVirtualMachine virtualMachineWithContextGroupRef:]):
* API/JSWrapperMap.mm:
(-[JSWrapperMap objcWrapperForJSValueRef:inContext:]):
2021-02-19 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Not allocating empty object for Intl options
https://bugs.webkit.org/show_bug.cgi?id=222203
Reviewed by Mark Lam.
This patch introduces Optional<JSObject&> to Intl options to explicitly mark it as maybe-null.
This maybe-null object can appear when the options is undefined. According to the spec, we allocates
empty object (with null [[Prototype]]) for this case, but accessing this object's property is non-observable
since this does not have [[Prototype]]. As a result, we can skip allocation and accesses in this case.
This can also pave the way to avoiding allocations of options objects for Date#toLocaleString etc.'s specific cases.
* runtime/IntlCollator.cpp:
(JSC::IntlCollator::initializeCollator):
* runtime/IntlDateTimeFormat.cpp:
(JSC::IntlDateTimeFormat::initializeDateTimeFormat):
(JSC::toDateTimeOptionsAnyDate): Deleted.
* runtime/IntlDisplayNames.cpp:
(JSC::IntlDisplayNames::initializeDisplayNames):
* runtime/IntlListFormat.cpp:
(JSC::IntlListFormat::initializeListFormat):
* runtime/IntlLocale.cpp:
(JSC::IntlLocale::initializeLocale):
* runtime/IntlNumberFormat.cpp:
(JSC::IntlNumberFormat::initializeNumberFormat):
* runtime/IntlNumberFormat.h:
* runtime/IntlNumberFormatInlines.h:
(JSC::setNumberFormatDigitOptions):
* runtime/IntlObject.cpp:
(JSC::intlBooleanOption):
(JSC::intlStringOption):
(JSC::intlNumberOption):
(JSC::supportedLocales):
* runtime/IntlObject.h:
* runtime/IntlObjectInlines.h:
(JSC::intlOption):
(JSC::intlGetOptionsObject): Deleted.
* runtime/IntlPluralRules.cpp:
(JSC::IntlPluralRules::initializePluralRules):
* runtime/IntlPluralRules.h:
* runtime/IntlRelativeTimeFormat.cpp:
(JSC::IntlRelativeTimeFormat::initializeRelativeTimeFormat):
* runtime/IntlSegmenter.cpp:
(JSC::IntlSegmenter::initializeSegmenter):
2021-02-19 Michael Saboff <msaboff@apple.com>
Minor fixes to RegExp match indices after r273086
https://bugs.webkit.org/show_bug.cgi?id=222157
Reviewed by Yusuke Suzuki.
When hasIndices is true, but there aren't any named groups, the spec says that we should
create the indices.groups property is the value undefined.
Increased the size of FlagsString to 7 plus terminater to account for the new 'd' flags.
* runtime/RegExpMatchesArray.h:
(JSC::createRegExpMatchesArray):
* runtime/RegExpPrototype.cpp:
2021-02-19 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Do not use toObject for options in new Intl constructors
https://bugs.webkit.org/show_bug.cgi?id=222164
Reviewed by Alexey Shvayka.
New spec change[1] introduced stricter GetOptionsObject for relatively new Intl constructors: Intl.DisplayNames, Intl.ListFormat, and Intl.Segmenter[2].
This does not perform `ToObject`, and instead,
1. If the input is an undefined, then it returns empty object.
2. If the input is an object, then it returns this object.
3. Otherwise, throwing a TypeError.
This patch implements it.
[1]: https://github.com/tc39/ecma402/pull/538
[2]: https://github.com/tc39/proposal-intl-segmenter/issues/132
* runtime/IntlDisplayNames.cpp:
(JSC::IntlDisplayNames::initializeDisplayNames):
* runtime/IntlListFormat.cpp:
(JSC::IntlListFormat::initializeListFormat):
* runtime/IntlObjectInlines.h:
(JSC::intlGetOptionsObject):
* runtime/IntlSegmenter.cpp:
(JSC::IntlSegmenter::initializeSegmenter):
2021-02-19 Mark Lam <mark.lam@apple.com>
Need to rebase builtins generator tests results.
https://bugs.webkit.org/show_bug.cgi?id=222184
rdar://74528501
Reviewed by Yusuke Suzuki.
* Scripts/tests/builtins/expected/WebCore-AnotherGuardedInternalBuiltin-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
* Scripts/tests/builtins/expected/WebCoreJSBuiltins.h-result:
2021-02-19 Mark Lam <mark.lam@apple.com>
Implement a GC verifier.
https://bugs.webkit.org/show_bug.cgi?id=217274
rdar://56255683
Reviewed by Filip Pizlo and Saam Barati.
The idea behind the GC verifier is that in the GC End phase before we finalize
and sweep, we'll do a simple stop the world synchronous full GC with the
VerifierSlotVisitor. The VerifierSlotVisitor will collect it's own information
on whether a JS cell should be marked or not. After this verifier GC pass, we'll
compare the mark results.
If the verifier GC says a cell should be marked, then the real GC should have
marked the cell. The reverse is not true: if the verifier does not mark a cell,
it is still OK for the real GC to mark it. For example, in an eden GC, all old
generation cells would be considered mark by the real GC though the verifier would
know better if they are already dead.
Implementation details:
1. SlotVisitor (only used by the real GC) now inherits from a new abstract class,
AbstractSlotVisitor.
VerifierSlotVisitor (only used by the verifier GC) also inherits from
AbstractSlotVisitor.
2. AbstractSlotVisitor declares many virtual methods.
SlotVisitor implements some of these virtual methods as inline and final.
If the client is invoking one these methods and knows that it will be operating
on a SlotVisitor, the method being final allows it to be inlined into the client
instead of going through the virtual dispatch.
For the VerifierSlotVisitor, these methods will always be invoked by virtual
dispatch via the AbstractSlotVisitor abstraction.
3. Almost all methods that takes a SlotVisitor previously (with a few exceptions)
will now be templatized, and specialized to either take a SlotVisitor or an
AbstractSlotVisitor.
The cell MethodTable will now have 2 versions of visitChildren and visitOutputConstraints:
one for SlotVisitor, and one for AbstractSlotVisitor.
The reason we don't wire the 2nd version to VerifierSlotVisitor (instead of
AbstractSlotVisitor) is because we don't need the GC verifier to run at top
speed (though we don't want it to be too slow). Also, having hooks for using
an AbstractSlotVisitor gives us more utility for implementing other types of
GC checkers / analyzers in the future as subclasses of AbstractSlotVisitor.
4. Some minority of methods that used to take a SlotVisitor but are not critical
to performance, will now just take an AbstractSlotVisitor instead. For example,
see TypeProfilerLog::visit().
5. isReachableFromOpaqueRoots() methods will also only take an AbstractSlotVisitor.
The reason this is OK is because isReachableFromOpaqueRoots() only uses the
visitor's addOpaqueRoot() and containsOpaqueRoot() methods, which are implemented
in the AbstractSlotVisitor itself.
For SlotVisitor, the m_opaqueRoot field will reference Heap::m_opaqueRoots.
For VerifierSlotVisitor, the m_opaqueRoot field will reference its own
opaque roots storage.
This implementation of addOpaqueRoot() is perf neutral for SlotVisitor because
where it would previously invoke m_heap.m_opaqueRoots.add(), it will now
invoke m_opaqueRoot.add() instead where m_opaqueRoot points to m_heap.m_opaqueRoots.
Ditto for AbstractSlotVisitor::containsOpaqueRoot().
6. When reifying a templatized visit method, we do it in 2 ways:
a. Implement the template method as an ALWAYS_INLINE Impl method, and have
2 visit methods (taking a SlotVisitor and an AbstractSlotVisitor respectively)
inline the Impl method. For example, see JSObject::visitChildrenImpl().
b. Just templatize the visit method, and explicitly instantiate it with a SlotVisitor
and an AbstractSlotVisitor. For example, see DesiredTransition::visitChildren().
The reason we need form (a) is if:
i. we need to export the visit methods.
For example, see JSObject:visitChildren().
Note: A Clang engineer told me that "there's no way to export an explicit
instantiation that will make it a strong symbol." This is because "C++ does not
provide any standard way to guarantee that an explicit instantiation is unique,
and Clang hasn't added any extension to do so."
ii. the visit method is an override of a virtual method.
For example, see DFG::Scannable::visitChildren() and DFG::Graph::visitChildren().
Otherwise, we'll prefer form (b) as it is natural C++.
7. Because templatizing all the visit methods requires a lot of boiler plate code,
we introduce some macros in SlotVisitorMacros.h to reduce some of the boiler
plate burden.
We especially try to do this for methods of form (a) (see (6) above) which
require more boiler plate.
8. The driver of the real GC is MarkingConstraintSet::executeConvergence() which
runs with the MarkingConstraintSolver.
The driver of the verifier GC is Heap::verifyGC(), which has a loop to drain
marked objects and execute contraints.
9. The GC verifier is built in by default but disabled. The relevant options are:
JSC_verifyGC and JSC_verboseVerifyGC.
JSC_verifyGC will enable the GC verifier.
If JSC_verifyGC is true and the verifier finds a cell that is
erroneously not marked by the real GC, it will dump an error message and then
crash with a RELEASE_ASSERT.
JSC_verboseVerifyGC will enable the GC verifier along with some more heavy
weight record keeping (i.e. tracking the parent / owner cell that marked a
cell, and capturing the call stack when the marked cell is appended to the mark
stack).
If JSC_verboseVerifyGC is true and the verifier finds a cell that is
erroneously not marked by the real GC, it will dump the parent cell and
captured stack along with an error message before crashing. This extra
information provides the starting point for debugging GC bugs found by the
verifier.
Enabling JSC_verboseVerifyGC will automatically enable JSC_verifyGC.
10. Non-determinism in the real GC.
The GC verifier's algorithm relies on the real GC being deterministic. However,
there are a few places where this is not true:
a. Marking conservative roots on the mutator stacks.
By the time the verifier GC runs (in the GC End phase), the mutator stacks
will look completely different than what the real GC saw. To work around
this, if the verifier is enabled, then every conservative root captured by
the real GC will also be added to the verifier's mark stack.
When running verifyGC() in the End phase, the conservative root scans will be
treated as no-ops.
b. CodeBlock::shouldJettisonDueToOldAge() may return a different value.
This is possible because the codeBlock may be in mid compilation while the
real GC is in progress.
CodeBlock::shouldVisitStrongly() calls shouldJettisonDueToOldAge(), and may
see an old LLInt codeBlock whose timeToLive has expired. As a result,
shouldJettisonDueToOldAge() returns true and shouldVisitStrongly() will
return false for the real GC, leading to it not marking the codeBlock.
However, before the verifier GC gets to run, baseline compilation on the
codeBlock may finish. As a baseline codeBlock now, it gets a longer time
to live.
As a result, when the verifier GC runs, shouldJettisonDueToOldAge() will
return false, and shouldVisitStrongly() in turn returns true. This results
in the verifier GC marking the codeBlock (and its children) when the real
GC did not, which leads to a false error. This is not a real error because
if the real GC did not mark the code block, it will simply get jettisoned,
and can be reinstantiated when needed later. There's no GC bug here.
However, we do need to work around this to prevent the false error for the
GC verifier.
The work around is to introduce a CodeBlock::m_visitChildrenSkippedDueToOldAge
flag that records what the real GC decided in shouldJettisonDueToOldAge().
This allows the verifier GC to replay the same decision and get a consistent
result.
c. CodeBlock::propagateTransitions() will only do a best effort at visiting
cells in ICs, etc. If a cell is not already strongly marked by the time
CodeBlock::propagateTransitions() checks it, propagateTransitions() will
not mark other cells that are reachable from it.
Since the real GC does marking on concurrent threads, marking order is not
deterministic. CodeBlock::propagateTransitions() may or may not see a cell
as already marked by the time it runs.
The verifier GC may mark some of these cells in a different order than the
real GC. As a result, in the verifier GC, CodeBlock::propagateTransitions()
may see a cell as marked (and therefore, visit its children) when it did
not for the real GC.
To work around this, we currently add a SuppressGCVerifierScope to
CodeBlock::propagateTransitions() to pessimize the verifier, and assume that
propagateTransitions() will mark nothing.
SuppressGCVerifierScope is a blunt hammer that stops the verifier GC from
analyzing all cells potentially reachable via CodeBlock::propagateTransitions().
In the future, it may be possible to refine this and track which cells were
actually skipped over (like we did for shouldJettisonDueToOldAge()).
However, this decision tracking needs to be done in the real GC, and can be
very expensive in terms of performance. The shouldJettisonDueToOldAge()
case is rare, and as such lends itself to this more fine grain tracking
without hurting performance. The decisions made in CodeBlock::propagateTransitions()
are not as rare, and hence, it would hurt performance if we did fine grain
decision tracking there (at least or now).
11. Marking in the verifier GC.
The real GC tracks cell marks using a Bitmap in the MarkedBlocks. The verifier
GC keeps tracks of MarkedBlock cell marks using a Bitmap on the side, stashed
away in a HashMap.
To improve the verifier marking performance, we reserve a void* m_verifierMemo
pointer in the MarkedBlock, which the verifier will employ to cache its
MarkedBlockData for that MarkedBlock. This allows the verifier to get to its
side Bitmap without having to do a HashMap look up for every cell.
Size-wise, in the current 16K MarkBlocks, there is previously room for 1005.5
atoms after reserving space for the MarkedBlock::Footer. Since we can never
allocate half an atom anyway, that .5 atom gives us the 8 bytes we need for
the m_verifierMemo pointer, which we'll put in the MarkedBlock::Footer. With
this patch, each MarkedBlock will now have exactly 1005 atoms available for
allocation.
I ran JetStream2 and Speedometer2 locally on a MacBookAir10,1, MacBookPro16,1,
and a 12.9” 4th Gen iPad Pro. The benchmark results for these were all neutral.
The design of the GC verifier is such that it incurs almost no additional runtime
memory overhead if not in use. Code size does increase significantly because
there are now 2 variants of most of the methods that take a SlotVisitor.
When in use, the additional runtime memory is encapsulated in the
VerifierSlotVisitor, which is instantiated and destructed every GC cycle. Hence,
it can affect peak memory usage during GCs, but the cost is transient. It does
not persist past the GC End phase.
* API/JSAPIWrapperObject.h:
* API/JSAPIWrapperObject.mm:
(JSAPIWrapperObjectHandleOwner::isReachableFromOpaqueRoots):
(JSC::JSAPIWrapperObject::visitChildrenImpl):
(JSC::JSAPIWrapperObject::visitChildren): Deleted.
* API/JSCallbackObject.cpp:
* API/JSCallbackObject.h:
(JSC::JSCallbackObjectData::visitChildren):
(JSC::JSCallbackObjectData::JSPrivatePropertyMap::visitChildren):
(JSC::JSCallbackObject<Parent>::visitChildrenImpl):
* API/JSManagedValue.mm:
(JSManagedValueHandleOwner::isReachableFromOpaqueRoots):
* API/JSMarkingConstraintPrivate.cpp:
(JSC::isMarked):
(JSContextGroupAddMarkingConstraint):
* API/JSVirtualMachine.mm:
(scanExternalObjectGraph):
(scanExternalRememberedSet):
* API/JSVirtualMachineInternal.h:
* API/MarkedJSValueRefArray.cpp:
(JSC::MarkedJSValueRefArray::visitAggregate):
* API/MarkedJSValueRefArray.h:
* API/glib/JSAPIWrapperGlobalObject.cpp:
(JSC::JSAPIWrapperGlobalObject::visitChildren): Deleted.
* API/glib/JSAPIWrapperGlobalObject.h:
* API/glib/JSAPIWrapperObjectGLib.cpp:
(JSAPIWrapperObjectHandleOwner::isReachableFromOpaqueRoots):
(JSC::JSAPIWrapperObject::visitChildrenImpl):
(JSC::JSAPIWrapperObject::visitChildren): Deleted.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Scripts/wkbuiltins/builtins_generate_internals_wrapper_header.py:
(BuiltinsInternalsWrapperHeaderGenerator):
* Scripts/wkbuiltins/builtins_generate_internals_wrapper_implementation.py:
(BuiltinsInternalsWrapperImplementationGenerator.generate_visit_method):
* Scripts/wkbuiltins/builtins_templates.py:
* Sources.txt:
* bytecode/AccessCase.cpp:
(JSC::AccessCase::propagateTransitions const):
(JSC::AccessCase::visitAggregateImpl const):
(JSC::AccessCase::visitAggregate const): Deleted.
* bytecode/AccessCase.h:
* bytecode/ByValInfo.cpp:
(JSC::ByValInfo::visitAggregateImpl):
(JSC::ByValInfo::visitAggregate): Deleted.
* bytecode/ByValInfo.h:
* bytecode/CheckPrivateBrandStatus.cpp:
(JSC::CheckPrivateBrandStatus::visitAggregateImpl):
(JSC::CheckPrivateBrandStatus::markIfCheap):
(JSC::CheckPrivateBrandStatus::visitAggregate): Deleted.
* bytecode/CheckPrivateBrandStatus.h:
* bytecode/CheckPrivateBrandVariant.cpp:
(JSC::CheckPrivateBrandVariant::markIfCheap):
(JSC::CheckPrivateBrandVariant::visitAggregateImpl):
(JSC::CheckPrivateBrandVariant::visitAggregate): Deleted.
* bytecode/CheckPrivateBrandVariant.h:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::CodeBlock):
(JSC::CodeBlock::visitChildrenImpl):
(JSC::CodeBlock::visitChildren):
(JSC::CodeBlock::shouldVisitStrongly):
(JSC::CodeBlock::shouldJettisonDueToOldAge):
(JSC::shouldMarkTransition):
(JSC::CodeBlock::propagateTransitions):
(JSC::CodeBlock::determineLiveness):
(JSC::CodeBlock::finalizeUnconditionally):
(JSC::CodeBlock::visitOSRExitTargets):
(JSC::CodeBlock::stronglyVisitStrongReferences):
(JSC::CodeBlock::stronglyVisitWeakReferences):
* bytecode/CodeBlock.h:
* bytecode/DeleteByIdVariant.cpp:
(JSC::DeleteByIdVariant::visitAggregateImpl):
(JSC::DeleteByIdVariant::markIfCheap):
(JSC::DeleteByIdVariant::visitAggregate): Deleted.
* bytecode/DeleteByIdVariant.h:
* bytecode/DeleteByStatus.cpp:
(JSC::DeleteByStatus::visitAggregateImpl):
(JSC::DeleteByStatus::markIfCheap):
(JSC::DeleteByStatus::visitAggregate): Deleted.
* bytecode/DeleteByStatus.h:
* bytecode/DirectEvalCodeCache.cpp:
(JSC::DirectEvalCodeCache::visitAggregateImpl):
(JSC::DirectEvalCodeCache::visitAggregate): Deleted.
* bytecode/DirectEvalCodeCache.h:
* bytecode/ExecutableToCodeBlockEdge.cpp:
(JSC::ExecutableToCodeBlockEdge::visitChildrenImpl):
(JSC::ExecutableToCodeBlockEdge::visitOutputConstraintsImpl):
(JSC::ExecutableToCodeBlockEdge::runConstraint):
(JSC::ExecutableToCodeBlockEdge::visitChildren): Deleted.
(JSC::ExecutableToCodeBlockEdge::visitOutputConstraints): Deleted.
* bytecode/ExecutableToCodeBlockEdge.h:
* bytecode/GetByIdVariant.cpp:
(JSC::GetByIdVariant::visitAggregateImpl):
(JSC::GetByIdVariant::markIfCheap):
(JSC::GetByIdVariant::visitAggregate): Deleted.
* bytecode/GetByIdVariant.h:
* bytecode/GetByStatus.cpp:
(JSC::GetByStatus::visitAggregateImpl):
(JSC::GetByStatus::markIfCheap):
(JSC::GetByStatus::visitAggregate): Deleted.
* bytecode/GetByStatus.h:
* bytecode/InByIdStatus.cpp:
(JSC::InByIdStatus::markIfCheap):
* bytecode/InByIdStatus.h:
* bytecode/InByIdVariant.cpp:
(JSC::InByIdVariant::markIfCheap):
* bytecode/InByIdVariant.h:
* bytecode/InternalFunctionAllocationProfile.h:
(JSC::InternalFunctionAllocationProfile::visitAggregate):
* bytecode/ObjectAllocationProfile.h:
(JSC::ObjectAllocationProfileBase::visitAggregate):
(JSC::ObjectAllocationProfileWithPrototype::visitAggregate):
* bytecode/PolymorphicAccess.cpp:
(JSC::PolymorphicAccess::propagateTransitions const):
(JSC::PolymorphicAccess::visitAggregateImpl):
(JSC::PolymorphicAccess::visitAggregate): Deleted.
* bytecode/PolymorphicAccess.h:
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::markIfCheap):
* bytecode/PutByIdStatus.h:
* bytecode/PutByIdVariant.cpp:
(JSC::PutByIdVariant::markIfCheap):
* bytecode/PutByIdVariant.h:
* bytecode/RecordedStatuses.cpp:
(JSC::RecordedStatuses::visitAggregateImpl):
(JSC::RecordedStatuses::markIfCheap):
(JSC::RecordedStatuses::visitAggregate): Deleted.
* bytecode/RecordedStatuses.h:
* bytecode/SetPrivateBrandStatus.cpp:
(JSC::SetPrivateBrandStatus::visitAggregateImpl):
(JSC::SetPrivateBrandStatus::markIfCheap):
(JSC::SetPrivateBrandStatus::visitAggregate): Deleted.
* bytecode/SetPrivateBrandStatus.h:
* bytecode/SetPrivateBrandVariant.cpp:
(JSC::SetPrivateBrandVariant::markIfCheap):
(JSC::SetPrivateBrandVariant::visitAggregateImpl):
(JSC::SetPrivateBrandVariant::visitAggregate): Deleted.
* bytecode/SetPrivateBrandVariant.h:
* bytecode/StructureSet.cpp:
(JSC::StructureSet::markIfCheap const):
* bytecode/StructureSet.h:
* bytecode/StructureStubInfo.cpp:
(JSC::StructureStubInfo::visitAggregateImpl):
(JSC::StructureStubInfo::propagateTransitions):
(JSC::StructureStubInfo::visitAggregate): Deleted.
* bytecode/StructureStubInfo.h:
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::visitChildrenImpl):
(JSC::UnlinkedCodeBlock::visitChildren): Deleted.
* bytecode/UnlinkedCodeBlock.h:
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::visitChildrenImpl):
(JSC::UnlinkedFunctionExecutable::visitChildren): Deleted.
* bytecode/UnlinkedFunctionExecutable.h:
* debugger/DebuggerScope.cpp:
(JSC::DebuggerScope::visitChildrenImpl):
(JSC::DebuggerScope::visitChildren): Deleted.
* debugger/DebuggerScope.h:
* dfg/DFGDesiredTransitions.cpp:
(JSC::DFG::DesiredTransition::visitChildren):
(JSC::DFG::DesiredTransitions::visitChildren):
* dfg/DFGDesiredTransitions.h:
* dfg/DFGDesiredWeakReferences.cpp:
(JSC::DFG::DesiredWeakReferences::visitChildren):
* dfg/DFGDesiredWeakReferences.h:
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::visitChildrenImpl):
(JSC::DFG::Graph::visitChildren):
* dfg/DFGGraph.h:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::checkLivenessAndVisitChildren):
(JSC::DFG::Plan::isKnownToBeLiveDuringGC):
(JSC::DFG::Plan::isKnownToBeLiveAfterGC):
* dfg/DFGPlan.h:
* dfg/DFGPlanInlines.h:
(JSC::DFG::Plan::iterateCodeBlocksForGC):
* dfg/DFGSafepoint.cpp:
(JSC::DFG::Safepoint::checkLivenessAndVisitChildren):
(JSC::DFG::Safepoint::isKnownToBeLiveDuringGC):
(JSC::DFG::Safepoint::isKnownToBeLiveAfterGC):
* dfg/DFGSafepoint.h:
* dfg/DFGScannable.h:
* dfg/DFGWorklist.cpp:
(JSC::DFG::Worklist::visitWeakReferences):
(JSC::DFG::Worklist::removeDeadPlans):
* dfg/DFGWorklist.h:
* dfg/DFGWorklistInlines.h:
(JSC::DFG::iterateCodeBlocksForGC):
(JSC::DFG::Worklist::iterateCodeBlocksForGC):
* heap/AbstractSlotVisitor.h: Added.
(JSC::AbstractSlotVisitor::Context::cell const):
(JSC::AbstractSlotVisitor::SuppressGCVerifierScope::SuppressGCVerifierScope):
(JSC::AbstractSlotVisitor::SuppressGCVerifierScope::~SuppressGCVerifierScope):
(JSC::AbstractSlotVisitor::DefaultMarkingViolationAssertionScope::DefaultMarkingViolationAssertionScope):
(JSC::AbstractSlotVisitor::collectorMarkStack):
(JSC::AbstractSlotVisitor::mutatorMarkStack):
(JSC::AbstractSlotVisitor::collectorMarkStack const):
(JSC::AbstractSlotVisitor::mutatorMarkStack const):
(JSC::AbstractSlotVisitor::isEmpty):
(JSC::AbstractSlotVisitor::setIgnoreNewOpaqueRoots):
(JSC::AbstractSlotVisitor::visitCount const):
(JSC::AbstractSlotVisitor::addToVisitCount):
(JSC::AbstractSlotVisitor::rootMarkReason const):
(JSC::AbstractSlotVisitor::setRootMarkReason):
(JSC::AbstractSlotVisitor::didRace):
(JSC::AbstractSlotVisitor::codeName const):
(JSC::SetRootMarkReasonScope::SetRootMarkReasonScope):
(JSC::SetRootMarkReasonScope::~SetRootMarkReasonScope):
* heap/AbstractSlotVisitorInlines.h: Added.
(JSC::AbstractSlotVisitor::Context::Context):
(JSC::AbstractSlotVisitor::Context::~Context):
(JSC::AbstractSlotVisitor::AbstractSlotVisitor):
(JSC::AbstractSlotVisitor::heap const):
(JSC::AbstractSlotVisitor::vm):
(JSC::AbstractSlotVisitor::vm const):
(JSC::AbstractSlotVisitor::addOpaqueRoot):
(JSC::AbstractSlotVisitor::containsOpaqueRoot const):
(JSC::AbstractSlotVisitor::append):
(JSC::AbstractSlotVisitor::appendHidden):
(JSC::AbstractSlotVisitor::appendHiddenUnbarriered):
(JSC::AbstractSlotVisitor::appendValues):
(JSC::AbstractSlotVisitor::appendValuesHidden):
(JSC::AbstractSlotVisitor::appendUnbarriered):
(JSC::AbstractSlotVisitor::parentCell const):
(JSC::AbstractSlotVisitor::reset):
* heap/HandleSet.cpp:
(JSC::HandleSet::visitStrongHandles):
* heap/HandleSet.h:
* heap/Heap.cpp:
(JSC::Heap::iterateExecutingAndCompilingCodeBlocks):
(JSC::Heap::iterateExecutingAndCompilingCodeBlocksWithoutHoldingLocks):
(JSC::Heap::runEndPhase):
(JSC::Heap::willStartCollection):
(JSC::scanExternalRememberedSet):
(JSC::serviceSamplingProfiler):
(JSC::Heap::addCoreConstraints):
(JSC::Heap::verifyGC):
(JSC::Heap::isAnalyzingHeap const): Deleted.
* heap/Heap.h:
(JSC::Heap::isMarkingForGCVerifier const):
(JSC::Heap::numOpaqueRoots const): Deleted.
* heap/HeapInlines.h:
(JSC::Heap::isMarked):
* heap/HeapProfiler.cpp:
(JSC::HeapProfiler::setActiveHeapAnalyzer):
* heap/IsoCellSet.h:
* heap/IsoCellSetInlines.h:
(JSC::IsoCellSet::forEachMarkedCellInParallel):
* heap/JITStubRoutineSet.cpp:
(JSC::JITStubRoutineSet::traceMarkedStubRoutines):
* heap/JITStubRoutineSet.h:
(JSC::JITStubRoutineSet::traceMarkedStubRoutines):
* heap/MarkStackMergingConstraint.cpp:
(JSC::MarkStackMergingConstraint::prepareToExecuteImpl):
(JSC::MarkStackMergingConstraint::executeImplImpl):
(JSC::MarkStackMergingConstraint::executeImpl):
* heap/MarkStackMergingConstraint.h:
* heap/MarkedBlock.h:
(JSC::MarkedBlock::Handle::atomAt const):
(JSC::MarkedBlock::setVerifierMemo):
(JSC::MarkedBlock::verifierMemo const):
* heap/MarkedSpace.cpp:
(JSC::MarkedSpace::visitWeakSets):
* heap/MarkedSpace.h:
* heap/MarkingConstraint.cpp:
(JSC::MarkingConstraint::execute):
(JSC::MarkingConstraint::executeSynchronously):
(JSC::MarkingConstraint::prepareToExecute):
(JSC::MarkingConstraint::doParallelWork):
(JSC::MarkingConstraint::prepareToExecuteImpl):
* heap/MarkingConstraint.h:
* heap/MarkingConstraintExecutorPair.h: Added.
(JSC::MarkingConstraintExecutorPair::MarkingConstraintExecutorPair):
(JSC::MarkingConstraintExecutorPair::execute):
* heap/MarkingConstraintSet.cpp:
(JSC::MarkingConstraintSet::add):
(JSC::MarkingConstraintSet::executeAllSynchronously):
(JSC::MarkingConstraintSet::executeAll): Deleted.
* heap/MarkingConstraintSet.h:
(JSC::MarkingConstraintSet::add):
* heap/MarkingConstraintSolver.cpp:
* heap/MarkingConstraintSolver.h:
* heap/SimpleMarkingConstraint.cpp:
(JSC::SimpleMarkingConstraint::SimpleMarkingConstraint):
(JSC::SimpleMarkingConstraint::executeImplImpl):
(JSC::SimpleMarkingConstraint::executeImpl):
* heap/SimpleMarkingConstraint.h:
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::SlotVisitor):
(JSC::SlotVisitor::reset):
(JSC::SlotVisitor::appendSlow):
(JSC::SlotVisitor::addParallelConstraintTask):
* heap/SlotVisitor.h:
(JSC::SlotVisitor::collectorMarkStack): Deleted.
(JSC::SlotVisitor::mutatorMarkStack): Deleted.
(JSC::SlotVisitor::collectorMarkStack const): Deleted.
(JSC::SlotVisitor::mutatorMarkStack const): Deleted.
(JSC::SlotVisitor::isEmpty): Deleted.
(JSC::SlotVisitor::isFirstVisit const): Deleted.
(JSC::SlotVisitor::bytesVisited const): Deleted.
(JSC::SlotVisitor::visitCount const): Deleted.
(JSC::SlotVisitor::addToVisitCount): Deleted.
(JSC::SlotVisitor::isAnalyzingHeap const): Deleted.
(JSC::SlotVisitor::heapAnalyzer const): Deleted.
(JSC::SlotVisitor::rootMarkReason const): Deleted.
(JSC::SlotVisitor::setRootMarkReason): Deleted.
(JSC::SlotVisitor::markingVersion const): Deleted.
(JSC::SlotVisitor::mutatorIsStopped const): Deleted.
(JSC::SlotVisitor::rightToRun): Deleted.
(JSC::SlotVisitor::didRace): Deleted.
(JSC::SlotVisitor::setIgnoreNewOpaqueRoots): Deleted.
(JSC::SlotVisitor::codeName const): Deleted.
(JSC::SetRootMarkReasonScope::SetRootMarkReasonScope): Deleted.
(JSC::SetRootMarkReasonScope::~SetRootMarkReasonScope): Deleted.
* heap/SlotVisitorInlines.h:
(JSC::SlotVisitor::isMarked const):
(JSC::SlotVisitor::addOpaqueRoot): Deleted.
(JSC::SlotVisitor::containsOpaqueRoot const): Deleted.
(JSC::SlotVisitor::heap const): Deleted.
(JSC::SlotVisitor::vm): Deleted.
(JSC::SlotVisitor::vm const): Deleted.
* heap/SlotVisitorMacros.h: Added.
* heap/Subspace.h:
* heap/SubspaceInlines.h:
(JSC::Subspace::forEachMarkedCellInParallel):
* heap/VerifierSlotVisitor.cpp: Added.
(JSC::MarkerData::MarkerData):
(JSC::VerifierSlotVisitor::MarkedBlockData::MarkedBlockData):
(JSC::VerifierSlotVisitor::MarkedBlockData::addMarkerData):
(JSC::VerifierSlotVisitor::MarkedBlockData::markerData const):
(JSC::VerifierSlotVisitor::PreciseAllocationData::PreciseAllocationData):
(JSC::VerifierSlotVisitor::PreciseAllocationData::markerData const):
(JSC::VerifierSlotVisitor::PreciseAllocationData::addMarkerData):
(JSC::VerifierSlotVisitor::VerifierSlotVisitor):
(JSC::VerifierSlotVisitor::~VerifierSlotVisitor):
(JSC::VerifierSlotVisitor::addParallelConstraintTask):
(JSC::VerifierSlotVisitor::executeConstraintTasks):
(JSC::VerifierSlotVisitor::append):
(JSC::VerifierSlotVisitor::appendToMarkStack):
(JSC::VerifierSlotVisitor::appendUnbarriered):
(JSC::VerifierSlotVisitor::appendHiddenUnbarriered):
(JSC::VerifierSlotVisitor::drain):
(JSC::VerifierSlotVisitor::dumpMarkerData):
(JSC::VerifierSlotVisitor::isFirstVisit const):
(JSC::VerifierSlotVisitor::isMarked const):
(JSC::VerifierSlotVisitor::markAuxiliary):
(JSC::VerifierSlotVisitor::mutatorIsStopped const):
(JSC::VerifierSlotVisitor::testAndSetMarked):
(JSC::VerifierSlotVisitor::setMarkedAndAppendToMarkStack):
(JSC::VerifierSlotVisitor::visitAsConstraint):
(JSC::VerifierSlotVisitor::visitChildren):
* heap/VerifierSlotVisitor.h: Added.
(JSC::VerifierSlotVisitor::MarkedBlockData::block const):
(JSC::VerifierSlotVisitor::MarkedBlockData::atoms const):
(JSC::VerifierSlotVisitor::MarkedBlockData::isMarked):
(JSC::VerifierSlotVisitor::MarkedBlockData::testAndSetMarked):
(JSC::VerifierSlotVisitor::PreciseAllocationData::allocation const):
(JSC::VerifierSlotVisitor::appendSlow):
* heap/VerifierSlotVisitorInlines.h: Added.
(JSC::VerifierSlotVisitor::forEachLiveCell):
(JSC::VerifierSlotVisitor::forEachLivePreciseAllocation):
(JSC::VerifierSlotVisitor::forEachLiveMarkedBlockCell):
* heap/VisitCounter.h:
(JSC::VisitCounter::VisitCounter):
(JSC::VisitCounter::visitor const):
* heap/WeakBlock.cpp:
(JSC::WeakBlock::specializedVisit):
(JSC::WeakBlock::visitImpl):
(JSC::WeakBlock::visit):
* heap/WeakBlock.h:
* heap/WeakHandleOwner.cpp:
(JSC::WeakHandleOwner::isReachableFromOpaqueRoots):
* heap/WeakHandleOwner.h:
* heap/WeakSet.cpp:
* heap/WeakSet.h:
(JSC::WeakSet::visit):
* interpreter/ShadowChicken.cpp:
(JSC::ShadowChicken::visitChildren):
* interpreter/ShadowChicken.h:
* jit/GCAwareJITStubRoutine.cpp:
(JSC::MarkingGCAwareJITStubRoutine::markRequiredObjectsInternalImpl):
(JSC::MarkingGCAwareJITStubRoutine::markRequiredObjectsInternal):
(JSC::GCAwareJITStubRoutine::markRequiredObjectsInternal): Deleted.
* jit/GCAwareJITStubRoutine.h:
(JSC::GCAwareJITStubRoutine::markRequiredObjects):
(JSC::GCAwareJITStubRoutine::markRequiredObjectsInternal):
* jit/JITWorklist.cpp:
* jit/PolymorphicCallStubRoutine.cpp:
(JSC::PolymorphicCallStubRoutine::markRequiredObjectsInternalImpl):
(JSC::PolymorphicCallStubRoutine::markRequiredObjectsInternal):
* jit/PolymorphicCallStubRoutine.h:
* runtime/AbstractModuleRecord.cpp:
(JSC::AbstractModuleRecord::visitChildrenImpl):
(JSC::AbstractModuleRecord::visitChildren): Deleted.
* runtime/AbstractModuleRecord.h:
* runtime/ArgList.cpp:
(JSC::MarkedArgumentBuffer::markLists):
* runtime/ArgList.h:
* runtime/CacheableIdentifier.h:
* runtime/CacheableIdentifierInlines.h:
(JSC::CacheableIdentifier::visitAggregate const):
* runtime/ClassInfo.h:
(JSC::MethodTable::visitChildren const):
(JSC::MethodTable::visitOutputConstraints const):
* runtime/ClonedArguments.cpp:
(JSC::ClonedArguments::visitChildrenImpl):
(JSC::ClonedArguments::visitChildren): Deleted.
* runtime/ClonedArguments.h:
* runtime/DirectArguments.cpp:
(JSC::DirectArguments::visitChildrenImpl):
(JSC::DirectArguments::visitChildren): Deleted.
* runtime/DirectArguments.h:
* runtime/EvalExecutable.cpp:
(JSC::EvalExecutable::visitChildrenImpl):
(JSC::EvalExecutable::visitChildren): Deleted.
* runtime/EvalExecutable.h:
* runtime/Exception.cpp:
(JSC::Exception::visitChildrenImpl):
(JSC::Exception::visitChildren): Deleted.
* runtime/Exception.h:
* runtime/FunctionExecutable.cpp:
(JSC::FunctionExecutable::visitChildrenImpl):
(JSC::FunctionExecutable::visitChildren): Deleted.
* runtime/FunctionExecutable.h:
* runtime/FunctionRareData.cpp:
(JSC::FunctionRareData::visitChildrenImpl):
(JSC::FunctionRareData::visitChildren): Deleted.
* runtime/FunctionRareData.h:
* runtime/GenericArguments.h:
* runtime/GenericArgumentsInlines.h:
(JSC::GenericArguments<Type>::visitChildrenImpl):
(JSC::GenericArguments<Type>::visitChildren): Deleted.
* runtime/GetterSetter.cpp:
(JSC::GetterSetter::visitChildrenImpl):
(JSC::GetterSetter::visitChildren): Deleted.
* runtime/GetterSetter.h:
* runtime/HashMapImpl.cpp:
(JSC::HashMapBucket<Data>::visitChildrenImpl):
(JSC::HashMapImpl<HashMapBucket>::visitChildrenImpl):
(JSC::HashMapBucket<Data>::visitChildren): Deleted.
(JSC::HashMapImpl<HashMapBucket>::visitChildren): Deleted.
* runtime/HashMapImpl.h:
* runtime/InternalFunction.cpp:
(JSC::InternalFunction::visitChildrenImpl):
(JSC::InternalFunction::visitChildren): Deleted.
* runtime/InternalFunction.h:
* runtime/IntlCollator.cpp:
(JSC::IntlCollator::visitChildrenImpl):
(JSC::IntlCollator::visitChildren): Deleted.
* runtime/IntlCollator.h:
* runtime/IntlDateTimeFormat.cpp:
(JSC::IntlDateTimeFormat::visitChildrenImpl):
(JSC::IntlDateTimeFormat::visitChildren): Deleted.
* runtime/IntlDateTimeFormat.h:
* runtime/IntlLocale.cpp:
(JSC::IntlLocale::visitChildrenImpl):
(JSC::IntlLocale::visitChildren): Deleted.
* runtime/IntlLocale.h:
* runtime/IntlNumberFormat.cpp:
(JSC::IntlNumberFormat::visitChildrenImpl):
(JSC::IntlNumberFormat::visitChildren): Deleted.
* runtime/IntlNumberFormat.h:
* runtime/IntlPluralRules.cpp:
(JSC::IntlPluralRules::visitChildrenImpl):
(JSC::IntlPluralRules::visitChildren): Deleted.
* runtime/IntlPluralRules.h:
* runtime/IntlRelativeTimeFormat.cpp:
(JSC::IntlRelativeTimeFormat::visitChildrenImpl):
(JSC::IntlRelativeTimeFormat::visitChildren): Deleted.
* runtime/IntlRelativeTimeFormat.h:
* runtime/IntlSegmentIterator.cpp:
(JSC::IntlSegmentIterator::visitChildrenImpl):
(JSC::IntlSegmentIterator::visitChildren): Deleted.
* runtime/IntlSegmentIterator.h:
* runtime/IntlSegments.cpp:
(JSC::IntlSegments::visitChildrenImpl):
(JSC::IntlSegments::visitChildren): Deleted.
* runtime/IntlSegments.h:
* runtime/JSArrayBufferView.cpp:
(JSC::JSArrayBufferView::visitChildrenImpl):
(JSC::JSArrayBufferView::visitChildren): Deleted.
* runtime/JSArrayBufferView.h:
* runtime/JSArrayIterator.cpp:
(JSC::JSArrayIterator::visitChildrenImpl):
(JSC::JSArrayIterator::visitChildren): Deleted.
* runtime/JSArrayIterator.h:
* runtime/JSAsyncGenerator.cpp:
(JSC::JSAsyncGenerator::visitChildrenImpl):
(JSC::JSAsyncGenerator::visitChildren): Deleted.
* runtime/JSAsyncGenerator.h:
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::visitChildrenImpl):
(JSC::JSBigInt::visitChildren): Deleted.
* runtime/JSBigInt.h:
* runtime/JSBoundFunction.cpp:
(JSC::JSBoundFunction::visitChildrenImpl):
(JSC::JSBoundFunction::visitChildren): Deleted.
* runtime/JSBoundFunction.h:
* runtime/JSCallee.cpp:
(JSC::JSCallee::visitChildrenImpl):
(JSC::JSCallee::visitChildren): Deleted.
* runtime/JSCallee.h:
* runtime/JSCell.h:
* runtime/JSCellInlines.h:
(JSC::JSCell::visitChildrenImpl):
(JSC::JSCell::visitOutputConstraintsImpl):
(JSC::JSCell::visitChildren): Deleted.
(JSC::JSCell::visitOutputConstraints): Deleted.
* runtime/JSFinalizationRegistry.cpp:
(JSC::JSFinalizationRegistry::visitChildrenImpl):
(JSC::JSFinalizationRegistry::visitChildren): Deleted.
* runtime/JSFinalizationRegistry.h:
* runtime/JSFunction.cpp:
(JSC::JSFunction::visitChildrenImpl):
(JSC::JSFunction::visitChildren): Deleted.
* runtime/JSFunction.h:
* runtime/JSGenerator.cpp:
(JSC::JSGenerator::visitChildrenImpl):
(JSC::JSGenerator::visitChildren): Deleted.
* runtime/JSGenerator.h:
* runtime/JSGenericTypedArrayView.h:
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::visitChildrenImpl):
(JSC::JSGenericTypedArrayView<Adaptor>::visitChildren): Deleted.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::visitChildrenImpl):
(JSC::JSGlobalObject::visitChildren): Deleted.
* runtime/JSGlobalObject.h:
* runtime/JSImmutableButterfly.cpp:
(JSC::JSImmutableButterfly::visitChildrenImpl):
(JSC::JSImmutableButterfly::visitChildren): Deleted.
* runtime/JSImmutableButterfly.h:
* runtime/JSInternalFieldObjectImpl.h:
* runtime/JSInternalFieldObjectImplInlines.h:
(JSC::JSInternalFieldObjectImpl<passedNumberOfInternalFields>::visitChildrenImpl):
(JSC::JSInternalFieldObjectImpl<passedNumberOfInternalFields>::visitChildren): Deleted.
* runtime/JSLexicalEnvironment.cpp:
(JSC::JSLexicalEnvironment::visitChildrenImpl):
(JSC::JSLexicalEnvironment::visitChildren): Deleted.
* runtime/JSLexicalEnvironment.h:
* runtime/JSMapIterator.cpp:
(JSC::JSMapIterator::visitChildrenImpl):
(JSC::JSMapIterator::visitChildren): Deleted.
* runtime/JSMapIterator.h:
* runtime/JSModuleEnvironment.cpp:
(JSC::JSModuleEnvironment::visitChildrenImpl):
(JSC::JSModuleEnvironment::visitChildren): Deleted.
* runtime/JSModuleEnvironment.h:
* runtime/JSModuleNamespaceObject.cpp:
(JSC::JSModuleNamespaceObject::visitChildrenImpl):
(JSC::JSModuleNamespaceObject::visitChildren): Deleted.
* runtime/JSModuleNamespaceObject.h:
* runtime/JSModuleRecord.cpp:
(JSC::JSModuleRecord::visitChildrenImpl):
(JSC::JSModuleRecord::visitChildren): Deleted.
* runtime/JSModuleRecord.h:
* runtime/JSNativeStdFunction.cpp:
(JSC::JSNativeStdFunction::visitChildrenImpl):
(JSC::JSNativeStdFunction::visitChildren): Deleted.
* runtime/JSNativeStdFunction.h:
* runtime/JSObject.cpp:
(JSC::JSObject::markAuxiliaryAndVisitOutOfLineProperties):
(JSC::JSObject::visitButterfly):
(JSC::JSObject::visitButterflyImpl):
(JSC::JSObject::visitChildrenImpl):
(JSC::JSFinalObject::visitChildrenImpl):
(JSC::JSObject::visitChildren): Deleted.
(JSC::JSFinalObject::visitChildren): Deleted.
* runtime/JSObject.h:
* runtime/JSPromise.cpp:
(JSC::JSPromise::visitChildrenImpl):
(JSC::JSPromise::visitChildren): Deleted.
* runtime/JSPromise.h:
* runtime/JSPropertyNameEnumerator.cpp:
(JSC::JSPropertyNameEnumerator::visitChildrenImpl):
(JSC::JSPropertyNameEnumerator::visitChildren): Deleted.
* runtime/JSPropertyNameEnumerator.h:
* runtime/JSProxy.cpp:
(JSC::JSProxy::visitChildrenImpl):
(JSC::JSProxy::visitChildren): Deleted.
* runtime/JSProxy.h:
* runtime/JSScope.cpp:
(JSC::JSScope::visitChildrenImpl):
(JSC::JSScope::visitChildren): Deleted.
* runtime/JSScope.h:
* runtime/JSSegmentedVariableObject.cpp:
(JSC::JSSegmentedVariableObject::visitChildrenImpl):
(JSC::JSSegmentedVariableObject::visitChildren): Deleted.
* runtime/JSSegmentedVariableObject.h:
* runtime/JSSetIterator.cpp:
(JSC::JSSetIterator::visitChildrenImpl):
(JSC::JSSetIterator::visitChildren): Deleted.
* runtime/JSSetIterator.h:
* runtime/JSString.cpp:
(JSC::JSString::visitChildrenImpl):
(JSC::JSString::visitChildren): Deleted.
* runtime/JSString.h:
* runtime/JSStringIterator.cpp:
(JSC::JSStringIterator::visitChildrenImpl):
(JSC::JSStringIterator::visitChildren): Deleted.
* runtime/JSStringIterator.h:
* runtime/JSSymbolTableObject.cpp:
(JSC::JSSymbolTableObject::visitChildrenImpl):
(JSC::JSSymbolTableObject::visitChildren): Deleted.
* runtime/JSSymbolTableObject.h:
* runtime/JSWeakObjectRef.cpp:
(JSC::JSWeakObjectRef::visitChildrenImpl):
(JSC::JSWeakObjectRef::visitChildren): Deleted.
* runtime/JSWeakObjectRef.h:
* runtime/JSWithScope.cpp:
(JSC::JSWithScope::visitChildrenImpl):
(JSC::JSWithScope::visitChildren): Deleted.
* runtime/JSWithScope.h:
* runtime/JSWrapperObject.cpp:
(JSC::JSWrapperObject::visitChildrenImpl):
(JSC::JSWrapperObject::visitChildren): Deleted.
* runtime/JSWrapperObject.h:
* runtime/LazyClassStructure.cpp:
(JSC::LazyClassStructure::visit):
* runtime/LazyClassStructure.h:
* runtime/LazyProperty.h:
* runtime/LazyPropertyInlines.h:
(JSC::ElementType>::visit):
* runtime/ModuleProgramExecutable.cpp:
(JSC::ModuleProgramExecutable::visitChildrenImpl):
(JSC::ModuleProgramExecutable::visitChildren): Deleted.
* runtime/ModuleProgramExecutable.h:
* runtime/Options.cpp:
(JSC::Options::recomputeDependentOptions):
* runtime/OptionsList.h:
* runtime/ProgramExecutable.cpp:
(JSC::ProgramExecutable::visitChildrenImpl):
(JSC::ProgramExecutable::visitChildren): Deleted.
* runtime/ProgramExecutable.h:
* runtime/PropertyMapHashTable.h:
* runtime/PropertyTable.cpp:
(JSC::PropertyTable::visitChildrenImpl):
(JSC::PropertyTable::visitChildren): Deleted.
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::visitChildrenImpl):
(JSC::ProxyObject::visitChildren): Deleted.
* runtime/ProxyObject.h:
* runtime/ProxyRevoke.cpp:
(JSC::ProxyRevoke::visitChildrenImpl):
(JSC::ProxyRevoke::visitChildren): Deleted.
* runtime/ProxyRevoke.h:
* runtime/RegExpCachedResult.cpp:
(JSC::RegExpCachedResult::visitAggregateImpl):
(JSC::RegExpCachedResult::visitAggregate): Deleted.
* runtime/RegExpCachedResult.h:
* runtime/RegExpGlobalData.cpp:
(JSC::RegExpGlobalData::visitAggregateImpl):
(JSC::RegExpGlobalData::visitAggregate): Deleted.
* runtime/RegExpGlobalData.h:
* runtime/RegExpObject.cpp:
(JSC::RegExpObject::visitChildrenImpl):
(JSC::RegExpObject::visitChildren): Deleted.
* runtime/RegExpObject.h:
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::visit):
* runtime/SamplingProfiler.h:
* runtime/ScopedArguments.cpp:
(JSC::ScopedArguments::visitChildrenImpl):
(JSC::ScopedArguments::visitChildren): Deleted.
* runtime/ScopedArguments.h:
* runtime/SimpleTypedArrayController.cpp:
(JSC::SimpleTypedArrayController::JSArrayBufferOwner::isReachableFromOpaqueRoots):
* runtime/SimpleTypedArrayController.h:
* runtime/SmallStrings.cpp:
(JSC::SmallStrings::visitStrongReferences):
* runtime/SmallStrings.h:
* runtime/SparseArrayValueMap.cpp:
(JSC::SparseArrayValueMap::visitChildrenImpl):
(JSC::SparseArrayValueMap::visitChildren): Deleted.
* runtime/SparseArrayValueMap.h:
* runtime/StackFrame.cpp:
(JSC::StackFrame::visitChildren): Deleted.
* runtime/StackFrame.h:
(JSC::StackFrame::visitChildren):
* runtime/Structure.cpp:
(JSC::Structure::visitChildrenImpl):
(JSC::Structure::isCheapDuringGC):
(JSC::Structure::markIfCheap):
(JSC::Structure::visitChildren): Deleted.
* runtime/Structure.h:
* runtime/StructureChain.cpp:
(JSC::StructureChain::visitChildrenImpl):
(JSC::StructureChain::visitChildren): Deleted.
* runtime/StructureChain.h:
* runtime/StructureRareData.cpp:
(JSC::StructureRareData::visitChildrenImpl):
(JSC::StructureRareData::visitChildren): Deleted.
* runtime/StructureRareData.h:
* runtime/SymbolTable.cpp:
(JSC::SymbolTable::visitChildrenImpl):
(JSC::SymbolTable::visitChildren): Deleted.
* runtime/SymbolTable.h:
* runtime/TypeProfilerLog.cpp:
(JSC::TypeProfilerLog::visit):
* runtime/TypeProfilerLog.h:
* runtime/VM.h:
(JSC::VM::isAnalyzingHeap const):
(JSC::VM::activeHeapAnalyzer const):
(JSC::VM::setActiveHeapAnalyzer):
* runtime/WeakMapImpl.cpp:
(JSC::WeakMapImpl<WeakMapBucket>::visitChildrenImpl):
(JSC::WeakMapImpl<WeakMapBucket<WeakMapBucketDataKey>>::visitOutputConstraints):
(JSC::WeakMapImpl<BucketType>::visitOutputConstraints):
(JSC::WeakMapImpl<WeakMapBucket>::visitChildren): Deleted.
(JSC::WeakMapImpl<WeakMapBucket<WeakMapBucketDataKeyValue>>::visitOutputConstraints): Deleted.
* runtime/WeakMapImpl.h:
(JSC::WeakMapBucket::visitAggregate):
* tools/JSDollarVM.cpp:
(JSC::JSDollarVM::visitChildrenImpl):
(JSC::JSDollarVM::visitChildren): Deleted.
* tools/JSDollarVM.h:
* wasm/WasmGlobal.cpp:
(JSC::Wasm::Global::visitAggregateImpl):
(JSC::Wasm::Global::visitAggregate): Deleted.
* wasm/WasmGlobal.h:
* wasm/WasmTable.cpp:
(JSC::Wasm::Table::visitAggregateImpl):
(JSC::Wasm::Table::visitAggregate): Deleted.
* wasm/WasmTable.h:
* wasm/js/JSToWasmICCallee.cpp:
(JSC::JSToWasmICCallee::visitChildrenImpl):
(JSC::JSToWasmICCallee::visitChildren): Deleted.
* wasm/js/JSToWasmICCallee.h:
* wasm/js/JSWebAssemblyCodeBlock.cpp:
(JSC::JSWebAssemblyCodeBlock::visitChildrenImpl):
(JSC::JSWebAssemblyCodeBlock::visitChildren): Deleted.
* wasm/js/JSWebAssemblyCodeBlock.h:
* wasm/js/JSWebAssemblyGlobal.cpp:
(JSC::JSWebAssemblyGlobal::visitChildrenImpl):
(JSC::JSWebAssemblyGlobal::visitChildren): Deleted.
* wasm/js/JSWebAssemblyGlobal.h:
* wasm/js/JSWebAssemblyInstance.cpp:
(JSC::JSWebAssemblyInstance::visitChildrenImpl):
(JSC::JSWebAssemblyInstance::visitChildren): Deleted.
* wasm/js/JSWebAssemblyInstance.h:
* wasm/js/JSWebAssemblyMemory.cpp:
(JSC::JSWebAssemblyMemory::visitChildrenImpl):
(JSC::JSWebAssemblyMemory::visitChildren): Deleted.
* wasm/js/JSWebAssemblyMemory.h:
* wasm/js/JSWebAssemblyModule.cpp:
(JSC::JSWebAssemblyModule::visitChildrenImpl):
(JSC::JSWebAssemblyModule::visitChildren): Deleted.
* wasm/js/JSWebAssemblyModule.h:
* wasm/js/JSWebAssemblyTable.cpp:
(JSC::JSWebAssemblyTable::visitChildrenImpl):
(JSC::JSWebAssemblyTable::visitChildren): Deleted.
* wasm/js/JSWebAssemblyTable.h:
* wasm/js/WebAssemblyFunction.cpp:
(JSC::WebAssemblyFunction::visitChildrenImpl):
(JSC::WebAssemblyFunction::visitChildren): Deleted.
* wasm/js/WebAssemblyFunction.h:
* wasm/js/WebAssemblyFunctionBase.cpp:
(JSC::WebAssemblyFunctionBase::visitChildrenImpl):
(JSC::WebAssemblyFunctionBase::visitChildren): Deleted.
* wasm/js/WebAssemblyFunctionBase.h:
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::visitChildrenImpl):
(JSC::WebAssemblyModuleRecord::visitChildren): Deleted.
* wasm/js/WebAssemblyModuleRecord.h:
* wasm/js/WebAssemblyWrapperFunction.cpp:
(JSC::WebAssemblyWrapperFunction::visitChildrenImpl):
(JSC::WebAssemblyWrapperFunction::visitChildren): Deleted.
* wasm/js/WebAssemblyWrapperFunction.h:
2021-02-19 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Simplify excludedSet handling in object rest expression
https://bugs.webkit.org/show_bug.cgi?id=221668
Reviewed by Alexey Shvayka.
This patch simplifies Object rest/spread by avoiding use of JSSet.
Instead, we store IdentifierSet into UnlinkedCodeBlock's vector and
access this directly through JS constant number.
And for additional properties, we collect it during destructuring,
and pass it to @copyDataProperties as an argument so that we do not
need to call Set#add in JS side.
We also check (isNumber() || isString) conditions for properties to
avoid calling ToPropertyKey for constant case. This is OK since we
will call ToPropertyKey inside @copyDataProperties, and this is
side-effect free if the input is number or string.
This patch shows 2x improvement in microbenchmarking.
ToT Patched
object-rest-computed-destructuring 62.9960+-6.5072 ^ 30.2157+-1.1420 ^ definitely 2.0849x faster
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::setConstantIdentifierSetRegisters): Deleted.
* bytecode/CodeBlock.h:
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::constantIdentifierSets):
* bytecode/UnlinkedCodeBlockGenerator.h:
(JSC::UnlinkedCodeBlockGenerator::constantIdentifierSets):
(JSC::UnlinkedCodeBlockGenerator::addSetConstant):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitLoad):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::ObjectPatternNode::bindValue const):
(JSC::ObjectSpreadExpressionNode::emitBytecode):
* runtime/CachedTypes.cpp:
(JSC::CachedConstantIdentifierSetEntry::encode): Deleted.
(JSC::CachedConstantIdentifierSetEntry::decode const): Deleted.
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::getCallerCodeBlock):
(JSC::JSC_DEFINE_HOST_FUNCTION):
2021-02-18 Chris Dumez <cdumez@apple.com>
Reduce explicit usage of [objC autorelease] in WebKit
https://bugs.webkit.org/show_bug.cgi?id=221932
<rdar://problem/74410900>
Reviewed by Darin Adler.
Follow-up to r272936 in order to address post-landing review comments.
* API/JSContext.mm:
(-[JSContext init]):
* API/JSWrapperMap.mm:
(-[JSWrapperMap classInfoForClass:]):
2021-02-18 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Enable private methods
https://bugs.webkit.org/show_bug.cgi?id=222137
Reviewed by Tadeu Zagallo.
* runtime/OptionsList.h:
2021-02-18 Caio Lima <ticaiolima@gmail.com>
[JSC] Implement private static method
https://bugs.webkit.org/show_bug.cgi?id=219181
Reviewed by Yusuke Suzuki.
This patch is implementing static private methods and accessors
proposal based on https://github.com/tc39/proposal-static-class-features.
This implementation diverge a bit from private methods&accessors on the
brand check, because we are using a simpler way to perform static
brand checks. Since only the class constructor is allowed to access
its private methods and accessors, we save it on `@privateClassBrand`
on class lexical scope and compare it with the receiver of the static
private method (and accessors) using `===` operation.
While this genenrates more bytecodes than `check_private_brand`, we
don't need to perform a Structure transition to install a brand,
and avoid allocation of a private symbol. Since each evaluation of a
class generates a different constructor object, we preserve the semantics
that private methods are lexically scoped.
* builtins/BuiltinNames.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitCreatePrivateBrand):
(JSC::BytecodeGenerator::emitInstallPrivateBrand):
(JSC::BytecodeGenerator::emitInstallPrivateClassBrand):
(JSC::BytecodeGenerator::emitGetPrivateBrand):
(JSC::BytecodeGenerator::emitCheckPrivateBrand):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::BaseDotNode::emitGetPropertyValue):
(JSC::BaseDotNode::emitPutProperty):
(JSC::PostfixNode::emitDot):
(JSC::PrefixNode::emitDot):
(JSC::ClassExprNode::emitBytecode):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseClass):
(JSC::Parser<LexerType>::parseGetterSetter):
* parser/Parser.h:
(JSC::Scope::declarePrivateMethod):
(JSC::Scope::declarePrivateAccessor):
(JSC::Scope::declarePrivateSetter):
(JSC::Scope::declarePrivateGetter):
* parser/VariableEnvironment.cpp:
(JSC::VariableEnvironment::declarePrivateAccessor):
(JSC::VariableEnvironment::declarePrivateSetter):
(JSC::VariableEnvironment::declarePrivateGetter):
(JSC::VariableEnvironment::declarePrivateMethod):
* parser/VariableEnvironment.h:
(JSC::PrivateNameEntry::isStatic const):
(JSC::VariableEnvironment::isEmpty const):
(JSC::VariableEnvironment::declareStaticPrivateMethod):
(JSC::VariableEnvironment::declarePrivateSetter):
(JSC::VariableEnvironment::declareStaticPrivateSetter):
(JSC::VariableEnvironment::declarePrivateGetter):
(JSC::VariableEnvironment::declareStaticPrivateGetter):
(JSC::VariableEnvironment::hasStaticPrivateMethodOrAccessor const):
(JSC::VariableEnvironment::hasInstancePrivateMethodOrAccessor const):
(JSC::VariableEnvironment::hasPrivateMethodOrAccessor const): Deleted.
2021-02-18 Daniel Kolesa <dkolesa@igalia.com>
[JSC] Fix segfaults on 32-bit big endian systems
https://bugs.webkit.org/show_bug.cgi?id=221710
Reviewed by Yusuke Suzuki.
In these cases, we are loading values from memory into registers.
Seemingly, these values are present at an offset on 32-bit big
endian targets; therefore, add PayloadOffset, which is 4 on BE
and 0 on LE (same behavior as right now) and is already present
in other similar accesses in the file.
* llint/LowLevelInterpreter32_64.asm:
2021-02-18 Michael Saboff <msaboff@apple.com>
[JSC] Implement RegExp Match Indices proposal
https://bugs.webkit.org/show_bug.cgi?id=202475
Reviewed by Yusuke Suzuki.
This implements the latest version of the RegExp match indices proposal (https://github.com/tc39/proposal-regexp-match-indices).
It includes a new 'd' flag to RegExp's to trigger the population of the 'indices' property tree in a Matches result from
RegExp.exec() and related methods. This change is performance neutral on JetStream2.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
* runtime/CommonIdentifiers.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::fireWatchpointAndMakeAllArrayStructuresSlowPut):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::regExpMatchesArrayWithIndicesStructure const):
(JSC::JSGlobalObject::regExpMatchesIndicesArrayStructure const):
* runtime/RegExp.cpp:
(JSC::RegExpFunctionalTestCollector::outputOneTest):
(JSC::regexpToSourceString):
* runtime/RegExp.h:
* runtime/RegExpMatchesArray.cpp:
(JSC::createEmptyRegExpMatchesArray):
(JSC::createStructureWithIndicesImpl):
(JSC::createIndicesStructureImpl):
(JSC::createRegExpMatchesArrayWithIndicesStructure):
(JSC::createRegExpMatchesIndicesArrayStructure):
(JSC::createRegExpMatchesArrayWithIndicesSlowPutStructure):
(JSC::createRegExpMatchesIndicesArraySlowPutStructure):
* runtime/RegExpMatchesArray.h:
(JSC::createRegExpMatchesArray):
* runtime/RegExpPrototype.cpp:
(JSC::RegExpPrototype::finishCreation):
(JSC::flagsString):
(JSC::JSC_DEFINE_HOST_FUNCTION):
* yarr/YarrFlags.cpp:
(JSC::Yarr::parseFlags):
* yarr/YarrFlags.h:
* yarr/YarrInterpreter.h:
(JSC::Yarr::BytecodePattern::hasIndices const):
* yarr/YarrPattern.h:
(JSC::Yarr::YarrPattern::hasIndices const):
2021-02-17 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Rename entitlements for JITCage
https://bugs.webkit.org/show_bug.cgi?id=222077
<rdar://problem/74451093>
Reviewed by Mark Lam.
* Scripts/process-entitlements.sh:
* entitlements.plist:
* runtime/Options.cpp:
(JSC::canUseJITCage):
2021-02-16 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Remove unnecessary hack for iOS7
https://bugs.webkit.org/show_bug.cgi?id=222017
Reviewed by Mark Lam.
Remove this symbol hack since we are not supporting iOS7.
* API/JSBase.cpp:
(JSGetMemoryUsageStatistics):
2021-02-16 Saam Barati <sbarati@apple.com>
operationNewArrayWithSize should call tryCreate instead of create
https://bugs.webkit.org/show_bug.cgi?id=221983
<rdar://74265630>
Reviewed by Mark Lam.
I disassembled crashlogs inside operationNewArrayWithSize. They are crashing
inside array allocation. They are crashing on OOM. By code inspection,
operationNewArrayWithSizeAndHint has the same problem.
Callsites to both functions already handle exceptions being thrown, so
converting both operationNewArrayWithSize and operationNewArrayWithSizeAndHint
to throw instead of crash on OOM is trivial.
I wasn't able to come up with a test case for this.
* dfg/DFGOperations.cpp:
(JSC::DFG::JSC_DEFINE_JIT_OPERATION):
* runtime/ObjectConstructor.cpp:
(JSC::ownPropertyKeys):
2021-02-16 Chris Dumez <cdumez@apple.com>
Reduce explicit usage of [objC autorelease] in WebKit
https://bugs.webkit.org/show_bug.cgi?id=221932
Reviewed by Geoff Garen.
Reduce explicit usage of [objC autorelease] in WebKit by using RetainPtr<>.
* API/JSContext.mm:
(-[JSContext init]):
(+[JSContext contextWithJSGlobalContextRef:]):
* API/JSManagedValue.mm:
(+[JSManagedValue managedValueWithValue:]):
(+[JSManagedValue managedValueWithValue:andOwner:]):
* API/JSScript.mm:
(+[JSScript scriptOfType:withSource:andSourceURL:andBytecodeCache:inVirtualMachine:error:]):
(+[JSScript scriptOfType:memoryMappedFromASCIIFile:withSourceURL:andBytecodeCache:inVirtualMachine:error:]):
* API/JSVirtualMachine.mm:
(+[JSVirtualMachine virtualMachineWithContextGroupRef:]):
* API/JSWrapperMap.mm:
(-[JSWrapperMap classInfoForClass:]):
(-[JSWrapperMap objcWrapperForJSValueRef:inContext:]):
* inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm:
(Inspector::RemoteConnectionToTarget::connectionIdentifier const):
(Inspector::RemoteConnectionToTarget::destination const):
* inspector/scripts/codegen/objc_generator.py:
(ObjCGenerator.objc_protocol_import_expression_for_variable):
2021-02-16 Yusuke Suzuki <ysuzuki@apple.com> and Sergey Rubanov <chi187@gmail.com>
WebAssembly: implement non-trapping float to int conversion
https://bugs.webkit.org/show_bug.cgi?id=173471
Reviewed by Tadeu Zagallo.
This patch implements trunc-saturated opcodes in Wasm. This does not trap, and instead it generates
saturated-truncated integer results from floats.
1. If the input is NaN, then return 0.
2. If the input is higher than the maximum value, then return the maximum value (e.g. INT_32MAX).
3. If the input is lower than the minimum value, then return the minimum value (e.g. INT_32MIN).
These wasm opcodes are defined as two-byte opcodes. Currently, we do not have a mechanism to define
this kind of opcodes automatically, so we manually define them. We will clean up in the future patch.
We rename ExtTableOpType to Ext1OpType since it is no longer limited to table opcodes.
* generator/Wasm.rb:
* llint/WebAssembly.asm:
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::truncSaturated):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::truncSaturated):
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::truncSaturated):
(JSC::Wasm::FunctionParser<Context>::parseExpression):
(JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
* wasm/WasmLLIntGenerator.cpp:
(JSC::Wasm::LLIntGenerator::truncSaturated):
* wasm/generateWasm.py:
(isNormal):
* wasm/generateWasmOpsHeader.py:
(opcodeWithTypesMacroizer):
(saturatedTruncMacroizer):
(saturatedTruncMacroizer.modifier):
(Ext1OpType):
(ExtTableOpType): Deleted.
* wasm/wasm.json:
2021-02-16 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Enable JITCage on macOS
https://bugs.webkit.org/show_bug.cgi?id=221805
<rdar://problem/74153806>
Reviewed by Mark Lam.
We enable JITCage too on macOS if it is ARM64E.
We need to add this entitlement only when building it on macOS 120000 or higher version.
Otherwise, we cannot launch the process. This means that we need to dynamically generate entitlements file
because we must not attach this entitlement when building JSC for non 120000 macOS.
We also remove install_name for jsc binary because it broke codesigning. Previously, it was OK since we didn't
have com.apple.private.xxx, but now this broken codesigning makes JSC binary unlaunchable.
* JavaScriptCore.xcodeproj/project.pbxproj:
* Scripts/process-entitlements.sh:
2021-02-16 Chris Dumez <cdumez@apple.com>
Reduce explicit usage of [objC release] in WebKit even more
https://bugs.webkit.org/show_bug.cgi?id=221914
Reviewed by Alex Christensen.
* API/JSContext.mm:
(-[JSContext initWithVirtualMachine:]):
(-[JSContext dealloc]):
(-[JSContext virtualMachine]):
(-[JSContext initWithGlobalContextRef:]):
* API/JSManagedValue.mm:
(-[JSManagedValue initWithValue:]):
(-[JSManagedValue dealloc]):
(-[JSManagedValue didAddOwner:]):
(-[JSManagedValue didRemoveOwner:]):
* API/JSVirtualMachine.mm:
(-[JSVirtualMachine initWithContextGroupRef:]):
(-[JSVirtualMachine dealloc]):
(-[JSVirtualMachine contextForGlobalContextRef:]):
(-[JSVirtualMachine addContext:forGlobalContextRef:]):
(-[JSVirtualMachine externalObjectGraph]):
(-[JSVirtualMachine externalRememberedSet]):
* API/JSWrapperMap.mm:
(createRenameMap):
(copyMethodsToObject):
(-[JSWrapperMap initWithGlobalContextRef:]):
(-[JSWrapperMap classInfoForClass:]):
(-[JSWrapperMap objcWrapperForJSValueRef:inContext:]):
* inspector/scripts/codegen/generate_objc_configuration_implementation.py:
(ObjCConfigurationImplementationGenerator._generate_configuration_implementation_for_domains):
(ObjCConfigurationImplementationGenerator._generate_ivars):
* inspector/scripts/codegen/objc_generator_templates.py:
2021-02-16 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Dynamically generate entitlements
https://bugs.webkit.org/show_bug.cgi?id=221944
Reviewed by Saam Barati.
This patch generates entitlements at compile time since we need to selectively add certain entitlements to binaries.
It follows r248164's way: we must not use CODE_SIGN_ENTITLEMENTS because XCode inserts implicit code-signing
and it breaks our pipeline. We need to disable this XCode's implicit behavior by setting CODE_SIGN_INJECT_BASE_ENTITLEMENTS.
And we also create TestAPI.xcconfig to apply generated entitlements only to testapi and jsc shell.
* Configurations/Base.xcconfig:
* Configurations/JSC.xcconfig:
* Configurations/TestAPI.xcconfig: Copied from Source/JavaScriptCore/Configurations/ToolExecutable.xcconfig.
* Configurations/ToolExecutable.xcconfig:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Scripts/process-entitlements.sh: Added.
* allow-jit-macOS.entitlements: Removed.
* testapi.entitlements: Removed.
2021-02-15 Michael Saboff <msaboff@apple.com>
[ARM64] Change break instruction comment to indicate possible security failure
https://bugs.webkit.org/show_bug.cgi?id=221936
Reviewed by Mark Lam.
We change the comment value to indicate a possible security issue by
using the same value the C++ compiler emits.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::breakpoint):
* disassembler/ARM64/A64DOpcode.cpp:
(JSC::ARM64Disassembler::A64OpcodeExceptionGeneration::format):
* disassembler/ARM64/A64DOpcode.h:
(JSC::ARM64Disassembler::A64OpcodeExceptionGeneration::immediate16):
* offlineasm/arm64.rb:
2021-02-15 Timothy Hatcher <timothy@apple.com>
Web Inspector: Add a way to wake up debuggables to the remote inspector protocol
https://bugs.webkit.org/show_bug.cgi?id=221871
rdar://70351644
Reviewed by Devin Rousso.
* inspector/remote/RemoteInspector.h:
* inspector/remote/RemoteInspectorConstants.h:
* inspector/remote/cocoa/RemoteInspectorCocoa.mm:
(Inspector::RemoteInspector::xpcConnectionReceivedMessage): Handle WIRApplicationWakeUpDebuggablesMessage.
(Inspector::RemoteInspector::receivedWakeUpDebuggables): Added. Call the client.
2021-02-15 Alexey Shvayka <shvaikalesh@gmail.com>
[JSC] PropertySlot should allow passing custom setters
https://bugs.webkit.org/show_bug.cgi?id=221872
Reviewed by Yusuke Suzuki.
This patch:
1. Merges PropertySlot::TypeCustomAccessor into TypeCustom, allowing to pass a setter for
CustomAccessor / CustomValue. Raw C++ function pointers are used to avoid creating
CustomGetterSetter instances for non-reified static properties.
2. Reworks JSObject::getOwnPropertyDescriptor() for custom accessors, making it simpler,
more robust, and no longer required to reify all static properties.
3. Hoists GetValueFunc / PutValueFunc declarations to JSC namespace so they can be used
in header files.
4. Moves CustomAccessor's wrapper maps to JSGlobalObject (because VM outlives it) and
simplifies their keys to C++ function pointers.
5. Splits JSCustomGetterSetterFunction into JSCustomGetterFunction / JSCustomSetterFunction
since their signatures and [[Call]] logic are quite different. This is a nice refactor
that also simplifies garbage collection and reduces memory needed for setter wrappers.
6. Removes PropertyDescriptor::setCustomDescriptor(), making PropertyDescriptor unaware of
custom accessors. Also, drops CustomAccessor check from validateAndApplyPropertyDescriptor()
that was incorrect (no error should be thrown if accessors are unchanged) yet unreachable
because PropertyDescriptor::equalTo() ignores CustomAccessor.
This change fixes a) accessor functions of unforgeable properties [1] to be persistent
(in terms of referential equality) and b) cross-realm accessor functions to be of correct
global object (instead of lexical).
[1]: https://heycam.github.io/webidl/#dfn-unforgeable-on-an-interface
* API/JSCallbackObject.h:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* runtime/JSCustomGetterFunction.cpp: Added.
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::JSCustomGetterFunction::JSCustomGetterFunction):
(JSC::JSCustomGetterFunction::create):
* runtime/JSCustomGetterFunction.h: Added.
* runtime/JSCustomGetterSetterFunction.cpp: Removed.
* runtime/JSCustomGetterSetterFunction.h: Removed.
* runtime/JSCustomSetterFunction.cpp: Added.
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::JSCustomSetterFunction::JSCustomSetterFunction):
(JSC::JSCustomSetterFunction::create):
* runtime/JSCustomSetterFunction.h: Added.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::JSGlobalObject):
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::customGetterFunctionMap):
(JSC::JSGlobalObject::customSetterFunctionMap):
(JSC::JSGlobalObject::customGetterFunctionStructure const):
(JSC::JSGlobalObject::customSetterFunctionStructure const):
(JSC::JSGlobalObject::customGetterSetterFunctionStructure const): Deleted.
* runtime/JSObject.cpp:
(JSC::getCustomGetterFunction):
(JSC::getCustomSetterFunction):
(JSC::JSObject::getOwnPropertyDescriptor):
(JSC::validateAndApplyPropertyDescriptor):
(JSC::getCustomGetterSetterFunctionForGetterSetter): Deleted.
* runtime/JSObject.h:
(JSC::JSObject::fillCustomGetterPropertySlot):
* runtime/Lookup.h:
(JSC::getStaticPropertySlotFromTable):
* runtime/PropertyDescriptor.cpp:
(JSC::PropertyDescriptor::setAccessorDescriptor):
(JSC::PropertyDescriptor::setCustomDescriptor): Deleted.
* runtime/PropertyDescriptor.h:
* runtime/PropertySlot.cpp:
(JSC::PropertySlot::customAccessorGetter const): Deleted.
* runtime/PropertySlot.h:
(JSC::PropertySlot::isCustom const):
(JSC::PropertySlot::customGetter const):
(JSC::PropertySlot::customSetter const):
(JSC::PropertySlot::setCustom):
(JSC::PropertySlot::setCacheableCustom):
(JSC::PropertySlot::getValue const):
(JSC::PropertySlot::isCustomAccessor const): Deleted.
(JSC::PropertySlot::customGetterSetter const): Deleted.
(JSC::PropertySlot::setCustomGetterSetter): Deleted.
* runtime/PutPropertySlot.h:
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2021-02-15 Caio Lima <ticaiolima@gmail.com>
[ESNext] Implement private accessors
https://bugs.webkit.org/show_bug.cgi?id=194435
Reviewed by Yusuke Suzuki.
This patch is implementing support for instance private getters and
setters following the proposal on https://tc39.es/proposal-private-methods.
Private accessors also use the private brand check mechanism of
private methods, which means that we are using both
`op_set_private_brand` and `op_check_private_brand` to perform brand
checks. Accessors are also stored on class lexical scope as a pair of
`getter` and `setter`. This is done creating a new `JSObject` and
storing the `getter` on `get` property, and `setter` on `set`
property. This is designed in such way that we can always hit IC fast
path on `get_by_id_direct` to access the property, and also to allow
constant folding of accessors on DFG/FTL, since acessors objects are
going to be constant once created.
For reference, we have the following bytecode for a private getter
access:
```
class C {
get #m() {...}
access() {
return this.#m;
}
}
```
Bytecode for class declaration:
```
...
new_object dst:loc12, inlineCapacity:2 // this is the object to store getter and setter pair
new_func_exp dst:loc13, scope:loc4, functionDecl:"get #m() {...}"
put_by_id base:loc13, property:@homeObject, value:loc11, flags:Strict
put_by_id base:loc12, property:@get, value:loc13, flags:IsDirect|Strict
put_to_scope scope:loc4, var:#m, value:loc12 // loc4 is the class lexical scope
...
```
Bytecode for `access()`:
```
...
resolve_scope dst:loc7, scope:loc4, var:"#m", resolveType:GlobalProperty, localScopeDepth:0
get_from_scope dst:loc8, scope:loc7, var:@privateBrand
check_private_brand base:this, brand:loc8
get_from_scope dst:loc8, scope:loc7, var:"#m"
get_by_id_direct dst:loc9, base:loc8, property:@get
mov dst:loc10, src:this
call dst:loc6, callee:loc9, argc:1, argv:16
...
```
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::instantiateLexicalVariables):
(JSC::BytecodeGenerator::getPrivateTraits):
(JSC::BytecodeGenerator::getAvailablePrivateAccessNames):
(JSC::BytecodeGenerator::isPrivateMethod): Deleted.
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::PropertyListNode::emitBytecode):
(JSC::PropertyListNode::emitPutConstantProperty):
(JSC::BaseDotNode::emitGetPropertyValue):
(JSC::BaseDotNode::emitPutProperty):
(JSC::PostfixNode::emitDot):
(JSC::PrefixNode::emitDot):
* parser/Nodes.h:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseClass):
(JSC::Parser<LexerType>::parseGetterSetter):
* parser/Parser.h:
(JSC::Scope::declarePrivateSetter):
(JSC::Scope::declarePrivateGetter):
* parser/VariableEnvironment.cpp:
(JSC::VariableEnvironment::declarePrivateAccessor):
(JSC::VariableEnvironment::declarePrivateSetter):
(JSC::VariableEnvironment::declarePrivateGetter):
* parser/VariableEnvironment.h:
(JSC::VariableEnvironmentEntry::isPrivateSetter const):
(JSC::VariableEnvironmentEntry::isPrivateGetter const):
(JSC::VariableEnvironmentEntry::setIsPrivateSetter):
(JSC::VariableEnvironmentEntry::setIsPrivateGetter):
(JSC::PrivateNameEntry::isSetter const):
(JSC::PrivateNameEntry::isGetter const):
(JSC::PrivateNameEntry::isField const):
(JSC::PrivateNameEntry::isPrivateMethodOrAcessor const):
(JSC::VariableEnvironment::declarePrivateSetter):
(JSC::VariableEnvironment::declarePrivateGetter):
* runtime/ExceptionHelpers.cpp:
(JSC::createPrivateMethodAccessError):
2021-02-15 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r272831.
https://bugs.webkit.org/show_bug.cgi?id=221907
breaking internal build
Reverted changeset:
"[JSC] Enable JITCage on macOS"
https://bugs.webkit.org/show_bug.cgi?id=221805
https://trac.webkit.org/changeset/272831
2021-02-13 Alexey Shvayka <shvaikalesh@gmail.com>
Proxy's [[GetOwnProperty]] should complete trap result descriptor before validation
https://bugs.webkit.org/show_bug.cgi?id=221772
Reviewed by Yusuke Suzuki.
This patch implements CompletePropertyDescriptor abstract op and utilizes it in
Proxy's [[GetOwnProperty]], right before IsCompatiblePropertyDescriptor check
as per spec [1].
This change tightens trap result validation rules for properties that are
non-configurable on [[ProxyTarget]], aligning JSC with V8 and SpiderMonkey.
It's impossible to prefill trap result descriptor: toPropertyDescriptor() throws
on malformed descriptors, thus it expects the argument to be an empty descriptor
(added an assert).
Property descriptors returned to userland are unaffected as they were implicitly
completed when filling PropertySlot (see PropertyDescriptor::defaultAttributes).
[1]: https://tc39.es/ecma262/#sec-proxy-object-internal-methods-and-internal-slots-getownproperty-p (step 14)
* runtime/ObjectConstructor.cpp:
(JSC::toPropertyDescriptor):
* runtime/ProxyObject.cpp:
(JSC::completePropertyDescriptor):
(JSC::ProxyObject::performInternalMethodGetOwnProperty):
2021-02-12 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Enable JITCage on macOS
https://bugs.webkit.org/show_bug.cgi?id=221805
<rdar://problem/74153806>
Reviewed by Mark Lam.
We enable JITCage too on macOS if it is ARM64E.
We need to add this entitlement only when building it on macOS 120000 or higher version.
Otherwise, we cannot launch the process. This means that we need to dynamically generate entitlements file
because we must not attach this entitlement when building JSC for non 120000 macOS.
This patch follows r248164's way: we must not use CODE_SIGN_ENTITLEMENTS because XCode inserts implicit code-signing
and it breaks our pipeline. We need to disable this XCode's implicit behavior by setting CODE_SIGN_INJECT_BASE_ENTITLEMENTS.
And we also create TestAPI.xcconfig to apply generated entitlements only to testapi and jsc shell.
* Configurations/Base.xcconfig:
* Configurations/JSC.xcconfig:
* Configurations/TestAPI.xcconfig: Copied from Source/JavaScriptCore/Configurations/ToolExecutable.xcconfig.
* Configurations/ToolExecutable.xcconfig:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Scripts/process-entitlements.sh: Added.
* allow-jit-macOS.entitlements: Removed.
* testapi.entitlements: Removed.
2021-02-12 Mark Lam <mark.lam@apple.com>
Rename `slotVisitor` variables to `visitor`.
https://bugs.webkit.org/show_bug.cgi?id=221866
Reviewed by Yusuke Suzuki.
In existing code, we sometimes name a SlotVisitor instance `slotVisitor` and
sometimes just `visitor`. This patch makes it so that we use `visitor` consistently
everywhere. This will also reduce the size of the GC verifier patch later.
Also fixed a few typos in comments.
This is a pure refactoring patch. There are no behavior changes.
* API/JSMarkingConstraintPrivate.cpp:
(JSContextGroupAddMarkingConstraint):
* bytecode/RecordedStatuses.cpp:
(JSC::RecordedStatuses::visitAggregate):
(JSC::RecordedStatuses::markIfCheap):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::blocksInPostOrder):
* heap/Heap.cpp:
(JSC::Heap::runBeginPhase):
(JSC::Heap::runFixpointPhase):
(JSC::Heap::runConcurrentPhase):
(JSC::Heap::stopThePeriphery):
(JSC::Heap::resumeThePeriphery):
(JSC::Heap::addCoreConstraints):
(JSC::Heap::performIncrement):
* heap/HeapInlines.h:
(JSC::Heap::forEachSlotVisitor):
* runtime/JSSegmentedVariableObject.cpp:
(JSC::JSSegmentedVariableObject::visitChildren):
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::visit):
2021-02-12 Mark Lam <mark.lam@apple.com>
Remove some unused methods in MarkedBlock and PreciseAllocation.
https://bugs.webkit.org/show_bug.cgi?id=221864
Reviewed by Yusuke Suzuki.
* heap/MarkedBlock.h:
(JSC::MarkedBlock::Handle::visitWeakSet): Deleted.
(JSC::MarkedBlock::Handle::reapWeakSet): Deleted.
* heap/PreciseAllocation.cpp:
(JSC::PreciseAllocation::shrink): Deleted.
(JSC::PreciseAllocation::visitWeakSet): Deleted.
(JSC::PreciseAllocation::reapWeakSet): Deleted.
* heap/PreciseAllocation.h:
2021-02-12 Michael Saboff <msaboff@apple.com>
[ARM64e] Harden Mach exception handling
https://bugs.webkit.org/show_bug.cgi?id=221841
Reviewed by Geoffrey Garen.
Split wasm_throw_from_fault_handler_trampoline into two trampolines to eliminate the
need to pass a register argument to signify if we are using FastTLS. With this change
we don't need to modify registers besides the PC when handling exceptions.
Added sanity checks to make sure handlers are being called for the exceptions they
were registered for.
* bytecode/BytecodeList.rb:
* llint/WebAssembly.asm:
* runtime/VMTraps.cpp:
* signal: Added.
* tools/SigillCrashAnalyzer.cpp:
(JSC::installCrashHandler):
* wasm/WasmFaultSignalHandler.cpp:
(JSC::Wasm::trapHandler):
2021-02-12 Mark Lam <mark.lam@apple.com>
Move RootMarkReason out of SlotVisitor.
https://bugs.webkit.org/show_bug.cgi?id=221831
Reviewed by Tadeu Zagallo.
This will lessen the amount of diff needed for the GC verifier later.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* heap/Heap.cpp:
(JSC::Heap::addCoreConstraints):
* heap/HeapAnalyzer.h:
* heap/HeapSnapshotBuilder.cpp:
(JSC::HeapSnapshotBuilder::analyzeEdge):
(JSC::rootTypeToString):
* heap/HeapSnapshotBuilder.h:
* heap/RootMarkReason.h: Added.
* heap/SlotVisitor.h:
(JSC::SetRootMarkReasonScope::SetRootMarkReasonScope):
* inspector/JSInjectedScriptHost.cpp:
2021-02-11 Nikita Vasilyev <nvasilyev@apple.com>
Web Inspector: "Show Extended Gridlines" option for grid overlay does not work
https://bugs.webkit.org/show_bug.cgi?id=221775
Reviewed by Devin Rousso.
Replace all mentions of "Gridlines" with "GridLines" (camelcase).
* inspector/protocol/DOM.json:
2021-02-11 Mark Lam <mark.lam@apple.com>
CodeBlock::propagateTransitions() should also handle OpSetPrivateBrand's LLInt IC.
https://bugs.webkit.org/show_bug.cgi?id=221787
Reviewed by Yusuke Suzuki.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::propagateTransitions):
2021-02-11 Alexey Shvayka <shvaikalesh@gmail.com>
SetIntegrityLevel should call [[DefineOwnProperty]] with partial descriptor
https://bugs.webkit.org/show_bug.cgi?id=221497
Reviewed by Yusuke Suzuki.
This patch prevents [[GetOwnProperty]] result descriptor from being reused for
[[DefineOwnProperty]]. Instead, partial descriptor with only [[Configurable]]
and (conditionally) [[Writable]] fields is passed, which is observable by
ProxyObject's "defineProperty" trap (and possibly any other opaque object).
Also, replaces isDataDescriptor() check with negated isAccessorDescriptor()
as per spec [1], which is equivalent in this case yet is false dichotomy
for partial descriptors.
Aligns JSC with V8 and SpiderMonkey.
[1]: https://tc39.es/ecma262/#sec-setintegritylevel (step 7.b.ii)
* runtime/ObjectConstructor.cpp:
(JSC::setIntegrityLevel):
2021-02-11 Don Olmstead <don.olmstead@sony.com>
[CMake] WEBKIT_EXECUTABLE can incorrectly link framework
https://bugs.webkit.org/show_bug.cgi?id=221703
Reviewed by Michael Catanzaro.
GTK compiles JavaScriptCore as a SHARED library but the symbols from WTF are not being
properly exposed from it. Workaround this by linking WTF directly until GTK turns on
hidden visibility and properly exports symbols.
* shell/PlatformGTK.cmake:
2021-02-10 Don Olmstead <don.olmstead@sony.com>
Non-unified build fixes, early February 2021 edition
https://bugs.webkit.org/show_bug.cgi?id=221701
Unreviewed non-unified build fixes.
* bytecode/IterationModeMetadata.h:
* bytecode/SetPrivateBrandStatus.h:
2021-02-10 Mark Lam <mark.lam@apple.com>
We should not static_assert on an ENABLE() macro.
https://bugs.webkit.org/show_bug.cgi?id=221714
rdar://74197896
Reviewed by Yusuke Suzuki.
This is because the ENABLE() macro reduces to a macro expression
`(defined ENABLE_##WTF_FEATURE && ENABLE_##WTF_FEATURE)` which is not a C++
expression that a static_assert can evaluate.
* llint/LLIntData.cpp:
* llint/LLIntData.h:
(JSC::LLInt::getCodePtr):
(JSC::LLInt::getWide16CodePtr):
(JSC::LLInt::getWide32CodePtr):
2021-02-10 Saam Barati <sbarati@apple.com>
Don't crash when reparsing an arrow function and the parsing invariant is broken
https://bugs.webkit.org/show_bug.cgi?id=221632
<rdar://71874091>
Reviewed by Tadeu Zagallo and Mark Lam.
We have code where we assert that when reparsing an arrow function,
we see the '=>' token after parsing the parameters. Since we already
parsed the arrow function before, this assertion makes sense. But somehow,
this is leading to crashes on real websites. We don't know why this invariant
is being broken. I'm changing this to a debug assert, and we're tracking
the full fix in:
https://bugs.webkit.org/show_bug.cgi?id=221633
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseInner):
2021-02-09 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] C++ iteration should support fast iterator protocol
https://bugs.webkit.org/show_bug.cgi?id=221526
Reviewed by Alexey Shvayka.
This patch adds fast iteration protocol support in C++ iteration (forEachIterable).
In JS, we have op_iterator_open / op_iterator_next to iterate array quickly.
But we do not use this feature in C++ forEachIterable. In this patch we integrate
the same (or a bit more efficient since we can avoid creating JSArrayIterator) mechanism
so that iteration in C++ gets faster for normal arrays.
We observed 1.9x faster in Map creation with arrays.
ToT Patched
map-constructor 35.7446+-0.2354 ^ 18.7516+-0.4534 ^ definitely 1.9062x faster
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::iteratorEntries):
* runtime/CommonSlowPaths.cpp:
(JSC::iteratorOpenTryFastImpl):
* runtime/IteratorOperations.cpp:
(JSC::iteratorClose):
(JSC::prepareForFastArrayIteration):
* runtime/IteratorOperations.h:
(JSC::forEachInIterable):
* runtime/JSArrayIterator.h:
2021-02-09 Caio Lima <ticaiolima@gmail.com>
Fix warning introduced by r272580
https://bugs.webkit.org/show_bug.cgi?id=221612
Unreviewed build fixes.
* bytecode/CheckPrivateBrandVariant.cpp:
* bytecode/CheckPrivateBrandVariant.h:
* bytecode/SetPrivateBrandVariant.cpp:
* bytecode/SetPrivateBrandVariant.h:
2021-02-09 Caio Lima <ticaiolima@gmail.com>
[ESNext] Implement private methods
https://bugs.webkit.org/show_bug.cgi?id=194434
Reviewed by Filip Pizlo.
This patch is adding support to private methods following the
specification on https://tc39.es/proposal-private-methods/.
This is introducing a new way to declare private methods on
class syntax. Private methods are only accessible within
classes they were declared, and only can be called from
objects that are instance of these classes.
To guarantee such rules, the proposal presents the concept of
Brand Check. During class evaluation, if a private method is present,
a `brand` is installed in this class. Every instance of such class
then gets this brand installed during `[[Construct]]` operation. It
means that an object can have multiple brands (e.g when there is also
private methods declared on super class). Before accessing a private
method, there is a check to validate if the target of the call has the
brand of callee method.
The brand check mechanism is implemented using a `@privateBrand`
stored on class scope. Here is a representation of how this mechanism
works:
```
class C {
#m() { return 3; }
method() { return this.#m(); }
}
let c = new C();
console.log(c.method()); // prints 3
```
Generated bytecode for the following representation:
```
{ // class lexical scope
const @privateBrand = @createPrivateSymbol();
const #m = function () { return 3; }
C.prototype.method = function() {
@check_private_brand(this, @privateBrand);
return #m.call(this);
}
C = function() {
@set_private_brand(this, @privateBrand);
}
}
let c = new C();
console.log(c.method()); // prints 3
```
# Resolving correct brand to check
In the case of shadowing or nested scope, we need to emit brand
checks to the right private brand. See code below:
```
class C {
#m() { return 3; }
method() { return this.#m();}
A = class {
#m2() { return 3; }
foo(o) { return o.#m(); }
}
}
```
The call of "#m" in `foo` refers to "C::#m". In such case, we need to
check C's private brand, instead of A's private brand.
To perform the proper check, we first resolve scope of "#m" and then
check the private brand of this scope (the scope where the private
method and brand are stored is the same).
So the bytecode to lookup the right brand is:
```
mov loc9, arg1
resolve_scope loc10, "#m"
get_from_scope loc11, loc10, "@privateBrand"
check_private_brand loc9, loc11
get_from_scope loc11, loc10, "#m"
// setup call frame
call loc11, ...
// ...
```
# Brand check mechanism
We are introducing in this patch 2 new bytecodes to allow brand check
of objects: `op_set_brand` and `op_check_brand`.
`op_set_brand` sets a new brand in an object, so we can perform the brand
check later when accessing private methods. This operations throws when
trying to add the same brand twice in an Object.
`op_check_brand` checks if the given object contains the brand we are
looking for. It traverses the brand chain to verify if the brand is
present, and throws `TypeError` otherwise.
We are also introducing a subclass for Structure called BrandedStructure.
It is used to store brands and to allow brand check mechanism. BrandedStructure
stores a brand and a parent pointer to another BrandedStructure that allow
us traverse the brand chain. With `BrandedStructure`, we can then
infer that a given object has the brand we are looking for just
checking its structureId. This is a very good optimization, since we can
reduce most of brand checks to structure checks.
We created a new kind of transition called `SetBrand` that happens when
`op_set_brand` is executed. This allow us to cache such kind of
trasitions on trasition table using the key `<brand->uid, 0,
TransitionKind::SetBrand>`. During this transition, we take previous
structure and apply one of the following rules:
1. If it's a BrandedStructure, we then set it to `m_parentBrand`,
to allow proper brand chain check.
2. If it's not a BrandedStructure, we set `m_parentBrand` to `nullptr`,
meaning that this is the first brand being added to the object
with this structure.
For now, we are using the flag `isBrandedStructure` to identify that a
given Structure is a BrandedStructure. This is done to avoid changes
on places where we are checking for `vm.structureStructure()`.
However, if we ever need space on Structure, this flag is a good
candidate to be deleted and we can move to a solution that uses
`vm.brandedStructureStructure()`;
# JIT Support
This patch also includes initial JIT support for `set_private_brand`
and `check_private_brand`. On Baseline JIT, we are using
`JITPravateBrandAccessGenerator` to support IC for both operands.
On `DFGByteCodeParser` we are trying to inline brand access whenever
possible, and fallbacking to `SetPrivateBrand` and
`CheckPrivateBrand` otherwise. Those nodes are not being optimized at
their full potential, but the code generated by them is also relying on
`JITPrivateBrandAccessGenerator` to have IC support for both DFG and
FTL. During DFG parsing, we try to reduce those access to `CheckIsConstant`
and `CheckStructure` (with `PutStructure` for `set_private_brand` cases)
based on available profiled data. This is meant to make brand checks
almost free on DFG/FTL tiers when we have a single evaluation of a
class, since the `CheckIsConstant` can be eliminated by the constant-folded
scope load, and the `CheckStructure` is very likely to be redundant
to any other `CheckStructure` that can be performed on receiver
when we have a finite structure set.
For instance, when we have a brand check on a path-of-no-return to
a `GetByOffset` sequence on the same receiver, the `CheckStructure`
for the brand check will enable CSE of the `CheckStructure` that
would happen for that `GetByOffset`. Such design is possible because brand
checks supports polymorphic access very similr to what we have for
`GetByOffset` sequences.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* builtins/BuiltinExecutables.cpp:
(JSC::BuiltinExecutables::createDefaultConstructor):
(JSC::BuiltinExecutables::createExecutable):
* builtins/BuiltinExecutables.h:
We are adding a new parameter `PrivateBrandRequirement` to propagate
when a default constructor needs to emit code to setup private brand
on instances.
* builtins/BuiltinNames.h:
Adding `@privateBrand` that we use to store private brand on
class's scope.
* bytecode/AccessCase.cpp:
(JSC::AccessCase::createCheckPrivateBrand):
(JSC::AccessCase::createSetPrivateBrand):
(JSC::AccessCase::requiresIdentifierNameMatch const):
(JSC::AccessCase::requiresInt32PropertyCheck const):
(JSC::AccessCase::needsScratchFPR const):
(JSC::AccessCase::forEachDependentCell const):
(JSC::AccessCase::doesCalls const):
(JSC::AccessCase::canReplace const):
(JSC::AccessCase::dump const):
(JSC::AccessCase::generateWithGuard):
(JSC::AccessCase::generateImpl):
* bytecode/AccessCase.h:
(JSC::AccessCase::structure const):
(JSC::AccessCase::newStructure const):
* bytecode/BytecodeList.rb:
* bytecode/BytecodeUseDef.cpp:
(JSC::computeUsesForBytecodeIndexImpl):
(JSC::computeDefsForBytecodeIndexImpl):
* bytecode/CheckPrivateBrandStatus.cpp: Added.
(JSC::CheckPrivateBrandStatus::appendVariant):
(JSC::CheckPrivateBrandStatus::computeForBaseline):
(JSC::CheckPrivateBrandStatus::CheckPrivateBrandStatus):
(JSC::CheckPrivateBrandStatus::computeForStubInfoWithoutExitSiteFeedback):
(JSC::CheckPrivateBrandStatus::computeFor):
(JSC::CheckPrivateBrandStatus::slowVersion const):
(JSC::CheckPrivateBrandStatus::merge):
(JSC::CheckPrivateBrandStatus::filter):
(JSC::CheckPrivateBrandStatus::singleIdentifier const):
(JSC::CheckPrivateBrandStatus::visitAggregate):
(JSC::CheckPrivateBrandStatus::markIfCheap):
(JSC::CheckPrivateBrandStatus::finalize):
(JSC::CheckPrivateBrandStatus::dump const):
* bytecode/CheckPrivateBrandStatus.h: Added.
* bytecode/CheckPrivateBrandVariant.cpp: Added.
(JSC::CheckPrivateBrandVariant::CheckPrivateBrandVariant):
(JSC::CheckPrivateBrandVariant::~CheckPrivateBrandVariant):
(JSC::CheckPrivateBrandVariant::attemptToMerge):
(JSC::CheckPrivateBrandVariant::markIfCheap):
(JSC::CheckPrivateBrandVariant::finalize):
(JSC::CheckPrivateBrandVariant::visitAggregate):
(JSC::CheckPrivateBrandVariant::dump const):
(JSC::CheckPrivateBrandVariant::dumpInContext const):
* bytecode/CheckPrivateBrandVariant.h: Added.
(JSC::CheckPrivateBrandVariant::structureSet const):
(JSC::CheckPrivateBrandVariant::structureSet):
(JSC::CheckPrivateBrandVariant::identifier const):
(JSC::CheckPrivateBrandVariant::overlaps):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::finalizeLLIntInlineCaches):
* bytecode/ExecutableInfo.h:
(JSC::ExecutableInfo::ExecutableInfo):
(JSC::ExecutableInfo::privateBrandRequirement const):
* bytecode/PolymorphicAccess.cpp:
(JSC::PolymorphicAccess::regenerate):
(WTF::printInternal):
* bytecode/RecordedStatuses.cpp:
(JSC::RecordedStatuses::operator=):
(JSC::RecordedStatuses::addCheckPrivateBrandStatus):
(JSC::RecordedStatuses::addSetPrivateBrandStatus):
(JSC::RecordedStatuses::visitAggregate):
(JSC::RecordedStatuses::markIfCheap):
* bytecode/RecordedStatuses.h:
(JSC::RecordedStatuses::forEachVector):
* bytecode/SetPrivateBrandStatus.cpp: Added.
(JSC::SetPrivateBrandStatus::appendVariant):
(JSC::SetPrivateBrandStatus::computeForBaseline):
(JSC::SetPrivateBrandStatus::SetPrivateBrandStatus):
(JSC::SetPrivateBrandStatus::computeForStubInfoWithoutExitSiteFeedback):
(JSC::SetPrivateBrandStatus::computeFor):
(JSC::SetPrivateBrandStatus::slowVersion const):
(JSC::SetPrivateBrandStatus::merge):
(JSC::SetPrivateBrandStatus::filter):
(JSC::SetPrivateBrandStatus::singleIdentifier const):
(JSC::SetPrivateBrandStatus::visitAggregate):
(JSC::SetPrivateBrandStatus::markIfCheap):
(JSC::SetPrivateBrandStatus::finalize):
(JSC::SetPrivateBrandStatus::dump const):
* bytecode/SetPrivateBrandStatus.h: Added.
* bytecode/SetPrivateBrandVariant.cpp: Added.
(JSC::SetPrivateBrandVariant::SetPrivateBrandVariant):
(JSC::SetPrivateBrandVariant::~SetPrivateBrandVariant):
(JSC::SetPrivateBrandVariant::attemptToMerge):
(JSC::SetPrivateBrandVariant::markIfCheap):
(JSC::SetPrivateBrandVariant::finalize):
(JSC::SetPrivateBrandVariant::visitAggregate):
(JSC::SetPrivateBrandVariant::dump const):
(JSC::SetPrivateBrandVariant::dumpInContext const):
* bytecode/SetPrivateBrandVariant.h: Added.
(JSC::SetPrivateBrandVariant::oldStructure const):
(JSC::SetPrivateBrandVariant::newStructure const):
(JSC::SetPrivateBrandVariant::identifier const):
(JSC::SetPrivateBrandVariant::overlaps):
* bytecode/StructureStubInfo.cpp:
(JSC::StructureStubInfo::reset):
* bytecode/StructureStubInfo.h:
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedCodeBlock.h:
(JSC::UnlinkedCodeBlock::privateBrandRequirement const):
* bytecode/UnlinkedCodeBlockGenerator.h:
(JSC::UnlinkedCodeBlockGenerator::privateBrandRequirement const):
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::generateUnlinkedFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
* bytecode/UnlinkedFunctionExecutable.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
We changed BytecodeGenerator for FunctionNode and EvalNode to
propagate parentScope PrivateNameEnvironment. These environments stores
private name entries that are visible into the scope of the
function/eval.
This is required to identify the kind of access a private name is
referring to, since it can be a private field or a private method.
(JSC::BytecodeGenerator::instantiateLexicalVariables):
(JSC::BytecodeGenerator::emitGetPrivateName):
(JSC::BytecodeGenerator::emitCreatePrivateBrand):
The process to create a private brand is as follows:
1. Create a PrivateSymbol using `@createPrivateSymbol`.
2. Store this symbol into a given scope (i.e class lexical scope)
on `@privateBrand` variable.
(JSC::BytecodeGenerator::emitInstallPrivateBrand):
(JSC::BytecodeGenerator::emitGetPrivateBrand):
We added `m_privateNamesStack` to BytecodeGenerator to represent the
scope chain of available private names while generating bytecode.
(JSC::BytecodeGenerator::emitCheckPrivateBrand):
(JSC::BytecodeGenerator::isPrivateMethod):
(JSC::BytecodeGenerator::pushPrivateAccessNames):
(JSC::BytecodeGenerator::popPrivateAccessNames):
(JSC::BytecodeGenerator::getAvailablePrivateAccessNames):
(JSC::BytecodeGenerator::emitNewDefaultConstructor):
(JSC::BytecodeGenerator::emitNewClassFieldInitializerFunction):
(JSC::BytecodeGenerator::emitDirectGetByVal): Deleted.
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::privateBrandRequirement const):
(JSC::BytecodeGenerator::generate):
(JSC::BytecodeGenerator::makeFunction):
This change is required to properly propagate PrivateBrandRequirement
to arrow functions that can potentially call `super()`.
* bytecompiler/NodesCodegen.cpp:
(JSC::PropertyListNode::emitDeclarePrivateFieldNames):
(JSC::PropertyListNode::emitBytecode):
(JSC::PropertyListNode::emitPutConstantProperty):
(JSC::BaseDotNode::emitGetPropertyValue):
Adding support to properly access private method. Since we store
private methods on class lexical scope, we need a different set of
instructions to access a private method.
(JSC::BaseDotNode::emitPutProperty):
In the case of we trying to write in a private method, we need to
throw a TypeError according to specification
(https://tc39.es/proposal-private-methods/#sec-privatefieldset).
(JSC::FunctionCallValueNode::emitBytecode):
(JSC::PostfixNode::emitDot):
(JSC::PrefixNode::emitDot):
(JSC::ClassExprNode::emitBytecode):
* debugger/DebuggerCallFrame.cpp:
(JSC::DebuggerCallFrame::evaluateWithScopeExtension):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
(JSC::DFG::AbstractInterpreter<AbstractStateType>::filterICStatus):
* dfg/DFGArgumentsEliminationPhase.cpp:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGClobbersExitState.cpp:
(JSC::DFG::clobbersExitState):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGGraph.h:
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::link):
* dfg/DFGJITCompiler.h:
(JSC::DFG::JITCompiler::addPrivateBrandAccess):
* dfg/DFGMayExit.cpp:
* dfg/DFGNode.h:
(JSC::DFG::Node::hasCheckPrivateBrandStatus):
(JSC::DFG::Node::checkPrivateBrandStatus):
(JSC::DFG::Node::hasSetPrivateBrandStatus):
(JSC::DFG::Node::setPrivateBrandStatus):
* dfg/DFGNodeType.h:
* dfg/DFGObjectAllocationSinkingPhase.cpp:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCheckPrivateBrand):
(JSC::DFG::SpeculativeJIT::compileSetPrivateBrand):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStoreBarrierInsertionPhase.cpp:
* dfg/DFGVarargsForwardingPhase.cpp:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compilePrivateBrandAccess):
(JSC::FTL::DFG::LowerDFGToB3::compileCheckPrivateBrand):
(JSC::FTL::DFG::LowerDFGToB3::compileSetPrivateBrand):
* interpreter/Interpreter.cpp:
(JSC::eval):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
(JSC::JIT::link):
* jit/JIT.h:
* jit/JITInlineCacheGenerator.cpp:
(JSC::JITPrivateBrandAccessGenerator::JITPrivateBrandAccessGenerator):
(JSC::JITPrivateBrandAccessGenerator::generateFastPath):
(JSC::JITPrivateBrandAccessGenerator::finalize):
* jit/JITInlineCacheGenerator.h:
(JSC::JITPrivateBrandAccessGenerator::JITPrivateBrandAccessGenerator):
(JSC::JITPrivateBrandAccessGenerator::slowPathJump const):
* jit/JITOperations.cpp:
(JSC::JSC_DEFINE_JIT_OPERATION):
(JSC::getPrivateName):
* jit/JITOperations.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_set_private_brand):
(JSC::JIT::emitSlow_op_set_private_brand):
(JSC::JIT::emit_op_check_private_brand):
(JSC::JIT::emitSlow_op_check_private_brand):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_set_private_brand):
(JSC::JIT::emitSlow_op_set_private_brand):
(JSC::JIT::emit_op_check_private_brand):
(JSC::JIT::emitSlow_op_check_private_brand):
* jit/Repatch.cpp:
(JSC::tryCacheCheckPrivateBrand):
(JSC::repatchCheckPrivateBrand):
(JSC::tryCacheSetPrivateBrand):
(JSC::repatchSetPrivateBrand):
(JSC::resetCheckPrivateBrand):
(JSC::resetSetPrivateBrand):
* jit/Repatch.h:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LLIntSlowPaths.h:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* parser/Nodes.cpp:
(JSC::FunctionMetadataNode::FunctionMetadataNode):
* parser/Nodes.h:
(JSC::BaseDotNode::isPrivateMember const):
(JSC::BaseDotNode::isPrivateField const): Deleted.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseClass):
(JSC::Parser<LexerType>::parseMemberExpression):
* parser/Parser.h:
(JSC::Scope::declarePrivateMethod):
(JSC::Scope::declarePrivateField):
(JSC::Parser<LexerType>::parse):
(JSC::parse):
(JSC::Scope::declarePrivateName): Deleted.
* parser/ParserModes.h:
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createDotAccess):
* parser/VariableEnvironment.cpp:
(JSC::VariableEnvironment::declarePrivateMethod):
* parser/VariableEnvironment.h:
(JSC::VariableEnvironmentEntry::isPrivateField const):
(JSC::VariableEnvironmentEntry::isPrivateMethod const):
(JSC::VariableEnvironmentEntry::setIsPrivateField):
(JSC::VariableEnvironmentEntry::setIsPrivateMethod):
(JSC::PrivateNameEntry::isMethod const):
(JSC::PrivateNameEntry::isPrivateMethodOrAcessor const):
(JSC::VariableEnvironment::addPrivateName):
(JSC::VariableEnvironment::declarePrivateField):
(JSC::VariableEnvironment::declarePrivateMethod):
(JSC::VariableEnvironment::privateNameEnvironment const):
(JSC::VariableEnvironment::hasPrivateMethodOrAccessor const):
(JSC::VariableEnvironment::addPrivateNamesFrom):
(JSC::VariableEnvironmentEntry::isPrivateName const): Deleted.
(JSC::VariableEnvironmentEntry::setIsPrivateName): Deleted.
(JSC::VariableEnvironment::declarePrivateName): Deleted.
* runtime/CachedTypes.cpp:
(JSC::CachedCodeBlockRareData::encode):
(JSC::CachedCodeBlockRareData::decode const):
(JSC::CachedFunctionExecutableRareData::encode):
(JSC::CachedFunctionExecutableRareData::decode const):
(JSC::CachedFunctionExecutable::privateBrandRequirement const):
(JSC::CachedCodeBlock::derivedContextType const):
(JSC::CachedFunctionExecutable::encode):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
(JSC::CachedCodeBlock::needsClassFieldInitializer const): Deleted.
* runtime/CodeCache.cpp:
(JSC::generateUnlinkedCodeBlockImpl):
(JSC::generateUnlinkedCodeBlock):
(JSC::generateUnlinkedCodeBlockForDirectEval):
(JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
* runtime/CodeCache.h:
* runtime/DirectEvalExecutable.cpp:
(JSC::DirectEvalExecutable::create):
(JSC::DirectEvalExecutable::DirectEvalExecutable):
* runtime/DirectEvalExecutable.h:
* runtime/EvalExecutable.cpp:
(JSC::EvalExecutable::EvalExecutable):
* runtime/EvalExecutable.h:
(JSC::EvalExecutable::executableInfo const):
(JSC::EvalExecutable::privateBrandRequirement const):
* runtime/ExceptionHelpers.cpp:
(JSC::createInvalidPrivateNameError):
* runtime/IndirectEvalExecutable.cpp:
(JSC::IndirectEvalExecutable::IndirectEvalExecutable):
* runtime/JSObject.h:
* runtime/JSObjectInlines.h:
(JSC::JSObject::checkPrivateBrand):
(JSC::JSObject::setPrivateBrand):
* runtime/JSScope.cpp:
(JSC::JSScope::collectClosureVariablesUnderTDZ):
* runtime/JSScope.h:
* runtime/ModuleProgramExecutable.h:
* runtime/Options.cpp:
(JSC::Options::recomputeDependentOptions):
* runtime/OptionsList.h:
* runtime/ProgramExecutable.h:
* runtime/Structure.cpp:
(JSC::Structure::materializePropertyTable):
(JSC::BrandedStructure::BrandedStructure):
(JSC::BrandedStructure::create):
(JSC::BrandedStructure::checkBrand):
(JSC::Structure::setBrandTransitionFromExistingStructureImpl):
(JSC::Structure::setBrandTransitionFromExistingStructureConcurrently):
(JSC::Structure::setBrandTransition):
* runtime/Structure.h:
(JSC::Structure::finishCreation):
* runtime/StructureInlines.h:
(JSC::Structure::create):
(JSC::Structure::forEachPropertyConcurrently):
* runtime/StructureTransitionTable.h:
* runtime/SymbolTable.cpp:
(JSC::SymbolTable::cloneScopePart):
* runtime/SymbolTable.h:
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2021-02-09 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Make JSON.parse faster by using table for fast string parsing
https://bugs.webkit.org/show_bug.cgi?id=221593
Reviewed by Ryosuke Niwa and Geoffrey Garen.
We use Latin1 table for quickly checking whether a character is safe for the fast path string parsing in JSON.
This offers 1-3% improvement in Kraken json-parse-financial test.
* parser/Lexer.cpp:
(JSC::Lexer<T>::Lexer):
* runtime/LiteralParser.cpp:
(JSC::LiteralParser<CharType>::Lexer::lex):
(JSC::isSafeStringCharacter):
(JSC::LiteralParser<CharType>::Lexer::lexString):
* runtime/LiteralParser.h:
2021-02-08 Patrick Angle <pangle@apple.com>
Web Inspector: Add `CSS.setLayoutContextTypeChangedMode` for getting information about all layout contexts
https://bugs.webkit.org/show_bug.cgi?id=221449
Reviewed by Devin Rousso.
Added `CSS.setLayoutContextTypeChangedMode` command and `CSS.LayoutContextTypeChangedMode` enum for controlling
if the frontend should be informed of all layout context type changes, or if only currently instrumented nodes
should be observed.
* inspector/protocol/CSS.json:
2021-02-08 Alicia Boya García <aboya@igalia.com>
Add ConsoleMessage::toString()
https://bugs.webkit.org/show_bug.cgi?id=221539
Reviewed by Eric Carlson.
Currently ConsoleMessage doesn't have a publicly API to retrieve the
stored JSON values into a string for printing.
The closest equivalent is message(), but it doesn't return any JSON
objects attached. This makes it an ill fit when printing
ConsoleMessage's to the system terminal, since these JSON values often
contain information that is important for debugging, e.g.:
SourceBufferPrivateGStreamer::removeCodedFrames(126493C320000001) removing sample (notice: no sample)
SourceBufferPrivateGStreamer::removeCodedFrames(126493C320000001) the range in removeCodedFrames() includes already enqueued samples, reenqueueing from (notice: no time)
This patch adds a new ConsoleMessage::toString() method that
constructs a String containing these JSON values, and makes use of it
when printing messages to the system terminal, giving more useful
output, e.g:
CONSOLE MEDIASOURCE DEBUG MediaSourcePrivateGStreamer::addSourceBuffer(D4447A9F1F483EEF) {"containerType":"video/webm","codecs":"codecs","profiles":"profiles"}
CONSOLE MEDIA LOG HTMLMediaElement::mediaPlayerDurationChanged(D4447A9F1F483EEF) duration = {"invalid":true,"numerator":-1,"denominator":1,"flags":0}, current time = {"value":0,"numerator":0,"denominator":10000000,"flags":1}
* inspector/ConsoleMessage.cpp:
(Inspector::ConsoleMessage::toString const):
* inspector/ConsoleMessage.h:
2021-02-08 Alicia Boya García <aboya@igalia.com>
ConsoleMessage: Don't encode string JSONLogValue's as JSON
https://bugs.webkit.org/show_bug.cgi?id=221421
Reviewed by Eric Carlson.
JSONLogValue's have two tagged types: String and JSON. Despite this,
the ConsoleMessage constructor was converting the string values to
JSON while coalescing them.
This also added quotes on the return value of message() for
ConsoleMessage's created with this constructor, but not with others.
This patch removes that behavior, keeping strings as strings and using
wrapObject() instead of wrapJSONString() for them.
* inspector/ConsoleMessage.cpp:
(Inspector::ConsoleMessage::ConsoleMessage):
(Inspector::ConsoleMessage::addToFrontend):
2021-02-07 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Replace toInteger with toIntegerOrInfinity
https://bugs.webkit.org/show_bug.cgi?id=218642
Reviewed by Alexey Shvayka.
In ECMA262 spec, ToInteger abstract operation is replaced with ToIntegerOrInfinity.
This patch renames toInteger to toIntegerOrInfinity in JSC.
* builtins/ArrayPrototype.js:
(fill):
(includes):
(copyWithin):
(flat):
(at):
* builtins/FunctionPrototype.js:
(bind):
* builtins/GlobalOperations.js:
(globalPrivate.toIntegerOrInfinity):
(globalPrivate.toLength):
(globalPrivate.toInteger): Deleted.
* builtins/RegExpPrototype.js:
(overriddenName.string_appeared_here.replace):
* builtins/StringPrototype.js:
(repeat):
(at):
* builtins/TypedArrayPrototype.js:
(subarray):
(at):
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::weakMapEntries):
(Inspector::JSInjectedScriptHost::weakSetEntries):
(Inspector::JSInjectedScriptHost::iteratorEntries):
* runtime/ArrayPrototype.cpp:
(JSC::argumentClampedIndexFromStartOrEnd):
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/IntlSegments.cpp:
(JSC::IntlSegments::containing):
* runtime/JSCJSValue.cpp:
(JSC::JSValue::toIntegerOrInfinity const):
(JSC::JSValue::toLength const):
(JSC::JSValue::toInteger const): Deleted.
* runtime/JSCJSValue.h:
* runtime/JSCJSValueInlines.h:
* runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
(JSC::argumentClampedIndexFromStartOrEnd):
(JSC::genericTypedArrayViewProtoFuncSet):
(JSC::genericTypedArrayViewProtoFuncLastIndexOf):
* runtime/NumberPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::extractToStringRadixArgument):
* runtime/RegExpObjectInlines.h:
(JSC::getRegExpObjectLastIndexAsUnsigned):
* runtime/StringPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::stringIndexOfImpl):
(JSC::stringIncludesImpl):
2021-02-06 Alexey Shvayka <shvaikalesh@gmail.com>
REGRESSION (r264574): Unchecked JS exception in validateAndApplyPropertyDescriptor()
https://bugs.webkit.org/show_bug.cgi?id=221494
Reviewed by Yusuke Suzuki.
This patch brings back exception check after sameValue(), which was accidentally
removed in r264574. sameValue() may throw OOM when comparing rope strings.
Even though this case was unreachable because of PropertyDescriptor::equalTo()
fast path, we should maintain consistent exception checks.
For the same reason, sameValue() in protoFuncFinalizationRegistryRegister() is
replaced with pointer comparison, which is safe & unobservable because `target`
is a known JSObject.
* runtime/FinalizationRegistryPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/JSObject.cpp:
(JSC::validateAndApplyPropertyDescriptor):
2021-02-05 Patrick Angle <pangle@apple.com>
Web Inspector: Implement backend support for maintaining a list of Grid layout contexts
https://bugs.webkit.org/show_bug.cgi?id=221228
Reviewed by Devin Rousso.
Added `CSS.LayoutContextType` property to `DOM.Node` and added `CSS.nodeLayoutContextTypeChanged` event.
* inspector/protocol/CSS.json:
- Added `CSS.LayoutContextType` type.
- Added `DOM.nodeLayoutContextTypeChanged` event.
* inspector/protocol/DOM.json:
- Added `layoutContextType` property to `DOM.Node` type.
2021-02-05 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, follow-up change after r272428
https://bugs.webkit.org/show_bug.cgi?id=221454
isPropertyNameExcluded can invoke GC etc. Structure::forEachProperty can miss PropertyTable and Structure
reference when it is highly optimized, so that it can crash if GC happens in the middle of Structure::forEachProperty.
1. Insert ensureStillAliveHere in Structure::forEachProperty to ensure liveness of PropertyTable
2. We should not perform side-effectful operation including GC in Structure::forEachProperty. So we moved isPropertyNameExcluded.
* runtime/StructureInlines.h:
(JSC::Structure::forEachProperty):
2021-02-05 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] globalFuncCopyDataProperties should not perform GC-sensitive operation in the middle of Structure::forEachProperty
https://bugs.webkit.org/show_bug.cgi?id=221454
Reviewed by Mark Lam.
isPropertyNameExcluded can invoke GC etc. And running Structure::forEachProperty
is fragile state against any side-effect including GC.
We should not perform GC-sensitive operation during Structure::forEachProperty.
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
2021-02-05 Alexey Shvayka <shvaikalesh@gmail.com>
Object.assign should throw for property creation on non-extensible `target`
https://bugs.webkit.org/show_bug.cgi?id=220712
Reviewed by Ross Kirsling.
This performance-neutral change precludes Object.assign from taking the
fast path if `target` is a non-extensible JSFinalObject, which ensures
a TypeError is thrown for property creation via [[Set]].
Aligns JSC with the spec [1], V8, and SpiderMonkey.
[1]: https://tc39.es/ecma262/#sec-validateandapplypropertydescriptor (step 2.a)
* runtime/ObjectConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
2021-02-05 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] JSImmutableButterfly's toString cache should not happen for generic join
https://bugs.webkit.org/show_bug.cgi?id=221444
<rdar://problem/73972862>
Reviewed by Mark Lam.
We should not cache Array#toString results with JSImmutableButterfly if
its join operation becomes generic join: including objects in array, since
this can invoke object.toString(), and it isn't side-effect free.
* runtime/ArrayPrototype.cpp:
(JSC::fastJoin):
(JSC::JSC_DEFINE_HOST_FUNCTION):
2021-02-05 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Atomics.store in DFG / FTL should return ToNumber(input) value
https://bugs.webkit.org/show_bug.cgi?id=221438
<rdar://problem/73973264>
Reviewed by Filip Pizlo.
Atomics.store is different from the other ReadModifyWrite atomics. It returns the input value without truncating it into TypedArray's requirement.
For example,
var u8 = new Uint8Array(8);
Atomics.store(u8, 0, 0xffff) === 0xffff // Not 0xff.
However DFG and FTL implementations do not handle it correctly.
This patch fixes AI, fixup, and code generations to handle this.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileGetByValOnIntTypedArray):
(JSC::DFG::SpeculativeJIT::getIntTypedArrayStoreOperandForAtomics):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileAtomicsReadModifyWrite):
(JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
(JSC::FTL::DFG::LowerDFGToB3::setIntTypedArrayLoadResult):
(JSC::FTL::DFG::LowerDFGToB3::toIntegerOrInfinity):
2021-02-04 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Implement Object.entries in C++
https://bugs.webkit.org/show_bug.cgi?id=221380
Reviewed by Alexey Shvayka.
This patch implements Object.entries in C++ because it is more efficient.
It is not using dynamic feature (like, calling a callback). And in C++,
we can avoid JSArray allocations for @Object.@getOwnPropertyNames.
This patch also removes unnecessary JS private functions, @propertyIsEnumerable,
and @getOwnPropertyNames.
* builtins/BuiltinNames.h:
* builtins/ObjectConstructor.js:
(entries): Deleted.
* bytecode/LinkTimeConstant.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/JSGlobalObjectFunctions.cpp:
* runtime/JSGlobalObjectFunctions.h:
* runtime/ObjectConstructor.cpp:
(JSC::ObjectConstructor::finishCreation):
(JSC::JSC_DEFINE_HOST_FUNCTION):
2021-02-03 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Insert PhantomLocal just before SetLocal for |this| to ensure liveness
https://bugs.webkit.org/show_bug.cgi?id=221353
<rdar://problem/70373862>
Reviewed by Saam Barati.
Let's consider the following case before SSA conversion.
BB#0:
SetArgumentDefinitely(this)
...
@a: SomethingFun()
MoveHint(@a, this)
SetLocal(@a, this)
Jump #1
BB#1:
...
ExitOK (this point)
...
@b: SomethingFun()
MoveHint(@b, this)
SetLocal(@b, this)
...
BB#2: (Catch entry point)
...
@c: SetArgumentDefinitely(this)
...
Jump #1
We have two entry points. And BB#0 sets @a to |this| while BB#2 does not update |this|, so it is using @c.
We have several patterns we can store |this|: arrow functions' |this| loading, derived constructors' |this| update. So we can see
SetLocal(@x, this) at arbitrary code points in CodeBlocks having them.
The problem is that DFG strongly assumed that |this| is initialized in the root basic block only once. So usually, we do not insert Flush/PhantomLocal for |this|.
But this is problematic when we can store |this| at arbitrary basic blocks since we do not properly insert Flush/PhantomLocal(this) in BB#1's just before Store.
Not inserting that in the above case makes |this| dead in BB#1's head liveness. Then we do not properly insert Phi(BB#0, BB#2) for |this|.
This is OK for non |this| locals since literally that local is not used at all in BB#1. But |this| is special since it is always live in bytecode.
So, OSR availability will be broken in the above graph: at ExitOK place, |this| must be live in bytecode. But |this| is pointing ConflictingFlush since
BB#0 says @a and BB#2 says @c while we do not have Phi.
The problem is that we do not keep liveness of |this| properly in BB#1. When setting a new |this|, we insert PhantomLocal to keep liveness so that appropriate Phi
will be inserted when two predecessors have different DFG nodes for |this|, and this graph can appear in arrow functions, derived constructors, and code with catch.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::setArgument):
* dfg/DFGVariableAccessDataDump.cpp:
(JSC::DFG::VariableAccessDataDump::dump const):
2021-02-01 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Atomics should support BigInt64Array / BigUint64Array
https://bugs.webkit.org/show_bug.cgi?id=221245
Reviewed by Keith Miller.
This patch adds BigInt64Array / BigUint64Array support for Atomics.
1. Atomics.store should be rewritten since it returns non-type-coerced result, so we cannot use atomicReadModifyWrite.
The spec also describes Atomics.store without using AtomicReadModifyWrite[1].
2. Extend Atomics.isLockFree to also accept a size of 8.
3. Currently, DFG / FTL handle Atomics + BigInt64Array/BigUint64Array as Array::Generic.
[1]: https://tc39.es/ecma262/#sec-atomics.store
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileAtomicsIsLockFree):
* runtime/AtomicsObject.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::atomicsWaitImpl):
(JSC::JSC_DEFINE_JIT_OPERATION):
* runtime/ToNativeFromValue.h:
(JSC::toNativeFromValue):
2021-02-03 Yusuke Suzuki <ysuzuki@apple.com>
[AppleWin 32bit][LLInt] LLIntData.h(104) : warning C4172: returning address of local variable or temporary: id
https://bugs.webkit.org/show_bug.cgi?id=220714
Reviewed by Mark Lam.
This patch fixes LLInt build when ENABLE(COMPUTED_GOTO_OPCODES) is false.
* llint/LLIntData.h:
(JSC::LLInt::getOpcode):
(JSC::LLInt::getOpcodeWide16):
(JSC::LLInt::getOpcodeWide32):
(JSC::LLInt::getOpcodeAddress):
(JSC::LLInt::getOpcodeWide16Address):
(JSC::LLInt::getOpcodeWide32Address):
(JSC::LLInt::getCodePtr):
(JSC::LLInt::getWide16CodePtr):
(JSC::LLInt::getWide32CodePtr):
2021-02-02 Ross Kirsling <ross.kirsling@sony.com>
Completion value of a finally block should not be ignored if completion is abrupt
https://bugs.webkit.org/show_bug.cgi?id=221238
Reviewed by Yusuke Suzuki.
Per https://tc39.es/ecma262/#sec-try-statement-runtime-semantics-evaluation,
the completion value of a finally block is ignored *just* when it is a normal completion,
but we've been ignoring it in all cases.
This patch ensures that when a finally block is exited with a break or continue statement,
its completion value is used as the completion value for the entire TryStatement.
(Note: This behavior will be important for the upcoming "do expressions" proposal,
as it is effectively a reification of completion values.)
* bytecompiler/NodesCodegen.cpp:
(JSC::TryNode::emitBytecode):
1. Don't throw away the result of evaluating the finally block.
2. Only use the try or catch block result if we make it all the way to the end of the finally block.
2021-02-02 Don Olmstead <don.olmstead@sony.com>
REGRESSION(r269309): [Cocoa] RemoteInspectorCocoa files are being compiled twice
https://bugs.webkit.org/show_bug.cgi?id=220951
<rdar://problem/73848263>
Reviewed by BJ Burg.
Refactor our SourcesCocoa files in JavaScriptCore to avoid double-listing
or double-building remote inspection-related files. Properly track
inspector/remote/SourcesCocoa.txt as a build dependency.
* JavaScriptCore.xcodeproj/project.pbxproj:
* Scripts/generate-unified-sources.sh:
* SourcesCocoa.txt:
2021-02-02 Xan Lopez <xan@igalia.com>
[JSC] Small cleanup in StackVisitor::readNonInlinedFrame
https://bugs.webkit.org/show_bug.cgi?id=221259
Reviewed by Yusuke Suzuki.
isAnyWasmCallee() will never be true if WebAssembly is disabled at
compile time, so we can move a good chunk of code inside the
USE(WEBASSEMBLY) check. Also move all constant initializations at
the beginning of the method, and remove an unnecessary extra
variable.
* interpreter/StackVisitor.cpp:
(JSC::StackVisitor::readNonInlinedFrame):
2021-02-02 BJ Burg <bburg@apple.com>
Web Inspector: implement the basics for showing/hiding grid overlays
https://bugs.webkit.org/show_bug.cgi?id=221062
Reviewed by Devin Rousso.
Add new commands to show and hide CSS grid overlays:
- DOM.showGridOverlay
- DOM.hideGridOverlay
* inspector/protocol/DOM.json:
2021-02-02 Adrian Perez de Castro <aperez@igalia.com>
Non-unified build fixes, late January 2021 edition
https://bugs.webkit.org/show_bug.cgi?id=221044
Unreviewed non-unified build fixes.
* wasm/WasmStreamingCompiler.cpp: Add missing WasmWorklist.h header.
* wasm/WasmStreamingCompiler.h: Add missing JSCJSValue.h header and forwars declarations
for JSGlobalObject, JSObject, and VM.
* wasm/WasmStreamingPlan.cpp: Add missing WasmLLIntPlan.h header.
* wasm/js/WebAssemblyGlobalConstructor.cpp: Add missing JSWebAssemblyHelpers.h and
JSWebAssemblyRuntimeError.h headers.
2021-02-01 Saam Barati <sbarati@apple.com>
Sign m_offset in AssemblerLabel
https://bugs.webkit.org/show_bug.cgi?id=221237
Reviewed by Mark Lam.
* assembler/ARM64Assembler.h:
(JSC::ARM64Assembler::labelForWatchpoint):
(JSC::ARM64Assembler::label):
(JSC::ARM64Assembler::getRelocatedAddress):
(JSC::ARM64Assembler::getDifferenceBetweenLabels):
(JSC::ARM64Assembler::getCallReturnOffset):
(JSC::ARM64Assembler::linkJump):
(JSC::ARM64Assembler::addressOf):
* assembler/ARMv7Assembler.h:
(JSC::ARMv7Assembler::labelForWatchpoint):
(JSC::ARMv7Assembler::label):
(JSC::ARMv7Assembler::getRelocatedAddress):
(JSC::ARMv7Assembler::getDifferenceBetweenLabels):
(JSC::ARMv7Assembler::getCallReturnOffset):
(JSC::ARMv7Assembler::linkJump):
(JSC::ARMv7Assembler::linkCall):
(JSC::ARMv7Assembler::linkPointer):
* assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::Jump::link const):
(JSC::AbstractMacroAssembler::Jump::linkTo const):
* assembler/AssemblerBuffer.h:
(JSC::AssemblerLabel::AssemblerLabel):
(JSC::AssemblerLabel::operator=):
(JSC::AssemblerLabel::isSet const):
(JSC::AssemblerLabel::labelAtOffset const):
(JSC::AssemblerLabel::operator== const):
(JSC::AssemblerLabel::offset const):
(JSC::AssemblerLabel::setOffset):
* assembler/LinkBuffer.h:
(JSC::LinkBuffer::offsetOf):
(JSC::LinkBuffer::applyOffset):
* assembler/MIPSAssembler.h:
(JSC::MIPSAssembler::labelForWatchpoint):
(JSC::MIPSAssembler::label):
(JSC::MIPSAssembler::getRelocatedAddress):
(JSC::MIPSAssembler::getDifferenceBetweenLabels):
(JSC::MIPSAssembler::getCallReturnOffset):
(JSC::MIPSAssembler::linkJump):
(JSC::MIPSAssembler::linkCall):
(JSC::MIPSAssembler::linkPointer):
* assembler/X86Assembler.h:
(JSC::X86Assembler::labelForWatchpoint):
(JSC::X86Assembler::label):
(JSC::X86Assembler::linkJump):
(JSC::X86Assembler::linkCall):
(JSC::X86Assembler::linkPointer):
(JSC::X86Assembler::getCallReturnOffset):
(JSC::X86Assembler::getRelocatedAddress):
(JSC::X86Assembler::getDifferenceBetweenLabels):
2021-02-01 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] TypedArray#fill should be implemented in C++
https://bugs.webkit.org/show_bug.cgi?id=221182
Reviewed by Ross Kirsling.
Since TypedArray#fill does not invoke callbacks, implementing it in C++ is better.
This removes several utility functions exposed in JS for TypedArray#fill implementation,
and makes TypedArray#fill simple.
* builtins/BuiltinNames.h:
* builtins/TypedArrayPrototype.js:
(globalPrivate.typedArrayClampArgumentToStartOrEnd): Deleted.
(fill): Deleted.
* bytecode/LinkTimeConstant.h:
* runtime/JSArrayBufferView.cpp:
(JSC::validateTypedArray):
* runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
(JSC::genericTypedArrayViewProtoFuncFill):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/JSGlobalObjectFunctions.cpp:
* runtime/JSGlobalObjectFunctions.h:
* runtime/JSTypedArrayViewPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::JSTypedArrayViewPrototype::finishCreation):
* runtime/JSTypedArrayViewPrototype.h:
2021-02-01 Saam Barati <sbarati@apple.com>
Lazily create m_windowCloseWatchpoints so we don't mistakenly think we have a frame when re-associating a document to a given cached frame
https://bugs.webkit.org/show_bug.cgi?id=221098
<rdar://72894454>
Reviewed by Ryosuke Niwa and Mark Lam.
* bytecode/AccessCase.cpp:
(JSC::AccessCase::commit):
* bytecode/Watchpoint.h:
(JSC::WatchpointSet::isStillValidOnJSThread const):
* runtime/PropertySlot.h:
(JSC::PropertySlot::setWatchpointSet):
2021-01-31 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Implement BigInt64Array and BigUint64Array
https://bugs.webkit.org/show_bug.cgi?id=190800
Reviewed by Ross Kirsling.
This patch implements BigInt64Array and BigUint64Array.
1. In this patch, we do not support BigInt64Array/BigUint64Array + Atomics yet.
2. We make canGetIndexQuickly false for BigInt64Array and BigUint64Array. And we
use generic path for getting values from BigInt64Array and BigUint64Array. We
will optimize it in [1] and [2]. But possibly, this does not have super large
impact on performance since getting value from BigInt64Array and BigUint64Array
are already costly since we always need to allocate BigInt for results.
3. DFG / FTL GetByVal etc. are using Array::Generic for BigInt64Array and BigUint64Array.
4. But GetArrayLength, CheckArray, byteLength getter etc. are using Array::BigInt64Array / Array::BigUint64Array
for optimization.
5. Extend ArrayProfile's ArrayMode for BigInt64Array and BigUint64Array so that ArrayProfile
can record BigInt64Array and BigUint64Array information.
6. Implement DataView#{setBigInt64,setBigUint64,getBigInt64,getBigUint64}.
7. Extend JSC APIs to support BigInt64Array and BigUint64Array.
[1]: https://bugs.webkit.org/show_bug.cgi?id=221181
[2]: https://bugs.webkit.org/show_bug.cgi?id=221183
* API/JSTypedArray.cpp:
(toJSTypedArrayType):
(toTypedArrayType):
(createTypedArray):
* API/JSValueRef.h:
* API/tests/TypedArrayCTest.cpp:
(forEachTypedArrayType):
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* builtins/BuiltinNames.h:
* builtins/TypedArrayPrototype.js:
(fill):
(map):
(filter):
* bytecode/ArrayProfile.cpp:
(JSC::dumpArrayModes):
* bytecode/ArrayProfile.h:
* bytecode/ByValInfo.h:
(JSC::jitArrayModeForClassInfo):
(JSC::jitArrayModePermitsPut):
(JSC::typedArrayTypeForJITArrayMode):
* bytecode/LinkTimeConstant.h:
* bytecode/SpeculatedType.cpp:
(JSC::dumpSpeculation):
(JSC::speculationToAbbreviatedString):
(JSC::speculationFromTypedArrayType):
(JSC::typedArrayTypeFromSpeculation):
(JSC::speculationFromString):
* bytecode/SpeculatedType.h:
(JSC::isBigInt64ArraySpeculation):
(JSC::isBigUint64ArraySpeculation):
(JSC::isDirectArgumentsSpeculation):
(JSC::isScopedArgumentsSpeculation):
(JSC::isActionableIntMutableArraySpeculation): Deleted.
(JSC::isActionableFloatMutableArraySpeculation): Deleted.
(JSC::isActionableTypedMutableArraySpeculation): Deleted.
(JSC::isActionableMutableArraySpeculation): Deleted.
(JSC::isActionableArraySpeculation): Deleted.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGArrayMode.cpp:
(JSC::DFG::ArrayMode::fromObserved):
(JSC::DFG::ArrayMode::refine const):
(JSC::DFG::ArrayMode::alreadyChecked const):
(JSC::DFG::arrayTypeToString):
(JSC::DFG::toTypedArrayType):
(JSC::DFG::toArrayType):
(JSC::DFG::permitsBoundsCheckLowering):
* dfg/DFGArrayMode.h:
(JSC::DFG::ArrayMode::supportsSelfLength const):
(JSC::DFG::ArrayMode::arrayModesThatPassFiltering const):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGOperations.cpp:
(JSC::DFG::JSC_DEFINE_JIT_OPERATION):
* dfg/DFGOperations.h:
(JSC::DFG::operationNewTypedArrayWithSizeForType):
(JSC::DFG::operationNewTypedArrayWithOneArgumentForType):
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileHasIndexedProperty):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
(JSC::FTL::DFG::LowerDFGToB3::compilePutByVal):
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::subtype):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::privateCompilePutByVal):
* jit/Repatch.cpp:
(JSC::tryCacheArrayGetByVal):
* llint/LowLevelInterpreter.asm:
* runtime/AtomicsObject.cpp:
* runtime/AtomicsObject.h:
* runtime/BigInt64Array.h: Copied from Source/JavaScriptCore/runtime/JSTypedArrayConstructors.cpp.
* runtime/BigUint64Array.h: Copied from Source/JavaScriptCore/runtime/JSTypedArrayConstructors.cpp.
* runtime/JSArrayBufferView.cpp:
(JSC::elementSize):
(JSC::validateTypedArray):
* runtime/JSArrayBufferView.h:
* runtime/JSBigInt.h:
* runtime/JSCell.h:
* runtime/JSDataView.h:
* runtime/JSDataViewPrototype.cpp:
(JSC::getData):
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/JSGenericTypedArrayView.h:
* runtime/JSGenericTypedArrayViewConstructor.h:
* runtime/JSGenericTypedArrayViewConstructorInlines.h:
(JSC::constructGenericTypedArrayViewWithArguments):
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::setWithSpecificType):
(JSC::JSGenericTypedArrayView<Adaptor>::set):
(JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlotByIndex):
* runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
(JSC::genericTypedArrayViewProtoFuncJoin):
(JSC::genericTypedArrayViewProtoFuncSlice):
(JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/JSGlobalObjectFunctions.h:
* runtime/JSType.cpp:
(WTF::printInternal):
* runtime/JSType.h:
* runtime/JSTypedArrayConstructors.cpp:
* runtime/JSTypedArrayConstructors.h:
* runtime/JSTypedArrayPrototypes.cpp:
* runtime/JSTypedArrayPrototypes.h:
* runtime/JSTypedArrayViewPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/JSTypedArrayViewPrototype.h:
* runtime/JSTypedArrays.cpp:
* runtime/JSTypedArrays.h:
* runtime/ToNativeFromValue.h:
(JSC::toNativeFromValue):
(JSC::toNativeFromValueWithoutCoercion):
* runtime/TypedArrayAdaptors.h:
(JSC::IntegralTypedArrayAdaptor::toJSValue):
(JSC::FloatTypedArrayAdaptor::toJSValue):
(JSC::BigIntTypedArrayAdaptor::toJSValue):
(JSC::BigIntTypedArrayAdaptor::toNativeFromInt32):
(JSC::BigIntTypedArrayAdaptor::toNativeFromUint32):
(JSC::BigIntTypedArrayAdaptor::toNativeFromDouble):
(JSC::BigIntTypedArrayAdaptor::convertTo):
(JSC::Uint8ClampedAdaptor::toJSValue):
(JSC::IntegralTypedArrayAdaptor::toDouble): Deleted.
(JSC::FloatTypedArrayAdaptor::toDouble): Deleted.
(JSC::Uint8ClampedAdaptor::toDouble): Deleted.
* runtime/TypedArrayType.cpp:
(JSC::constructorClassInfoForType):
(WTF::printInternal):
* runtime/TypedArrayType.h:
(JSC::isBigIntTypedView):
(JSC::logElementSize):
(JSC::isBigInt):
(JSC::isSigned):
(JSC::contentType):
* runtime/TypedArrays.h:
* runtime/VM.cpp:
* runtime/VM.h:
2021-02-01 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Add @ in Error.stack if URL exists
https://bugs.webkit.org/show_bug.cgi?id=221184
Reviewed by Keith Miller.
Append '@' if URL exists even if function name does not exist to make the
format simple for parsing in JS (splitting with '@' to extract URL and function name).
* runtime/StackFrame.cpp:
(JSC::StackFrame::toString const):
2021-01-30 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, fix after r272071
https://bugs.webkit.org/show_bug.cgi?id=220914
Since WebAssembly.Global can be "immutable", we cannot use Wasm::Global::set when setting an initial value.
* wasm/js/WebAssemblyGlobalConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
2021-01-29 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Adjust property order of host JSFunction
https://bugs.webkit.org/show_bug.cgi?id=221168
Reviewed by Darin Adler.
We should first define "length" before "name".
This will be included in upcoming test262 update[1].
[1]: https://github.com/tc39/test262/pull/2921
* runtime/JSFunction.cpp:
(JSC::JSFunction::finishCreation):
2021-01-29 Keith Miller <keith_miller@apple.com>
SourceParseMode should be a member of the JSC::Parser
https://bugs.webkit.org/show_bug.cgi?id=221149
Reviewed by Ross Kirsling.
Right now we pass the SourceParseMode as a argument to many of the
functions in the parser. This patch move it into a member on the
class. This will make it available deeper in the parser, which is
important for implementing top level await.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::Parser):
(JSC::Parser<LexerType>::parseInner):
(JSC::Parser<LexerType>::parseModuleSourceElements):
(JSC::Parser<LexerType>::parseAsyncFunctionSourceElements):
(JSC::Parser<LexerType>::parseAsyncGeneratorFunctionSourceElements):
(JSC::Parser<LexerType>::parseFunctionBody):
(JSC::Parser<LexerType>::parseFunctionParameters):
(JSC::Parser<LexerType>::parseFunctionInfo):
(JSC::Parser<LexerType>::parseFunctionDeclaration):
(JSC::Parser<LexerType>::parseAsyncFunctionDeclaration):
(JSC::Parser<LexerType>::parseClass):
(JSC::Parser<LexerType>::parseProperty):
(JSC::Parser<LexerType>::parsePropertyMethod):
(JSC::Parser<LexerType>::parseGetterSetter):
(JSC::Parser<LexerType>::parseFunctionExpression):
(JSC::Parser<LexerType>::parseAsyncFunctionExpression):
(JSC::Parser<LexerType>::parseArrowFunctionExpression):
* parser/Parser.h:
(JSC::Parser::sourceParseMode const):
(JSC::Parser<LexerType>::parse):
(JSC::parse):
(JSC::parseFunctionForFunctionConstructor):
2021-01-29 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, internal build fix after r272082
https://bugs.webkit.org/show_bug.cgi?id=221147
* runtime/Options.cpp:
(JSC::canUseJITCage):
2021-01-29 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Add com.apple.private.securejit entitlement for JITCage
https://bugs.webkit.org/show_bug.cgi?id=221147
Reviewed by Keith Miller.
Add com.apple.private.securejit only for iOS, used for JITCage.
* entitlements.plist:
* runtime/Options.cpp:
(JSC::canUseJITCage):
2021-01-29 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Fix WebAssembly.Global's error message and support "funcref"
https://bugs.webkit.org/show_bug.cgi?id=221157
Reviewed by Keith Miller.
Since it accepts "anyfunc" and "externref", we should update the error message.
And we should support "funcref" too.
* wasm/js/WebAssemblyGlobalConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* wasm/js/WebAssemblyTableConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
2021-01-29 Dmitry Bezhetskov <dbezhetskov@igalia.com>
[WASM-References] Enable reference types by default
https://bugs.webkit.org/show_bug.cgi?id=220890
Reviewed by Yusuke Suzuki.
Enable wasm reference types by default.
* runtime/OptionsList.h:
2021-01-29 Dmitry Bezhetskov <dbezhetskov@igalia.com>
[JSC] WebAssembly.Global should support Funcref and Externref
https://bugs.webkit.org/show_bug.cgi?id=220914
Reviewed by Yusuke Suzuki.
Allow using reference types in ctor of WebAssembly.Global
according to the spec
https://webassembly.github.io/reference-types/js-api/index.html#dom-global-global.
* wasm/js/WebAssemblyGlobalConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
2021-01-29 David Kilzer <ddkilzer@apple.com>
check-webkit-style: warn about WTF::BlockPtr use in JavaScriptCore until ARC is enabled
<https://webkit.org/b/221108>
<rdar://problem/73726640>
Reviewed by Joseph Pecoraro.
* API/JSVirtualMachine.mm:
* inspector/remote/RemoteConnectionToTarget.h:
- Remove or replace unused <wtf/BlockPtr.h> headers.
2021-01-28 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Add JSPromise::rejectedPromise
https://bugs.webkit.org/show_bug.cgi?id=221077
Reviewed by Mark Lam.
This patch adds JSPromise::rejectedPromise static function which can return newly created rejected promise.
The benefit of this function is that it avoids calling JS functions internally. It is efficient, fast, plus,
we can ensure that no JS related error happens (stack-overflow, terminated-execution errors).
* builtins/PromiseOperations.js:
* runtime/JSPromise.cpp:
(JSC::JSPromise::rejectedPromise):
* runtime/JSPromise.h:
* wasm/js/JSWebAssembly.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
2021-01-27 Yusuke Suzuki <ysuzuki@apple.com>
WebAssembly: add support for stream APIs
https://bugs.webkit.org/show_bug.cgi?id=173105
Reviewed by Keith Miller.
This patch implements WebAssembly.{compileStreaming,instantiateStreaming}. JavaScriptCore offers Wasm::StreamingCompiler interface to WebCore,
so that WebCore can feed FetchResponse and compile wasm code in a streaming fashion.
Wasm::StreamingCompiler drives Wasm::LLIntPlan while it does not use Wasm::Worklist since currently Wasm::Worklist is not suitable abstraction for
streaming compilation which generates compilation tasks incrementally. Instead, Wasm::StreamingCompiler generates Wasm::StreamingPlan and enqueues
them to Wasm::Worklist, and each StreamingPlan compiles one function at a time. And we gather these compiled functions into the one LLIntPlan and
finally Wasm::StreamingCompiler completes Wasm::LLIntPlan.
We already have Wasm::StreamingParser, which is designed for streaming compilation. We can pass bytes to this parser, and this parser invokes a callback
when a new wasm function is found. Then, Wasm::StreamingCompiler generates Wasm::StreamingPlan for that.
We add WasmStreamingCompiler JS objects to JSC shell to test streaming compilation easily.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* builtins/WebAssembly.js:
(compileStreaming):
(instantiateStreaming):
* runtime/DeferredWorkTimer.cpp:
(JSC::DeferredWorkTimer::cancelPendingWork):
* runtime/DeferredWorkTimer.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/JSGlobalObject.h:
* runtime/OptionsList.h:
* tools/JSDollarVM.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::JSDollarVM::finishCreation):
* wasm/WasmBBQPlan.cpp:
(JSC::Wasm::BBQPlan::BBQPlan):
* wasm/WasmBBQPlan.h:
* wasm/WasmCodeBlock.cpp:
(JSC::Wasm::CodeBlock::CodeBlock):
* wasm/WasmEntryPlan.cpp:
(JSC::Wasm::EntryPlan::EntryPlan):
* wasm/WasmEntryPlan.h:
* wasm/WasmLLIntPlan.cpp:
(JSC::Wasm::LLIntPlan::LLIntPlan):
(JSC::Wasm::LLIntPlan::didCompleteCompilation):
(JSC::Wasm::LLIntPlan::completeInStreaming):
(JSC::Wasm::LLIntPlan::didCompileFunctionInStreaming):
(JSC::Wasm::LLIntPlan::didFailInStreaming):
* wasm/WasmLLIntPlan.h:
* wasm/WasmModule.cpp:
(JSC::Wasm::Module::validateSync):
(JSC::Wasm::Module::validateAsync):
* wasm/WasmStreamingCompiler.cpp: Added.
(JSC::Wasm::StreamingCompiler::StreamingCompiler):
(JSC::Wasm::StreamingCompiler::~StreamingCompiler):
(JSC::Wasm::StreamingCompiler::create):
(JSC::Wasm::StreamingCompiler::didReceiveFunctionData):
(JSC::Wasm::StreamingCompiler::didCompileFunction):
(JSC::Wasm::StreamingCompiler::didFinishParsing):
(JSC::Wasm::StreamingCompiler::completeIfNecessary):
(JSC::Wasm::StreamingCompiler::didComplete):
(JSC::Wasm::StreamingCompiler::finalize):
(JSC::Wasm::StreamingCompiler::fail):
(JSC::Wasm::StreamingCompiler::cancel):
* wasm/WasmStreamingCompiler.h: Added.
* wasm/WasmStreamingParser.cpp:
* wasm/WasmStreamingParser.h:
* wasm/WasmStreamingPlan.cpp: Copied from Source/JavaScriptCore/builtins/WebAssembly.js.
(JSC::Wasm::StreamingPlan::StreamingPlan):
(JSC::Wasm::StreamingPlan::work):
* wasm/WasmStreamingPlan.h: Copied from Source/JavaScriptCore/wasm/js/JSWebAssembly.h.
* wasm/js/JSWebAssembly.cpp:
(JSC::JSWebAssembly::finishCreation):
(JSC::JSWebAssembly::instantiateForStreaming):
(JSC::JSC_DEFINE_HOST_FUNCTION):
* wasm/js/JSWebAssembly.h:
2021-01-27 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Avoid using DirectCall when executable is wasm function
https://bugs.webkit.org/show_bug.cgi?id=221055
Reviewed by Keith Miller.
This is a partial patch from https://bugs.webkit.org/show_bug.cgi?id=220339, which is reverted because of Facebook crash.
For now, we just avoid using DirectCall to wasm functions so that normal Call will be used, and it is efficient. This
patch avoids JetStream2 regression.
* dfg/DFGOperations.cpp:
(JSC::DFG::JSC_DEFINE_JIT_OPERATION):
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
* jit/JITOperations.cpp:
(JSC::virtualForWithFunction):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::setUpCall):
* runtime/Intrinsic.cpp:
(JSC::intrinsicName):
* runtime/Intrinsic.h:
* wasm/js/WebAssemblyFunction.cpp:
(JSC::WebAssemblyFunction::create):
2021-01-27 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, rebaselining builtin generator test result files
https://bugs.webkit.org/show_bug.cgi?id=221028
* Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Combined.js-result:
* Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
2021-01-27 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r271186.
https://bugs.webkit.org/show_bug.cgi?id=221051
Breaks Facebook on arm64e devices
Reverted changeset:
"[JSC] DFG/FTL DirectCall need to respect Wasm IC"
https://bugs.webkit.org/show_bug.cgi?id=220339
https://trac.webkit.org/changeset/271186
2021-01-27 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Remove InspectorInstrumentation object
https://bugs.webkit.org/show_bug.cgi?id=221028
Reviewed by Ryosuke Niwa.
Remove InspectorInstrumentation since it is not used. We would like to clean up Promise's rejection path.
* CMakeLists.txt:
* DerivedSources-input.xcfilelist:
* DerivedSources-output.xcfilelist:
* DerivedSources.make:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Scripts/tests/builtins/JavaScriptCore-Builtin.Promise-Combined.js:
(rejectPromise):
(fulfillPromise):
* Scripts/tests/builtins/JavaScriptCore-Builtin.Promise-Separate.js:
(rejectPromise):
(fulfillPromise):
* Scripts/tests/builtins/expected/JavaScriptCore-Builtin.Promise-Separate.js-result:
* Sources.txt:
* builtins/BuiltinNames.h:
* builtins/InspectorInstrumentationObject.js: Removed.
* builtins/PromiseOperations.js:
(globalPrivate.rejectPromise):
(globalPrivate.fulfillPromise):
* bytecode/LinkTimeConstant.h:
* runtime/InspectorInstrumentationObject.cpp: Removed.
* runtime/InspectorInstrumentationObject.h: Removed.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
2021-01-26 Dmitry Bezhetskov <dbezhetskov@igalia.com>
[WASM-References] Change default value for externref's tables from null to undefined
https://bugs.webkit.org/show_bug.cgi?id=220918
Reviewed by Yusuke Suzuki.
Update reference types tests to satisfy the spec:
Externref's tables default value should be undefined.
* wasm/js/JSWebAssemblyHelpers.h:
(JSC::defaultValueForTable):
* wasm/js/WebAssemblyTableConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* wasm/js/WebAssemblyTablePrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
2021-01-25 Simon Fraser <simon.fraser@apple.com>
Crash when remote inspecting in debug builds
https://bugs.webkit.org/show_bug.cgi?id=220956
<rdar://73379637>
Reviewed by Devin Rousso.
Convert RemoteConnectionToTarget from using BlockPtr<> to Function<> because BlockPtr<>
was triggering crashes which seem to be related to mixing ARC and non-ARC code.
* inspector/remote/RemoteConnectionToTarget.h:
* inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm:
(Inspector::RemoteTargetHandleRunSourceGlobal):
(Inspector::RemoteTargetQueueTaskOnGlobalQueue):
(Inspector::RemoteTargetHandleRunSourceWithInfo):
(Inspector::RemoteConnectionToTarget::dispatchAsyncOnTarget):
(Inspector::RemoteConnectionToTarget::setup):
(Inspector::RemoteConnectionToTarget::close):
(Inspector::RemoteConnectionToTarget::sendMessageToTarget):
(Inspector::RemoteConnectionToTarget::queueTaskOnPrivateRunLoop):
(Inspector::RemoteConnectionToTarget::takeQueue):
2021-01-25 Alexey Shvayka <shvaikalesh@gmail.com>
REGRESSION (r270874): Some React Native apps are reported broken on iOS
https://bugs.webkit.org/show_bug.cgi?id=220809
Reviewed by Saam Barati.
r270874 fixed for/in shadowing issue by introducing an invariant: a property
returned by getOwn*PropertyNames() in DontEnumPropertiesMode::Exclude should be
reported as [[Enumerable]] by getOwnPropertySlot(). Otherwise, for/in skips the
property, which causes RN apps to break.
Since there is no way to enforce this invariant for opaque API objects like
JSCallbackObject, this change skips [[Enumerable]] check for them by introducing
GetOwnPropertySlotMayBeWrongAboutDontEnum out of line type info flag.
Also, this patch reverts JSCallbackObject::getOwnPropertySlot() changes of r270874
that are no longer necessary and observable (via Object.getOwnPropertyDescriptor).
* API/JSCallbackObject.h:
* API/JSCallbackObjectFunctions.h:
(JSC::JSCallbackObject<Parent>::getOwnPropertySlot):
* API/tests/testapiScripts/testapi.js:
* runtime/JSObject.cpp:
(JSC::JSObject::hasEnumerableProperty const):
* runtime/JSTypeInfo.h:
(JSC::TypeInfo::getOwnPropertySlotMayBeWrongAboutDontEnum const):
2021-01-25 Chris Dumez <cdumez@apple.com>
Update availability annotations to match the macOS 11.0 and iOS 14.0 GM SDKs
https://bugs.webkit.org/show_bug.cgi?id=220874
<rdar://73474368>
Reviewed by Darin Adler.
* API/JSContextPrivate.h:
* API/JSContextRefPrivate.h:
2021-01-23 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] DeferredWorkTimer should clear pending task after running
https://bugs.webkit.org/show_bug.cgi?id=220888
Reviewed by Mark Lam.
Wasm code assumes that scheduleWorkSoon clears pending dependencies. But DeferredWorkTimer is not clearing it, and instead, FinalizationRegistry etc. is clearing
it explicitly. This semantics is problematic. We are putting cancelPendingWork in JSPromise::resolve / JSPromise::reject. But they do not work since this is C++
version of them, and JSPromise has JS version of them. And if JS version is called, cancelPendingWork is not called. And we do not want to complicate JSPromise's
reject / resolve path since this is super hot, and we should keep them in JS.
Instead, we should always clear pending task if it is called.
* jsc.cpp:
(JSC_DEFINE_HOST_FUNCTION):
* runtime/DeferredWorkTimer.cpp:
(JSC::DeferredWorkTimer::doWork):
* runtime/DeferredWorkTimer.h:
* runtime/JSFinalizationRegistry.cpp:
(JSC::JSFinalizationRegistry::finalizeUnconditionally):
* runtime/JSPromise.cpp:
(JSC::JSPromise::resolve): Remove this work-around, and instead, we must call scheduleWorkSoon if addPendingWork is called.
(JSC::JSPromise::reject): Ditto.
* wasm/js/JSWebAssembly.cpp:
(JSC::JSWebAssembly::webAssemblyModuleValidateAsync):
(JSC::instantiate): Use instance for Ticket instead of promise to disambiguate the ticket scheduling from compileAndInstantiate's one easily.
(JSC::compileAndInstantiate): There are path that we do not call scheduleWorkSoon while we call addPendingWork, this is wrong, and JSPromise's workaround is added to
alleviate this situation. We should not do that: we must call scheduleWorkSoon at some point if addPendingWork is called.
(JSC::JSWebAssembly::webAssemblyModuleInstantinateAsync):
2021-01-23 Xan Lopez <xan@igalia.com>
[JSC] Allow to build WebAssembly without B3
https://bugs.webkit.org/show_bug.cgi?id=220365
Reviewed by Yusuke Suzuki.
Make all the B3 related code in WebAssembly a compile-time
option. When disabled WebAssembly will only use its LLInt tier.
* llint/LLIntOfflineAsmConfig.h: define WEBASSEMBLY_B3JIT for the
offline assembler.
* llint/WebAssembly.asm: guard B3 code inside WEBASSEMBLY_B3JTI ifdefs.
* wasm/WasmAirIRGenerator.cpp: ditto.
* wasm/WasmAirIRGenerator.h: ditto.
* wasm/WasmB3IRGenerator.cpp: ditto.
* wasm/WasmB3IRGenerator.h: ditto.
* wasm/WasmBBQPlan.cpp: ditto.
* wasm/WasmBBQPlan.h: ditto.
* wasm/WasmCallee.h: ditto.
* wasm/WasmCodeBlock.cpp:
(JSC::Wasm::CodeBlock::CodeBlock): ditto.
* wasm/WasmCodeBlock.h:
(JSC::Wasm::CodeBlock::wasmEntrypointCalleeFromFunctionIndexSpace): ditto.
* wasm/WasmLLIntGenerator.h: ditto.
* wasm/WasmLLIntPlan.cpp: ditto.
* wasm/WasmOMGForOSREntryPlan.cpp: ditto.
* wasm/WasmOMGForOSREntryPlan.h: ditto.
* wasm/WasmOMGPlan.cpp: ditto.
* wasm/WasmOMGPlan.h: ditto.
* wasm/WasmOSREntryData.h: ditto.
* wasm/WasmOperations.cpp: ditto.
* wasm/WasmOperations.h: ditto.
* wasm/WasmPlan.cpp: ditto.
* wasm/WasmPlan.h: ditto.
* wasm/WasmSlowPaths.cpp: ditto.
* wasm/WasmSlowPaths.h: ditto.
* wasm/WasmThunks.cpp: ditto.
* wasm/WasmThunks.h: ditto.
* wasm/WasmTierUpCount.cpp: ditto.
* wasm/WasmTierUpCount.h: ditto.
* wasm/generateWasmOpsHeader.py: ditto.
2021-01-22 Yusuke Suzuki <ysuzuki@apple.com>
Should SharedArrayBuffer/WebAssembly.Memory really throw?
https://bugs.webkit.org/show_bug.cgi?id=220364
Reviewed by Mark Lam.
Not accessing "shared" field if Options::useSharedArrayBuffer() is false.
* wasm/js/WebAssemblyMemoryConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
2021-01-22 Keith Miller <keith_miller@apple.com>
Obj-C API should do correct type checks when using a 32-bit address space
https://bugs.webkit.org/show_bug.cgi?id=220880
<rdar://72370334>
Reviewed by Tadeu Zagallo.
* API/JSValue.mm:
(-[JSValue isNull]):
(-[JSValue isBoolean]):
(-[JSValue isNumber]):
(-[JSValue isString]):
2021-01-22 Yusuke Suzuki <ysuzuki@apple.com>
REGRESSION (r271731): Unchecked JS exception under GlobalObject::moduleLoaderFetch
https://bugs.webkit.org/show_bug.cgi?id=220868
Reviewed by Mark Lam.
Because TerminatedExecutionError needs to be uncaught, CatchScope's semantics does not work well.
So, we extend ThrowScope to implement CatchScope's feature, and use ThrowScope etc.
We also add JSPromise::rejectWithCaughtException since this pattern is common enough.
* API/JSAPIGlobalObject.mm:
(JSC::JSAPIGlobalObject::moduleLoaderImportModule):
(JSC::JSAPIGlobalObject::moduleLoaderFetch):
* jsc.cpp:
(GlobalObject::moduleLoaderImportModule):
(GlobalObject::moduleLoaderFetch):
* runtime/Completion.cpp:
(JSC::rejectPromise):
(JSC::loadAndEvaluateModule):
(JSC::loadModule):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/JSInternalPromise.cpp:
(JSC::JSInternalPromise::rejectWithCaughtException):
* runtime/JSInternalPromise.h:
* runtime/JSModuleLoader.cpp:
(JSC::JSModuleLoader::importModule):
(JSC::JSModuleLoader::resolve):
(JSC::JSModuleLoader::fetch):
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::reject): Deleted.
* runtime/JSPromise.cpp:
(JSC::JSPromise::rejectWithCaughtException):
* runtime/JSPromise.h:
* runtime/ThrowScope.h:
(JSC::ThrowScope::clearException):
* wasm/js/JSWebAssembly.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::resolve):
(JSC::JSWebAssembly::webAssemblyModuleValidateAsync):
(JSC::instantiate):
(JSC::compileAndInstantiate):
(JSC::JSWebAssembly::webAssemblyModuleInstantinateAsync):
(JSC::reject): Deleted.
(JSC::webAssemblyModuleValidateAsyncInternal): Deleted.
(JSC::webAssemblyModuleInstantinateAsyncInternal): Deleted.
2021-01-22 Mark Lam <mark.lam@apple.com>
Disable Options:useAtMethod because of compatibility issue.
https://bugs.webkit.org/show_bug.cgi?id=220788
rdar://72933608
Reviewed by Saam Barati and Yusuke Suzuki.
See https://github.com/tc39/proposal-relative-indexing-method/issues/41.
* jsc.cpp:
(CommandLine::parseArguments):
- enable Options::useAtMethod by default for the jsc shell for testing.
* runtime/OptionsList.h:
2021-01-21 Devin Rousso <drousso@apple.com>
[Apple Pay] use the first item in `shippingOptions` even when it's not `selected`
https://bugs.webkit.org/show_bug.cgi?id=220810
Reviewed by Andy Estes.
* inspector/protocol/Console.json:
* runtime/ConsoleTypes.h:
* inspector/ConsoleMessage.cpp:
(Inspector::messageSourceValue):
* runtime/ConsoleClient.cpp:
(JSC::appendMessagePrefix):
Add a new `PaymentRequest` value to the `ChannelSource` enum.
2021-01-21 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] JSPromise should not propagate TerminatedExecutionError
https://bugs.webkit.org/show_bug.cgi?id=220820
<rdar://problem/72929399>
Reviewed by Mark Lam.
TerminatedExecutionError is uncatcheable exception to finish JS execution as soon as possible.
We should not propagate TerminatedExecutionError in JSPromise's rejection.
In this patch, we do not reject promise if exception is TerminatedExecutionError.
* API/JSAPIGlobalObject.mm:
(JSC::JSAPIGlobalObject::moduleLoaderImportModule):
(JSC::JSAPIGlobalObject::moduleLoaderFetch):
* API/JSContext.mm:
(-[JSContext evaluateJSScript:]):
* jsc.cpp:
(GlobalObject::moduleLoaderImportModule):
(GlobalObject::moduleLoaderFetch):
(runWithOptions):
* runtime/Completion.cpp:
(JSC::rejectPromise):
(JSC::loadAndEvaluateModule):
(JSC::loadModule):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/JSModuleLoader.cpp:
(JSC::reject):
(JSC::JSModuleLoader::importModule):
(JSC::JSModuleLoader::resolve):
(JSC::JSModuleLoader::fetch):
(JSC::JSC_DEFINE_HOST_FUNCTION):
* wasm/js/JSWebAssembly.cpp:
(JSC::reject):
2021-01-19 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, fix GCC warnings
https://bugs.webkit.org/show_bug.cgi?id=220718
* dfg/DFGOperations.cpp:
(JSC::DFG::tierUpCommon):
2021-01-19 Lauro Moura <lmoura@igalia.com>
REGRESSION(r271580) [GTK] LTS/Debian build failure due to unsupported g-ir-scanner parameter
https://bugs.webkit.org/show_bug.cgi?id=220730
Reviewed by Philippe Normand.
No new behavior. No new tests.
* PlatformGTK.cmake: Expose --sources-top-dirs only if available.
2021-01-19 Adrian Perez de Castro <aperez@igalia.com>
Non-unified build fixes, mid January 2021 edition
https://bugs.webkit.org/show_bug.cgi?id=220725
Unreviewed non-unified build fixes.
* runtime/JSObject.cpp:
(JSC::JSObject::getNonReifiedStaticPropertyNames): Remove inline function from here,
as it is used in JSPropertyNameEnumerator.cpp and the compiler needs to see the function
body to be able to inline it, otherwise linking fails.
* runtime/JSObjectInlines.h:
(JSC::JSObject::getNonReifiedStaticPropertyNames): Moved inline function here.
* wasm/WasmInstance.cpp: Add missing JSWebAssemblyHelpers.h header.
* wasm/js/WebAssemblyModuleRecord.cpp: Add missing ObjectConstructor.h header.
2021-01-18 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] FTL::prepareOSREntry can clear OSR entry CodeBlock if it is already invalidated
https://bugs.webkit.org/show_bug.cgi?id=220718
<rdar://problem/70527068>
Reviewed by Mark Lam.
FTL::prepareOSREntry can clear OSR entry CodeBlock if it is already invalidated. However, the caller is not assuming that,
and it calls clearOSREntryBlockAndResetThresholds again. And clearOSREntryBlockAndResetThresholds's assertion hit.
This patch correctly handles the invalidated case.
* dfg/DFGOperations.cpp:
(JSC::DFG::tierUpCommon):
2021-01-18 Xan López <xan@igalia.com>
[JSC] Implement a B3::Compilation replacement for wasm-llint
https://bugs.webkit.org/show_bug.cgi?id=220585
Reviewed by Yusuke Suzuki.
Move B3Compilation, B3OpaqueByproducts and B3OpaqueByproduct to
jit/. They are used by non-B3 code and they are not really B3
specific. Also rename B3CompilationPtrTag to JITCompilationPtrTag.
* CMakeLists.txt: add new source files.
* JavaScriptCore.xcodeproj/project.pbxproj: ditto.
* Sources.txt: ditto.
* b3/B3Compile.cpp:
(JSC::B3::compile): use JITCompilationPtrTag.
* b3/B3Compile.h: change includes.
* b3/B3DataSection.h: ditto.
* b3/B3Procedure.cpp: ditto.
* b3/B3Procedure.h: ditto.
* b3/air/testair.cpp: use JITCompilationPtrTag.
* b3/testb3.h: change includes.
(invoke):
* b3/testb3_6.cpp:
(testInterpreter): use JITCompilationPtrTag.
(testEntrySwitchSimple): ditto.
(testEntrySwitchNoEntrySwitch): ditto.
(testEntrySwitchWithCommonPaths): ditto.
(testEntrySwitchWithCommonPathsAndNonTrivialEntrypoint): ditto.
(testEntrySwitchLoop): ditto.
* ftl/FTLJITCode.h: use JSC::OpaqueByproducts.
* ftl/FTLOutput.h: change includes.
* jit/JITCompilation.cpp: Renamed from Source/JavaScriptCore/b3/B3Compilation.cpp.
(JSC::Compilation::Compilation):
* jit/JITCompilation.h: Renamed from Source/JavaScriptCore/b3/B3Compilation.h.
(JSC::Compilation::code const):
(JSC::Compilation::codeRef const):
* jit/JITOpaqueByproduct.h: Renamed from Source/JavaScriptCore/b3/B3OpaqueByproduct.h.
* jit/JITOpaqueByproducts.cpp: Renamed from Source/JavaScriptCore/b3/B3OpaqueByproducts.cpp.
* jit/JITOpaqueByproducts.h: Renamed from Source/JavaScriptCore/b3/B3OpaqueByproducts.h.
* runtime/JSCPtrTag.h: rename B3CompilationPtrTag to JITCompilationPtrTag.
* wasm/WasmB3IRGenerator.h: use JSC::OpaqueByproducts.
* wasm/WasmBBQPlan.cpp: use JSC::Compilation.
(JSC::Wasm::BBQPlan::work):
(JSC::Wasm::BBQPlan::didCompleteCompilation):
* wasm/WasmBinding.h: change includes.
* wasm/WasmCallee.h: ditto.
* wasm/WasmFormat.h: use JSC::Compilation.
* wasm/WasmLLIntPlan.cpp: ditto.
(JSC::Wasm::LLIntPlan::didCompleteCompilation):
* wasm/WasmLLIntPlan.h: use JITCompilationPtrTag.
* wasm/WasmModule.h: ditto.
* wasm/WasmOMGForOSREntryPlan.cpp: use JSC::Compilation.
(JSC::Wasm::OMGForOSREntryPlan::work):
* wasm/WasmOMGPlan.cpp: ditto.
(JSC::Wasm::OMGPlan::work):
* wasm/WasmParser.h: change includes.
* wasm/js/WasmToJS.h: ditto.
2021-01-18 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] earlyReturnFromInfiniteLoopsLimit should check all caller functions when emitting
https://bugs.webkit.org/show_bug.cgi?id=220700
<rdar://problem/71229150>
Reviewed by Mark Lam.
earlyReturnFromInfiniteLoopsLimit does not return when the function is builtin. But this does not consider about the case that
the caller is inlining and the caller is builtin. Since this returns from entire DFG / FTL functions, we should check any of
callers are not builtin functions too.
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileLoopHint):
2021-01-18 Mark Lam <mark.lam@apple.com>
[AppleWin 32bit] LLInt C Loop: LowLevelInterpreter.cpp(90,7): error C2653: 'WebConfig': is not a class or namespace name
https://bugs.webkit.org/show_bug.cgi?id=220405
Reviewed by Fujii Hironori.
Add a missing #if ENABLE(UNIFIED_AND_FREEZABLE_CONFIG_RECORD).
* llint/LowLevelInterpreter.cpp:
2021-01-18 Michael Catanzaro <mcatanzaro@gnome.org>
[GTK] Multilib conflicts in gir files
https://bugs.webkit.org/show_bug.cgi?id=220636
Reviewed by Carlos Garcia Campos.
* PlatformGTK.cmake:
2021-01-18 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] callerIsOMGCompiled should be robust
https://bugs.webkit.org/show_bug.cgi?id=220697
Reviewed by Mark Lam.
This function did not work if this function is called from microtask / unhandled rejection since there is no caller frame.
This patch makes this function more robust against such usage.
* jsc.cpp:
(JSC_DEFINE_HOST_FUNCTION):
2021-01-17 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] DFG/FTL Atomics should not accept Float32/Float64 typed arrays
https://bugs.webkit.org/show_bug.cgi?id=220692
<rdar://problem/73238369>
Reviewed by Mark Lam.
We accidentally accept Float32/Float64 typed arrays. We should accept only integer TypedArrays (Int8, Uint8, ... etc.)
as specified in [1]. If the other types come, we just make it Array::Generic and call slow path which can handle them.
[1]: https://tc39.es/ecma262/#sec-validateintegertypedarray
* dfg/DFGArrayMode.h:
(JSC::DFG::ArrayMode::isOneOfTypedArrayView const): Deleted.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
2021-01-17 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] FTL OSR entry FlushFormat array is reversed
https://bugs.webkit.org/show_bug.cgi?id=220695
<rdar://problem/72930932>
Reviewed by Mark Lam.
After r268783, FlushFormat array is erroneously sorted in reversed order.
This patch fixes that.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::lower):
2021-01-17 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] GenericArguments<Type>::defineOwnProperty's assumption about error is not correct
https://bugs.webkit.org/show_bug.cgi?id=220693
<rdar://problem/72929171>
Reviewed by Mark Lam.
Any function taking JSGlobalObject* can cause out-of-memory error potentially. And we have a way to invoke it.
But GenericArguments<Type>::defineOwnProperty didn't assume OutOfMemory error. This patch fixes it.
* runtime/GenericArgumentsInlines.h:
(JSC::GenericArguments<Type>::defineOwnProperty):
2021-01-17 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Add some more exception checks in globalFuncCopyDataProperties
https://bugs.webkit.org/show_bug.cgi?id=220691
Reviewed by Mark Lam.
This patch add some missing exception checks in globalFuncCopyDataProperties to fix tests attached in this patch.
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
2021-01-17 Yusuke Suzuki <ysuzuki@apple.com>
Add JSC API configuring GC signals in Linux
https://bugs.webkit.org/show_bug.cgi?id=220641
Reviewed by Mark Lam.
Add JSConfigureSignalForGC function for Linux and FreeBSD (non Apple, non Windows platforms).
* API/JSBase.cpp:
(JSConfigureSignalForGC):
* API/JSBasePrivate.h:
2021-01-15 Alexey Proskuryakov <ap@apple.com>
Build fixes with newer clang
https://bugs.webkit.org/show_bug.cgi?id=220679
Reviewed by Mark Lam.
Class needs type casting to be used as map key in Objective-C. After https://reviews.llvm.org/D67983,
Objective-C++ also requires this (see discussion there for why it's OK to just cast).
* API/JSWrapperMap.mm: (-[JSWrapperMap classInfoForClass:]):
2021-01-15 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Clean up DFGPreciseLocalClobberize to avoid duplicate code
https://bugs.webkit.org/show_bug.cgi?id=220670
Reviewed by Filip Pizlo.
This patch cleans up DFGPreciseLocalClobberize by extracting code to lambda to remove duplicate code.
* dfg/DFGPreciseLocalClobberize.h:
(JSC::DFG::PreciseLocalClobberizeAdaptor::readTop):
2021-01-14 Ross Kirsling <ross.kirsling@sony.com>
[JSC] Correctly handle escaped keyword identifiers
https://bugs.webkit.org/show_bug.cgi?id=220634
Reviewed by Yusuke Suzuki.
When `let`, `await`, and `yield` are accepted as identifiers, they should be accepted even in escaped form.
This patch ensures this behavior for variable, parameter, and label names.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::isArrowFunctionParameters):
(JSC::Parser<LexerType>::parseStatementListItem):
(JSC::Parser<LexerType>::parseVariableDeclarationList):
(JSC::Parser<LexerType>::parseFormalParameters):
(JSC::Parser<LexerType>::parseFunctionInfo):
(JSC::Parser<LexerType>::parseClass):
(JSC::Parser<LexerType>::parseAssignmentExpression):
(JSC::Parser<LexerType>::parsePrimaryExpression):
Make use of new parser functions.
* parser/Parser.h:
(JSC::isContextualKeyword): Renamed from isAnyContextualKeyword.
(JSC::Parser::matchSpecIdentifier): Allow escaped contextual keywords.
(JSC::Parser::matchIdentifierOrPossiblyEscapedContextualKeyword): Added.
(JSC::Parser::isAllowedIdentifierLet): Renamed from isLETMaskedAsIDENT.
(JSC::Parser::isPossiblyEscapedLet): Added.
(JSC::Parser::isDisallowedIdentifierAwait): Added.
(JSC::Parser::isAllowedIdentifierAwait): Added.
(JSC::Parser::isPossiblyEscapedAwait): Added.
(JSC::Parser::canUseIdentifierAwait): Added.
(JSC::Parser::isDisallowedIdentifierYield): Added.
(JSC::Parser::isAllowedIdentifierYield): Renamed from isYIELDMaskedAsIDENT.
(JSC::Parser::isPossiblyEscapedYield): Added.
(JSC::Parser::canUseIdentifierYield): Added.
(JSC::Parser::matchAllowedEscapedContextualKeyword): Added.
(JSC::Parser::disallowedIdentifierAwaitReason): Fix mistake (left over from previous patch).
(JSC::isIdentifierOrAnyContextualKeyword): Deleted.
(JSC::isSafeContextualKeyword): Deleted.
(JSC::Parser::isDisallowedIdentifierLet): Deleted.
* parser/ParserTokens.h:
Remove obsolete notion of "safe contextual keyword".
2021-01-14 Xan Lopez <xan@igalia.com>
[JSC] Implement a B3::ValueRep replacement for wasm-llint
https://bugs.webkit.org/show_bug.cgi?id=220412
Reviewed by Yusuke Suzuki.
The LLInt code in WebAssembly uses B3::ValueRep to store
information about the calling convention for functions. We will
use instead a new class with just enough functionality for those
needs (basically, whether a value in a function call will be in a
register or the stack) and convert to B3::ValueRep when
transitioning into B3/Air. This is part of the work needed to
allow WebAssembly to work without B3, and eventually in
interpreted mode only.
* Sources.txt: add new sources.
* b3/B3ValueRep.h:
(JSC::B3::ValueRep::ValueRep): include WasmValueLocation.h and add
a method to convert B3::ValueRep to Wasm::ValueLocation.
* JavaScriptCore.xcodeproj/project.pbxproj: add new sources.
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::emitCallPatchpoint): covert existing Wasm::ValueLocation into B3::ValueRep.
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::createCallPatchpoint): ditto.
* wasm/WasmCallingConvention.h:
(JSC::Wasm::CallInformation::computeResultsOffsetList): use Wasm::ValueLocation.
* wasm/WasmOperations.cpp:
(JSC::Wasm::JSC_DEFINE_JIT_OPERATION): ditto.
* wasm/WasmValueLocation.cpp: new class, basically B3::ValueRep
without all the stuff we don't need in WasmLLInt.
(JSC::Wasm::ValueLocation::dump const):
(WTF::printInternal):
* wasm/WasmValueLocation.h: ditto.
(JSC::Wasm::ValueLocation::ValueLocation):
(JSC::Wasm::ValueLocation::reg):
(JSC::Wasm::ValueLocation::stack):
(JSC::Wasm::ValueLocation::stackArgument):
(JSC::Wasm::ValueLocation::kind const):
(JSC::Wasm::ValueLocation::isReg const):
(JSC::Wasm::ValueLocation::reg const):
(JSC::Wasm::ValueLocation::isGPR const):
(JSC::Wasm::ValueLocation::isFPR const):
(JSC::Wasm::ValueLocation::gpr const):
(JSC::Wasm::ValueLocation::fpr const):
(JSC::Wasm::ValueLocation::isStack const):
(JSC::Wasm::ValueLocation::offsetFromFP const):
(JSC::Wasm::ValueLocation::isStackArgument const):
(JSC::Wasm::ValueLocation::offsetFromSP const):
* wasm/js/JSToWasm.cpp:
(JSC::Wasm::marshallJSResult): use Wasm::ValueLocation.
2021-01-14 Saam Barati <sbarati@apple.com>
SpeculativeJIT::compileGetEnumerableLength should not use GPRFlushedCallResult
https://bugs.webkit.org/show_bug.cgi?id=220557
Reviewed by Yusuke Suzuki.
It wasn't used as the result from a call, so we're overly restricting the
register we allocate for no good reason.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileGetEnumerableLength):
2021-01-14 Saam Barati <sbarati@apple.com>
Baseline JIT should emit mutatorFence after inline allocations
https://bugs.webkit.org/show_bug.cgi?id=220572
Reviewed by Yusuke Suzuki.
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_new_object):
(JSC::JIT::emit_op_create_this):
2021-01-13 Xan Lopez <xan@igalia.com>
[JSC] Remove the unused compilation byproducts from the wasm embedder entrypoint
https://bugs.webkit.org/show_bug.cgi?id=220587
Reviewed by Yusuke Suzuki.
This is just passed around uninitialized, remove it.
* wasm/WasmB3IRGenerator.h:
* wasm/WasmBBQPlan.cpp:
(JSC::Wasm::BBQPlan::didCompleteCompilation):
2021-01-12 Ross Kirsling <ross.kirsling@sony.com>
[JSC] Class name 'await' is valid in sync context
https://bugs.webkit.org/show_bug.cgi?id=220575
Reviewed by Yusuke Suzuki.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseClass):
Check for valid 'await'.
* parser/Parser.h:
(JSC::Parser::isDisallowedIdentifierAwait):
Fix mistake -- we care if the containing function is async, we don't care about being *at* function scope.
2021-01-12 Ross Kirsling <ross.kirsling@sony.com>
[JSC] Class names must be lexed as strict mode code
https://bugs.webkit.org/show_bug.cgi?id=220567
Reviewed by Yusuke Suzuki.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseClass):
Don't lex next token until *after* we've set up the class scope.
2021-01-12 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Bypass OperationPtrTagging for JITCage verification for CallDOMGetter
https://bugs.webkit.org/show_bug.cgi?id=220564
Reviewed by Saam Barati.
CustomAccessorPtrTag functions are not registered ones for JITCage since we are using C++ trampoline to invoke them.
However, we do not want to use this trampoline in x64 due to performance issue. So we would like to call these
functions directly from JIT while they are not registered (And this is OK in JITCage since they are called from trampoline).
In this patch we bypass OperationPtrTagging by using WTF::tagNativeCodePtrImpl directly for non JITCage case.
* dfg/DFGJITCompiler.h:
(JSC::DFG::JITCompiler::appendOperationCall):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCallDOMGetter):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculativeJIT::appendOperationCall):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCallDOMGetter):
(JSC::FTL::DFG::LowerDFGToB3::vmCall):
* ftl/FTLOutput.h:
(JSC::FTL::Output::operation):
* tools/JSDollarVM.cpp:
2021-01-12 Caio Lima <ticaiolima@gmail.com>
[ESNext] super accesses broken on arrow functions defined as class field
https://bugs.webkit.org/show_bug.cgi?id=220558
Reviewed by Darin Adler.
We need to properly set `isClassContext` for class fields
initialization.
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::generateUnlinkedFunctionCodeBlock):
2021-01-12 Don Olmstead <don.olmstead@sony.com>
Non-unified build fixes mid January 2021 edition
https://bugs.webkit.org/show_bug.cgi?id=220560
Unreviewed non-unified build fixes.
* API/JSLockRef.cpp:
* runtime/JSCJSValue.cpp:
* runtime/JSGlobalObjectFunctions.cpp:
2021-01-11 Devin Rousso <drousso@apple.com>
Web Inspector: Debugger: allow breakpoint actions to be evaluated as a user gesture
https://bugs.webkit.org/show_bug.cgi?id=200275
Reviewed by Brian Burg.
* inspector/protocol/Debugger.json:
* debugger/Breakpoint.h:
Add an optional `emulateUserGesture` property to `Debugger.BreakpointAction`.
* debugger/Debugger.h:
(JSC::Debugger::Client::debuggerScopeExtensionObject): Renamed from `scopeExtensionObject`.
(JSC::Debugger::Client::debuggerWillEvaluate): Added.
(JSC::Debugger::Client::debuggerDidEvaluate): Added.
* debugger/Debugger.cpp:
(JSC::Debugger::evaluateBreakpointCondition):
(JSC::Debugger::evaluateBreakpointActions):
Consult the `Debugger::Client` before and after evaluating each `Breakpoint::Action`.
Currently this is used by `WebCore::PageDebuggerAgent` to push onto or pop from a stack of
`WebCore::UserGestureEmulationScope`, each corresponding to a `Breakpoint::Action` that
has been set with `emulateUserGesture`.
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::parseBreakpointOptions):
(Inspector::InspectorDebuggerAgent::debuggerScopeExtensionObject): Renamed from `scopeExtensionObject`.
2021-01-10 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] JITCage's Gate mechanism is used in ARM64E even if JITCage is disable
https://bugs.webkit.org/show_bug.cgi?id=220500
Reviewed by Mark Lam.
We should ensure that Gate mechanism just works even if ENABLE(JIT_CAGE) is OFF in ARM64E since
in LLInt we are always using Gate even if ENABLE(JIT_CAGE) is OFF. It makes LLInt code
significantly simpler: we do not want to have multiple implementations for ARM64E for ENABLE(JIT_CAGE) ON/OFF
in LLInt if it is not necessary in terms of performance. And it didn't cause performance regression.
So for simplicity, we are always using Gate in LLInt.
However, when disabling ENABLE(JIT_CAGE), we accidentally disabled Gate mechanism too in LLInt.
It makes ARM64E broken if ENABLE(JIT_CAGE) is OFF. This patch makes Gate work even if ENABLE(JIT_CAGE) is OFF,
and this is the expected design.
* llint/LLIntData.cpp:
(JSC::LLInt::initialize):
* llint/LLIntEntrypoint.cpp:
(JSC::LLInt::setFunctionEntrypoint):
(JSC::LLInt::setEvalEntrypoint):
(JSC::LLInt::setProgramEntrypoint):
(JSC::LLInt::setModuleProgramEntrypoint):
* llint/LLIntThunks.cpp:
* llint/LLIntThunks.h:
2021-01-08 Alexey Shvayka <shvaikalesh@gmail.com>
Implement @copyDataProperties in C++ to optimize object rest / spread
https://bugs.webkit.org/show_bug.cgi?id=193618
Reviewed by Yusuke Suzuki.
Since @copyDataProperties is inherently polymorphic, implementing it in JS is not beneficial.
This patch:
1. Merges almost identical @copyDataProperties variants and moves them to C++, avoiding
allocations of JSArray instances and Identifier wrappers.
2. Skips non-observable [[Get]] calls, leveraging `slot.isTaintedByOpaqueObject()`.
3. Performs [[DefineOwnProperty]] via putDirectMayBeIndex(), since the spec guarantees
property creation to be successful [1]: `target` is an newly created object that is
not yet accessible to userland code. It's impossible for `target` to be non-extensible
nor have a non-configurable property.
4. Introduces a fast path similar to Object.assign, but:
a) with no checks on `target`, because it's guaranteed to be an extensible JSFinalObject;
b) with less checks on `source`, since we are performing putDirect() and don't care about
read-only properties nor __proto__.
Altogether, these changes result in 3.1x speed-up for object rest / spread.
Also, this patch removes unnecessary `target` return and @isObject check.
[1]: https://tc39.es/ecma262/#sec-copydataproperties (step 6.c.ii.2, note the "!" prefix)
* builtins/BuiltinNames.h:
* builtins/GlobalOperations.js:
(globalPrivate.speciesConstructor):
(globalPrivate.copyDataProperties): Deleted.
(globalPrivate.copyDataPropertiesNoExclusions): Deleted.
* bytecode/BytecodeIntrinsicRegistry.h:
* bytecode/LinkTimeConstant.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::ObjectPatternNode::bindValue const):
(JSC::ObjectSpreadExpressionNode::emitBytecode):
(JSC::BytecodeIntrinsicNode::emit_intrinsic_defineEnumerableWritableConfigurableDataProperty): Deleted.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::canPerformFastPropertyEnumerationForCopyDataProperties):
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/JSGlobalObjectFunctions.h:
2021-01-08 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Disable JITCage compile time in old iOS
https://bugs.webkit.org/show_bug.cgi?id=220477
Reviewed by Darin Adler.
* runtime/Gate.h: This is required in LLInt ARM64E.
* runtime/Options.cpp:
2021-01-08 Alexey Proskuryakov <ap@apple.com>
JavaScriptCore API headers contain project style includes
https://bugs.webkit.org/show_bug.cgi?id=220449
rdar://problem/71493605
Reviewed by Yusuke Suzuki.
* API/JSStringRefCF.h:
* API/JavaScriptCore.h:
2021-01-08 Alexey Shvayka <shvaikalesh@gmail.com>
for/in over a Proxy should not call [[GetOwnProperty]] trap twice per property
https://bugs.webkit.org/show_bug.cgi?id=189034
Reviewed by Yusuke Suzuki.
Although the spec [1] doesn't normatively require calling [[GetOwnProperty]]
only once per property, this is what V8 and SpiderMonkey do.
Since [[Enumerable]] property attribute is checked by has_enumerable_property
bytecode op, this patch avoids another observable [[GetOwnProperty]] call
by using DontEnumPropertiesMode::Include exclusively for Proxy objects.
A side effect of this change: if a property becomes [[Enumerable]] after
[[OwnPropertyKeys]] trap was called, it will be enumerated, which matches
the spec [2] and developer expectations.
This patch advances provided microbenchmark by 100%.
[1]: https://tc39.es/ecma262/#sec-enumerate-object-properties
[2]: https://tc39.es/ecma262/#sec-%foriniteratorprototype%.next (step 7.b.iii)
* runtime/JSPropertyNameEnumerator.cpp:
(JSC::getEnumerablePropertyNames):
2021-01-08 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, add missing scope.release() in JSModuleNamespaceObject
https://bugs.webkit.org/show_bug.cgi?id=220465
* runtime/JSModuleNamespaceObject.cpp:
(JSC::JSModuleNamespaceObject::getOwnPropertyNames):
2021-01-08 Dmitry Bezhetskov <dbezhetskov@igalia.com>
[WASM-References] Add optional default value parameter for Table.constructor, Table.grow and Table.set
https://bugs.webkit.org/show_bug.cgi?id=220323
Reviewed by Yusuke Suzuki.
Introduce the new optional parameter "defaultValue" for Table.grow(numOfElementsToAdd, [defaultValue]).
It is used to initialize newly added table elements.
Introduce the new optional parameter "defaultValue" for Table({initial: N, element:type}, [defaultValue]).
After Table is created we append initial times defaultValue to table if it is present.
Also add type check for funcref's table for Table.grow, Table ctor and Table.set.
Spec: https://webassembly.github.io/reference-types/js-api/index.html#tables.
* wasm/WasmOperations.cpp:
(JSC::Wasm::JSC_DEFINE_JIT_OPERATION):
* wasm/WasmTable.cpp:
(JSC::Wasm::Table::grow):
* wasm/WasmTable.h:
(JSC::Wasm::Table::isFuncrefTable const):
* wasm/js/JSWebAssemblyTable.cpp:
(JSC::JSWebAssemblyTable::grow):
* wasm/js/JSWebAssemblyTable.h:
* wasm/js/WebAssemblyTableConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* wasm/js/WebAssemblyTablePrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
2021-01-08 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] AtomicsIsLockFree's AI result is wrong
https://bugs.webkit.org/show_bug.cgi?id=220452
<rdar://problem/71228690>
Reviewed by Mark Lam.
The result type should be SpecBoolean. This leads to FTL unreachable in the test code.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2021-01-07 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] DFG/FTL Atomics should assume non-typed-array input with storage-edge
https://bugs.webkit.org/show_bug.cgi?id=220451
<rdar://problem/71237065>
Reviewed by Mark Lam.
Atomics implementation assumed that it only gets TypedArray via checkArray filter if storage-edge exists. But this is wrong.
String and the other cases can put storage-edge while it is not TypedArray. We should check whether this is one of TypedArray,
and if it is not, we should make it generic one instead of using fast TypedArray path.
* dfg/DFGArrayMode.h:
(JSC::DFG::ArrayMode::isOneOfTypedArrayView const):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
2021-01-07 Mark Lam <mark.lam@apple.com>
Work around Clang bug in __builtin_return_address().
https://bugs.webkit.org/show_bug.cgi?id=220432
rdar://71648468
Reviewed by Yusuke Suzuki.
Clang's __builtin_return_address() currently sometimes returns a PAC signed pointer
and sometimes not. This patch works around that by always ensuring that the pointer
is not signed.
Also changed the ReturnAddressPtr to store a signed pointer.
* assembler/MacroAssemblerCodeRef.h:
(JSC::ReturnAddressPtr::ReturnAddressPtr):
(JSC::ReturnAddressPtr::untaggedValue const):
(JSC::MacroAssemblerCodePtr::MacroAssemblerCodePtr):
* interpreter/AbstractPC.h:
(JSC::AbstractPC::AbstractPC):
* interpreter/CallFrame.h:
* jit/JIT.cpp:
(JSC::ctiPatchCallByReturnAddress):
* jit/JITOpcodes.cpp:
(JSC::JIT::privateCompileHasIndexedProperty):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::privateCompileHasIndexedProperty):
* jit/JITOperations.cpp:
(JSC::JSC_DEFINE_JIT_OPERATION):
(JSC::unprofiledMul): Deleted.
(JSC::profiledMul): Deleted.
(JSC::unprofiledSub): Deleted.
(JSC::profiledSub): Deleted.
* jit/JITPropertyAccess.cpp:
(JSC::JIT::privateCompilePutByVal):
(JSC::JIT::privateCompilePutPrivateNameWithCachedId):
(JSC::JIT::privateCompilePutByValWithCachedId):
* runtime/JSCPtrTag.h:
2021-01-07 Alexey Shvayka <shvaikalesh@gmail.com>
[JSC] Simplify get*PropertyNames() methods and EnumerationMode
https://bugs.webkit.org/show_bug.cgi?id=212954
Reviewed by Yusuke Suzuki.
Before this change, [[OwnPropertyKeys]] overrides were sometimes implemented
inconsistently, via different get*PropertyNames() methods that duplicated logic
(e.g. ErrorInstance, RegExpObject, and StringObject).
This patch:
1. Introduces a clear convention to implement [[OwnPropertyKeys]] overrides:
if it's defined by the spec, getOwnPropertyNames() method is used; otherwise,
non-materialized properties are enumerated / reified in getOwnSpecialPropertyNames().
While no class should define both methods, we don't assert this to support inheritance.
Removes getOwnNonIndexPropertyNames() from the method table and converts it to instance
method; its overrides were renamed to getOwnSpecialPropertyNames() and exempted from
calling the no-op base method.
This approach was chosen, instead of getOwnNonIndexPropertyNames() override, because
for/in enumeration must be sure there are no enumerable properties between
getEnumerableLength() and the first structure property.
Also, removes getStructurePropertyNames() from the method table as it's unreasonable
to override it.
2. Extracts JSObject::getOwnIndexPropertyNames() instance method to enforce
correct enumeration order in getOwnPropertyNames() overrides: special indices =>
butterfly storage => special properties => non-reified static => structure properties.
Loose mode `arguments` were fixed to enumerate indices from butterfly storage before
special properties [1], aligning JSC with V8 and SpiderMonkey.
3. Reworks for/in enumeration so the special properties always come before structure ones,
aligning enumeration order of String objects [2] and typed arrays [3] that have expando
properties with the spec, V8, and SpiderMonkey.
Removes getPropertyNames() and getGenericPropertyNames() from the method table, along
with their overrides, because ES7 disabled customization of for/in enumeration [4].
Instead, JSObject::getPropertyNames() instance method and getEnumerablePropertyNames()
are introduced, featuring a loop instead of recursion.
Also, this enabled dropping hard-to-follow JSObjectPropertiesMode bit and simplifying
EnumerationMode to an enum.
for/in and Object.keys microbenchmarks are neutral. This change does not affect
JSPropertyNameEnumerator caching, nor fast paths of its bytecodes.
[1]: https://tc39.es/ecma262/#sec-createmappedargumentsobject (steps 15-16 and 20-21)
[2]: https://tc39.es/ecma262/#sec-string-exotic-objects-ownpropertykeys
[3]: https://tc39.es/ecma262/#sec-integer-indexed-exotic-objects-ownpropertykeys
[4]: https://github.com/tc39/ecma262/pull/367
* API/JSAPIValueWrapper.h:
Remove OverridesAnyFormOfGetPropertyNames structure flag as it should never be queried
from JSCell instances.
* API/JSCallbackObject.h:
* API/JSCallbackObjectFunctions.h:
(JSC::JSCallbackObject<Parent>::getOwnSpecialPropertyNames):
(JSC::JSCallbackObject<Parent>::getOwnNonIndexPropertyNames): Deleted.
* API/JSObjectRef.cpp:
(JSObjectCopyPropertyNames):
* bindings/ScriptValue.cpp:
(Inspector::jsToInspectorValue):
* bytecode/ObjectAllocationProfileInlines.h:
(JSC::ObjectAllocationProfileBase<Derived>::possibleDefaultPropertyCount):
Use DontEnumPropertyMode::Include as the intent is to count all properties, even
private symbols. EnumerationMode() defaults did exclude non-enumerable properties.
* debugger/DebuggerScope.cpp:
(JSC::DebuggerScope::getOwnPropertyNames):
* debugger/DebuggerScope.h:
* runtime/ClassInfo.h:
* runtime/ClonedArguments.cpp:
(JSC::ClonedArguments::getOwnSpecialPropertyNames):
Don't materialize DontEnum properties unless it's DontEnumPropertiesMode::Include,
advancing provided microbenchmark by ~23%.
(JSC::ClonedArguments::getOwnPropertyNames): Deleted.
* runtime/ClonedArguments.h:
* runtime/EnumerationMode.h:
Explicitly specify enum type to reduce its size.
(JSC::EnumerationMode::EnumerationMode): Deleted.
(JSC::EnumerationMode::includeDontEnumProperties): Deleted.
(JSC::EnumerationMode::includeJSObjectProperties): Deleted.
* runtime/ErrorInstance.cpp:
(JSC::ErrorInstance::getOwnSpecialPropertyNames):
Don't materialize DontEnum properties unless it's DontEnumPropertiesMode::Include,
advancing provided microbenchmark by a factor of 5.
(JSC::ErrorInstance::getOwnNonIndexPropertyNames): Deleted.
(JSC::ErrorInstance::getStructurePropertyNames): Deleted.
* runtime/ErrorInstance.h:
* runtime/GenericArguments.h:
* runtime/GenericArgumentsInlines.h:
(JSC::GenericArguments<Type>::getOwnPropertyNames):
* runtime/JSArray.cpp:
(JSC::JSArray::getOwnSpecialPropertyNames):
(JSC::JSArray::getOwnNonIndexPropertyNames): Deleted.
* runtime/JSArray.h:
* runtime/JSCell.cpp:
(JSC::JSCell::getOwnPropertyNames):
(JSC::JSCell::getOwnSpecialPropertyNames):
(JSC::JSCell::getOwnNonIndexPropertyNames): Deleted.
(JSC::JSCell::getPropertyNames): Deleted.
(JSC::JSCell::getStructurePropertyNames): Deleted.
(JSC::JSCell::getGenericPropertyNames): Deleted.
* runtime/JSCell.h:
* runtime/JSFunction.cpp:
(JSC::JSFunction::getOwnSpecialPropertyNames):
(JSC::JSFunction::getOwnNonIndexPropertyNames): Deleted.
* runtime/JSFunction.h:
* runtime/JSGenericTypedArrayView.h:
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertyNames):
* runtime/JSGlobalObject.h:
Remove OverridesAnyFormOfGetPropertyNames structure flag as it's inherited from
JSSymbolTableObject, and JSGlobalObject itself doesn't override getOwn*PropertyNames().
* runtime/JSLexicalEnvironment.cpp:
(JSC::JSLexicalEnvironment::getOwnSpecialPropertyNames):
(JSC::JSLexicalEnvironment::getOwnNonIndexPropertyNames): Deleted.
* runtime/JSLexicalEnvironment.h:
* runtime/JSModuleEnvironment.cpp:
(JSC::JSModuleEnvironment::getOwnSpecialPropertyNames):
(JSC::JSModuleEnvironment::getOwnNonIndexPropertyNames): Deleted.
* runtime/JSModuleEnvironment.h:
* runtime/JSModuleNamespaceObject.cpp:
(JSC::JSModuleNamespaceObject::getOwnPropertyNames):
Call getOwnNonIndexPropertyNames() directly, guarded by includeSymbolProperties() check,
since module namespace objects can't have string properties besides m_names.
(See https://tc39.es/ecma262/#sec-module-namespace-exotic-objects-defineownproperty-p-desc)
* runtime/JSModuleNamespaceObject.h:
* runtime/JSONObject.cpp:
(JSC::Stringifier::Holder::appendNextProperty):
(JSC::Walker::walk):
* runtime/JSObject.cpp:
(JSC::JSObject::getNonReifiedStaticPropertyNames):
(JSC::JSObject::getPropertyNames):
(JSC::JSObject::getOwnPropertyNames):
(JSC::JSObject::getOwnSpecialPropertyNames):
(JSC::JSObject::getOwnIndexedPropertyNames):
(JSC::JSObject::getOwnNonIndexPropertyNames):
(JSC::getClassPropertyNames): Deleted.
(JSC::JSObject::getStructurePropertyNames): Deleted.
(JSC::JSObject::getGenericPropertyNames): Deleted.
* runtime/JSObject.h:
(JSC::JSObject::getOwnSpecialPropertyNames):
* runtime/JSPropertyNameEnumerator.cpp:
(JSC::getEnumerablePropertyNames):
* runtime/JSPropertyNameEnumerator.h:
(JSC::propertyNameEnumerator):
* runtime/JSProxy.cpp:
(JSC::JSProxy::getOwnPropertyNames):
(JSC::JSProxy::getPropertyNames): Deleted.
(JSC::JSProxy::getStructurePropertyNames): Deleted.
(JSC::JSProxy::getGenericPropertyNames): Deleted.
* runtime/JSProxy.h:
* runtime/JSSymbolTableObject.cpp:
(JSC::JSSymbolTableObject::getOwnSpecialPropertyNames):
(JSC::JSSymbolTableObject::getOwnNonIndexPropertyNames): Deleted.
* runtime/JSSymbolTableObject.h:
* runtime/JSTypeInfo.h:
(JSC::TypeInfo::overridesGetOwnPropertyNames const):
(JSC::TypeInfo::overridesGetOwnSpecialPropertyNames const):
(JSC::TypeInfo::overridesAnyFormOfGetOwnPropertyNames const):
(JSC::TypeInfo::overridesGetPropertyNames const): Deleted.
(JSC::TypeInfo::overridesAnyFormOfGetPropertyNames const): Deleted.
* runtime/ObjectConstructor.cpp:
(JSC::objectConstructorGetOwnPropertyDescriptors):
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::defineProperties):
(JSC::setIntegrityLevel):
(JSC::testIntegrityLevel):
(JSC::ownPropertyKeys):
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::performGetOwnPropertyNames):
(JSC::ProxyObject::getOwnPropertyNames):
(JSC::ProxyObject::getPropertyNames): Deleted.
(JSC::ProxyObject::getOwnNonIndexPropertyNames): Deleted.
(JSC::ProxyObject::getStructurePropertyNames): Deleted.
(JSC::ProxyObject::getGenericPropertyNames): Deleted.
* runtime/ProxyObject.h:
Remove IsQuickPropertyAccessAllowedForEnumeration flag from ProxyObject's structure
since canAccessPropertiesQuicklyForEnumeration() now checks for method overrides.
* runtime/RegExpObject.cpp:
(JSC::RegExpObject::getOwnSpecialPropertyNames):
(JSC::RegExpObject::getOwnNonIndexPropertyNames): Deleted.
(JSC::RegExpObject::getPropertyNames): Deleted.
(JSC::RegExpObject::getGenericPropertyNames): Deleted.
* runtime/RegExpObject.h:
* runtime/StringObject.cpp:
(JSC::StringObject::getOwnPropertyNames):
(JSC::StringObject::getOwnNonIndexPropertyNames): Deleted.
* runtime/StringObject.h:
* runtime/Structure.cpp:
(JSC::Structure::validateFlags):
Strengthen overridesGetOwn*PropertyNames and overridesGetPrototype asserts into
equivalence tests.
(JSC::Structure::getPropertyNamesFromStructure):
(JSC::Structure::canAccessPropertiesQuicklyForEnumeration const):
* runtime/Structure.h:
* runtime/StructureInlines.h:
(JSC::Structure::canCacheOwnPropertyNames const):
* tools/JSDollarVM.cpp:
Remove OverridesAnyFormOfGetPropertyNames structure flag as it's inherited from
JSArray, and RuntimeArray itself doesn't override getOwn*PropertyNames().
2021-01-07 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] New expression and value function call should reserve function register if arguments include assignments
https://bugs.webkit.org/show_bug.cgi?id=220429
<rdar://problem/70598359>
Reviewed by Alexey Shvayka.
If the following code is executed, we need to reserve |x| before evaluating arguments since arguments can override
local |x| variable before calling it.
new x(x = 1)
We found there are two places we are not doing this.
1. new expression
2. function value call (it is checking `isLocation()`, but we can still use local variables for function if we use comma expression)
We introduced hasAssignment flag to ArgumentsNode, and reserve a function in a new temporary register if arguments include assignments.
We also need to increment assignmentCount in destructuring assignment.
* bytecompiler/NodesCodegen.cpp:
(JSC::NewExprNode::emitBytecode):
(JSC::FunctionCallValueNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createArguments):
* parser/NodeConstructors.h:
(JSC::ArgumentsNode::ArgumentsNode):
* parser/Nodes.h:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseDestructuringPattern):
(JSC::Parser<LexerType>::parseArguments):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createArguments):
2021-01-07 Mark Lam <mark.lam@apple.com>
The scratch register should be different from the target register when calling validateUntaggedPtr.
https://bugs.webkit.org/show_bug.cgi?id=220397
rdar://72771069
Reviewed by Yusuke Suzuki.
* assembler/MacroAssemblerARM64E.h:
(JSC::MacroAssemblerARM64E::validateUntaggedPtr):
- Added an ASSERT to enforce this invariant.
* jit/ThunkGenerators.cpp:
(JSC::emitPointerValidation):
- emitPointerValidation() was reusing the target register as the scratch register.
This is a hold over from the previous way of doing the validation (which had a
bug). With the validation bug fixed, this register reuse is no longer allowed.
2021-01-07 Mark Lam <mark.lam@apple.com>
Remove some aliases of obsolete JSC options.
https://bugs.webkit.org/show_bug.cgi?id=220402
Reviewed by Yusuke Suzuki.
* runtime/OptionsList.h:
2021-01-06 Mark Lam <mark.lam@apple.com>
Fix a dataMemoryTempRegister use violation in FTLLowerDFGToB3's compileLoopHint().
https://bugs.webkit.org/show_bug.cgi?id=220399
Reviewed by Yusuke Suzuki.
This was tripping an assertion failure on the invalid use of the dataMemoryTempRegister
during a Debug build JSC stress test run with DoesGC validation enabled.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileLoopHint):
2021-01-06 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] DateTimeFormat#formatRange should generate the same output to DateTimeFormat#format if startDate and endDate are "practically-equal"
https://bugs.webkit.org/show_bug.cgi?id=220395
Reviewed by Ross Kirsling.
Intl.DateTimeFormat.formatRange(startDate, endDate) also needs to generate the same formatted string to the Intl.DateTimeFormat.format
if startDate and endDate are *practically-equal* (spec term). However, due to CLDR, just using udtitvfmt_format generates different
formatted string to udat_format's result even though startDate and endDate are the same.
new Intl.DateTimeFormat("en", { dateStyle: "long", timeStyle: "short" }).format(new Date())
// "December 12, 2019 at 11:48 AM"
new Intl.DateTimeFormat("en", { dateStyle: "long", timeStyle: "short" }).formatRange(new Date(), new Date())
// "December 12, 2019, 11:48 AM"
In Intl.DateTimeFormat#formatRangeToParts, we deploys *practically-equal* checking to avoid this issue. The same thing should be done in
Intl.DateTimeFormat#formatRange too.
In this patch, we stop using udtitvfmt_format if ICU version is 64 or later to perform *practically-equal* checking.
[1]: https://github.com/tc39/proposal-intl-DateTimeFormat-formatRange/issues/19
* runtime/IntlDateTimeFormat.cpp:
(JSC::formattedValueFromDateRange):
(JSC::dateFieldsPracticallyEqual):
(JSC::IntlDateTimeFormat::formatRange):
(JSC::IntlDateTimeFormat::formatRangeToParts):
(JSC::definitelyAfterGregorianCalendarChangeDate): Deleted.
2021-01-06 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Replace JSBigInt::toUint64 with JSBigInt::toBigUInt64
https://bugs.webkit.org/show_bug.cgi?id=220378
Reviewed by Darin Adler.
This patch replaces JSBigInt::toUint64 with JSBigInt::toBigUInt64.
Rough purposes of these functions are the same, and JSBigInt::toBigUInt64
has the semantics defined in the ECMA262 spec. While the behavior is
slightly different[1], this difference does not matter for the clients of
JSBigInt::toUint64.
[1]: JSBigInt::toUint64 fails conversion if JSBigInt is out of range of uint64_t,
while JSBigInt::toBigUInt64 always generates uint64_t by computing mod UINT64_MAX.
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::toUint64Heap): Deleted.
* runtime/JSBigInt.h:
2021-01-05 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] DFG/FTL DirectCall need to respect Wasm IC
https://bugs.webkit.org/show_bug.cgi?id=220339
Reviewed by Saam Barati.
We found that Wasm IC for fast calls are not used in several places.
1. LLInt calls
2. DFG/FTL DirectCall
3. Virtual calls
We noticed this because of r271112. r271112 made wasm function loading from exports constant-folded in DFG/FTL.
And it emits DirectCall instead of Call in DFG/FTL. Then, we missed Wasm IC and get large performance regression
in JetStream2 richard-wasm.
In this patch, we use Wasm IC as much as possible. The key thing of this wasm IC is that it relies on callee.
So, if the place is just checking Executable, then we should not go to that IC. Fortunately, the above three checks
callee before using code pointer obtained for Wasm IC.
1. LLInt call fast path first checks callee.
2. DFG/FTL DirectCall requires callee is constant for wasm functions.
3. Virtual calls are not storing generated codePtr.
* dfg/DFGOperations.cpp:
(JSC::DFG::JSC_DEFINE_JIT_OPERATION):
* jit/JITOperations.cpp:
(JSC::virtualForWithFunction):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::setUpCall):
2021-01-05 Yusuke Suzuki <ysuzuki@apple.com>
[WASM] [BigInt] Add I64 to BigInt conversion
https://bugs.webkit.org/show_bug.cgi?id=213528
Reviewed by Michael Saboff.
This patch implements i64 to BigInt / BigInt to i64 support in WebAssembly to expose i64 features to JS.
1. Arguments of exposed wasm functions can have i64.
2. Returned values of exposed wasm functions can have i64.
3. WebAssembly.Global can expose i64 value to JS.
Currently, we do not support fast JS->Wasm IC for wasm functions including i64 arguments. But this should be supported later
in https://bugs.webkit.org/show_bug.cgi?id=220053.
* jsc.cpp:
(JSC_DEFINE_HOST_FUNCTION):
* runtime/BigIntConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::toBigInt): Deleted.
* runtime/BigIntConstructor.h:
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::toBigUInt64Heap):
* runtime/JSBigInt.h:
* runtime/JSCJSValue.cpp:
(JSC::JSValue::toBigInt const):
(JSC::JSValue::toBigInt64 const):
(JSC::JSValue::toBigUInt64 const):
* runtime/JSCJSValue.h:
* wasm/WasmExceptionType.h:
* wasm/WasmGlobal.cpp:
(JSC::Wasm::Global::get const):
(JSC::Wasm::Global::set):
* wasm/WasmGlobal.h:
* wasm/WasmOperations.cpp:
(JSC::Wasm::JSC_DEFINE_JIT_OPERATION):
* wasm/WasmOperations.h:
* wasm/js/JSToWasm.cpp:
(JSC::Wasm::marshallJSResult):
(JSC::Wasm::createJSToWasmWrapper):
(JSC::Wasm::boxWasmResult): Deleted.
* wasm/js/WasmToJS.cpp:
(JSC::Wasm::wasmToJS):
(JSC::Wasm::handleBadI64Use): Deleted.
* wasm/js/WebAssemblyFunction.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::WebAssemblyFunction::jsCallEntrypointSlow):
* wasm/js/WebAssemblyGlobalConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* wasm/js/WebAssemblyGlobalPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::link):
2021-01-05 Alexey Shvayka <shvaikalesh@gmail.com>
We should have a DFG intrinsic for the construct case of the Object constructor
https://bugs.webkit.org/show_bug.cgi?id=155591
Reviewed by Yusuke Suzuki.
Given that a) ObjectConstructor behaves identically for [[Call]] and [[Construct]] with itself
as NewTarget [1] and b) handleConstantInternalFunction() returns early if NewTarget is altered,
this patch simply removes CodeForCall guard.
While `new Object()` is already optimized via BytecodeGenerator::emitExpectedFunctionSnippet(),
this change is a 4x speedup for rather rare usages like `new window.Object()`.
[1]: https://tc39.es/ecma262/#sec-object-value (step 1)
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
2021-01-05 Dmitry Bezhetskov <dbezhetskov@igalia.com>
[WASM-References] Added few unreached-invalid tests
https://bugs.webkit.org/show_bug.cgi?id=220311
Reviewed by Yusuke Suzuki.
Add semantic checks for parsing unreachable for the following intructions:
local.get/set.tee, global.get/set, br/br_if and call.
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseIndexForLocal):
(JSC::Wasm::FunctionParser<Context>::parseIndexForGlobal):
(JSC::Wasm::FunctionParser<Context>::parseFunctionIndex):
(JSC::Wasm::FunctionParser<Context>::parseBranchTarget):
(JSC::Wasm::FunctionParser<Context>::parseExpression):
(JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
2020-12-16 Tadeu Zagallo <tzagallo@apple.com>
propertyNameEnumerator must check it can still take the fast path after getGenericPropertyNames
https://bugs.webkit.org/show_bug.cgi?id=219957
<rdar://71156284>
Reviewed by Yusuke Suzuki.
We need to check if we still `canAccessPropertiesQuicklyForEnumeration` on
`structureAfterGettingPropertyNames`, since we might call out out to a proxy's
`getPrototypeOf` callback through `getGenericPropertyNames`.
* runtime/JSPropertyNameEnumerator.h:
(JSC::propertyNameEnumerator):
2020-11-17 Tadeu Zagallo <tzagallo@apple.com>
Validate every instruction in AssemblerBuffer
https://bugs.webkit.org/show_bug.cgi?id=218104
<rdar://problem/69433094>
Reviewed by Saam Barati.
* assembler/AssemblerBuffer.cpp:
(JSC::threadSpecificAssemblerHashes):
* assembler/AssemblerBuffer.h:
(JSC::AssemblerBuffer::AssemblerBuffer):
(JSC::AssemblerBuffer::~AssemblerBuffer):
(JSC::AssemblerBuffer::releaseAssemblerData):
(JSC::AssemblerBuffer::releaseAssemblerHashes):
(JSC::AssemblerBuffer::putIntegralUnchecked):
(JSC::AssemblerBuffer::grow):
(JSC::AssemblerBuffer::outOfLineGrow):
(JSC::ARM64EHash::update): Deleted.
(JSC::ARM64EHash::finalHash const): Deleted.
(): Deleted.
(JSC::AssemblerBuffer::hash const): Deleted.
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::copyCompactAndLinkCode):
* assembler/LinkBuffer.h:
2021-01-04 Dmitry Bezhetskov <dbezhetskov@igalia.com>
[WASM-References] Fix data section parsing and add more tests from ref-types
https://bugs.webkit.org/show_bug.cgi?id=220235
Reviewed by Yusuke Suzuki.
We should read leb128 unsigned integer instead of just one byte for
Data entry flag.
* wasm/WasmSectionParser.cpp:
(JSC::Wasm::SectionParser::parseData):
2021-01-04 Jeff Miller <jeffm@apple.com>
Update user-visible copyright strings to include 2021
https://bugs.webkit.org/show_bug.cgi?id=219901
Reviewed by Anders Carlsson.
* Info.plist:
2021-01-01 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Remove unnecessary mov bytecodes when performing simple object pattern destructuring to variables
https://bugs.webkit.org/show_bug.cgi?id=220219
Reviewed by Alexey Shvayka.
Currently, we are first puts object pattern's expression into temporary variable, and then, we store it into local variable register.
The following code
({ data } = object);
emits this kind of bytecode.
get_by_id dst:loc10, base:loc9, property:0
mov dst:loc6, src:loc10
However, this should be
get_by_id dst:loc6, base:loc9, property:0
We are emitting many unnecessary movs since this destructuring pattern is common. Increasing amount of mov (1) discourages inlining unnecessarily and (2) simply makes
bytecode memory large. Since this is very common pattern, we should carefully optimize it to remove such unnecessary movs.
This patch looks into pattern when performing object pattern destructuring. And avoid emitting mov when it is possible. There are some cases we cannot remove movs, so
this patch's writableDirectBindingIfPossible looks into whether this is possible (& profitable).
* bytecompiler/NodesCodegen.cpp:
(JSC::ObjectPatternNode::bindValue const):
(JSC::BindingNode::writableDirectBindingIfPossible const):
(JSC::BindingNode::finishDirectBindingAssignment const):
(JSC::AssignmentElementNode::writableDirectBindingIfPossible const):
(JSC::AssignmentElementNode::finishDirectBindingAssignment const):
* parser/Nodes.h:
(JSC::DestructuringPatternNode::writableDirectBindingIfPossible const):
(JSC::DestructuringPatternNode::finishDirectBindingAssignment const):
2021-01-02 Alexey Shvayka <shvaikalesh@gmail.com>
Improve error message for uninitialized |this| in derived constructor
https://bugs.webkit.org/show_bug.cgi?id=220221
Reviewed by Yusuke Suzuki.
Since class constructors perform `return this;` by default, and derived
constructors require `super()` to be called before |this| access, regular
TDZ error message is quite confusing, given the following code:
`new (class extends Object { constructor() { } });`
Considering that currently op_check_tdz is called on thisRegister() only
in derived constructors, this patch modifies its slow path to throw a
helpful error message that covers |this| access and non-object returns.
V8 and SpiderMonkey have similar error messages, mentioning `super()`.
slow_path_throw_tdz_error is merged into slow_path_check_tdz, which is
invoked from baseline JIT, so we can reliably acquire the bytecode and
avoid code duplication.
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::JSC_DEFINE_COMMON_SLOW_PATH):
* runtime/CommonSlowPaths.h:
2021-01-02 Alexey Shvayka <shvaikalesh@gmail.com>
Don't throw if `function.caller` is a non-strict / generator / async function
https://bugs.webkit.org/show_bug.cgi?id=220216
Reviewed by Yusuke Suzuki.
The spec forbids [1] ES6+ and strict mode functions from having their own "caller"
property. r230662 went even further, throwing TypeError if `function.caller` attempts
to return non-strict / generator / async function, which doesn't contradict ECMA-262,
but diverges from V8 and SpiderMonkey (they just return the caller).
Since throwing TypeError causes quite a lot test262 failures and is a bit dangerous
(legacy library which uses `function.caller` is called from ES6 code), this patch
replaces it with `null` return.
Given that r230662 appears to be web-compatible, this change preserves its intent
to limit `function.caller` API as much as possible by returning `null` for all ES6+
functions, including methods, accessors, and arrow functions.
[1]: https://tc39.es/ecma262/#sec-forbidden-extensions (paragraphs 1-2)
* runtime/JSFunction.cpp:
(JSC::JSC_DEFINE_CUSTOM_GETTER):
2020-12-31 Alexey Shvayka <shvaikalesh@gmail.com>
JSFunction::deleteProperty() fails to delete a non-existent "prototype" property
https://bugs.webkit.org/show_bug.cgi?id=220211
Reviewed by Yusuke Suzuki.
This patch replaces arrow function check with hasPrototypeProperty() since there
are more functions without a "prototype" (accessors, methods, async functions),
aligning JSC with the spec, V8, and SpiderMonkey.
hasPrototypeProperty() is already used by JSFunction::getOwnPropertySlot().
* runtime/JSFunction.cpp:
(JSC::JSFunction::deleteProperty):
2020-12-30 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] WebAssembly Table/Memory/Global should allow inheritance
https://bugs.webkit.org/show_bug.cgi?id=220207
Reviewed by Alexey Shvayka.
WebAssembly.{Table,Memory,Global} should accept inheritance by JS class syntax.
We need to create structure from new.target value.
* wasm/js/WebAssemblyGlobalConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* wasm/js/WebAssemblyMemoryConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* wasm/js/WebAssemblyTableConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
2020-12-30 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, fix iteration count check
https://bugs.webkit.org/show_bug.cgi?id=220206
We should have iterationCount variable to track iteration count since it can be larger than MarkedArgumentBuffer's size.
* wasm/WasmOperations.cpp:
(JSC::Wasm::JSC_DEFINE_JIT_OPERATION):
2020-12-30 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Wasm multivalue should iterate iterable result from JS function first before converting values
https://bugs.webkit.org/show_bug.cgi?id=220206
Reviewed by Alexey Shvayka.
When converting JS results to Wasm multivalue (result from JS when executing Wasm->JS calls), we should first iterate all results from iterable.
And then, we should convert each element into Wasm value. Currently, we are converting while iterating, this is not aligned to the spec.
* wasm/WasmOperations.cpp:
(JSC::Wasm::JSC_DEFINE_JIT_OPERATION):
2020-12-29 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Update WebAssembly instance's exports object
https://bugs.webkit.org/show_bug.cgi?id=220189
Reviewed by Alexey Shvayka.
This patch aligns the WebAssembly Instance's exports object to the updated spec.
1. exports object is a plain object which [[Prototype]] is null[1]. We were using module namespace object. Also, the object should be frozen.
2. exported functions' name should be index, according to the spec[2].
[1]: https://webassembly.github.io/spec/js-api/index.html#create-an-exports-object
[2]: https://webassembly.github.io/spec/js-api/index.html#exported-function-exotic-objects
* wasm/js/JSWebAssembly.cpp:
(JSC::resolve):
* wasm/js/JSWebAssemblyInstance.cpp:
(JSC::JSWebAssemblyInstance::finishCreation):
(JSC::JSWebAssemblyInstance::visitChildren):
(JSC::JSWebAssemblyInstance::finalizeCreation):
(JSC::JSWebAssemblyInstance::tryCreate):
* wasm/js/JSWebAssemblyInstance.h:
* wasm/js/WebAssemblyInstancePrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::visitChildren):
(JSC::WebAssemblyModuleRecord::link):
* wasm/js/WebAssemblyModuleRecord.h:
2020-12-27 Dmitry Bezhetskov <dbezhetskov@igalia.com>
[WASM-References] Fix table.init and table.grow to satisfy the spec
https://bugs.webkit.org/show_bug.cgi?id=220181
Reviewed by Yusuke Suzuki.
Fix and refactor a little bit table.init and
table.grow.
* wasm/WasmOperations.cpp:
(JSC::Wasm::JSC_DEFINE_JIT_OPERATION):
* wasm/WasmOperations.h:
* wasm/WasmSlowPaths.cpp:
(JSC::LLInt::WASM_SLOW_PATH_DECL):
2020-12-27 Dmitry Bezhetskov <dbezhetskov@igalia.com>
[WASM-References] Adjust table.fill to satisfy the spec
https://bugs.webkit.org/show_bug.cgi?id=220161
Reviewed by Yusuke Suzuki.
Fixed table.fill for the case when count is 0 and offset is equal to
table size.
* wasm/WasmOperations.cpp:
(JSC::Wasm::setWasmTableElement):
(JSC::Wasm::JSC_DEFINE_JIT_OPERATION):
* wasm/WasmOperations.h:
* wasm/WasmSlowPaths.cpp:
(JSC::LLInt::WASM_SLOW_PATH_DECL):
2020-12-27 Dmitry Bezhetskov <dbezhetskov@igalia.com>
[WASM-References] Add declared function indexes set to check from what functions we can create refs
https://bugs.webkit.org/show_bug.cgi?id=220009
Reviewed by Yusuke Suzuki.
By ref-types spec we can create references only from declared functions.
Declared function is a function that was mentioned:
as export,
as part of ref.func init expression for a global,
in the element section.
In this patch declared function indexes set introduced to check this
requirement.
https://webassembly.github.io/reference-types/core/valid/instructions.html#reference-instructions.
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseExpression):
* wasm/WasmModuleInformation.h:
(JSC::Wasm::ModuleInformation::isDeclaredFunction const):
(JSC::Wasm::ModuleInformation::addDeclaredFunction):
* wasm/WasmSectionParser.cpp:
(JSC::Wasm::SectionParser::parseGlobal):
(JSC::Wasm::SectionParser::parseExport):
(JSC::Wasm::SectionParser::parseElementSegmentVectorOfExpressions):
(JSC::Wasm::SectionParser::parseElementSegmentVectorOfIndexes):
2020-12-25 Mark Lam <mark.lam@apple.com>
VMInspector::dumpRegisters() should not dump beyond the start of the next frame.
https://bugs.webkit.org/show_bug.cgi?id=220136
rdar://64404201
Reviewed by Yusuke Suzuki.
VMInspector::dumpRegisters() was dumping stack slots up for up to
codeBlock->numCalleeLocals() slots for any given CallFrame. This is incorrect.
codeBlock->numCalleeLocals() indicates the maximum number of stack slots that the
codeBlock may use. However, the executing codeBlock may not necessary use up that
number of slots before calling another function.
In the attached test case, the global program has 98 callee locals. However, it
was only using a very small number of stack slots to call $vm.dumpRegisters().
On an ASAN build, iterating thru 98 stack slots of the global program (to dump
their contents) ended up reading beyond the top of the stack, and this made ASAN
very unhappy. The fix is simply to ensure that VMInspector::dumpRegisters() never
dumps past the start of the next CallFrame.
* tools/VMInspector.cpp:
(JSC::VMInspector::dumpRegisters):
2020-12-21 Jessica Tallon <jtallon@igalia.com>
[JSC] Add minimum parameter to the WASM JS-API for Memory & Table.
https://bugs.webkit.org/show_bug.cgi?id=219600
Reviewed by Yusuke Suzuki.
This patch adds a "minimum" perameter to the constructor of both WebAssembly.Memory and
WebAssembly.Table. This represents the same value as the "initial" perameter. The new
perameter name is outlined here [1]. It is part of the JS type reflection proposal.
[1]: https://github.com/WebAssembly/js-types/blob/master/proposals/js-types/Overview.md#naming-of-size-limits
* JSTests/wasm/js-api/table.js:
* JSTests/wasm/js-api/test_memory_constructor.js:
* Source/JavaScriptCore/wasm/js/WebAssemblyMemoryConstructor.cpp:
* Source/JavaScriptCore/wasm/js/WebAssemblyTableConstructor.cpp:
2020-12-21 Keith Miller <keith_miller@apple.com>
DFG should make sure replacement watchpoint is fired before folding to PutByOffset
https://bugs.webkit.org/show_bug.cgi?id=220031
<rdar://72045350>
Reviewed by Saam Barati.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::presenceConditionIfConsistent):
(JSC::DFG::ByteCodeParser::checkPresence):
(JSC::DFG::ByteCodeParser::checkPresenceForReplace):
(JSC::DFG::ByteCodeParser::load):
(JSC::DFG::ByteCodeParser::store):
(JSC::DFG::ByteCodeParser::presenceLike): Deleted.
(JSC::DFG::ByteCodeParser::checkPresenceLike): Deleted.
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::tryFoldAsPutByOffset):
* runtime/Structure.cpp:
(JSC::Structure::dump const):
2020-12-18 Mark Lam <mark.lam@apple.com>
Build fix after r270988.
https://bugs.webkit.org/show_bug.cgi?id=220021
<rdar://problem/72474809>
Not reviewed.
* JavaScriptCore.xcodeproj/project.pbxproj:
2020-12-18 Saam Barati <sbarati@apple.com>
CachedRefPtr should adoptRef before calling ref to appease RefCounted's debug assertions
https://bugs.webkit.org/show_bug.cgi?id=219953
<rdar://problem/72391255>
Reviewed by Tadeu Zagallo.
* runtime/CachedTypes.cpp:
(JSC::CachedRefPtr::decode const):
2020-12-18 Mark Lam <mark.lam@apple.com>
Fix MacroAssemblerARM64E::validateUntaggedPtr() to account for TBI.
https://bugs.webkit.org/show_bug.cgi?id=220021
<rdar://problem/72474809>
Reviewed by Saam Barati.
* assembler/AbstractMacroAssembler.h:
* assembler/DisallowMacroScratchRegisterUsage.h:
- templatized the DisallowMacroScratchRegisterUsage class so that we can #include
it in MacroAssembler implementations.
* assembler/MacroAssemblerARM64E.h:
(JSC::MacroAssemblerARM64E::validateUntaggedPtr):
2020-12-17 Mark Lam <mark.lam@apple.com>
Add tagging to JIT probe's return address.
https://bugs.webkit.org/show_bug.cgi?id=220008
rdar://71279530
Reviewed by Keith Miller and Robin Morisset.
* assembler/MacroAssemblerARM64.cpp:
* assembler/testmasm.cpp:
(JSC::testProbeModifiesProgramCounter):
* runtime/JSCPtrTag.h:
2020-12-18 Yusuke Suzuki <ysuzuki@apple.com>
[CSSJIT] Do not use trampoline if JITCage is disabled
https://bugs.webkit.org/show_bug.cgi?id=220004
Reviewed by Tadeu Zagallo.
* llint/LLIntData.cpp:
* llint/LowLevelInterpreter.asm:
2020-12-18 Dmitry Bezhetskov <dbezhetskov@igalia.com>
[WASM-References] Reuse instance initElementSegment to reduce duplication
https://bugs.webkit.org/show_bug.cgi?id=220007
Reviewed by Yusuke Suzuki.
Simple refactroing. We need only one place to initialize elements
segments.
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::evaluate):
2020-12-17 Dmitry Bezhetskov <dbezhetskov@igalia.com>
[WASM-References] Add support for memory.copy, memory.init and data.drop
https://bugs.webkit.org/show_bug.cgi?id=219943
Reviewed by Yusuke Suzuki.
Add support for memory.copy [dstAddress, srcAddress, length] -> []
that copies one memory segment to another memory segment.
The memory.copy calls C memcpy function to utilize all possible optimization for copy.
This instruction speedup copying data segments in wasm because without it we need to use a lot
load/store instructions with loops in wasm.
Add support for memory.init data_segment_index [dstAddress, srcAddress, length] -> []
that copies data from a passive data segment into a memory segment.
This instruction is the same as memory.copy but for read-only data segments.
It also utilize C memcpy under the hood.
Add support for data.drop data_segment_index [] -> []
that resize given data segment to zero.
Data.drop makes redundant data segment and prevents usage of it in the next.
BTW, it is just a hint for the host runtime so we don't have to change data segment.
Add support for Data count section.
This section just stores the number of data segments.
We need this to validate memory.init instruction's data index because
Code section comes before Data section.
These instructions are needed to support reference types proposal and bulk proposal.
* bytecode/BytecodeList.rb:
* llint/WebAssembly.asm:
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::addMemoryCopy):
(JSC::Wasm::AirIRGenerator::addMemoryInit):
(JSC::Wasm::AirIRGenerator::addDataDrop):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::addMemoryInit):
(JSC::Wasm::B3IRGenerator::addMemoryCopy):
(JSC::Wasm::B3IRGenerator::addDataDrop):
* wasm/WasmFormat.cpp:
(JSC::Wasm::Segment::create):
* wasm/WasmFormat.h:
(JSC::Wasm::Segment::isActive const):
(JSC::Wasm::Segment::isPassive const):
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseDataSegmentIndex):
(JSC::Wasm::FunctionParser<Context>::parseMemoryCopyImmediates):
(JSC::Wasm::FunctionParser<Context>::parseMemoryInitImmediates):
(JSC::Wasm::FunctionParser<Context>::parseExpression):
(JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
* wasm/WasmInstance.cpp:
(JSC::Wasm::Instance::Instance):
(JSC::Wasm::Instance::memoryInit):
(JSC::Wasm::Instance::dataDrop):
* wasm/WasmInstance.h:
* wasm/WasmLLIntGenerator.cpp:
(JSC::Wasm::LLIntGenerator::addMemoryInit):
(JSC::Wasm::LLIntGenerator::addDataDrop):
(JSC::Wasm::LLIntGenerator::addMemoryCopy):
* wasm/WasmMemory.cpp:
(JSC::Wasm::Memory::copy):
(JSC::Wasm::Memory::init):
* wasm/WasmMemory.h:
* wasm/WasmModuleInformation.h:
(JSC::Wasm::ModuleInformation::dataSegmentsCount const):
* wasm/WasmOperations.cpp:
(JSC::Wasm::JSC_DEFINE_JIT_OPERATION):
* wasm/WasmOperations.h:
* wasm/WasmSectionParser.cpp:
(JSC::Wasm::SectionParser::parseElement):
(JSC::Wasm::SectionParser::parseI32InitExpr):
(JSC::Wasm::SectionParser::parseI32InitExprForElementSection):
(JSC::Wasm::SectionParser::parseI32InitExprForDataSection):
(JSC::Wasm::SectionParser::parseDataSegmentCoreSpec):
(JSC::Wasm::SectionParser::parseDataSegmentReferenceTypesSpec):
(JSC::Wasm::SectionParser::parseGlobalType):
(JSC::Wasm::SectionParser::parseData):
(JSC::Wasm::SectionParser::parseDataCount):
* wasm/WasmSectionParser.h:
* wasm/WasmSections.h:
(JSC::Wasm::validateOrder):
* wasm/WasmSlowPaths.cpp:
(JSC::LLInt::WASM_SLOW_PATH_DECL):
* wasm/WasmSlowPaths.h:
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::evaluate):
* wasm/wasm.json:
2020-12-16 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Not using JITCage trampoline for non JITCage JSC
https://bugs.webkit.org/show_bug.cgi?id=219974
Reviewed by Tadeu Zagallo.
We avoid using JITCage trampoline in YarrJIT if JSC is not using JITCage.
* llint/LowLevelInterpreter.asm:
* yarr/YarrJIT.cpp:
* yarr/YarrJIT.h:
(JSC::Yarr::YarrCodeBlock::execute):
2020-12-15 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Accept arbitrary module namespace identifier names
https://bugs.webkit.org/show_bug.cgi?id=217576
<rdar://problem/70416104>
Reviewed by Darin Adler.
This patch implements arbitrary module namespace identifier names[1].
After this, we can export and import arbitrary module export names which are not valid as a variable identifier.
For example,
import { "delete" as deletedValue } from "./ok.js";
...
export {
deletedValue as "delete"
};
[1]: https://github.com/tc39/ecma262/pull/2154
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseImportClauseItem):
(JSC::Parser<LexerType>::parseImportDeclaration):
(JSC::Parser<LexerType>::parseExportSpecifier):
(JSC::Parser<LexerType>::parseExportDeclaration):
* parser/Parser.h:
2020-12-16 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, fix stale assertions
https://bugs.webkit.org/show_bug.cgi?id=219847
After r270764, HostFunctionPtrTag and CustomAccessorPtrTag are categorized as Native ones.
However, in non-JIT-caged environment, still they are used as JIT ones. Then, we are getting
stale assertions. Several other tags are showing similar things for non JIT environments etc.
Add `Options::useJITCage()` check since this caller/callee type is only valid in JIT Cage environment.
* assembler/MacroAssemblerARM64E.h:
(JSC::MacroAssemblerARM64E::call):
(JSC::MacroAssemblerARM64E::farJump):
2020-12-15 Saam Barati <sbarati@apple.com>
destinationFor should check for FTLJIT, not DFGJIT twice
https://bugs.webkit.org/show_bug.cgi?id=219929
Reviewed by Mark Lam.
The code was checking for DFGJIT twice instead of checking for FTLJIT.
This doesn't fix any actual bugs, since nobody passes in FTLJIT to this
function. But if we ever do in the future, it would have revealed this bug.
* bytecode/BytecodeOperandsForCheckpoint.h:
(JSC::destinationFor):
2020-12-15 Alexey Shvayka <shvaikalesh@gmail.com>
Non-enumerable property fails to shadow inherited enumerable property from for-in
https://bugs.webkit.org/show_bug.cgi?id=38970
Reviewed by Keith Miller.
While for/in was initially specified with notion of "shadowing", it wasn't clarified
until ES5 that [[Enumerable]] attributes are ignored when determining if a property
has already been processed. Recently, for/in spec was expanded [1] to pin down common
case enumeration as it's currently implemented by V8 and SpiderMonkey.
Since keeping track of DontEnum properties is a massive slowdown for uncached runs
(with any data structure used), this patch simply adds [[Enumerable]] check to
has_{indexed,structure,generic}_property bytecode ops and does renaming chores.
Common code is now shared between HasIndexedProperty (emitted for `0 in arr`) and
HasEnumerableIndexedProperty DFG nodes via passing different slow path ops rather
than having OpInfo with PropertySlot::InternalMethodType, which is a nice refactor.
While this change aligns common case for/in enumeration with the spec and other
engines, it also introduces a few observable discrepancies from V8 and SpiderMonkey,
which are permitted by the spec [2]:
a) properties that have been redefined as DontEnum within loop body are skipped,
which matches the spec [3] and seems like expected behavior;
b) "shadowing" is broken if a DontEnum property of already visited object is
added / deleted / redefined within loop body, which (pretty much) never happens.
This patch introduces a new invariant: all properties getOwn*PropertyNames() returns
in DontEnumPropertiesMode::Exclude should be reported as [[Enumerable]] by
getOwnPropertySlot(). JSCallbackObject and RuntimeArray are fixed to follow it.
for/in and Object.keys microbenchmarks are neutral. This change does not affect
JSPropertyNameEnumerator caching, nor fast paths of its bytecodes.
[1]: https://github.com/tc39/ecma262/pull/1791
[2]: https://tc39.es/ecma262/#sec-enumerate-object-properties (last paragraph)
[3]: https://tc39.es/ecma262/#sec-%foriniteratorprototype%.next (step 7.b.iii)
* API/JSCallbackObjectFunctions.h:
(JSC::JSCallbackObject<Parent>::getOwnPropertySlot):
* API/tests/testapi.c:
* API/tests/testapiScripts/testapi.js:
* bytecode/BytecodeList.rb:
* bytecode/BytecodeUseDef.cpp:
(JSC::computeUsesForBytecodeIndexImpl):
(JSC::computeDefsForBytecodeIndexImpl):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
* bytecode/Opcode.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitHasEnumerableIndexedProperty):
(JSC::BytecodeGenerator::emitHasEnumerableStructureProperty):
(JSC::BytecodeGenerator::emitHasEnumerableProperty):
(JSC::BytecodeGenerator::emitHasGenericProperty): Deleted.
(JSC::BytecodeGenerator::emitHasIndexedProperty): Deleted.
(JSC::BytecodeGenerator::emitHasStructureProperty): Deleted.
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::ForInNode::emitBytecode):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::convertToHasIndexedProperty):
* dfg/DFGNode.h:
(JSC::DFG::Node::hasArrayMode):
(JSC::DFG::Node::hasInternalMethodType const): Deleted.
(JSC::DFG::Node::internalMethodType const): Deleted.
(JSC::DFG::Node::setInternalMethodType): Deleted.
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
(JSC::DFG::JSC_DEFINE_JIT_OPERATION):
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSSALoweringPhase.cpp:
(JSC::DFG::SSALoweringPhase::handleNode):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileHasEnumerableProperty):
(JSC::DFG::SpeculativeJIT::compileHasEnumerableStructureProperty):
(JSC::DFG::SpeculativeJIT::compileHasIndexedProperty):
(JSC::DFG::SpeculativeJIT::compileHasGenericProperty): Deleted.
(JSC::DFG::SpeculativeJIT::compileHasStructureProperty): Deleted.
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileHasIndexedProperty):
(JSC::FTL::DFG::LowerDFGToB3::compileHasEnumerableProperty):
(JSC::FTL::DFG::LowerDFGToB3::compileHasEnumerableStructureProperty):
(JSC::FTL::DFG::LowerDFGToB3::compileHasGenericProperty): Deleted.
(JSC::FTL::DFG::LowerDFGToB3::compileHasStructureProperty): Deleted.
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
* jit/JIT.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_has_enumerable_structure_property):
(JSC::JIT::emit_op_has_enumerable_indexed_property):
(JSC::JIT::emitSlow_op_has_enumerable_indexed_property):
(JSC::JIT::emit_op_has_structure_property): Deleted.
(JSC::JIT::emit_op_has_indexed_property): Deleted.
(JSC::JIT::emitSlow_op_has_indexed_property): Deleted.
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_has_enumerable_structure_property):
(JSC::JIT::emit_op_has_enumerable_indexed_property):
(JSC::JIT::emitSlow_op_has_enumerable_indexed_property):
(JSC::JIT::emit_op_has_structure_property): Deleted.
(JSC::JIT::emit_op_has_indexed_property): Deleted.
(JSC::JIT::emitSlow_op_has_indexed_property): Deleted.
* jit/JITOperations.cpp:
(JSC::JSC_DEFINE_JIT_OPERATION):
* jit/JITOperations.h:
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::JSC_DEFINE_COMMON_SLOW_PATH):
* runtime/CommonSlowPaths.h:
* runtime/JSObject.cpp:
(JSC::JSObject::hasProperty const):
(JSC::JSObject::hasEnumerableProperty const):
(JSC::JSObject::hasPropertyGeneric const): Deleted.
* runtime/JSObject.h:
2020-12-15 Saam Barati <sbarati@apple.com>
Switch to using a linked list for the TDZ environment instead of a Vector
https://bugs.webkit.org/show_bug.cgi?id=219909
<rdar://71441753>
Reviewed by Tadeu Zagallo.
Before, we'd represent the TDZ stack in terms of a Vector. While the entries
in the Vector were reference counted, the spine of the Vector itself would
match the length of the TDZ scope stack. It turns out this spine itself can
use non-trivial amounts of memory. We are seeing about a 0.5% regression from
this inside RAMification. This change makes it so that we now use a tree-like
data structure for scope stack entries. The data structure is a tree with only
parent pointers. Any field that used to be a vector of entries is now a
pointer to a node in this tree. So any pointer into this tree will have a
linked-list window into the tree, where the linked-list represents the same
data as the previous vector-as-stack data structure.
Initial testing shows this might be up to a 0.5% progression on RAMification.
* builtins/BuiltinExecutables.cpp:
(JSC::BuiltinExecutables::createExecutable):
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
* bytecode/UnlinkedFunctionExecutable.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::popLexicalScopeInternal):
(JSC::BytecodeGenerator::needsTDZCheck):
(JSC::BytecodeGenerator::liftTDZCheckIfPossible):
(JSC::BytecodeGenerator::pushTDZVariables):
(JSC::BytecodeGenerator::getVariablesUnderTDZ):
(JSC::BytecodeGenerator::preserveTDZStack):
(JSC::BytecodeGenerator::restoreTDZStack):
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::generate):
* parser/VariableEnvironment.h:
(JSC::TDZEnvironmentLink::TDZEnvironmentLink):
(JSC::TDZEnvironmentLink::create):
(JSC::TDZEnvironmentLink::contains const):
(JSC::TDZEnvironmentLink::parent):
* runtime/CachedTypes.cpp:
(JSC::CachedTDZEnvironmentLink::encode):
(JSC::CachedTDZEnvironmentLink::decode const):
* runtime/CodeCache.cpp:
(JSC::generateUnlinkedCodeBlockImpl):
(JSC::CodeCache::getUnlinkedGlobalFunctionExecutable):
2020-12-15 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r270860.
https://bugs.webkit.org/show_bug.cgi?id=219918
We workaround it differently, so this revert is not necessary
Reverted changeset:
"Unreviewed, reverting r269320, r269341, r269502, and
r269576."
https://bugs.webkit.org/show_bug.cgi?id=219915
https://trac.webkit.org/changeset/270860
2020-12-15 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r269320, r269341, r269502, and r269576.
https://bugs.webkit.org/show_bug.cgi?id=219915
ICU C++ internal API causes trouble
Reverted changesets:
"REGRESSION (r254038): Simple.com money transfer UI is very
laggy (multiple seconds per keypress)"
https://bugs.webkit.org/show_bug.cgi?id=218348
https://trac.webkit.org/changeset/269320
"[JSC] Obtain default timezone ID from cached icu::TimeZone"
https://bugs.webkit.org/show_bug.cgi?id=218531
https://trac.webkit.org/changeset/269341
"toLocaleDateString() resolves incorrect date for some old
dates"
https://bugs.webkit.org/show_bug.cgi?id=161623
https://trac.webkit.org/changeset/269502
"[JSC] Add TimeZone range cache over ICU TimeZone API"
https://bugs.webkit.org/show_bug.cgi?id=218681
https://trac.webkit.org/changeset/269576
2020-12-15 Dmitry Bezhetskov <dbezhetskov@igalia.com>
[WASM-References] Add support for memory.fill
https://bugs.webkit.org/show_bug.cgi?id=219848
Reviewed by Yusuke Suzuki.
Add support for memory.fill from ref-types spec.
memory.fill sets all bytes in a memory region to a given byte:
https://webassembly.github.io/reference-types/core/syntax/instructions.html#memory-instructions.
* bytecode/BytecodeList.rb:
* llint/WebAssembly.asm:
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::addMemoryFill):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::addMemoryFill):
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseMemoryFillImmediate):
(JSC::Wasm::FunctionParser<Context>::parseExpression):
(JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
* wasm/WasmLLIntGenerator.cpp:
(JSC::Wasm::LLIntGenerator::addMemoryFill):
* wasm/WasmMemory.cpp:
(JSC::Wasm::Memory::fill):
(JSC::Wasm::Memory::doMemoryFill):
* wasm/WasmMemory.h:
* wasm/WasmOperations.cpp:
(JSC::Wasm::JSC_DEFINE_JIT_OPERATION):
* wasm/WasmOperations.h:
* wasm/WasmSlowPaths.cpp:
(JSC::LLInt::WASM_SLOW_PATH_DECL):
* wasm/WasmSlowPaths.h:
* wasm/wasm.json:
2020-12-15 Dmitry Bezhetskov <dbezhetskov@igalia.com>
[WASM-References] Add support for type annotated select
https://bugs.webkit.org/show_bug.cgi?id=219595
Reviewed by Yusuke Suzuki.
Add support for typed select instruction from ref-types proposal:
select t : [t t i32] -> [t].
The annotated select instruction takes a value type immediate to deduce result type of select expression.
This version of select will help us with subtyping in the future where we want to avoid computing lubs.
For more information see:
https://github.com/WebAssembly/reference-types/issues/125,
https://webassembly.github.io/reference-types/core/binary/instructions.html#parametric-instructions.
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseAnnotatedSelectImmediates):
(JSC::Wasm::FunctionParser<Context>::parseExpression):
(JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
* wasm/wasm.json:
2020-12-14 Tadeu Zagallo <tzagallo@apple.com>
Move some of the work from JSLock to VMEntryScope
https://bugs.webkit.org/show_bug.cgi?id=219830
Reviewed by Mark Lam.
We move several things from JSLock to VMEntryScope that could only be observed after we entered the VM:
- WasmThreads: only used when tiering up wasm, so VMEntryScope would have executed
- registerThreadForMachExceptionHandling: The mach exception handlers are used for:
- sigill crash analyzer: only relevant after we enter the vm
- wasm fault signal handler: same, we must be executing wasm and therefore VMEntryScope will have executed.
- VMTraps: only handles faults in JIT code
- firePrimitiveGigacageEnabledIfNecessary: Only watched by the JITs
This gives is a ~10% improvement on APIBench (score change from ~36.3 to ~39.9), but as it turns out the most expensive
call is adding the current thread to the heap as this requires acquiring two locks. We can't move this to VMEntryScope
since it's possible to use the API and GC without ever entering the VM, which would result in the current thread's stack
not being scanned. Instead, we just remember the last thread that acquired the lock and skip the call if we're seeing the
same thread again. This greatly amortizes the cost and gives us another ~10%:
CURRENT_API: Baseline Change
----------------------------------------
RichardsMostlyC: 62ms 32ms
RichardsMostlyObjC: 303ms 264ms
RichardsMostlySwift: 296ms 261ms
RichardsSomeC: 76ms 49ms
RichardsSomeObjC: 156ms 150ms
RichardsSomeSwift: 200ms 197ms
UPCOMING_API: Baseline Change
----------------------------------------
RichardsMostlyC: 19ms 19ms
RichardsMostlyObjC: 282ms 260ms
RichardsMostlySwift: 282ms 264ms
RichardsSomeC: 79ms 46ms
RichardsSomeObjC: 156ms 149ms
RichardsSomeSwift: 195ms 195ms
----------------------------------------
Score: 36.2211 43.3368
* runtime/JSLock.cpp:
(JSC::JSLock::didAcquireLock):
(JSC::JSLock::willReleaseLock):
* runtime/JSLock.h:
* runtime/VMEntryScope.cpp:
(JSC::VMEntryScope::VMEntryScope):
(JSC::VMEntryScope::~VMEntryScope):
2020-12-14 Robin Morisset <rmorisset@apple.com>
Minor cleanup of BigInts
https://bugs.webkit.org/show_bug.cgi?id=219253
Reviewed by Yusuke Suzuki.
* runtime/JSBigInt.cpp:
(JSC::rightShiftByAbsolute):
2020-12-13 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Introduce vmEntryCustomAccessor and vmEntryHostFunction for JITCage
https://bugs.webkit.org/show_bug.cgi?id=219847
Reviewed by Mark Lam.
Instead of registering all host-functions and custom accessors with OperationPtrTag or HostFunctionPtrTag,
this patch introduces a trampoline which invokes them with special ptr-tag to reduce memory usage of JITOperationList.
When invoking custom accessor, we pass that pointer as a forth argument, and call vmEntryCustomAccessor.
And vmEntryCustomAccessor jumps to the passed argument with special ptr tag. And we register vmEntryCustomAccessor as an operation.
For host-functions, we pass that pointer as a third argument.
* assembler/JITOperationList.cpp:
(JSC::addPointers):
(JSC::JITOperationList::populatePointersInJavaScriptCore):
(JSC::JITOperationList::populatePointersInJavaScriptCoreForLLInt):
(JSC::JITOperationList::populatePointersInEmbedder):
* assembler/JITOperationList.h:
(JSC::JITOperationList::assertIsHostFunction): Deleted.
* b3/testb3_1.cpp:
(main):
* bytecode/AccessCase.cpp:
(JSC::AccessCase::generateImpl):
* bytecode/GetByIdVariant.cpp:
(JSC::GetByIdVariant::GetByIdVariant):
* bytecode/GetByIdVariant.h:
(JSC::GetByIdVariant::customAccessorGetter const):
* bytecode/GetByStatus.cpp:
(JSC::GetByStatus::computeForStubInfoWithoutExitSiteFeedback):
* bytecode/GetterSetterAccessCase.cpp:
(JSC::GetterSetterAccessCase::create):
* bytecode/GetterSetterAccessCase.h:
* dfg/DFGNode.h:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCallDOMGetter):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCallDOMGetter):
* jit/JITOperations.h:
* jit/Repatch.cpp:
(JSC::tryCacheGetBy):
(JSC::tryCachePutByID):
* jit/ThunkGenerators.cpp:
(JSC::nativeForGenerator):
* jsc.cpp:
(jscmain):
* llint/LLIntData.cpp:
(JSC::LLInt::initialize):
* llint/LLIntThunks.cpp:
* llint/LLIntThunks.h:
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/Gate.h:
* runtime/JSCPtrTag.h:
(JSC::tagJSCCodePtrImpl):
(JSC::untagJSCCodePtrImpl):
* runtime/NativeFunction.h:
* runtime/PropertySlot.h:
* runtime/PutPropertySlot.h:
(JSC::PutPropertySlot::customSetter const):
* runtime/VM.cpp:
(JSC::VM::getHostFunction):
2020-12-14 Youenn Fablet <youenn@apple.com>
Pass an isolated copy of Settings to workers and worklets.
https://bugs.webkit.org/show_bug.cgi?id=219688
Reviewed by Sam Weinig.
* runtime/RuntimeFlags.h:
(JSC::RuntimeFlags::isolatedCopy const):
2020-12-13 Samuel Thibault <samuel.thibault@ens-lyon.org>
[JSC] Set s_maxPathLength fallback when OS does not have a PATH_MAX limitation
https://bugs.webkit.org/show_bug.cgi?id=219571
Reviewed by Yusuke Suzuki.
* runtime/ConfigFile.h:
(ConfigFile::s_maxPathLength): Fallback to 4095 when PATH_MAX is not defined.
2020-12-11 Tadeu Zagallo <tzagallo@apple.com>
REGRESSION (r270665): testapi failing on JSC bots
https://bugs.webkit.org/show_bug.cgi?id=219787
Reviewed by Saam Barati.
* API/JSValueRef.cpp:
(JSValueIsString):
(JSValueIsObject):
(JSValueIsSymbol):
2020-12-11 Caio Lima <ticaiolima@gmail.com>
[JIT] Require value registers explicitly on emitValueProfilingSite
https://bugs.webkit.org/show_bug.cgi?id=219550
Reviewed by Yusuke Suzuki.
This patch is removing the default value for `emitValueProfilingSite`
to avoid bugs like r270423 and r270431.
* jit/JIT.cpp:
(JSC::JIT::compileWithoutLinking):
* jit/JIT.h:
* jit/JITCall.cpp:
(JSC::JIT::emitPutCallResult):
(JSC::JIT::emit_op_iterator_open):
* jit/JITCall32_64.cpp:
(JSC::JIT::emitPutCallResult):
(JSC::JIT::emit_op_iterator_open):
* jit/JITInlines.h:
(JSC::JIT::appendCallWithExceptionCheckSetJSValueResultWithProfile):
(JSC::JIT::emitValueProfilingSiteIfProfiledOpcode):
(JSC::JIT::emitValueProfilingSite):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_to_number):
(JSC::JIT::emit_op_to_numeric):
(JSC::JIT::emit_op_to_object):
(JSC::JIT::emit_op_catch):
(JSC::JIT::emit_op_get_direct_pname):
(JSC::JIT::emit_op_get_argument):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_to_number):
(JSC::JIT::emit_op_to_numeric):
(JSC::JIT::emit_op_to_object):
(JSC::JIT::emit_op_catch):
(JSC::JIT::emit_op_get_direct_pname):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_get_by_val):
(JSC::JIT::emit_op_get_private_name):
(JSC::JIT::emit_op_try_get_by_id):
(JSC::JIT::emit_op_get_by_id_direct):
(JSC::JIT::emit_op_get_by_id):
(JSC::JIT::emit_op_get_by_id_with_this):
(JSC::JIT::emit_op_get_from_scope):
(JSC::JIT::emit_op_get_from_arguments):
(JSC::JIT::emit_op_get_internal_field):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_get_by_val):
(JSC::JIT::emit_op_get_private_name):
(JSC::JIT::emit_op_try_get_by_id):
(JSC::JIT::emit_op_get_by_id_direct):
(JSC::JIT::emit_op_get_by_id):
(JSC::JIT::emit_op_get_by_id_with_this):
(JSC::JIT::emit_op_get_from_scope):
(JSC::JIT::emit_op_get_from_arguments):
(JSC::JIT::emit_op_get_internal_field):
2020-12-11 Tadeu Zagallo <tzagallo@apple.com>
REGRESSION (r270665): testapi failing on CLoop bot
https://bugs.webkit.org/show_bug.cgi?id=219787
Reviewed by Mark Lam.
The API has to special case the empty JSValue as null.
* API/JSValueRef.cpp:
(JSValueGetType):
(JSValueIsNull):
2020-12-11 Don Olmstead <don.olmstead@sony.com>
[CMake] Determine correct visibility for linked frameworks
https://bugs.webkit.org/show_bug.cgi?id=210366
Reviewed by Michael Catanzaro.
Set JavaScriptCore_FRAMEWORKS to determine correct linkage for the library. Remove
explicit setting of STATICALLY_LINKED_WITH_${framework} and $<TARGET_OBJECTS:${framework}>
by ports.
Move the add_subdirectory of shell to the end of the CMakeLists.txt so its after the
WEBKIT_FRAMEWORK call. This ensures that the frameworks linked into JavaScriptCore are
known when creating the executables in that directory.
* CMakeLists.txt:
* PlatformGTK.cmake:
* PlatformJSCOnly.cmake:
* PlatformMac.cmake:
* PlatformPlayStation.cmake:
* shell/CMakeLists.txt:
2020-12-11 Dmitry Bezhetskov <dbezhetskov@igalia.com>
[WASM-References] Add table.init
https://bugs.webkit.org/show_bug.cgi?id=219297
Reviewed by Yusuke Suzuki.
Add support for table.init, elem.drop and new element section
from reference-type proposal:
https://webassembly.github.io/reference-types/core/syntax/instructions.html#table-instructions,
https://webassembly.github.io/reference-types/core/syntax/modules.html#element-segments.
All in one patch because all this stuff are very coupled and ref-types
spec tests require each other to run the its tests, so not to write
hand-crafted tests this is in one PR.
* bytecode/BytecodeList.rb:
* llint/WebAssembly.asm:
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::addTableInit):
(JSC::Wasm::AirIRGenerator::addElemDrop):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::addTableInit):
(JSC::Wasm::B3IRGenerator::addElemDrop):
* wasm/WasmFormat.h:
(JSC::Wasm::Element::Element):
(JSC::Wasm::Element::length const):
(JSC::Wasm::Element::isPassive const):
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseExpression):
* wasm/WasmInstance.cpp:
(JSC::Wasm::Instance::Instance):
(JSC::Wasm::Instance::elemDrop):
(JSC::Wasm::Instance::elem const):
(JSC::Wasm::Instance::initElementSegment):
(JSC::Wasm::Instance::tableInit):
* wasm/WasmInstance.h:
(JSC::Wasm::Instance::isImportFunction const):
* wasm/WasmLLIntGenerator.cpp:
(JSC::Wasm::LLIntGenerator::addTableInit):
(JSC::Wasm::LLIntGenerator::addElemDrop):
* wasm/WasmModuleInformation.h:
(JSC::Wasm::ModuleInformation::elementCount const):
* wasm/WasmOperations.cpp:
(JSC::Wasm::JSC_DEFINE_JIT_OPERATION):
* wasm/WasmOperations.h:
* wasm/WasmSectionParser.cpp:
(JSC::Wasm::SectionParser::parseElement):
(JSC::Wasm::SectionParser::parseElementSegmentVectorOfExpressions):
(JSC::Wasm::SectionParser::parseElementSegmentVectorOfIndexes):
(JSC::Wasm::SectionParser::parseFuncIndexFromRefExpForElementSection): Deleted.
(JSC::Wasm::SectionParser::parseFuncIndexForElementSection): Deleted.
* wasm/WasmSectionParser.h:
* wasm/WasmSlowPaths.cpp:
(JSC::LLInt::WASM_SLOW_PATH_DECL):
* wasm/WasmSlowPaths.h:
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::evaluate):
* wasm/wasm.json:
2020-12-11 Mark Lam <mark.lam@apple.com>
Add extra validation after untagging code pointers.
https://bugs.webkit.org/show_bug.cgi?id=219765
rdar://72069920
Reviewed by Robin Morisset.
* assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::untagReturnAddress):
(JSC::AbstractMacroAssembler::validateUntaggedPtr):
* assembler/MacroAssemblerARM64E.h:
(JSC::MacroAssemblerARM64E::untagReturnAddress):
(JSC::MacroAssemblerARM64E::validateUntaggedPtr):
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::reifyInlinedCallFrames):
* ftl/FTLThunks.cpp:
(JSC::FTL::genericGenerationThunkGenerator):
* jit/CCallHelpers.h:
(JSC::CCallHelpers::prepareForTailCallSlow):
* jit/CallFrameShuffler.cpp:
(JSC::CallFrameShuffler::prepareForTailCall):
* jit/ThunkGenerators.cpp:
(JSC::emitPointerValidation):
(JSC::arityFixupGenerator):
* llint/LLIntThunks.cpp:
(JSC::LLInt::createTailCallGate):
(JSC::LLInt::untagGateThunk):
* wasm/js/WebAssemblyFunction.cpp:
(JSC::WebAssemblyFunction::jsCallEntrypointSlow):
2020-12-10 Tadeu Zagallo <tzagallo@apple.com>
Removing unnecessary locking from JSValue API functions
https://bugs.webkit.org/show_bug.cgi?id=219723
Reviewed by Filip Pizlo.
Remove the unnecessary locking from the JSValueIs* and JSValueMake* API functions
that only work on primitives. Also remove the unnecessary method dispatching and
call from the -[JSValue is*] methods.
This improves the APIBench score by another ~8% since these are such common operations.
Here are the results: (Baseline includes https://bugs.webkit.org/show_bug.cgi?id=219663)
CURRENT_API: Baseline Change
----------------------------------------
RichardsMostlyC: 74ms 60ms
RichardsMostlyObjC: 304ms 300ms
RichardsMostlySwift: 305ms 293ms
RichardsSomeC: 97ms 77ms
RichardsSomeObjC: 158ms 159ms
RichardsSomeSwift: 202ms 198ms
UPCOMING_API: Baseline Change
----------------------------------------
RichardsMostlyC: 23ms 19ms
RichardsMostlyObjC: 282ms 282ms
RichardsMostlySwift: 280ms 282ms
RichardsSomeC: 95ms 76ms
RichardsSomeObjC: 157ms 156ms
RichardsSomeSwift: 202ms 197ms
----------------------------------------
Score: 33.6404 36.4006
* API/APICast.h:
(toRef):
* API/JSValue.mm:
(-[JSValue isUndefined]):
(-[JSValue isNull]):
(-[JSValue isBoolean]):
(-[JSValue isNumber]):
(-[JSValue isString]):
(-[JSValue isObject]):
(-[JSValue isSymbol]):
* API/JSValueRef.cpp:
(JSValueGetType):
(JSValueIsUndefined):
(JSValueIsNull):
(JSValueIsBoolean):
(JSValueIsNumber):
(JSValueIsString):
(JSValueIsObject):
(JSValueIsSymbol):
(JSValueMakeUndefined):
(JSValueMakeNull):
(JSValueMakeBoolean):
(JSValueMakeNumber):
2020-12-10 Alexey Shvayka <shvaikalesh@gmail.com>
Align [[DefineOwnProperty]] method of mapped arguments object with the spec
https://bugs.webkit.org/show_bug.cgi?id=219750
Reviewed by Yusuke Suzuki.
This patch reimplements [[DefineOwnProperty]] method to resemble the spec [1] as
closely as possible, aligning JSC with V8 and SpiderMonkey on remaining test262 cases.
Unlike the spec [2], JSC doesn't materialize mapped indices with initial values,
so putDirectIndex() is performed on the first call to handle incomplete descriptors.
Even though there is a possibility to avoid JSObject storage puts for a handful of
super rare descriptors, it's not worth the increased complexity.
[1]: https://tc39.es/ecma262/#sec-arguments-exotic-objects-defineownproperty-p-desc
[2]: https://tc39.es/ecma262/#sec-createmappedargumentsobject (step 15.b)
* runtime/GenericArgumentsInlines.h:
(JSC::GenericArguments<Type>::defineOwnProperty):
2020-12-10 Tadeu Zagallo <tzagallo@apple.com>
Add a JSC API to allow acquiring the JSLock
https://bugs.webkit.org/show_bug.cgi?id=219663
Reviewed by Filip Pizlo.
Introduce two new functions to the C API: JSLock and JSUnlock. These
functions allow users to take control of the JSContext's lock, which
can greatly reduce the overhead of bridging between JS and native.
* API/JSLockRef.cpp: Added.
(JSLock):
(JSUnlock):
* API/JSLockRefPrivate.h: Added.
* API/JSValueRef.cpp:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
2020-12-10 Don Olmstead <don.olmstead@sony.com>
[CMake] Determine when to use $<TARGET_OBJECTS> for executables
https://bugs.webkit.org/show_bug.cgi?id=219648
Reviewed by Michael Catanzaro.
Use ${taget_name}_FRAMEWORKS to specify WebKit frameworks when linking executables.
* CMakeLists.txt:
* shell/CMakeLists.txt:
2020-12-10 Don Olmstead <don.olmstead@sony.com>
[CMake] Use WEBKIT_EXECUTABLE macro for LLInt executables
https://bugs.webkit.org/show_bug.cgi?id=219746
Reviewed by Michael Catanzaro.
The LLInt executables were the only ones within Source that were being created
without the WEBKIT_EXECUTABLE macros.
* CMakeLists.txt:
2020-12-10 Patrick Angle <pangle@apple.com>
Web Inspector: Show current properties for font in new Elements sidebar Font panel
https://bugs.webkit.org/show_bug.cgi?id=218964
Reviewed by Devin Rousso.
Adds objects and method for getting font data for a node to the `CSS` domain. A `CSS.Font` is meant to represent
a `WebCore::Font` and contain information about the underlying font as the system sees it. The source for this
information can be a system font or a web font. Each `CSS.Font` in turn can have some number of
`CSS.FontVariationAxis` for its available open-type variation axes. Fonts that don't support these features will
have an empty set of axes.
* inspector/protocol/CSS.json:
- Added objects and method for getting font data for a node.
2020-12-10 Don Olmstead <don.olmstead@sony.com>
[CMake] Use TARGET_PROPERTY to set includes for executables
https://bugs.webkit.org/show_bug.cgi?id=219743
Reviewed by Michael Catanzaro.
Use $<TARGET_PROPERTY:JavaScriptCore,INCLUDE_DIRECTORIES> for all executables being
built alongside JavaScriptCore. This simplifies the includes for those targets.
Additionally relocate the setting of include directories for LLInt executables
so they're next to the rest of their definitions.
* CMakeLists.txt:
* shell/CMakeLists.txt:
2020-12-09 Dmitry Bezhetskov <dbezhetskov@igalia.com>
Fix redundant assert
https://bugs.webkit.org/show_bug.cgi?id=219725
Reviewed by Ross Kirsling.
* runtime/JSArrayBufferPrototype.cpp:
(JSC::arrayBufferSlice):
2020-12-08 Ross Kirsling <ross.kirsling@sony.com>
Unreviewed debug test fix following r270552.
* runtime/JSGenericTypedArrayViewConstructorInlines.h:
(JSC::constructCustomArrayBufferIfNeeded):
(JSC::constructGenericTypedArrayViewWithArguments):
Add missing exception check (and rearrange slightly).
2020-12-08 Ross Kirsling <ross.kirsling@sony.com>
Unreviewed non-unified build fix following r270552.
* runtime/JSArrayBufferPrototypeInlines.h:
2020-12-08 Ross Kirsling <ross.kirsling@sony.com>
Align %TypedArray% constructor behavior with spec
https://bugs.webkit.org/show_bug.cgi?id=219527
Reviewed by Yusuke Suzuki.
These should be the last JSC-side corrections for typed array behavior:
namely, fixes for the constructor itself.
Broadly speaking, there are three fixes here:
1. ArrayBuffer argument (https://tc39.es/ecma262/#sec-initializetypedarrayfromarraybuffer):
We need to throw if the input buffer gets detached.
2. Array-like argument (https://tc39.es/ecma262/#sec-initializetypedarrayfromarraylike):
length needs toLength, not toUInt32.
3. Typed array argument (https://tc39.es/ecma262/#sec-initializetypedarrayfromtypedarray):
We need to support the case where the input typed array uses a custom ArrayBuffer.
This case is *extremely* strange -- we still create the same type of typed array with a normal ArrayBuffer,
but we override the prototype of that ArrayBuffer to inputTypedArray.buffer.constructor[@@species].prototype.
* JavaScriptCore.xcodeproj/project.pbxproj:
* runtime/JSArrayBufferConstructor.cpp:
* runtime/JSArrayBufferPrototype.cpp:
(JSC::arrayBufferSpeciesConstructorSlow): Added.
(JSC::speciesWatchpointIsValid): Moved.
* runtime/JSArrayBufferPrototype.h:
* runtime/JSArrayBufferPrototypeInlines.h: Added.
* runtime/JSGenericTypedArrayViewConstructorInlines.h:
(JSC::constructCustomArrayBufferIfNeeded): Added.
(JSC::constructGenericTypedArrayViewWithArguments):
* runtime/JSGlobalObject.h:
2020-12-08 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Enable "at" methods
https://bugs.webkit.org/show_bug.cgi?id=219631
Reviewed by Ross Kirsling.
This patch enables "at" methods in Array, String, and %TypedArray% by flipping runtime flag.
* runtime/OptionsList.h:
2020-12-08 Caio Lima <ticaiolima@gmail.com>
[ESNext] op_put_private_name is wrong
https://bugs.webkit.org/show_bug.cgi?id=219616
Reviewed by Tadeu Zagallo.
Since `m_property` is a JSCell pointer, we need to use both `loadp`
and `bpneq` on `op_put_private_name`.
* llint/LowLevelInterpreter64.asm:
2020-12-07 Dmitry Bezhetskov <dbezhetskov@igalia.com>
[WASM-References] Add support for table.copy
https://bugs.webkit.org/show_bug.cgi?id=219427
Reviewed by Yusuke Suzuki.
Add support for table.copy from reference types proposal:
https://webassembly.github.io/reference-types/core/syntax/instructions.html#table-instructions.
The table.copy instruction accepts three stack arguments (destination
offset, source offset, length) and two immediates for table indexes
and copies items from one wasm table to another.
* bytecode/BytecodeList.rb:
* llint/WebAssembly.asm:
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::addTableFill):
(JSC::Wasm::AirIRGenerator::addTableCopy):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::addTableFill):
(JSC::Wasm::B3IRGenerator::addTableCopy):
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseExpression):
* wasm/WasmInstance.cpp:
(JSC::Wasm::Instance::tableCopy):
* wasm/WasmInstance.h:
* wasm/WasmLLIntGenerator.cpp:
(JSC::Wasm::LLIntGenerator::addTableCopy):
* wasm/WasmOperations.cpp:
(JSC::Wasm::isSumOverflow):
(JSC::Wasm::JSC_DEFINE_JIT_OPERATION):
* wasm/WasmOperations.h:
* wasm/WasmSectionParser.cpp:
(JSC::Wasm::SectionParser::parseElement):
* wasm/WasmSlowPaths.cpp:
(JSC::LLInt::WASM_SLOW_PATH_DECL):
* wasm/WasmSlowPaths.h:
* wasm/WasmTable.cpp:
(JSC::Wasm::Table::copy):
(JSC::Wasm::FuncRefTable::copyFunction):
* wasm/WasmTable.h:
* wasm/wasm.json:
2020-12-07 Don Olmstead <don.olmstead@sony.com>
[CMake] Remove WEBKIT_WRAP_SOURCELIST
https://bugs.webkit.org/show_bug.cgi?id=196916
Reviewed by Michael Catanzaro.
* CMakeLists.txt:
2020-12-06 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] get / set for object literal and class should not be escaped
https://bugs.webkit.org/show_bug.cgi?id=219576
Reviewed by Alexey Shvayka.
"get" and "set" for getter and setter should not be escaped one.
Terminal symbols of the lexical grammars are shown in fixed width font [1],
and are to appear in a script exactly as written.
[1]: https://tc39.es/ecma262/#sec-method-definitions
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseClass):
(JSC::Parser<LexerType>::parseProperty):
2020-12-05 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Accept escaped keywords for class and object property names
https://bugs.webkit.org/show_bug.cgi?id=219575
Reviewed by Alexey Shvayka.
In this patch, we accept escaped keywords for class, object, and object pattern property names.
var object = {
bre\u0061k: 42
};
When escaped keyword appears, we produce ESCAPED_KEYWORD with CanBeErrorTokenFlag. Now CanBeErrorTokenFlag
represents "when this token appears in an error condition, possibly this is error token and special message will appear",
instead of saying this token is definitely an error. So we can just use ESCAPED_KEYWORD token to handle this case.
* parser/Lexer.cpp:
(JSC::Lexer<CharacterType>::parseIdentifierSlowCase):
(JSC::Lexer<T>::lexWithoutClearingLineTerminator):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseDestructuringPattern):
(JSC::Parser<LexerType>::parseClass):
(JSC::Parser<LexerType>::parseProperty):
(JSC::Parser<LexerType>::printUnexpectedTokenText):
* parser/Parser.h:
(JSC::Parser<LexerType>::parse):
* parser/ParserTokens.h:
2020-12-04 Adam Roben <aroben@apple.com>
More FALLBACK_PLATFORM adoption
https://bugs.webkit.org/show_bug.cgi?id=219545
Reviewed by Tim Horton.
* Configurations/SDKVariant.xcconfig:
WK_EMPTY_$(THIS_IS_NOT_EMPTY) evaluates to the empty string, not to
NO.
2020-12-04 Caio Lima <ticaiolima@gmail.com>
[JIT] Value profile stores wrong value in BaselineJIT for some operations
https://bugs.webkit.org/show_bug.cgi?id=219535
Reviewed by Mark Lam.
This patch is a follow up from r270423 to fix 32-bits baseline JIT
code from `op_iterator_next`. It's also fixing wrong profile value for
`op_get_prototype_of`.
* jit/JITCall32_64.cpp:
(JSC::JIT::emit_op_iterator_next):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_get_prototype_of):
2020-12-03 Saam Barati <sbarati@apple.com>
"done" checkpoint of iterator_next stores the wrong register in the value profile in baseline JIT
https://bugs.webkit.org/show_bug.cgi?id=219501
Reviewed by Keith Miller.
* jit/JIT.h:
* jit/JITCall.cpp:
(JSC::JIT::emit_op_iterator_next):
* jit/JITInlines.h:
(JSC::JIT::emitValueProfilingSite):
(JSC::JIT::emitValueProfilingSiteIfProfiledOpcode):
2020-12-03 Adam Roben <aroben@apple.com>
Adopt FALLBACK_PLATFORM
https://bugs.webkit.org/show_bug.cgi?id=219504
Reviewed by Tim Horton.
* Configurations/SDKVariant.xcconfig:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Scripts/check-xcfilelists.sh:
Use FALLBACK_PLATFORM it if it's defined, otherwise use PLATFORM_NAME
as before.
2020-12-03 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] not using std::make_pair for workaround of (possibly) ASan bug
https://bugs.webkit.org/show_bug.cgi?id=219502
<rdar://71642789>
Reviewed by Robin Morisset.
We are getting ASan crash in LayoutTests/fast/canvas/webgl/array-unit-tests.html after r269574.
However, this is inside std::make_pair, and it looks like a bug in ASan.
To workaround this for now, we avoid using std::make_pair and instead just using C++ uniform initialization.
* runtime/JSArrayBufferPrototype.cpp:
2020-12-03 Saam Barati <sbarati@apple.com>
JIT::emit_op_iterator_next fast path passes in the wrong identifier to the "done" JITGetByIdGenerator
https://bugs.webkit.org/show_bug.cgi?id=219499
Reviewed by Keith Miller.
The reason nothing was failing here is that the slow path which calls into C
code to do repatching of the IC was using the right "done" identifier. The
fast path only checks if the identifier is "length", so the code sidestepped
itself being wrong in any way. However, it's good form to use the correct
identifier.
* jit/JITCall.cpp:
(JSC::JIT::emit_op_iterator_next):
2020-12-03 Lauro Moura <lmoura@igalia.com>
[WTF] Avoid JSONValue::create with raw string falling to bool overload
https://bugs.webkit.org/show_bug.cgi?id=219483
Reviewed by Adrian Perez de Castro.
* inspector/InjectedScriptBase.cpp:
(Inspector::InjectedScriptBase::makeAsyncCall): Convert to WTF::String when creating the value.
2020-12-02 Michael Catanzaro <mcatanzaro@gnome.org>
aarch64 llint does not build with JIT disabled
https://bugs.webkit.org/show_bug.cgi?id=219288
<rdar://problem/71855960>
Reviewed by Darin Adler.
* assembler/ARM64Assembler.h: Rename USE(JUMP_ISLANDS) to ENABLE(JUMP_ISLANDS).
(JSC::ARM64Assembler::replaceWithJump):
(JSC::ARM64Assembler::linkJumpOrCall):
* assembler/AbstractMacroAssembler.h: Rename USE(JUMP_ISLANDS) to ENABLE(JUMP_ISLANDS).
(JSC::AbstractMacroAssembler::prepareForAtomicRepatchNearCallConcurrently):
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::copyCompactAndLinkCode): Guard JIT-specific code with ENABLE(JIT).
* jit/ExecutableAllocator.cpp: Rename USE(JUMP_ISLANDS) to ENABLE(JUMP_ISLANDS).
(JSC::initializeJITPageReservation):
* jit/ExecutableAllocator.h: Rename USE(JUMP_ISLANDS) to ENABLE(JUMP_ISLANDS).
2020-12-02 Ross Kirsling <ross.kirsling@sony.com>
%TypedArray%#slice shouldn't care about source buffer detachment if there's nothing to copy
https://bugs.webkit.org/show_bug.cgi?id=219451
Reviewed by Yusuke Suzuki.
From https://tc39.es/ecma262/#sec-%typedarray%.prototype.slice:
13. Let A be ? TypedArraySpeciesCreate(O, « 𝔽(count) »).
14. If count > 0, then
a. If IsDetachedBuffer(O.[[ViewedArrayBuffer]]) is true, throw a TypeError exception.
...
15. Return A.
We had step 14.a raised above 14; this patch fixes the ordering.
* runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
(JSC::genericTypedArrayViewProtoFuncSlice):
2020-12-02 Dmitry Bezhetskov <dbezhetskov@igalia.com>
[WASM-References] Add support for active mods in element section
https://bugs.webkit.org/show_bug.cgi?id=219192
Reviewed by Yusuke Suzuki.
Adjust wasm parser to parse new form of element section.
https://webassembly.github.io/reference-types/core/binary/modules.html#element-section.
* wasm/WasmEntryPlan.cpp:
(JSC::Wasm::EntryPlan::prepare):
* wasm/WasmFormat.h:
(JSC::Wasm::Element::Element):
(JSC::Wasm::Element::active const):
* wasm/WasmSectionParser.cpp:
(JSC::Wasm::SectionParser::parseElement):
(JSC::Wasm::SectionParser::validateElementTableIdx):
(JSC::Wasm::SectionParser::parseI32InitExpr):
(JSC::Wasm::SectionParser::parseElemKind):
(JSC::Wasm::SectionParser::parseIndexCountForElemSection):
(JSC::Wasm::SectionParser::parseFuncIdxFromRefExpForElemSection):
(JSC::Wasm::SectionParser::parseFuncIdxForElemSection):
* wasm/WasmSectionParser.h:
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::evaluate):
2020-12-01 Sergey Rubanov <chi187@gmail.com>
Fix Aarch64 build failure
https://bugs.webkit.org/show_bug.cgi?id=219395
Reviewed by Yusuke Suzuki.
* offlineasm/arm64.rb:
2020-12-01 Keith Rollin <krollin@apple.com>
Consolidate header postprocessing scripts
https://bugs.webkit.org/show_bug.cgi?id=219388
<rdar://problem/71840357>
Reviewed by David Kilzer.
Our build system contains the following scripts to perform some
postprocessing of headers that we export to the SDK:
JavaScriptCore/postprocess-headers.sh
WebKit/mac/postprocess-framework-headers.sh
WebKitLegacy/mac/postprocess-headers.sh
The preceding scripts are used when using the non-XCBuild -- or
"legacy" -- Xcode build system. They are invoked in a custom Run
Script build phase after the headers have been exported with the
standard Xcode facility for creating frameworks.
Alternatively, we also have the following postprocessing scripts:
WebKit/Scripts/postprocess-header-rule
JavaScriptCore/Scripts/postprocess-header-rule
WebKitLegacy/scripts/postprocess-header-rule
These scripts are used when using the XCBuild build system. They are
invoked *during* the header export process to copy and postprocess the
headers in one blow. They are part of a Custom Build Rule for
exporting files ending in ".h".
The reason why we have two sets of scripts is because of the different
capabilities of the two Xcode build systems. The legacy system does
not support a custom "export header" step that would allow us to copy
and postprocess each header in a single step. Therefore, when using
the legacy build system, we export in one build step and postprocess
in a subsequent build step. And XCBuild doesn't like the approach
taken by the old build system where files are exported first and then
munged in a separate step, since that confuses its notion of the state
of the build ("Hey! That file I exported in the previous build? I see
now that it's been changed, so I'm going to export it again. And
change its modification date. And then rebuild everything downstream
that uses it."). Therefore, XCBuild added a facility for copying and
postprocessing in one step.
The scripts supporting each of these approaches are very similar to
each other, such that there is a lot of code duplication between them.
At the same time, by having two sets of scripts that are very similar
to each other, we run the risk of "drift", where files in one set may
get updated while their counterparts in the other set are not.
Address this duplication by making the scripts in the "legacy" set be
mere stubs that invoke the scripts in the new "XCBuild" set. In doing
this, we also fix a case of drift: the legacy-based scripts made use
of a timestamp file to determine if headers needed to be reprocessed
and exported, while the XCBuild-based scripts used a "process the
files and export them if any actual changes now exist between this new
version and any previously-exported version" approach.
Along the way, fix a bug in WebKitLegacy's postprocess-header-rule
that resulted in WebKitAvailability.h not being processed. The
practical effect of this bug is that the file ended up with both macOS
and iOS code, along with the #if that controlled which chunk of code
was compiled, instead of just the chunk of code specific to the
targeted SDK. Normally, the unused chunk of code would get removed
through the invocation of `unifdef`. But, because of the bug, the
results of running `unifdef` were being discarded.
* postprocess-headers.sh:
2020-12-01 Alexey Shvayka <shvaikalesh@gmail.com>
Remove unused getPrimitiveNumber() methods
https://bugs.webkit.org/show_bug.cgi?id=219370
Reviewed by Mark Lam.
These methods were originated in KJS, have weird signature / return value,
are currently unused, and were displaced by toNumber() / toPrimitive().
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::getPrimitiveNumber const): Deleted.
* runtime/JSBigInt.h:
* runtime/JSCJSValue.h:
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::getPrimitiveNumber): Deleted.
* runtime/JSCell.cpp:
(JSC::JSCell::getPrimitiveNumber const): Deleted.
* runtime/JSCell.h:
* runtime/JSObject.cpp:
(JSC::JSObject::getPrimitiveNumber const): Deleted.
* runtime/JSObject.h:
* runtime/JSString.cpp:
(JSC::JSString::getPrimitiveNumber const): Deleted.
* runtime/JSString.h:
(JSC::JSString::toBoolean const):
* runtime/Symbol.cpp:
(JSC::Symbol::getPrimitiveNumber const): Deleted.
* runtime/Symbol.h:
2020-12-01 Lauro Moura <lmoura@igalia.com>
[JSC] Make Bytecodes generator command also depend on wasm.json
https://bugs.webkit.org/show_bug.cgi?id=219383
Reviewed by Adrian Perez de Castro.
r270265 added some new operations to wasm.json but its change did not
trigger the bytecodes generator command, causing the build to fail in
some platforms (in fact, it was caught by GTK and WPE EWS bots).
* CMakeLists.txt: Add wasm.json as dependency to the bytecodes.h generator
command.
2020-11-30 Yusuke Suzuki <ysuzuki@apple.com>
Making module entry promise-like by setting "then"
https://bugs.webkit.org/show_bug.cgi?id=216695
Reviewed by Saam Barati.
Setting then: @undefined to make entry promise-like.
We also optimize @InternalPromise.internalAll a bit.
* builtins/InternalPromiseConstructor.js:
(internalAll.newResolveElement):
(internalAll):
* builtins/ModuleLoader.js:
(globalPrivate.newRegistryEntry):
(requestImportModule):
(async requestImportModule): Deleted.
* builtins/PromiseOperations.js:
(globalPrivate.fulfillPromiseWithFirstResolvingFunctionCallCheck):
2020-11-30 Sergey Rubanov <chi187@gmail.com>
Add support for the Wasm i64 sign-extension-ops proposal
https://bugs.webkit.org/show_bug.cgi?id=218990
Reviewed by Yusuke Suzuki.
* llint/WebAssembly.asm:
* offlineasm/arm64.rb:
* offlineasm/cloop.rb:
* offlineasm/instructions.rb:
* offlineasm/x86.rb:
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64Extend8S>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64Extend16S>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I64Extend32S>):
* wasm/wasm.json:
2020-11-28 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, follow-up after r270214
https://bugs.webkit.org/show_bug.cgi?id=219281
ARM64 does not support unary Not32 / Not64.
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::emitAtomicBinaryRMWOp):
2020-11-27 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Use ARM atomic ops in wasm
https://bugs.webkit.org/show_bug.cgi?id=219281
Reviewed by Filip Pizlo.
This patch uses ARM LSE Atomic instructions in wasm atomic operations. This includes support in MacroAssembler, offlineasm, Air and B3,
so that FTL atomic operations automatically leverage ARM LSE atomic instructions too. Later we can extend DFG JIT to use it too.
One interesting thing is that this includes a fix for cmpxchg wasm operation implementations. Unfortunately, current wasm cmpxchg ops
are not the same to ARM cas / X86 cmpxchg. For example, i64.atomic.rmw8.cmpxchg_u takes i64 expected value. And the spec requires that
we should perform `i64-expected-value <cmp> loaded-zero-extended-1byte-value`. For example, if the expected value is `0xffffffff_ffffff00`,
and the value stored in the memory is `0x00`, then the wasm op needs to fail since `0x00` is not `0xffffffff_ffffff00`. But x86 and ARM
cmpxchg / cas ops behave differently since it truncates expected value to 1byte when performing 1byte cmpxchg. So we need to have a check
which performs the value is within 1byte range in this operation.
* assembler/ARM64EAssembler.h:
(JSC::ARM64EAssembler::exoticAtomicLoadStore):
(JSC::ARM64EAssembler::exoticAtomicCAS):
(JSC::ARM64EAssembler::ldaddal):
(JSC::ARM64EAssembler::ldeoral):
(JSC::ARM64EAssembler::ldclral):
(JSC::ARM64EAssembler::ldsetal):
(JSC::ARM64EAssembler::swpal):
(JSC::ARM64EAssembler::casal):
* assembler/MacroAssemblerARM64E.h:
(JSC::MacroAssemblerARM64E::atomicXchgAdd8):
(JSC::MacroAssemblerARM64E::atomicXchgAdd16):
(JSC::MacroAssemblerARM64E::atomicXchgAdd32):
(JSC::MacroAssemblerARM64E::atomicXchgAdd64):
(JSC::MacroAssemblerARM64E::atomicXchgXor8):
(JSC::MacroAssemblerARM64E::atomicXchgXor16):
(JSC::MacroAssemblerARM64E::atomicXchgXor32):
(JSC::MacroAssemblerARM64E::atomicXchgXor64):
(JSC::MacroAssemblerARM64E::atomicXchgOr8):
(JSC::MacroAssemblerARM64E::atomicXchgOr16):
(JSC::MacroAssemblerARM64E::atomicXchgOr32):
(JSC::MacroAssemblerARM64E::atomicXchgOr64):
(JSC::MacroAssemblerARM64E::atomicXchgClear8):
(JSC::MacroAssemblerARM64E::atomicXchgClear16):
(JSC::MacroAssemblerARM64E::atomicXchgClear32):
(JSC::MacroAssemblerARM64E::atomicXchgClear64):
(JSC::MacroAssemblerARM64E::atomicXchg8):
(JSC::MacroAssemblerARM64E::atomicXchg16):
(JSC::MacroAssemblerARM64E::atomicXchg32):
(JSC::MacroAssemblerARM64E::atomicXchg64):
(JSC::MacroAssemblerARM64E::atomicStrongCAS8):
(JSC::MacroAssemblerARM64E::atomicStrongCAS16):
(JSC::MacroAssemblerARM64E::atomicStrongCAS32):
(JSC::MacroAssemblerARM64E::atomicStrongCAS64):
* b3/B3LowerMacros.cpp:
* b3/B3LowerToAir.cpp:
* b3/air/AirOpcode.opcodes:
* b3/air/opcode_generator.rb:
* disassembler/ARM64/A64DOpcode.cpp:
(JSC::ARM64Disassembler::A64DOpcodeLoadAtomic::format):
(JSC::ARM64Disassembler::A64DOpcodeSwapAtomic::format):
(JSC::ARM64Disassembler::A64DOpcodeCAS::format):
* disassembler/ARM64/A64DOpcode.h:
(JSC::ARM64Disassembler::A64DOpcode::appendInstructionName):
(JSC::ARM64Disassembler::A64DOpcodeLoadAtomic::opName):
(JSC::ARM64Disassembler::A64DOpcodeLoadAtomic::rs):
(JSC::ARM64Disassembler::A64DOpcodeLoadAtomic::opc):
(JSC::ARM64Disassembler::A64DOpcodeLoadAtomic::ar):
(JSC::ARM64Disassembler::A64DOpcodeLoadAtomic::opNumber):
(JSC::ARM64Disassembler::A64DOpcodeSwapAtomic::opName):
(JSC::ARM64Disassembler::A64DOpcodeSwapAtomic::rs):
(JSC::ARM64Disassembler::A64DOpcodeSwapAtomic::ar):
(JSC::ARM64Disassembler::A64DOpcodeSwapAtomic::opNumber):
(JSC::ARM64Disassembler::A64DOpcodeCAS::opName):
(JSC::ARM64Disassembler::A64DOpcodeCAS::rs):
(JSC::ARM64Disassembler::A64DOpcodeCAS::o1):
(JSC::ARM64Disassembler::A64DOpcodeCAS::l):
(JSC::ARM64Disassembler::A64DOpcodeCAS::opNumber):
* llint/WebAssembly.asm:
* offlineasm/arm64.rb:
* offlineasm/instructions.rb:
* offlineasm/x86.rb:
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::sanitizeAtomicResult):
(JSC::Wasm::AirIRGenerator::appendGeneralAtomic):
(JSC::Wasm::AirIRGenerator::appendStrongCAS):
(JSC::Wasm::AirIRGenerator::emitAtomicLoadOp):
(JSC::Wasm::AirIRGenerator::emitAtomicStoreOp):
(JSC::Wasm::AirIRGenerator::emitAtomicBinaryRMWOp):
(JSC::Wasm::AirIRGenerator::emitAtomicCompareExchange):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::emitAtomicCompareExchange):
2020-11-26 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Add wasm atomics instructions
https://bugs.webkit.org/show_bug.cgi?id=218954
Reviewed by Filip Pizlo.
This patch implements wasm threading's atomic operations[1] in X86_64 and ARM64. Currently, all ARM64 atomic operations are implemented by using LL/SC.
Later, we will use ARM64 CAS operations if possible, at least in ARM64E.
To test it easily, we also extend jsc shell's worker to support transferring shared WebAssembly.Memory so that we can use wasm atomic operations in several
workers in jsc shell.
[1]: https://github.com/WebAssembly/threads
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::atomicXchg8):
(JSC::MacroAssemblerX86Common::atomicXchg16):
(JSC::MacroAssemblerX86Common::atomicXchg32):
* b3/B3Kind.h:
(JSC::B3::Kind::hasTraps const):
* b3/B3LowerToAir.cpp:
* b3/B3Width.h:
(JSC::B3::bytesForWidth):
* b3/testb3_8.cpp:
(testAtomicXchg):
* bytecode/BytecodeList.rb:
* interpreter/Register.h:
(JSC::Register::unboxedInt64 const):
(JSC::Register::asanUnsafeUnboxedInt64 const):
* jsc.cpp:
(Message::releaseContents):
(Message::Message):
(JSC_DEFINE_HOST_FUNCTION):
* llint/WebAssembly.asm:
* offlineasm/arm64.rb:
* offlineasm/instructions.rb:
* offlineasm/x86.rb:
* runtime/OptionsList.h:
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::appendEffectful):
(JSC::Wasm::accessWidth):
(JSC::Wasm::sizeOfAtomicOpMemoryAccess):
(JSC::Wasm::AirIRGenerator::fixupPointerPlusOffsetForAtomicOps):
(JSC::Wasm::AirIRGenerator::sanitizeAtomicResult):
(JSC::Wasm::AirIRGenerator::appendGeneralAtomic):
(JSC::Wasm::AirIRGenerator::appendStrongCAS):
(JSC::Wasm::AirIRGenerator::emitAtomicLoadOp):
(JSC::Wasm::AirIRGenerator::atomicLoad):
(JSC::Wasm::AirIRGenerator::emitAtomicStoreOp):
(JSC::Wasm::AirIRGenerator::atomicStore):
(JSC::Wasm::AirIRGenerator::emitAtomicBinaryRMWOp):
(JSC::Wasm::AirIRGenerator::atomicBinaryRMW):
(JSC::Wasm::AirIRGenerator::emitAtomicCompareExchange):
(JSC::Wasm::AirIRGenerator::atomicCompareExchange):
(JSC::Wasm::AirIRGenerator::atomicWait):
(JSC::Wasm::AirIRGenerator::atomicNotify):
(JSC::Wasm::AirIRGenerator::atomicFence):
(JSC::Wasm::AirIRGenerator::addCall):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer):
(JSC::Wasm::B3IRGenerator::memoryKind):
(JSC::Wasm::accessWidth):
(JSC::Wasm::sizeOfAtomicOpMemoryAccess):
(JSC::Wasm::B3IRGenerator::sanitizeAtomicResult):
(JSC::Wasm::B3IRGenerator::fixupPointerPlusOffsetForAtomicOps):
(JSC::Wasm::B3IRGenerator::emitAtomicLoadOp):
(JSC::Wasm::B3IRGenerator::atomicLoad):
(JSC::Wasm::B3IRGenerator::emitAtomicStoreOp):
(JSC::Wasm::B3IRGenerator::atomicStore):
(JSC::Wasm::B3IRGenerator::emitAtomicBinaryRMWOp):
(JSC::Wasm::B3IRGenerator::atomicBinaryRMW):
(JSC::Wasm::B3IRGenerator::emitAtomicCompareExchange):
(JSC::Wasm::B3IRGenerator::atomicCompareExchange):
(JSC::Wasm::B3IRGenerator::atomicWait):
(JSC::Wasm::B3IRGenerator::atomicNotify):
(JSC::Wasm::B3IRGenerator::atomicFence):
(JSC::Wasm::B3IRGenerator::addCall):
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::atomicLoad):
(JSC::Wasm::FunctionParser<Context>::atomicStore):
(JSC::Wasm::FunctionParser<Context>::atomicBinaryRMW):
(JSC::Wasm::FunctionParser<Context>::atomicCompareExchange):
(JSC::Wasm::FunctionParser<Context>::atomicWait):
(JSC::Wasm::FunctionParser<Context>::atomicNotify):
(JSC::Wasm::FunctionParser<Context>::atomicFence):
(JSC::Wasm::FunctionParser<Context>::parseExpression):
(JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
* wasm/WasmLLIntGenerator.cpp:
(JSC::Wasm::LLIntGenerator::atomicLoad):
(JSC::Wasm::LLIntGenerator::atomicStore):
(JSC::Wasm::LLIntGenerator::atomicBinaryRMW):
(JSC::Wasm::LLIntGenerator::atomicCompareExchange):
(JSC::Wasm::LLIntGenerator::atomicWait):
(JSC::Wasm::LLIntGenerator::atomicNotify):
(JSC::Wasm::LLIntGenerator::atomicFence):
* wasm/WasmMemory.h:
* wasm/WasmMemoryInformation.cpp:
(JSC::Wasm::MemoryInformation::MemoryInformation):
* wasm/WasmMemoryInformation.h:
(JSC::Wasm::MemoryInformation::isShared const):
* wasm/WasmOperations.cpp:
(JSC::Wasm::wait):
(JSC::Wasm::JSC_DEFINE_JIT_OPERATION):
* wasm/WasmOperations.h:
* wasm/WasmSectionParser.cpp:
(JSC::Wasm::SectionParser::parseResizableLimits):
(JSC::Wasm::SectionParser::parseTableHelper):
(JSC::Wasm::SectionParser::parseMemoryHelper):
* wasm/WasmSectionParser.h:
* wasm/WasmSlowPaths.cpp:
(JSC::LLInt::WASM_SLOW_PATH_DECL):
* wasm/WasmSlowPaths.h:
* wasm/generateWasm.py:
(isAtomic):
(isAtomicLoad):
(isAtomicStore):
(isAtomicBinaryRMW):
(memoryLog2Alignment):
* wasm/generateWasmOpsHeader.py:
(atomicMemoryLoadMacroizer):
(atomicMemoryLoadMacroizer.modifier):
(atomicMemoryStoreMacroizer):
(atomicMemoryStoreMacroizer.modifier):
(atomicBinaryRMWMacroizer):
(atomicBinaryRMWMacroizer.modifier):
(memoryLog2AlignmentGenerator):
(atomicMemoryLog2AlignmentGenerator):
(ExtAtomicOpType):
* wasm/js/JSWebAssemblyInstance.cpp:
(JSC::JSWebAssemblyInstance::tryCreate):
* wasm/wasm.json:
2020-11-19 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Enable private instance and static fields
https://bugs.webkit.org/show_bug.cgi?id=219179
Reviewed by Mark Lam.
Enable private instance and static fields. We are not supporting private methods and static private methods yet.
* runtime/OptionsList.h:
2020-11-19 Saam Barati <sbarati@apple.com>
Use os_thread_self_restrict_rwx_is_supported instead of pthread_jit_write_protect_supported_np on Apple Internal SDK builds
https://bugs.webkit.org/show_bug.cgi?id=219099
<rdar://problem/71547048>
Reviewed by Mark Lam.
* assembler/FastJITPermissions.h:
(useFastJITPermissions):
(threadSelfRestrictRWXToRW):
(threadSelfRestrictRWXToRX):
2020-11-19 Xan López <xan@igalia.com>
[JSC] Add support for static private class fields
https://bugs.webkit.org/show_bug.cgi?id=214297
Reviewed by Yusuke Suzuki.
Static private fields come trivially now that both private and
static (public) fields are implemented.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseClass): accept static private fields if the runtime option allows it.
* runtime/Options.cpp:
(JSC::Options::recomputeDependentOptions): usePrivateStaticClassFields depends on usePrivateClassFields.
* runtime/OptionsList.h: add runtime option to enable static private fields.
* tools/JSDollarVM.cpp: add a method to check for private symbols in the stress tests.
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::JSDollarVM::finishCreation):
2020-11-19 Adrian Perez de Castro <aperez@igalia.com>
[JSC] Build failed due to unknown values in LLIntDesiredOffsets.h
https://bugs.webkit.org/show_bug.cgi?id=219158
Reviewed by Don Olmstead.
CMake uses the contents of the variables OFFLINE_ASM and GENERATOR as part of the
dependencies that cause LLIntDesiredOffsets.h to be regenerated, so add to them
those files missing from the lists.
* CMakeLists.txt: Update OFFLINE_ASM and GENERATOR lists.
2020-11-18 Dmitry Bezhetskov <dbezhetskov@igalia.com>
[WASM-References] Remove subtyping rule for externref and funcref
https://bugs.webkit.org/show_bug.cgi?id=218885
Reviewed by Yusuke Suzuki.
Make funcref is not a subtype of externref.
The spec: https://webassembly.github.io/reference-types/core/
The PR for removing subtype from the spec:
https://github.com/WebAssembly/reference-types/pull/87.
* wasm/WasmFormat.h:
(JSC::Wasm::isSubtype):
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseExpression):
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::link):
2020-11-18 Ross Kirsling <ross.kirsling@sony.com>
[JSC] Reinstate String#at
https://bugs.webkit.org/show_bug.cgi?id=219124
Reviewed by Yusuke Suzuki.
At this week's TC39 meeting, consensus was achieved on renaming item() *and* keeping it for strings too.
Accordingly, this patch reinstates String.prototype.at behind the existing useAtMethod runtime option.
* builtins/StringPrototype.js:
(at):
* runtime/StringPrototype.cpp:
(JSC::StringPrototype::finishCreation):
2020-11-17 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Improve Wasm binary test coverage
https://bugs.webkit.org/show_bug.cgi?id=204843
Reviewed by Darin Adler.
This patch fixes some of bugs in wasm parser so that we validate malformed wasm modules more strictly.
1. current_memory / grow_memory should have uint8 flag, not varuint32 flag.
2. global section should have uint8 mutability information, not varuint32.
3. memory section should have varuint32 memory count.
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseExpression):
(JSC::Wasm::FunctionParser<Context>::parseUnreachableExpression):
* wasm/WasmSectionParser.cpp:
(JSC::Wasm::SectionParser::parseResizableLimits):
(JSC::Wasm::SectionParser::parseMemory):
(JSC::Wasm::SectionParser::parseGlobalType):
* wasm/wasm.json:
2020-11-18 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, relanding r269940
https://bugs.webkit.org/show_bug.cgi?id=219076
ARM64E clang optimizer is broken and optimizing forever if Wasm::MemoryHandle::memory() is inlined.
Putting NEVER_INLINE onto this function for now (unfortunate).
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* llint/LLIntPCRanges.h:
(JSC::LLInt::isWasmLLIntPC):
* llint/LowLevelInterpreter.asm:
* llint/WebAssembly.asm:
* runtime/JSArrayBuffer.h:
(JSC::JSArrayBuffer::toWrappedAllowShared):
* runtime/JSArrayBufferView.h:
* runtime/JSArrayBufferViewInlines.h:
(JSC::JSArrayBufferView::toWrappedAllowShared):
* runtime/JSGenericTypedArrayView.h:
(JSC::JSGenericTypedArrayView<Adaptor>::toWrappedAllowShared):
* runtime/Options.cpp:
(JSC::overrideDefaults):
(JSC::Options::initialize):
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::AirIRGenerator):
(JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState):
(JSC::Wasm::AirIRGenerator::addCurrentMemory):
(JSC::Wasm::AirIRGenerator::emitCheckAndPreparePointer):
(JSC::Wasm::AirIRGenerator::addCall):
(JSC::Wasm::AirIRGenerator::addCallIndirect):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::B3IRGenerator):
(JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
(JSC::Wasm::B3IRGenerator::addCurrentMemory):
(JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer):
(JSC::Wasm::B3IRGenerator::addCall):
(JSC::Wasm::B3IRGenerator::addCallIndirect):
* wasm/WasmBinding.cpp:
(JSC::Wasm::wasmToWasm):
* wasm/WasmFaultSignalHandler.cpp:
(JSC::Wasm::trapHandler):
(JSC::Wasm::enableFastMemory):
(JSC::Wasm::prepareFastMemory):
* wasm/WasmInstance.h:
(JSC::Wasm::Instance::cachedMemory const):
(JSC::Wasm::Instance::cachedBoundsCheckingSize const):
(JSC::Wasm::Instance::updateCachedMemory):
(JSC::Wasm::Instance::offsetOfCachedBoundsCheckingSize):
(JSC::Wasm::Instance::cachedMemorySize const): Deleted.
(JSC::Wasm::Instance::offsetOfCachedMemorySize): Deleted.
* wasm/WasmMemory.cpp:
(JSC::Wasm::MemoryHandle::MemoryHandle):
(JSC::Wasm::MemoryHandle::~MemoryHandle):
(JSC::Wasm::MemoryHandle::memory const):
(JSC::Wasm::Memory::Memory):
(JSC::Wasm::Memory::create):
(JSC::Wasm::Memory::tryCreate):
(JSC::Wasm::Memory::addressIsInGrowableOrFastMemory):
(JSC::Wasm::Memory::growShared):
(JSC::Wasm::Memory::grow):
(JSC::Wasm::Memory::dump const):
(JSC::Wasm::Memory::~Memory): Deleted.
(JSC::Wasm::Memory::addressIsInActiveFastMemory): Deleted.
* wasm/WasmMemory.h:
(JSC::Wasm::Memory::addressIsInGrowableOrFastMemory):
(JSC::Wasm::Memory::operator bool const): Deleted.
(JSC::Wasm::Memory::memory const): Deleted.
(JSC::Wasm::Memory::size const): Deleted.
(JSC::Wasm::Memory::sizeInPages const): Deleted.
(JSC::Wasm::Memory::initial const): Deleted.
(JSC::Wasm::Memory::maximum const): Deleted.
(JSC::Wasm::Memory::mode const): Deleted.
(JSC::Wasm::Memory::check): Deleted.
(JSC::Wasm::Memory::offsetOfMemory): Deleted.
(JSC::Wasm::Memory::offsetOfSize): Deleted.
(JSC::Wasm::Memory::addressIsInActiveFastMemory): Deleted.
* wasm/WasmMemoryInformation.cpp:
(JSC::Wasm::PinnedRegisterInfo::get):
(JSC::Wasm::PinnedRegisterInfo::PinnedRegisterInfo):
* wasm/WasmMemoryInformation.h:
(JSC::Wasm::PinnedRegisterInfo::toSave const):
* wasm/WasmMemoryMode.cpp:
(JSC::Wasm::makeString):
* wasm/WasmMemoryMode.h:
* wasm/js/JSToWasm.cpp:
(JSC::Wasm::createJSToWasmWrapper):
* wasm/js/JSWebAssemblyInstance.cpp:
(JSC::JSWebAssemblyInstance::tryCreate):
* wasm/js/JSWebAssemblyMemory.cpp:
(JSC::JSWebAssemblyMemory::buffer):
(JSC::JSWebAssemblyMemory::growSuccessCallback):
* wasm/js/JSWebAssemblyMemory.h:
* wasm/js/WebAssemblyFunction.cpp:
(JSC::WebAssemblyFunction::jsCallEntrypointSlow):
* wasm/js/WebAssemblyMemoryConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* wasm/js/WebAssemblyMemoryPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::evaluate):
2020-11-18 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r269940.
https://bugs.webkit.org/show_bug.cgi?id=219076
caused seemingly-infinite build time regression
Reverted changeset:
"[JSC] Implement WebAssembly.Memory with shared"
https://bugs.webkit.org/show_bug.cgi?id=218693
https://trac.webkit.org/changeset/269940
2020-11-16 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Implement WebAssembly.Memory with shared
https://bugs.webkit.org/show_bug.cgi?id=218693
Reviewed by Saam Barati.
This patch implements shared WebAssembly.Memory. This can be shared between workers like SharedArrayBuffer.
The most interesting thing of shared WebAssembly.Memory is that it is growable. The memory can be grown in
one thread, and immediately, it should be accessible in the other threads.
To achieve that, shared WebAssembly.Memory leverages signaling even if bounds-checking is mainly used.
If the fast memory is enabled, we just use it so that mprotect can make memory grown easily. But if fast memory
is disabled, we allocates requested VA region and perform bounds-checking with this VA. Since WebAssembly.Memory
always requires "maximum" size of memory, we can first allocate VA and map active part of memory first. And
when growing, we perform mprotect to the rest of the memory. Since this VA is not 4GB, we still need to perform
bounds-checking, but we perform bounds-checking with VA size instead of active memory size. As a result, even if
shared WebAssembly.Memory is grown, we do not need to update (1) pointer and (2) bounds-checking size.
The shared bounds-checking WebAssembly.Memory is something like below.
<================================================ maximum ============================><------------ other memory, protected by bounds-checking --...
<======= active ==========><===================== not active yet =====================>
^ [ if we access this, fault handler will detect it] ^
pointer bounds checking size
These "growable bound-checking memory" is now managed by wasm memory-manager. And fault handler is used even if fast memory is disabled.
And fault handler also accepts signals from Wasm LLInt code since both bounds-checkings + signalings are required to confine memory access even in
Wasm LLInt. This patch also renamed memory-size and size-register to bounds-checking-size and bounds-checking-size-register since this is no longer
a size of memory.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* llint/LLIntPCRanges.h:
(JSC::LLInt::isWasmLLIntPC):
* llint/LowLevelInterpreter.asm:
* llint/WebAssembly.asm:
* runtime/JSArrayBuffer.h:
(JSC::JSArrayBuffer::toWrappedAllowShared):
* runtime/JSArrayBufferView.h:
* runtime/JSArrayBufferViewInlines.h:
(JSC::JSArrayBufferView::toWrappedAllowShared):
* runtime/JSGenericTypedArrayView.h:
(JSC::JSGenericTypedArrayView<Adaptor>::toWrappedAllowShared):
* runtime/Options.cpp:
(JSC::overrideDefaults):
(JSC::Options::initialize):
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::AirIRGenerator):
(JSC::Wasm::AirIRGenerator::restoreWebAssemblyGlobalState):
(JSC::Wasm::AirIRGenerator::addCurrentMemory):
(JSC::Wasm::AirIRGenerator::emitCheckAndPreparePointer):
(JSC::Wasm::AirIRGenerator::addCall):
(JSC::Wasm::AirIRGenerator::addCallIndirect):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::B3IRGenerator):
(JSC::Wasm::B3IRGenerator::restoreWebAssemblyGlobalState):
(JSC::Wasm::B3IRGenerator::addCurrentMemory):
(JSC::Wasm::B3IRGenerator::emitCheckAndPreparePointer):
(JSC::Wasm::B3IRGenerator::addCall):
(JSC::Wasm::B3IRGenerator::addCallIndirect):
* wasm/WasmBinding.cpp:
(JSC::Wasm::wasmToWasm):
* wasm/WasmFaultSignalHandler.cpp:
(JSC::Wasm::trapHandler):
(JSC::Wasm::enableFastMemory):
(JSC::Wasm::prepareFastMemory):
* wasm/WasmInstance.h:
(JSC::Wasm::Instance::cachedMemory const):
(JSC::Wasm::Instance::cachedBoundsCheckingSize const):
(JSC::Wasm::Instance::updateCachedMemory):
(JSC::Wasm::Instance::offsetOfCachedBoundsCheckingSize):
(JSC::Wasm::Instance::cachedMemorySize const): Deleted.
(JSC::Wasm::Instance::offsetOfCachedMemorySize): Deleted.
* wasm/WasmMemory.cpp:
(JSC::Wasm::MemoryHandle::MemoryHandle):
(JSC::Wasm::MemoryHandle::~MemoryHandle):
(JSC::Wasm::Memory::Memory):
(JSC::Wasm::Memory::create):
(JSC::Wasm::Memory::tryCreate):
(JSC::Wasm::Memory::addressIsInGrowableOrFastMemory):
(JSC::Wasm::Memory::growShared):
(JSC::Wasm::Memory::grow):
(JSC::Wasm::Memory::dump const):
(JSC::Wasm::Memory::~Memory): Deleted.
(JSC::Wasm::Memory::addressIsInActiveFastMemory): Deleted.
* wasm/WasmMemory.h:
(JSC::Wasm::Memory::addressIsInGrowableOrFastMemory):
(JSC::Wasm::Memory::operator bool const): Deleted.
(JSC::Wasm::Memory::memory const): Deleted.
(JSC::Wasm::Memory::size const): Deleted.
(JSC::Wasm::Memory::sizeInPages const): Deleted.
(JSC::Wasm::Memory::initial const): Deleted.
(JSC::Wasm::Memory::maximum const): Deleted.
(JSC::Wasm::Memory::mode const): Deleted.
(JSC::Wasm::Memory::check): Deleted.
(JSC::Wasm::Memory::offsetOfMemory): Deleted.
(JSC::Wasm::Memory::offsetOfSize): Deleted.
(JSC::Wasm::Memory::addressIsInActiveFastMemory): Deleted.
* wasm/WasmMemoryInformation.cpp:
(JSC::Wasm::PinnedRegisterInfo::get):
(JSC::Wasm::PinnedRegisterInfo::PinnedRegisterInfo):
* wasm/WasmMemoryInformation.h:
(JSC::Wasm::PinnedRegisterInfo::toSave const):
* wasm/WasmMemoryMode.cpp:
(JSC::Wasm::makeString):
* wasm/WasmMemoryMode.h:
* wasm/js/JSToWasm.cpp:
(JSC::Wasm::createJSToWasmWrapper):
* wasm/js/JSWebAssemblyInstance.cpp:
(JSC::JSWebAssemblyInstance::tryCreate):
* wasm/js/JSWebAssemblyMemory.cpp:
(JSC::JSWebAssemblyMemory::buffer):
(JSC::JSWebAssemblyMemory::growSuccessCallback):
* wasm/js/JSWebAssemblyMemory.h:
* wasm/js/WebAssemblyFunction.cpp:
(JSC::WebAssemblyFunction::jsCallEntrypointSlow):
* wasm/js/WebAssemblyMemoryConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* wasm/js/WebAssemblyMemoryPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::evaluate):
2020-11-17 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Enable static public class fields
https://bugs.webkit.org/show_bug.cgi?id=219058
Reviewed by Saam Barati.
Let's flip the runtime flag (usePublicStaticClassFields). And we drop usePublicClassFields flag since it is already shipped.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
* bytecompiler/NodesCodegen.cpp:
(JSC::FunctionCallValueNode::emitBytecode):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseClass):
* runtime/OptionsList.h:
2020-11-17 Michael Catanzaro <mcatanzaro@gnome.org>
[CMake] generate_offset_extractor.rb missing build dependency for llint/WebAssembly.asm
https://bugs.webkit.org/show_bug.cgi?id=219043
Reviewed by Don Olmstead.
generate_offset_extractor.rb is missing a build dependency for llint/WebAssembly.asm. If
WebAssembly.asm is modified, generate_offset_extracter.rb needs to be run again.
* CMakeLists.txt:
2020-11-17 Saam Barati <sbarati@apple.com>
Add more info to the RELEASE_ASSERT inside Parser::parseInner
https://bugs.webkit.org/show_bug.cgi?id=219054
<rdar://problem/71506453>
Reviewed by Mark Lam.
We have some crashes here, and it'll be helpful for the crashlogs to have
more info in the register state.
* parser/Lexer.h:
(JSC::Lexer::codeLength):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseInner):
2020-11-17 Sergey Rubanov <chi187@gmail.com>
Add support for the Wasm i32 sign-extension-ops proposal
https://bugs.webkit.org/show_bug.cgi?id=210302
Reviewed by Yusuke Suzuki.
* llint/LowLevelInterpreter.asm:
* llint/WebAssembly.asm:
* offlineasm/arm64.rb:
* offlineasm/cloop.rb:
* offlineasm/instructions.rb:
* offlineasm/x86.rb:
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32Extend8S>):
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32Extend16S>):
* wasm/wasm.json:
2020-11-17 Xan López <xan@igalia.com>
[JSC] Add support for static public class fields
https://bugs.webkit.org/show_bug.cgi?id=194095
Reviewed by Yusuke Suzuki.
Add support for static public class fields. We can reuse most of
the existing machinery available for instance fields. Like
instance fields, static fields are initialized with a synthetic
function. This is done to allow us to trivially follow the scoping
rules in the spec. As it happens with instance fields this could
be inlined in a future patch.
A lot of small changes in many files are just a matter of doing
s/instance/class/ for variables related to class fields, which
before were assuming there are only instance fields implemented.
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::generateUnlinkedFunctionCodeBlock): do s/instanceField/classField/.
* bytecode/UnlinkedFunctionExecutable.h: ditto.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitNewClassFieldInitializerFunction): ditto.
* bytecompiler/BytecodeGenerator.h: ditto, plus add a parameter
for static field locations in emitDefineClassElements.
* bytecompiler/NodesCodegen.cpp:
(JSC::PropertyListNode::emitBytecode): save static fields
locations when going through the property list.
(JSC::PropertyListNode::emitSaveComputedFieldName): consider
static fields here too.
(JSC::ClassExprNode::emitBytecode): call the initializer for
static fields as the very last action of the class creation.
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createDefineField): field nodes can be static
too now.
* parser/NodeConstructors.h:
(JSC::DefineFieldNode::DefineFieldNode): ditto.
* parser/Nodes.h: ditto.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseInner): s/instanceField/classField/
(JSC::Parser<LexerType>::parseClass): consider static fields.
(JSC::Parser<LexerType>::parseInstanceFieldInitializerSourceElements):
s/instanceField/classField/, and consider static fields.
* parser/Parser.h:
(JSC::Parser<LexerType>::parse): s/instanceField/classField/
(JSC::parse): ditto.
* runtime/JSFunction.cpp:
(JSC::JSFunction::setFunctionName): s/instanceField/classField/
* runtime/OptionsList.h: add option to enable/disable static public fields.
2020-11-15 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Wasm should get byte length from source typed array
https://bugs.webkit.org/show_bug.cgi?id=218955
Reviewed by Sam Weinig.
WebAssembly's module source should be read with byteLength instead of length of typed-array.
* runtime/JSArrayBufferView.cpp:
(JSC::JSArrayBufferView::byteLength const):
(JSC::JSArrayBufferView::slowDownAndWasteMemory):
* runtime/JSArrayBufferView.h:
* wasm/js/JSWebAssemblyHelpers.h:
(JSC::getWasmBufferFromValue):
2020-11-14 Don Olmstead <don.olmstead@sony.com>
[clang-tidy] Run modernize-use-override through JSC
https://bugs.webkit.org/show_bug.cgi?id=218916
Reviewed by Yusuke Suzuki.
* inspector/agents/InspectorAgent.h:
* inspector/agents/InspectorScriptProfilerAgent.h:
* inspector/agents/InspectorTargetAgent.h:
* inspector/agents/JSGlobalObjectAuditAgent.h:
* inspector/agents/JSGlobalObjectDebuggerAgent.h:
* inspector/agents/JSGlobalObjectRuntimeAgent.h:
* inspector/remote/socket/RemoteInspectorConnectionClient.h:
* inspector/remote/socket/RemoteInspectorServer.h:
* runtime/JSGlobalObjectDebuggable.h:
2020-11-13 Xan López <xan@igalia.com>
[JSC] Use symbols as identifiers for class fields computed names storage
https://bugs.webkit.org/show_bug.cgi?id=216172
Reviewed by Yusuke Suzuki.
Use private symbols for the property keys of the class fields with
computed names. This is cleaner than using raw numeric identifiers and
will be less cumbersome when we add static fields. It also prevents
potential collisions if other features want to store data in the class
scope.
* bytecompiler/NodesCodegen.cpp:
(JSC::PropertyListNode::emitSaveComputedFieldName): adapt a comment.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseClass): use private identifiers for computed fields property keys.
(JSC::Parser<LexerType>::parseInstanceFieldInitializerSourceElements): ditto.
* parser/ParserArena.cpp:
(JSC::IdentifierArena::makePrivateIdentifier): method to create a private identifier.
* parser/ParserArena.h:
* runtime/CachedTypes.cpp:
(JSC::CachedUniquedStringImplBase::encode): consider registered symbols, they are used by the parser now.
(JSC::CachedUniquedStringImplBase::decode const): ditto.
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
(JSC::VM::privateSymbolRegistry): create a private symbol registry too.
2020-11-13 Sergey Rubanov <chi187@gmail.com>
WebAssembly: opcodes for table.grow and table.size are mixed up
https://bugs.webkit.org/show_bug.cgi?id=218644
Reviewed by Yusuke Suzuki.
* wasm/wasm.json:
2020-11-12 Devin Rousso <drousso@apple.com>
Web Inspector: ensure that `JSON::ArrayOf<T>` doesn't allow `addItem` to be called with a type other than `T`
https://bugs.webkit.org/show_bug.cgi?id=218686
Reviewed by Brian Burg.
* inspector/scripts/codegen/cpp_generator_templates.py:
* inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
(CppBackendDispatcherImplementationGenerator._generate_small_dispatcher_switch_implementation_for_domain):
(CppBackendDispatcherImplementationGenerator._generate_large_dispatcher_switch_implementation_for_domain):
* inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
* inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py:
(CppProtocolTypesImplementationGenerator._generate_enum_mapping):
(CppProtocolTypesImplementationGenerator._generate_open_field_names):
Use `ASCIILiteral`, `makeString`, and `_s` instead of inlined `char*` to ensure that the
`String` function overload is used.
* inspector/scripts/tests/expected/command-targetType-matching-domain-debuggableType.json-result:
* inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/expected/definitions-with-mac-platform.json-result:
* inspector/scripts/tests/expected/domain-debuggableTypes.json-result:
* inspector/scripts/tests/expected/domain-targetType-matching-domain-debuggableType.json-result:
* inspector/scripts/tests/expected/domain-targetTypes.json-result:
* inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
* inspector/scripts/tests/expected/enum-values.json-result:
* inspector/scripts/tests/expected/event-targetType-matching-domain-debuggableType.json-result:
* inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
* inspector/scripts/tests/expected/type-declaration-array-type.json-result:
* inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
* inspector/scripts/tests/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
* inspector/scripts/tests/expected/type-with-open-parameters.json-result:
2020-11-12 Dmitry Bezhetskov <dbezhetskov@igalia.com>
[WASM-References] Support imm for ref.null
https://bugs.webkit.org/show_bug.cgi?id=218744
Reviewed by Yusuke Suzuki.
Updated ref.null according to the ref-types spec:
https://github.com/WebAssembly/reference-types/.
* wasm/WasmFormat.h:
(JSC::Wasm::isRefType):
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseExpression):
* wasm/WasmParser.h:
(JSC::Wasm::Parser<SuccessType>::parseRefType):
* wasm/WasmSectionParser.cpp:
(JSC::Wasm::SectionParser::parseInitExpr):
* wasm/wasm.json:
2020-11-11 John Wilander <wilander@apple.com>
PCM: Change from ad-click-attribution to private-click-measurement (in all forms, including .well-known URL)
https://bugs.webkit.org/show_bug.cgi?id=218730
<rdar://problem/71094296>
Reviewed by Alex Christensen.
Change to the official name of the proposed standard Private Click Measurement
https://github.com/privacycg/private-click-measurement.
This includes a change of the reporting URL from
"/.well-known/ad-click-attribution/" to
"/.well-known/private-click-measurement/".
* inspector/ConsoleMessage.cpp:
(Inspector::messageSourceValue):
* inspector/protocol/Console.json:
* inspector/protocol/Page.json:
* runtime/ConsoleClient.cpp:
(JSC::appendMessagePrefix):
* runtime/ConsoleTypes.h:
2020-11-11 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Implement Intl.DateTimeFormat.formatRangeToParts
https://bugs.webkit.org/show_bug.cgi?id=213822
<rdar://problem/69328711>
Reviewed by Ross Kirsling.
This patch implements Intl.DateTimeFormat.formatRangeToParts. It is already stage-4 (included in the spec).
The inputs are date interval, and this function generates array of parts of formatted string of date interval.
Currently, required ICU APIs are draft status. So, for now, we track ABI changes, and use APIs with careful version checks.
However, currently, OpenSource macOS WebKit is built with specific ICU header (ICU 62 headers). So for now, we disable it
in OpenSource macOS WebKit build. But we enable it for Apple Internal SDK WebKit build. We can enable it if we include
multiple ICU header sets and select appropriate one against the linked ICU version. In the other platforms, they are using
corresponding ICU headers so that we can just enable it.
There are two interesting implementation topics.
1. From ICU 67, the signature of udtitvfmt_formatToResult is changed. We need to switch the implementation with fine grained ICU version checks.
2. udtitvfmt_formatToResult does not have an ability to configure gregorian calendar change date: before that date, the calendar is julian.
In ECMAScript spec, we need to ignore this gregorian calendar change date, and we should handle all gregorian calendar dates as is even if
the dates are older than gregorian calendar change date. However, since udtitvfmt_formatToResult does not offer the above ability,
ICU automatically switches the calendar between gregorian and julian. To fix this issue, ICU 67 introduced udtitvfmt_formatCalendarToResult,
which can take an explicit calendar for each input date so that we configure gregorian calendar change date. But this only exists after ICU 67.
In the implementations using ICU 64-66, we just use udtitvfmt_formatToResult.
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* runtime/IntlDateTimeFormat.cpp:
(JSC::UDateIntervalFormatDeleter::operator()):
(JSC::IntlDateTimeFormat::formatToParts const):
(JSC::definitelyAfterGregorianCalendarChangeDate):
(JSC::formattedValueFromDateRange):
(JSC::IntlDateTimeFormat::formatRange):
(JSC::IntlDateTimeFormat::formatRangeToParts):
* runtime/IntlDateTimeFormat.h:
* runtime/IntlDateTimeFormatPrototype.cpp:
(JSC::IntlDateTimeFormatPrototype::create):
(JSC::IntlDateTimeFormatPrototype::finishCreation):
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/IntlDateTimeFormatPrototype.h:
* runtime/OptionsList.h:
2020-11-11 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] wasm fault trampoline should be C code since it is tagged as CFunctionPtr
https://bugs.webkit.org/show_bug.cgi?id=218781
Reviewed by Keith Miller and Mark Lam.
When returning from signal handler, handler requires that instruction pointer is CFunctionPtrTag-ed.
So we should set C trampoline instead of JIT trampoline here.
This patch implements trampoline in LLInt Wasm code so that we can use CFunctionPtrTag.
* bytecode/BytecodeList.rb:
* llint/WebAssembly.asm:
* wasm/WasmFaultSignalHandler.cpp:
(JSC::Wasm::trapHandler):
2020-11-10 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r269660.
https://bugs.webkit.org/show_bug.cgi?id=218786
Crashing in EWS iOS simulator bots
Reverted changeset:
"PCM: Change from ad-click-attribution to private-click-
measurement (in all forms, including .well-known URL)"
https://bugs.webkit.org/show_bug.cgi?id=218730
https://trac.webkit.org/changeset/269660
2020-11-10 Ross Kirsling <ross.kirsling@sony.com>
Align %TypedArray% behavior with recent spec adjustments
https://bugs.webkit.org/show_bug.cgi?id=218776
Reviewed by Yusuke Suzuki.
The recent spec changes for typed arrays with detached buffers had certain ripple effects,
namely the following two PRs which will be presented in next week's TC39 meeting.
Since no controversy is expected, this patch addresses them now, though test262 adjustments are forthcoming.
1. https://github.com/tc39/ecma262/pull/2210
It is correct that `ta[i] = n` doesn't throw when `ta` has a detached buffer or `i` is otherwise OOB,
but by not throwing, Reflect.set(ta, i, n) is obliged to return true.
2. https://github.com/tc39/ecma262/pull/2221
Until now, %TypedArray%.prototype.{includes, indexOf, join, lastIndexOf} lacked a rigorous specification;
in particular, each has a parameter that may detach the buffer upon valueOf or toString, and the expected
behavior was not made clear. It seems most sensible to do what the corresponding Array methods do upon
`array.length = 0`: make use of the cached length but don't access indices, such that indexOf/lastIndexOf
return -1 while includes/join act as if the elements were all `undefined`.
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::put):
(JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
(JSC::JSGenericTypedArrayView<Adaptor>::putByIndex):
* runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
(JSC::genericTypedArrayViewProtoFuncIncludes):
(JSC::genericTypedArrayViewProtoFuncIndexOf):
(JSC::genericTypedArrayViewProtoFuncJoin):
(JSC::genericTypedArrayViewProtoFuncLastIndexOf):
2020-11-10 John Wilander <wilander@apple.com>
PCM: Change from ad-click-attribution to private-click-measurement (in all forms, including .well-known URL)
https://bugs.webkit.org/show_bug.cgi?id=218730
<rdar://problem/71094296>
Reviewed by Devin Rousso.
Change to the official name of the proposed standard Private Click Measurement
https://github.com/privacycg/private-click-measurement.
This includes a change of the reporting URL from
"/.well-known/ad-click-attribution/" to
"/.well-known/private-click-measurement/".
* inspector/ConsoleMessage.cpp:
(Inspector::messageSourceValue):
* inspector/protocol/Console.json:
* inspector/protocol/Page.json:
* runtime/ConsoleClient.cpp:
(JSC::appendMessagePrefix):
* runtime/ConsoleTypes.h:
2020-11-09 Keith Miller <keith_miller@apple.com>
Add total counts to sampling profiler dump
https://bugs.webkit.org/show_bug.cgi?id=218666
Reviewed by Yusuke Suzuki.
This is nice for computing the approximate percentage of total time in a function.
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::reportTopFunctions):
(JSC::SamplingProfiler::reportTopBytecodes):
2020-11-08 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Add TimeZone range cache over ICU TimeZone API
https://bugs.webkit.org/show_bug.cgi?id=218681
Reviewed by Ross Kirsling.
icu::TimeZone is more accurate and faster than localtime_r. But still, it is slower than returning cached data!
We saw 10% regression in JetStream2/date-format-xparb-SP with icu::TimeZone switching.
In this patch, we put one-depth timezone cache back over icu::TimeZone API, and recover the performance.
In addition, new version of timezone cache includes "start" side extension (while old one only extends "end" of the range).
The test covers all cases in the added cache.
* runtime/JSDateMath.cpp:
(JSC::DateCache::calculateLocalTimeOffset):
(JSC::DateCache::localTimeOffset):
(JSC::DateCache::gregorianDateTimeToMS):
(JSC::DateCache::msToGregorianDateTime):
(JSC::DateCache::parseDate):
(JSC::DateCache::reset):
(JSC::localTimeOffset): Deleted.
* runtime/JSDateMath.h:
(JSC::DateCache::timeZoneCache):
* runtime/VM.h:
(JSC::LocalTimeOffsetCache::LocalTimeOffsetCache): Deleted.
(JSC::LocalTimeOffsetCache::reset): Deleted.
2020-11-08 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Support @@species in ArrayBuffer / SharedArrayBuffer slice
https://bugs.webkit.org/show_bug.cgi?id=218697
Reviewed by Ross Kirsling.
This patch adds support for @@species in ArrayBuffer/SharedArrayBuffer.prototype.slice.
We leverage the mechanism similar to Array's @@species handling: adding fast path with watchpoint.
When we found that some of critical properties (e.g. %Prototype%.constructor, %Constructor%[@@species])
are modified, watchpoint is fired and we go to the slow path. Until that, we use fast path that is
basically the same to the code before this patch.
* runtime/ArrayBuffer.cpp:
(JSC::ArrayBuffer::slice const):
(JSC::ArrayBuffer::sliceWithClampedIndex const):
(JSC::ArrayBuffer::sliceImpl const): Deleted.
* runtime/ArrayBuffer.h:
* runtime/ArrayBufferSharingMode.h:
* runtime/ArrayPrototype.cpp:
(JSC::speciesWatchpointIsValid):
* runtime/JSArrayBufferPrototype.cpp:
(JSC::speciesWatchpointIsValid):
(JSC::arrayBufferSlice):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::JSGlobalObject):
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
(JSC::JSGlobalObject::tryInstallSpeciesWatchpoint):
(JSC::JSGlobalObject::tryInstallArraySpeciesWatchpoint):
(JSC::JSGlobalObject::tryInstallArrayBufferSpeciesWatchpoint):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::arrayBufferSpeciesWatchpointSet):
(JSC::JSGlobalObject::arrayBufferPrototype const):
(JSC::JSGlobalObject::arrayBufferStructure const):
(JSC::JSGlobalObject::arrayBufferConstructor const):
2020-11-06 Dmitry Bezhetskov <dbezhetskov@igalia.com>
[WASM-References] Rename anyref to externref
https://bugs.webkit.org/show_bug.cgi?id=218331
Reviewed by Keith Miller.
* bytecode/BytecodeDumper.cpp:
(JSC::Wasm::BytecodeDumper::formatConstant const):
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::gExternref):
(JSC::Wasm::AirIRGenerator::tmpForType):
(JSC::Wasm::AirIRGenerator::emitCCall):
(JSC::Wasm::AirIRGenerator::moveOpForValueType):
(JSC::Wasm::AirIRGenerator::AirIRGenerator):
(JSC::Wasm::AirIRGenerator::addLocal):
(JSC::Wasm::AirIRGenerator::addConstant):
(JSC::Wasm::AirIRGenerator::setGlobal):
(JSC::Wasm::AirIRGenerator::gAnyref): Deleted.
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::addLocal):
(JSC::Wasm::B3IRGenerator::addTableGet):
(JSC::Wasm::B3IRGenerator::setGlobal):
* wasm/WasmCallingConvention.h:
(JSC::Wasm::WasmCallingConvention::marshallLocation const):
(JSC::Wasm::JSCallingConvention::marshallLocation const):
* wasm/WasmFormat.h:
(JSC::Wasm::isValueType):
(JSC::Wasm::isSubtype):
(JSC::Wasm::TableInformation::wasmType const):
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseExpression):
* wasm/WasmGlobal.cpp:
(JSC::Wasm::Global::get const):
(JSC::Wasm::Global::set):
(JSC::Wasm::Global::visitAggregate):
* wasm/WasmGlobal.h:
* wasm/WasmInstance.cpp:
(JSC::Wasm::Instance::Instance):
(JSC::Wasm::Instance::setGlobal):
* wasm/WasmLLIntGenerator.cpp:
(JSC::Wasm::LLIntGenerator::jsNullConstant):
(JSC::Wasm::LLIntGenerator::callInformationForCaller):
(JSC::Wasm::LLIntGenerator::callInformationForCallee):
(JSC::Wasm::LLIntGenerator::addArguments):
(JSC::Wasm::LLIntGenerator::addLocal):
(JSC::Wasm::LLIntGenerator::setGlobal):
* wasm/WasmOperations.cpp:
(JSC::Wasm::JSC_DEFINE_JIT_OPERATION):
(JSC::Wasm::setWasmTableElement):
* wasm/WasmSectionParser.cpp:
(JSC::Wasm::SectionParser::parseTableHelper):
* wasm/WasmTable.cpp:
(JSC::Wasm::Table::tryCreate):
(JSC::Wasm::Table::set):
* wasm/WasmTable.h:
(JSC::Wasm::Table::isExternrefTable const):
(JSC::Wasm::Table::isAnyrefTable const): Deleted.
* wasm/js/JSToWasm.cpp:
(JSC::Wasm::boxWasmResult):
* wasm/js/JSWebAssemblyTable.cpp:
(JSC::JSWebAssemblyTable::set):
* wasm/js/WasmToJS.cpp:
(JSC::Wasm::wasmToJS):
* wasm/js/WebAssemblyFunction.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::WebAssemblyFunction::jsCallEntrypointSlow):
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::link):
* wasm/js/WebAssemblyTableConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* wasm/wasm.json:
2020-11-06 Yusuke Suzuki <ysuzuki@apple.com>
Re-enable SharedArrayBuffer for JSC shell and Testers
https://bugs.webkit.org/show_bug.cgi?id=212069
Reviewed by Keith Miller.
This patch revives SharedArrayBuffer and Atomics and aligning them to the latest spec.
1. SharedArrayBuffer's sort should be done in JS side. C++ sort is not safe for SharedArrayBuffer since the buffer
can be modified by different threads while sorting.
2. Atomics.wait should be renamed to Atomics.notify.
3. Atomics operation should be VarArgs in DFG because DFGSSALoweringPhase assumes that they are VarArgs and they can
have another arg for CheckInBounds dependency.
4. For test262, JSC shell should support "--can-block-is-false" flag. If it is true, the main thread's [[CanBlock]] becomes false.
This means that `Atomics.wait` cannot be used.
* builtins/BuiltinNames.h:
* builtins/TypedArrayPrototype.js:
(sort):
* bytecode/LinkTimeConstant.h:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::mustGenerate const):
(JSC::DFG::Node::hasVarArgs const):
(JSC::DFG::Node::mustGenerate): Deleted.
* dfg/DFGNodeType.h:
* dfg/DFGSSALoweringPhase.cpp:
(JSC::DFG::SSALoweringPhase::handleNode):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileAtomicsIsLockFree):
* jsc.cpp:
(printUsageStatement):
(CommandLine::parseArguments):
(runJSC):
* runtime/AtomicsObject.cpp:
(JSC::AtomicsObject::finishCreation):
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::JSC_DEFINE_JIT_OPERATION):
* runtime/CommonIdentifiers.h:
* runtime/Intrinsic.cpp:
(JSC::intrinsicName):
* runtime/Intrinsic.h:
* runtime/JSArrayBufferPrototype.cpp:
(JSC::arrayBufferSlice):
(JSC::arrayBufferByteLength):
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::JSArrayBufferPrototype::finishCreation):
* runtime/JSCJSValue.h:
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::toIntegerOrInfinity const):
* runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
(JSC::genericTypedArrayViewProtoFuncReverse):
(JSC::genericTypedArrayViewPrivateFuncSort):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/JSTypedArrayViewPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/JSTypedArrayViewPrototype.h:
* runtime/OptionsList.h:
* runtime/SimpleTypedArrayController.cpp:
(JSC::SimpleTypedArrayController::SimpleTypedArrayController):
(JSC::SimpleTypedArrayController::isAtomicsWaitAllowedOnCurrentThread):
* runtime/SimpleTypedArrayController.h:
* runtime/SmallStrings.cpp:
(JSC::SmallStrings::initializeCommonStrings):
(JSC::SmallStrings::visitStrongReferences):
* runtime/SmallStrings.h:
(JSC::SmallStrings::notEqualString const):
(JSC::SmallStrings::timedOutString const):
(JSC::SmallStrings::okString const):
2020-11-06 Mark Lam <mark.lam@apple.com>
Use address diversified PAC to ensure the integrity of opcode maps.
https://bugs.webkit.org/show_bug.cgi?id=218646
Reviewed by Yusuke Suzuki.
One reason for doing this is because space in the JSCConfig is limited, and may
hurt RAMification scores if we need to expand it when adding new opcodes.
By putting the opcode maps in dirty global memory, we still use less memory
because dirty global memory does not incur internal fragmentation like the
JSCConfig does.
In this patch, we move g_jscConfig.llint.opcodeMap, g_jscConfig.llint.opcodeMapWide16,
and g_jscConfig.llint.opcodeMapWide32 back to global arrays g_opcodeMap, g_opcodeMapWide16,
and g_opcodeMapWide32.
* interpreter/InterpreterInlines.h:
(JSC::Interpreter::getOpcodeID):
- Since this function is only used debugging purposes during development, and is
currently unused, we can just strip the PAC bits from the opcode when computing
the opcodeID. The alternative to doing this requires that we know how the
Opcode is signed by the client. Since this function is currently unused, we
have no clients to study / fix up for now.
* llint/LLIntData.cpp:
(JSC::LLInt::initialize):
- Changed an ASSERT for llint_throw_from_slow_path_trampoline to static_assert,
and add a second one as well for wasm_throw_from_slow_path_trampoline.
- Moved the signing of the Opcode pointers into llint_entry() and wasm_entry()
instead. Now, non-ARM64E ports don't need to execute this no-op assignment loop
(assuming it wasn't already elided by the compiler).
* llint/LLIntData.h:
(JSC::LLInt::opcodeMap):
(JSC::LLInt::opcodeMapWide16):
(JSC::LLInt::opcodeMapWide32):
(JSC::LLInt::getOpcode):
(JSC::LLInt::getOpcodeWide16):
(JSC::LLInt::getOpcodeWide32):
- Change getOpcode(), getOpcodeWide16(), and getOpcodeWide32() to return a reference
to the entry in the corresponding opcode map. This is needed because we need to
be able to compute the address of the Opcode entry in order to retag the Opcode.
(JSC::LLInt::getCodePtrImpl):
(JSC::LLInt::getCodePtr):
(JSC::LLInt::getWide16CodePtr):
(JSC::LLInt::getWide32CodePtr):
* llint/LowLevelInterpreter.asm:
* llint/WebAssembly.asm:
- Changed the bytecode dispatch `jmp`s to use address diversification when
authenticating the Opcode pointer.
- Changed llint_entry and wasm_entry to also tag the Opcode pointers for ARM64E.
- Changed llint_entry and wasm_entry to validate that they are only called during
system initialization.
* offlineasm/arm64.rb:
- Optimize `leap` code generation to elide an add instruction if it's only adding
0 to a global address.
* offlineasm/arm64e.rb:
* offlineasm/ast.rb:
* offlineasm/instructions.rb:
- Added support for jmp or call using address diversified pointers.
- Added a tagCodePtr instruction that also supports signing address diversified pointers.
* runtime/JSCConfig.h:
* runtime/JSCPtrTag.h:
(JSC::untagAddressDiversifiedCodePtr):
- Added untagAddressDiversifiedCodePtr() so that we can retag the Opcode pointers.
2020-11-05 Don Olmstead <don.olmstead@sony.com>
Non-unified build fixes, early November 2020 edition
https://bugs.webkit.org/show_bug.cgi?id=218628
Unreviewed non-unified build fix.
* llint/LLIntSlowPaths.cpp:
2020-11-05 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, build fix for ARM64E
https://bugs.webkit.org/show_bug.cgi?id=218587
* llint/LLIntData.cpp:
2020-11-04 Yusuke Suzuki <ysuzuki@apple.com>
Apply JITCage to CSSJIT
https://bugs.webkit.org/show_bug.cgi?id=218587
Reviewed by Mark Lam.
* llint/LLIntData.cpp:
* llint/LowLevelInterpreter.asm:
* runtime/JSCPtrTag.h:
* yarr/YarrJIT.cpp:
2020-11-04 David Kilzer <ddkilzer@apple.com>
WebKit should remove unused debug variant support
<https://webkit.org/b/218315>
<rdar://problem/70785369>
Reviewed by Darin Adler.
Remove support for building the debug variant since it is
currently unused. We now set default values for the
DEAD_CODE_STRIPPING, DEBUG_DEFINES, GCC_OPTIMIZATION_LEVEL and
STRIP_INSTALLED_PRODUCT variables.
Also move these values out of the Xcode project into
Base.xcconfig files using the [config=Debug] specifier so that
these overrides are next to the definitions.
* Configurations/Base.xcconfig:
* JavaScriptCore.xcodeproj/project.pbxproj:
2020-11-04 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, fix ARM64 only crash (ARM64E works) after JIT Cage
https://bugs.webkit.org/show_bug.cgi?id=218143
* yarr/YarrJIT.h:
(JSC::Yarr::YarrCodeBlock::execute):
2020-11-03 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, build fix for ARM64E debug build
https://bugs.webkit.org/show_bug.cgi?id=218143
* runtime/JSCPtrTag.cpp:
(JSC::tagForPtr):
2020-11-03 Saam Barati <sbarati@apple.com>
Add back the removed assertion from r269338 and add a test
https://bugs.webkit.org/show_bug.cgi?id=218543
Reviewed by Filip Pizlo.
The assertion from r269338 was wrong in JSLock::willReleaseLock because
of our use of DropAllLocks. However, it is correct inside the topmost ~VMEntryScope.
* jsc.cpp:
(JSC_DEFINE_HOST_FUNCTION):
* runtime/VMEntryScope.cpp:
(JSC::VMEntryScope::~VMEntryScope):
2020-11-03 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Add JITCage support
https://bugs.webkit.org/show_bug.cgi?id=218143
Reviewed by Saam Barati.
Towards software verified JIT, this patch adds partial JIT-Caging support which cages JIT call / jumps in a certain format.
This is currently only enabled when internal SDK is enabled. And it is only enabled in ARM64E for now.
Currently, this patch does not have CSS JIT support. Subsequent patch will add it.
We ensured that JS2 and RAMification are neutral.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/JITOperationList.cpp:
(JSC::addPointers):
(JSC::JITOperationList::populatePointersInJavaScriptCoreForLLInt):
* assembler/JITOperationList.h:
(JSC::JITOperationList::map const):
(JSC::JITOperationList::assertIsHostFunction):
(JSC::JITOperationList::assertIsJITOperation):
(JSC::JITOperationList::contains const): Deleted.
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::farJump):
* assembler/MacroAssemblerARM64E.h:
(JSC::MacroAssemblerARM64E::callTrustedPtr):
(JSC::MacroAssemblerARM64E::call):
(JSC::MacroAssemblerARM64E::callRegister):
(JSC::MacroAssemblerARM64E::farJumpRegister):
(JSC::MacroAssemblerARM64E::farJump):
(JSC::MacroAssemblerARM64E::ret):
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::farJump):
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::farJump):
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::farJump):
* bytecode/BytecodeList.rb:
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::callerReturnPC):
(JSC::DFG::adjustAndJumpToTarget):
* dfg/DFGOSRExitCompilerCommon.h:
* jit/ExecutableAllocator.cpp:
(JSC::ExecutableAllocator::setJITEnabled):
(JSC::initializeJITPageReservation):
* jit/GPRInfo.h:
* jit/PolymorphicCallStubRoutine.cpp:
(JSC::PolymorphicCallNode::unlink):
* jit/ThunkGenerators.cpp:
(JSC::emitPointerValidation):
* llint/LLIntData.cpp:
(JSC::LLInt::initialize):
* llint/LLIntData.h:
(JSC::LLInt::getOpcode):
(JSC::LLInt::getOpcodeWide16):
(JSC::LLInt::getOpcodeWide32):
(JSC::LLInt::getCodePtr):
(JSC::LLInt::getWide16CodePtr):
(JSC::LLInt::getWide32CodePtr):
(JSC::LLInt::getCodeFunctionPtr):
(JSC::LLInt::getWide16CodeFunctionPtr):
(JSC::LLInt::getWide32CodeFunctionPtr):
* llint/LLIntEntrypoint.cpp:
(JSC::LLInt::entrypointTrampoline):
(JSC::LLInt::setFunctionEntrypoint):
(JSC::LLInt::setEvalEntrypoint):
(JSC::LLInt::setProgramEntrypoint):
(JSC::LLInt::setModuleProgramEntrypoint):
(JSC::LLInt::getHostCallReturnValueEntrypoint):
(JSC::LLInt::fuzzerReturnEarlyFromLoopHintEntrypoint):
(JSC::LLInt::genericReturnPointEntrypoint):
* llint/LLIntEntrypoint.h:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
(JSC::LLInt::commonCallEval):
(JSC::LLInt::dispatchToNextInstruction):
* llint/LLIntThunks.cpp:
(JSC::LLInt::generateThunkWithJumpTo):
(JSC::LLInt::generateThunkWithJumpToPrologue):
(JSC::LLInt::generateThunkWithJumpToLLIntReturnPoint):
(JSC::LLInt::functionForCallEntryThunk):
(JSC::LLInt::functionForConstructEntryThunk):
(JSC::LLInt::functionForCallArityCheckThunk):
(JSC::LLInt::functionForConstructArityCheckThunk):
(JSC::LLInt::evalEntryThunk):
(JSC::LLInt::programEntryThunk):
(JSC::LLInt::moduleProgramEntryThunk):
(JSC::LLInt::wasmFunctionEntryThunk):
(JSC::LLInt::handleCatchThunk):
(JSC::LLInt::genericReturnPointThunk):
(JSC::LLInt::fuzzerReturnEarlyFromLoopHintThunk):
(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):
(JSC::LLInt::normalOSRExitTrampolineThunk):
(JSC::LLInt::checkpointOSRExitTrampolineThunk):
(JSC::LLInt::checkpointOSRExitFromInlinedCallTrampolineThunk):
(JSC::LLInt::returnLocationThunk):
* llint/LLIntThunks.h:
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* llint/WebAssembly.asm:
* offlineasm/arm64.rb:
* offlineasm/mips.rb:
* runtime/Gate.h: Added.
* runtime/JSCConfig.h:
* runtime/JSCPtrTag.cpp:
(JSC::tagForPtr):
(JSC::callerType):
(JSC::calleeType):
* runtime/JSCPtrTag.h:
(JSC::tagJSCCodePtrImpl):
(JSC::untagJSCCodePtrImpl):
(JSC::tagCodePtrWithStackPointerForJITCall):
(JSC::untagCodePtrWithStackPointerForJITCall):
* runtime/MatchResult.h:
(JSC::MatchResult::MatchResult):
* runtime/Options.cpp:
(JSC::disableAllJITOptions):
(JSC::canUseJITCage):
* runtime/OptionsList.h:
* wasm/WasmSlowPaths.cpp:
* yarr/YarrJIT.cpp:
* yarr/YarrJIT.h:
(JSC::Yarr::YarrCodeBlock::execute):
2020-11-03 Geoffrey Garen <ggaren@apple.com>
Drop most uses of the phrase 'neuter' from the tree
https://bugs.webkit.org/show_bug.cgi?id=218536
Reviewed by Tim Horton.
In ArrayBuffer use cases, the spec has gone with "detached".
In other cases, I picked something.
* JavaScriptCore.order:
* builtins/ArrayIteratorPrototype.js:
(next):
* builtins/BuiltinNames.h:
* builtins/TypedArrayPrototype.js:
(fill):
(globalPrivate.typedArrayElementCompare):
* bytecode/LinkTimeConstant.h:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDesiredWatchpoints.cpp:
(JSC::DFG::ArrayBufferViewWatchpointAdaptor::add):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCheckDetached):
(JSC::DFG::SpeculativeJIT::jumpForTypedArrayIsDetachedIfOutOfBounds):
(JSC::DFG::SpeculativeJIT::compilePutByValForIntTypedArray):
(JSC::DFG::SpeculativeJIT::compilePutByValForFloatTypedArray):
(JSC::DFG::SpeculativeJIT::compileCheckNeutered): Deleted.
(JSC::DFG::SpeculativeJIT::jumpForTypedArrayIsNeuteredIfOutOfBounds): Deleted.
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGTypeCheckHoistingPhase.cpp:
(JSC::DFG::TypeCheckHoistingPhase::identifyRedundantStructureChecks):
(JSC::DFG::TypeCheckHoistingPhase::identifyRedundantArrayChecks):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileCheckDetached):
(JSC::FTL::DFG::LowerDFGToB3::compilePutByVal):
(JSC::FTL::DFG::LowerDFGToB3::speculateTypedArrayIsNotDetached):
(JSC::FTL::DFG::LowerDFGToB3::compileCheckNeutered): Deleted.
(JSC::FTL::DFG::LowerDFGToB3::speculateTypedArrayIsNotNeutered): Deleted.
* runtime/ArrayBuffer.cpp:
(JSC::ArrayBufferContents::tryAllocate):
(JSC::ArrayBuffer::transferTo):
(JSC::ArrayBuffer::detach):
(JSC::ArrayBuffer::notifyDetaching):
(JSC::ArrayBuffer::neuter): Deleted.
(JSC::ArrayBuffer::notifyNeutering): Deleted.
* runtime/ArrayBuffer.h:
(JSC::ArrayBuffer::isDetached):
(JSC::ArrayBuffer::detachingWatchpointSet):
(JSC::ArrayBuffer::isNeutered): Deleted.
(JSC::ArrayBuffer::neuteringWatchpointSet): Deleted.
* runtime/ArrayBufferView.cpp:
(JSC::ArrayBufferView::ArrayBufferView):
(JSC::ArrayBufferView::~ArrayBufferView):
(JSC::ArrayBufferView::setDetachable):
(JSC::ArrayBufferView::setNeuterable): Deleted.
* runtime/ArrayBufferView.h:
(JSC::ArrayBufferView::isDetached const):
(JSC::ArrayBufferView::possiblySharedBuffer const):
(JSC::ArrayBufferView::isShared const):
(JSC::ArrayBufferView::baseAddress const):
(JSC::ArrayBufferView::byteOffset const):
(JSC::ArrayBufferView::isDetachable const):
(JSC::ArrayBufferView::isNeutered const): Deleted.
(JSC::ArrayBufferView::isNeuterable const): Deleted.
* runtime/GenericTypedArrayView.h:
* runtime/JSArrayBufferView.cpp:
(JSC::JSArrayBufferView::detach):
(JSC::JSArrayBufferView::neuter): Deleted.
* runtime/JSArrayBufferView.h:
(JSC::JSArrayBufferView::isDetached):
(JSC::JSArrayBufferView::isNeutered): Deleted.
* runtime/JSDataView.cpp:
(JSC::JSDataView::create):
* runtime/JSDataViewPrototype.cpp:
(JSC::getData):
(JSC::setData):
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/JSGenericTypedArrayView.h:
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::setWithSpecificType):
(JSC::JSGenericTypedArrayView<Adaptor>::set):
(JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlotByIndex):
(JSC::JSGenericTypedArrayView<Adaptor>::deletePropertyByIndex):
* runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
(JSC::speciesConstruct):
(JSC::genericTypedArrayViewProtoFuncSet):
(JSC::genericTypedArrayViewProtoFuncCopyWithin):
(JSC::genericTypedArrayViewProtoFuncIncludes):
(JSC::genericTypedArrayViewProtoFuncIndexOf):
(JSC::genericTypedArrayViewProtoFuncJoin):
(JSC::genericTypedArrayViewProtoFuncLastIndexOf):
(JSC::genericTypedArrayViewProtoFuncReverse):
(JSC::genericTypedArrayViewPrivateFuncSort):
(JSC::genericTypedArrayViewProtoFuncSlice):
(JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/JSTypedArrayViewPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::createTypedArrayIteratorObject):
* runtime/JSTypedArrayViewPrototype.h:
* wasm/js/JSWebAssemblyHelpers.h:
(JSC::getWasmBufferFromValue):
* wasm/js/JSWebAssemblyMemory.cpp:
(JSC::JSWebAssemblyMemory::growSuccessCallback):
2020-11-03 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Obtain default timezone ID from cached icu::TimeZone
https://bugs.webkit.org/show_bug.cgi?id=218531
<rdar://problem/64265880>
Reviewed by Ross Kirsling.
ICU internally caches icu::TimeZone (icu::TimeZone::createDefault), and it is not updated even if system timezone is changed.
As a result, we will see wrong timezone in Intl.DateTimeFormat when system timezone is changed.
We have a mechanism that clears TimeZone cache for JS Date. However, this mechanism is not used for Intl.DateTimeFormat.
This patch retrieves timezone ID from cached icu::TimeZone in VM::dateCache. So system's timezone change can be effective for
Intl.DateTimeFormat, and timezone becomes consistent between JS Date and Intl.DateTimeFormat.
Unfortunately, we need to use C++ APIs since we do not have a way to get timezone ID from icu::TimeZone.
Once https://unicode-org.atlassian.net/browse/ICU-21372 is fixed, we can switch to C APIs.
* runtime/IntlDateTimeFormat.cpp:
(JSC::IntlDateTimeFormat::initializeDateTimeFormat):
(JSC::isUTCEquivalent): Deleted.
(JSC::defaultTimeZone): Deleted.
* runtime/JSDateMath.cpp:
(JSC::DateCache::defaultTimeZone):
* runtime/JSDateMath.h:
(JSC::isUTCEquivalent):
2020-11-03 Saam Barati <sbarati@apple.com>
Don't assert there is no checkpoint side state when dropping the JSLock
https://bugs.webkit.org/show_bug.cgi?id=218537
Reviewed by Filip Pizlo.
You may have multiple OSR exit sidestate data on the stack, and then call into
API code, which might DropAllLocks. Hence, this assert is wrong.
Working on a test. Will land in a followup.
* runtime/JSLock.cpp:
(JSC::JSLock::willReleaseLock):
2020-11-03 Yusuke Suzuki <ysuzuki@apple.com>
REGRESSION (r254038): Simple.com money transfer UI is very laggy (multiple seconds per keypress)
https://bugs.webkit.org/show_bug.cgi?id=218348
Reviewed by Darin Adler.
We have depth-1 LocalTimeOffset cache to avoid repeatedly calling `localtime_r`. But this depth-1 cache can be easily missed if
we parse Dates of multiple years. Instead of increasing depth as a work-around, this patch starts using ICU TimeZone cache.
This is used in SpiderMonkey and V8 too, and it is the right direction since ICU knows tzdata and can do more sophisticated caching.
Microbenchmark shows 24x improvement.
ToT Patched
local-date-constructor 2026.8715+-11.2909 ^ 85.0022+-1.0548 ^ definitely 23.8449x faster
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* runtime/DateConstructor.cpp:
(JSC::millisecondsFromComponents):
(JSC::constructDate):
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/DateInstance.cpp:
(JSC::DateInstance::calculateGregorianDateTime const):
(JSC::DateInstance::calculateGregorianDateTimeUTC const):
* runtime/DateInstance.h:
* runtime/DatePrototype.cpp:
(JSC::setNewValueFromTimeArgs):
(JSC::setNewValueFromDateArgs):
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/JSDateMath.cpp:
(JSC::OpaqueICUTimeZoneDeleter::operator()):
(JSC::localTimeOffset):
(JSC::DateCache::gregorianDateTimeToMS):
(JSC::DateCache::msToGregorianDateTime):
(JSC::DateCache::parseDate):
(JSC::DateCache::cachedDateInstanceData):
(JSC::DateCache::timeZoneCacheSlow):
(JSC::DateCache::reset):
(JSC::gregorianDateTimeToMS): Deleted.
(JSC::msToGregorianDateTime): Deleted.
(JSC::parseDate): Deleted.
* runtime/JSDateMath.h:
(JSC::DateCache::timeZoneCache):
* runtime/VM.cpp:
(JSC::VM::resetDateCache): Deleted.
* runtime/VM.h:
(JSC::VM::resetDateCache):
* runtime/VMEntryScope.cpp:
(JSC::VMEntryScope::VMEntryScope):
2020-11-03 Keith Rollin <krollin@apple.com>
Extend check-for-inappropriate-files-in-framework to WebKitLegacy and JavaScriptCore
https://bugs.webkit.org/show_bug.cgi?id=218272
<rdar://problem/70748116>
Reviewed by Simon Fraser.
Bug 218268 reports that some *.txt files got included in WebKitLegacy.
To help protect against this happening in the future, extend
check-for-inappropriate-files-in-framework to check for *.txt files,
and apply the script to WebKitLegacy and JavaScriptCore in addition to
WebCore and WebKit.
* JavaScriptCore.xcodeproj/project.pbxproj:
2020-11-03 Don Olmstead <don.olmstead@sony.com>
[CMake] Add remote inspector platforms
https://bugs.webkit.org/show_bug.cgi?id=218451
Reviewed by Michael Catanzaro.
Add a CMake definition for each of the three remote inspector server backends to
remove duplication between the ports. Modify the port's CMake files to use the
shared definitions.
* PlatformFTW.cmake:
* PlatformGTK.cmake:
* PlatformJSCOnly.cmake:
* PlatformPlayStation.cmake:
* PlatformWPE.cmake:
* PlatformWin.cmake:
* inspector/remote/Cocoa.cmake: Added.
* inspector/remote/GLib.cmake: Added.
* inspector/remote/Socket.cmake: Added.
* inspector/remote/SourcesCocoa.txt: Copied from Source/JavaScriptCore/SourcesWPE.txt.
* inspector/remote/SourcesGLib.txt: Renamed from Source/JavaScriptCore/SourcesGTK.txt.
* inspector/remote/SourcesSocket.txt: Renamed from Source/JavaScriptCore/SourcesWPE.txt.
2020-11-02 Xan Lopez <xan@igalia.com>
[JSC] Remove compiler warning in LLIntData.cpp
https://bugs.webkit.org/show_bug.cgi?id=218443
Reviewed by Mark Lam.
Fix compiler warning by casting a scoped enum to its underlying
type. Not allowing implicit type conversions is the whole point of
scoped enums.
* interpreter/CallFrame.h: remove underlying type specifier, since
we are using the default anyway ('int').
* llint/LLIntData.cpp:
(JSC::LLInt::Data::performAssertions): cast the scoped enum to its
underlying type.
2020-10-29 Jérôme Decoodt <jdecoodt@apple.com>
JavaScriptCore should support multiple build variants
<https://webkit.org/b/218347>
<rdar://problem/70786057>
Reviewed by Keith Miller.
Update JavaScriptCore to handle BUILD_VARIANTS properly by
passing the value to build phase scripts and handling all
variants set during the build. For engineering builds,
BUILD_VARIANTS=normal.
* CMakeLists.txt:
- Update to pass equivalent ${BUILD_VARIANTS} for non-Apple
platforms to asm.rb and generate_offset_extractor.rb.
* JavaScriptCore.xcodeproj/project.pbxproj:
(LLInt Offsets | Generate Derived Sources):
(Offline Assembler | Offline Assemble):
- Update build phase script to pass "${BUILD_VARIANTS}" as an
argument to scripts.
* offlineasm/asm.rb:
- Parse BUILD_VARIANTS argument to pass to
offsetsAndConfigurationIndexForVariants().
* offlineasm/generate_offset_extractor.rb:
- Parse BUILD_VARIANTS argument to pass to
configurationIndicesForVariants().
* offlineasm/offsets.rb:
(offsetsAndConfigurationIndex):
- Update argument list in comment block.
(offsetsAndConfigurationIndexForVariants): Add.
- Invoke offsetsAndConfigurationIndex() for each build variant.
(configurationIndices):
- Update argument list in comment block.
(configurationIndicesForVariants): Add.
- Invoke configurationIndices() for each build variant.
2020-10-28 Basuke Suzuki <basuke.suzuki@sony.com>
[WinCairo][PlayStation] Add handling for accept failure case
https://bugs.webkit.org/show_bug.cgi?id=217353
Reviewed by Alex Christensen.
It is rare to happen, but listening socket can be invalid state (i.e. cable disconnection, interface error),
and accept() will be called because of the poll's false report. In that situation, it is required to rebuild
the listening socket from the scratch. The failure of accept is the good place to capture this situation.
This patch moves listening duty into Listener internal calss and it is possible to make the invalid state
while maintained by SocketEndpoint. Also in case of failure continues, the retry will be gradually increasing
the intervals.
* inspector/remote/socket/RemoteInspectorServer.h:
* inspector/remote/socket/RemoteInspectorSocketEndpoint.cpp:
(Inspector::RemoteInspectorSocketEndpoint::listenInet):
(Inspector::RemoteInspectorSocketEndpoint::pollingTimeout):
(Inspector::RemoteInspectorSocketEndpoint::workerThread):
(Inspector::RemoteInspectorSocketEndpoint::createClient):
(Inspector::RemoteInspectorSocketEndpoint::disconnect):
(Inspector::RemoteInspectorSocketEndpoint::acceptInetSocketIfEnabled):
* inspector/remote/socket/RemoteInspectorSocketEndpoint.h:
2020-10-28 Saam Barati <sbarati@apple.com>
Better cache our serialization of the outer TDZ environment when creating FunctionExecutables during bytecode generation
https://bugs.webkit.org/show_bug.cgi?id=199866
<rdar://problem/53333108>
Reviewed by Tadeu Zagallo.
This patch removes performance pathologies regarding programs with
many variables under TDZ (let/const). We had an algorithm for caching
the results of gathering all variables under TDZ, but that algorithm
wasn't nearly aggressive enough in its caching. This lead us to worst
case quadratic runtime, which could happens in practice for large functions.
There are a few fixes here:
- Instead of flattening the entire TDZ stack, and caching that result,
we now cache each stack entry individually. So as you push/pop to the
TDZ environment stack, we no longer invalidate everything. Instead, we
will just need to cache the newly pushed entry. We also no longer invalidate
the cache for lifting a TDZ check. The compromise here is we may emit
more runtime TDZ checks for closure variables. This is better than N^2
bytecode compile time perf, since a well predicted branch for a TDZ
check is essentially free.
- We no longer transform the CompactTDZEnvironment (formerly CompactVariableEnvironment)
from a Vector into a HashSet each time we generate code for an inner function. Instead,
CompactTDZEnvironment can be in two modes: compact and inflated. It starts life off in
compact mode (a vector), and will turn into an inflated mode if it's ever needed. Once
inflated, it'll stay this way until it's destructed. This improves our algorithm from being
O(EnvSize * NumFunctions) to O(EnvSize) at the cost of using more space in a HashTable versus a
Vector. In the future, we could consider just binary searching through this Vector, and never using
a hash table.
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::generateUnlinkedFunctionCodeBlock):
(JSC::UnlinkedFunctionExecutable::UnlinkedFunctionExecutable):
* bytecode/UnlinkedFunctionExecutable.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
(JSC::BytecodeGenerator::popLexicalScopeInternal):
(JSC::BytecodeGenerator::needsTDZCheck):
(JSC::BytecodeGenerator::liftTDZCheckIfPossible):
(JSC::BytecodeGenerator::pushTDZVariables):
(JSC::BytecodeGenerator::getVariablesUnderTDZ):
(JSC::BytecodeGenerator::preserveTDZStack):
(JSC::BytecodeGenerator::restoreTDZStack):
(JSC::BytecodeGenerator::emitNewInstanceFieldInitializerFunction):
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::generate):
(JSC::BytecodeGenerator::makeFunction):
* debugger/DebuggerCallFrame.cpp:
(JSC::DebuggerCallFrame::evaluateWithScopeExtension):
* interpreter/Interpreter.cpp:
(JSC::eval):
* parser/Parser.h:
(JSC::Parser<LexerType>::parse):
(JSC::parse):
* parser/VariableEnvironment.cpp:
(JSC::CompactTDZEnvironment::sortCompact):
(JSC::CompactTDZEnvironment::CompactTDZEnvironment):
(JSC::CompactTDZEnvironment::operator== const):
(JSC::CompactTDZEnvironment::toTDZEnvironmentSlow const):
(JSC::CompactTDZEnvironmentMap::get):
(JSC::CompactTDZEnvironmentMap::Handle::~Handle):
(JSC::CompactTDZEnvironmentMap::Handle::Handle):
(JSC::CompactVariableEnvironment::CompactVariableEnvironment): Deleted.
(JSC::CompactVariableEnvironment::operator== const): Deleted.
(JSC::CompactVariableEnvironment::toVariableEnvironment const): Deleted.
(JSC::CompactVariableMap::get): Deleted.
(JSC::CompactVariableMap::Handle::~Handle): Deleted.
(JSC::CompactVariableMap::Handle::Handle): Deleted.
* parser/VariableEnvironment.h:
(JSC::CompactTDZEnvironment::toTDZEnvironment const):
(JSC::CompactTDZEnvironmentKey::CompactTDZEnvironmentKey):
(JSC::CompactTDZEnvironmentKey::hash):
(JSC::CompactTDZEnvironmentKey::equal):
(JSC::CompactTDZEnvironmentKey::makeDeletedValue):
(JSC::CompactTDZEnvironmentKey::isHashTableDeletedValue const):
(JSC::CompactTDZEnvironmentKey::environment):
(WTF::HashTraits<JSC::CompactTDZEnvironmentKey>::emptyValue):
(WTF::HashTraits<JSC::CompactTDZEnvironmentKey>::isEmptyValue):
(WTF::HashTraits<JSC::CompactTDZEnvironmentKey>::constructDeletedValue):
(WTF::HashTraits<JSC::CompactTDZEnvironmentKey>::isDeletedValue):
(JSC::CompactTDZEnvironmentMap::Handle::environment const):
(JSC::CompactVariableEnvironment::hash const): Deleted.
(JSC::CompactVariableMapKey::CompactVariableMapKey): Deleted.
(JSC::CompactVariableMapKey::hash): Deleted.
(JSC::CompactVariableMapKey::equal): Deleted.
(JSC::CompactVariableMapKey::makeDeletedValue): Deleted.
(JSC::CompactVariableMapKey::isHashTableDeletedValue const): Deleted.
(JSC::CompactVariableMapKey::isHashTableEmptyValue const): Deleted.
(JSC::CompactVariableMapKey::environment): Deleted.
(WTF::HashTraits<JSC::CompactVariableMapKey>::emptyValue): Deleted.
(WTF::HashTraits<JSC::CompactVariableMapKey>::isEmptyValue): Deleted.
(WTF::HashTraits<JSC::CompactVariableMapKey>::constructDeletedValue): Deleted.
(WTF::HashTraits<JSC::CompactVariableMapKey>::isDeletedValue): Deleted.
(JSC::CompactVariableMap::Handle::Handle): Deleted.
(JSC::CompactVariableMap::Handle::operator=): Deleted.
(JSC::CompactVariableMap::Handle::operator bool const): Deleted.
(JSC::CompactVariableMap::Handle::environment const): Deleted.
(JSC::CompactVariableMap::Handle::swap): Deleted.
* runtime/CachedTypes.cpp:
(JSC::Decoder::handleForTDZEnvironment const):
(JSC::Decoder::setHandleForTDZEnvironment):
(JSC::CachedCompactTDZEnvironment::encode):
(JSC::CachedCompactTDZEnvironment::decode const):
(JSC::CachedCompactTDZEnvironmentMapHandle::encode):
(JSC::CachedCompactTDZEnvironmentMapHandle::decode const):
(JSC::CachedFunctionExecutableRareData::decode const):
(JSC::Decoder::handleForEnvironment const): Deleted.
(JSC::Decoder::setHandleForEnvironment): Deleted.
(JSC::CachedCompactVariableEnvironment::encode): Deleted.
(JSC::CachedCompactVariableEnvironment::decode const): Deleted.
(JSC::CachedCompactVariableMapHandle::encode): Deleted.
(JSC::CachedCompactVariableMapHandle::decode const): Deleted.
* runtime/CachedTypes.h:
* runtime/CodeCache.cpp:
(JSC::generateUnlinkedCodeBlockImpl):
(JSC::generateUnlinkedCodeBlock):
(JSC::generateUnlinkedCodeBlockForDirectEval):
(JSC::recursivelyGenerateUnlinkedCodeBlockForProgram):
(JSC::recursivelyGenerateUnlinkedCodeBlockForModuleProgram):
(JSC::CodeCache::getUnlinkedGlobalCodeBlock):
* runtime/CodeCache.h:
* runtime/Completion.cpp:
(JSC::generateProgramBytecode):
(JSC::generateModuleBytecode):
* runtime/DirectEvalExecutable.cpp:
(JSC::DirectEvalExecutable::create):
* runtime/DirectEvalExecutable.h:
* runtime/JSScope.cpp:
(JSC::JSScope::collectClosureVariablesUnderTDZ):
* runtime/JSScope.h:
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2020-10-28 Robin Morisset <rmorisset@apple.com>
DFGIntegerRangeOptimization is wrong for Upsilon (as 'shadow' nodes are not in SSA form)
https://bugs.webkit.org/show_bug.cgi?id=218073
Reviewed by Saam Barati.
In DFGIntegerRangeOptimization, when visiting an Upsilon node, we call setEquivalence, that calls setRelationship.
But despite its name, this function does not overwrite a pre-existing relationship, it simply replaces it by an over-approximation of the intersection of the old and new relationship (see the filter method).
Since the old relationship is always (by definition) an over-approximation of this intersection, it will often do nothing at all if it cannot find a closer approximation.
This is a problem specifically for Upsilon nodes, because several of them can store to the same "shadow node" corresponding to a given Phi, so they are the only case where there can already be a completely different relationship for the same nodes (coming from a different Upsilon).
The fix is very simple thanks to a suggestion by Phil: we just remove all relationships referring to the shadow node just before executing an Upsilon.
This is correct since the upsilon effectively kills that shadow node, before making it live again with a different value, and we already aggressively prune the relationshipMaps by liveness.
* dfg/DFGIntegerRangeOptimizationPhase.cpp:
2020-10-27 Michael Catanzaro <mcatanzaro@gnome.org>
-Wparentheses warning in OptionsList.h
https://bugs.webkit.org/show_bug.cgi?id=218242
Unreviewed, fix warning by adding extra parentheses.
* runtime/OptionsList.h:
2020-10-26 Devin Rousso <drousso@apple.com>
Web Inspector: console command line API should be exposed to breakpoint conditions/actions
https://bugs.webkit.org/show_bug.cgi?id=218141
<rdar://problem/70636727>
Reviewed by Brian Burg.
* debugger/Debugger.h:
(JSC::Debugger::Client::scopeExtensionObject): Added.
* debugger/Debugger.cpp:
(JSC::Debugger::setClient): Added.
(JSC::Debugger::evaluateBreakpointCondition):
(JSC::Debugger::evaluateBreakpointActions):
Introduce an optional `Debugger::Client` virtual class that can be used to adjust behavior
in various situations. Right now it is used when evaluating breakpoint conditions/actions
to get a scope extension object.
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::internalEnable):
(Inspector::InspectorDebuggerAgent::internalDisable):
(Inspector::InspectorDebuggerAgent::scopeExtensionObject): Added.
Implement `Debugger::Client` and provide a newly created `CommandLineAPI` instance.
* inspector/InjectedScript.h:
* inspector/InjectedScript.cpp:
(Inspector::InjectedScript::createCommandLineAPIObject const): Added.
* inspector/InjectedScriptSource.js:
(let.InjectedScript.prototype.createCommandLineAPIObject): Added.
(let.InjectedScript.prototype._evaluateOn):
Expose a way for the C++ to create `CommandLineAPI` instances.
2020-10-15 Tadeu Zagallo <tzagallo@apple.com>
Sign MacroAssembler::jumpsToLink
https://bugs.webkit.org/show_bug.cgi?id=217774
<rdar://problem/69433058>
Reviewed by Saam Barati.
* assembler/ARM64Assembler.h:
(JSC::ARM64Assembler::LinkRecord::LinkRecord):
(JSC::ARM64Assembler::LinkRecord::setFrom):
(JSC::ARM64Assembler::LinkRecord::to const):
(JSC::ARM64Assembler::linkJump):
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::copyCompactAndLinkCode):
2020-10-15 Tadeu Zagallo <tzagallo@apple.com>
Validate addresses returned by LinkBuffer::locationOf
https://bugs.webkit.org/show_bug.cgi?id=217786
<rdar://problem/69887913>
Reviewed by Saam Barati.
* assembler/LinkBuffer.h:
(JSC::LinkBuffer::locationOf):
(JSC::LinkBuffer::locationOfNearCall):
(JSC::LinkBuffer::getLinkerAddress):
2020-10-26 Alex Christensen <achristensen@webkit.org>
Inclusive software: Remove instances of "dumb" from the code
https://bugs.webkit.org/show_bug.cgi?id=217778
Reviewed by Simon Fraser.
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCallEval):
(JSC::FTL::DFG::LowerDFGToB3::unboxBoolean):
* heap/SlotVisitor.h:
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitVirtualCall):
(JSC::AssemblyHelpers::emitDumbVirtualCall): Deleted.
* jit/AssemblyHelpers.h:
* jit/JITCall.cpp:
(JSC::JIT::compileCallEvalSlowCase):
* jit/JITCall32_64.cpp:
(JSC::JIT::compileCallEvalSlowCase):
* runtime/CachedTypes.cpp:
* runtime/JSCJSValue.h:
* runtime/WriteBarrier.h:
* runtime/WriteBarrierInlines.h:
(JSC::RawValueTraits<Unknown>>::set):
(JSC::DumbValueTraits<Unknown>>::set): Deleted.
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::addCallIndirect):
* wasm/generateWasm.py:
(opcodeIterator):
2020-10-26 Sam Weinig <weinig@apple.com>
JSC special function forward declarations (e.g. JSC_DECLARE_HOST_FUNCTION) that are internal to a cpp file should be declared with static to avoid external linkage
https://bugs.webkit.org/show_bug.cgi?id=218159
Reviewed by Darin Adler.
Add static prefix when declarations are constrained to the cpp file. This should help out the linker
by using the correct linkage type.
* runtime/ArrayPrototype.cpp:
* runtime/AsyncGeneratorFunctionConstructor.cpp:
* runtime/AtomicsObject.cpp:
* runtime/DateConstructor.cpp:
* runtime/DatePrototype.cpp:
* runtime/InspectorInstrumentationObject.cpp:
* runtime/JSDataViewPrototype.cpp:
* runtime/JSONObject.cpp:
* runtime/MathObject.cpp:
* runtime/ObjectConstructor.cpp:
* runtime/RegExpObject.cpp:
* runtime/StringPrototype.cpp:
2020-10-24 Yusuke Suzuki <ysuzuki@apple.com>
[ECMA-402] Implement Intl.ListFormat
https://bugs.webkit.org/show_bug.cgi?id=209775
Reviewed by Ross Kirsling.
This patch implements Intl.ListFormat. Intl.ListFormat requires ulistfmt_openForType.
But it is available after ICU 67, and it is draft (unstable) API in ICU 67.
But now, this function is stable in ICU 68 without signature change and no major
change happened to this API. Thus, we can assume that this API signature won't be changed.
We specially undef U_HIDE_DRAFT_API for unicode/ulistformatter.h to use this draft (but stable) APIs.
While macOS / iOS shipping ICU (AppleICU) is ICU 66, AppleICU has ulistfmt_openForType and related APIs
even in ICU 66. We use these APIs in AppleICU 66 to implement Intl.ListFormat.
* CMakeLists.txt:
* DerivedSources-input.xcfilelist:
* DerivedSources-output.xcfilelist:
* DerivedSources.make:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* runtime/CommonIdentifiers.h:
* runtime/IntlDisplayNames.cpp:
(JSC::IntlDisplayNames::initializeDisplayNames):
* runtime/IntlListFormat.cpp: Added.
(JSC::UListFormatterDeleter::operator()):
(JSC::IntlListFormat::create):
(JSC::IntlListFormat::createStructure):
(JSC::IntlListFormat::IntlListFormat):
(JSC::IntlListFormat::finishCreation):
(JSC::IntlListFormat::initializeListFormat):
(JSC::stringListFromIterable):
(JSC::ListFormatInput::ListFormatInput):
(JSC::ListFormatInput::size const):
(JSC::ListFormatInput::stringPointers const):
(JSC::ListFormatInput::stringLengths const):
(JSC::IntlListFormat::format const):
(JSC::IntlListFormat::formatToParts const):
(JSC::IntlListFormat::resolvedOptions const):
(JSC::IntlListFormat::styleString):
(JSC::IntlListFormat::typeString):
* runtime/IntlListFormat.h: Added.
* runtime/IntlListFormatConstructor.cpp: Added.
(JSC::IntlListFormatConstructor::create):
(JSC::IntlListFormatConstructor::createStructure):
(JSC::IntlListFormatConstructor::IntlListFormatConstructor):
(JSC::IntlListFormatConstructor::finishCreation):
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/IntlListFormatConstructor.h: Added.
* runtime/IntlListFormatPrototype.cpp: Added.
(JSC::IntlListFormatPrototype::create):
(JSC::IntlListFormatPrototype::createStructure):
(JSC::IntlListFormatPrototype::IntlListFormatPrototype):
(JSC::IntlListFormatPrototype::finishCreation):
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/IntlListFormatPrototype.h: Added.
* runtime/IntlObject.cpp:
(JSC::createListFormatConstructor):
(JSC::IntlObject::finishCreation):
* runtime/IntlObject.h:
(JSC::intlListFormatAvailableLocales):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::listFormatStructure):
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2020-10-23 Keith Miller <keith_miller@apple.com>
Using WASM function size as the cap for choosing a register allocator causes performance regressions.
https://bugs.webkit.org/show_bug.cgi?id=217290
Reviewed by Michael Saboff.
Previously in https://bugs.webkit.org/show_bug.cgi?id=212105 we
limited the size of WASM functions we compile with OMG because
sufficiently large functions caused us to OOM while register
allocating. The memory growth we saw is because the memory usage
of graph coloring is O((number of tmps)^2). However, some large
WASM functions may not have that many tmps by the time we get to
register allocation. This patch changes our heuristic to instead
use the total number of tmps right before register allocation
instead of the WASM function size. The number of tmps is more
likely to represent the worst case memory usage of register
allocation. This fixes a performance regression in Safari 14 when running
https://dos.zone/en/play/https%3A%2F%2Fdoszone-uploads.s3.dualstack.eu-central-1.amazonaws.com%2Foriginal%2F2X%2Fb%2Fb4b5275904d86a4ab8a20917b2b7e34f0df47bf7.jsdos
* b3/air/AirGenerate.cpp:
(JSC::B3::Air::prepareForGeneration):
* runtime/OptionsList.h:
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::AirIRGenerator):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::B3IRGenerator):
(JSC::Wasm::parseAndCompile):
* wasm/WasmCompilationMode.cpp:
(JSC::Wasm::wasmFunctionSizeCanBeOMGCompiled): Deleted.
* wasm/WasmCompilationMode.h:
* wasm/WasmOperations.cpp:
(JSC::Wasm::JSC_DEFINE_JIT_OPERATION):
2020-10-23 Angelos Oikonomopoulos <angelos@igalia.com>
[JSC] Fix argument order for double and/or ops on ARMv7
https://bugs.webkit.org/show_bug.cgi?id=218118
Reviewed by Adrian Perez de Castro.
The andDouble and orDouble macro assembler methods for ARMv7
incorrectly pass the destination register as the last argument,
whereas the assembler expects the destination to be the first
argument.
This fixes a failing testmasm test.
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::andDouble):
(JSC::MacroAssemblerARMv7::orDouble):
2020-10-22 Robin Morisset <rmorisset@apple.com>
Use operand names when dumping Bytecode
https://bugs.webkit.org/show_bug.cgi?id=218084
Reviewed by Saam Barati.
For example this would output the following:
[ 258] put_to_scope scope:loc7, var:3, value:loc8, getPutInfo:1048576<DoNotThrowIfNotFound|GlobalProperty|Initialization|NotStrictMode>, symbolTableOrScopeDepth:0, offset:0
instead of
[ 258] put_to_scope loc7, 3, loc8, 1048576<DoNotThrowIfNotFound|GlobalProperty|Initialization|NotStrictMode>, 0, 0
* bytecode/BytecodeDumper.h:
(JSC::BytecodeDumperBase::dumpOperand):
* generator/Opcode.rb:
2020-10-21 Caitlin Potter <caitp@igalia.com>
[JSC] support op_get_private_name in DFG and FTL
https://bugs.webkit.org/show_bug.cgi?id=214861
Reviewed by Filip Pizlo.
Adds DFG/FTL support for op_get_private_name.
During DFG bytecode parsing, we will attempt, if deemed possible by
the information available, to output a GetByOffset operation. If a
single private field identifier is used in all cases (the common case),
but there are too many structure variants, a GetPrivateNameById
operation is emitted instead. Failing that, the GetPrivateName
operation is produced, which produces a GetByVal IC like in the
baseline JIT.
In FTL, GetPrivateNameByID can be reduced to [Multi]GetByOffset in the
DFGConstantFoldingPhase, or a GetByID IC when lowering to B3.
* bytecode/GetByStatus.cpp:
(JSC::GetByStatus::computeFromLLInt):
* bytecode/StructureStubInfo.h:
(JSC::appropriateOptimizingGetByIdFunction):
(JSC::appropriateGenericGetByIdFunction):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::simplifyGetByStatus):
(JSC::DFG::ByteCodeParser::handleGetById):
(JSC::DFG::ByteCodeParser::handleGetPrivateNameById):
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::convertToGetByOffset):
(JSC::DFG::Node::convertToMultiGetByOffset):
(JSC::DFG::Node::hasCacheableIdentifier):
(JSC::DFG::Node::hasHeapPrediction):
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileGetPrivateName):
(JSC::DFG::SpeculativeJIT::compileGetPrivateNameByVal):
(JSC::DFG::SpeculativeJIT::compileGetPrivateNameById):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::getPrivateName):
(JSC::FTL::DFG::LowerDFGToB3::compileGetPrivateName):
(JSC::FTL::DFG::LowerDFGToB3::compileGetPrivateNameById):
* jit/ICStats.h:
* jit/JITOperations.cpp:
(JSC::getPrivateName):
(JSC::JSC_DEFINE_JIT_OPERATION):
* jit/JITOperations.h:
* jit/Repatch.cpp:
(JSC::appropriateOptimizingGetByFunction):
(JSC::appropriateGetByFunction):
(JSC::tryCacheGetBy):
* jit/Repatch.h:
* runtime/OptionsList.h:
2020-10-20 Saam Barati <sbarati@apple.com>
Don't OSR exit to bc#0 for FTL argument type checks during loop OSR entry
https://bugs.webkit.org/show_bug.cgi?id=217925
<rdar://problem/70369407>
Reviewed by Michael Saboff and Tadeu Zagallo.
When the FTL was emitting type checks for the named arguments of a function,
it was always emitting these type checks with an exit origin of bc#0. It was
doing this even if we were an OSR entry compilation! This meant that type
checks for arguments that failed during loop OSR entry would incorrectly exit
back to bc#0.
This patch fixes this by having the OSR entry runtime code validate the
argument types before OSR entering. The current OSR entry compiled code in
the FTL is designed to only allow exiting after all ExtractOSREntryLocal and
MovHints have executed, so it is simpler to put the type checks in the runtime
instead of the compiled code.
This patch also makes it so we do exponential backoff when failing to OSR
enter. This is needed due to insufficient profiling where we never properly
profile the type of arguments. Before this, we'd OSR exit in the FTL code
itself, which does exponential backoff when recompiling. This patch builds
this same exponential backoff in for when we fail to OSR enter enough times
to give up on the OSR entry compilation.
* ftl/FTLForOSREntryJITCode.h:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::lower):
* ftl/FTLOSREntry.cpp:
(JSC::FTL::prepareOSREntry):
2020-10-20 Michael Saboff <msaboff@apple.com>
[JSC] Update RegExp UCD to version 13.0
https://bugs.webkit.org/show_bug.cgi?id=217975
Reviewed by Yusuke Suzuki.
UCD 13.0 data files and an update to the generated file's copyright.
* ucd/CaseFolding.txt:
* ucd/DerivedBinaryProperties.txt:
* ucd/DerivedCoreProperties.txt:
* ucd/DerivedNormalizationProps.txt:
* ucd/PropList.txt:
* ucd/PropertyAliases.txt:
* ucd/PropertyValueAliases.txt:
* ucd/ScriptExtensions.txt:
* ucd/Scripts.txt:
* ucd/UnicodeData.txt:
* ucd/emoji-data.txt:
* yarr/generateYarrUnicodePropertyTables.py:
2020-10-20 Ross Kirsling <ross.kirsling@sony.com>
[JSC] Rename item() to at() and move it behind a flag
https://bugs.webkit.org/show_bug.cgi?id=217942
Reviewed by Yusuke Suzuki.
{Array, %TypedArray%}.prototype.item is official web-incompatible,
but it is expected to be renamed to `at` instead of being scrapped entirely:
https://github.com/tc39/proposal-item-method/issues/34
This patch performs the renaming, but does so behind a runtime flag since this has yet to achieve consensus.
* builtins/ArrayPrototype.js:
(at):
(item): Deleted.
* builtins/TypedArrayPrototype.js:
(at):
(item): Deleted.
* runtime/ArrayPrototype.cpp:
(JSC::ArrayPrototype::finishCreation):
* runtime/JSTypedArrayViewPrototype.cpp:
(JSC::JSTypedArrayViewPrototype::finishCreation):
* runtime/OptionsList.h:
2020-10-20 Philippe Normand <pnormand@igalia.com> and Pavel Feldman <pavel.feldman@gmail.com>
Web Inspector: Add setScreenSizeOverride API to the Page agent
https://bugs.webkit.org/show_bug.cgi?id=213242
Reviewed by Devin Rousso.
* inspector/protocol/Page.json: Add a new setScreenSizeOverride API in the Page agent.
2020-10-19 Ross Kirsling <ross.kirsling@sony.com>
%TypedArray%#sort helper functions should be globalPrivate
https://bugs.webkit.org/show_bug.cgi?id=217928
Reviewed by Yusuke Suzuki and Alexey Shvayka.
Following r267827, this patch ensures that %TypedArray%.prototype.sort's helper functions:
1. use parameters instead of capturing variables
2. are converted from local functions to globalPrivate ones
To this end, also expose Math.min as a link-time constant.
* builtins/ArrayPrototype.js:
(globalPrivate.sortMerge):
(globalPrivate.sortMin): Deleted.
* builtins/BuiltinNames.h:
* builtins/TypedArrayPrototype.js:
(globalPrivate.typedArrayElementCompare): Added.
(globalPrivate.typedArrayMerge): Added.
(globalPrivate.typedArrayMergeSort): Added.
(sort):
(sort.min): Deleted.
(sort.merge): Deleted.
(sort.mergeSort): Deleted.
* bytecode/LinkTimeConstant.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/MathObject.cpp:
* runtime/MathObject.h:
2020-10-19 Alexey Shvayka <shvaikalesh@gmail.com>
[WebIDL] %Interface%.prototype.constructor should be defined on [[Set]] receiver
https://bugs.webkit.org/show_bug.cgi?id=216533
Reviewed by Darin Adler.
Before this change, a [[Set]] performed on an %Interface% instance used to overwrite
%Interface%.prototype.constructor instead of defining own "constructor" property.
Since using CustomValue is essential for lazy initialization of WebIDL constructors,
and forwarding [[Set]] with correct receiver would require further diverging
CustomValue setter signature from CustomAccessor counterpart, this patch makes a
CustomValue property without a setter to be treated as a data descriptor [1].
This avoids generating a "constructor" setter for every exposed WebIDL interface and
making an extra put() dispatch in putInlineSlow(). Changing the semantics is safe
because there were no setter-less CustomValue properties before this patch.
[1]: https://tc39.es/ecma262/#sec-ordinarysetwithowndescriptor (step 3.e.ii)
* bytecode/AccessCase.cpp:
(JSC::AccessCase::generateImpl):
* runtime/CustomGetterSetter.cpp:
(JSC::callCustomSetter):
* runtime/CustomGetterSetter.h:
* runtime/JSCJSValue.cpp:
(JSC::JSValue::putToPrimitive): Add missing exception check.
* runtime/JSCustomGetterSetterFunction.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/JSObject.cpp:
(JSC::JSObject::putInlineSlow):
* runtime/Lookup.h:
(JSC::putEntry):
* runtime/PropertySlot.cpp:
(JSC::PropertySlot::customGetter const):
* runtime/PropertySlot.h:
* tools/JSDollarVM.cpp:
2020-10-19 Mark Cohen <m@mpc.sh>
test262: test/language/expressions/conditional/in-branch-1.js
https://bugs.webkit.org/show_bug.cgi?id=217879
Reviewed by Darin Adler.
The test262 test in question checks that the parser respects the +In
parameter on the left-hand AssignmentExpression (between `?` and `:`)
in the ternary operator grammar. The relevant piece of the spec can be
found here (https://tc39.es/ecma262/#sec-conditional-operator). The
test checks this by embedding a ternary with left-hand
AssignmentExpression that contains the `in` keyword in the
initializing statement of a `for` loop, where `in` would normally be
disallowed. All this patch does is unconditionally allow the `in`
keyword inside the left-hand AssignmentExpression of a ternary.
This also fixes a variable typo in parseForStatement.
* parser/Parser.cpp:
2020-10-18 David Kilzer <ddkilzer@apple.com>
Fix -Wdeprecated-copy warnings in WTF and JavaScriptCore
<https://webkit.org/b/217855>
<rdar://problem/67716914>
Reviewed by Darin Adler.
* assembler/ARM64Assembler.h:
(JSC::ARM64Assembler::LinkRecord::LinkRecord): Add.
- Implement the copy constructor since the compiler may not
have implemented it the same way as the copy assignment
operator.
(JSC::ARM64Assembler::LinkRecord::operator=):
- Fix return type of copy assignment operator and simplify it.
2020-10-18 Caio Lima <ticaiolima@gmail.com>
[ESNext][JIT] Add support for UntypedUse on PutPrivateName's base operand
https://bugs.webkit.org/show_bug.cgi?id=217373
Reviewed by Yusuke Suzuki.
This patch is adding UntypedUse for `PutPrivateName`'s base operand to
avoid a OSR when we have a non-cell base.
Also, it is fixing a bug on private field operations `get_private_name` and
`put_private_name` to call `ToObject` on base to properly support
class fields spec text[1][2].
[1] - https://tc39.es/proposal-class-fields/#sec-getvalue
[2] - https://tc39.es/proposal-class-fields/#sec-putvalue
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compilePutPrivateName):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compilePutPrivateName):
* jit/JITOperations.cpp:
(JSC::setPrivateField):
(JSC::definePrivateField):
(JSC::JSC_DEFINE_JIT_OPERATION):
(JSC::getPrivateName):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_put_private_name):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_put_private_name):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/CommonSlowPaths.cpp:
Previous implementation was wrongly considering that base was always
an object, causing segmentation fault when base was not an object.
We changed this to handle cases when base is not and object, following
what spec text specifies.
2020-10-17 Ross Kirsling <ross.kirsling@sony.com>
Unreviewed fix for r268640
https://bugs.webkit.org/show_bug.cgi?id=217883
It seems I made a late adjustment that test262 was unhappy with; this reverts just that line.
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
2020-10-17 Ross Kirsling <ross.kirsling@sony.com>
Ensure %TypedArray% essential internal methods adhere to spec
https://bugs.webkit.org/show_bug.cgi?id=217854
Reviewed by Yusuke Suzuki.
This patch addresses https://github.com/tc39/ecma262/pull/2164,
which aligns detached buffer semantics in typed arrays with web reality.
In particular:
- [[HasProperty]] must not throw
- IntegerIndexedElementGet (i.e. [[GetOwnProperty]] and [[Get]]) must not throw
- IntegerIndexedElementSet (i.e. [[DefineOwnProperty]] and [[Set]]) must not throw
- Integer-indexed elements must be [[Configurable]] (to avoid breaking a [[HasProperty]] invariant)
- [[Delete]] must be overridden to return false for integer-indexed elements (which are *not* deletable)
This patch furthermore ensures that all of these essential internal methods have a spec-perfect implementation.
Note that there are a couple of interesting ripple effects here:
- The fill(), sort(), and set() methods should throw explicitly, but we'd been letting [[Get]] throw instead.
- Other callback-taking methods should *not* throw anymore; they only did so implicitly via [[Get]] and [[Set]].
* builtins/TypedArrayPrototype.js:
(fill):
(sort):
* runtime/JSGenericTypedArrayView.h:
* runtime/JSGenericTypedArrayViewInlines.h:
(JSC::JSGenericTypedArrayView<Adaptor>::set):
(JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlot):
(JSC::JSGenericTypedArrayView<Adaptor>::put):
(JSC::JSGenericTypedArrayView<Adaptor>::defineOwnProperty):
(JSC::JSGenericTypedArrayView<Adaptor>::deleteProperty):
(JSC::JSGenericTypedArrayView<Adaptor>::getOwnPropertySlotByIndex):
(JSC::JSGenericTypedArrayView<Adaptor>::deletePropertyByIndex):
* runtime/JSGlobalObjectFunctions.h:
* runtime/JSObjectInlines.h:
(JSC::JSObject::getPropertySlot):
(JSC::JSObject::getNonIndexPropertySlot):
* runtime/JSTypedArrays.cpp:
2020-10-16 Devin Rousso <drousso@apple.com>
Web Inspector: REGRESSION(r266074): line-based JavaScript breakpoints don't hit after reload
https://bugs.webkit.org/show_bug.cgi?id=217862
Reviewed by Timothy Hatcher.
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::clearDebuggerBreakpointState):
Don't clear the list of protocol breakpoints when the global object changes. Protocol
breakpoints should only be cleared when individually removed or by `Debugger.disable`.
2020-10-16 Saam Barati <sbarati@apple.com>
Don't emit OpSpread with a constant as the destination
https://bugs.webkit.org/show_bug.cgi?id=217800
<rdar://problem/69492311>
Reviewed by Yusuke Suzuki.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitCall):
(JSC::BytecodeGenerator::emitConstruct):
2020-10-16 Michael Catanzaro <mcatanzaro@gnome.org>
REGRESSION(r267727): Warning spam from JSC_DECLARE_CUSTOM_GETTER
https://bugs.webkit.org/show_bug.cgi?id=217585
Reviewed by Yusuke Suzuki.
A small number of source files now need to use JSC_DECLARE_CUSTOM_GETTER_WITHOUT_WTF_INTERNAL.
* b3/testb3_5.cpp:
* b3/testb3_7.cpp:
* tools/JSDollarVM.cpp:
2020-10-15 Saam Barati <sbarati@apple.com>
Don't assign a bogus register to Load/ForwardVarargs in AvailabilityAnalysis before stack layout
https://bugs.webkit.org/show_bug.cgi?id=217789
<rdar://problem/69285703>
Reviewed by Keith Miller.
There is code inside AvailabilityAnalysis phase that was assuming the
Load/ForwardVarargs data was already stack allocated. However, this isn't
guaranteed to be the case. However, we were doing virtual register math on
invalid virtual registers, leading to wonky results. The fix here is to
model it like we do GetStack/PutStack, where we say, before we do stack
allocation, we just tell availability analysis the flush format, but not
where it's flushed.
This was causing validation errors when merging these invalid FlushedAts with
the FlushedAts from GetStack/PutStack.
* dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
(JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
2020-10-15 Alexey Shvayka <shvaikalesh@gmail.com>
REGRESSION (r268489): test/built-ins/Object/entries/order-after-define-property.js failing on test262 bots
https://bugs.webkit.org/show_bug.cgi?id=217738
Reviewed by Yusuke Suzuki.
This change fixes an oversight of r268489 that caused Object.entries to
return a sparse array if its argument contained non-enumerable properties.
* builtins/ObjectConstructor.js:
(entries):
2020-10-14 Alexey Shvayka <shvaikalesh@gmail.com>
Use @putByValDirect instead of Array.prototype.@push in built-ins
https://bugs.webkit.org/show_bug.cgi?id=175432
Reviewed by Yusuke Suzuki.
Before this patch, Array.prototype.@push was used to implement List spec type,
stacks / queues, and in place of CreateDataProperty [1].
It's undesirably observable since elements are pushed using [[Set]],
affecting indexed properties on prototypes [2].
This change introduces @arrayPush() intrinsic to use with lists / stacks / queues.
@arrayPush() should only be used with JSArray receivers because "length" isn't
incremented. Unlike Array.prototype.@push, it doesn't grow arrays beyond UINT_MAX,
which is OK for current use cases. Object.entries microbenchmark is neutral.
Despite Array.prototype.@shift also performing [[Set]], it's safe to use with
non-sparse receivers.
[1]: https://tc39.es/ecma262/#sec-createarrayfromlist (step 4.a)
[2]: https://tc39.es/ecma262/#sec-array.prototype.push (step 5.a)
* builtins/ArrayPrototype.js:
(globalPrivate.sortBucketSort):
* builtins/ObjectConstructor.js:
(entries):
* builtins/RegExpPrototype.js:
(globalPrivate.matchSlow):
(Symbol.replace):
(Symbol.split):
* builtins/TypedArrayPrototype.js:
(filter):
* bytecode/BytecodeIntrinsicRegistry.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::BytecodeIntrinsicNode::emit_intrinsic_arrayPush):
* runtime/ArrayPrototype.cpp:
(JSC::ArrayPrototype::finishCreation):
2020-10-14 Don Olmstead <don.olmstead@sony.com>
Non-unified build fixes, mid October 2020
https://bugs.webkit.org/show_bug.cgi?id=217721
Reviewed by Yusuke Suzuki.
* API/JSContextRef.cpp:
* dfg/DFGDoesGCCheck.cpp:
* llint/LLIntExceptions.cpp:
* llint/LLIntExceptions.h:
* llint/LLIntThunks.h:
2020-10-13 Saam Barati <sbarati@apple.com>
JSObject::getPropertyNames should have a stack overflow check
https://bugs.webkit.org/show_bug.cgi?id=217677
<rdar://problem/69286436>
Reviewed by Tadeu Zagallo.
A prototype chain can be long enough where the recursion causes a stack
overflow. The attached test case uses $vm to mimic such a prototype chain
by using JSProxy to make a cyclic prototype chain. But the same works by
making a prototype chain very long, but the test case takes too long to
run to justify landing. For posterity, the alternate test case is:
```
function makeLongProtoChain(length) {
let object = /foo/;
for (let i = 0; i < length; ++i) {
next = /foo/;
next.__proto__ = object;
object = next;
}
return object;
}
let o = makeLongProtoChain(30000);
for (let q in o) {}
```
* runtime/JSObject.cpp:
(JSC::JSObject::getPropertyNames):
2020-10-13 Keith Rollin <krollin@apple.com>
Remove leftover MACOSX_DEPLOYMENT_TARGET_macosx support
https://bugs.webkit.org/show_bug.cgi?id=217649
<rdar://problem/70236877>
Reviewed by Darin Adler.
Bug 42796 introduced MACOSX_DEPLOYMENT_TARGET_<PLATFORM> as "support
for compiling WebKit against iOS SDKs". Support for the iOS part of
this feature was later removed in several changes, including Bug
139212, Bug 139463 and Bug 144762. However, vestiges have remained for
five or six years in the form of MACOSX_DEPLOYMENT_TARGET_macosx. The
inclusion of the platform in MACOSX_DEPLOYMENT_TARGET is no longer
needed and can be removed.
This changes brings most projects in conformance with other projects
that don't support including the platform in MACOSX_DEPLOYMENT_TARGET,
including WebEditingTester, gtest, WebKitTestRunner, MiniBrowser, and
TestWebKitAPI.
Along the way, remove a couple of left-over references to macOS 10.16,
and a couple of places where [sdk=macosx*] was still being used.
With this change, initialization of MACOSX_DEPLOYMENT_TARGET should be
consistent across all projects, with two exceptions: WebKitLauncher
(which hardcodes it to 10.12) and libwebrtc's copy of googletest
(which hardcodes it to 10.4). The reasons for these hard-coded values
is not apparent, so leave them be.
* Configurations/DebugRelease.xcconfig:
2020-10-12 Yusuke Suzuki <ysuzuki@apple.com>
JIT operations do not need extern "C"
https://bugs.webkit.org/show_bug.cgi?id=217636
Reviewed by Saam Barati.
Since they are directly embedded by JIT code generator (not linked via linker), they do not need to be C linkage.
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* ftl/FTLOSRExitCompiler.cpp:
* ftl/FTLOSRExitCompiler.h:
* ftl/FTLOperations.cpp:
* ftl/FTLOperations.h:
* jit/JITOperations.cpp:
* jit/JITOperations.h:
2020-10-12 Saam Barati <sbarati@apple.com>
Array.prototype.sort's sortBucketSort accesses an array in an invalid way that can lead to incorrect results with indexed properties on the prototype chain
https://bugs.webkit.org/show_bug.cgi?id=217634
<rdar://problem/69489404>
Reviewed by Yusuke Suzuki.
Inside one of Array.prototype.sort's builtin helper methods, we are using an
array as an internal data structure to do some bookkeeping. However, we were
accessing it in such a way that it was reading properties from the prototype
chain. The code is written in a way such that it is only correct if it is
reading self properties (as the prototype chain can be user controlled). The
fix is to set this bookkeeping array's __proto__ to null, so we don't read
from the prototype chain.
* builtins/ArrayPrototype.js:
(globalPrivate.sortBucketSort):
2020-10-11 Yusuke Suzuki <ysuzuki@apple.com>
OpToPropertyKey only accepts temporary for destination
https://bugs.webkit.org/show_bug.cgi?id=217471
Reviewed by Saam Barati.
propertyName register can be constant. We should create temporary register if it is necessary for the destination.
* bytecompiler/NodesCodegen.cpp:
(JSC::ObjectPatternNode::bindValue const):
2020-10-12 Luming Yin <luming_yin@apple.com>
[macOS] Workaround for MAC_OS_X_VERSION_MAJOR incorrectly including minor version when building
with Xcode 12 on macOS Big Sur SUs
https://bugs.webkit.org/show_bug.cgi?id=217602
rdar://70194453
Reviewed by Darin Adler.
The previous workaround turns out to be ineffective because we can't set the value of
TARGET_MAC_OS_X_VERSION_MAJOR based on a previous value of itself. Introduce a new
variable TARGET_MAC_OS_X_VERSION_MAJOR to determine whether we need to explicitly
adjust MAC_OS_X_VERSION_MAJOR to 110000.
* Configurations/DebugRelease.xcconfig:
2020-10-12 Luming Yin <luming_yin@apple.com>
[macOS] Workaround for MAC_OS_X_VERSION_MAJOR incorrectly including minor version when building
with Xcode 12 on macOS Big Sur SUs
https://bugs.webkit.org/show_bug.cgi?id=217602
rdar://70194453
Reviewed by Darin Adler.
Due to a bug in Xcode (rdar://70185899), Xcode 12.0 and Xcode 12.1 Beta incorrectly includes the
minor release number in MAC_OS_X_VERSION_MAJOR, which causes Debug and Release builds of WebKit
to be misconfigured when building on macOS Big Sur SUs, leading to webpages failing to load.
To work around the Xcode bug, when the MAC_OS_X_VERSION_MAJOR includes the minor version number,
drop the minor version number by explicitly setting TARGET_MAC_OS_X_VERSION_MAJOR to 110000.
Note: This change should be reverted after <rdar://70185899> is resolved.
* Configurations/DebugRelease.xcconfig:
2020-10-11 Luming Yin <luming_yin@apple.com>
Strip patch version from TARGET_MAC_OS_X_VERSION_MAJOR when building for macOS Big Sur
or later
https://bugs.webkit.org/show_bug.cgi?id=217594
rdar://70188497
Reviewed by Darin Adler.
To ensure successful Mac Catalyst WebKit builds, strip the patch version from
TARGET_MAC_OS_X_VERSION_MAJOR by using two `base:`s on MACOSX_DEPLOYMENT_TARGET.
* Configurations/Base.xcconfig:
2020-10-11 Luming Yin <luming_yin@apple.com>
Ignore deployment suffix and identifier when computing major OS version for macOS
Big Sur and newer
https://bugs.webkit.org/show_bug.cgi?id=217584
rdar://70168426
Reviewed by Darin Adler.
Stop using MACOSX_DEPLOYMENT_TARGET:suffix:identifier to compute major OS versions.
Only use the deployment target base for macOS Big Sur and newer. Keep the manual
definitions for legacy versions of macOS.
* Configurations/Base.xcconfig:
2020-10-11 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, mark missing custom getter and setters
https://bugs.webkit.org/show_bug.cgi?id=217500
* tools/JSDollarVM.cpp:
2020-10-11 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] arguments.callee should become ThrowTypeError if function has non simple parameter list
https://bugs.webkit.org/show_bug.cgi?id=217574
Reviewed by Darin Adler.
We should set ThrowTypeError in ClonedArguments when the callee is strict mode or callee has non simple parameter list[1].
We propagate NonSimpleParameterList information from parser and use it when materializing "callee" property of ClonedArguments.
[1]: https://tc39.es/ecma262/#sec-functiondeclarationinstantiation
* parser/Nodes.h:
(JSC::ScopeNode::isStrictMode const):
(JSC::ScopeNode::usesNonSimpleParameterList const):
(JSC::ScopeNode::setFeatures): Deleted.
(JSC::ScopeNode::setUsesArguments): Deleted.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseInner):
* parser/ParserModes.h:
* runtime/ClonedArguments.cpp:
(JSC::ClonedArguments::getOwnPropertySlot):
(JSC::ClonedArguments::materializeSpecials):
* runtime/ScriptExecutable.h:
(JSC::ScriptExecutable::usesNonSimpleParameterList const):
2020-10-11 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] BigInt constructor should be constructible while it always throws an error
https://bugs.webkit.org/show_bug.cgi?id=217575
Reviewed by Darin Adler.
In terms of the spec, BigInt constructor should be a constructor. So we should put constructBigIntConstructor function instead of nullptr.
But it should always throw a TypeError. Error message looks a bit awkward ("TypeError: function is not a constructor..."), but this looks
most intuitive to users. Note that V8 and SpiderMonkey throw similar messages ("is not a constructor").
* runtime/BigIntConstructor.cpp:
(JSC::BigIntConstructor::BigIntConstructor):
(JSC::JSC_DEFINE_HOST_FUNCTION):
2020-10-11 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] LowerCase when LanguageTag checks duplicate variants
https://bugs.webkit.org/show_bug.cgi?id=217571
Reviewed by Ross Kirsling.
Since Unicode LanguageTag is case insensitive, we need to recognize "VARIANT0" and "variant0" are the same language tag variants.
To achieve that, we perform toASCIILower when computing VariantCode.
* runtime/IntlObject.cpp:
(JSC::parseVariantCode):
2020-10-09 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Assert Operation and HostFunction are in JITOperationsList
https://bugs.webkit.org/show_bug.cgi?id=217500
Reviewed by Saam Barati.
We make JSC PtrTag more restricted. We add the following information for each PtrTag.
1. What code target is tagged with this PtrTag? Native or JIT.
2. What uses this PtrTag when invoking code? Native, JIT, or None.
And we will verify via JIT-caging.
This patch adds HostFunctionPtrTag and sign host functions with it. Previously, it was signed with JSEntryPtrTag,
and this is wrong since it is used for JS entry thunks. And we introduce assertion that function is registered in
JITOperationList when signing function with OperationPtrTag or HostFunctionPtrTag.
We also annotate all operations in testb3 so that testb3 can work with OperationPtrTag / HostFunctionPtrTag assertions.
* assembler/JITOperationList.cpp:
(JSC::addPointers):
* assembler/JITOperationList.h:
* b3/testb3_1.cpp:
(main):
* b3/testb3_5.cpp:
(JSC_DEFINE_JIT_OPERATION):
(simpleFunction): Deleted.
(functionWithHellaArguments): Deleted.
(functionWithHellaArguments2): Deleted.
(functionWithHellaArguments3): Deleted.
(simpleFunctionDouble): Deleted.
(simpleFunctionFloat): Deleted.
(functionWithHellaDoubleArguments): Deleted.
(functionWithHellaFloatArguments): Deleted.
* b3/testb3_6.cpp:
(JSC_DEFINE_JIT_OPERATION):
(interpreterPrint): Deleted.
* b3/testb3_7.cpp:
(JSC_DEFINE_JIT_OPERATION):
(oneFunction): Deleted.
(noOpFunction): Deleted.
(functionNineArgs): Deleted.
* dfg/DFGOSREntry.cpp:
(JSC::DFG::prepareOSREntry):
* dfg/DFGOperations.cpp:
* jit/JITOperations.cpp:
* jit/ThunkGenerators.cpp:
(JSC::nativeForGenerator):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/JSCPtrTag.cpp:
(JSC::tagForPtr):
(JSC::ptrTagName):
* runtime/JSCPtrTag.h:
(JSC::tagJSCCodePtrImpl):
(JSC::untagJSCCodePtrImpl):
* runtime/NativeFunction.h:
(JSC::TaggedNativeFunction::TaggedNativeFunction):
(JSC::TaggedNativeFunction::operator NativeFunction):
* wasm/WasmOperations.cpp:
(JSC::Wasm::doOSREntry):
2020-10-09 Keith Miller <keith_miller@apple.com>
Enable WeakRefs/FinalizationRegistries by default.
https://bugs.webkit.org/show_bug.cgi?id=215789
Reviewed by Yusuke Suzuki.
* runtime/OptionsList.h:
2020-10-09 Keith Miller <keith_miller@apple.com>
Finalizers shouldn't run if events can't fire
https://bugs.webkit.org/show_bug.cgi?id=214508
Reviewed by Ryosuke Niwa.
This patch makes it so the DeferredWorkTimer won't run scheduled
tasks if those would not have run if they were scheduled in
WebCore. To do this there is now a concept of a
ScriptExecutionOwner. The ScriptExecutionOwner is almost always
the same as the global object of the pending task (referred to as
the ticket). The only exception to this is if the global object
is a JSDOMWindowBase, then the ScriptExecutionOwner is the
Document's JS wrapper. To tell the status of a
ScriptExecutionOwner, the DeferredWorkTimer calls a virtual
function on the global object of the ticket, for JSC-only this
just always returns Running. For WebCore, we ask the
ScriptExecutionContext associated with the ScriptExecutionOwner.
* API/JSAPIGlobalObject.cpp:
* API/JSAPIGlobalObject.mm:
* jsc.cpp:
* runtime/DeferredWorkTimer.cpp:
(JSC::DeferredWorkTimer::doWork):
(JSC::DeferredWorkTimer::addPendingWork):
(JSC::DeferredWorkTimer::hasDependancyInPendingWork):
(JSC::DeferredWorkTimer::didResumeScriptExecutionOwner):
* runtime/DeferredWorkTimer.h:
* runtime/JSFinalizationRegistry.cpp:
(JSC::JSFinalizationRegistry::create):
(JSC::JSFinalizationRegistry::finishCreation):
* runtime/JSFinalizationRegistry.h:
* runtime/JSGlobalObject.cpp:
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::currentScriptExecutionOwner):
(JSC::JSGlobalObject::scriptExecutionStatus):
2020-10-08 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, reland r268170
https://bugs.webkit.org/show_bug.cgi?id=217460
Fixed missing wrong OperationPtrTag use in Repatch.cpp.
* assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::getLinkerAddress):
* assembler/AssemblerBuffer.h:
(JSC::ARM64EHash::update):
(JSC::ARM64EHash::finalHash const):
* assembler/JITOperationList.cpp:
(JSC::addPointers):
* assembler/MacroAssemblerARM64.cpp:
(JSC::MacroAssembler::probe):
* assembler/MacroAssemblerCodeRef.h:
(JSC::MacroAssemblerCodePtr::MacroAssemblerCodePtr):
(JSC::MacroAssemblerCodePtr::createFromExecutableAddress):
* assembler/testmasm.cpp:
(JSC::testProbeModifiesProgramCounter):
* b3/air/testair.cpp:
* ftl/FTLOutput.h:
(JSC::FTL::Output::callWithoutSideEffects):
(JSC::FTL::Output::operation):
* ftl/FTLSlowPathCall.cpp:
(JSC::FTL::SlowPathCallContext::makeCall):
* jit/JITCode.cpp:
(JSC::JITCodeWithCodeRef::executableAddressAtOffset):
* jit/JITExceptions.cpp:
(JSC::genericUnwind):
* jit/JITOperations.cpp:
* jit/Repatch.cpp:
(JSC::readPutICCallTarget):
(JSC::ftlThunkAwareRepatchCall):
(JSC::tryCacheGetBy):
(JSC::tryCachePutByID):
* llint/LLIntData.cpp:
(JSC::LLInt::initialize):
* llint/LLIntPCRanges.h:
(JSC::LLInt::isLLIntPC):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::setUpCall):
* llint/LLIntThunks.cpp:
(JSC::LLInt::generateThunkWithJumpTo):
* runtime/JSCPtrTag.h:
* runtime/MachineContext.h:
(JSC::MachineContext::instructionPointer):
* runtime/NativeExecutable.cpp:
(JSC::NativeExecutable::finishCreation):
* runtime/PutPropertySlot.h:
(JSC::PutPropertySlot::setCustomValue):
(JSC::PutPropertySlot::setCustomAccessor):
(JSC::PutPropertySlot::customSetter const):
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::emitCCall):
* wasm/WasmSlowPaths.cpp:
2020-10-08 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r268170 and r268190.
https://bugs.webkit.org/show_bug.cgi?id=217502
Crash on ARM64E exclusively
Reverted changesets:
"[JSC] Restrict more ptr-tagging and avoid using
OperationPtrTag for JIT code"
https://bugs.webkit.org/show_bug.cgi?id=217460
https://trac.webkit.org/changeset/268170
"Unreviewed, build fix for ARM64E"
https://bugs.webkit.org/show_bug.cgi?id=217460
https://trac.webkit.org/changeset/268190
2020-10-08 Ryosuke Niwa <rniwa@webkit.org>
Make it possible to send an arbitrary IPC message from JavaScript
https://bugs.webkit.org/show_bug.cgi?id=217423
<rdar://problem/69969351>
Reviewed by Geoffrey Garen.
Added a helper function to get uint64_t out of BigInt.
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::toUint64Heap): Added.
* runtime/JSBigInt.h:
(JSC::JSBigInt::toUint64): Added.
2020-10-07 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Restrict more ptr-tagging and avoid using OperationPtrTag for JIT code
https://bugs.webkit.org/show_bug.cgi?id=217460
Reviewed by Saam Barati.
This patch makes tagging / untagging pointer functions solid by using PtrTag in template parameter.
Later, we will introduce compile time behavior change for different kind of PtrTag so that we can insert OperationPtrTag validation
when tagging a function with OperationPtrTag.
We also found that FTL is tagging JIT code with OperationPtrTag wrongly. We should tag it with JITThunkPtrTag.
* assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::getLinkerAddress):
* assembler/AssemblerBuffer.h:
(JSC::ARM64EHash::update):
(JSC::ARM64EHash::finalHash const):
* assembler/JITOperationList.cpp:
(JSC::addPointers):
* assembler/MacroAssemblerARM64.cpp:
(JSC::MacroAssembler::probe):
* assembler/MacroAssemblerCodeRef.h:
(JSC::MacroAssemblerCodePtr::MacroAssemblerCodePtr):
(JSC::MacroAssemblerCodePtr::createFromExecutableAddress):
* assembler/testmasm.cpp:
(JSC::testProbeModifiesProgramCounter):
* b3/air/testair.cpp:
* ftl/FTLOutput.h:
(JSC::FTL::Output::callWithoutSideEffects):
(JSC::FTL::Output::operation):
* ftl/FTLSlowPathCall.cpp:
(JSC::FTL::SlowPathCallContext::makeCall):
* jit/JITCode.cpp:
(JSC::JITCodeWithCodeRef::executableAddressAtOffset):
* jit/JITExceptions.cpp:
(JSC::genericUnwind):
* jit/JITOperations.cpp:
* jit/Repatch.cpp:
(JSC::readPutICCallTarget):
(JSC::ftlThunkAwareRepatchCall):
(JSC::tryCacheGetBy):
(JSC::tryCachePutByID):
* llint/LLIntData.cpp:
(JSC::LLInt::initialize):
* llint/LLIntPCRanges.h:
(JSC::LLInt::isLLIntPC):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::setUpCall):
* llint/LLIntThunks.cpp:
(JSC::LLInt::generateThunkWithJumpTo):
* runtime/MachineContext.h:
(JSC::MachineContext::instructionPointer):
* runtime/NativeExecutable.cpp:
(JSC::NativeExecutable::finishCreation):
* runtime/PutPropertySlot.h:
(JSC::PutPropertySlot::setCustomValue):
(JSC::PutPropertySlot::setCustomAccessor):
(JSC::PutPropertySlot::customSetter const):
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::emitCCall):
* wasm/WasmSlowPaths.cpp:
2020-10-07 Ross Kirsling <ross.kirsling@sony.com>
[JSC] Revert String.prototype.item
https://bugs.webkit.org/show_bug.cgi?id=217449
Reviewed by Yusuke Suzuki.
This patch reverts the String part of r267814, as it has been shown to be web-incompatible:
https://github.com/tc39/proposal-item-method/issues/31
Thankfully, this was the inessential part of the proposal; the core parts (Array and %TypedArray%) remain for now.
* builtins/StringPrototype.js:
(item): Deleted.
* runtime/StringPrototype.cpp:
2020-10-07 Keith Rollin <krollin@apple.com>
Update post-processing rules for headers to not unnecessarily change timestamps
https://bugs.webkit.org/show_bug.cgi?id=217371
<rdar://problem/69992230>
Reviewed by Darin Adler.
Under XCBuild, the scripts employed in custom build rules can be
invoked in innocuous situations. A common example is when the user is
building from the command-line and they change the `make` output from
stdout to a file, or vice-versa. Changing the output changes the
setting of the COLOR_DIAGNOSTICS environment variable, which is enough
to cause XCBuild to think something is different and that the custom
build rule needs to be invoked. For the script's part, nothing
significant has changed, yet it post-processes the header files,
causing their modification dates to change, causing downstream
rebuilds to occur.
Fix this problem by adopting an approach that doesn't modify the
post-processed header files unless their contents actually change.
* Scripts/postprocess-header-rule:
2020-10-05 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] More consistent PtrTagging for code types
https://bugs.webkit.org/show_bug.cgi?id=217362
Reviewed by Mark Lam.
1. Avoid tagging JIT code with OperationPtrTag. OperationPtrTag should be used only for operations (C++ code).
2. Avoid mixing JIT and C++ code for the same tagged pointers. For exception trampoline, in JIT mode, we should have
JIT trampoline thunk which goes to LLInt bytecode handler code.
* bytecode/BytecodeList.rb:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::finalizeUnconditionally):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::compileExceptionHandlers):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileMathIC):
* jit/ICStats.h:
* jit/JIT.cpp:
(JSC::JIT::compileWithoutLinking):
(JSC::JIT::link):
(JSC::JIT::privateCompileExceptionHandlers):
* jit/JIT.h:
(JSC::CallRecord::CallRecord):
* jit/JITCall.cpp:
(JSC::JIT::compileTailCall):
(JSC::JIT::compileOpCall):
(JSC::JIT::compileOpCallSlowCase):
* jit/JITCall32_64.cpp:
(JSC::JIT::compileOpCall):
(JSC::JIT::compileOpCallSlowCase):
* jit/JITExceptions.cpp:
(JSC::genericUnwind):
* jit/JITInlines.h:
(JSC::JIT::emitNakedNearCall):
(JSC::JIT::emitNakedNearTailCall):
(JSC::JIT::emitNakedCall): Deleted.
(JSC::JIT::emitNakedTailCall): Deleted.
* jit/JITPropertyAccess.cpp:
(JSC::JIT::privateCompilePutByVal):
(JSC::JIT::privateCompilePutPrivateNameWithCachedId):
(JSC::JIT::privateCompilePutByValWithCachedId):
* jit/SlowPathCall.h:
(JSC::JITSlowPathCall::call):
* llint/LLIntData.h:
(JSC::LLInt::getWide16CodeRef):
(JSC::LLInt::getWide32CodeRef):
(JSC::LLInt::getCodeFunctionPtr):
(JSC::LLInt::getWide16CodeFunctionPtr):
(JSC::LLInt::getWide32CodeFunctionPtr):
* llint/LLIntEntrypoint.cpp:
(JSC::LLInt::setFunctionEntrypoint):
(JSC::LLInt::setEvalEntrypoint):
(JSC::LLInt::setProgramEntrypoint):
(JSC::LLInt::setModuleProgramEntrypoint):
* llint/LLIntExceptions.cpp:
(JSC::LLInt::callToThrow):
(JSC::LLInt::handleUncaughtException):
(JSC::LLInt::catcher):
* llint/LLIntExceptions.h:
* llint/LLIntSlowPaths.cpp:
* llint/LLIntThunks.cpp:
(JSC::LLInt::generateThunkWithJumpTo):
(JSC::LLInt::functionForCallEntryThunk):
(JSC::LLInt::functionForConstructEntryThunk):
(JSC::LLInt::functionForCallArityCheckThunk):
(JSC::LLInt::functionForConstructArityCheckThunk):
(JSC::LLInt::evalEntryThunk):
(JSC::LLInt::programEntryThunk):
(JSC::LLInt::moduleProgramEntryThunk):
(JSC::LLInt::wasmFunctionEntryThunk):
(JSC::LLInt::callToThrowThunk):
(JSC::LLInt::handleUncaughtExceptionThunk):
(JSC::LLInt::catcherThunk):
* llint/LLIntThunks.h:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::processUnverifiedStackTraces):
* wasm/WasmOperations.cpp:
(JSC::Wasm::JSC_DEFINE_JIT_OPERATION):
2020-10-05 Ross Kirsling <ross.kirsling@sony.com>
%TypedArray%.from must do mapping and putting in lockstep
https://bugs.webkit.org/show_bug.cgi?id=217349
Reviewed by Yusuke Suzuki.
%TypedArray%.from first turns the input iterator into a list to find the size for the resulting typed array,
then it fills the typed array with the list elements.
If a map function is provided, however, it must be called during the *second* phase, not the first,
because if an element throws upon valueOf, that should prevent all further calls of the map function.
* builtins/TypedArrayConstructor.js:
(from):
2020-10-05 Yusuke Suzuki <ysuzuki@apple.com>
Unrevewed, fix crash for ASan debug builds
https://bugs.webkit.org/show_bug.cgi?id=217261
Reviewed by Saam Barati.
This function touches memory region which ASan cannot understand whether this is safe.
And ASan makes pointer fat so that it will see some null pointers.
* assembler/JITOperationList.cpp:
(JSC::addPointers):
2020-10-05 Keith Miller <keith_miller@apple.com>
Add JSC option to trigger a hardware breakpoint when debugger expressions are reached.
https://bugs.webkit.org/show_bug.cgi?id=217334
Reviewed by Yusuke Suzuki.
* interpreter/Interpreter.cpp:
(JSC::Interpreter::debug):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::defaultCodeGenerationMode const):
* runtime/OptionsList.h:
2020-10-05 David Kilzer <ddkilzer@apple.com>
Build fix: Use JSC_DEFINE_HOST_FUNCTION_WITH_ATTRIBUTES() with SUPPRESS_ASAN
<rdar://problem/69954783>
* tools/JSDollarVM.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION_WITH_ATTRIBUTES):
- Change `SUPPRESS_ASAN JSC_DEFINE_HOST_FUNCTION()` to
`JSC_DEFINE_HOST_FUNCTION_WITH_ATTRIBUTES(..., SUPPRESS_ASAN, ...)`
to fix the build.
2020-10-03 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Introduce JITOperationList to validate JIT-caged pointers
https://bugs.webkit.org/show_bug.cgi?id=217261
Reviewed by Saam Barati.
This patch adds JITOperationList, which manages all the host-function & jit-operation pointers.
And we can now query whether the given pointer is registered in this table.
Currently, as a test, we are verifying that host-function is registered in this table when creating NativeExecutable in debug build.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* assembler/JITOperationList.cpp: Added.
(JSC::JITOperationList::initialize):
(JSC::addPointers):
(JSC::JITOperationList::populatePointersInJavaScriptCore):
(JSC::JITOperationList::populatePointersInEmbedder):
* assembler/JITOperationList.h: Added.
(JSC::JITOperationList::contains const):
(JSC::JITOperationList::assertIsHostFunction):
(JSC::JITOperationList::assertIsJITOperation):
(JSC::JITOperationList::instance):
* assembler/MacroAssemblerARM64.cpp:
* assembler/MacroAssemblerARMv7.cpp:
* assembler/MacroAssemblerMIPS.cpp:
* assembler/MacroAssemblerX86Common.cpp:
* jsc.cpp:
(jscmain):
* runtime/InitializeThreading.cpp:
(JSC::initialize):
* runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
(JSC::genericTypedArrayViewProtoFuncSet):
(JSC::genericTypedArrayViewProtoFuncCopyWithin):
(JSC::genericTypedArrayViewProtoFuncIncludes):
(JSC::genericTypedArrayViewProtoFuncIndexOf):
(JSC::genericTypedArrayViewProtoFuncJoin):
(JSC::genericTypedArrayViewProtoFuncLastIndexOf):
(JSC::genericTypedArrayViewProtoGetterFuncBuffer):
(JSC::genericTypedArrayViewProtoGetterFuncLength):
(JSC::genericTypedArrayViewProtoGetterFuncByteLength):
(JSC::genericTypedArrayViewProtoGetterFuncByteOffset):
(JSC::genericTypedArrayViewProtoFuncReverse):
(JSC::genericTypedArrayViewPrivateFuncSort):
(JSC::genericTypedArrayViewProtoFuncSlice):
(JSC::genericTypedArrayViewPrivateFuncSubarrayCreate):
(JSC::JSC_DEFINE_HOST_FUNCTION): Deleted.
* runtime/VM.cpp:
(JSC::VM::getHostFunction):
2020-10-02 Ross Kirsling <ross.kirsling@sony.com>
[JSC] Add Array#item to @@unscopables
https://bugs.webkit.org/show_bug.cgi?id=217243
Reviewed by Yusuke Suzuki.
ES2015+ Array methods must be listed in Array.prototype[@@unscopables] per the note here:
https://tc39.es/ecma262/#sec-array.prototype-@@unscopables
The Array#item spec doesn't currently make this explicit, but I created an issue to ensure it isn't overlooked:
https://github.com/tc39/proposal-item-method/issues/30
* runtime/ArrayPrototype.cpp:
(JSC::ArrayPrototype::finishCreation):
2020-10-02 Adrian Perez de Castro <aperez@igalia.com>
Unreviewed. [GTK] Add missing locale.h header needed for setlocale()
* jsc.cpp: Add missing locale.h header for the GTK port, which is needed to get the
definition for setlocale() in scope.
2020-10-01 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Masm probe should invoke JIT operation function
https://bugs.webkit.org/show_bug.cgi?id=217199
Reviewed by Mark Lam.
Masm probe function should be invoked via OperationPtrTag since it is invoked from JIT code, and it is native code.
And we should register probe trampoline as JIT operation.
* assembler/MacroAssemblerARM64.cpp:
(JSC::MacroAssembler::probe):
* assembler/MacroAssemblerARMv7.cpp:
* assembler/MacroAssemblerMIPS.cpp:
* assembler/MacroAssemblerX86Common.cpp:
* runtime/JSCPtrTag.h:
2020-10-01 Adrian Perez de Castro <aperez@igalia.com> and Don Olmstead <don.olmstead@sony.com>
Non-unified build fixes, early October 2020 edition
https://bugs.webkit.org/show_bug.cgi?id=217165
Reviewed by Yusuke Suzuki.
* llint/LLIntEntrypoint.h:
* llint/LLIntSlowPaths.cpp:
2020-10-01 Yusuke Suzuki <ysuzuki@apple.com>
stress/put-private-name-invalid-define.js.ftl-eager is getting flaky failure
https://bugs.webkit.org/show_bug.cgi?id=217164
Reviewed by Mark Lam.
JIT operations need to use JITOperationPrologueCallFrameTracer to configure top call frame correctly.
But putById private field JIT operations miss them or use wrong frame tracer. Since we are not setting top frame correctly,
exception object creation from this JIT operations can be broken, and leading to stress/put-private-name-invalid-define.js.ftl-eager crash.
This patch configures top call frame via JITOperationPrologueCallFrameTracer appropriately.
* jit/JITOperations.cpp:
2020-10-01 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Define Array#sort's implementation functions as globalPrivate
https://bugs.webkit.org/show_bug.cgi?id=217168
Reviewed by Ross Kirsling.
Now, these Array#sort's implementation functions are not capturing any heap variables. So we can make them @globalPrivate,
this avoids function allocations in LLInt / Baseline / DFG in Array#sort.
* builtins/ArrayPrototype.js:
(globalPrivate.sortMin):
(globalPrivate.sortStringComparator):
(globalPrivate.sortCompact):
(globalPrivate.sortCommit):
(globalPrivate.sortMerge):
(globalPrivate.sortMergeSort):
(globalPrivate.sortBucketSort):
(sort):
(sort.min): Deleted.
(sort.stringComparator): Deleted.
(sort.compact): Deleted.
(sort.commit): Deleted.
(sort.merge): Deleted.
(sort.mergeSort): Deleted.
(sort.bucketSort): Deleted.
2020-10-01 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Do not use std::function in setPrivateField and definePrivateField
https://bugs.webkit.org/show_bug.cgi?id=217167
Reviewed by Ross Kirsling.
std::function can potentially allocate an object in heap. We should should just pass lambda with a templatized parameter instead.
* jit/JITOperations.cpp:
(JSC::setPrivateField):
(JSC::definePrivateField):
2020-09-30 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] We should not tag C function with JIT code related ptr tag
https://bugs.webkit.org/show_bug.cgi?id=217150
Reviewed by Mark Lam.
We are tagging getHostCallReturnValue function with JIT related PtrTag. As a part of JIT-caging effort, we are restricting our
PtrTag usage more for code types (e.g. JIT code should be tagged with JIT related PtrTag). So, we should not tag getHostCallReturnValue
with that. This patch implements getHostCallReturnValue in JIT code if JIT is enabled. If not, it is implemented by LLInt.
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* bytecode/BytecodeList.rb:
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* heap/MarkedBlock.h:
(JSC::MarkedBlock::Footer::offsetOfVM):
* heap/PreciseAllocation.h:
(JSC::PreciseAllocation::offsetOfWeakSet):
* heap/WeakSet.h:
(JSC::WeakSet::offsetOfVM):
* jit/HostCallReturnValue.cpp: Removed.
* jit/HostCallReturnValue.h: Removed.
* jit/JITOperations.cpp:
* jit/JITOperationsMSVC64.cpp: Removed.
* jit/JITStubsMSVC64.asm:
* llint/LLIntEntrypoint.cpp:
(JSC::LLInt::getHostCallReturnValueEntrypoint):
* llint/LLIntEntrypoint.h:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::handleHostCall):
(JSC::LLInt::commonCallEval):
* llint/LLIntThunks.cpp:
(JSC::LLInt::getHostCallReturnValueThunk):
* llint/LLIntThunks.h:
* llint/LowLevelInterpreter.cpp:
(JSC::CLoop::execute):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/JSCellInlines.h:
(JSC::tryAllocateCellHelper):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::offsetOfVM):
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
(JSC::VM::offsetOfEncodedHostCallReturnValue):
2020-09-30 Ross Kirsling <ross.kirsling@sony.com>
[JSC] Implement item method proposal
https://bugs.webkit.org/show_bug.cgi?id=217115
Reviewed by Yusuke Suzuki.
This patch implements {Array, %TypedArray%, String}.prototype.item, which reached Stage 3 at TC39 last week:
https://github.com/tc39/proposal-item-method/
This method behaves like the [] operator except:
- it recognizes negative indices (-1 through -length, without wrapping)
- it returns undefined *without* calling getters for out-of-bounds indices
The primary motivation for this is as a layering improvement for Web APIs (see, e.g., NodeList.prototype.item),
but the primary visible benefit for JavaScript users is negative indexation.
* builtins/ArrayPrototype.js:
(item):
* builtins/StringPrototype.js:
(item):
* builtins/TypedArrayPrototype.js:
(item):
* runtime/ArrayPrototype.cpp:
(JSC::ArrayPrototype::finishCreation):
* runtime/JSTypedArrayViewPrototype.cpp:
(JSC::JSTypedArrayViewPrototype::finishCreation):
* runtime/StringPrototype.cpp:
2020-09-30 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Common slow paths should be JIT operations
https://bugs.webkit.org/show_bug.cgi?id=217141
Reviewed by Saam Barati.
Unlike LLInt slow paths, common (common means common between LLInt and Baseline) slow paths can be called from baseline JIT code. Thus, they should be JIT operations.
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::llint_slow_path_checkpoint_osr_exit_from_inlined_call):
(JSC::LLInt::llint_slow_path_checkpoint_osr_exit):
(JSC::LLInt::slow_path_checkpoint_osr_exit_from_inlined_call): Deleted.
(JSC::LLInt::slow_path_checkpoint_osr_exit): Deleted.
* llint/LLIntSlowPaths.h:
* llint/LowLevelInterpreter.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::JSC_DEFINE_COMMON_SLOW_PATH):
(JSC::iteratorOpenTryFastImpl):
(JSC::iteratorNextTryFastImpl):
(JSC::SLOW_PATH_DECL): Deleted.
(JSC::iterator_open_try_fast): Deleted.
(JSC::iterator_next_try_fast): Deleted.
* runtime/CommonSlowPaths.h:
2020-09-30 Basuke Suzuki <basuke.suzuki@sony.com>
[PlayStation][WinCairo] Enable WebDriver target on PlayStation and client for WinCairo
https://bugs.webkit.org/show_bug.cgi?id=216908
Reviewed by Don Olmstead.
Implement automation session correctly for PlayStation and WinCairo.
* inspector/remote/RemoteInspector.h:
* inspector/remote/socket/RemoteInspectorConnectionClient.cpp:
(Inspector::RemoteInspectorConnectionClient::parseTargetListJSON):
* inspector/remote/socket/RemoteInspectorConnectionClient.h:
* inspector/remote/socket/RemoteInspectorSocket.cpp:
(Inspector::RemoteInspector::stopInternal):
(Inspector::RemoteInspector::requestAutomationSession):
(Inspector::RemoteInspector::startAutomationSession):
2020-09-30 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r267795.
https://bugs.webkit.org/show_bug.cgi?id=217135
Incorrect fix.
Reverted changeset:
"REGRESSION(r259582): Build fails on aarch64 Linux with WebKit
2.30.1 on LLIntOffsetsExtractor.cpp.o"
https://bugs.webkit.org/show_bug.cgi?id=217079
https://trac.webkit.org/changeset/267795
2020-09-30 Mike Gorse <mgorse@suse.com>
REGRESSION(r259582): Build fails on aarch64 Linux with WebKit 2.30.1 on LLIntOffsetsExtractor.cpp.o
https://bugs.webkit.org/show_bug.cgi?id=217079
Reviewed by Michael Catanzaro.
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::copyCompactAndLinkCode): DOn't compile in a call to
dumpJITMemory if JIT is disabled; leads to a build failure.
2020-09-29 Yusuke Suzuki <ysuzuki@apple.com>
Always use OperationPtrTag for all operations and annotate operations in CSS JIT
https://bugs.webkit.org/show_bug.cgi?id=217117
Reviewed by Mark Lam.
For JIT-caging, we would like to annotate all operations consistently with OperationPtrTag.
This patch replaces B3CCallPtrTag and CSSOperationPtrTag with OperationPtrTag and handle these
operations as Operation in JIT-caging.
We also collect and annotate all the operations called in CSS JIT and define them with JSC_DEFINE_JIT_OPERATION.
* b3/B3LowerMacros.cpp:
* b3/B3LowerMacrosAfterOptimizations.cpp:
* b3/B3MathExtras.cpp:
* b3/B3ReduceLoopStrength.cpp:
(JSC::B3::ReduceLoopStrength::reduceByteCopyLoopsToMemcpy):
* b3/B3ReduceStrength.cpp:
* b3/air/AirCCallSpecial.cpp:
(JSC::B3::Air::CCallSpecial::generate):
* b3/testb3_5.cpp:
(testCallSimple):
(testCallRare):
(testCallRareLive):
(testCallSimplePure):
(testCallFunctionWithHellaArguments):
(testCallFunctionWithHellaArguments2):
(testCallFunctionWithHellaArguments3):
(testCallSimpleDouble):
(testCallSimpleFloat):
(testCallFunctionWithHellaDoubleArguments):
(testCallFunctionWithHellaFloatArguments):
(testLinearScanWithCalleeOnStack):
* b3/testb3_6.cpp:
(testInterpreter):
* b3/testb3_7.cpp:
(testLICMPure):
(testLICMPureSideExits):
(testLICMPureWritesPinned):
(testLICMPureWrites):
(testLICMReadsLocalState):
(testLICMReadsPinned):
(testLICMReads):
(testLICMPureNotBackwardsDominant):
(testLICMPureFoiledByChild):
(testLICMPureNotBackwardsDominantFoiledByChild):
(testLICMExitsSideways):
(testLICMWritesLocalState):
(testLICMWrites):
(testLICMFence):
(testLICMWritesPinned):
(testLICMControlDependent):
(testLICMControlDependentNotBackwardsDominant):
(testLICMControlDependentSideExits):
(testLICMReadsPinnedWritesPinned):
(testLICMReadsWritesDifferentHeaps):
(testLICMReadsWritesOverlappingHeaps):
(testLICMDefaultCall):
(testShuffleDoesntTrashCalleeSaves):
* ftl/FTLOutput.h:
(JSC::FTL::Output::callWithoutSideEffects):
(JSC::FTL::Output::operation):
* runtime/JSCPtrTag.h:
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::emitCCall):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::addTableGet):
(JSC::Wasm::B3IRGenerator::addTableSet):
(JSC::Wasm::B3IRGenerator::addRefFunc):
(JSC::Wasm::B3IRGenerator::addTableSize):
(JSC::Wasm::B3IRGenerator::addTableGrow):
(JSC::Wasm::B3IRGenerator::addTableFill):
(JSC::Wasm::B3IRGenerator::addGrowMemory):
(JSC::Wasm::B3IRGenerator::setGlobal):
(JSC::Wasm::B3IRGenerator::emitWriteBarrierForJSWrapper):
(JSC::Wasm::B3IRGenerator::addOp<OpType::I32Popcnt>):
(JSC::Wasm::B3IRGenerator::addOp<OpType::I64Popcnt>):
2020-09-26 Darin Adler <darin@apple.com>
Refactor test runner code to cut down on copy/paste code and long-winded repetitive idioms
https://bugs.webkit.org/show_bug.cgi?id=217028
Reviewed by Sam Weinig.
* API/JSRetainPtr.h: Added support for JSClassRef.
2020-09-29 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Annotate JIT operation functions called from B3 etc.
https://bugs.webkit.org/show_bug.cgi?id=217082
Reviewed by Saam Barati.
There are many math functions that are called from B3 etc. We should make them JIT operations to complete JIT-caging.
* b3/B3LowerMacros.cpp:
* b3/B3LowerMacrosAfterOptimizations.cpp:
* b3/B3MathExtras.cpp:
* b3/B3ReduceLoopStrength.cpp:
(JSC::B3::JSC_DEFINE_JIT_OPERATION):
(JSC::B3::ReduceLoopStrength::reduceByteCopyLoopsToMemcpy):
(JSC::B3::fastForwardCopy32): Deleted.
* b3/B3ReduceLoopStrength.h:
(JSC::B3::fastForwardCopy32):
* b3/B3ReduceStrength.cpp:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGArithMode.cpp:
(JSC::DFG::arithUnaryFunction):
(JSC::DFG::arithUnaryOperation):
(WTF::printInternal):
* dfg/DFGArithMode.h:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileArithMod):
(JSC::DFG::SpeculativeJIT::compileArithRounding):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileArithPow):
* ftl/FTLOutput.cpp:
(JSC::FTL::Output::doubleTrunc):
(JSC::FTL::Output::doubleUnary):
(JSC::FTL::Output::doubleStdPow):
(JSC::FTL::Output::doublePow): Deleted.
* ftl/FTLOutput.h:
* jit/SpecializedThunkJIT.h:
(JSC::SpecializedThunkJIT::callDoubleToDouble):
* jit/ThunkGenerators.cpp:
* runtime/MathCommon.cpp:
(JSC::Math::log1pDoubleImpl):
(JSC::Math::log1pFloatImpl):
(JSC::Math::log1p):
(JSC::Math::JSC_DEFINE_JIT_OPERATION):
(JSC::Math::roundDoubleImpl):
* runtime/MathCommon.h:
* runtime/MathObject.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* runtime/Operations.h:
(JSC::jsRemainder):
2020-09-29 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, attempt to fix WinCairo build failure part 2
https://bugs.webkit.org/show_bug.cgi?id=217071
* ftl/FTLOperations.h:
2020-09-29 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, attempt to fix WinCairo build failure
https://bugs.webkit.org/show_bug.cgi?id=217071
* ftl/FTLOperations.h:
* tools/JSDollarVM.cpp:
2020-09-28 Yusuke Suzuki <ysuzuki@apple.com>
Use JSC_DECLARE_JIT_OPERATION / JSC_DECLARE_CUSTOM_GETTER / JSC_DECLARE_CUSTOM_SETTER
https://bugs.webkit.org/show_bug.cgi?id=217071
Reviewed by Keith Miller.
This patch changes how to define JIT_OPERATIONs including custom getters and setters.
We introduce JSC_DECLARE_JIT_OPERATION etc. to declare and define them. This is useful
to perform some additional things (like, JIT-caging registering) for each function.
2020-09-28 Mark Lam <mark.lam@apple.com>
Add Bounds Check Elimination validation for debugging.
https://bugs.webkit.org/show_bug.cgi?id=217055
rdar://69122891
Reviewed by Keith Miller.
Added a JSC_validateBoundsCheckElimination option (with alias
JSC_validateBCE) that adds an AssertInBounds whenever a CheckInBounds
node is elided.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGIntegerCheckCombiningPhase.cpp:
(JSC::DFG::IntegerCheckCombiningPhase::handleBlock):
* dfg/DFGIntegerRangeOptimizationPhase.cpp:
* dfg/DFGNodeType.h:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGValidate.cpp:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::validateAIState):
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileAssertNotEmpty):
(JSC::FTL::DFG::LowerDFGToB3::compileAssertInBounds):
* ftl/FTLOperations.cpp:
(JSC::FTL::operationReportBoundsCheckEliminationErrorAndCrash):
* ftl/FTLOperations.h:
* runtime/OptionsList.h:
2020-09-26 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, follow-up after r267373 to resolve post-commit review comments
https://bugs.webkit.org/show_bug.cgi?id=216667
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileNormalizeMapKey):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileMapHash):
(JSC::FTL::DFG::LowerDFGToB3::compileNormalizeMapKey):
* runtime/HashMapImpl.h:
(JSC::jsMapHash):
2020-09-25 Ross Kirsling <ross.kirsling@sony.com>
%TypedArray%.{from, of} no longer perform AllocateTypedArray
https://bugs.webkit.org/show_bug.cgi?id=216991
Reviewed by Yusuke Suzuki.
Back in ES2015, %TypedArray%.of and %TypedArray%.from appear to have been based on the abstract operation
AllocateTypedArray, which involved crawling the prototype chain to find the appropriate constructor and
only permitted `this` to be a (derived) typed array.
This appears to have gone away as of ES2016 -- we simply expect `this` to be a constructor and verify that it
produced a typed array (of sufficient length).
* builtins/BuiltinNames.h:
* builtins/TypedArrayConstructor.js:
(of):
(from):
(allocateInt8Array): Deleted.
(allocateInt16Array): Deleted.
(allocateInt32Array): Deleted.
(allocateUint32Array): Deleted.
(allocateUint16Array): Deleted.
(allocateUint8Array): Deleted.
(allocateUint8ClampedArray): Deleted.
(allocateFloat32Array): Deleted.
(allocateFloat64Array): Deleted.
* runtime/JSGenericTypedArrayViewConstructor.h:
* runtime/JSGenericTypedArrayViewConstructorInlines.h:
(JSC::JSGenericTypedArrayViewConstructor<ViewClass>::finishCreation):
(JSC::JSGenericTypedArrayViewConstructor<ViewClass>::create):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
2020-09-25 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Introduce JSC_DECLARE_HOST_FUNCTION / JSC_DEFINE_HOST_FUNCTION to make host function definition easy-to-scanned for JIT-caging
https://bugs.webkit.org/show_bug.cgi?id=216966
Reviewed by Saam Barati.
This patch introduces JSC_DECLARE_HOST_FUNCTION / JSC_DEFINE_HOST_FUNCTION and changes how to define host functions.
In the new way, we declare a function like,
JSC_DECLARE_HOST_FUNCTION(functionHelloWorld);
And define the function like,
JSC_DEFINE_HOST_FUNCTION(functionHelloWorld, (JSGlobalObject* globalObject, CallFrame* callFrame))
{
// function body.
}
This makes adding some meta information to each function easy, which helps JIT-caging to collect allowed function pointers.
* API/JSAPIWrapperObject.mm:
(JSC::JSCallbackObject<JSAPIWrapperObject>::getCallFunction):
(JSC::JSCallbackObject<JSAPIWrapperObject>::getConstructFunction):
(JSC::JSC_DEFINE_HOST_FUNCTION):
* API/JSCallbackConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::constructJSCallbackConstructor): Deleted.
* API/JSCallbackFunction.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::callJSCallbackFunction): Deleted.
* API/JSCallbackObject.cpp:
(JSC::JSCallbackObject<JSNonFinalObject>::getCallFunction):
(JSC::JSCallbackObject<JSNonFinalObject>::getConstructFunction):
(JSC::JSCallbackObject<JSGlobalObject>::getCallFunction):
(JSC::JSCallbackObject<JSGlobalObject>::getConstructFunction):
(JSC::JSC_DEFINE_HOST_FUNCTION):
* API/JSCallbackObject.h:
* API/JSCallbackObjectFunctions.h:
(JSC::JSCallbackObject<Parent>::getConstructData):
(JSC::JSCallbackObject<Parent>::constructImpl):
(JSC::JSCallbackObject<Parent>::getCallData):
(JSC::JSCallbackObject<Parent>::callImpl):
(JSC::JSCallbackObject<Parent>::construct): Deleted.
(JSC::JSCallbackObject<Parent>::call): Deleted.
* API/ObjCCallbackFunction.mm:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::callObjCCallbackFunction): Deleted.
(JSC::constructObjCCallbackFunction): Deleted.
* API/glib/JSAPIWrapperGlobalObject.cpp:
(JSC::JSCallbackObject<JSAPIWrapperGlobalObject>::getCallFunction):
(JSC::JSCallbackObject<JSAPIWrapperGlobalObject>::getConstructFunction):
* API/glib/JSAPIWrapperObjectGLib.cpp:
(JSC::JSCallbackObject<JSAPIWrapperObject>::getCallFunction):
(JSC::JSCallbackObject<JSAPIWrapperObject>::getConstructFunction):
(JSC::JSC_DEFINE_HOST_FUNCTION):
* API/glib/JSCCallbackFunction.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::callJSCCallbackFunction): Deleted.
(JSC::constructJSCCallbackFunction): Deleted.
* inspector/JSInjectedScriptHostPrototype.cpp:
(Inspector::JSC_DEFINE_HOST_FUNCTION):
(Inspector::jsInjectedScriptHostPrototypeAttributeEvaluate): Deleted.
(Inspector::jsInjectedScriptHostPrototypeAttributeSavedResultAlias): Deleted.
(Inspector::jsInjectedScriptHostPrototypeFunctionInternalConstructorName): Deleted.
(Inspector::jsInjectedScriptHostPrototypeFunctionIsHTMLAllCollection): Deleted.
(Inspector::jsInjectedScriptHostPrototypeFunctionIsPromiseRejectedWithNativeGetterTypeError): Deleted.
(Inspector::jsInjectedScriptHostPrototypeFunctionProxyTargetValue): Deleted.
(Inspector::jsInjectedScriptHostPrototypeFunctionWeakMapSize): Deleted.
(Inspector::jsInjectedScriptHostPrototypeFunctionWeakMapEntries): Deleted.
(Inspector::jsInjectedScriptHostPrototypeFunctionWeakSetSize): Deleted.
(Inspector::jsInjectedScriptHostPrototypeFunctionWeakSetEntries): Deleted.
(Inspector::jsInjectedScriptHostPrototypeFunctionIteratorEntries): Deleted.
(Inspector::jsInjectedScriptHostPrototypeFunctionQueryInstances): Deleted.
(Inspector::jsInjectedScriptHostPrototypeFunctionQueryHolders): Deleted.
(Inspector::jsInjectedScriptHostPrototypeFunctionEvaluateWithScopeExtension): Deleted.
(Inspector::jsInjectedScriptHostPrototypeFunctionSubtype): Deleted.
(Inspector::jsInjectedScriptHostPrototypeFunctionFunctionDetails): Deleted.
(Inspector::jsInjectedScriptHostPrototypeFunctionGetInternalProperties): Deleted.
* inspector/JSJavaScriptCallFramePrototype.cpp:
(Inspector::JSC_DEFINE_HOST_FUNCTION):
(Inspector::jsJavaScriptCallFramePrototypeFunctionEvaluateWithScopeExtension): Deleted.
(Inspector::jsJavaScriptCallFramePrototypeFunctionScopeDescriptions): Deleted.
(Inspector::jsJavaScriptCallFrameAttributeCaller): Deleted.
(Inspector::jsJavaScriptCallFrameAttributeSourceID): Deleted.
(Inspector::jsJavaScriptCallFrameAttributeLine): Deleted.
(Inspector::jsJavaScriptCallFrameAttributeColumn): Deleted.
(Inspector::jsJavaScriptCallFrameAttributeFunctionName): Deleted.
(Inspector::jsJavaScriptCallFrameAttributeScopeChain): Deleted.
(Inspector::jsJavaScriptCallFrameAttributeThisObject): Deleted.
(Inspector::jsJavaScriptCallFrameAttributeType): Deleted.
(Inspector::jsJavaScriptCallFrameIsTailDeleted): Deleted.
* jsc.cpp:
(JSC_DEFINE_HOST_FUNCTION):
(functionPrintStdOut): Deleted.
(functionPrintStdErr): Deleted.
(functionDebug): Deleted.
(functionDescribe): Deleted.
(functionDescribeArray): Deleted.
(functionSleepSeconds): Deleted.
(functionJSCStack): Deleted.
(functionGCAndSweep): Deleted.
(functionFullGC): Deleted.
(functionEdenGC): Deleted.
(functionHeapSize): Deleted.
(functionResetMemoryPeak): Deleted.
(functionAddressOf): Deleted.
(functionVersion): Deleted.
(functionRun): Deleted.
(functionRunString): Deleted.
(functionLoad): Deleted.
(functionLoadString): Deleted.
(functionReadFile): Deleted.
(functionCheckSyntax): Deleted.
(functionSetSamplingFlags): Deleted.
(functionClearSamplingFlags): Deleted.
(functionGetRandomSeed): Deleted.
(functionSetRandomSeed): Deleted.
(functionIsRope): Deleted.
(functionCallerSourceOrigin): Deleted.
(functionReadline): Deleted.
(functionPreciseTime): Deleted.
(functionNeverInlineFunction): Deleted.
(functionNoDFG): Deleted.
(functionNoFTL): Deleted.
(functionNoOSRExitFuzzing): Deleted.
(functionOptimizeNextInvocation): Deleted.
(functionNumberOfDFGCompiles): Deleted.
(functionCallerIsOMGCompiled): Deleted.
(functionDollarCreateRealm): Deleted.
(functionDollarEvalScript): Deleted.
(functionDollarAgentStart): Deleted.
(functionDollarAgentReceiveBroadcast): Deleted.
(functionDollarAgentReport): Deleted.
(functionDollarAgentSleep): Deleted.
(functionDollarAgentBroadcast): Deleted.
(functionDollarAgentGetReport): Deleted.
(functionDollarAgentLeaving): Deleted.
(functionDollarAgentMonotonicNow): Deleted.
(functionWaitForReport): Deleted.
(functionHeapCapacity): Deleted.
(functionFlashHeapAccess): Deleted.
(functionDisableRichSourceInfo): Deleted.
(functionMallocInALoop): Deleted.
(functionTotalCompileTime): Deleted.
(functionJSCOptions): Deleted.
(functionReoptimizationRetryCount): Deleted.
(functionTransferArrayBuffer): Deleted.
(functionFailNextNewCodeBlock): Deleted.
(functionQuit): Deleted.
(functionFalse): Deleted.
(functionUndefined1): Deleted.
(functionUndefined2): Deleted.
(functionIsInt32): Deleted.
(functionIsPureNaN): Deleted.
(functionIdentity): Deleted.
(functionEffectful42): Deleted.
(functionMakeMasquerader): Deleted.
(functionCallMasquerader): Deleted.
(functionHasCustomProperties): Deleted.
(functionDumpTypesForAllVariables): Deleted.
(functionDrainMicrotasks): Deleted.
(functionSetTimeout): Deleted.
(functionReleaseWeakRefs): Deleted.
(functionFinalizationRegistryLiveCount): Deleted.
(functionFinalizationRegistryDeadCount): Deleted.
(functionIs32BitPlatform): Deleted.
(functionCreateGlobalObject): Deleted.
(functionCreateHeapBigInt): Deleted.
(functionCreateBigInt32): Deleted.
(functionUseBigInt32): Deleted.
(functionIsBigInt32): Deleted.
(functionIsHeapBigInt): Deleted.
(functionCheckModuleSyntax): Deleted.
(functionPlatformSupportsSamplingProfiler): Deleted.
(functionGenerateHeapSnapshot): Deleted.
(functionGenerateHeapSnapshotForGCDebugging): Deleted.
(functionResetSuperSamplerState): Deleted.
(functionEnsureArrayStorage): Deleted.
(functionStartSamplingProfiler): Deleted.
(functionSamplingProfilerStackTraces): Deleted.
(functionMaxArguments): Deleted.
(functionAsyncTestStart): Deleted.
(functionAsyncTestPassed): Deleted.
(functionWebAssemblyMemoryMode): Deleted.
(functionSetUnhandledRejectionCallback): Deleted.
(functionAsDoubleNumber): Deleted.
* runtime/AggregateErrorConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::callAggregateErrorConstructor): Deleted.
(JSC::constructAggregateErrorConstructor): Deleted.
* runtime/ArrayConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::constructWithArrayConstructor): Deleted.
(JSC::callArrayConstructor): Deleted.
(JSC::arrayConstructorPrivateFuncIsArraySlow): Deleted.
* runtime/ArrayConstructor.h:
* runtime/ArrayPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::arrayProtoFuncSpeciesCreate): Deleted.
(JSC::arrayProtoFuncToString): Deleted.
(JSC::arrayProtoFuncToLocaleString): Deleted.
(JSC::arrayProtoFuncJoin): Deleted.
(JSC::arrayProtoFuncValues): Deleted.
(JSC::arrayProtoFuncEntries): Deleted.
(JSC::arrayProtoFuncKeys): Deleted.
(JSC::arrayProtoFuncPop): Deleted.
(JSC::arrayProtoFuncPush): Deleted.
(JSC::arrayProtoFuncReverse): Deleted.
(JSC::arrayProtoFuncShift): Deleted.
(JSC::arrayProtoFuncSlice): Deleted.
(JSC::arrayProtoFuncSplice): Deleted.
(JSC::arrayProtoFuncUnShift): Deleted.
(JSC::arrayProtoFuncIndexOf): Deleted.
(JSC::arrayProtoFuncLastIndexOf): Deleted.
(JSC::arrayProtoPrivateFuncConcatMemcpy): Deleted.
(JSC::arrayProtoPrivateFuncAppendMemcpy): Deleted.
* runtime/ArrayPrototype.h:
* runtime/AsyncFunctionConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::callAsyncFunctionConstructor): Deleted.
(JSC::constructAsyncFunctionConstructor): Deleted.
* runtime/AsyncGeneratorFunctionConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::callAsyncGeneratorFunctionConstructor): Deleted.
(JSC::constructAsyncGeneratorFunctionConstructor): Deleted.
* runtime/AtomicsObject.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::atomicsFuncAdd): Deleted.
(JSC::atomicsFuncAnd): Deleted.
(JSC::atomicsFuncCompareExchange): Deleted.
(JSC::atomicsFuncExchange): Deleted.
(JSC::atomicsFuncIsLockFree): Deleted.
(JSC::atomicsFuncLoad): Deleted.
(JSC::atomicsFuncOr): Deleted.
(JSC::atomicsFuncStore): Deleted.
(JSC::atomicsFuncSub): Deleted.
(JSC::atomicsFuncWait): Deleted.
(JSC::atomicsFuncWake): Deleted.
(JSC::atomicsFuncXor): Deleted.
* runtime/BigIntConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::callBigIntConstructor): Deleted.
(JSC::bigIntConstructorFuncAsUintN): Deleted.
(JSC::bigIntConstructorFuncAsIntN): Deleted.
* runtime/BigIntPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::bigIntProtoFuncToString): Deleted.
(JSC::bigIntProtoFuncToLocaleString): Deleted.
(JSC::bigIntProtoFuncValueOf): Deleted.
* runtime/BooleanConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::callBooleanConstructor): Deleted.
(JSC::constructWithBooleanConstructor): Deleted.
* runtime/BooleanPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::booleanProtoFuncToString): Deleted.
(JSC::booleanProtoFuncValueOf): Deleted.
* runtime/ConsoleObject.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::consoleProtoFuncDebug): Deleted.
(JSC::consoleProtoFuncError): Deleted.
(JSC::consoleProtoFuncLog): Deleted.
(JSC::consoleProtoFuncInfo): Deleted.
(JSC::consoleProtoFuncWarn): Deleted.
(JSC::consoleProtoFuncClear): Deleted.
(JSC::consoleProtoFuncDir): Deleted.
(JSC::consoleProtoFuncDirXML): Deleted.
(JSC::consoleProtoFuncTable): Deleted.
(JSC::consoleProtoFuncTrace): Deleted.
(JSC::consoleProtoFuncAssert): Deleted.
(JSC::consoleProtoFuncCount): Deleted.
(JSC::consoleProtoFuncCountReset): Deleted.
(JSC::consoleProtoFuncProfile): Deleted.
(JSC::consoleProtoFuncProfileEnd): Deleted.
(JSC::consoleProtoFuncTakeHeapSnapshot): Deleted.
(JSC::consoleProtoFuncTime): Deleted.
(JSC::consoleProtoFuncTimeLog): Deleted.
(JSC::consoleProtoFuncTimeEnd): Deleted.
(JSC::consoleProtoFuncTimeStamp): Deleted.
(JSC::consoleProtoFuncGroup): Deleted.
(JSC::consoleProtoFuncGroupCollapsed): Deleted.
(JSC::consoleProtoFuncGroupEnd): Deleted.
(JSC::consoleProtoFuncRecord): Deleted.
(JSC::consoleProtoFuncRecordEnd): Deleted.
(JSC::consoleProtoFuncScreenshot): Deleted.
* runtime/DateConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::constructWithDateConstructor): Deleted.
(JSC::callDate): Deleted.
(JSC::dateParse): Deleted.
(JSC::dateNow): Deleted.
(JSC::dateUTC): Deleted.
* runtime/DatePrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::dateProtoFuncToString): Deleted.
(JSC::dateProtoFuncToUTCString): Deleted.
(JSC::dateProtoFuncToISOString): Deleted.
(JSC::dateProtoFuncToDateString): Deleted.
(JSC::dateProtoFuncToTimeString): Deleted.
(JSC::dateProtoFuncToPrimitiveSymbol): Deleted.
(JSC::dateProtoFuncGetTime): Deleted.
(JSC::dateProtoFuncGetFullYear): Deleted.
(JSC::dateProtoFuncGetUTCFullYear): Deleted.
(JSC::dateProtoFuncGetMonth): Deleted.
(JSC::dateProtoFuncGetUTCMonth): Deleted.
(JSC::dateProtoFuncGetDate): Deleted.
(JSC::dateProtoFuncGetUTCDate): Deleted.
(JSC::dateProtoFuncGetDay): Deleted.
(JSC::dateProtoFuncGetUTCDay): Deleted.
(JSC::dateProtoFuncGetHours): Deleted.
(JSC::dateProtoFuncGetUTCHours): Deleted.
(JSC::dateProtoFuncGetMinutes): Deleted.
(JSC::dateProtoFuncGetUTCMinutes): Deleted.
(JSC::dateProtoFuncGetSeconds): Deleted.
(JSC::dateProtoFuncGetUTCSeconds): Deleted.
(JSC::dateProtoFuncGetMilliSeconds): Deleted.
(JSC::dateProtoFuncGetUTCMilliseconds): Deleted.
(JSC::dateProtoFuncGetTimezoneOffset): Deleted.
(JSC::dateProtoFuncSetTime): Deleted.
(JSC::dateProtoFuncSetMilliSeconds): Deleted.
(JSC::dateProtoFuncSetUTCMilliseconds): Deleted.
(JSC::dateProtoFuncSetSeconds): Deleted.
(JSC::dateProtoFuncSetUTCSeconds): Deleted.
(JSC::dateProtoFuncSetMinutes): Deleted.
(JSC::dateProtoFuncSetUTCMinutes): Deleted.
(JSC::dateProtoFuncSetHours): Deleted.
(JSC::dateProtoFuncSetUTCHours): Deleted.
(JSC::dateProtoFuncSetDate): Deleted.
(JSC::dateProtoFuncSetUTCDate): Deleted.
(JSC::dateProtoFuncSetMonth): Deleted.
(JSC::dateProtoFuncSetUTCMonth): Deleted.
(JSC::dateProtoFuncSetFullYear): Deleted.
(JSC::dateProtoFuncSetUTCFullYear): Deleted.
(JSC::dateProtoFuncSetYear): Deleted.
(JSC::dateProtoFuncGetYear): Deleted.
(JSC::dateProtoFuncToJSON): Deleted.
* runtime/DatePrototype.h:
* runtime/ErrorConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::constructErrorConstructor): Deleted.
(JSC::callErrorConstructor): Deleted.
* runtime/ErrorPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::errorProtoFuncToString): Deleted.
* runtime/FinalizationRegistryConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::callFinalizationRegistry): Deleted.
(JSC::constructFinalizationRegistry): Deleted.
* runtime/FinalizationRegistryPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::protoFuncFinalizationRegistryRegister): Deleted.
(JSC::protoFuncFinalizationRegistryUnregister): Deleted.
* runtime/FunctionConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::constructWithFunctionConstructor): Deleted.
(JSC::callFunctionConstructor): Deleted.
* runtime/FunctionPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::callFunctionPrototype): Deleted.
(JSC::functionProtoFuncToString): Deleted.
* runtime/GeneratorFunctionConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::callGeneratorFunctionConstructor): Deleted.
(JSC::constructGeneratorFunctionConstructor): Deleted.
* runtime/InspectorInstrumentationObject.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::inspectorInstrumentationObjectLog): Deleted.
* runtime/IntlCollatorConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::constructIntlCollator): Deleted.
(JSC::callIntlCollator): Deleted.
(JSC::IntlCollatorConstructorFuncSupportedLocalesOf): Deleted.
* runtime/IntlCollatorPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::IntlCollatorFuncCompare): Deleted.
(JSC::IntlCollatorPrototypeGetterCompare): Deleted.
(JSC::IntlCollatorPrototypeFuncResolvedOptions): Deleted.
* runtime/IntlDateTimeFormatConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::constructIntlDateTimeFormat): Deleted.
(JSC::callIntlDateTimeFormat): Deleted.
(JSC::IntlDateTimeFormatConstructorFuncSupportedLocalesOf): Deleted.
* runtime/IntlDateTimeFormatPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::IntlDateTimeFormatFuncFormatDateTime): Deleted.
(JSC::IntlDateTimeFormatPrototypeGetterFormat): Deleted.
(JSC::IntlDateTimeFormatPrototypeFuncFormatToParts): Deleted.
(JSC::IntlDateTimeFormatPrototypeFuncFormatRange): Deleted.
(JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions): Deleted.
* runtime/IntlDisplayNamesConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::constructIntlDisplayNames): Deleted.
(JSC::callIntlDisplayNames): Deleted.
(JSC::IntlDisplayNamesConstructorSupportedLocalesOf): Deleted.
* runtime/IntlDisplayNamesPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::IntlDisplayNamesPrototypeFuncOf): Deleted.
(JSC::IntlDisplayNamesPrototypeFuncResolvedOptions): Deleted.
* runtime/IntlLocaleConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::constructIntlLocale): Deleted.
(JSC::callIntlLocale): Deleted.
* runtime/IntlLocalePrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::IntlLocalePrototypeFuncMaximize): Deleted.
(JSC::IntlLocalePrototypeFuncMinimize): Deleted.
(JSC::IntlLocalePrototypeFuncToString): Deleted.
(JSC::IntlLocalePrototypeGetterBaseName): Deleted.
(JSC::IntlLocalePrototypeGetterCalendar): Deleted.
(JSC::IntlLocalePrototypeGetterCaseFirst): Deleted.
(JSC::IntlLocalePrototypeGetterCollation): Deleted.
(JSC::IntlLocalePrototypeGetterHourCycle): Deleted.
(JSC::IntlLocalePrototypeGetterNumeric): Deleted.
(JSC::IntlLocalePrototypeGetterNumberingSystem): Deleted.
(JSC::IntlLocalePrototypeGetterLanguage): Deleted.
(JSC::IntlLocalePrototypeGetterScript): Deleted.
(JSC::IntlLocalePrototypeGetterRegion): Deleted.
* runtime/IntlNumberFormatConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::constructIntlNumberFormat): Deleted.
(JSC::callIntlNumberFormat): Deleted.
(JSC::IntlNumberFormatConstructorFuncSupportedLocalesOf): Deleted.
* runtime/IntlNumberFormatPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::IntlNumberFormatFuncFormat): Deleted.
(JSC::IntlNumberFormatPrototypeGetterFormat): Deleted.
(JSC::IntlNumberFormatPrototypeFuncFormatToParts): Deleted.
(JSC::IntlNumberFormatPrototypeFuncResolvedOptions): Deleted.
* runtime/IntlObject.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::intlObjectFuncGetCanonicalLocales): Deleted.
* runtime/IntlPluralRulesConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::constructIntlPluralRules): Deleted.
(JSC::callIntlPluralRules): Deleted.
(JSC::IntlPluralRulesConstructorFuncSupportedLocalesOf): Deleted.
* runtime/IntlPluralRulesPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::IntlPluralRulesPrototypeFuncSelect): Deleted.
(JSC::IntlPluralRulesPrototypeFuncResolvedOptions): Deleted.
* runtime/IntlRelativeTimeFormatConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::constructIntlRelativeTimeFormat): Deleted.
(JSC::callIntlRelativeTimeFormat): Deleted.
(JSC::IntlRelativeTimeFormatConstructorFuncSupportedLocalesOf): Deleted.
* runtime/IntlRelativeTimeFormatPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::IntlRelativeTimeFormatPrototypeFuncFormat): Deleted.
(JSC::IntlRelativeTimeFormatPrototypeFuncFormatToParts): Deleted.
(JSC::IntlRelativeTimeFormatPrototypeFuncResolvedOptions): Deleted.
* runtime/IntlSegmentIteratorPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::IntlSegmentIteratorPrototypeFuncNext): Deleted.
* runtime/IntlSegmenterConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::constructIntlSegmenter): Deleted.
(JSC::callIntlSegmenter): Deleted.
(JSC::IntlSegmenterConstructorSupportedLocalesOf): Deleted.
* runtime/IntlSegmenterPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::IntlSegmenterPrototypeFuncSegment): Deleted.
(JSC::IntlSegmenterPrototypeFuncResolvedOptions): Deleted.
* runtime/IntlSegmentsPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::IntlSegmentsPrototypeFuncContaining): Deleted.
(JSC::IntlSegmentsPrototypeFuncIterator): Deleted.
* runtime/JSArrayBufferConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::callArrayBuffer): Deleted.
(JSC::constructArrayBuffer): Deleted.
(JSC::constructSharedArrayBuffer): Deleted.
(JSC::arrayBufferFuncIsView): Deleted.
* runtime/JSArrayBufferPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::arrayBufferProtoFuncSlice): Deleted.
(JSC::arrayBufferProtoGetterFuncByteLength): Deleted.
(JSC::sharedArrayBufferProtoGetterFuncByteLength): Deleted.
* runtime/JSBoundFunction.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::boundThisNoArgsFunctionCall): Deleted.
(JSC::boundFunctionCall): Deleted.
(JSC::boundThisNoArgsFunctionConstruct): Deleted.
(JSC::boundFunctionConstruct): Deleted.
(JSC::isBoundFunction): Deleted.
(JSC::hasInstanceBoundFunction): Deleted.
* runtime/JSBoundFunction.h:
* runtime/JSCustomGetterSetterFunction.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::customGetterSetterFunctionCall): Deleted.
* runtime/JSDataViewPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::dataViewProtoGetterBuffer): Deleted.
(JSC::dataViewProtoGetterByteLength): Deleted.
(JSC::dataViewProtoGetterByteOffset): Deleted.
(JSC::dataViewProtoFuncGetInt8): Deleted.
(JSC::dataViewProtoFuncGetInt16): Deleted.
(JSC::dataViewProtoFuncGetInt32): Deleted.
(JSC::dataViewProtoFuncGetUint8): Deleted.
(JSC::dataViewProtoFuncGetUint16): Deleted.
(JSC::dataViewProtoFuncGetUint32): Deleted.
(JSC::dataViewProtoFuncGetFloat32): Deleted.
(JSC::dataViewProtoFuncGetFloat64): Deleted.
(JSC::dataViewProtoFuncSetInt8): Deleted.
(JSC::dataViewProtoFuncSetInt16): Deleted.
(JSC::dataViewProtoFuncSetInt32): Deleted.
(JSC::dataViewProtoFuncSetUint8): Deleted.
(JSC::dataViewProtoFuncSetUint16): Deleted.
(JSC::dataViewProtoFuncSetUint32): Deleted.
(JSC::dataViewProtoFuncSetFloat32): Deleted.
(JSC::dataViewProtoFuncSetFloat64): Deleted.
* runtime/JSFunction.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::argumentsGetter):
(JSC::callerGetter):
(JSC::callHostFunctionAsConstructor): Deleted.
(JSC::JSFunction::argumentsGetter): Deleted.
(JSC::JSFunction::callerGetter): Deleted.
* runtime/JSFunction.h:
* runtime/JSGenericTypedArrayViewConstructor.h:
* runtime/JSGenericTypedArrayViewConstructorInlines.h:
(JSC::JSGenericTypedArrayViewConstructor<ViewClass>::JSGenericTypedArrayViewConstructor):
(JSC::constructGenericTypedArrayViewImpl):
(JSC::callGenericTypedArrayViewImpl):
(JSC::constructGenericTypedArrayView): Deleted.
(JSC::callGenericTypedArrayView): Deleted.
* runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::genericTypedArrayViewProtoFuncSet): Deleted.
(JSC::genericTypedArrayViewProtoFuncCopyWithin): Deleted.
(JSC::genericTypedArrayViewProtoFuncIncludes): Deleted.
(JSC::genericTypedArrayViewProtoFuncIndexOf): Deleted.
(JSC::genericTypedArrayViewProtoFuncJoin): Deleted.
(JSC::genericTypedArrayViewProtoFuncLastIndexOf): Deleted.
(JSC::genericTypedArrayViewProtoGetterFuncBuffer): Deleted.
(JSC::genericTypedArrayViewProtoGetterFuncLength): Deleted.
(JSC::genericTypedArrayViewProtoGetterFuncByteLength): Deleted.
(JSC::genericTypedArrayViewProtoGetterFuncByteOffset): Deleted.
(JSC::genericTypedArrayViewProtoFuncReverse): Deleted.
(JSC::genericTypedArrayViewPrivateFuncSort): Deleted.
(JSC::genericTypedArrayViewProtoFuncSlice): Deleted.
(JSC::genericTypedArrayViewPrivateFuncSubarrayCreate): Deleted.
* runtime/JSGlobalObject.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::makeBoundFunction): Deleted.
(JSC::hasOwnLengthProperty): Deleted.
(JSC::createPrivateSymbol): Deleted.
(JSC::assertCall): Deleted.
(JSC::enableSamplingProfiler): Deleted.
(JSC::disableSamplingProfiler): Deleted.
(JSC::enableSuperSampler): Deleted.
(JSC::disableSuperSampler): Deleted.
(JSC::enqueueJob): Deleted.
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::globalFuncEval): Deleted.
(JSC::globalFuncParseInt): Deleted.
(JSC::globalFuncParseFloat): Deleted.
(JSC::globalFuncDecodeURI): Deleted.
(JSC::globalFuncDecodeURIComponent): Deleted.
(JSC::globalFuncEncodeURI): Deleted.
(JSC::globalFuncEncodeURIComponent): Deleted.
(JSC::globalFuncEscape): Deleted.
(JSC::globalFuncUnescape): Deleted.
(JSC::globalFuncThrowTypeError): Deleted.
(JSC::globalFuncThrowTypeErrorArgumentsCalleeAndCaller): Deleted.
(JSC::globalFuncMakeTypeError): Deleted.
(JSC::globalFuncProtoGetter): Deleted.
(JSC::globalFuncProtoSetter): Deleted.
(JSC::globalFuncSetPrototypeDirect): Deleted.
(JSC::globalFuncHostPromiseRejectionTracker): Deleted.
(JSC::globalFuncBuiltinLog): Deleted.
(JSC::globalFuncBuiltinDescribe): Deleted.
(JSC::globalFuncImportModule): Deleted.
(JSC::globalFuncPropertyIsEnumerable): Deleted.
(JSC::globalFuncOwnKeys): Deleted.
(JSC::globalFuncDateTimeFormat): Deleted.
* runtime/JSGlobalObjectFunctions.h:
* runtime/JSModuleLoader.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::moduleLoaderParseModule): Deleted.
(JSC::moduleLoaderRequestedModules): Deleted.
(JSC::moduleLoaderModuleDeclarationInstantiation): Deleted.
(JSC::moduleLoaderResolve): Deleted.
(JSC::moduleLoaderResolveSync): Deleted.
(JSC::moduleLoaderFetch): Deleted.
(JSC::moduleLoaderGetModuleNamespaceObject): Deleted.
(JSC::moduleLoaderEvaluate): Deleted.
* runtime/JSNativeStdFunction.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::runStdFunction): Deleted.
* runtime/JSONObject.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::JSONProtoFuncParse): Deleted.
(JSC::JSONProtoFuncStringify): Deleted.
* runtime/JSObject.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::objectPrivateFuncInstanceOf): Deleted.
* runtime/JSObject.h:
* runtime/JSTypedArrayViewConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::constructTypedArrayView): Deleted.
* runtime/JSTypedArrayViewPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::typedArrayViewPrivateFuncIsTypedArrayView): Deleted.
(JSC::typedArrayViewPrivateFuncIsNeutered): Deleted.
(JSC::typedArrayViewPrivateFuncLength): Deleted.
(JSC::typedArrayViewPrivateFuncGetOriginalConstructor): Deleted.
(JSC::typedArrayViewProtoFuncValues): Deleted.
(JSC::typedArrayProtoViewFuncEntries): Deleted.
(JSC::typedArrayViewProtoFuncKeys): Deleted.
(JSC::typedArrayViewPrivateFuncSort): Deleted.
(JSC::typedArrayViewProtoFuncSet): Deleted.
(JSC::typedArrayViewProtoFuncCopyWithin): Deleted.
(JSC::typedArrayViewProtoFuncIncludes): Deleted.
(JSC::typedArrayViewProtoFuncLastIndexOf): Deleted.
(JSC::typedArrayViewProtoFuncIndexOf): Deleted.
(JSC::typedArrayViewProtoFuncJoin): Deleted.
(JSC::typedArrayViewProtoGetterFuncBuffer): Deleted.
(JSC::typedArrayViewProtoGetterFuncLength): Deleted.
(JSC::typedArrayViewProtoGetterFuncByteLength): Deleted.
(JSC::typedArrayViewProtoGetterFuncByteOffset): Deleted.
(JSC::typedArrayViewProtoFuncReverse): Deleted.
(JSC::typedArrayViewPrivateFuncSubarrayCreate): Deleted.
(JSC::typedArrayViewProtoFuncSlice): Deleted.
(JSC::typedArrayViewProtoGetterFuncToStringTag): Deleted.
* runtime/JSTypedArrayViewPrototype.h:
* runtime/JSTypedArrays.cpp:
(JSC::createUint8TypedArray): Deleted.
* runtime/MapConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::callMap): Deleted.
(JSC::constructMap): Deleted.
(JSC::mapPrivateFuncMapBucketHead): Deleted.
(JSC::mapPrivateFuncMapBucketNext): Deleted.
(JSC::mapPrivateFuncMapBucketKey): Deleted.
(JSC::mapPrivateFuncMapBucketValue): Deleted.
* runtime/MapConstructor.h:
* runtime/MapPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::mapProtoFuncClear): Deleted.
(JSC::mapProtoFuncDelete): Deleted.
(JSC::mapProtoFuncGet): Deleted.
(JSC::mapProtoFuncHas): Deleted.
(JSC::mapProtoFuncSet): Deleted.
(JSC::mapProtoFuncValues): Deleted.
(JSC::mapProtoFuncKeys): Deleted.
(JSC::mapProtoFuncEntries): Deleted.
(JSC::mapProtoFuncSize): Deleted.
* runtime/MathObject.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::mathProtoFuncAbs): Deleted.
(JSC::mathProtoFuncACos): Deleted.
(JSC::mathProtoFuncASin): Deleted.
(JSC::mathProtoFuncATan): Deleted.
(JSC::mathProtoFuncATan2): Deleted.
(JSC::mathProtoFuncCeil): Deleted.
(JSC::mathProtoFuncClz32): Deleted.
(JSC::mathProtoFuncCos): Deleted.
(JSC::mathProtoFuncExp): Deleted.
(JSC::mathProtoFuncFloor): Deleted.
(JSC::mathProtoFuncHypot): Deleted.
(JSC::mathProtoFuncLog): Deleted.
(JSC::mathProtoFuncMax): Deleted.
(JSC::mathProtoFuncMin): Deleted.
(JSC::mathProtoFuncPow): Deleted.
(JSC::mathProtoFuncRandom): Deleted.
(JSC::mathProtoFuncRound): Deleted.
(JSC::mathProtoFuncSign): Deleted.
(JSC::mathProtoFuncSin): Deleted.
(JSC::mathProtoFuncSqrt): Deleted.
(JSC::mathProtoFuncTan): Deleted.
(JSC::mathProtoFuncIMul): Deleted.
(JSC::mathProtoFuncACosh): Deleted.
(JSC::mathProtoFuncASinh): Deleted.
(JSC::mathProtoFuncATanh): Deleted.
(JSC::mathProtoFuncCbrt): Deleted.
(JSC::mathProtoFuncCosh): Deleted.
(JSC::mathProtoFuncExpm1): Deleted.
(JSC::mathProtoFuncFround): Deleted.
(JSC::mathProtoFuncLog1p): Deleted.
(JSC::mathProtoFuncLog10): Deleted.
(JSC::mathProtoFuncLog2): Deleted.
(JSC::mathProtoFuncSinh): Deleted.
(JSC::mathProtoFuncTanh): Deleted.
(JSC::mathProtoFuncTrunc): Deleted.
* runtime/MathObject.h:
* runtime/NativeErrorConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::callEvalError): Deleted.
(JSC::constructEvalError): Deleted.
(JSC::callRangeError): Deleted.
(JSC::constructRangeError): Deleted.
(JSC::callReferenceError): Deleted.
(JSC::constructReferenceError): Deleted.
(JSC::callSyntaxError): Deleted.
(JSC::constructSyntaxError): Deleted.
(JSC::callTypeError): Deleted.
(JSC::constructTypeError): Deleted.
(JSC::callURIError): Deleted.
(JSC::constructURIError): Deleted.
* runtime/NativeFunction.h:
* runtime/NullGetterFunction.cpp:
(JSC::NullGetterFunctionInternal::JSC_DEFINE_HOST_FUNCTION):
(JSC::NullGetterFunctionInternal::callReturnUndefined): Deleted.
* runtime/NullSetterFunction.cpp:
(JSC::NullSetterFunctionInternal::JSC_DEFINE_HOST_FUNCTION):
(JSC::NullSetterFunctionInternal::callReturnUndefined): Deleted.
(JSC::NullSetterFunctionInternal::callThrowError): Deleted.
* runtime/NumberConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::constructNumberConstructor): Deleted.
(JSC::callNumberConstructor): Deleted.
(JSC::numberConstructorFuncIsInteger): Deleted.
(JSC::numberConstructorFuncIsSafeInteger): Deleted.
* runtime/NumberPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::numberProtoFuncToExponential): Deleted.
(JSC::numberProtoFuncToFixed): Deleted.
(JSC::numberProtoFuncToPrecision): Deleted.
(JSC::numberProtoFuncToString): Deleted.
(JSC::numberProtoFuncToLocaleString): Deleted.
(JSC::numberProtoFuncValueOf): Deleted.
* runtime/NumberPrototype.h:
* runtime/ObjectConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::constructWithObjectConstructor): Deleted.
(JSC::callObjectConstructor): Deleted.
(JSC::objectConstructorGetPrototypeOf): Deleted.
(JSC::objectConstructorSetPrototypeOf): Deleted.
(JSC::objectConstructorGetOwnPropertyNames): Deleted.
(JSC::objectConstructorGetOwnPropertySymbols): Deleted.
(JSC::objectConstructorKeys): Deleted.
(JSC::objectConstructorAssign): Deleted.
(JSC::objectConstructorValues): Deleted.
(JSC::objectConstructorDefineProperty): Deleted.
(JSC::objectConstructorDefineProperties): Deleted.
(JSC::objectConstructorCreate): Deleted.
(JSC::objectConstructorPreventExtensions): Deleted.
(JSC::objectConstructorIsSealed): Deleted.
(JSC::objectConstructorIsFrozen): Deleted.
(JSC::objectConstructorIsExtensible): Deleted.
(JSC::objectConstructorIs): Deleted.
* runtime/ObjectConstructor.h:
* runtime/ObjectPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::objectProtoFuncValueOf): Deleted.
(JSC::objectProtoFuncHasOwnProperty): Deleted.
(JSC::objectProtoFuncIsPrototypeOf): Deleted.
(JSC::objectProtoFuncDefineGetter): Deleted.
(JSC::objectProtoFuncDefineSetter): Deleted.
(JSC::objectProtoFuncLookupGetter): Deleted.
(JSC::objectProtoFuncLookupSetter): Deleted.
(JSC::objectProtoFuncPropertyIsEnumerable): Deleted.
(JSC::objectProtoFuncToLocaleString): Deleted.
(JSC::objectProtoFuncToString): Deleted.
* runtime/ObjectPrototype.h:
* runtime/ProxyConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::makeRevocableProxy): Deleted.
(JSC::constructProxyObject): Deleted.
(JSC::callProxy): Deleted.
* runtime/ProxyObject.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::performProxyCall): Deleted.
(JSC::performProxyConstruct): Deleted.
* runtime/ProxyRevoke.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::performProxyRevoke): Deleted.
* runtime/ReflectObject.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::reflectObjectConstruct): Deleted.
(JSC::reflectObjectDefineProperty): Deleted.
(JSC::reflectObjectGet): Deleted.
(JSC::reflectObjectGetOwnPropertyDescriptor): Deleted.
(JSC::reflectObjectGetPrototypeOf): Deleted.
(JSC::reflectObjectIsExtensible): Deleted.
(JSC::reflectObjectOwnKeys): Deleted.
(JSC::reflectObjectPreventExtensions): Deleted.
(JSC::reflectObjectSet): Deleted.
(JSC::reflectObjectSetPrototypeOf): Deleted.
* runtime/RegExpConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::esSpecRegExpCreate): Deleted.
(JSC::esSpecIsRegExp): Deleted.
(JSC::constructWithRegExpConstructor): Deleted.
(JSC::callRegExpConstructor): Deleted.
* runtime/RegExpConstructor.h:
* runtime/RegExpPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::regExpProtoFuncTestFast): Deleted.
(JSC::regExpProtoFuncExec): Deleted.
(JSC::regExpProtoFuncMatchFast): Deleted.
(JSC::regExpProtoFuncCompile): Deleted.
(JSC::regExpProtoFuncToString): Deleted.
(JSC::regExpProtoGetterGlobal): Deleted.
(JSC::regExpProtoGetterIgnoreCase): Deleted.
(JSC::regExpProtoGetterMultiline): Deleted.
(JSC::regExpProtoGetterDotAll): Deleted.
(JSC::regExpProtoGetterSticky): Deleted.
(JSC::regExpProtoGetterUnicode): Deleted.
(JSC::regExpProtoGetterFlags): Deleted.
(JSC::regExpProtoGetterSource): Deleted.
(JSC::regExpProtoFuncSearchFast): Deleted.
(JSC::regExpProtoFuncSplitFast): Deleted.
* runtime/RegExpPrototype.h:
* runtime/SetConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::callSet): Deleted.
(JSC::constructSet): Deleted.
(JSC::setPrivateFuncSetBucketHead): Deleted.
(JSC::setPrivateFuncSetBucketNext): Deleted.
(JSC::setPrivateFuncSetBucketKey): Deleted.
* runtime/SetConstructor.h:
* runtime/SetPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::setProtoFuncAdd): Deleted.
(JSC::setProtoFuncClear): Deleted.
(JSC::setProtoFuncDelete): Deleted.
(JSC::setProtoFuncHas): Deleted.
(JSC::setProtoFuncSize): Deleted.
(JSC::setProtoFuncValues): Deleted.
(JSC::setProtoFuncEntries): Deleted.
* runtime/StringConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::stringFromCharCode):
(JSC::stringFromCodePoint): Deleted.
(JSC::constructWithStringConstructor): Deleted.
(JSC::callStringConstructor): Deleted.
* runtime/StringConstructor.h:
* runtime/StringPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::stringProtoFuncRepeatCharacter): Deleted.
(JSC::stringProtoFuncReplaceUsingRegExp): Deleted.
(JSC::stringProtoFuncReplaceUsingStringSearch): Deleted.
(JSC::stringProtoFuncReplaceAllUsingStringSearch): Deleted.
(JSC::stringProtoFuncToString): Deleted.
(JSC::stringProtoFuncCharAt): Deleted.
(JSC::stringProtoFuncCharCodeAt): Deleted.
(JSC::stringProtoFuncCodePointAt): Deleted.
(JSC::stringProtoFuncIndexOf): Deleted.
(JSC::builtinStringIndexOfInternal): Deleted.
(JSC::stringProtoFuncLastIndexOf): Deleted.
(JSC::stringProtoFuncSlice): Deleted.
(JSC::stringProtoFuncSplitFast): Deleted.
(JSC::stringProtoFuncSubstr): Deleted.
(JSC::stringProtoFuncSubstring): Deleted.
(JSC::builtinStringSubstringInternal): Deleted.
(JSC::stringProtoFuncToLowerCase): Deleted.
(JSC::stringProtoFuncToUpperCase): Deleted.
(JSC::stringProtoFuncLocaleCompare): Deleted.
(JSC::stringProtoFuncToLocaleLowerCase): Deleted.
(JSC::stringProtoFuncToLocaleUpperCase): Deleted.
(JSC::stringProtoFuncTrim): Deleted.
(JSC::stringProtoFuncTrimStart): Deleted.
(JSC::stringProtoFuncTrimEnd): Deleted.
(JSC::stringProtoFuncStartsWith): Deleted.
(JSC::stringProtoFuncEndsWith): Deleted.
(JSC::stringProtoFuncIncludes): Deleted.
(JSC::builtinStringIncludesInternal): Deleted.
(JSC::stringProtoFuncIterator): Deleted.
(JSC::stringProtoFuncNormalize): Deleted.
* runtime/StringPrototype.h:
* runtime/Structure.h:
* runtime/SymbolConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::callSymbol): Deleted.
(JSC::constructSymbol): Deleted.
(JSC::symbolConstructorFor): Deleted.
(JSC::symbolConstructorKeyFor): Deleted.
* runtime/SymbolPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::symbolProtoGetterDescription): Deleted.
(JSC::symbolProtoFuncToString): Deleted.
(JSC::symbolProtoFuncValueOf): Deleted.
* runtime/WeakMapConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::callWeakMap): Deleted.
(JSC::constructWeakMap): Deleted.
* runtime/WeakMapPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::protoFuncWeakMapDelete): Deleted.
(JSC::protoFuncWeakMapGet): Deleted.
(JSC::protoFuncWeakMapHas): Deleted.
(JSC::protoFuncWeakMapSet): Deleted.
* runtime/WeakObjectRefConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::callWeakRef): Deleted.
(JSC::constructWeakRef): Deleted.
* runtime/WeakObjectRefPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::protoFuncWeakRefDeref): Deleted.
* runtime/WeakSetConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::callWeakSet): Deleted.
(JSC::constructWeakSet): Deleted.
* runtime/WeakSetPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::protoFuncWeakSetDelete): Deleted.
(JSC::protoFuncWeakSetHas): Deleted.
(JSC::protoFuncWeakSetAdd): Deleted.
* tools/JSDollarVM.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::JSDollarVM::finishCreation):
(JSC::functionCrash): Deleted.
(JSC::functionBreakpoint): Deleted.
(JSC::functionDFGTrue): Deleted.
(JSC::functionFTLTrue): Deleted.
(JSC::functionCpuMfence): Deleted.
(JSC::functionCpuRdtsc): Deleted.
(JSC::functionCpuCpuid): Deleted.
(JSC::functionCpuPause): Deleted.
(JSC::functionCpuClflush): Deleted.
(JSC::functionLLintTrue): Deleted.
(JSC::functionBaselineJITTrue): Deleted.
(JSC::functionNoInline): Deleted.
(JSC::functionGC): Deleted.
(JSC::functionEdenGC): Deleted.
(JSC::functionGCSweepAsynchronously): Deleted.
(JSC::functionDumpSubspaceHashes): Deleted.
(JSC::functionCallFrame): Deleted.
(JSC::functionCodeBlockForFrame): Deleted.
(JSC::functionCodeBlockFor): Deleted.
(JSC::functionDumpSourceFor): Deleted.
(JSC::functionDumpBytecodeFor): Deleted.
(JSC::functionDataLog): Deleted.
(JSC::functionPrint): Deleted.
(JSC::functionDumpCallFrame): Deleted.
(JSC::functionDumpStack): Deleted.
(JSC::functionDumpRegisters): Deleted.
(JSC::functionDumpCell): Deleted.
(JSC::functionIndexingMode): Deleted.
(JSC::functionInlineCapacity): Deleted.
(JSC::functionValue): Deleted.
(JSC::functionGetPID): Deleted.
(JSC::functionHaveABadTime): Deleted.
(JSC::functionIsHavingABadTime): Deleted.
(JSC::functionCallWithStackSize): Deleted.
(JSC::functionCreateGlobalObject): Deleted.
(JSC::functionCreateProxy): Deleted.
(JSC::functionCreateRuntimeArray): Deleted.
(JSC::functionCreateNullRopeString): Deleted.
(JSC::functionCreateImpureGetter): Deleted.
(JSC::functionCreateCustomGetterObject): Deleted.
(JSC::functionCreateDOMJITNodeObject): Deleted.
(JSC::functionCreateDOMJITGetterObject): Deleted.
(JSC::functionCreateDOMJITGetterNoEffectsObject): Deleted.
(JSC::functionCreateDOMJITGetterComplexObject): Deleted.
(JSC::functionCreateDOMJITFunctionObject): Deleted.
(JSC::functionCreateDOMJITCheckJSCastObject): Deleted.
(JSC::functionCreateDOMJITGetterBaseJSObject): Deleted.
(JSC::functionCreateWasmStreamingParser): Deleted.
(JSC::functionCreateStaticCustomAccessor): Deleted.
(JSC::functionCreateStaticCustomValue): Deleted.
(JSC::functionCreateObjectDoingSideEffectPutWithoutCorrectSlotStatus): Deleted.
(JSC::functionCreateEmptyFunctionWithName): Deleted.
(JSC::functionSetImpureGetterDelegate): Deleted.
(JSC::functionCreateBuiltin): Deleted.
(JSC::functionGetPrivateProperty): Deleted.
(JSC::functionCreateRoot): Deleted.
(JSC::functionCreateElement): Deleted.
(JSC::functionGetElement): Deleted.
(JSC::functionCreateSimpleObject): Deleted.
(JSC::functionGetHiddenValue): Deleted.
(JSC::functionSetHiddenValue): Deleted.
(JSC::functionShadowChickenFunctionsOnStack): Deleted.
(JSC::functionSetGlobalConstRedeclarationShouldNotThrow): Deleted.
(JSC::functionFindTypeForExpression): Deleted.
(JSC::functionReturnTypeFor): Deleted.
(JSC::functionFlattenDictionaryObject): Deleted.
(JSC::functionDumpBasicBlockExecutionRanges): Deleted.
(JSC::functionHasBasicBlockExecuted): Deleted.
(JSC::functionBasicBlockExecutionCount): Deleted.
(JSC::functionEnableDebuggerModeWhenIdle): Deleted.
(JSC::functionDisableDebuggerModeWhenIdle): Deleted.
(JSC::functionDeleteAllCodeWhenIdle): Deleted.
(JSC::functionGlobalObjectCount): Deleted.
(JSC::functionGlobalObjectForObject): Deleted.
(JSC::functionGetGetterSetter): Deleted.
(JSC::functionLoadGetterFromGetterSetter): Deleted.
(JSC::functionCreateCustomTestGetterSetter): Deleted.
(JSC::functionDeltaBetweenButterflies): Deleted.
(JSC::functionCurrentCPUTime): Deleted.
(JSC::functionTotalGCTime): Deleted.
(JSC::functionParseCount): Deleted.
(JSC::functionIsWasmSupported): Deleted.
(JSC::functionMake16BitStringIfPossible): Deleted.
(JSC::JSDollarVMHelper::functionGetStructureTransitionList): Deleted.
(JSC::functionGetConcurrently): Deleted.
(JSC::functionHasOwnLengthProperty): Deleted.
(JSC::functionRejectPromiseAsHandled): Deleted.
(JSC::functionSetUserPreferredLanguages): Deleted.
(JSC::functionICUVersion): Deleted.
(JSC::functionICUHeaderVersion): Deleted.
(JSC::functionAssertEnabled): Deleted.
(JSC::functionIsMemoryLimited): Deleted.
(JSC::functionUseJIT): Deleted.
(JSC::functionIsGigacageEnabled): Deleted.
(JSC::functionToUncacheableDictionary): Deleted.
* wasm/js/JSWebAssembly.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::webAssemblyCompileFunc): Deleted.
(JSC::webAssemblyInstantiateFunc): Deleted.
(JSC::webAssemblyValidateFunc): Deleted.
(JSC::webAssemblyCompileStreamingInternal): Deleted.
(JSC::webAssemblyInstantiateStreamingInternal): Deleted.
* wasm/js/JSWebAssembly.h:
* wasm/js/WebAssemblyCompileErrorConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::constructJSWebAssemblyCompileError): Deleted.
(JSC::callJSWebAssemblyCompileError): Deleted.
* wasm/js/WebAssemblyFunction.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::callWebAssemblyFunction): Deleted.
* wasm/js/WebAssemblyGlobalConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::constructJSWebAssemblyGlobal): Deleted.
(JSC::callJSWebAssemblyGlobal): Deleted.
* wasm/js/WebAssemblyGlobalPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::webAssemblyGlobalProtoFuncValueOf): Deleted.
(JSC::webAssemblyGlobalProtoGetterFuncValue): Deleted.
(JSC::webAssemblyGlobalProtoSetterFuncValue): Deleted.
* wasm/js/WebAssemblyInstanceConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::constructJSWebAssemblyInstance): Deleted.
(JSC::callJSWebAssemblyInstance): Deleted.
* wasm/js/WebAssemblyInstancePrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::webAssemblyInstanceProtoFuncExports): Deleted.
* wasm/js/WebAssemblyLinkErrorConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::constructJSWebAssemblyLinkError): Deleted.
(JSC::callJSWebAssemblyLinkError): Deleted.
* wasm/js/WebAssemblyMemoryConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::constructJSWebAssemblyMemory): Deleted.
(JSC::callJSWebAssemblyMemory): Deleted.
* wasm/js/WebAssemblyMemoryPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::webAssemblyMemoryProtoFuncGrow): Deleted.
(JSC::webAssemblyMemoryProtoFuncBuffer): Deleted.
* wasm/js/WebAssemblyModuleConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::webAssemblyModuleCustomSections): Deleted.
(JSC::webAssemblyModuleImports): Deleted.
(JSC::webAssemblyModuleExports): Deleted.
(JSC::constructJSWebAssemblyModule): Deleted.
(JSC::callJSWebAssemblyModule): Deleted.
* wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::constructJSWebAssemblyRuntimeError): Deleted.
(JSC::callJSWebAssemblyRuntimeError): Deleted.
* wasm/js/WebAssemblyTableConstructor.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::constructJSWebAssemblyTable): Deleted.
(JSC::callJSWebAssemblyTable): Deleted.
* wasm/js/WebAssemblyTablePrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::webAssemblyTableProtoFuncLength): Deleted.
(JSC::webAssemblyTableProtoFuncGrow): Deleted.
(JSC::webAssemblyTableProtoFuncGet): Deleted.
(JSC::webAssemblyTableProtoFuncSet): Deleted.
* wasm/js/WebAssemblyWrapperFunction.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
(JSC::callWebAssemblyWrapperFunction): Deleted.
2020-09-25 Chris Dumez <cdumez@apple.com>
Get rid of AudioNode::RefType
https://bugs.webkit.org/show_bug.cgi?id=216945
Reviewed by Darin Adler.
* runtime/CachedTypes.cpp:
(JSC::CachedRefPtr::decode const):
2020-09-25 Alexey Shvayka <shvaikalesh@gmail.com>
DataView instances should not have own "byteLength" and "byteOffset" properties
https://bugs.webkit.org/show_bug.cgi?id=149906
Reviewed by Ross Kirsling.
Following JSDataView::getOwnPropertySlot() deletion in r266529, this patch
removes related method overrides that incorrectly reported "byteLength" and
"byteOffset" as own properties of DataView instances [1].
This change brings DataView objects in compliance with invariants of internal
methods [2] and aligns JSC with V8 and SpiderMonkey.
DataView microbenchmarks are neutral.
[1]: https://tc39.es/ecma262/#sec-properties-of-dataview-instances
[2]: https://tc39.es/ecma262/#sec-invariants-of-the-essential-internal-methods
* runtime/JSDataView.cpp:
(JSC::JSDataView::put): Deleted.
(JSC::JSDataView::defineOwnProperty): Deleted.
(JSC::JSDataView::deleteProperty): Deleted.
(JSC::JSDataView::getOwnNonIndexPropertyNames): Deleted.
* runtime/JSDataView.h:
2020-09-25 Adrian Perez de Castro <aperez@igalia.com>
Non-unified build fixes, late September 2020 edition
https://bugs.webkit.org/show_bug.cgi?id=216950
Unreviewed build fix.
* inspector/agents/InspectorConsoleAgent.cpp: Add missing ScriptArguments.h include.
2020-09-24 Ross Kirsling <ross.kirsling@sony.com>
%TypedArray%.prototype.toLocaleString must make conscious use of @toString
https://bugs.webkit.org/show_bug.cgi?id=216956
Reviewed by Yusuke Suzuki.
A fascinating bug: if we override Number.prototype.toLocaleString to return { valueOf() { ... } },
then we can observe our %TypedArray%.prototype.toLocaleString resolving its element values in the wrong order.
* builtins/TypedArrayPrototype.js:
(toLocaleString):
Wrap the toLocaleString call for each element in @toString(), as the spec indicates.
2020-09-24 Ross Kirsling <ross.kirsling@sony.com>
%TypedArray%.prototype.sort must throw if comparator is defined and uncallable
https://bugs.webkit.org/show_bug.cgi?id=216952
Reviewed by Yusuke Suzuki.
* builtins/TypedArrayPrototype.js:
(sort):
2020-09-24 Ross Kirsling <ross.kirsling@sony.com>
%TypedArray% methods should perform TypedArraySpeciesCreate correctly
https://bugs.webkit.org/show_bug.cgi?id=216938
Reviewed by Yusuke Suzuki.
map, filter, and slice are obliged to throw when:
1. this.constructor is defined but not an object
2. the species constructor produces a valid typed array which is shorter than the expected length
* builtins/TypedArrayPrototype.js:
(map):
(filter):
* runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
(JSC::genericTypedArrayViewProtoFuncSlice):
2020-09-24 Basuke Suzuki <basuke.suzuki@sony.com>
[PlayStation] Stop raising SIGPIPE when client side of RemoteInspector dies
https://bugs.webkit.org/show_bug.cgi?id=216805
Reviewed by Don Olmstead.
When communication is stopped caused by peer crash or non-polite close, SIGPIPE will be
raised on BSD (and maybe on Linux). We prefer to handle those events by returning error.
On Windows, there's no such fancy feature from the beginning.
* inspector/remote/socket/posix/RemoteInspectorSocketPOSIX.cpp:
(Inspector::Socket::read):
(Inspector::Socket::write):
2020-09-24 Angelos Oikonomopoulos <angelos@igalia.com>
[MIPS] Broken build after r267371
https://bugs.webkit.org/show_bug.cgi?id=216893
Reviewed by Adrian Perez de Castro.
This addresses two issues.
First, the fix in https://bugs.webkit.org/show_bug.cgi?id=216772 was not
getting exercised, because the LabelReference offset was always zero.
The reason the offset was zero is that LabelReference.mapChildren would discard
the offset when generating a new LabelReference to wrap the Label returned by
the code block it yielded to.
The reason this was only an issue on MIPS is because only MIPS was using the
result of calls to LabelReference.mapChildren (in its lowering phase,
assignRegistersToTemporaries -> replaceTemporariesWithRegisters ->
mapChildren). Other archs, e.g. X86_64 only call mapChildren in earlier phases
(specifically, subsequent to a call to isASTErroneous), in which the new
LabelReferences returned by mapChildren are later discarded. Even though ARM
32/64 contains indirect calls to mapChildren, those are made after the
arm{,64}LowerLabelReferences transformation which doesn't leave any
LabelReference nodes around for .mapChildren to be called on.
So this is not an issue for architectures other than MIPS because
(a) AddImmediates.fold correctly constructs a LabelReference with an offset by
calling LabelReference.plusOffset and
(b) they don't call (and therefore don't use the result of)
LabelReference.mapChildren in their lowering code.
Second, the code we generate needs to look up the /label/ in the GOT, not the
computed address. After the lookup, we simply need to add the offset.
* offlineasm/ast.rb:
* offlineasm/mips.rb:
2020-09-24 Ross Kirsling <ross.kirsling@sony.com>
%TypedArray%.prototype.fill must only evaluate its argument once
https://bugs.webkit.org/show_bug.cgi?id=216912
Reviewed by Yusuke Suzuki.
Currently, we evaluate the argument in `typedArray.fill({ valueOf() { ... } })` once per filled element,
but it should only be evaluated once in total.
* builtins/TypedArrayPrototype.js:
(fill):
2020-09-23 Ross Kirsling <ross.kirsling@sony.com>
%ArrayIteratorPrototype%.next must check for detached buffers
https://bugs.webkit.org/show_bug.cgi?id=216904
Reviewed by Yusuke Suzuki.
Per https://tc39.es/ecma262/#sec-%arrayiteratorprototype%.next:
8. If a has a [[TypedArrayName]] internal slot, then
a. If IsDetachedBuffer(a.[[ViewedArrayBuffer]]) is true, throw a TypeError exception.
* builtins/ArrayIteratorPrototype.js:
(next):
* builtins/BuiltinNames.h:
* bytecode/LinkTimeConstant.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/JSTypedArrayViewPrototype.cpp:
(JSC::typedArrayViewPrivateFuncIsNeutered):
* runtime/JSTypedArrayViewPrototype.h:
2020-09-23 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Simply some of template-specialized host functions by defining each function
https://bugs.webkit.org/show_bug.cgi?id=216907
Reviewed by Saam Barati.
This makes automatically-registering these functions in JIT-caging easy.
* API/APICallbackFunction.h:
(JSC::APICallbackFunction::callImpl):
(JSC::APICallbackFunction::constructImpl):
(JSC::APICallbackFunction::call): Deleted.
(JSC::APICallbackFunction::construct): Deleted.
* API/JSCallbackConstructor.cpp:
(JSC::constructJSCallbackConstructor):
(JSC::JSCallbackConstructor::getConstructData):
* API/JSCallbackFunction.cpp:
(JSC::callJSCallbackFunction):
(JSC::JSCallbackFunction::JSCallbackFunction):
* API/ObjCCallbackFunction.mm:
(JSC::callObjCCallbackFunction):
(JSC::constructObjCCallbackFunction):
(JSC::ObjCCallbackFunction::ObjCCallbackFunction):
* API/glib/JSCCallbackFunction.cpp:
(JSC::callJSCCallbackFunction):
(JSC::constructJSCCallbackFunction):
(JSC::JSCCallbackFunction::JSCCallbackFunction):
* dfg/DFGOperations.h:
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* jsc.cpp:
(accessorMakeMasquerader):
* runtime/JSArrayBufferConstructor.cpp:
(JSC::JSGenericArrayBufferConstructor<sharingMode>::JSGenericArrayBufferConstructor):
(JSC::JSGenericArrayBufferConstructor<sharingMode>::constructImpl):
(JSC::constructArrayBuffer):
(JSC::constructSharedArrayBuffer):
(JSC::JSGenericArrayBufferConstructor<sharingMode>::constructArrayBuffer): Deleted.
* runtime/JSArrayBufferConstructor.h:
* runtime/JSCustomGetterSetterFunction.cpp:
(JSC::customGetterSetterFunctionCall):
(JSC::JSCustomGetterSetterFunction::customGetterSetterFunctionCall): Deleted.
* runtime/JSCustomGetterSetterFunction.h:
* runtime/NativeErrorConstructor.cpp:
(JSC::NativeErrorConstructor<errorType>::constructImpl):
(JSC::NativeErrorConstructor<errorType>::callImpl):
(JSC::callEvalError):
(JSC::constructEvalError):
(JSC::callRangeError):
(JSC::constructRangeError):
(JSC::callReferenceError):
(JSC::constructReferenceError):
(JSC::callSyntaxError):
(JSC::constructSyntaxError):
(JSC::callTypeError):
(JSC::constructTypeError):
(JSC::callURIError):
(JSC::constructURIError):
(JSC::callFunction):
(JSC::constructFunction):
(JSC::NativeErrorConstructor<errorType>::NativeErrorConstructor):
(JSC::NativeErrorConstructorBase::finishCreation):
(JSC::NativeErrorConstructor<errorType>::constructNativeErrorConstructor): Deleted.
(JSC::NativeErrorConstructor<errorType>::callNativeErrorConstructor): Deleted.
* runtime/NativeErrorConstructor.h:
* runtime/RegExpConstructor.cpp:
(JSC::regExpConstructorDollarImpl):
(JSC::regExpConstructorDollar1):
(JSC::regExpConstructorDollar2):
(JSC::regExpConstructorDollar3):
(JSC::regExpConstructorDollar4):
(JSC::regExpConstructorDollar5):
(JSC::regExpConstructorDollar6):
(JSC::regExpConstructorDollar7):
(JSC::regExpConstructorDollar8):
(JSC::regExpConstructorDollar9):
(JSC::regExpConstructorInput):
(JSC::regExpConstructorMultiline):
(JSC::regExpConstructorLastMatch):
(JSC::regExpConstructorLastParen):
(JSC::regExpConstructorLeftContext):
(JSC::regExpConstructorRightContext):
(JSC::setRegExpConstructorInput):
(JSC::setRegExpConstructorMultiline):
(JSC::regExpConstructorDollar): Deleted.
* tools/JSDollarVM.cpp:
2020-09-23 Alexey Shvayka <shvaikalesh@gmail.com>
Update Array.prototype.sort to be consistent with tightened spec
https://bugs.webkit.org/show_bug.cgi?id=202582
Reviewed by Yusuke Suzuki and Keith Miller.
This patch implements the spec change [1] that reduces amount of cases resulting
in an implementation-defined sort order, aligning JSC with V8 and SpiderMonkey.
To achieve this, we collect all existing non-undefined receiver elements to a
temporary array, sort it, and write back sorted items, followed by `undefined`
values and holes.
This change is proven to be web-compatible (shipping since Chrome 76) and neutral
on peak memory consumption in the wild.
Although we can unobservably detect sparse receivers, we can't avoid creating a
temporary array for common case since userland comparators may throw; string
sorting won't measurably benefit from this, only increasing code complexity.
This change uses @putByValDirect unless the spec requires [[Set]], avoids using
closure variables, and adds a few drive-by optimizations, resulting in ~22%
faster string sorting and 13% speed-up for userland comparators.
Dromaeo/jslib is neutral.
[1]: https://github.com/tc39/ecma262/pull/1585
* builtins/ArrayPrototype.js:
(sort.stringComparator):
Optimization #1: replace char-by-char comparison loop with > operator, aligning
JSC with V8 and SpiderMonkey. This semantically equivalent change alone is a ~15%
progression for string sort.
(sort.compact):
(sort.commit):
Optimization #2: copy large non-numeric arrays in a loop rather than @appendMemcpy.
Using the latter unconditionally regresses provided microbenchmarks.
(sort.merge):
Optimization #3: replace `typeof` check and negation with strict equality.
(sort.mergeSort):
Optimization #4: always return sorted array instead of copying, even if it's the buffer.
Tweak: create the buffer with correct length.
(sort.bucketSort):
Optimization #5: avoid emitting 2 extra get_by_val ops by saving bucket lookup to a variable.
Tweak: create new bucket via array literal.
(sort): Fix typo in error message.
(sort.compactSparse): Deleted.
(sort.compactSlow): Deleted.
(sort.comparatorSort): Deleted.
(sort.stringSort): Deleted.
* runtime/ObjectConstructor.cpp:
(JSC::ObjectConstructor::finishCreation):
Remove @Object.@getPrototypeOf as it's now unused and we have @getPrototypeOf intrinsic anyway.
2020-09-23 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Intl spec update: handle awkward rounding behavior
https://bugs.webkit.org/show_bug.cgi?id=216760
Reviewed by Ross Kirsling.
This patch supports new spec change of "handle awkward rounding behavior"[1].
This changes minimumFractionDigits / maximumFractionDigits calculation when the specified ones are less than currency-digits.
[1]: https://github.com/tc39/ecma402/pull/471
* runtime/CommonIdentifiers.h:
* runtime/IntlNumberFormat.cpp:
(JSC::IntlNumberFormat::resolvedOptions const):
* runtime/IntlNumberFormatInlines.h:
(JSC::setNumberFormatDigitOptions):
* runtime/IntlPluralRules.cpp:
(JSC::IntlPluralRules::resolvedOptions const):
2020-09-23 Caio Lima <ticaiolima@gmail.com>
[JSC][ESNext] Create a new opcode to handle private fields store/define
https://bugs.webkit.org/show_bug.cgi?id=213372
Reviewed by Yusuke Suzuki.
This patch is adding a new opcode to handle private field storage.
Before this change, we were using `put_by_val_direct` and including
the information of `PutKind` into `PutByValFlags`. We initially decided
to use `put_by_val_direct` to take advantage of all IC mechanism already
implemented for this instruction, however the semantics of private field
is different enough to complicate the understanding of
`put_by_val_direct`.
The new instruction is called `put_private_name` and has as its operands
`baseObject` where the put is going to be placed, the `property`
that's going to be installed (it is always a private symbol of a
private field), the `value` we are going to store and the
`PrivateFieldPutKind` that can be `Define` or `Set`.
The difference of each `PrivateFieldPutKind` is the following:
- Define: It defines a new private field. If this field is already
present, it throws a `TypeError`.
- Set: It sets the value of a private field. If the field is not
present at the moment of set, it throws a `TypeError`.
This patch includes support of IC for all tiers. For DFG and FTL, we
are only emmiting IC when we are able to emit `CheckConstant`
for subscript identifier during Bytecode parsing. We are adding a new
DFG node called `PutPrivateNameById` that handles such cases when we
have constant identifiers.
We are also adding a new DFG node `PutPrivateName` that handles generic
case of `put_private_name`. The strategy used to compile
`put_private_name` is very similar with what we are using with
`put_by_val[_direct]`. We first try to compile it as `[Multi]PutByOffset`
using profiled information from LLInt and Baseline execution. If it
is not possible, we then emit `PutPrivateName[ById]` node. We get another
chance to transform `PutPrivateNameById` into `PutByOffset` if we can prove
its structure set at constant folding phase.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* bytecode/BytecodeList.rb:
* bytecode/BytecodeUseDef.cpp:
(JSC::computeUsesForBytecodeIndexImpl):
(JSC::computeDefsForBytecodeIndexImpl):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::propagateTransitions):
(JSC::CodeBlock::finalizeLLIntInlineCaches):
* bytecode/Fits.h:
* bytecode/PutByIdStatus.cpp:
(JSC::PutByIdStatus::computeFromLLInt):
(JSC::PutByIdStatus::computeFor):
* bytecode/PutByIdStatus.h:
* bytecode/PutByValFlags.cpp: Removed.
* bytecode/PutByValFlags.h: Removed.
* bytecode/PutKind.h:
(): Deleted.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitDirectPutByVal):
(JSC::BytecodeGenerator::emitDefinePrivateField):
(JSC::BytecodeGenerator::emitPrivateFieldPut):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handlePutPrivateNameById):
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::handlePutByVal):
(JSC::DFG::ecmaMode): Deleted.
(JSC::DFG::ecmaMode<OpPutByValDirect>): Deleted.
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
(JSC::DFG::ConstantFoldingPhase::tryFoldAsPutByOffset):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::convertToPutByOffset):
(JSC::DFG::Node::convertToMultiPutByOffset):
(JSC::DFG::Node::hasCacheableIdentifier):
(JSC::DFG::Node::hasPrivateFieldPutKind):
(JSC::DFG::Node::privateFieldPutKind):
* dfg/DFGNodeType.h:
* dfg/DFGOpInfo.h:
(JSC::DFG::OpInfo::OpInfo):
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compilePutPrivateName):
(JSC::DFG::SpeculativeJIT::compilePutPrivateNameById):
(JSC::DFG::SpeculativeJIT::compilePutByIdFlush):
(JSC::DFG::SpeculativeJIT::compilePutById):
(JSC::DFG::SpeculativeJIT::compilePutByIdDirect):
(JSC::DFG::SpeculativeJIT::cachedPutById):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStoreBarrierInsertionPhase.cpp:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compilePutPrivateNameById):
(JSC::FTL::DFG::LowerDFGToB3::compilePutPrivateName):
(JSC::FTL::DFG::LowerDFGToB3::cachedPutById):
(JSC::FTL::DFG::LowerDFGToB3::compilePutById):
* generator/DSL.rb:
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
(JSC::JIT::link):
* jit/JIT.h:
(JSC::ByValCompilationInfo::ByValCompilationInfo):
* jit/JITInlineCacheGenerator.cpp:
(JSC::JITPutByIdGenerator::JITPutByIdGenerator):
(JSC::JITPutByIdGenerator::slowPathFunction):
* jit/JITInlineCacheGenerator.h:
(JSC::JITPutByIdGenerator::JITPutByIdGenerator):
* jit/JITInlines.h:
(JSC::JIT::ecmaMode<OpPutPrivateName>):
(JSC::JIT::ecmaMode<OpPutByValDirect>): Deleted.
(JSC::JIT::privateFieldAccessKind): Deleted.
(JSC::JIT::privateFieldAccessKind<OpPutByValDirect>): Deleted.
* jit/JITOperations.cpp:
(JSC::setPrivateField):
(JSC::putPrivateField): Deleted.
* jit/JITOperations.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitPutByValWithCachedId):
(JSC::JIT::emitSlow_op_put_by_val):
(JSC::JIT::emit_op_put_private_name):
(JSC::JIT::emitSlow_op_put_private_name):
(JSC::JIT::emit_op_put_by_id):
(JSC::JIT::emitPutPrivateNameWithCachedId):
(JSC::JIT::privateCompilePutPrivateNameWithCachedId):
(JSC::JIT::privateCompilePutByValWithCachedId):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_put_private_name):
(JSC::JIT::emitSlow_op_put_private_name):
(JSC::JIT::emit_op_put_by_id):
* jit/Repatch.cpp:
(JSC::appropriateGenericPutByIdFunction):
(JSC::appropriateOptimizingPutByIdFunction):
(JSC::tryCachePutByID):
(JSC::resetPutByID):
* llint/LLIntOffsetsExtractor.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LLIntSlowPaths.h:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/JSObject.h:
* runtime/JSObjectInlines.h:
(JSC::JSObject::setPrivateField):
(JSC::JSObject::putPrivateField): Deleted.
* runtime/PrivateFieldPutKind.cpp: Added.
(JSC::PrivateFieldPutKind::dump const):
* runtime/PrivateFieldPutKind.h: Added.
(JSC::PrivateFieldPutKind::fromByte):
(JSC::PrivateFieldPutKind::none):
(JSC::PrivateFieldPutKind::set):
(JSC::PrivateFieldPutKind::define):
(JSC::PrivateFieldPutKind::isNone const):
(JSC::PrivateFieldPutKind::isSet const):
(JSC::PrivateFieldPutKind::isDefine const):
(JSC::PrivateFieldPutKind::value const):
(JSC::PrivateFieldPutKind::PrivateFieldPutKind):
2020-09-22 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Enable Intl.DateTimeFormat dayPeriod
https://bugs.webkit.org/show_bug.cgi?id=216845
Reviewed by Mark Lam.
Since we already have consensus, let's enable it.
For now, we keep this flag since it is possible that something
happens before the change is integrated into the spec.
* runtime/OptionsList.h:
2020-09-22 HyeockJin Kim <kherootz@gmail.com>
Coerce computed property before adding to |excludedList|
https://bugs.webkit.org/show_bug.cgi?id=216437
Reviewed by Yusuke Suzuki.
* bytecompiler/NodesCodegen.cpp:
(JSC::ObjectPatternNode::bindValue const):
2020-09-21 Paulo Matos <pmatos@igalia.com>
Fix MIPS leai,leap when offset is nonzero
https://bugs.webkit.org/show_bug.cgi?id=216772
Reviewed by Mark Lam.
Fix required by change from webkit#216685
* offlineasm/mips.rb:
2020-09-21 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] BigInt should work with Map / Set
https://bugs.webkit.org/show_bug.cgi?id=216667
Reviewed by Robin Morisset.
This patch makes BigInt supported in Map / Set.
1. In NormalizeMapKey, we always attempt to convert HeapBigInt to BigInt32 (if supported). So we ensure that,
normalized BigInt has one unique form for BigInt32 range. This allows us to use hashing for BigInt32 bit pattern directly.
2. In MapHash, for BigInt32, we directly has the JSValue bits. For HeapBigInt, we calculate hash via Hasher.
3. In GetMapBucket, we consider HeapBigInt case correctly.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::fixupNormalizeMapKey):
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileNormalizeMapKey):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileMapHash):
(JSC::FTL::DFG::LowerDFGToB3::compileNormalizeMapKey):
(JSC::FTL::DFG::LowerDFGToB3::compileGetMapBucket):
* runtime/HashMapImpl.h:
(JSC::normalizeMapKey):
(JSC::jsMapHash):
(JSC::concurrentJSMapHash):
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::concurrentHash):
* runtime/JSBigInt.h:
(JSC::tryConvertToBigInt32):
2020-09-21 Mark Lam <mark.lam@apple.com>
Move some LLInt globals into JSC::Config.
https://bugs.webkit.org/show_bug.cgi?id=216685
rdar://68964544
Reviewed by Keith Miller.
1. Moved the following into g_jscConfig:
Data::s_exceptionInstructions ==> g_jscConfig.llint.exceptionInstructions
Data::s_wasmExceptionInstructions ==> g_jscConfig.llint.wasmExceptionInstructions
g_opcodeMap ==> g_jscConfig.llint.opcodeMap
g_opcodeMapWide16 ==> g_jscConfig.llint.opcodeMapWide16
g_opcodeMapWide32 ==> g_jscConfig.llint.opcodeMapWide32
2. Fixed cloop.rb so that it can take an offset for the leap offlineasm instruction.
3. Fixed x86.rb so that it can take an offset for the leap offlineasm instruction.
4. Fixed arm.rb so that it can take an offset for the leap offlineasm instruction.
Note: arm64.rb already does this right.
5. Added JSC::Config::singleton() to return a reference to g_jscConfig.
This is useful when debugging with lldb since g_jscConfig is not an actual
label, but is a macro that computes the address of the Config record.
This patch has been smoke tested on arm64e, x86_64, and cloop (on x86_64 and armv7k).
* llint/LLIntData.cpp:
(JSC::LLInt::LLIntInitializeAssertScope::LLIntInitializeAssertScope):
(JSC::LLInt::LLIntInitializeAssertScope::~LLIntInitializeAssertScope):
(JSC::LLInt::LLIntInitializeAssertScope::assertInitializationIsAllowed):
(JSC::LLInt::initialize):
* llint/LLIntData.h:
(JSC::LLInt::exceptionInstructions):
(JSC::LLInt::wasmExceptionInstructions):
(JSC::LLInt::opcodeMap):
(JSC::LLInt::opcodeMapWide16):
(JSC::LLInt::opcodeMapWide32):
(JSC::LLInt::getOpcode):
(JSC::LLInt::getOpcodeWide16):
(JSC::LLInt::getOpcodeWide32):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter.cpp:
* llint/LowLevelInterpreter64.asm:
* llint/WebAssembly.asm:
* offlineasm/arm.rb:
* offlineasm/cloop.rb:
* offlineasm/x86.rb:
* runtime/JSCConfig.cpp:
(JSC::Config::singleton):
* runtime/JSCConfig.h:
2020-09-21 Basuke Suzuki <basuke.suzuki@sony.com>
[WinCairo][PlayStation] Support different instances of listener client.
https://bugs.webkit.org/show_bug.cgi?id=216733
Reviewed by Don Olmstead.
Currently RemoteInspectorSocketEndpoint support one client instance for all
listeners. This patch allows listeners to create its own listener client on
accept timing.
* inspector/remote/RemoteControllableTarget.h:
* inspector/remote/RemoteInspector.h:
* inspector/remote/socket/RemoteInspectorConnectionClient.cpp:
(Inspector::RemoteInspectorConnectionClient::didReceive):
* inspector/remote/socket/RemoteInspectorConnectionClient.h:
* inspector/remote/socket/RemoteInspectorServer.cpp:
(Inspector::RemoteInspectorServer::start):
(Inspector::RemoteInspectorServer::doAccept):
* inspector/remote/socket/RemoteInspectorServer.h:
* inspector/remote/socket/RemoteInspectorSocket.cpp:
(Inspector::RemoteInspector::didClose):
* inspector/remote/socket/RemoteInspectorSocket.h:
* inspector/remote/socket/RemoteInspectorSocketEndpoint.cpp:
(Inspector::RemoteInspectorSocketEndpoint::RemoteInspectorSocketEndpoint):
(Inspector::RemoteInspectorSocketEndpoint::~RemoteInspectorSocketEndpoint):
(Inspector::RemoteInspectorSocketEndpoint::listenInet):
(Inspector::RemoteInspectorSocketEndpoint::workerThread):
(Inspector::RemoteInspectorSocketEndpoint::generateConnectionID):
(Inspector::RemoteInspectorSocketEndpoint::createClient):
(Inspector::RemoteInspectorSocketEndpoint::disconnect):
(Inspector::RemoteInspectorSocketEndpoint::createListener):
(Inspector::RemoteInspectorSocketEndpoint::invalidateClient):
(Inspector::RemoteInspectorSocketEndpoint::invalidateListener):
(Inspector::RemoteInspectorSocketEndpoint::getPort const):
(Inspector::RemoteInspectorSocketEndpoint::recvIfEnabled):
(Inspector::RemoteInspectorSocketEndpoint::sendIfEnabled):
(Inspector::RemoteInspectorSocketEndpoint::send):
(Inspector::RemoteInspectorSocketEndpoint::acceptInetSocketIfEnabled):
* inspector/remote/socket/RemoteInspectorSocketEndpoint.h:
2020-09-21 Keith Miller <keith_miller@apple.com>
Functions should consistently enumerate length before name
https://bugs.webkit.org/show_bug.cgi?id=216789
Reviewed by Yusuke Suzuki.
In https://github.com/tc39/ecma262/pull/2116, which has been
approved to be merged into the main JS spec, it's expected that
all functions should have their length property enumerated before
the name property. To ensure this invariant, this patch moves the
length set into InternalFunction::finishCreation.
There are no new tests since tests will be added to test262 when
the spec PR is merged. Adding tests to stress just means we will
have the same test twice, which seems like a waste.
* API/JSCallbackFunction.cpp:
(JSC::JSCallbackFunction::finishCreation):
* API/ObjCCallbackFunction.mm:
(JSC::ObjCCallbackFunction::create):
* API/glib/JSCCallbackFunction.cpp:
(JSC::JSCCallbackFunction::create):
* runtime/AggregateErrorConstructor.cpp:
(JSC::AggregateErrorConstructor::finishCreation):
* runtime/ArrayConstructor.cpp:
(JSC::ArrayConstructor::finishCreation):
* runtime/AsyncFunctionConstructor.cpp:
(JSC::AsyncFunctionConstructor::finishCreation):
* runtime/AsyncGeneratorFunctionConstructor.cpp:
(JSC::AsyncGeneratorFunctionConstructor::finishCreation):
* runtime/BigIntConstructor.cpp:
(JSC::BigIntConstructor::finishCreation):
* runtime/BooleanConstructor.cpp:
(JSC::BooleanConstructor::finishCreation):
* runtime/DateConstructor.cpp:
(JSC::DateConstructor::finishCreation):
* runtime/ErrorConstructor.cpp:
(JSC::ErrorConstructor::finishCreation):
* runtime/FinalizationRegistryConstructor.cpp:
(JSC::FinalizationRegistryConstructor::finishCreation):
* runtime/FunctionConstructor.cpp:
(JSC::FunctionConstructor::finishCreation):
* runtime/FunctionPrototype.cpp:
(JSC::FunctionPrototype::finishCreation):
* runtime/GeneratorFunctionConstructor.cpp:
(JSC::GeneratorFunctionConstructor::finishCreation):
* runtime/InternalFunction.cpp:
(JSC::InternalFunction::finishCreation):
(JSC::InternalFunction::createFunctionThatMasqueradesAsUndefined):
* runtime/InternalFunction.h:
* runtime/IntlCollatorConstructor.cpp:
(JSC::IntlCollatorConstructor::finishCreation):
* runtime/IntlDateTimeFormatConstructor.cpp:
(JSC::IntlDateTimeFormatConstructor::finishCreation):
* runtime/IntlDisplayNamesConstructor.cpp:
(JSC::IntlDisplayNamesConstructor::finishCreation):
* runtime/IntlLocaleConstructor.cpp:
(JSC::IntlLocaleConstructor::finishCreation):
* runtime/IntlNumberFormatConstructor.cpp:
(JSC::IntlNumberFormatConstructor::finishCreation):
* runtime/IntlPluralRulesConstructor.cpp:
(JSC::IntlPluralRulesConstructor::finishCreation):
* runtime/IntlRelativeTimeFormatConstructor.cpp:
(JSC::IntlRelativeTimeFormatConstructor::finishCreation):
* runtime/IntlSegmenterConstructor.cpp:
(JSC::IntlSegmenterConstructor::finishCreation):
* runtime/JSArrayBufferConstructor.cpp:
(JSC::JSGenericArrayBufferConstructor<sharingMode>::finishCreation):
* runtime/JSGenericTypedArrayViewConstructorInlines.h:
(JSC::JSGenericTypedArrayViewConstructor<ViewClass>::finishCreation):
* runtime/JSTypedArrayViewConstructor.cpp:
(JSC::JSTypedArrayViewConstructor::finishCreation):
* runtime/MapConstructor.cpp:
(JSC::MapConstructor::finishCreation):
* runtime/NativeErrorConstructor.cpp:
(JSC::NativeErrorConstructorBase::finishCreation):
* runtime/NullGetterFunction.h:
* runtime/NullSetterFunction.h:
* runtime/NumberConstructor.cpp:
(JSC::NumberConstructor::finishCreation):
* runtime/ObjectConstructor.cpp:
(JSC::ObjectConstructor::finishCreation):
* runtime/ProxyConstructor.cpp:
(JSC::ProxyConstructor::finishCreation):
* runtime/ProxyRevoke.cpp:
(JSC::ProxyRevoke::finishCreation):
* runtime/RegExpConstructor.cpp:
(JSC::RegExpConstructor::finishCreation):
* runtime/SetConstructor.cpp:
(JSC::SetConstructor::finishCreation):
* runtime/StringConstructor.cpp:
(JSC::StringConstructor::finishCreation):
* runtime/SymbolConstructor.cpp:
(JSC::SymbolConstructor::finishCreation):
* runtime/WeakMapConstructor.cpp:
(JSC::WeakMapConstructor::finishCreation):
* runtime/WeakObjectRefConstructor.cpp:
(JSC::WeakObjectRefConstructor::finishCreation):
* runtime/WeakSetConstructor.cpp:
(JSC::WeakSetConstructor::finishCreation):
* wasm/js/WebAssemblyCompileErrorConstructor.cpp:
(JSC::WebAssemblyCompileErrorConstructor::finishCreation):
* wasm/js/WebAssemblyGlobalConstructor.cpp:
(JSC::WebAssemblyGlobalConstructor::finishCreation):
* wasm/js/WebAssemblyInstanceConstructor.cpp:
(JSC::WebAssemblyInstanceConstructor::finishCreation):
* wasm/js/WebAssemblyLinkErrorConstructor.cpp:
(JSC::WebAssemblyLinkErrorConstructor::finishCreation):
* wasm/js/WebAssemblyMemoryConstructor.cpp:
(JSC::WebAssemblyMemoryConstructor::finishCreation):
* wasm/js/WebAssemblyModuleConstructor.cpp:
(JSC::WebAssemblyModuleConstructor::finishCreation):
* wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
(JSC::WebAssemblyRuntimeErrorConstructor::finishCreation):
* wasm/js/WebAssemblyTableConstructor.cpp:
(JSC::WebAssemblyTableConstructor::finishCreation):
2020-09-21 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Proxy should be trapped if base value is primitive
https://bugs.webkit.org/show_bug.cgi?id=216764
Reviewed by Darin Adler.
While we have special care in JSObject::putInline etc., we missed it in JSValue::putToPrimitive.
So, if proxy exists in the prototype chain for the primitive values (e.g. StringPrototype -> Proxy chain),
we miss the Proxy trap. We should have ProxyObject special check in JSValue::putToPrimitive too.
* runtime/JSCJSValue.cpp:
(JSC::JSValue::putToPrimitive):
2020-09-20 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Drop Options::useBigInt
https://bugs.webkit.org/show_bug.cgi?id=216743
Reviewed by Darin Adler.
Now BigInt is shipped. Let's just remove Options::useBigInt.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitEqualityOpImpl):
* parser/Lexer.cpp:
(JSC::Lexer<T>::parseHex):
(JSC::Lexer<T>::parseBinary):
(JSC::Lexer<T>::parseOctal):
(JSC::Lexer<T>::parseDecimal):
* runtime/JSGlobalObject.h:
* runtime/OptionsList.h:
2020-09-20 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, use RELEASE_AND_RETURN to suppress exception verification failure
https://bugs.webkit.org/show_bug.cgi?id=216686
<rdar://problem/69157632>
* runtime/JSModuleNamespaceObject.cpp:
(JSC::JSModuleNamespaceObject::defineOwnProperty):
2020-09-18 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Generator declaration should not be allowed in single statement context
https://bugs.webkit.org/show_bug.cgi?id=216720
Reviewed by Ross Kirsling.
Generator declaration in single statement context (like the following code) should be syntax error.
We already made async function / async generator function syntax error. We should apply the same rule
to generator declaration too.
if (false)
function * gen() { }
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseSingleFunction):
(JSC::Parser<LexerType>::parseStatement):
(JSC::Parser<LexerType>::parseFunctionDeclarationStatement):
(JSC::Parser<LexerType>::parseFunctionDeclaration):
(JSC::Parser<LexerType>::parseExportDeclaration):
* parser/Parser.h:
2020-09-18 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] PreciseAllocation's isNewlyAllocated flag should be propagated from isMarked at GC begin phase to make isLive correct
https://bugs.webkit.org/show_bug.cgi?id=216717
Reviewed by Mark Lam.
When starting full GC, at beginMarking, PreciseAllocation's mark bit is cleared to be usable for upcoming marking.
However, this means that HeapCell::isLive will see this object as dead until it is marked.
Let's consider that this object is not newly allocated one. Then, its isNewlyAllocated is false. And now mark bit
is also cleared. Since PreciseAllocation::isLive is isNewlyAllocated || isMarked, then it looks dead, while it is live.
This confuses HeapCell:isLive function and makes some of watchpoints perform wrong decisions (e.g. this condition is
no longer valid, let's just discard it).
At the beginning of full collection, we should propagate the old mark bit to isNewlyAllocated so that it looks live
during marking. This is similar trick to MarkedBlock::aboutToMark.
* heap/PreciseAllocation.cpp:
(JSC::PreciseAllocation::flip):
2020-09-18 Saam Barati <sbarati@apple.com>
console APIs shouldn't crash making a string that's too long for a console warning when using user provided labels
https://bugs.webkit.org/show_bug.cgi?id=216709
<rdar://problem/68275357>
Reviewed by Mark Lam and Devin Rousso.
Various console APIs send warnings when a label can't be found. These warnings
include the label itself. If this label has a long enough length, when we make
these warning strings, we can crash, because we exceed max string length.
This patch fixes this by truncating the label everywhere it's used if it
exceeds a length of 10000.
* inspector/JSGlobalObjectConsoleClient.cpp:
(Inspector::JSGlobalObjectConsoleClient::profile):
* inspector/ScriptArguments.h:
* inspector/agents/InspectorConsoleAgent.cpp:
(Inspector::InspectorConsoleAgent::startTiming):
(Inspector::InspectorConsoleAgent::logTiming):
(Inspector::InspectorConsoleAgent::stopTiming):
(Inspector::InspectorConsoleAgent::count):
(Inspector::InspectorConsoleAgent::countReset):
2020-09-18 Keith Miller <keith_miller@apple.com>
DFG should ensure there are PhantomLocals for the taken block of op_jneq_ptr
https://bugs.webkit.org/show_bug.cgi?id=216669
Reviewed by Saam Barati.
Right now, if there is a local that is live on the taken branch but dead on
not-taken branch then nothing will preserve it for OSR exit. This patch simply
adds a PhantomLocal for each live operand for the first bytecode of the taken block.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
2020-09-18 Paulo Matos <pmatos@igalia.com>
Unified build fixes from ARMv7 build failures
https://bugs.webkit.org/show_bug.cgi?id=216698
Reviewed by Adrian Perez de Castro.
* llint/LLIntThunks.cpp:
* runtime/FileBasedFuzzerAgent.cpp:
* runtime/FunctionExecutableDump.cpp:
* runtime/NativeExecutable.cpp:
* runtime/WeakMapImpl.cpp:
2020-09-17 Mark Lam <mark.lam@apple.com>
Use OS_CONSTANT(EFFECTIVE_ADDRESS_WIDTH) in speculationFromCell()'s isSanePointer().
https://bugs.webkit.org/show_bug.cgi?id=216638
Reviewed by Saam Barati.
We should be using OS_CONSTANT(EFFECTIVE_ADDRESS_WIDTH) instead of assuming the
width of the pointer address bits.
* bytecode/SpeculatedType.cpp:
(JSC::isSanePointer):
2020-09-17 Devin Rousso <drousso@apple.com>
Web Inspector: REGRESSION(r266885): fix open source build
https://bugs.webkit.org/show_bug.cgi?id=216675
Reviewed by Timothy Hatcher.
Add back methods used by `WebInspector.framework`.
* inspector/InspectorBackendDispatcher.cpp:
(Inspector::BackendDispatcher::getInteger): Added.
(Inspector::BackendDispatcher::getDouble): Added.
(Inspector::BackendDispatcher::getString): Added.
2020-09-17 Tadeu Zagallo <tzagallo@apple.com>
Inconsistent loop exit assertion in B3ReduceLoopStrength
https://bugs.webkit.org/show_bug.cgi?id=216274
<rdar://problem/68513573>
Reviewed by Keith Miller.
On B3ReduceLoopStrength, we first calculate where the loop exits to, and ensure there's only
one exit target. Later on, we compute how many places within the loop exit to that single exit
target. Currently, we assume that having a single target implies that we'll only ever have one
exit point, which is incorrect. To fix it, instead of asserting there should only be one exit
point, we just bail if we find more than one.
* b3/B3ReduceLoopStrength.cpp:
(JSC::B3::ReduceLoopStrength::reduceByteCopyLoopsToMemcpy):
2020-09-17 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Async generator default-export is not handled
https://bugs.webkit.org/show_bug.cgi?id=216643
Reviewed by Ross Kirsling.
`export default async function * test() { }` syntax should be correctly handled.
This patch adds the code retrieving "test" name from the above declaration correctly.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseExportDeclaration):
2020-09-17 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Update JSModuleNamespaceObject::defineOwnProperty
https://bugs.webkit.org/show_bug.cgi?id=216640
Reviewed by Ross Kirsling.
This patch implements spec update of JSModuleNamespaceObject::defineOwnProperty.
We implement https://tc39.es/ecma262/#sec-module-namespace-exotic-objects-defineownproperty-p-desc precisely.
* runtime/JSModuleNamespaceObject.cpp:
(JSC::JSModuleNamespaceObject::getOwnPropertySlotCommon):
(JSC::JSModuleNamespaceObject::deleteProperty):
(JSC::JSModuleNamespaceObject::getOwnPropertyNames):
(JSC::JSModuleNamespaceObject::defineOwnProperty):
2020-09-17 Mark Lam <mark.lam@apple.com>
Add some pointer sanity checks to speculationFromCell().
https://bugs.webkit.org/show_bug.cgi?id=216638
rdar://23226333
Reviewed by Yusuke Suzuki.
Add some sanity checks to mitigate against some potential pointer corruptions
from profiling data. The goal here is not to exhaustively filter out all possible
bad pointers, but simply to filter out as many as possible to reduce crashes from
such bad pointers, and to do so with the least possible performance impact.
It is OK to do such filtering here because we're only trying to compute a
SpeculatedType from the pointer. If the pointer is bad, we can just return
SpecNone indicating that we don't have any info to speculate on.
* bytecode/SpeculatedType.cpp:
(JSC::isSanePointer):
(JSC::speculationFromCell):
* runtime/StructureIDTable.h:
(JSC::StructureIDTable::tryGet):
* runtime/VM.h:
(JSC::VM::tryGetStructure):
2020-09-17 Yusuke Suzuki <ysuzuki@apple.com>
Support export namespace `export * as ns`
https://bugs.webkit.org/show_bug.cgi?id=214379
Reviewed by Ross Kirsling.
This patch supports `export * as ns from "module"` syntax. If it is used, we expose "module"'s namespace object as "ns".
For each module environment, we create *namespace* (starNamespace) private symbol scope variable. And we fill it later
with module namespace object. This way allows us to use module namespace object IC and super fast imported module binding
lookup though environment variable lookup mechanism.
* builtins/BuiltinNames.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::BytecodeGenerator):
* parser/NodesAnalyzeModule.cpp:
(JSC::ExportNamedDeclarationNode::analyzeModule):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseExportDeclaration):
* runtime/AbstractModuleRecord.cpp:
(JSC::AbstractModuleRecord::ExportEntry::createNamespace):
(JSC::AbstractModuleRecord::resolveExportImpl):
(JSC::AbstractModuleRecord::getModuleNamespace):
(JSC::AbstractModuleRecord::setModuleEnvironment):
(JSC::AbstractModuleRecord::dump):
* runtime/AbstractModuleRecord.h:
* runtime/CommonIdentifiers.h:
* runtime/JSFunction.cpp:
(JSC::JSFunction::name):
(JSC::JSFunction::reifyName):
* runtime/JSModuleNamespaceObject.cpp:
(JSC::JSModuleNamespaceObject::getOwnPropertySlotCommon):
* runtime/JSModuleRecord.cpp:
(JSC::JSModuleRecord::instantiateDeclarations):
(JSC::JSModuleRecord::evaluate):
* wasm/js/JSWebAssemblyModule.cpp:
(JSC::JSWebAssemblyModule::finishCreation):
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::link):
2020-09-17 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Optimize Promise#finally by avoiding creating multiple environments
https://bugs.webkit.org/show_bug.cgi?id=216637
Reviewed by Ross Kirsling.
Let's just create functions inside Promise#finally. This avoids creating
multiple lexical environments that are captured by each function.
* builtins/PromisePrototype.js:
(finally):
(globalPrivate.getThenFinally): Deleted.
(globalPrivate.getCatchFinally): Deleted.
2020-09-16 Saam Barati <sbarati@apple.com>
Don't IC a null custom accessor/value setter
https://bugs.webkit.org/show_bug.cgi?id=216620
<rdar://problem/68976066>
Reviewed by Mark Lam.
Our runtime allows CustomGetterSetter objects setter field to not contain an
actual C function to call. In such a scenario, the runtime just does nothing
except return false to the ::put code (which may result in throwing an
exception in strict mode code).
However, our IC code never considered whether this function could be nullptr.
The fix here is simple: don't IC such custom accessor/value setters.
* runtime/PutPropertySlot.h:
(JSC::PutPropertySlot::isCacheableCustom const):
2020-09-16 Philippe Normand <pnormand@igalia.com>
[Flatpak SDK][WPE] Launching the remote inspector kills MB
https://bugs.webkit.org/show_bug.cgi?id=213899
Reviewed by Adrian Perez de Castro.
Load inspector resources from developer build artefacts, when the inspector server is
running in this configuration. Fall back to system libraries loading mechanism otherwise.
* inspector/remote/glib/RemoteInspectorUtils.cpp:
(Inspector::backendCommands):
2020-09-16 Adrian Perez de Castro <aperez@igalia.com>
Non-unified build fixes, early September 2020 edition
https://bugs.webkit.org/show_bug.cgi?id=216599
Unreviewed build fix.
Largely based on a patch by Lauro Moura <lmoura@igalia.com>
* runtime/IntlCache.cpp: Add missing wtf/Vector.h include.
* runtime/IntlCache.h: Add missing wtf/text/CString.h include.
* runtime/IntlNumberFormatPrototype.cpp: Replace IntlNumberFormat.h
include with IntlNumberFormatInlines.h to fix linking.
2020-09-15 Saam Barati <sbarati@apple.com>
JSImmutableButterfly::get needs to return jsDoubleNumber for double arrays
https://bugs.webkit.org/show_bug.cgi?id=216589
<rdar://problem/68061245>
Reviewed by Yusuke Suzuki.
We are using JSImmutableButterfly::get in AI to constant fold GetByVal,
but we were failing to always return a boxed double value for double loads.
We were calling jsNumber instead of jsDooubleNumber. This is in contrast to
the runtime, which always returns a double boxed value. This would lead AI
to disagree with the runtime, and miscompile code.
* runtime/JSImmutableButterfly.h:
(JSC::JSImmutableButterfly::get const):
2020-09-15 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Cache UDateTimePatternGenerator
https://bugs.webkit.org/show_bug.cgi?id=213454
Reviewed by Ross Kirsling.
ICU udatpg_open function is particularly slow. As a result, 80~% of time is used by this function when calling Date#toLocaleString.
We should have last-used cache in VM, which covers major cases like, "One locale (possibly default locale) is used and continuously
use toLocaleString with that locale".
This significantly improves toLocaleString / toLocaleDateString / toLocaleTimeString performance.
ToT Patched
date-to-locale-string 392.0092+-0.6811 ^ 87.3196+-3.1598 ^ definitely 4.4894x faster
date-to-locale-date-string 377.9117+-7.8701 ^ 70.4155+-3.6661 ^ definitely 5.3669x faster
date-to-locale-time-string 373.1970+-3.0142 ^ 67.3790+-2.8952 ^ definitely 5.5388x faster
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* runtime/IntlCache.cpp: Added.
(JSC::IntlCache::cacheSharedPatternGenerator):
(JSC::IntlCache::getBestDateTimePattern):
* runtime/IntlCache.h: Added.
(JSC::IntlCache::getSharedPatternGenerator):
* runtime/IntlDateTimeFormat.cpp:
(JSC::IntlDateTimeFormat::initializeDateTimeFormat):
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
(JSC::VM::intlCache):
2020-09-15 HyeockJin Kim <kherootz@gmail.com>
Check whether the iterator is callable in spread
https://bugs.webkit.org/show_bug.cgi?id=215974
Reviewed by Darin Adler.
* builtins/IteratorHelpers.js:
(performIteration):
2020-09-15 Tadeu Zagallo <tzagallo@apple.com>
Object allocation sinking forgets escaped nodes when structure changes
https://bugs.webkit.org/show_bug.cgi?id=216214
<rdar://problem/68518460>
Reviewed by Saam Barati.
Consider the following program:
bb0:
a: NewObject
b: CreateActivation()
_: Branch(bb2, bb1)
bb1:
_: PutByOffset(a, 'x', 42)
_: PutStrucute(a, {x: 0})
_: Branch(bb2, bb1)
bb2:
_: CheckStructure(a, {x: 0})
_: PutClosureVar(b, 0, Kill:a)
_: Branch(bb3, bb2)
bb3:
c: GetClosureVar(b, 0)
_: PutByOffset(global, 'y', c)
_: Return
Due to the order we visit the program, we'll visit bb2 before bb1. The first time we visit bb2, heapAtHead will be:
#@a: ObjectAllocation({})
#@b: ActivationAllocation()
@a => #@a
@b => #@b
Now CheckStructure would always fail, so it will escape @a and heapAtTail will be:
#@a: EscapedAllocation()
#@b: ActivationAllocation()
@a => #@a
@b => #@b
And after pruning:
#@b: ActivationAllocation()
@b => #@b
Now, we'll visit bb3 and then bb1. When we visit bb1 we'll set the structure {x: 0} for the #@a and eventually visit bb2 again. This time around CheckStructure will no longer escape @a, since the allocation has the right structure, and heapAtTail will be:
#@a: ObjectAllocation({x: 0})
#@b: ActivationAllocation(0: #@a)
@b => #@b
However, we now have to merge into bb3, which has heapAtHead:
#@b: ActivationAllocation()
@b => #@b
Since we can't add the extra field to the activation, we'll end up escaping @a at the edge and therefore pruning #@b, which will leave the heap for bb3 unchanged.
That's a problem, since PutClosureVar didn't see the escaped object, but GetClosureVar thinks it's escaped. The materialization for @a will be placed after the
PutClosureVar, at end of bb2, when the node is already dead. When computing the SSA defs, the PutByOffset at bb3 will then see @a (which at this point will be a
PhantomNewObject) instead of its materialization.
The issue happens because we don't allow allocations to add extra fields while merging, but we do allow adding new structures. This results in different decisions
being made about what escapes in CheckStructure and MultiGetByOffset. To avoid this problem, we track two sets of structures: structures and structuresForMaterialization.
The first is used for checks and should never grow while the second is used for materialization and is allowed to grow.
* dfg/DFGObjectAllocationSinkingPhase.cpp:
2020-09-15 Saam Barati <sbarati@apple.com>
CustomFunctionEquivalence PropertyCondition needs to check if the structure has the property
https://bugs.webkit.org/show_bug.cgi?id=216575
<rdar://problem/68286930>
Reviewed by Yusuke Suzuki.
The CustomFunctionEquivalence PropertyCondition would only return false to
isStillValidAssumingImpurePropertyWatchpoint if the Structure's static
property table was reified or if the static property table did not contain the
property. However, this missed the obvious case of where we store to this
property in normal object storage without reifying the static property table.
The fix here is simple: we first check if the Structure's property table
has this property, and if so, return false.
This patch also renames CustomFunctionEquivalence to HasStaticProperty to
better capture what we're doing.
* bytecode/ObjectPropertyCondition.h:
(JSC::ObjectPropertyCondition::hasStaticProperty):
(JSC::ObjectPropertyCondition::customFunctionEquivalence): Deleted.
* bytecode/ObjectPropertyConditionSet.cpp:
(JSC::ObjectPropertyConditionSet::hasOneSlotBaseCondition const):
(JSC::ObjectPropertyConditionSet::slotBaseCondition const):
(JSC::generateConditionsForPrototypePropertyHitCustom):
* bytecode/PropertyCondition.cpp:
(JSC::PropertyCondition::dumpInContext const):
(JSC::PropertyCondition::isStillValidAssumingImpurePropertyWatchpoint const):
(JSC::PropertyCondition::validityRequiresImpurePropertyWatchpoint const):
(JSC::PropertyCondition::isStillValid const):
(JSC::PropertyCondition::isWatchableWhenValid const):
(WTF::printInternal):
* bytecode/PropertyCondition.h:
(JSC::PropertyCondition::hasStaticProperty):
(JSC::PropertyCondition::hash const):
(JSC::PropertyCondition::operator== const):
(JSC::PropertyCondition::customFunctionEquivalence): Deleted.
* tools/JSDollarVM.cpp:
(JSC::functionCreateStaticCustomValue):
(JSC::JSDollarVM::finishCreation):
2020-09-15 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Apply Intl.DateTimeFormat hour-cycle correctly when timeStyle is used
https://bugs.webkit.org/show_bug.cgi?id=216521
Reviewed by Ross Kirsling.
When specifying timeStyle in Intl.DateTimeFormat, we need to check that the generated format also follows to the hourCycle / hour12 options
specified in the constructor. Because dayPeriod can be included automatically, just replacing symbols after generating a pattern can dump strange result.
For example, the generated one is something like "02:12:47 PM Coordinated Universal Time". And we adjust the pattern to make it "14:12:47 PM Coordinated Universal Time"
when hourCycle H23 / H24 is specified. But this looks strange since dayPeriod "PM" should not exist when using H23 / H24.
In this patch, we revise our hour-cycle handling in Intl.DateTimeFormat. We align our behavior to SpiderMonkey's one[1] rather than the spec's one: when hour12 is specified,
we will just use 'H' or 'h' skeleton and do not enforce hour-cycle after generating pattern in hour12 case. If hour12 is not specified, then we use 'h' or 'H' skeleton
symbols based on hour-cycle, and later we modify the pattern based on hour-cycle. If both are not offered, we use 'j' which allows ICU to pick preferable one.
This is slightly different behavior to the spec (hcDefault etc.) but the spec's behavior can cause a bit surprising result[2,3], and SpiderMonkey like behavior will be
integrated into the spec eventually[4].
[1]: https://github.com/tc39/ecma402/issues/402#issuecomment-623628320
[2]: https://github.com/tc39/ecma402/issues/402
[3]: https://bugs.chromium.org/p/chromium/issues/detail?id=1045791
[4]: https://github.com/tc39/ecma402/pull/436
* runtime/IntlDateTimeFormat.cpp:
(JSC::IntlDateTimeFormat::setFormatsFromPattern):
(JSC::IntlDateTimeFormat::parseHourCycle):
(JSC::IntlDateTimeFormat::hourCycleFromPattern):
(JSC::IntlDateTimeFormat::replaceHourCycleInSkeleton):
(JSC::IntlDateTimeFormat::replaceHourCycleInPattern):
(JSC::IntlDateTimeFormat::initializeDateTimeFormat):
(JSC::IntlDateTimeFormat::hourCycleString):
(JSC::IntlDateTimeFormat::resolvedOptions const):
(JSC::IntlDateTimeFormat::createDateIntervalFormatIfNecessary):
* runtime/IntlDateTimeFormat.h:
2020-09-14 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Intl.Collator should take collation option
https://bugs.webkit.org/show_bug.cgi?id=216529
Reviewed by Ross Kirsling.
This patch adds "collation" option to Intl.Collator. We are already getting consensus[1], and will be integrated into the spec.
Previously, passing "collation" is only available through "-u-co-" unicode extension in the passed locale. The proposal exposes
collation option as an option to Intl.Collator so that we can set it easily.
"collation" is used only when "usage" is "sort". "search" usage will filter out collation options since "search" itself is one of
the "collation" option.
[1]: https://github.com/tc39/ecma402/pull/459
* runtime/IntlCollator.cpp:
(JSC::IntlCollator::sortLocaleData):
(JSC::IntlCollator::initializeCollator):
2020-09-15 Joonghun Park <jh718.park@samsung.com>
Unreviewed. Remove the build warning below since r228533.
warning: ‘%40s’ directive argument is null [-Wformat-overflow=]
Since gcc which has version >= 9 is stricter about passing null string
pointers to printf-like functions, add null string pointer check
to fix the warning proactively.
* jsc.cpp:
(runJSC):
2020-09-14 Keith Miller <keith_miller@apple.com>
BytecodeParser should GetLocal op_ret's value even if it's unused by the caller
https://bugs.webkit.org/show_bug.cgi?id=216506
Reviewed by Mark Lam.
We have to unconditionally GetLocal operands each bytecode claims to use
regardless of true liveness. This is important to keep OSRAvailability simple.
However, op_ret would only GetLocal the return value if we knew the value
was going to be used by an inline caller.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
2020-09-14 Alexey Shvayka <shvaikalesh@gmail.com>
Proxy's "ownKeys" trap result should not be sorted
https://bugs.webkit.org/show_bug.cgi?id=216227
Reviewed by Yusuke Suzuki.
Given that we can't know whether ownPropertyKeys() received property names from
userland Proxy's "ownKeys" trap, this patch moves symbols after strings sorting [1]
to Structure::getPropertyNamesFromStructure(), aligning observed property order
(via Proxy's "getOwnPropertyDescriptor" trap) with V8 and SpiderMonkey.
Also, removes sorting logic duplication in objectConstructorAssign().
This change is neutral on provided Reflect.ownKeys microbenchmark. Although property
name collection besides PropertyNameMode::StringsAndSymbols cases is unaffected,
Object.{keys,getOwnPropertySymbols} microbenchmarks regress by 6-12% due to
increased Structure::getPropertyNamesFromStructure() code size.
[1]: https://tc39.es/ecma262/#sec-ordinaryownpropertykeys (steps 3-4)
* runtime/ObjectConstructor.cpp:
(JSC::objectConstructorAssign):
(JSC::ownPropertyKeys):
* runtime/Structure.cpp:
(JSC::Structure::getPropertyNamesFromStructure):
2020-09-14 Alexey Shvayka <shvaikalesh@gmail.com>
ArraySetLength should coerce [[Value]] before descriptor validation
https://bugs.webkit.org/show_bug.cgi?id=158791
Reviewed by Darin Adler.
This patch:
1. Moves [[Value]] coercion before descriptor validation as per spec [1],
which fixes ASSERT() failure and aligns JSC with V8 & SpiderMonkey.
2. Prevents JSArray::setLengthWithArrayStorage() from throwing if the length
is unchanged, even if it's read-only [2].
3. Refactors JSArray::defineOwnProperty() leveraging #2 to always perform
setLength(), which greatly reduces the number of checks, branches,
and setLengthWritable() calls.
Following the ArraySetLength spec steps precisely [1] would result in
more difficult-to-follow code because descriptor validation [2] is inlined
and [[Delete]] failures are handled in setLength().
This change is performance-neutral as it doesn't affect JSArray::put(),
which was vetted to be spec-correct and is covered by test262 suite.
[1]: https://tc39.es/ecma262/#sec-arraysetlength (steps 3-4)
[2]: https://tc39.es/ecma262/#sec-validateandapplypropertydescriptor (step 7.a.ii)
* runtime/JSArray.cpp:
(JSC::JSArray::defineOwnProperty):
(JSC::JSArray::setLengthWithArrayStorage):
2020-09-14 Saam Barati <sbarati@apple.com>
Remove bogus asserts in FTLLower that assume programs are compiled with sensible speculations
https://bugs.webkit.org/show_bug.cgi?id=216485
<rdar://problem/68562804>
Reviewed by Keith Miller.
We had an assert inside lowCell that if a value was not part of the JSValue
hashmap of values, then the type must not conform to being a cell. However,
consider a program like this:
```
x = ArithAdd(i32, i32) <-- x is an i32 here
if (b) {
Check(Cell:@x)
ArrayifyToStructure(@x, thingy)
}
<-- HERE
```
@x will live in FTLLower's i32 hashmap, but because of the AI rule for
ArrayifyToStructure, it will also have SpecCell in its type. This is totally
valid, and asserting that this isn't possible is wrong. (Obviously the above
speculation is stupid, as we will always exit at the Check, but it's valid IR.)
This patch removes this assertion from lowCell, and removes similar assertions
from other low* functions.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::lowInt32):
(JSC::FTL::DFG::LowerDFGToB3::lowInt52):
(JSC::FTL::DFG::LowerDFGToB3::lowCell):
(JSC::FTL::DFG::LowerDFGToB3::lowBoolean):
(JSC::FTL::DFG::LowerDFGToB3::lowDouble):
2020-09-14 Alexey Shvayka <shvaikalesh@gmail.com>
Make a few built-in methods throw if called as top-level functions
https://bugs.webkit.org/show_bug.cgi?id=216467
Reviewed by Darin Adler.
Non-strict userland functions substitute undefined & null `this` values
with the global object [1], while built-in functions do not [2].
This patch adds 5 missing toThis(globalObject, ECMAMode::strict()) calls,
preventing built-in methods from being called as top-level functions:
```
let {toString} = Error.prototype;
toString(); // now throws TypeError
```
Aligns JSC with V8 and SpiderMonkey.
This change is performance-neutral due to DFG inlining of OpToThis.
All other callFrame->thisValue() usages were vetted to be spec-correct.
[1]: https://tc39.es/ecma262/#sec-ordinarycallbindthis (step 6.a.iii)
[2]: https://tc39.es/ecma262/#sec-built-in-function-objects-call-thisargument-argumentslist (step 10)
* runtime/ArrayPrototype.cpp:
(JSC::createArrayIteratorObject):
* runtime/DatePrototype.cpp:
(JSC::dateProtoFuncToPrimitiveSymbol):
(JSC::dateProtoFuncToJSON):
* runtime/ErrorPrototype.cpp:
(JSC::errorProtoFuncToString):
* runtime/RegExpPrototype.cpp:
(JSC::regExpProtoFuncToString):
2020-09-14 Devin Rousso <drousso@apple.com>
Web Inspector: REGRESSION(r266885): dyld: Symbol not found: __ZN9Inspector17BackendDispatcher12sendResponseElON3WTF6RefPtrINS1_8JSONImpl6ObjectENS1_13DumbPtrTraitsIS4_EEEEb
https://bugs.webkit.org/show_bug.cgi?id=216486
Reviewed by Joseph Pecoraro.
* inspector/InspectorBackendDispatcher.h:
* inspector/InspectorBackendDispatcher.cpp:
(Inspector::BackendDispatcher::sendResponse):
Add back overloads removed in r266885 so that the symbols exist.
2020-09-14 Saam Barati <sbarati@apple.com>
Don't assume byte code operands are uint32 JSValues
https://bugs.webkit.org/show_bug.cgi?id=216386
Reviewed by Yusuke Suzuki.
The slow path for enumerator_generic_pname was assuming that its input index operand
would always be a UInt32 JSValue boxed as int32. However, this assumption isn't true
because that value can have double format in the DFG, and remain in that format when
we exit from the DFG to baseline/LLInt code.
This was found via the widening number fuzzing agent.
I also audited two more places that seem like they suffer from the same issue,
and also switched them to using the asUInt32AsAnyInt function:
- enumerator_structure_pname
- create_rest
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
2020-09-11 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Canonicalize "true" unicode extension type value to ""
https://bugs.webkit.org/show_bug.cgi?id=216224
Reviewed by Ross Kirsling.
Unicode Technical Standard #35 defines that unicode extension type's "true" should be converged to "".
This patch implements it by extracting unicode extension subtags and replacing "true" to "".
* runtime/IntlLocale.cpp:
(JSC::LocaleIDBuilder::toCanonical):
(JSC::IntlLocale::keywordValue const):
(JSC::IntlLocale::calendar):
(JSC::IntlLocale::caseFirst):
(JSC::IntlLocale::collation):
(JSC::IntlLocale::hourCycle):
(JSC::IntlLocale::numberingSystem):
(JSC::IntlLocale::numeric):
* runtime/IntlLocale.h:
* runtime/IntlLocalePrototype.cpp:
(JSC::IntlLocalePrototypeGetterCalendar):
(JSC::IntlLocalePrototypeGetterCaseFirst):
(JSC::IntlLocalePrototypeGetterCollation):
(JSC::IntlLocalePrototypeGetterHourCycle):
(JSC::IntlLocalePrototypeGetterNumberingSystem):
* runtime/IntlObject.cpp:
(JSC::unicodeExtensionSubTags):
(JSC::canonicalizeUnicodeExtensionsAfterICULocaleCanonicalization):
(JSC::languageTagForLocaleID):
(JSC::resolveLocale):
* runtime/IntlObject.h:
* runtime/IntlObjectInlines.h:
(JSC::computeTwoCharacters16Code):
* runtime/StringPrototype.cpp:
(JSC::computeTwoCharacters16Code): Deleted.
2020-09-11 Yusuke Suzuki <yusukesuzuki@slowstart.org>
[JSC] attribute-change transition should not pin Structure
https://bugs.webkit.org/show_bug.cgi?id=215528
Reviewed by Saam Barati.
This patch avoids using pin in attribute-change transition. To achieve this, attribute-change transition is now fully supported
transition chain in forEachPropertyConcurrently etc.: we can retrieve properties with changed attributes correctly via traversing
transition chain. And we also support attribute-change transition in materializePropertyTable, so we do not need to pin structure.
The design largely mimics existing removePropertyTransition and addPropertyTransition. This patch also adds `hasBeenDictionary()`
check before adding structure to the transition so that we can avoid adding unnecessary structure entry to the transition table.
* bytecode/AccessCase.cpp:
(JSC::AccessCase::generateImpl):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compilePutStructure):
* jit/Repatch.cpp:
(JSC::tryCacheDeleteBy):
* runtime/Structure.cpp:
(JSC::Structure::materializePropertyTable):
(JSC::Structure::addPropertyTransitionToExistingStructureImpl):
(JSC::Structure::addPropertyTransition):
(JSC::Structure::addNewPropertyTransition):
(JSC::Structure::removePropertyTransitionFromExistingStructureImpl):
(JSC::Structure::removeNewPropertyTransition):
(JSC::Structure::attributeChangeTransitionToExistingStructure):
(JSC::Structure::attributeChangeTransition):
(JSC::Structure::nonPropertyTransitionSlow):
(JSC::Structure::attributeChange):
* runtime/Structure.h:
* runtime/StructureInlines.h:
(JSC::Structure::forEachPropertyConcurrently):
(JSC::Structure::attributeChange):
(JSC::Structure::attributeChangeWithoutTransition):
* tools/JSDollarVM.cpp:
(JSC::JSDollarVMHelper::functionGetStructureTransitionList):
2020-09-10 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] customGetterSetterFunctionCall should have proper exception checking
https://bugs.webkit.org/show_bug.cgi?id=216391
<rdar://problem/68631643>
Reviewed by Mark Lam.
Add appropriate exception checking to customGetterSetterFunctionCall.
* runtime/JSCustomGetterSetterFunction.cpp:
(JSC::JSCustomGetterSetterFunction::customGetterSetterFunctionCall):
2020-09-10 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Add exception checks to JSCallbackObject
https://bugs.webkit.org/show_bug.cgi?id=216384
<rdar://problem/68632190>
Reviewed by Saam Barati.
This patch adds necessary exception checks to JSCallbackObject to suppress exception verifier crash in Debug build.
* API/JSCallbackObjectFunctions.h:
(JSC::JSCallbackObject<Parent>::getOwnPropertySlot):
(JSC::JSCallbackObject<Parent>::defaultValue):
(JSC::JSCallbackObject<Parent>::put):
(JSC::JSCallbackObject<Parent>::putByIndex):
(JSC::JSCallbackObject<Parent>::deleteProperty):
(JSC::JSCallbackObject<Parent>::staticFunctionGetter):
2020-09-10 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] agent start function should move isolated copy of source
https://bugs.webkit.org/show_bug.cgi?id=216383
<rdar://problem/66371008>
Reviewed by Saam Barati.
We are calling `isolatedCopy()` and setting it to variable in caller thread. And we are copying it to the thread.
This means that ref-count will happen in caller thread and callee thread, this is wrong.
We should pass isolatedCopy string directly to the callee thread.
* jsc.cpp:
(functionDollarAgentStart):
2020-09-10 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] unshift / shift should take structure lock
https://bugs.webkit.org/show_bug.cgi?id=216378
<rdar://problem/68496096>
Reviewed by Mark Lam.
When unshifting / shifting butterfly, we need to move property storage values too.
If property storage values are moved while concurrent JIT compiler is accessing it, it could include garbage value.
For example, concurrent JIT compiler is accessing [2] property storage.
1 2 3
[ JSValue ][ JSValue ][ Header ]
But unshift moved it like this.
1 2 3
[ JSValue ][ JSValue ][ Header ]
Since butterfly pointer held by JSObject is not updated yet, concurrent JIT compiler will read [ Header ] as JSValue and crash.
In this patch, we take structure lock when shifting existing butterfly since this affect on property storage. Since JSObject::getDirectConcurrently
takes a structure lock, this locking prevents concurrent compilers from getting an invalid value.
* runtime/JSArray.cpp:
(JSC::JSArray::unshiftCountSlowCase):
(JSC::JSArray::shiftCountWithArrayStorage):
(JSC::JSArray::unshiftCountWithArrayStorage):
2020-09-10 Joonghun Park <jh718.park@samsung.com>
Unreviewed. Remove the build warning below since r266885.
warning: redundant move in return statement [-Wredundant-move]
Because return statement already returns rvalue reference,
we don't need WTFMove at return.
* inspector/agents/InspectorRuntimeAgent.cpp:
(Inspector::InspectorRuntimeAgent::getRuntimeTypesForVariablesAtOffsets):
(Inspector::InspectorRuntimeAgent::getBasicBlocks):
2020-09-10 Alexey Shvayka <shvaikalesh@gmail.com>
Promise.prototype.finally should perform PromiseResolve
https://bugs.webkit.org/show_bug.cgi?id=176006
Reviewed by Yusuke Suzuki.
This patch extracts @promiseResolve global private function and utilizes it in
Promise.prototype.finally then/catch functions [1] to avoid creating an extra
Promise Capability. Aligns JSC with V8 and SpiderMonkey.
[1]: https://tc39.es/ecma262/#sec-thenfinallyfunctions (step 7)
* builtins/PromiseConstructor.js:
(resolve):
* builtins/PromiseOperations.js:
(globalPrivate.promiseResolve):
* builtins/PromisePrototype.js:
(globalPrivate.getThenFinally):
(globalPrivate.getCatchFinally):
2020-09-10 Devin Rousso <drousso@apple.com>
Web Inspector: modernize generated backend protocol code
https://bugs.webkit.org/show_bug.cgi?id=216302
<rdar://problem/68547649>
Reviewed by Brian Burg.
Previously, the inspector protocol was expressed in code in a somewhat confusing way:
- the error string was the first argument
- required parameters were `T` or `const T&`
- optional parameters were `const T*`
- enum parameters were the underlying type requiring the backend dispatcher handler to
process it instead of it being preprocessed
- required returns were `T&`
- optional returns were `T*`
This doesn't really make for easy/obvious reading of code since the order of arguments is
not weird (e.g. error string first), and that there are references/pointers to primitive
types.
This patch cleans up the generated inspector protocol code to be:
- required parameters are `T` or `Ref<T>&&`
- optional parameters are `Optional<T>&&` or `RefPtr<T>&&`
- enum parameters are preprocessed and passed to the backend dispatcher handler if valid
- synchronous commands return `Expected<X, ErrorString>` using the same types/rules above
where `X` is either a single return or a `std::tuple` of multiple returns
The one exception to the above is `String`, which is already a tri-state of `nullString()`,
`emptyString()`, and something set, so there's no need to use `Optional<String>`.
Also use `Protocol` objects/`typedefs` wherever possible to further relate the protocol
JSON and the actual backend dispatcher handler implementation.
* inspector/scripts/codegen/generator.py:
(Generator.generate_includes_from_entries):
* inspector/scripts/codegen/cpp_generator_templates.py:
* inspector/scripts/codegen/cpp_generator.py:
(CppGenerator.helpers_namespace):
(CppGenerator.cpp_getter_method_for_type):
(CppGenerator.cpp_setter_method_for_type):
(CppGenerator.cpp_protocol_type_for_type):
(CppGenerator.cpp_type_for_type_member_argument): Added.
(CppGenerator.cpp_type_for_command_parameter): Added.
(CppGenerator.cpp_type_for_command_return_declaration): Added.
(CppGenerator.cpp_type_for_command_return_argument): Added.
(CppGenerator.cpp_type_for_event_parameter): Added.
(CppGenerator.cpp_type_for_enum): Added.
(CppGenerator.should_move_argument): Added.
(CppGenerator.should_release_argument): Added.
(CppGenerator.should_dereference_argument): Added.
(CppGenerator.cpp_protocol_type_for_type_member): Deleted.
(CppGenerator.cpp_type_for_unchecked_formal_in_parameter): Deleted.
(CppGenerator.cpp_type_for_checked_formal_event_parameter): Deleted.
(CppGenerator.cpp_type_for_type_member): Deleted.
(CppGenerator.cpp_type_for_type_with_name): Deleted.
(CppGenerator.cpp_type_for_formal_out_parameter): Deleted.
(CppGenerator.cpp_type_for_formal_async_parameter): Deleted.
(CppGenerator.cpp_type_for_stack_in_parameter): Deleted.
(CppGenerator.cpp_type_for_stack_out_parameter): Deleted.
(CppGenerator.cpp_assertion_method_for_type_member): Deleted.
(CppGenerator.cpp_assertion_method_for_type_member.assertion_method_for_type): Deleted.
(CppGenerator.should_use_wrapper_for_return_type): Deleted.
(CppGenerator.should_use_references_for_type): Deleted.
(CppGenerator.should_pass_by_copy_for_return_type): Deleted.
* inspector/scripts/codegen/generate_cpp_alternate_backend_dispatcher_header.py:
(CppAlternateBackendDispatcherHeaderGenerator._generate_secondary_header_includes):
(CppAlternateBackendDispatcherHeaderGenerator._generate_handler_declaration_for_command):
* inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py:
(CppBackendDispatcherHeaderGenerator.generate_output):
(CppBackendDispatcherHeaderGenerator._generate_secondary_header_includes):
(CppBackendDispatcherHeaderGenerator._generate_handler_declarations_for_domain):
(CppBackendDispatcherHeaderGenerator._generate_handler_declaration_for_command):
(CppBackendDispatcherHeaderGenerator._generate_async_handler_declaration_for_command):
(CppBackendDispatcherHeaderGenerator._generate_dispatcher_declaration_for_command):
(CppBackendDispatcherHeaderGenerator._generate_anonymous_enum_for_parameter): Deleted.
* inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
(CppBackendDispatcherImplementationGenerator._generate_secondary_header_includes):
(CppBackendDispatcherImplementationGenerator._generate_small_dispatcher_switch_implementation_for_domain):
(CppBackendDispatcherImplementationGenerator._generate_async_dispatcher_class_for_domain):
(CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command):
* inspector/scripts/codegen/generate_cpp_frontend_dispatcher_header.py:
(CppFrontendDispatcherHeaderGenerator._generate_secondary_header_includes):
(CppFrontendDispatcherHeaderGenerator._generate_dispatcher_declaration_for_event):
* inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py:
(CppFrontendDispatcherImplementationGenerator._generate_secondary_header_includes):
(CppFrontendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_event):
* inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
(CppProtocolTypesHeaderGenerator._generate_secondary_header_includes):
* inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py:
(CppProtocolTypesImplementationGenerator._generate_secondary_header_includes):
(CppProtocolTypesImplementationGenerator._generate_enum_conversion_methods_for_domain):
(CppProtocolTypesImplementationGenerator._generate_open_field_names):
(CppProtocolTypesImplementationGenerator._generate_assertion_for_enum):
* inspector/scripts/codegen/generate_objc_backend_dispatcher_header.py:
(ObjCBackendDispatcherHeaderGenerator._generate_objc_handler_declaration_for_command):
* inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
(ObjCBackendDispatcherImplementationGenerator._generate_handler_implementation_for_command):
(ObjCBackendDispatcherImplementationGenerator._generate_success_block_for_command):
(ObjCBackendDispatcherImplementationGenerator._generate_success_block_for_command.and):
(ObjCBackendDispatcherImplementationGenerator._generate_conversions_for_command.in_param_expression):
(ObjCBackendDispatcherImplementationGenerator._generate_conversions_for_command):
(ObjCBackendDispatcherImplementationGenerator._generate_invocation_for_command):
* inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
(ObjCFrontendDispatcherImplementationGenerator._generate_event):
(ObjCFrontendDispatcherImplementationGenerator._generate_event_out_parameters):
* inspector/scripts/codegen/objc_generator_templates.py:
* inspector/scripts/codegen/objc_generator.py:
(ObjCGenerator.protocol_type_for_type):
(ObjCGenerator.objc_type_for_param_internal):
(ObjCGenerator.objc_protocol_import_expression_for_parameter):
* inspector/protocol/Page.json:
Now that enums are processed before being passed to backend dispacher handlers, the
`appearance` parameter of `Page.setForcedAppearance` must be marked `optional` as
there's no way for it to accept an empty string, as that's not possible for an enum.
* inspector/agents/InspectorAgent.h:
* inspector/agents/InspectorAgent.cpp:
* inspector/agents/InspectorAuditAgent.h:
* inspector/agents/InspectorAuditAgent.cpp:
* inspector/agents/InspectorConsoleAgent.h:
* inspector/agents/InspectorConsoleAgent.cpp:
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
* inspector/agents/InspectorHeapAgent.h:
* inspector/agents/InspectorHeapAgent.cpp:
* inspector/agents/InspectorRuntimeAgent.h:
* inspector/agents/InspectorRuntimeAgent.cpp:
* inspector/agents/InspectorScriptProfilerAgent.h:
* inspector/agents/InspectorScriptProfilerAgent.cpp:
* inspector/agents/InspectorTargetAgent.h:
* inspector/agents/InspectorTargetAgent.cpp:
* inspector/agents/JSGlobalObjectAuditAgent.h:
* inspector/agents/JSGlobalObjectAuditAgent.cpp:
* inspector/agents/JSGlobalObjectDebuggerAgent.h:
* inspector/agents/JSGlobalObjectDebuggerAgent.cpp:
* inspector/agents/JSGlobalObjectRuntimeAgent.h:
* inspector/agents/JSGlobalObjectRuntimeAgent.cpp:
* inspector/JSGlobalObjectConsoleClient.cpp:
* inspector/JSGlobalObjectInspectorController.cpp:
Elided backend dispatcher handler changes describe above.
* bindings/ScriptValue.cpp:
(Inspector::jsToInspectorValue):
* inspector/AsyncStackTrace.h:
* inspector/AsyncStackTrace.cpp:
(Inspector::AsyncStackTrace::buildInspectorObject const):
* inspector/ConsoleMessage.cpp:
(Inspector::ConsoleMessage::addToFrontend):
* inspector/InjectedScriptBase.h:
* inspector/InjectedScriptBase.cpp:
(Inspector::InjectedScriptBase::makeEvalCall):
(Inspector::InjectedScriptBase::checkCallResult):
(Inspector::InjectedScriptBase::checkAsyncCallResult):
* inspector/InjectedScript.h:
* inspector/InjectedScript.cpp:
(Inspector::InjectedScript::execute):
(Inspector::InjectedScript::evaluate):
(Inspector::InjectedScript::callFunctionOn):
(Inspector::InjectedScript::evaluateOnCallFrame):
(Inspector::InjectedScript::getFunctionDetails):
(Inspector::InjectedScript::functionDetails):
(Inspector::InjectedScript::getPreview):
(Inspector::InjectedScript::getProperties):
(Inspector::InjectedScript::getDisplayableProperties):
(Inspector::InjectedScript::getInternalProperties):
(Inspector::InjectedScript::getCollectionEntries):
(Inspector::InjectedScript::saveResult):
(Inspector::InjectedScript::wrapCallFrames const):
(Inspector::InjectedScript::wrapObject const):
(Inspector::InjectedScript::wrapJSONString const):
(Inspector::InjectedScript::wrapTable const):
(Inspector::InjectedScript::previewValue const):
* inspector/InjectedScriptManager.cpp:
(Inspector::InjectedScriptManager::injectedScriptForObjectId):
* inspector/InspectorBackendDispatcher.h:
* inspector/InspectorBackendDispatcher.cpp:
(Inspector::BackendDispatcher::CallbackBase::sendSuccess):
(Inspector::BackendDispatcher::dispatch):
(Inspector::BackendDispatcher::sendResponse):
(Inspector::BackendDispatcher::getPropertyValue):
(Inspector::BackendDispatcher::getBoolean):
(Inspector::BackendDispatcher::getInteger):
(Inspector::BackendDispatcher::getDouble):
(Inspector::BackendDispatcher::getString):
(Inspector::BackendDispatcher::getValue):
(Inspector::BackendDispatcher::getObject):
(Inspector::BackendDispatcher::getArray):
(Inspector::castToInteger): Deleted.
(Inspector::castToNumber): Deleted.
* inspector/InspectorProtocolTypes.h:
(Inspector::Protocol::BindingTraits<JSON::ArrayOf<T>>::runtimeCast):
(Inspector::Protocol::BindingTraits<JSON::ArrayOf<T>>::assertValueHasExpectedType):
* inspector/remote/socket/RemoteInspectorConnectionClient.cpp:
(Inspector::RemoteInspectorConnectionClient::extractEvent):
* inspector/remote/socket/RemoteInspectorSocket.cpp:
(Inspector::RemoteInspector::pushListingsNow):
* runtime/TypeSet.cpp:
(JSC::StructureShape::inspectorRepresentation):
`JSON` classes now use `Ref&&` wherever possible and `Optional` instead of an out parameter
for `get*`/`as*` so that values can be more easily manipulated and can be confidently known
to exist.
* inspector/scripts/tests/enum-values.json:
* inspector/scripts/tests/expected/command-targetType-matching-domain-debuggableType.json-result:
* inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/expected/definitions-with-mac-platform.json-result:
* inspector/scripts/tests/expected/domain-debuggableTypes.json-result:
* inspector/scripts/tests/expected/domain-targetType-matching-domain-debuggableType.json-result:
* inspector/scripts/tests/expected/domain-targetTypes.json-result:
* inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
* inspector/scripts/tests/expected/enum-values.json-result:
* inspector/scripts/tests/expected/event-targetType-matching-domain-debuggableType.json-result:
* inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
* inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result:
* inspector/scripts/tests/expected/should-strip-comments.json-result:
* inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
* inspector/scripts/tests/expected/type-declaration-array-type.json-result:
* inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
* inspector/scripts/tests/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
* inspector/scripts/tests/expected/type-with-open-parameters.json-result:
* inspector/scripts/tests/expected/version.json-result:
2020-09-09 Saam Barati <sbarati@apple.com>
OutOfBoundsSaneChain operations should use their own heap locations
https://bugs.webkit.org/show_bug.cgi?id=216328
<rdar://problem/68568039>
Reviewed by Keith Miller.
There is code in local CSE that does some basic bounds check elimination
for PutByVal. It does this analysis by seeing if a particular heap location
is already defined, and if so, it eliminates the bounds check for the
PutByVal. This doesn't work for OutOfBoundsSaneChain for the obvious reason
that these GetByVals are not proven to be in bounds. So GetByVal's in the
OutOfBoundsSaneChain mode reusing non OutOfBoundsSaneChain heap locations
can lead to a bug where we mistakenly remove a bounds check. The fix is to
have all OutOfBoundsSaneChain operations use distinct heaps, and for CSE to
not query those heaps.
* dfg/DFGArrayMode.h:
(JSC::DFG::ArrayMode::isAnySaneChain const): Deleted.
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGHeapLocation.cpp:
(WTF::printInternal):
* dfg/DFGHeapLocation.h:
2020-09-09 Keith Miller <keith_miller@apple.com>
BigInt should PACCage its data pointer
https://bugs.webkit.org/show_bug.cgi?id=216319
Reviewed by Yusuke Suzuki.
* runtime/JSBigInt.h:
2020-09-09 Alexey Shvayka <shvaikalesh@gmail.com>
Don't emitDirectBinding() if there is a [...rest] element binding
https://bugs.webkit.org/show_bug.cgi?id=216228
Reviewed by Darin Adler.
emitDirectBinding() is up for removal due to not respecting overriden or removed
Array.prototype[Symbol.iterator]. However, dropping it slows down popular swap pattern
`[a, b] = [b, a]` by 40% with DFG/FTL, and by a factor of 6 with baseline JIT only.
Until we figure out the best way to preserve common case performance, this patch
prevents `let [...rest] = [1]` from ending up as a number instead of an array,
aligning JSC with V8 and SpiderMonkey.
* bytecompiler/NodesCodegen.cpp:
(JSC::ArrayPatternNode::emitDirectBinding):
2020-09-08 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] returnEarlyFromInfiniteLoopsForFuzzing should return object
https://bugs.webkit.org/show_bug.cgi?id=216289
<rdar://problem/68496533>
Reviewed by Saam Barati.
When returning early with returnEarlyFromInfiniteLoopsForFuzzing, we are returning with undefined.
But this is wrong when the callee is constructor since constructor is strongly assumed that it returns an object.
We should return some object from returnEarlyFromInfiniteLoopsForFuzzing. In this patch, we return global object
associated to this callee instead of undefined
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::~CodeBlock):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileLoopHint):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_loop_hint):
* llint/LowLevelInterpreter64.asm:
2020-09-08 Saam Barati <sbarati@apple.com>
re-enable TCSM on all OSs
https://bugs.webkit.org/show_bug.cgi?id=216281
Reviewed by Tadeu Zagallo.
* runtime/Options.cpp:
(JSC::defaultTCSMValue):
2020-09-08 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Special property caching should check Structure's cacheability
https://bugs.webkit.org/show_bug.cgi?id=216222
Reviewed by Saam Barati.
While StructureRareData::cacheSpecialPropertySlow caches properties, the way it takes is incomplete.
It is not checking Structure's cacheability. We were caching miss condition even if structure is !propertyAccessesAreCacheableForAbsence.
We should perform the same check done in IC case. Strictly speaking, we can cache value for uncacheable-dictionary because we are setting
property change watchpoint (which will fire). But it sounds not so profitable if this structure is uncacheable.
* runtime/JSObject.cpp:
(JSC::JSObject::convertToUncacheableDictionary):
* runtime/JSObject.h:
* runtime/StructureRareData.cpp:
(JSC::StructureRareData::cacheSpecialPropertySlow):
* tools/JSDollarVM.cpp:
(JSC::functionToUncacheableDictionary):
(JSC::JSDollarVM::finishCreation):
2020-09-07 Joonghun Park <jh718.park@samsung.com>
Unreviewed. Remove the build warning below since r266567.
warning: parameter ‘hint’ set but not used [-Wunused-but-set-parameter]
* runtime/JSObject.cpp:
(JSC::callToPrimitiveFunction):
2020-09-06 Darin Adler <darin@apple.com>
TextCodec refinements
https://bugs.webkit.org/show_bug.cgi?id=216219
Reviewed by Sam Weinig.
* parser/Lexer.h:
(JSC::Lexer<UChar>::isWhiteSpace): Use byteOrderMark constant.
2020-09-05 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, suppress exception checking after unwrapForOldFunctions
https://bugs.webkit.org/show_bug.cgi?id=216193
* runtime/IntlNumberFormatPrototype.cpp:
(JSC::IntlNumberFormatPrototypeGetterFormat):
(JSC::IntlNumberFormatPrototypeFuncResolvedOptions):
2020-09-05 Devin Rousso <drousso@apple.com>
Web Inspector: allow DOM breakpoints to be configured
https://bugs.webkit.org/show_bug.cgi?id=215795
Reviewed by Brian Burg.
* inspector/protocol/DOMDebugger.json:
Add an `options` parameter to `DOMDebugger.setDOMBreakpoint` to allow configuration.
2020-09-04 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Align legacy Intl constructor behavior to spec
https://bugs.webkit.org/show_bug.cgi?id=216193
Reviewed by Darin Adler.
Legacy Intl constructors (Intl.DateTimeFormat and Intl.NumberFormat) have special handling when it is called via `Intl.DateTimeFormat()` form.
This allowed legacy Intl constructors to be used with prototype-based inheritance without using class syntax. This legacy behavior is later specified
explicitly in the spec. So we should align our implementation to the spec's one.
1. When defining fallback formats, we need to put them into the property which is visible via Symbol("IntlLegacyConstructedSymbol").
2. Even if the provided thisValue is IntlDateTimeFormat* / IntlNumberFormat*, we should create another instance and put it to Symbol("IntlLegacyConstructedSymbol") field.
* JavaScriptCore.xcodeproj/project.pbxproj:
* builtins/BuiltinNames.cpp:
(JSC::BuiltinNames::BuiltinNames):
* builtins/BuiltinNames.h:
(JSC::BuiltinNames::intlLegacyConstructedSymbol const):
* runtime/CommonIdentifiers.h:
* runtime/IntlDateTimeFormat.h:
* runtime/IntlDateTimeFormatConstructor.cpp:
(JSC::IntlDateTimeFormatConstructor::finishCreation):
(JSC::callIntlDateTimeFormat):
* runtime/IntlDateTimeFormatInlines.h: Added.
(JSC::IntlDateTimeFormat::unwrapForOldFunctions):
* runtime/IntlDateTimeFormatPrototype.cpp:
(JSC::IntlDateTimeFormatPrototypeGetterFormat):
(JSC::IntlDateTimeFormatPrototypeFuncFormatToParts):
(JSC::IntlDateTimeFormatPrototypeFuncFormatRange):
(JSC::IntlDateTimeFormatPrototypeFuncResolvedOptions):
* runtime/IntlNumberFormat.h:
* runtime/IntlNumberFormatConstructor.cpp:
(JSC::IntlNumberFormatConstructor::finishCreation):
(JSC::callIntlNumberFormat):
* runtime/IntlNumberFormatInlines.h:
(JSC::IntlNumberFormat::unwrapForOldFunctions):
* runtime/IntlNumberFormatPrototype.cpp:
(JSC::IntlNumberFormatPrototypeGetterFormat):
(JSC::IntlNumberFormatPrototypeFuncFormatToParts):
(JSC::IntlNumberFormatPrototypeFuncResolvedOptions):
* runtime/IntlObject.cpp:
(JSC::createDateTimeFormatConstructor):
(JSC::createNumberFormatConstructor):
* runtime/IntlObjectInlines.h:
(JSC::constructIntlInstanceWithWorkaroundForLegacyIntlConstructor):
(JSC::unwrapForLegacyIntlConstructor):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::dateTimeFormatConstructor):
(JSC::JSGlobalObject::dateTimeFormatPrototype):
(JSC::JSGlobalObject::numberFormatConstructor):
(JSC::JSGlobalObject::numberFormatPrototype):
2020-09-04 Alexey Shvayka <shvaikalesh@gmail.com>
Array.prototype.push should always perform [[Set]] in strict mode
https://bugs.webkit.org/show_bug.cgi?id=216121
Unreviewed, address Darin's feedback on r266581.
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncPush): Remove unnecessary static_cast<uint64_t>.
2020-09-04 Alexey Shvayka <shvaikalesh@gmail.com>
Array.prototype.push should always perform [[Set]] in strict mode
https://bugs.webkit.org/show_bug.cgi?id=216121
Reviewed by Darin Adler.
This patch fixes arrayProtoFuncPush() to throw a TypeError if putting an
index beyond UINT32_MAX has failed, aligning JSC with the spec [1], V8,
and SpiderMonkey. Also, refactors the method leveraging putByIndexInline().
Array.prototype.push microbenchmarks, including varargs tests, are neutral.
[1]: https://tc39.es/ecma262/#sec-array.prototype.push (step 5.b)
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncPush):
2020-09-03 Carlos Garcia Campos <cgarcia@igalia.com>
Unreviewed. [GLIB] Add missing return
There's no change in behavior because jsObjectCall() returns undefined in case of failure, but fixes a memory leak.
* API/glib/JSCValue.cpp:
(jsc_value_object_invoke_methodv):
2020-09-02 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Cache toString / valueOf / @@toPrimitive for major cases
https://bugs.webkit.org/show_bug.cgi?id=216061
Reviewed by Saam Barati.
When toPrimitive is called, we need to look-up three properties at most to perform operation. And these special properties do not have caching mechanism at all.
We found that Speedometer2/EmberJS-Debug-TodoMVC is using very much time for this property look-up. We should have caching mechanism in StructureRareData, which
should be similar to @@toStringTag & Object#toString caching mechanism.
This patch generalizes @@toStringTag & Object#toString caching mechanism as SpecialPropertyCache. And we accelerate toString / valueOf / @@toPrimitive look-ups in
toPrimitive with this caching mechanism.
This patch improved Speedometer2/EmberJS-Debug-TodoMVC by 10%.
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* bytecode/Watchpoint.cpp:
* bytecode/Watchpoint.h:
* runtime/CachedSpecialPropertyAdaptiveStructureWatchpoint.cpp: Renamed from Source/JavaScriptCore/runtime/ObjectToStringAdaptiveStructureWatchpoint.cpp.
(JSC::CachedSpecialPropertyAdaptiveStructureWatchpoint::CachedSpecialPropertyAdaptiveStructureWatchpoint):
(JSC::CachedSpecialPropertyAdaptiveStructureWatchpoint::install):
(JSC::CachedSpecialPropertyAdaptiveStructureWatchpoint::fireInternal):
* runtime/CachedSpecialPropertyAdaptiveStructureWatchpoint.h: Renamed from Source/JavaScriptCore/runtime/ObjectToStringAdaptiveStructureWatchpoint.h.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::objectProtoToStringFunction const):
* runtime/JSObject.cpp:
(JSC::callToPrimitiveFunction):
(JSC::JSObject::ordinaryToPrimitive const):
(JSC::JSObject::toPrimitive const):
* runtime/ObjectPrototype.cpp:
(JSC::ObjectPrototype::finishCreation):
(JSC::objectProtoFuncToString):
* runtime/Structure.h:
* runtime/StructureInlines.h:
(JSC::Structure::cacheSpecialProperty):
(JSC::Structure::setObjectToStringValue): Deleted.
* runtime/StructureRareData.cpp:
(JSC::StructureRareData::visitChildren):
(JSC::StructureRareData::ensureSpecialPropertyCacheSlow):
(JSC::StructureRareData::giveUpOnSpecialPropertyCache):
(JSC::StructureRareData::cacheSpecialPropertySlow):
(JSC::StructureRareData::clearCachedSpecialProperty):
(JSC::StructureRareData::finalizeUnconditionally):
(JSC::CachedSpecialPropertyAdaptiveInferredPropertyValueWatchpoint::CachedSpecialPropertyAdaptiveInferredPropertyValueWatchpoint):
(JSC::CachedSpecialPropertyAdaptiveInferredPropertyValueWatchpoint::isValid const):
(JSC::CachedSpecialPropertyAdaptiveInferredPropertyValueWatchpoint::handleFire):
(JSC::StructureRareData::setObjectToStringValue): Deleted.
(JSC::StructureRareData::clearObjectToStringValue): Deleted.
(JSC::ObjectToStringAdaptiveInferredPropertyValueWatchpoint::ObjectToStringAdaptiveInferredPropertyValueWatchpoint): Deleted.
(JSC::ObjectToStringAdaptiveInferredPropertyValueWatchpoint::isValid const): Deleted.
(JSC::ObjectToStringAdaptiveInferredPropertyValueWatchpoint::handleFire): Deleted.
* runtime/StructureRareData.h:
* runtime/StructureRareDataInlines.h:
(JSC::StructureRareData::cachedSpecialProperty const):
(JSC::StructureRareData::canCacheSpecialProperty):
(JSC::StructureRareData::ensureSpecialPropertyCache):
(JSC::StructureRareData::cacheSpecialProperty):
(JSC::StructureRareData::objectToStringValue const): Deleted.
2020-09-03 Saam Barati <sbarati@apple.com>
Sampling profiler should dump hash as part of the top function key to prevent incorrectly grouping nameless functions together
https://bugs.webkit.org/show_bug.cgi?id=216087
Reviewed by Tadeu Zagallo.
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::reportTopFunctions):
2020-09-03 Devin Rousso <drousso@apple.com>
Web Inspector: allow url breakpoints to be configured
https://bugs.webkit.org/show_bug.cgi?id=215793
Reviewed by Brian Burg.
* inspector/protocol/DOMDebugger.json:
Add an `options` parameter to `DOMDebugger.setURLBreakpoint` to allow configuration.
Add an `isRegex` parameter to `DOMDebugger.removeURLBreakpoint` so that we know what
type of URL breakpoint is being removed.
2020-09-03 Devin Rousso <drousso@apple.com>
Web Inspector: allow special JavaScript breakpoints to be configured
https://bugs.webkit.org/show_bug.cgi?id=215794
Reviewed by Brian Burg.
* inspector/protocol/Debugger.json:
Add an `options` parameter to the following commands for configuring the related breakpoint:
- `Debugger.setPauseOnDebuggerStatements`
- `Debugger.setPauseOnExceptions`
- `Debugger.setPauseOnAssertions`
- `Debugger.setPauseOnMicrotasks`
* debugger/Debugger.h:
(JSC::Debugger::needsExceptionCallbacks const):
(JSC::Debugger::pauseOnAllExceptionsBreakpoint const): Added.
(JSC::Debugger::setPauseOnAllExceptionsBreakpoint): Added.
(JSC::Debugger::pauseOnUncaughtExceptionsBreakpoint const): Added.
(JSC::Debugger::setPauseOnUncaughtExceptionsBreakpoint): Added.
(JSC::Debugger::setPauseOnDebuggerStatementsBreakpoint): Added.
(JSC::Debugger::pauseOnExceptionsState const): Deleted.
(JSC::Debugger::setPauseOnDebuggerStatements): Deleted.
* debugger/Debugger.cpp:
(JSC::Debugger::TemporarilyDisableExceptionBreakpoints::TemporarilyDisableExceptionBreakpoints): Added.
(JSC::Debugger::TemporarilyDisableExceptionBreakpoints::~TemporarilyDisableExceptionBreakpoints): Added.
(JSC::Debugger::TemporarilyDisableExceptionBreakpoints::replace): Added.
(JSC::Debugger::TemporarilyDisableExceptionBreakpoints::restore): Added.
(JSC::Debugger::Debugger):
(JSC::Debugger::breakProgram):
(JSC::Debugger::exception):
(JSC::Debugger::didReachDebuggerStatement):
(JSC::Debugger::setPauseOnExceptionsState): Deleted.
Add `JSC::Breakpoint` member variables for the Debugger Statements and Exceptions
breakpoints. Split the Exceptions breakpoint into two `JSC::Breakpoint` now that
All Exceptions and Uncaught Exceptions can be independently configured (the All
Exceptions breakpoint still takes precedence).
* debugger/DebuggerCallFrame.h:
* debugger/DebuggerCallFrame.cpp:
(JSC::DebuggerCallFrame::evaluateWithScopeExtension):
If there is no `CallFrame`, climb the backtrace until the first valid `CallFrame` is reached.
This is needed when pausing in native code, such as for assertions/exceptions.
* debugger/Breakpoint.h:
Export `JSC::Breakpoint::create` so that other parts of WebKit can create breakpoints.
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::disable):
(Inspector::InspectorDebuggerAgent::handleConsoleAssert):
(Inspector::InspectorDebuggerAgent::setPauseOnDebuggerStatements):
(Inspector::InspectorDebuggerAgent::setPauseOnExceptions):
(Inspector::InspectorDebuggerAgent::setPauseOnAssertions):
(Inspector::InspectorDebuggerAgent::setPauseOnMicrotasks):
(Inspector::InspectorDebuggerAgent::evaluateOnCallFrame):
(Inspector::InspectorDebuggerAgent::scriptExecutionBlockedByCSP):
(Inspector::InspectorDebuggerAgent::willRunMicrotask):
(Inspector::InspectorDebuggerAgent::didRunMicrotask):
(Inspector::InspectorDebuggerAgent::breakProgram):
Add `JSC::Breakpoint` member variables for the Assertion Failures and All Microtasks
breakpoints. Pass them to the `JSC::Debugger` when they are hit.
* inspector/agents/InspectorAuditAgent.cpp:
(Inspector::InspectorAuditAgent::run):
* inspector/agents/InspectorRuntimeAgent.cpp:
(Inspector::InspectorRuntimeAgent::evaluate):
(Inspector::InspectorRuntimeAgent::callFunctionOn):
(Inspector::InspectorRuntimeAgent::getPreview):
(Inspector::InspectorRuntimeAgent::getProperties):
(Inspector::InspectorRuntimeAgent::getDisplayableProperties):
(Inspector::setPauseOnExceptionsState): Deleted.
Use `TemporarilyDisableExceptionBreakpoints` to save, override, and restore the exceptions
breakpoints now that they've been separated into two `JSC::Breakpoint` instead of an `enum`.
2020-09-03 Keith Miller <keith_miller@apple.com>
Finish comment describing the various *Stack SSA nodes in DFG
https://bugs.webkit.org/show_bug.cgi?id=216110
Reviewed by Sam Weinig.
* dfg/DFGNodeType.h:
2020-09-03 David Kilzer <ddkilzer@apple.com>
AbstractMacroAssembler::Jump class has uninitialized instance variables
<https://webkit.org/b/216082>
Reviewed by Michael Saboff.
* assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::Jump):
- Switch to default constructor syntax.
- Provide defaults for instance variables.
2020-09-03 Ross Kirsling <ross.kirsling@sony.com>
[JSC] Add missing detached buffer errors for DataView
https://bugs.webkit.org/show_bug.cgi?id=216062
Reviewed by Yusuke Suzuki.
DataView methods are often expected to throw a TypeError if the underlying ArrayBuffer is detached
(or neutered, in older terminology) -- this patch adds a slew of missing cases from the following spec section:
- https://tc39.es/ecma262/#sec-properties-of-the-dataview-prototype-object
At the same time:
- get rid of JSDataView::getOwnPropertySlot, which was turning dataViewProtoGetterByte{Length,Offset}
into mostly unreachable code and erroneously causing byte{Length,Offset} to have property descriptors
- perform some simple cleanup of neighboring error calls / messages
- fix value of DataView.length (our only other DataView spec bug)
* runtime/JSDataView.cpp:
(JSC::JSDataView::create):
(JSC::JSDataView::getOwnPropertySlot): Deleted.
* runtime/JSDataView.h:
* runtime/JSDataViewPrototype.cpp:
(JSC::getData):
(JSC::setData):
(JSC::dataViewProtoGetterByteLength):
(JSC::dataViewProtoGetterByteOffset):
* runtime/JSGenericTypedArrayViewConstructorInlines.h:
(JSC::JSGenericTypedArrayViewConstructor<ViewClass>::finishCreation):
2020-09-02 Michael Saboff <msaboff@apple.com>
ASSERTION FAILED: value.isCell() && value.asCell()->type() == CustomGetterSetterType ./bytecode/ObjectPropertyConditionSet.cpp
https://bugs.webkit.org/show_bug.cgi?id=216103
Reviewed by Saam Barati.
Changed the ASSERT to an if statement. This checks to see if, the likely newly changed,
property is still a custom getter setter before caching its access as such.
* bytecode/ObjectPropertyConditionSet.cpp:
(JSC::generateConditionsForPrototypePropertyHitCustom):
* tools/JSDollarVM.cpp: Added test helper function.
2020-09-01 Yusuke Suzuki <ysuzuki@apple.com>
Skip fast/css-custom-paint/out-of-memory-while-adding-worklet-module.html if Gigacage is not enabled
https://bugs.webkit.org/show_bug.cgi?id=216043
<rdar://problem/66394369>
Reviewed by Mark Lam.
* tools/JSDollarVM.cpp:
(JSC::functionIsGigacageEnabled):
(JSC::JSDollarVM::finishCreation):
2020-08-31 Mark Lam <mark.lam@apple.com>
Remove some PtrTag debugging code from release builds.
https://bugs.webkit.org/show_bug.cgi?id=216025
<rdar://problem/68098263>
Reviewed by Saam Barati.
Removed PtrTag name lookup debugging utility from release builds.
* runtime/JSCPtrTag.cpp:
* runtime/JSCPtrTag.h:
2020-09-01 Carlos Garcia Campos <cgarcia@igalia.com>
[Linux] Web Inspector: show per thread cpu usage
https://bugs.webkit.org/show_bug.cgi?id=215883
Reviewed by Adrian Perez de Castro.
Remove platform specific getter machThread() and add thread() to return the Thread instead. The caller knows how
to get the machThread or id from a Thread.
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::reportTopBytecodes):
(JSC::SamplingProfiler::machThread): Deleted.
* runtime/SamplingProfiler.h:
(JSC::SamplingProfiler::thread):
2020-08-31 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] StructureStubInfo / CallLinkInfo / ByValInfo should set CodeOrigin or BytecodeIndex at construction
https://bugs.webkit.org/show_bug.cgi?id=215987
<rdar://problem/66370323>
Reviewed by Mark Lam.
We had race condition during construction of StructureStubInfo and CodeOrigin field setting.
1. The thread creates StructureStubInfo by calling CodeBlock::addStubInfo. This is guarded by the lock. But at this point we are not setting StructureStubInfo::codeOrigin.
2. Then (1)'s thread attempts to set StructureStubInfo::codeOrigin. But at this point, it is not guarded by the lock.
3. Before (2) is executed, DFG ByteCodeParser calls CodeBlock::getICStatusMap. It creates HashMap<CodeOrigin, StructureStubInfo*>.
4. Since StructureStubInfo*'s codeOrigin is not configured yet, (3) sees invalid CodeOrigin. And storing invalid CodeOrigin as a HashMap key is not correct.
We should configure CodeOrigin at construction of StructureStubInfo, which is guarded by the lock. We have the same problem for CallLinkInfo and ByValInfo. This patch fixes them.
To reproduce this, we need to execute a script 2~ days repeatedly. So it is difficult to add a test.
* bytecode/AccessCase.cpp:
(JSC::AccessCase::generateImpl):
* bytecode/ByValInfo.h:
(JSC::ByValInfo::ByValInfo):
(JSC::ByValInfo::setUp):
* bytecode/CallLinkInfo.cpp:
(JSC::CallLinkInfo::CallLinkInfo):
* bytecode/CallLinkInfo.h:
(JSC::CallLinkInfo::setUpCall):
(JSC::CallLinkInfo::setCodeOrigin): Deleted.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::addStubInfo):
(JSC::CodeBlock::addByValInfo):
(JSC::CodeBlock::addCallLinkInfo):
* bytecode/CodeBlock.h:
* bytecode/StructureStubInfo.cpp:
(JSC::StructureStubInfo::StructureStubInfo):
* bytecode/StructureStubInfo.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::emitCall):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstruct):
(JSC::FTL::DFG::LowerDFGToB3::compileDirectCallOrConstruct):
(JSC::FTL::DFG::LowerDFGToB3::compileTailCall):
(JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread):
(JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
(JSC::FTL::DFG::LowerDFGToB3::compileCallEval):
* jit/JIT.cpp:
(JSC::JIT::link):
* jit/JITCall.cpp:
(JSC::JIT::compileCallEvalSlowCase):
(JSC::JIT::compileOpCall):
* jit/JITCall32_64.cpp:
(JSC::JIT::compileCallEvalSlowCase):
(JSC::JIT::compileOpCall):
* jit/JITInlineCacheGenerator.cpp:
(JSC::garbageStubInfo):
(JSC::JITInlineCacheGenerator::JITInlineCacheGenerator):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_has_indexed_property):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_has_indexed_property):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_put_by_val):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_put_by_val):
* wasm/js/WasmToJS.cpp:
(JSC::Wasm::wasmToJS):
2020-08-30 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] @defaultPromiseThen fast path should check species constructor
https://bugs.webkit.org/show_bug.cgi?id=215996
Reviewed by Ross Kirsling.
When executing @defaultPromiseThen fast path, we assumed that this execution is not observable.
This is wrong only for species constructor part: this @@species access & derived constructor calls
can be observable. In this patch,
1. We extract part of Promise#then as @performPromiseThen, which corresponds to the spec's PerformPromiseThen.
2. In promise fast path, we check @speciesConstructor is @Promise or @InternalPromise. If it is not, then we go to the slow path.
This fixes Promise#finally failures in test262.
* builtins/PromiseOperations.js:
(globalPrivate.promiseResolveThenableJobFast):
(globalPrivate.promiseResolveThenableJobWithoutPromiseFast):
(globalPrivate.promiseResolveThenableJobWithDerivedPromise):
(onFulfilled):
(onRejected):
(globalPrivate.performPromiseThen):
* builtins/PromisePrototype.js:
(then):
(onFulfilled): Deleted.
(onRejected): Deleted.
2020-08-30 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Use -2 for grouping options in IntlRelativeTimeFormat
https://bugs.webkit.org/show_bug.cgi?id=215984
Reviewed by Ross Kirsling.
Several test262 tests are failing after ICU 67. This is because Intl.RelativeTimeFormat is not using locale-sensitive grouping option.
There are hidden option -2 for UNumberFormat. It is supported so long, but it is not explicitly documented. After ICU 68, it is exposed as a constant,
we should pass -2 to UNumberFormat's grouping options to use locale-sensitive grouping option here.
* runtime/IntlRelativeTimeFormat.cpp:
(JSC::IntlRelativeTimeFormat::initializeRelativeTimeFormat):
2020-08-30 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] async function cannot appear in single-statement context
https://bugs.webkit.org/show_bug.cgi?id=215993
Reviewed by Darin Adler.
The following code is syntax error[1] because ExpressionStatement has `async [no LineTerminator here] function` lookahead.
if (false)
async function t() { }
[1]: https://tc39.es/ecma262/#sec-expression-statement
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseStatement):
(JSC::Parser<LexerType>::maybeParseAsyncFunctionDeclarationStatement): Deleted.
* parser/Parser.h:
2020-08-29 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] `let [` sequence cannot appear in ExpressionStatement context
https://bugs.webkit.org/show_bug.cgi?id=215977
Reviewed by Ross Kirsling.
Because of ambiguity between destructuring assignment and member access (let IDENTIFIER), ECMA262 does not allow `let [` sequence in ExpressionStatement context[1].
We should throw SyntaxError when we see something like this.
if (false)
let [ok] = [42];
[1]: https://tc39.es/ecma262/#sec-expression-statement
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseStatement):
2020-08-29 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] for-of uses AssignmentExpression while for-in uses Expression
https://bugs.webkit.org/show_bug.cgi?id=215975
Reviewed by Ross Kirsling.
While for-in uses Expression, for-of and for-await-of use AssignmentExpression which does not accept comma-expression.
We should align our implementation to that.
for (LeftHandSideExpression in Expression) Statement
for (LeftHandSideExpression of AssignmentExpression) Statement
for await(LeftHandSideExpression of AssignmentExpression) Statement
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseForStatement):
2020-08-28 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] for-of / for-in left-hand-side target should be simple-assignment-target
https://bugs.webkit.org/show_bug.cgi?id=215969
Reviewed by Ross Kirsling.
Left-hand-side of `for-in`, `for-of`, and `for-await-of` should be simple assignment target[1]
if the target is not declaration and not destructuring pattern.
[1]: https://tc39.es/ecma262/#sec-for-in-and-for-of-statements-static-semantics-early-errors
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseForStatement):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createCommaExpr): Should return CommaExpr to align it to ASTBuilder.
(JSC::SyntaxChecker::appendToCommaExpr):
(JSC::SyntaxChecker::appendStatement):
(JSC::SyntaxChecker::combineCommaNodes): Deleted since it is not used.
2020-08-28 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Implement Intl.DateTimeFormat dayPeriod
https://bugs.webkit.org/show_bug.cgi?id=215839
Reviewed by Ross Kirsling.
This patch implements Intl.DateTimeFormat dayPeriod option[1]. We can use "narrow", "short", or "long" for dayPeriod,
and it determines how "AM" etc. is represented.
[1]: https://github.com/tc39/ecma402/pull/346
* builtins/DatePrototype.js:
(toLocaleString.toDateTimeOptionsAnyAll):
(toLocaleString):
(toLocaleTimeString.toDateTimeOptionsTimeTime):
(toLocaleTimeString):
* bytecode/BytecodeIntrinsicRegistry.cpp:
(JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
* bytecode/BytecodeIntrinsicRegistry.h:
* runtime/CommonIdentifiers.h:
* runtime/IntlDateTimeFormat.cpp:
(JSC::toDateTimeOptionsAnyDate):
(JSC::IntlDateTimeFormat::setFormatsFromPattern):
(JSC::IntlDateTimeFormat::initializeDateTimeFormat):
(JSC::IntlDateTimeFormat::dayPeriodString):
(JSC::IntlDateTimeFormat::resolvedOptions const):
* runtime/IntlDateTimeFormat.h:
* runtime/OptionsList.h:
2020-08-28 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] super property with new should be accepted
https://bugs.webkit.org/show_bug.cgi?id=215966
Reviewed by Ross Kirsling.
While we should reject `new super` / `new super()`, we should accept `new super.property`.
https://tc39.es/ecma262/#prod-SuperProperty is a child production of https://tc39.es/ecma262/#prod-MemberExpression,
unlike https://tc39.es/ecma262/#prod-SuperCall. So `new` should accept SuperProperty (e.g. `super.xxx`).
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseMemberExpression):
2020-08-28 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] `new import.meta()` is acceptable
https://bugs.webkit.org/show_bug.cgi?id=215915
Reviewed by Ross Kirsling.
`new import.meta()` is valid in terms of syntax while it throws runtime error.
We should accept this code, while `new import()` is not correct syntax.
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseMemberExpression):
2020-08-27 Alexey Shvayka <shvaikalesh@gmail.com>
__proto__ in object literal should perform [[SetPrototypeOf]] directly
https://bugs.webkit.org/show_bug.cgi?id=215769
Reviewed by Ross Kirsling.
To fix __proto__ usage in object literals if Object.prototype.__proto__ is overridden
or removed, this patch sets the [[Prototype]] directly, aligning JSC with V8 and
SpiderMonkey. We are safe to skip method table lookups and cycle checks, as the
spec [1] calls [[SetPrototypeOf]] on newly created (unreferenced) ordinary objects.
This change removes PropertyNode::PutType because its only purpose was to accomodate
__proto__ in object literals. Since emitPutConstantProperty() handles static public
class fields, which don't need `super` binding, PropertyNode::isUnderscoreProtoSetter()
is extended to reject class properties.
This patch speeds up creating object literals with __proto__ by 25%.
[1]: https://tc39.es/ecma262/#sec-__proto__-property-names-in-object-initializers (step 7.a)
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitDirectPutById):
(JSC::BytecodeGenerator::emitDirectSetPrototypeOf):
1. Remove unused `dst` parameter to align with other `put` methods.
2. Remove `divot*` parameters as it's cumbersome to pass them through,
and globalFuncSetPrototypeDirect() never throws anyway.
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::PropertyListNode::emitPutConstantProperty):
(JSC::BytecodeIntrinsicNode::emit_intrinsic_putByIdDirect):
(JSC::BytecodeIntrinsicNode::emit_intrinsic_putByIdDirectPrivate):
(JSC::ClassExprNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createGetterOrSetterProperty):
(JSC::ASTBuilder::createProperty):
(JSC::ASTBuilder::isUnderscoreProtoSetter const):
* parser/NodeConstructors.h:
(JSC::PropertyNode::PropertyNode):
* parser/Nodes.h:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseClass):
(JSC::Parser<LexerType>::parseProperty):
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createProperty):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncSetPrototypeDirect):
1. Ignore a prototype value of incorrect type as per spec [1],
which is unobservable for call sites in ClassExprNode::emitBytecode().
2. Assert that JSObject::setPrototypeDirect() doesn't throw.
2020-08-27 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] setLength in Array#push could get very large length
https://bugs.webkit.org/show_bug.cgi?id=215897
<rdar://problem/67859149>
Reviewed by Keith Miller.
Array#push can get length larger than UINT32_MAX. And in this case, we should throw a RangeError.
Before r266215, it was using putLength which throws an error. But it was replaced with setLength,
and JSC::setLength assumes that it never gets a length greater than UINT32_MAX by asserting. We
should fix it so that Array#push should thrown an error correctly.
* runtime/ArrayPrototype.cpp:
(JSC::setLength):
2020-08-27 Saam Barati <sbarati@apple.com>
GetByVal constant folding over a Double OutOfBoundsSaneChain array with no BytecodeUsesAsOther should constant fold to PNaN, not undefined
https://bugs.webkit.org/show_bug.cgi?id=215894
<rdar://problem/67669696>
Reviewed by Michael Saboff and Keith Miller.
GetByVals of the form { OutOfBoundsSaneChain, Double } where there are no
BytecodeUsesAsOther return PNaN for holes and OOB accesses, not jsUndefined().
The constant folding for this though was folding to jsUndefined(). I forgot
to update that code to constant fold to PNaN when I wrote the OutOfBoundsSaneChain
implementation.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2020-08-27 Keith Miller <keith_miller@apple.com>
structureOrNull should take VM instead of getting it from the marked block
https://bugs.webkit.org/show_bug.cgi?id=215899
Reviewed by Yusuke Suzuki.
It's slightly faster use an existing VM over recomputing the address. It probably doesn't
happen to matter here for performance but it's good hygiene.
* API/tests/JSWrapperMapTests.mm:
(+[JSWrapperMapTests testStructureIdentity]):
* jit/JITOperations.cpp:
* runtime/JSCJSValue.h:
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::structureOrNull const):
(JSC::JSValue::structureOrUndefined const): Deleted.
2020-08-27 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Use auxiliary memory for JSBigInt storage
https://bugs.webkit.org/show_bug.cgi?id=215876
Reviewed by Mark Lam.
This makes JSBigInt non-destructible cell. And it makes allocating JSBigInt from JIT easy.
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::JSBigInt):
(JSC::JSBigInt::visitChildren):
(JSC::JSBigInt::createWithLength):
(JSC::JSBigInt::destroy): Deleted.
* runtime/JSBigInt.h:
* runtime/VM.cpp:
(JSC::VM::VM):
2020-08-27 Keith Miller <keith_miller@apple.com>
OSR availability validation should run for any node with exitOK
https://bugs.webkit.org/show_bug.cgi?id=215672
Reviewed by Saam Barati.
Currently we only validate OSR exit availability if a node would
say `mayExit(graph, node) != DoesNotExit` and the node is marked
as exitOK. However, it would be perfectly valid to insert a node
that exits anywhere we have a node marked exitOK. So with this
patch we now validate all places where it would ever be possible
to OSR exit.
Relaxing our criteria revealed a number of bugs however. Which I
will describe below in, IMO, increasing complexity/subtly.
First, we currently don't mark arity fixup during inlining as not
exitOK. However, since our arity code says its code origin is
OpEnter, we assume arity fixup has already happened.
Second, OpGetScope, should not mark its first argument as used
since it's not actually used. This is problematic because we could
have a loop where OpGetScope is the first bytecode, namely when
doing tail recursive inlining. If we were in that position, there
could be a local that was used at a merge point at the loop
backedge that had two MovHint defs from both predecessors. In DFG
IR this would look like:
BB#1:
@1: MovHint(Undefined, loc1)
...
Jump(#2)
BB#2:
... // loc1 is live here in bytecode
@2: MovHint(@scopeObject, loc1)
@3: SetLocal(@scopeObject, loc1)
Branch(#3, #4) // #4 is the successor of the tail call loop
BB#3:
@4 MovHint(Undefined, loc1)
...
Jump(#2)
When we do CPS conversion the MovHints at @1 and @4 will be seen
as different variables (there's no GetLocal). Then, after, during
SSA conversion we won't insert a phi connecting them, making the
argument to OpGetScope, in this case loc1, unrecoverable there are
conflicting nodes and the value isn't saved on the stack.
There were also issues with MovHintRemoval Phase but rather than
fix them we opted to just remove the phase as it didn't show any
performance impact. I'll describe the issues I found below for
completeness, however.
Third, MovHint removal phase had a bug where it would not mark
sections where a zombied MovHint has yet to be killed as not
exitOK. So in theory another phase could come along and insert an
exiting node there.
Fourth, MovHint removal phase had a second bug where a MovHint
that was not killed in the current block would be zombied, which
is wrong for SSA. It's wrong because the MovHinted value could
still be live for OSR exit in a successor block.
Lastly, this patch adds some new verbose options as well as the ability to
dump a DFG::BasicBlock without dereferencing it.
* bytecode/BytecodeUseDef.cpp:
(JSC::computeUsesForBytecodeIndexImpl):
* dfg/DFGBasicBlock.cpp:
(WTF::printInternal):
* dfg/DFGBasicBlock.h:
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::inlineCall):
* dfg/DFGCPSRethreadingPhase.cpp:
(JSC::DFG::CPSRethreadingPhase::propagatePhis):
* dfg/DFGEpoch.h:
(JSC::DFG::Epoch::operator bool const):
* dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
(JSC::DFG::OSRAvailabilityAnalysisPhase::run):
* dfg/DFGSSACalculator.cpp:
(JSC::DFG::SSACalculator::dump const):
2020-08-27 Keith Miller <keith_miller@apple.com>
JSClassRef should work with JS class syntax.
https://bugs.webkit.org/show_bug.cgi?id=215047
Reviewed by Darin Adler.
This is done by checking if value returned by the
callAsConstructor parameter to JSObjectMakeConstructor returns an
object allocated as the jsClass parameter. When that happens we
replace the prototype of the returned object with the prototype of
the new.target. Ideally we would have passed the derived classes
constructor from the beginning of our support for JS subclassing
but at this point that's probably not compatible with too many
applications.
* API/APICallbackFunction.h:
(JSC::APICallbackFunction::construct):
* API/JSObjectRef.h:
* API/tests/testapi.cpp:
(APIString::APIString):
(TestAPI::markedJSValueArrayAndGC):
(TestAPI::classDefinitionWithJSSubclass):
(testCAPIViaCpp):
* API/tests/testapi.mm:
(testObjectiveCAPI):
2020-08-26 Alexey Shvayka <shvaikalesh@gmail.com>
Use jsTypeofIsObject() in DFG AI and operationTypeOfIsObject()
https://bugs.webkit.org/show_bug.cgi?id=144457
Reviewed by Saam Barati.
This patch refactors jsTypeofIsObject(), leveraging fast path of isCallable(),
moves it to the header, and utilizes it in operationTypeOfIsObject() & DFG AI
(minding concurrency) to eliminate code duplication.
Also, removes orphaned slow_path_is_object declaration.
No behavior change, `typeof` microbenchmarks are neutral.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGOperations.cpp:
* runtime/CommonSlowPaths.h:
* runtime/Operations.cpp:
(JSC::jsTypeofIsObject): Deleted.
* runtime/Operations.h:
(JSC::jsTypeofIsObjectWithConcurrency):
(JSC::jsTypeofIsObject):
2020-08-26 Alexey Shvayka <shvaikalesh@gmail.com>
Merge putLength() into setLength()
https://bugs.webkit.org/show_bug.cgi?id=211279
Reviewed by Darin Adler and Saam Barati.
This patch:
1. Replaces all putLength() call sites with setLength(), saving two JSValue
instantiations in arrayProtoFuncPop() and two in arrayProtoFuncShift().
2. Merges putLength() into setLength(), removing superfluous put() call for
JSArray. Also, performs put() in strict mode to preserve the original
error messages, like ones in ProxyObject::performPut().
3. Inlines performPop(), which avoided an extra index check and Identifier
creation, as it was on the slow path anyway (note JSArray::pop() call).
This change advances provided setLength()-heavy microbenchmark by ~40%,
while existing Array tests are neutral.
* runtime/ArrayPrototype.cpp:
(JSC::setLength):
(JSC::arrayProtoFuncPop):
(JSC::arrayProtoFuncPush):
(JSC::arrayProtoFuncShift):
(JSC::arrayProtoFuncUnShift):
(JSC::putLength): Deleted.
2020-08-26 Saam Barati <sbarati@apple.com>
Make isIndex use MAX_ARRAY_INDEX
https://bugs.webkit.org/show_bug.cgi?id=215872
Reviewed by Darin Adler.
It's already written in such a way where it relies on what MAX_ARRAY_INDEX
is defined as. But instead of MAX_ARRAY_INDEX, the function was hardcoding
MAX_ARRAY_INDEX + 1.
* runtime/Identifier.h:
(JSC::isIndex):
2020-08-26 Alexey Shvayka <shvaikalesh@gmail.com>
Use unsigned type for `length` of JSFunction
https://bugs.webkit.org/show_bug.cgi?id=215870
Reviewed by Darin Adler.
Since the `length` value of a built-in function is its arity,
we can communicate it's always non-negative via method signatures.
No behavior change: `length` values redefined by user code are unaffected.
* runtime/InternalFunction.cpp:
(JSC::InternalFunction::createFunctionThatMasqueradesAsUndefined):
* runtime/InternalFunction.h:
* runtime/JSFunction.cpp:
(JSC::JSFunction::create):
(JSC::JSFunction::finishCreation):
* runtime/JSFunction.h:
* runtime/JSNativeStdFunction.cpp:
(JSC::JSNativeStdFunction::finishCreation):
(JSC::JSNativeStdFunction::create):
* runtime/JSNativeStdFunction.h:
2020-08-26 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Enable Intl.Segmenter
https://bugs.webkit.org/show_bug.cgi?id=215854
Reviewed by Ross Kirsling.
This is already stage-3 and all the features are implemented. Let's just enable it.
* runtime/IntlObject.cpp:
(JSC::IntlObject::finishCreation):
* runtime/OptionsList.h:
2020-08-26 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Add ASCII comparison fast path for IntlCollator
https://bugs.webkit.org/show_bug.cgi?id=215798
Reviewed by Darin Adler, Ross Kirsling, and Saam Barati.
The idea behind this change is the following: ICU Collator's comparison is too slow. We should have fast path for ASCII strings when we know this equals to ICU Collator's result.
The problem is that even for ASCII strings, collation is super complicated!
1. Unicode defines Unicode Collation Algorithm (UCA). To perform collation, it uses collation element tables which defines weights on various levels per code point. UCA also offers
the Default Unicode Collation Element Table (DUCET). This UCA with DUCET is used when using ICU Root Collator.
2. UCA collation consists of rules, which defines how collation works. And ICU locales define customized collations by adding special rules to that.
3. UCA behaves differently by using different options.
Based on that, our observation is that some of major locales are not defining additional rules in (2). This means that they behaves the same to UCA with DUCET.
This patch implements a simplified version of comparison which generates the same results for ASCII strings (excluding control characters) to UCA with DUCET. This fast path can be usable only when the following conditions are met.
1. The collator does not have additional rules to ICU Root Colator.
2. The collator is using default options.
These checks are very important since there are a lot of edge-case locales. For example,
1. th (Thai language) ignores punctuations (even including ASCII punctuations) by default. This is defined as ignore-punctuations option is enabled by default, so without (2)'s check, th comparison becomes wrong.
2. There are contraction concept (multiple letters behave as a single letter). "ch" letters are ordered interestingly in Czech language. So even in ASCII, Czech shows very interesting collation behavior.
So we cannot safely take this fast path without carefully querying the information to ICU.
This shows 37% improvement in JetStream2/cdjs in en-US environment.
* runtime/IntlCollator.cpp:
(JSC::IntlCollator::initializeCollator):
(JSC::IntlCollator::compareStrings const):
(JSC::canDoASCIIUCADUCETComparisonWithUCollator):
(JSC::IntlCollator::updateCanDoASCIIUCADUCETComparison const):
(JSC::IntlCollator::checkICULocaleInvariants):
* runtime/IntlCollator.h:
* runtime/IntlObject.cpp:
(JSC::intlCollatorAvailableLocales):
* runtime/IntlObject.h:
* runtime/IntlObjectInlines.h:
(JSC::canUseASCIIUCADUCETComparison):
(JSC::compareASCIIWithUCADUCET):
2020-08-26 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Implement Intl.DateTimeFormat fractionalSecondDigits
https://bugs.webkit.org/show_bug.cgi?id=215840
Reviewed by Ross Kirsling.
This patch implements fractionalSecondDigits option for Intl.DateTimeFormat. If it is
specified, milliseconds in N digits are represented in the formatted output.
This extension is about to be merged into the spec[1]. SpiderMonkey and V8 support it,
and V8 shipped it without flags.
[1]: https://github.com/tc39/ecma402/pull/347
* builtins/DatePrototype.js:
(toLocaleString.toDateTimeOptionsAnyAll):
(toLocaleString):
(toLocaleTimeString.toDateTimeOptionsTimeTime):
(toLocaleTimeString):
* runtime/CommonIdentifiers.h:
* runtime/IntlDateTimeFormat.cpp:
(JSC::toDateTimeOptionsAnyDate):
(JSC::IntlDateTimeFormat::setFormatsFromPattern):
(JSC::IntlDateTimeFormat::initializeDateTimeFormat):
(JSC::IntlDateTimeFormat::resolvedOptions const):
(JSC::partTypeString):
* runtime/IntlDateTimeFormat.h:
2020-08-25 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] FTL should use m_origin instead of m_node->origin since m_node can be nullptr
https://bugs.webkit.org/show_bug.cgi?id=215833
Reviewed by Mark Lam.
While we are using m_node->origin, m_node can be nullptr (at the entry of the FTL function).
m_origin is always pointing appropriate origin. We should use it instead.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileToObjectOrCallObjectConstructor):
(JSC::FTL::DFG::LowerDFGToB3::compileToThis):
(JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
(JSC::FTL::DFG::LowerDFGToB3::compileValueSub):
(JSC::FTL::DFG::LowerDFGToB3::compileValueMul):
(JSC::FTL::DFG::LowerDFGToB3::compileBinaryMathIC):
(JSC::FTL::DFG::LowerDFGToB3::compileStrCat):
(JSC::FTL::DFG::LowerDFGToB3::compileArithAddOrSub):
(JSC::FTL::DFG::LowerDFGToB3::compileArithClz32):
(JSC::FTL::DFG::LowerDFGToB3::compileValueDiv):
(JSC::FTL::DFG::LowerDFGToB3::compileValueMod):
(JSC::FTL::DFG::LowerDFGToB3::compileArithAbs):
(JSC::FTL::DFG::LowerDFGToB3::compileArithUnary):
(JSC::FTL::DFG::LowerDFGToB3::compileValuePow):
(JSC::FTL::DFG::LowerDFGToB3::compileArithRandom):
(JSC::FTL::DFG::LowerDFGToB3::compileArithRound):
(JSC::FTL::DFG::LowerDFGToB3::compileArithFloor):
(JSC::FTL::DFG::LowerDFGToB3::compileArithCeil):
(JSC::FTL::DFG::LowerDFGToB3::compileArithTrunc):
(JSC::FTL::DFG::LowerDFGToB3::compileArithSqrt):
(JSC::FTL::DFG::LowerDFGToB3::compileArithFRound):
(JSC::FTL::DFG::LowerDFGToB3::compileIncOrDec):
(JSC::FTL::DFG::LowerDFGToB3::compileValueNegate):
(JSC::FTL::DFG::LowerDFGToB3::compileValueBitNot):
(JSC::FTL::DFG::LowerDFGToB3::compileValueBitAnd):
(JSC::FTL::DFG::LowerDFGToB3::compileValueBitOr):
(JSC::FTL::DFG::LowerDFGToB3::compileValueBitXor):
(JSC::FTL::DFG::LowerDFGToB3::compileValueBitRShift):
(JSC::FTL::DFG::LowerDFGToB3::compileValueBitLShift):
(JSC::FTL::DFG::LowerDFGToB3::compileGetById):
(JSC::FTL::DFG::LowerDFGToB3::compileGetByIdWithThis):
(JSC::FTL::DFG::LowerDFGToB3::compileGetByValWithThis):
(JSC::FTL::DFG::LowerDFGToB3::compilePutByIdWithThis):
(JSC::FTL::DFG::LowerDFGToB3::compilePutByValWithThis):
(JSC::FTL::DFG::LowerDFGToB3::compileAtomicsReadModifyWrite):
(JSC::FTL::DFG::LowerDFGToB3::compileAtomicsIsLockFree):
(JSC::FTL::DFG::LowerDFGToB3::compileDefineDataProperty):
(JSC::FTL::DFG::LowerDFGToB3::compileDefineAccessorProperty):
(JSC::FTL::DFG::LowerDFGToB3::compileGetIndexedPropertyStorage):
(JSC::FTL::DFG::LowerDFGToB3::compileGetPrototypeOf):
(JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
(JSC::FTL::DFG::LowerDFGToB3::compilePutByVal):
(JSC::FTL::DFG::LowerDFGToB3::compilePutAccessorById):
(JSC::FTL::DFG::LowerDFGToB3::compilePutGetterSetterById):
(JSC::FTL::DFG::LowerDFGToB3::compilePutAccessorByVal):
(JSC::FTL::DFG::LowerDFGToB3::compileDeleteById):
(JSC::FTL::DFG::LowerDFGToB3::compileDeleteByVal):
(JSC::FTL::DFG::LowerDFGToB3::compileArrayPush):
(JSC::FTL::DFG::LowerDFGToB3::compileArraySlice):
(JSC::FTL::DFG::LowerDFGToB3::compileArrayIndexOf):
(JSC::FTL::DFG::LowerDFGToB3::compileArrayPop):
(JSC::FTL::DFG::LowerDFGToB3::compilePushWithScope):
(JSC::FTL::DFG::LowerDFGToB3::compileCreateActivation):
(JSC::FTL::DFG::LowerDFGToB3::compileNewFunction):
(JSC::FTL::DFG::LowerDFGToB3::compileCreateDirectArguments):
(JSC::FTL::DFG::LowerDFGToB3::compileCreateScopedArguments):
(JSC::FTL::DFG::LowerDFGToB3::compileCreateClonedArguments):
(JSC::FTL::DFG::LowerDFGToB3::compileCreateArgumentsButterfly):
(JSC::FTL::DFG::LowerDFGToB3::compileCreateRest):
(JSC::FTL::DFG::LowerDFGToB3::compileObjectKeysOrObjectGetOwnPropertyNames):
(JSC::FTL::DFG::LowerDFGToB3::compileObjectCreate):
(JSC::FTL::DFG::LowerDFGToB3::compileNewSymbol):
(JSC::FTL::DFG::LowerDFGToB3::compileNewArray):
(JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSpread):
(JSC::FTL::DFG::LowerDFGToB3::compileCreateThis):
(JSC::FTL::DFG::LowerDFGToB3::compileCreatePromise):
(JSC::FTL::DFG::LowerDFGToB3::compileCreateInternalFieldObject):
(JSC::FTL::DFG::LowerDFGToB3::compileSpread):
(JSC::FTL::DFG::LowerDFGToB3::compileNewArrayBuffer):
(JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSize):
(JSC::FTL::DFG::LowerDFGToB3::compileNewTypedArray):
(JSC::FTL::DFG::LowerDFGToB3::compileToNumber):
(JSC::FTL::DFG::LowerDFGToB3::compileToNumeric):
(JSC::FTL::DFG::LowerDFGToB3::compileCallNumberConstructor):
(JSC::FTL::DFG::LowerDFGToB3::compileToStringOrCallStringConstructorOrStringValueOf):
(JSC::FTL::DFG::LowerDFGToB3::compileToPrimitive):
(JSC::FTL::DFG::LowerDFGToB3::compileToPropertyKey):
(JSC::FTL::DFG::LowerDFGToB3::compileMakeRope):
(JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
(JSC::FTL::DFG::LowerDFGToB3::compileStringFromCharCode):
(JSC::FTL::DFG::LowerDFGToB3::compileMultiPutByOffset):
(JSC::FTL::DFG::LowerDFGToB3::compileGetGlobalThis):
(JSC::FTL::DFG::LowerDFGToB3::compileGetArgument):
(JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
(JSC::FTL::DFG::LowerDFGToB3::compileSameValue):
(JSC::FTL::DFG::LowerDFGToB3::compileCallEval):
(JSC::FTL::DFG::LowerDFGToB3::compileVarargsLength):
(JSC::FTL::DFG::LowerDFGToB3::compileLoadVarargs):
(JSC::FTL::DFG::LowerDFGToB3::compileForwardVarargs):
(JSC::FTL::DFG::LowerDFGToB3::compileSwitch):
(JSC::FTL::DFG::LowerDFGToB3::compileThrow):
(JSC::FTL::DFG::LowerDFGToB3::compileThrowStaticError):
(JSC::FTL::DFG::LowerDFGToB3::mapHashString):
(JSC::FTL::DFG::LowerDFGToB3::compileMapHash):
(JSC::FTL::DFG::LowerDFGToB3::compileGetMapBucket):
(JSC::FTL::DFG::LowerDFGToB3::compileSetAdd):
(JSC::FTL::DFG::LowerDFGToB3::compileMapSet):
(JSC::FTL::DFG::LowerDFGToB3::compileTypeOfIsObject):
(JSC::FTL::DFG::LowerDFGToB3::compileIsCallable):
(JSC::FTL::DFG::LowerDFGToB3::compileIsConstructor):
(JSC::FTL::DFG::LowerDFGToB3::compileInByVal):
(JSC::FTL::DFG::LowerDFGToB3::compileHasOwnProperty):
(JSC::FTL::DFG::LowerDFGToB3::compileParseInt):
(JSC::FTL::DFG::LowerDFGToB3::compileInstanceOfCustom):
(JSC::FTL::DFG::LowerDFGToB3::compileHasIndexedProperty):
(JSC::FTL::DFG::LowerDFGToB3::compileHasGenericProperty):
(JSC::FTL::DFG::LowerDFGToB3::compileHasStructurePropertyImpl):
(JSC::FTL::DFG::LowerDFGToB3::compileGetDirectPname):
(JSC::FTL::DFG::LowerDFGToB3::compileGetPropertyEnumerator):
(JSC::FTL::DFG::LowerDFGToB3::compileToIndexString):
(JSC::FTL::DFG::LowerDFGToB3::compileMaterializeCreateActivation):
(JSC::FTL::DFG::LowerDFGToB3::compileCheckTraps):
(JSC::FTL::DFG::LowerDFGToB3::compileNewRegexp):
(JSC::FTL::DFG::LowerDFGToB3::compileSetFunctionName):
(JSC::FTL::DFG::LowerDFGToB3::compileStringReplace):
(JSC::FTL::DFG::LowerDFGToB3::compileLogShadowChickenTail):
(JSC::FTL::DFG::LowerDFGToB3::getArgumentsLength):
(JSC::FTL::DFG::LowerDFGToB3::getCurrentCallee):
(JSC::FTL::DFG::LowerDFGToB3::getArgumentsStart):
(JSC::FTL::DFG::LowerDFGToB3::compare):
(JSC::FTL::DFG::LowerDFGToB3::compileStringSlice):
(JSC::FTL::DFG::LowerDFGToB3::compileToLowerCase):
(JSC::FTL::DFG::LowerDFGToB3::compileNumberToStringWithRadix):
(JSC::FTL::DFG::LowerDFGToB3::compileNumberToStringWithValidRadixConstant):
(JSC::FTL::DFG::LowerDFGToB3::compileResolveScopeForHoistingFuncDeclInEval):
(JSC::FTL::DFG::LowerDFGToB3::compileResolveScope):
(JSC::FTL::DFG::LowerDFGToB3::compileGetDynamicVar):
(JSC::FTL::DFG::LowerDFGToB3::compilePutDynamicVar):
(JSC::FTL::DFG::LowerDFGToB3::compileCallDOM):
(JSC::FTL::DFG::LowerDFGToB3::compileCallDOMGetter):
(JSC::FTL::DFG::LowerDFGToB3::compileLoopHint):
(JSC::FTL::DFG::LowerDFGToB3::genericJSValueCompare):
(JSC::FTL::DFG::LowerDFGToB3::stringsEqual):
(JSC::FTL::DFG::LowerDFGToB3::allocateJSArray):
(JSC::FTL::DFG::LowerDFGToB3::boolify):
(JSC::FTL::DFG::LowerDFGToB3::equalNullOrUndefined):
(JSC::FTL::DFG::LowerDFGToB3::contiguousPutByValOutOfBounds):
(JSC::FTL::DFG::LowerDFGToB3::switchStringSlow):
(JSC::FTL::DFG::LowerDFGToB3::buildTypeOf):
(JSC::FTL::DFG::LowerDFGToB3::lazySlowPath):
(JSC::FTL::DFG::LowerDFGToB3::masqueradesAsUndefinedWatchpointIsStillValid):
(JSC::FTL::DFG::LowerDFGToB3::codeOriginDescriptionOfCallSite const):
(JSC::FTL::DFG::LowerDFGToB3::callCheck):
(JSC::FTL::DFG::LowerDFGToB3::appendOSRExit):
* jsc.cpp:
(runJSC):
* runtime/OptionsList.h:
2020-08-25 Devin Rousso <drousso@apple.com>
Web Inspector: breakpoint condition should be evaluated before the ignore count
https://bugs.webkit.org/show_bug.cgi?id=215364
<rdar://problem/67310703>
Reviewed by Joseph Pecoraro.
Previously, when pausing, `JSC::Breakpoint` would check that it's `ignoreCount` before it
would even attempt to evaluate it's `condition`. This meant that a `JSC::Breakpoint` with
a `condition` of `foo === 42` and an `ignoreCount` of `3` would ignore the first three
pauses and then only pause if `foo === 42`. This is likely contrary to the expectation of
most users (especially since the `condition` input is before the `ignoreCount` input in
the Web Inspector frontend UI) in that they would probably expect to ignore the first
three pauses if `foo === 42`.
* debugger/Breakpoint.cpp:
(JSC::Breakpoint::shouldPause):
2020-08-25 Alexey Shvayka <shvaikalesh@gmail.com>
Invalid early error for object literal method named "__proto__"
https://bugs.webkit.org/show_bug.cgi?id=215760
Reviewed by Ross Kirsling.
According to Annex B [1], `{ __proto__: null, __proto__() {} }` is a valid object literal as the second
`__proto__` wasn't obtained from `PropertyDefinition : PropertyName : AssignmentExpression` production.
Currently, JSC throws an early SyntaxError, unlike V8 and SpiderMonkey.
Since a method needs `super` binding, the most straightforward fix would be adding SuperBinding field
to SyntaxChecker::Property and exposing it via an accessor. However, given that Property is a very
common structure, this approach would noticeably increase memory pressure during parsing.
Instead, this patch reworks SyntaxChecker::Property to accept `isUnderscoreProtoSetter` parameter,
removing optional `name` field, its accessor, and shouldCheckPropertyForUnderscoreProtoDuplicate(),
which reduces sizeof(SyntaxChecker::Property) by a factor of 8: from 16 to 2 bytes.
Also, this change avoids two extra makeNumericIdentifier() calls, speeding up numeric keys parsing.
This approach is feasible because "__proto__" is the only identifier-based early error for object
literals [2], with no such errors being added in upcoming stage 2-4 proposals.
Additionally, this patch removes `strict` / `complete` bool parameter from {parse,create}Property()
signatures as a) it was always `true`, b) is now unused, and c) strict mode can be checked via scope.
[1]: https://tc39.es/ecma262/#sec-__proto__-property-names-in-object-initializers
[2]: https://tc39.es/ecma262/#sec-object-initializer-static-semantics-early-errors
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createGetterOrSetterProperty):
(JSC::ASTBuilder::createProperty):
(JSC::ASTBuilder::isUnderscoreProtoSetter const):
(JSC::ASTBuilder::getName const): Deleted.
* parser/Nodes.h:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseClass):
(JSC::Parser<LexerType>::parseProperty):
(JSC::Parser<LexerType>::parseGetterSetter):
(JSC::Parser<LexerType>::parseObjectLiteral):
(JSC::Parser<LexerType>::shouldCheckPropertyForUnderscoreProtoDuplicate): Deleted.
* parser/Parser.h:
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::SyntaxChecker):
(JSC::SyntaxChecker::Property::Property):
(JSC::SyntaxChecker::Property::operator!):
(JSC::SyntaxChecker::createProperty):
(JSC::SyntaxChecker::createGetterOrSetterProperty):
(JSC::SyntaxChecker::operatorStackPop):
2020-08-25 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Add concurrency-aware version of isCallable / isConstructor to make it usable in DFG compiler
https://bugs.webkit.org/show_bug.cgi?id=215746
Reviewed by Saam Barati.
This patch adds isCallableWithConcurrency and isConstructorWithConcurrency to JSCell, JSValue etc.
This can work even if it is called from concurrent compiler threads. We also add jsTypeStringForValueWithConcurrency
and jsTypeofIsFunctionWithConcurrency which are using the above WithConcurrency functionalities.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* runtime/Concurrency.h: Added.
(WTF::printInternal):
* runtime/InternalFunction.cpp:
(JSC::InternalFunction::finishCreation):
(JSC::InternalFunction::getCallData):
(JSC::InternalFunction::getConstructData):
* runtime/JSCJSValue.h:
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::isCallableWithConcurrency const):
(JSC::JSValue::isConstructorWithConcurrency const):
* runtime/JSCell.h:
* runtime/JSCellInlines.h:
(JSC::JSCell::isCallableWithConcurrency):
(JSC::JSCell::isConstructorWithConcurrency):
(JSC::JSCell::isCallable):
(JSC::JSCell::isConstructor):
* runtime/JSFunction.cpp:
(JSC::JSFunction::finishCreation):
(JSC::JSFunction::getCallData):
(JSC::JSFunction::getConstructData):
* runtime/NumberPrototype.cpp:
(JSC::throwVMToThisNumberError):
* runtime/Operations.cpp:
(JSC::jsTypeStringForValueWithConcurrency):
(JSC::jsTypeStringForValue): Deleted.
* runtime/Operations.h:
(JSC::jsTypeofIsFunctionWithConcurrency):
(JSC::jsTypeStringForValue):
(JSC::jsTypeofIsFunction):
2020-08-25 Alexey Shvayka <shvaikalesh@gmail.com>
Implementation of the class "extends" clause incorrectly uses __proto__ for setting prototypes
https://bugs.webkit.org/show_bug.cgi?id=205848
Reviewed by Keith Miller.
To prevent `class extends` from breaking if Object.prototype.__proto__ is overridden
or removed, this patch replaces OpPutById bytecodes in ClassExprNode::emitBytecode()
with JSObject::setPrototypeDirect() invocations via OpCall.
Since the spec sets [[Prototype]] values directly [1], we are safe to skip method
table lookups and cycle checks.
Although this approach adds 4 `mov` ops to emitted bytecode for `class extends` creation,
increasing instruction count to 35, I prefer it over introducing a slow path only op.
To avoid emitting 2 extra `mov` ops, globalFuncSetPrototypeDirect() uses thisRegister().
Aligns JSC with V8 and SpiderMonkey. Derived class creation microbenchmark is neutral.
[1]: https://tc39.es/ecma262/#sec-createbuiltinfunction (step 7)
* builtins/BuiltinNames.h:
* bytecode/BytecodeDumper.cpp:
(JSC::CodeBlockBytecodeDumper<Block>::dumpConstants): Fix typo.
* bytecode/LinkTimeConstant.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitSetPrototypeOf):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::ClassExprNode::emitBytecode):
* parser/Nodes.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
2020-08-24 Keith Miller <keith_miller@apple.com>
DFG should always run CFG Simplification after Constant Folding.
https://bugs.webkit.org/show_bug.cgi?id=215286
Reviewed by Robin Morisset.
We didn't do this originally because LICM, many years ago, was
unsound if the CFG didn't have exactly the right shape around
loops. This is no longer true so we don't have to worry about
changing the CFG anymore. While, this doesn't appear to be a
speedup on JetStream 2 CFG, probably because we'd eventually
simplify the graph in B3, CFG Simplification is very cheap and
make other DFG optimizations easier in the future.
Also, remove unecessary validation rule that no exitOKs can come
before any Phi nodes in DFG. This isn't required and fails after
merging two basic blocks where the latter block has a Phi.
* dfg/DFGCFGSimplificationPhase.cpp:
(JSC::DFG::CFGSimplificationPhase::run):
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
* dfg/DFGValidate.cpp:
2020-08-24 Keith Miller <keith_miller@apple.com>
Remove MovHintRemoval phase
https://bugs.webkit.org/show_bug.cgi?id=215785
Reviewed by Saam Barati.
The MovHintRemoval phase doesn't play nicely with our OSR
Availability. Specifically, it needs to do a tricky dance where it
marks all the live ranges of the ZombieHints as not
exitOK. There's also an issue because we treated unused locals as
kill in this block, which is wrong for SSA when a MovHint is
used in another block. Since removing MovHintRemoval isn't a
performance regression, we are removing it rather than fixing bugs
related to it. Relatedly, since the only place we produce
ZombieHints is MovHintRemoval this patch also removes that node
type.
* Sources.txt:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGClobbersExitState.cpp:
(JSC::DFG::clobbersExitState):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGMayExit.cpp:
* dfg/DFGMovHintRemovalPhase.cpp: Removed.
* dfg/DFGMovHintRemovalPhase.h: Removed.
* dfg/DFGNode.h:
(JSC::DFG::Node::containsMovHint):
(JSC::DFG::Node::hasUnlinkedOperand):
* dfg/DFGNodeType.h:
* dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
(JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
* dfg/DFGPhantomInsertionPhase.cpp:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::compileInThreadImpl):
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileMovHint):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGVarargsForwardingPhase.cpp:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::validateAIState):
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
* runtime/OptionsList.h:
2020-08-24 Devin Rousso <drousso@apple.com>
Web Inspector: rename `ScriptDebugServer` subclasses/methods
https://bugs.webkit.org/show_bug.cgi?id=215363
<rdar://problem/67310441>
Reviewed by Brian Burg.
r266074 merged `Inspector::ScriptDebugServer` into `JSC::Debugger`. All subclasses and
functions should be renamed to match this change.
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* inspector/InspectorEnvironment.h:
* inspector/JSGlobalObjectDebugger.h: Renamed from Source/JavaScriptCore/inspector/JSGlobalObjectScriptDebugServer.h.
* inspector/JSGlobalObjectDebugger.cpp: Renamed from Source/JavaScriptCore/inspector/JSGlobalObjectScriptDebugServer.cpp.
* inspector/JSGlobalObjectInspectorController.h:
* inspector/JSGlobalObjectInspectorController.cpp:
* inspector/agents/InspectorAuditAgent.h:
* inspector/agents/InspectorAuditAgent.cpp:
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
* inspector/agents/InspectorRuntimeAgent.h:
* inspector/agents/InspectorRuntimeAgent.cpp:
* inspector/agents/InspectorScriptProfilerAgent.cpp:
* inspector/agents/JSGlobalObjectDebuggerAgent.cpp:
* inspector/remote/RemoteInspectionTarget.cpp:
* inspector/remote/cocoa/RemoteConnectionToTargetCocoa.mm:
2020-08-24 Devin Rousso <drousso@apple.com>
Web Inspector: allow event breakpoints to be configured
https://bugs.webkit.org/show_bug.cgi?id=215362
<rdar://problem/66932921>
Reviewed by Brian Burg.
This allows developers to do things like:
- only pause when `window.event.type` is a certain value
- ignore the first N pauses
- evaluate JavaScript whenever an event listener is invoked without pausing
* inspector/protocol/DOM.json:
Add an `options` paramater to `DOM.setBreakpointForEventListener` to allow configuration.
* inspector/protocol/DOMDebugger.json:
Add an `options` paramater to `DOMDebugger.setEventBreakpoint` to allow configuration.
* debugger/Breakpoint.h:
(JSC::Breakpoint::id const): Added.
(JSC::Breakpoint::sourceID const): Added.
(JSC::Breakpoint::lineNumber const): Added.
(JSC::Breakpoint::columnNumber const): Added.
(JSC::Breakpoint::condition const): Added.
(JSC::Breakpoint::actions const): Added.
(JSC::Breakpoint::isAutoContinue const): Added.
(JSC::Breakpoint::resetHitCount): Added.
(JSC::Breakpoint::isLinked const): Added.
(JSC::Breakpoint::isResolved const): Added.
(JSC::BreakpointsList::~BreakpointsList): Deleted.
* debugger/Breakpoint.cpp: Added.
(JSC::Breakpoint::Action::Action): Added.
(JSC::Breakpoint::create): Added.
(JSC::Breakpoint::Breakpoint): Added.
(JSC::Breakpoint::link): Added.
(JSC::Breakpoint::resolve): Added.
(JSC::Breakpoint::shouldPause): Added.
Unify `JSC::Breakpoint` and `Inspector::ScriptBreakpoint`.
* debugger/DebuggerPrimitives.h:
* debugger/Debugger.h:
* debugger/Debugger.cpp:
(JSC::Debugger::Debugger):
(JSC::Debugger::addObserver): Added.
(JSC::Debugger::removeObserver): Added.
(JSC::Debugger::canDispatchFunctionToObservers const): Added.
(JSC::Debugger::dispatchFunctionToObservers): Added.
(JSC::Debugger::sourceParsed): Added.
(JSC::Debugger::toggleBreakpoint):
(JSC::Debugger::applyBreakpoints):
(JSC::Debugger::resolveBreakpoint):
(JSC::Debugger::setBreakpoint):
(JSC::Debugger::removeBreakpoint):
(JSC::Debugger::didHitBreakpoint): Added.
(JSC::Debugger::clearBreakpoints):
(JSC::Debugger::evaluateBreakpointCondition): Added.
(JSC::Debugger::evaluateBreakpointActions): Added.
(JSC::Debugger::schedulePauseAtNextOpportunity): Added.
(JSC::Debugger::cancelPauseAtNextOpportunity): Added.
(JSC::Debugger::schedulePauseForSpecialBreakpoint): Added.
(JSC::Debugger::cancelPauseForSpecialBreakpoint): Added.
(JSC::Debugger::continueProgram):
(JSC::Debugger::stepNextExpression):
(JSC::Debugger::stepIntoStatement):
(JSC::Debugger::stepOverStatement):
(JSC::Debugger::stepOutOfFunction):
(JSC::Debugger::pauseIfNeeded):
(JSC::Debugger::handlePause): Added.
(JSC::Debugger::exceptionOrCaughtValue): Added.
(JSC::Debugger::atExpression):
(JSC::Debugger::clearNextPauseState):
(JSC::Debugger::willRunMicrotask): Added.
(JSC::Debugger::didRunMicrotask): Added.
(JSC::Debugger::hasBreakpoint): Deleted.
(JSC::Debugger::setPauseOnNextStatement): Deleted.
Unify `JSC::Debugger` and `Inspector::ScriptDebugServer` to simplify breakpoint logic.
Introduce the concept of a "special breakpoint", which is essentially a `JSC::Breakpoint`
that is expected to pause at the next opportunity but isn't tied to a particular location.
As an example, whenever an event breakpoint is hit, instead of just pausing at the next
opportunity, the newly managed `JSC::Breakpoint` is used as a "special breakpoint", allowing
for it's configuration (ie.g. condition, ignore count, actions, auto-continue) to be used.
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::objectGroupForBreakpointAction):
(Inspector::breakpointActionTypeForString): Added.
(Inspector::parseBreakpointOptions): Added.
(Inspector::InspectorDebuggerAgent::ProtocolBreakpoint::fromPayload): Added.
(Inspector::InspectorDebuggerAgent::ProtocolBreakpoint::ProtocolBreakpoint): Added.
(Inspector::InspectorDebuggerAgent::ProtocolBreakpoint::createDebuggerBreakpoint const): Added.
(Inspector::InspectorDebuggerAgent::ProtocolBreakpoint::matchesScriptURL const): Added.
(Inspector::InspectorDebuggerAgent::debuggerBreakpointFromPayload): Added.
(Inspector::InspectorDebuggerAgent::enable):
(Inspector::InspectorDebuggerAgent::disable):
(Inspector::InspectorDebuggerAgent::buildBreakpointPauseReason):
(Inspector::InspectorDebuggerAgent::handleConsoleAssert):
(Inspector::InspectorDebuggerAgent::didScheduleAsyncCall):
(Inspector::buildDebuggerLocation):
(Inspector::InspectorDebuggerAgent::setBreakpointByUrl):
(Inspector::InspectorDebuggerAgent::setBreakpoint):
(Inspector::InspectorDebuggerAgent::didSetBreakpoint):
(Inspector::InspectorDebuggerAgent::resolveBreakpoint):
(Inspector::InspectorDebuggerAgent::removeBreakpoint):
(Inspector::InspectorDebuggerAgent::continueToLocation):
(Inspector::InspectorDebuggerAgent::schedulePauseAtNextOpportunity): Added.
(Inspector::InspectorDebuggerAgent::cancelPauseAtNextOpportunity): Added.
(Inspector::InspectorDebuggerAgent::schedulePauseForSpecialBreakpoint): Added.
(Inspector::InspectorDebuggerAgent::cancelPauseForSpecialBreakpoint): Added.
(Inspector::InspectorDebuggerAgent::pause):
(Inspector::InspectorDebuggerAgent::resume):
(Inspector::InspectorDebuggerAgent::didBecomeIdle):
(Inspector::InspectorDebuggerAgent::sourceMapURLForScript):
(Inspector::InspectorDebuggerAgent::didParseSource):
(Inspector::InspectorDebuggerAgent::willRunMicrotask):
(Inspector::InspectorDebuggerAgent::didRunMicrotask):
(Inspector::InspectorDebuggerAgent::didPause):
(Inspector::InspectorDebuggerAgent::breakpointActionSound):
(Inspector::InspectorDebuggerAgent::breakpointActionProbe):
(Inspector::InspectorDebuggerAgent::clearInspectorBreakpointState):
(Inspector::InspectorDebuggerAgent::clearDebuggerBreakpointState):
(Inspector::matches): Deleted.
(Inspector::buildObjectForBreakpointCookie): Deleted.
(Inspector::InspectorDebuggerAgent::breakpointActionsFromProtocol): Deleted.
(Inspector::InspectorDebuggerAgent::schedulePauseOnNextStatement): Deleted.
(Inspector::InspectorDebuggerAgent::cancelPauseOnNextStatement): Deleted.
Create a private `ProtocolBreakpoint` class that holds the data sent by the frontend. This
is necessary because breakpoints in the frontend have a potentially one-to-many relationship
with breakpoints in the backend, as the same script can be loaded many times on a page. Each
of those scripts is independent, however, and can execute differently, meaning that the same
breakpoint for each script also needs a different state (e.g. ignore count). As such, the
`ProtocolBreakpoint` is effectively a template that is actualized whenever a new script is
parsed that matches the URL of the `ProtocolBreakpoint` to create a `JSC::Breakpoint` that
is used by the `JSC::Debugger`. `ProtocolBreakpoint` also parses breakpoint configurations.
* inspector/InspectorEnvironment.h:
* inspector/JSGlobalObjectScriptDebugServer.h:
* inspector/JSGlobalObjectScriptDebugServer.cpp:
(Inspector::JSGlobalObjectScriptDebugServer::JSGlobalObjectScriptDebugServer):
(Inspector::JSGlobalObjectScriptDebugServer::attachDebugger):
(Inspector::JSGlobalObjectScriptDebugServer::detachDebugger):
(Inspector::JSGlobalObjectScriptDebugServer::runEventLoopWhilePaused):
* inspector/agents/InspectorAuditAgent.h:
* inspector/agents/InspectorAuditAgent.cpp:
(Inspector::InspectorAuditAgent::run):
* inspector/agents/InspectorRuntimeAgent.h:
* inspector/agents/InspectorRuntimeAgent.cpp:
(Inspector::setPauseOnExceptionsState):
(Inspector::InspectorRuntimeAgent::evaluate):
(Inspector::InspectorRuntimeAgent::callFunctionOn):
(Inspector::InspectorRuntimeAgent::getPreview):
(Inspector::InspectorRuntimeAgent::getProperties):
(Inspector::InspectorRuntimeAgent::getDisplayableProperties):
* inspector/agents/InspectorScriptProfilerAgent.cpp:
* inspector/agents/JSGlobalObjectDebuggerAgent.h:
Replace `Inspector::ScriptDebugServer` with `JSC::Debugger`.
* runtime/JSMicrotask.cpp:
(JSC::JSMicrotask::run):
Drive-by: r248894 mistakenly omitted the call to notify the debugger that the microtask ran.
* inspector/ScriptBreakpoint.h: Removed.
* inspector/ScriptDebugListener.h: Removed.
* inspector/ScriptDebugServer.h: Removed.
* inspector/ScriptDebugServer.cpp: Removed.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
2020-08-24 Devin Rousso <drousso@apple.com>
Web Inspector: remove "extra domains" concept now that domains can be added based on the debuggable type
https://bugs.webkit.org/show_bug.cgi?id=201150
<rdar://problem/56545911>
Reviewed by Brian Burg.
* inspector/scripts/codegen/objc_generator_templates.py:
* inspector/augmentable/AugmentableInspectorController.h:
* inspector/JSGlobalObjectInspectorController.h:
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::connectFrontend):
(Inspector::JSGlobalObjectInspectorController::registerAlternateAgent): Added.
(Inspector::JSGlobalObjectInspectorController::appendExtraAgent): Deleted.
* inspector/InspectorAgentRegistry.h:
* inspector/InspectorAgentRegistry.cpp:
(Inspector::AgentRegistry::appendExtraAgent): Deleted.
* inspector/protocol/Inspector.json:
* inspector/agents/InspectorAgent.h:
* inspector/agents/InspectorAgent.cpp:
(Inspector::InspectorAgent::activateExtraDomain): Deleted.
(Inspector::InspectorAgent::activateExtraDomains): Deleted.
* inspector/scripts/tests/expected/command-targetType-matching-domain-debuggableType.json-result:
* inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/expected/definitions-with-mac-platform.json-result:
* inspector/scripts/tests/expected/domain-debuggableTypes.json-result:
* inspector/scripts/tests/expected/domain-targetType-matching-domain-debuggableType.json-result:
* inspector/scripts/tests/expected/domain-targetTypes.json-result:
* inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
* inspector/scripts/tests/expected/enum-values.json-result:
* inspector/scripts/tests/expected/event-targetType-matching-domain-debuggableType.json-result:
* inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result:
Rebase protocol tests.
2020-08-23 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, wrong merge resolution between r266031 and r263837
https://bugs.webkit.org/show_bug.cgi?id=209774
r263837 is landed after r266031 is configured. OSS buildbots didn't catch this since they are using old ICU headers.
* runtime/IntlNumberFormat.cpp:
(JSC::IntlNumberFormat::initializeNumberFormat):
2020-08-22 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, assertion was opposite
https://bugs.webkit.org/show_bug.cgi?id=215058
We should ensure that this is *not* zero.
* runtime/IntlObject.cpp:
(JSC::parseVariantCode):
2020-08-22 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Implement Intl Language Tag Parser
https://bugs.webkit.org/show_bug.cgi?id=215058
Reviewed by Ross Kirsling and Darin Adler.
This patch adds LanguageTagParser which performs isStructurallyValidLanguageTag[1] validation precisely.
The spec strictly defines acceptable format as language-tag and this is not the same to ICU's one and this
is even tested in test262. We should have LanguageTagParser to validate the input.
[1]: https://tc39.es/ecma402/#sec-isstructurallyvalidlanguagetag
* runtime/IntlLocale.cpp:
(JSC::LocaleIDBuilder::initialize):
(JSC::IntlLocale::initializeLocale):
* runtime/IntlObject.cpp:
(JSC::canonicalizeLocaleList):
(JSC::parseVariantCode):
(JSC::convertToUnicodeSingletonIndex):
(JSC::isUnicodeExtensionAttribute):
(JSC::isUnicodeExtensionKey):
(JSC::isUnicodeExtensionTypeComponent):
(JSC::isUnicodePUExtensionValue):
(JSC::isUnicodeOtherExtensionValue):
(JSC::isUnicodeTKey):
(JSC::isUnicodeTValueComponent):
(JSC::LanguageTagParser::LanguageTagParser):
(JSC::LanguageTagParser::isEOS):
(JSC::LanguageTagParser::next):
(JSC::LanguageTagParser::parseUnicodeLocaleId):
(JSC::LanguageTagParser::parseUnicodeLanguageId):
(JSC::LanguageTagParser::parseUnicodeExtensionAfterPrefix):
(JSC::LanguageTagParser::parseTransformedExtensionAfterPrefix):
(JSC::LanguageTagParser::parseOtherExtensionAfterPrefix):
(JSC::LanguageTagParser::parsePUExtensionAfterPrefix):
(JSC::LanguageTagParser::parseExtensionsAndPUExtensions):
(JSC::isStructurallyValidLanguageTag):
(JSC::isUnicodeLanguageId):
* runtime/IntlObject.h:
2020-08-22 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, workaround for old ICU headers in macOS Catalina bots
https://bugs.webkit.org/show_bug.cgi?id=209774
EWS and Catalina bots are inconsistent in terms of ICU header versions.
This patch adds a workaround which checks ICU header version too at runtime.
* tools/JSDollarVM.cpp:
(JSC::functionICUHeaderVersion):
(JSC::JSDollarVM::finishCreation):
2020-08-22 Alexey Shvayka <shvaikalesh@gmail.com>
The [[ThrowTypeError]] function object must not be extensible
https://bugs.webkit.org/show_bug.cgi?id=108873
Reviewed by Yusuke Suzuki.
This patch:
1. Sets the value of %ThrowTypeError% "name" property to the empty string,
as required [1] for anonymous built-in functions.
2. Calls JSObject::freeze() on %ThrowTypeError%, making it non-extensible and
its "name" and "length" properties non-configurable to match the spec [2].
Both changes align JSC with V8 and SpiderMonkey.
[1]: https://tc39.es/ecma262/#sec-ecmascript-standard-built-in-objects
[2]: https://tc39.es/ecma262/#sec-%throwtypeerror%
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
2020-08-22 Yusuke Suzuki <ysuzuki@apple.com>
[ECMA-402] Intl.DateTimeFormat dateStyle/timeStyle missing in WebKit
https://bugs.webkit.org/show_bug.cgi?id=209776
Reviewed by Darin Adler and Ross Kirsling.
This patch implements Intl.DateTimeFormat dateStyle and timeStyle options. When it is specified,
we query the best date-time format with these options to ICU instead of configuring each date-time
formats.
Since ECMA402 requires enforcement of hourCycle specified from the option, even if ICU ignores that.
So, after getting the appropriate pattern from ICU, we modify this pattern and re-create UDateFormat
from the modified pattern.
* builtins/DatePrototype.js:
(toLocaleString.toDateTimeOptionsAnyAll):
(toLocaleString):
(toLocaleDateString.toDateTimeOptionsDateDate):
(toLocaleDateString):
(toLocaleTimeString.toDateTimeOptionsTimeTime):
(toLocaleTimeString):
* runtime/CommonIdentifiers.h:
* runtime/IntlDateTimeFormat.cpp:
(JSC::toDateTimeOptionsAnyDate):
(JSC::IntlDateTimeFormat::initializeDateTimeFormat):
(JSC::IntlDateTimeFormat::formatStyleString):
(JSC::IntlDateTimeFormat::resolvedOptions const):
* runtime/IntlDateTimeFormat.h:
2020-08-22 Yusuke Suzuki <ysuzuki@apple.com>
[ECMA-402] Implement Intl.DateTimeFormat.prototype.formatRange
https://bugs.webkit.org/show_bug.cgi?id=209778
Reviewed by Ross Kirsling.
This patch adds Intl.DateTimeFormat#formatRange. It takes two dates, and
generates formatted text which represents interval between these two dates.
We skip the implementation of Intl.DateTimeFormat#formatRangeToParts since
ICU udtitvfmt_formatToResult API is not getting stable state yet. We retrieve
pattern from UDateFormat, get skeleton from that pattern, and construct
UDateIntervalFormat from this skeleton.
* runtime/IntlDateTimeFormat.cpp:
(JSC::IntlDateTimeFormat::initializeDateTimeFormat):
(JSC::IntlDateTimeFormat::createDateIntervalFormatIfNecessary):
(JSC::IntlDateTimeFormat::formatRange):
(JSC::IntlDateTimeFormat::UDateFormatDeleter::operator() const): Deleted.
* runtime/IntlDateTimeFormat.h:
* runtime/IntlDateTimeFormatPrototype.cpp:
(JSC::IntlDateTimeFormatPrototypeFuncFormatRange):
2020-08-22 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Add Intl.Segmenter
https://bugs.webkit.org/show_bug.cgi?id=213638
Reviewed by Ross Kirsling.
This patch implements Intl.Segmenter[1]. Intl.Segmenter offers access to ICU break iterator feature, which can break strings into grapheme cluster / words / sentences.
[1]: https://github.com/tc39/proposal-intl-segmenter
* CMakeLists.txt:
* DerivedSources-input.xcfilelist:
* DerivedSources-output.xcfilelist:
* DerivedSources.make:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* runtime/CommonIdentifiers.h:
* runtime/IntlObject.cpp:
(JSC::createSegmenterConstructor):
(JSC::IntlObject::finishCreation):
(JSC::intlSegmenterAvailableLocales):
* runtime/IntlObject.h:
* runtime/IntlSegmentIterator.cpp: Added.
(JSC::IntlSegmentIterator::create):
(JSC::IntlSegmentIterator::createStructure):
(JSC::IntlSegmentIterator::IntlSegmentIterator):
(JSC::IntlSegmentIterator::finishCreation):
(JSC::IntlSegmentIterator::visitChildren):
(JSC::IntlSegmentIterator::next):
* runtime/IntlSegmentIterator.h: Added.
* runtime/IntlSegmentIteratorPrototype.cpp: Added.
(JSC::IntlSegmentIteratorPrototype::create):
(JSC::IntlSegmentIteratorPrototype::createStructure):
(JSC::IntlSegmentIteratorPrototype::IntlSegmentIteratorPrototype):
(JSC::IntlSegmentIteratorPrototype::finishCreation):
(JSC::IntlSegmentIteratorPrototypeFuncNext):
* runtime/IntlSegmentIteratorPrototype.h: Added.
* runtime/IntlSegmenter.cpp: Added.
(JSC::IntlSegmenter::create):
(JSC::IntlSegmenter::createStructure):
(JSC::IntlSegmenter::IntlSegmenter):
(JSC::IntlSegmenter::finishCreation):
(JSC::IntlSegmenter::initializeSegmenter):
(JSC::IntlSegmenter::segment const):
(JSC::IntlSegmenter::resolvedOptions const):
(JSC::IntlSegmenter::granularityString):
(JSC::IntlSegmenter::createSegmentDataObject):
* runtime/IntlSegmenter.h: Added.
* runtime/IntlSegmenterConstructor.cpp: Added.
(JSC::IntlSegmenterConstructor::create):
(JSC::IntlSegmenterConstructor::createStructure):
(JSC::IntlSegmenterConstructor::IntlSegmenterConstructor):
(JSC::IntlSegmenterConstructor::finishCreation):
(JSC::constructIntlSegmenter):
(JSC::callIntlSegmenter):
(JSC::IntlSegmenterConstructorSupportedLocalesOf):
* runtime/IntlSegmenterConstructor.h: Added.
* runtime/IntlSegmenterPrototype.cpp: Added.
(JSC::IntlSegmenterPrototype::create):
(JSC::IntlSegmenterPrototype::createStructure):
(JSC::IntlSegmenterPrototype::IntlSegmenterPrototype):
(JSC::IntlSegmenterPrototype::finishCreation):
(JSC::IntlSegmenterPrototypeFuncSegment):
(JSC::IntlSegmenterPrototypeFuncResolvedOptions):
* runtime/IntlSegmenterPrototype.h: Added.
* runtime/IntlSegments.cpp: Added.
(JSC::IntlSegments::create):
(JSC::IntlSegments::createStructure):
(JSC::IntlSegments::IntlSegments):
(JSC::IntlSegments::finishCreation):
(JSC::IntlSegments::containing):
(JSC::IntlSegments::createSegmentIterator):
(JSC::IntlSegments::visitChildren):
* runtime/IntlSegments.h: Added.
* runtime/IntlSegmentsPrototype.cpp: Added.
(JSC::IntlSegmentsPrototype::create):
(JSC::IntlSegmentsPrototype::createStructure):
(JSC::IntlSegmentsPrototype::IntlSegmentsPrototype):
(JSC::IntlSegmentsPrototype::finishCreation):
(JSC::IntlSegmentsPrototypeFuncContaining):
(JSC::IntlSegmentsPrototypeFuncIterator):
* runtime/IntlSegmentsPrototype.h: Added.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::segmentIteratorStructure):
(JSC::JSGlobalObject::segmenterStructure):
(JSC::JSGlobalObject::segmentsStructure):
* runtime/OptionsList.h:
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2020-08-22 Yusuke Suzuki <ysuzuki@apple.com>
[ECMA-402] Implement unified Intl.NumberFormat
https://bugs.webkit.org/show_bug.cgi?id=209774
Reviewed by Ross Kirsling and Darin Adler.
This patch implements updated Intl.NumberFormat. This update was proposed in [1], and integrated into ECMA-402 spec.
This patch adds support for missing features in the previous Intl.NumberFormat implementation. Adding "unit", "unitDisplay",
"signDisplay", "notation", and "currencySign". Then Intl.NumberFormat can now handle "unit" etc.
To support new features, we need to use UNumberFormatter which is available after ICU 64 (while it is offered in ICU 62, some
critical part are added in 64 too). So, we keep the old UNumberFormat based implementation which is used for [60, 64) since WebKit
currently supports ICU 60. Old implementation does not support new things. If ICU is 64 or later, Intl.NumberFormat starts using
UNumberFormatter, and implements all the specified features.
[1]: https://github.com/tc39/proposal-unified-intl-numberformat
* JavaScriptCore.xcodeproj/project.pbxproj:
* runtime/IntlCollator.cpp:
(JSC::IntlCollator::UCollatorDeleter::operator() const): Deleted.
* runtime/IntlCollator.h:
* runtime/IntlDateTimeFormat.cpp:
(JSC::IntlDateTimeFormat::UDateFormatDeleter::operator() const): Deleted.
* runtime/IntlDateTimeFormat.h:
* runtime/IntlNumberFormat.cpp:
(JSC::computeCurrencyDigits):
(JSC::sanctionedSimpleUnitIdentifier):
(JSC::WellFormedUnit::WellFormedUnit):
(JSC::wellFormedUnitIdentifier):
(JSC::IntlNumberFormat::initializeNumberFormat):
(JSC::IntlNumberFormat::format const):
(JSC::IntlNumberFormat::styleString):
(JSC::IntlNumberFormat::currencyDisplayString):
(JSC::IntlNumberFormat::notationString):
(JSC::IntlNumberFormat::currencySignString):
(JSC::IntlNumberFormat::unitDisplayString):
(JSC::IntlNumberFormat::compactDisplayString):
(JSC::IntlNumberFormat::signDisplayString):
(JSC::IntlNumberFormat::resolvedOptions const):
(JSC::partTypeString):
(JSC::IntlNumberFormat::formatToPartsInternal):
(JSC::IntlNumberFormat::formatToParts const):
(JSC::IntlNumberFormat::UNumberFormatDeleter::operator() const): Deleted.
* runtime/IntlNumberFormat.h:
* runtime/IntlNumberFormatInlines.h: Added.
(JSC::setNumberFormatDigitOptions):
(JSC::IntlFieldIterator::IntlFieldIterator):
(JSC::IntlFieldIterator::next):
* runtime/IntlPluralRules.cpp:
(JSC::IntlPluralRules::initializePluralRules):
(JSC::IntlPluralRules::resolvedOptions const):
(JSC::IntlPluralRules::UPluralRulesDeleter::operator() const): Deleted.
(JSC::IntlPluralRules::UNumberFormatDeleter::operator() const): Deleted.
(JSC::UEnumerationDeleter::operator() const): Deleted.
* runtime/IntlPluralRules.h:
* runtime/IntlRelativeTimeFormat.cpp:
(JSC::IntlRelativeTimeFormat::formatToParts const):
(JSC::IntlRelativeTimeFormat::URelativeDateTimeFormatterDeleter::operator() const): Deleted.
(JSC::IntlRelativeTimeFormat::UNumberFormatDeleter::operator() const): Deleted.
* runtime/IntlRelativeTimeFormat.h:
* tools/JSDollarVM.cpp:
(JSC::functionICUVersion):
2020-08-21 Yusuke Suzuki <ysuzuki@apple.com>
Console object's @@toStringTag should be "console" instead of "Console"
https://bugs.webkit.org/show_bug.cgi?id=215750
Reviewed by Ross Kirsling.
Use "console" instead of "Console". Now, namespace object has @@toStringTag.
https://github.com/web-platform-tests/wpt/pull/24717
* runtime/ConsoleObject.cpp:
2020-08-22 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Enable Intl.DisplayNames
https://bugs.webkit.org/show_bug.cgi?id=215749
Reviewed by Ross Kirsling.
Enable Intl.DisplayNames by default. This is already stage 4 and integrated into the spec.
* runtime/IntlObject.cpp:
(JSC::IntlObject::finishCreation):
* runtime/OptionsList.h:
2020-08-21 Alexey Shvayka <shvaikalesh@gmail.com>
StrictEq should not care about masqueradesAsUndefinedWatchpoint
https://bugs.webkit.org/show_bug.cgi?id=215743
Reviewed by Yusuke Suzuki.
This patch removes masqueradesAsUndefinedWatchpoint handling for StrictEq
from fixupCompareStrictEqAndSameValue(), aligning it with SameValue.
According to the spec [1], only a few language constructs special-case
[[IsHTMLDDA]] objects: ToBoolean, abstract equality, and `typeof`.
No behavior change.
[1]: https://tc39.es/ecma262/#sec-IsHTMLDDA-internal-slot
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupCompareStrictEqAndSameValue):
2020-08-21 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r265965.
https://bugs.webkit.org/show_bug.cgi?id=215744
getCallData can be called from DFG concurrent compiler, but it
is not safe in DOM PluginObject
Reverted changeset:
"Use jsTypeofIsObject() in DFG AI and
operationTypeOfIsObject()"
https://bugs.webkit.org/show_bug.cgi?id=144457
https://trac.webkit.org/changeset/265965
2020-08-21 Alexey Shvayka <shvaikalesh@gmail.com>
Align "length" properties of function prototypes with the spec
https://bugs.webkit.org/show_bug.cgi?id=215716
Reviewed by Ross Kirsling.
This change defines Function.prototype.length [1] as [[Configurable]] and
removes "length" properties from other (async/generator) function prototypes
that are ordinary non-callable objects [2], aligning JSC with V8 and SpiderMonkey.
Also, adds inherits() ASSERT in FunctionPrototype::finishCreation()
to match (most of) the other built-ins.
[1]: https://tc39.es/ecma262/#sec-properties-of-the-function-prototype-object
[2]: https://tc39.es/ecma262/#sec-async-function-prototype-properties
* runtime/AsyncFunctionPrototype.cpp:
(JSC::AsyncFunctionPrototype::finishCreation):
* runtime/AsyncGeneratorFunctionPrototype.cpp:
(JSC::AsyncGeneratorFunctionPrototype::finishCreation):
* runtime/FunctionPrototype.cpp:
(JSC::FunctionPrototype::finishCreation):
* runtime/GeneratorFunctionPrototype.cpp:
(JSC::GeneratorFunctionPrototype::finishCreation):
2020-08-21 Alexey Shvayka <shvaikalesh@gmail.com>
Define Intl[Symbol.toStringTag]
https://bugs.webkit.org/show_bug.cgi?id=215715
Reviewed by Ross Kirsling.
This patch utilizes JSC_TO_STRING_TAG_WITHOUT_TRANSITION() to define Symbol.toStringTag
on Intl namespace object, implementing the recent spec change [1] and aligning JSC with V8.
Also, adds inherits() ASSERT to match (most of) the other built-ins.
[1]: https://github.com/tc39/ecma402/pull/487
* runtime/IntlObject.cpp:
(JSC::IntlObject::finishCreation):
2020-08-21 Alexey Shvayka <shvaikalesh@gmail.com>
Function.prototype.bind should not clamp "length" to int32
https://bugs.webkit.org/show_bug.cgi?id=215733
Reviewed by Darin Adler.
This patch fixes to integer conversion of target function's "length" values
beyond UINT_MAX, aligning JSC with the spec [1], V8 and SpiderMonkey.
`double` is used instead of `uint64_t` to retain semantics of JS Number type [2]
and hold Infinity values. To avoid spreading `double length` over JSFunction::create()
and its subclasses, JSBoundFunction is modified to use JSFunction::finishCreation(VM&)
overload, removing 2 unused arguments and speeding up bound function creation by ~9%.
[1]: https://tc39.es/ecma262/#sec-function.prototype.bind (step 6.c.i)
[2]: https://tc39.es/ecma262/#sec-ecmascript-language-types-number-type
* builtins/FunctionPrototype.js:
(bind):
* runtime/JSBoundFunction.cpp:
(JSC::JSBoundFunction::create):
(JSC::JSBoundFunction::JSBoundFunction):
(JSC::JSBoundFunction::finishCreation):
* runtime/JSBoundFunction.h:
* runtime/JSFunction.cpp:
(JSC::JSFunction::finishCreation):
(JSC::JSFunction::reifyLength):
* runtime/JSGlobalObject.cpp:
(JSC::makeBoundFunction):
2020-08-20 Saam Barati <sbarati@apple.com>
Replace IC on Proxy must write barrier Proxy's target
https://bugs.webkit.org/show_bug.cgi?id=215720
Reviewed by Yusuke Suzuki.
The put_by_id opcode in the baseline and the DFG/FTl will emit a writeBarrier
after the operation is complete. But it does this to the base object. In the
case of an IC with the base as a Proxy, we're not actually storing to the Proxy, but
instead, the Proxy's target. This patch makes it so our IC code writeBarriers
the Proxy's target. This fixed a crash when running Speedometer2.
* bytecode/AccessCase.cpp:
(JSC::AccessCase::canReplace const):
(JSC::AccessCase::generateImpl):
* bytecode/PolymorphicAccess.cpp:
(JSC::AccessGenerationState::preserveLiveRegistersToStackForCallWithoutExceptions):
* bytecode/PolymorphicAccess.h:
2020-08-20 Alexey Shvayka <shvaikalesh@gmail.com>
Invalid early errors for class methods named "constructor" and "prototype"
https://bugs.webkit.org/show_bug.cgi?id=215413
Reviewed by Darin Adler.
This change removes invalid early syntax errors, allowing static async/generator
methods named "constructor" and instance async/generator methods named "prototype",
which aligns JSC with the spec [1], V8, and SpiderMonkey.
Also, removes a FIXME related to super() calls outside constructor that was
resolved in r181404 and is covered by test262 suite.
[1]: https://tc39.es/ecma262/#sec-class-definitions-static-semantics-early-errors
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseClass):
2020-08-20 Alexey Shvayka <shvaikalesh@gmail.com>
Use jsTypeofIsObject() in DFG AI and operationTypeOfIsObject()
https://bugs.webkit.org/show_bug.cgi?id=144457
Reviewed by Saam Barati.
This patch:
1. Refactors jsTypeofIsObject(), leveraging fast path of isCallable(),
moves it to the header, and utilizes it in DFG AI and
operationTypeOfIsObject() to eliminate code duplication.
2. Splits jsTypeofIsFunction() into 2 methods to accomodate
operationTypeOfIsFunction() calling it with JSObject* argument.
3. Removes orphaned slow_path_is_object declaration.
No behavior change, `typeof` microbenchmarks are neutral.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGOperations.cpp:
* runtime/CommonSlowPaths.h:
* runtime/Operations.cpp:
(JSC::jsTypeofIsObject): Deleted.
* runtime/Operations.h:
(JSC::jsTypeofIsObject):
(JSC::jsTypeofIsFunction):
2020-08-19 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Add Object.getOwnPropertyNames caching as it is done for Object.keys, and accelerate Object.getOwnPropertyDescriptor
https://bugs.webkit.org/show_bug.cgi?id=215666
Reviewed by Saam Barati.
Object.getOwnPropertyNames is immutable for Structure if structure meets some conditions. And we have optimization for Object.keys.
This patch wires existing caching mechanism for Object.keys to Object.getOwnPropertyNames so that Object.getOwnPropertyNames has
full support of caching & inlined code in DFG / FTL.
We also pre-bake structure for the result of Object.getOwnPropertyDescriptor so that we do not need to perform hash table lookup every
time we create an object for Object.getOwnPropertyDescriptor. This makes Object.getOwnPropertyDescriptor 2x faster from the microbenchmark.
The above two optimization makes Speedometer2/Inferno-TodoMVC 7% faster, and it also optimizes Speedometer2/EmberJS-Debug by 5%.
In total, we can get 0.7 - 1.0% progression in Speedometer2.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileObjectKeysOrObjectGetOwnPropertyNames):
(JSC::DFG::SpeculativeJIT::compileObjectKeys): Deleted.
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileObjectKeysOrObjectGetOwnPropertyNames):
(JSC::FTL::DFG::LowerDFGToB3::compileObjectKeys): Deleted.
* runtime/Intrinsic.cpp:
(JSC::intrinsicName):
* runtime/Intrinsic.h:
* runtime/IteratorOperations.cpp:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::dataPropertyDescriptorObjectStructure const):
(JSC::JSGlobalObject::accessorPropertyDescriptorObjectStructure const):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncOwnKeys):
* runtime/ObjectConstructor.cpp:
(JSC::objectConstructorGetOwnPropertyNames):
(JSC::objectConstructorGetOwnPropertySymbols):
(JSC::objectConstructorKeys):
(JSC::ownPropertyKeys):
(JSC::constructObjectFromPropertyDescriptorSlow):
* runtime/ObjectConstructor.h:
(JSC::createDataPropertyDescriptorObjectStructure):
(JSC::createAccessorPropertyDescriptorObjectStructure):
(JSC::constructObjectFromPropertyDescriptor):
* runtime/ReflectObject.cpp:
(JSC::reflectObjectOwnKeys):
* runtime/Structure.cpp:
(JSC::Structure::canCachePropertyNameEnumerator const):
* runtime/Structure.h:
* runtime/StructureInlines.h:
(JSC::Structure::setCachedPropertyNames):
(JSC::Structure::cachedPropertyNames const):
(JSC::Structure::cachedPropertyNamesIgnoringSentinel const):
(JSC::Structure::canCacheOwnPropertyNames const):
(JSC::Structure::setCachedOwnKeys): Deleted.
(JSC::Structure::cachedOwnKeys const): Deleted.
(JSC::Structure::cachedOwnKeysIgnoringSentinel const): Deleted.
(JSC::Structure::canCacheOwnKeys const): Deleted.
* runtime/StructureRareData.cpp:
(JSC::StructureRareData::visitChildren):
* runtime/StructureRareData.h:
* runtime/StructureRareDataInlines.h:
(JSC::StructureRareData::cachedPropertyNames const):
(JSC::StructureRareData::cachedPropertyNamesIgnoringSentinel const):
(JSC::StructureRareData::cachedPropertyNamesConcurrently const):
(JSC::StructureRareData::setCachedPropertyNames):
(JSC::StructureRareData::cachedOwnKeys const): Deleted.
(JSC::StructureRareData::cachedOwnKeysIgnoringSentinel const): Deleted.
(JSC::StructureRareData::cachedOwnKeysConcurrently const): Deleted.
(JSC::StructureRareData::setCachedOwnKeys): Deleted.
2020-08-19 Alexey Shvayka <shvaikalesh@gmail.com>
Introduce OpIsCallable bytecode and intrinsic
https://bugs.webkit.org/show_bug.cgi?id=215572
Reviewed by Ross Kirsling and Saam Barati.
This patch:
1. Aligns slow_path_is_function with DFG/FTL implementations by introducing
jsTypeofIsFunction() helper. This fixes `typeof document.all === "function"`
to return `false` instead of `true`.
2. Renames is_function bytecode op to typeof_is_function, aligning it with
typeof_is_undefined and typeof_is_object. New name offers better semantics
and clearly communicates the op should be avoided when implementing new
features because of `typeof` behavior with [[IsHTMLDDA]] objects [1].
3. Adds is_callable bytecode op and utilizes it in built-ins via intrinsic,
removing `typeof callback === "function"` checks. This prevents [[IsHTMLDDA]]
objects from being considered non-callable [2].
To preserve the fast path for JSFunctionType,
createFunctionThatMasqueradesAsUndefined() is relocated to InternalFunction.
`typeof` microbenchmarks are neutral.
[1]: https://tc39.es/ecma262/#sec-IsHTMLDDA-internal-slot-typeof
[2]: https://tc39.es/ecma262/#sec-array.prototype.map (step 3)
* builtins/ArrayConstructor.js:
* builtins/ArrayPrototype.js:
(reduce):
(reduceRight):
(every):
(forEach):
(filter):
(map):
(some):
(find):
(findIndex):
(sort):
(flatMap):
* builtins/FunctionPrototype.js:
(overriddenName.string_appeared_here.symbolHasInstance):
(bind):
* builtins/MapPrototype.js:
(forEach):
* builtins/PromiseConstructor.js:
(all):
(allSettled):
(any):
(race):
(nakedConstructor.Promise):
(nakedConstructor.InternalPromise):
* builtins/PromiseOperations.js:
(globalPrivate.newPromiseCapabilitySlow):
(globalPrivate.resolvePromise):
(globalPrivate.resolveWithoutPromise):
* builtins/PromisePrototype.js:
(finally):
(globalPrivate.getThenFinally):
(globalPrivate.getCatchFinally):
* builtins/ReflectObject.js:
(apply):
* builtins/RegExpPrototype.js:
(globalPrivate.regExpExec):
(overriddenName.string_appeared_here.replace):
* builtins/SetPrototype.js:
(forEach):
* builtins/TypedArrayConstructor.js:
* builtins/TypedArrayPrototype.js:
(every):
(find):
(findIndex):
(forEach):
(some):
(sort):
(reduce):
(reduceRight):
(map):
(filter):
* bytecode/BytecodeIntrinsicRegistry.h:
* bytecode/BytecodeList.rb:
* bytecode/BytecodeUseDef.cpp:
(JSC::computeUsesForBytecodeIndexImpl):
(JSC::computeDefsForBytecodeIndexImpl):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitEqualityOpImpl):
(JSC::BytecodeGenerator::emitIsCallable):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGHeapLocation.cpp:
(WTF::printInternal):
* dfg/DFGHeapLocation.h:
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileIsCallable):
(JSC::DFG::SpeculativeJIT::compileIsFunction): Deleted.
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileIsCallable):
(JSC::FTL::DFG::LowerDFGToB3::compileIsFunction): Deleted.
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
* jit/JITOperations.h:
* jsc.cpp:
(functionMakeMasquerader):
* llint/LowLevelInterpreter.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
* runtime/InternalFunction.cpp:
(JSC::InternalFunction::createFunctionThatMasqueradesAsUndefined):
* runtime/InternalFunction.h:
* runtime/JSFunction.cpp:
(JSC::JSFunction::createFunctionThatMasqueradesAsUndefined): Deleted.
* runtime/JSFunction.h:
* runtime/Operations.h:
(JSC::jsTypeofIsFunction):
2020-08-19 Saam Barati <sbarati@apple.com>
REGRESSION (r265775): DFG ASSERTION FAILED: AI-clobberize disagreement; AI says FoldedClobber while clobberize says (Direct:[], Super:[])
https://bugs.webkit.org/show_bug.cgi?id=215639
<rdar://problem/67376432>
Reviewed by Robin Morisset.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2020-08-19 Tadeu Zagallo <tzagallo@apple.com>
B3 IntRange is incorrect for negative masks
https://bugs.webkit.org/show_bug.cgi?id=215536
<rdar://problem/67130430>
Reviewed by Michael Saboff and Robin Morisset.
In the B3 ReduceStrength phase, we compute rangeForMask as (0, mask). This is correct for
positive values, but incorrect when negative. To fix it, we use `(INT_MIN & mask, INT_MAX & mask)`
as the range for negative masks.
* b3/B3ReduceStrength.cpp:
* b3/testb3.h:
* b3/testb3_1.cpp:
(run):
* b3/testb3_5.cpp:
(testCheckSubBitAnd):
2020-08-18 Saam Barati <sbarati@apple.com>
Update byte offsets in JSString.h comment
https://bugs.webkit.org/show_bug.cgi?id=215621
Reviewed by Yusuke Suzuki.
* runtime/JSString.h:
2020-08-17 Saam Barati <sbarati@apple.com>
Have an OOB+SaneChain Array::Speculation
https://bugs.webkit.org/show_bug.cgi?id=215487
Reviewed by Yusuke Suzuki.
This patch adds a new ArrayMode speculation in the DFG/FTL called OutOfBoundsSaneChain.
It allows us to do fast things when we go OOB, like simply return undefined.
This is because we install watchpoints on the prototype chain to ensure they
have no indexed properties. This patch implements OutOfBoundsSaneChain on
GetByVal over Int32/Double/Contiguous original JS arrays. We can extend it in
the future to non original JS arrays if we prove their prototype is Array.prototype.
To implement this properly, we also need to ensure that the index isn't negative,
as Array.prototype/Object.prototype may have negative indexed accessors. We
do this via speculation, and if we ever recompile, and see an exit because of
this, we will stop speculating OutOfBoundsSaneChain.
This is about 20% faster on crypto-md5-SP. And ~3-4x faster on the
microbenchmarks I created.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGArrayMode.cpp:
(JSC::DFG::ArrayMode::refine const):
(JSC::DFG::arraySpeculationToString):
* dfg/DFGArrayMode.h:
(JSC::DFG::ArrayMode::isInBoundsSaneChain const):
(JSC::DFG::ArrayMode::isOutOfBoundsSaneChain const):
(JSC::DFG::ArrayMode::isOutOfBounds const):
(JSC::DFG::ArrayMode::isEffectfulOutOfBounds const):
(JSC::DFG::ArrayMode::isInBounds const):
(JSC::DFG::ArrayMode::isSaneChain const): Deleted.
* dfg/DFGCSEPhase.cpp:
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::checkArray):
(JSC::DFG::FixupPhase::setSaneChainIfPossible):
(JSC::DFG::FixupPhase::convertToHasIndexedProperty):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileGetByValOnString):
(JSC::DFG::SpeculativeJIT::compileHasIndexedProperty):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGValidate.cpp:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
(JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
(JSC::FTL::DFG::LowerDFGToB3::compileHasIndexedProperty):
2020-08-16 Alexey Shvayka <shvaikalesh@gmail.com>
Remove OpIsObjectOrNull from ClassExprNode::emitBytecode()
https://bugs.webkit.org/show_bug.cgi?id=214525
Reviewed by Keith Miller.
This patch:
1. Replaces OpIsObjectOrNull in ClassExprNode::emitBytecode() [1] with emitIsObject() +
emitIsNull(), preventing DFG/FTL from throwing a TypeError if `document.all` is the
value of superclass "prototype" property, which aligns JSC with V8 and SpiderMonkey.
Also, tweaks error message to reflect that `null` is allowed.
2. Renames is_object_or_null bytecode op to typeof_is_object, fixing the confusing
operationObjectIsObject() name, and aligns it with typeof_is_undefined.
New name offers better semantics and clearly communicates the op should be avoided when
implementing new features because of `typeof` behavior with [[IsHTMLDDA]] objects [2].
[1]: https://tc39.es/ecma262/#sec-runtime-semantics-classdefinitionevaluation (step 5.g.ii)
[2]: https://tc39.es/ecma262/#sec-IsHTMLDDA-internal-slot-typeof
* bytecode/BytecodeList.rb:
* bytecode/BytecodeUseDef.cpp:
(JSC::computeUsesForBytecodeIndexImpl):
(JSC::computeDefsForBytecodeIndexImpl):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitEqualityOpImpl):
* bytecompiler/NodesCodegen.cpp:
(JSC::ClassExprNode::emitBytecode):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGHeapLocation.cpp:
(WTF::printInternal):
* dfg/DFGHeapLocation.h:
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileTypeOfIsObject):
(JSC::DFG::SpeculativeJIT::compileIsObjectOrNull): Deleted.
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileTypeOfIsObject):
(JSC::FTL::DFG::LowerDFGToB3::compileIsObjectOrNull): Deleted.
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
* llint/LowLevelInterpreter.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
* runtime/Operations.cpp:
(JSC::jsTypeofIsObject):
(JSC::jsIsObjectTypeOrNull): Deleted.
* runtime/Operations.h:
2020-08-15 Adrian Perez de Castro <aperez@igalia.com>
Unreviewed non-unified source build fix
* dfg/DFGOSRAvailabilityAnalysisPhase.cpp: Add missing OperandsInlines.h header.
2020-08-14 Caio Lima <ticaiolima@gmail.com>
[ARMv7][JSC] Conservative GC is not considering `r7` as a root
https://bugs.webkit.org/show_bug.cgi?id=215512
Reviewed by Yusuke Suzuki.
Since `r7` is a callee-saved register on ARMv7
we need to consider it as a conservative root.
See the statement "A subroutine must preserve
the contents of the registers r4-r8, r10, r11
and SP (and r9 in PCS variants that designate
r9 as v6) form page 15 of
https://developer.arm.com/documentation/ihi0042/f/.
* heap/RegisterState.h:
2020-08-12 Keith Miller <keith_miller@apple.com>
OSRAvailabilityAnalysis shouldn't mark GetStack nodes directly as valid places for recovery
https://bugs.webkit.org/show_bug.cgi?id=215434
Reviewed by Saam Barati.
It's somewhat subtle why we cannot use the node for the GetStack
itself in the Availability's node field. The reason is that if we
did we would need to make any phase that converts nodes to
GetStack availability aware. For instance, a place where this
could come up is in constant folding if you had a graph like the
following, which could arise from PutStack sinking:
BB#1:
@1: NewObject()
@2: MovHint(@1, inline-arg1)
@3: Jump(#2, #3)
BB#2:
@4: PutStack(@1, inline-arg1)
@5: GetMyArgumentByVal(inline-arg1)
@6: Jump(#3)
BB#3:
@7: InvalidationPoint()
If constant folding converts @5 to a GetStack then at @7
inline-arg1 won't be available since at the end of BB#1 our
availability is (@1, DeadFlush) and (@5,
FlushedAt(inline-arg1)). When that gets merged at BB#3 then the
availability will be (nullptr, ConflictingFlush).
This patch also makes validation check that availability is sane
at each pontential exit site if
Options::validateFTLOSRExitLiveness() is set. Since this is
actually a Phase we also need to make sure that we don't infinite
loop, so there is now a m_isValidating field on m_graph. The
validateOSRExitAvailability phase is also careful not to modify
the Graph, in order to avoid masking bugs when validating.
In a followup patch I intend to look into why MovHint elimination
will convert:
@2: MovHint(@0, loc1, bc#1, ExitInvalid)
@3: KillStack(loc1, bc#2, ExitValid)
@4: MovHint(@1 loc1, bc#2, ExitInvalid)
into
@2: ZombieHint(@0, loc1, bc#1, ExitInvalid)
@3: KillStack(loc1, bc#2, ExitValid)
@4: MovHint(@1 loc1, bc#2, ExitInvalid)
when loc1 is live in the bytecode at bc#2. But for now, the
validation rule works around this by only checking when mayExit
and the nodes exitOK agree exiting is possible.
* dfg/DFGGraph.h:
* dfg/DFGOSRAvailabilityAnalysisPhase.cpp:
(JSC::DFG::OSRAvailabilityAnalysisPhase::OSRAvailabilityAnalysisPhase):
(JSC::DFG::OSRAvailabilityAnalysisPhase::run):
(JSC::DFG::performOSRAvailabilityAnalysis):
(JSC::DFG::validateOSRExitAvailability):
(JSC::DFG::LocalOSRAvailabilityCalculator::executeNode):
* dfg/DFGOSRAvailabilityAnalysisPhase.h:
* dfg/DFGPhase.h:
(JSC::DFG::runPhase):
* dfg/DFGValidate.cpp:
2020-08-13 Alexey Shvayka <shvaikalesh@gmail.com>
Cache Structure::attributeChangeTransition()
https://bugs.webkit.org/show_bug.cgi?id=214890
Reviewed by Yusuke Suzuki.
With this change, a non-dictionary structure adds attribute-change transitions
to transition table, making redefinition to previous atttributes a fast path.
After too many transitions, the structure becomes a dictionary, firing the
transition watchpoint. Attribute-change transitions pin their property tables,
preventing forEachPropertyConcurrently() traversal.
This patch advances provided microbenchmark by ~90% and progresses
Speedometer2/EmberJS-Debug-TodoMVC by ~12% (~5% over r264573).
No behavior change.
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::getRegExpPrototypeProperty):
* runtime/JSObjectInlines.h:
(JSC::JSObject::putDirectInternal):
* runtime/Structure.cpp:
(JSC::Structure::materializePropertyTable):
(JSC::Structure::removeNewPropertyTransition):
(JSC::Structure::attributeChangeTransition):
* runtime/Structure.h:
2020-08-13 Alexey Shvayka <shvaikalesh@gmail.com>
Rework StructureTransitionTable::Hash::Key encoding
https://bugs.webkit.org/show_bug.cgi?id=215483
Reviewed by Yusuke Suzuki.
This patch implements new encoding of StructureTransitionTable::Hash::Key
to enable storing attribute change transitions in a transition table.
Since PropertyMapEntry attributes are always uint8_t, the remaining 8 bits
are used for TransitionKind, which also accommodates non-property transitions,
removing a bit hacky toAttributes() and utilization of unused pointer bits.
This change also introduces TransitionKind::Unknown we can validate against,
preventing addition transition from being a default, which could be unsafe.
No behavior change.
* runtime/JSObject.cpp:
(JSC::JSObject::notifyPresenceOfIndexedAccessors):
(JSC::JSObject::createInitialUndecided):
(JSC::JSObject::createInitialInt32):
(JSC::JSObject::createInitialDouble):
(JSC::JSObject::createInitialContiguous):
(JSC::JSObject::convertUndecidedToInt32):
(JSC::JSObject::convertUndecidedToDouble):
(JSC::JSObject::convertUndecidedToContiguous):
(JSC::JSObject::convertUndecidedToArrayStorage):
(JSC::JSObject::convertInt32ToDouble):
(JSC::JSObject::convertInt32ToContiguous):
(JSC::JSObject::convertInt32ToArrayStorage):
(JSC::JSObject::convertDoubleToContiguous):
(JSC::JSObject::convertDoubleToArrayStorage):
(JSC::JSObject::convertContiguousToArrayStorage):
(JSC::JSObject::convertFromCopyOnWrite):
(JSC::JSObject::switchToSlowPutArrayStorage):
(JSC::JSObject::suggestedArrayStorageTransition const):
* runtime/JSObject.h:
* runtime/Structure.cpp:
(JSC::StructureTransitionTable::contains const):
(JSC::StructureTransitionTable::get const):
(JSC::StructureTransitionTable::add):
(JSC::Structure::Structure):
(JSC::Structure::addPropertyTransitionToExistingStructureImpl):
(JSC::Structure::addNewPropertyTransition):
(JSC::Structure::removePropertyTransitionFromExistingStructureImpl):
(JSC::Structure::removeNewPropertyTransition):
(JSC::Structure::sealTransition):
(JSC::Structure::freezeTransition):
(JSC::Structure::preventExtensionsTransition):
(JSC::Structure::nonPropertyTransitionSlow):
* runtime/Structure.h:
* runtime/StructureInlines.h:
(JSC::Structure::nonPropertyTransition):
* runtime/StructureTransitionTable.h:
(JSC::changesIndexingType):
(JSC::newIndexingType):
(JSC::preventsExtensions):
(JSC::setsDontDeleteOnAllProperties):
(JSC::setsReadOnlyOnNonAccessorProperties):
(JSC::StructureTransitionTable::Hash::Key::Key):
(JSC::StructureTransitionTable::Hash::Key::attributes const):
(JSC::StructureTransitionTable::Hash::Key::transitionKind const):
(JSC::StructureTransitionTable::Hash::hash):
(JSC::toAttributes): Deleted.
(JSC::StructureTransitionTable::Hash::Key::isAddition const): Deleted.
2020-08-12 Keith Rollin <krollin@apple.com>
Remove the need for defining USE_NEW_BUILD_SYSTEM
https://bugs.webkit.org/show_bug.cgi?id=215439
Reviewed by Darin Adler.
When building WebKit for XCBuild, we currently require that the
external build system (such as the Makefile, build-webkit, etc.)
defines the USE_NEW_BUILD_SYSTEM=YES build setting. This build setting
controls parts of our build instructions that are sensitive to when
XCBuild or the Legacy build system are being used. Notably, we need to
know when to use our custom “copy and modify” scripts with copying
certain header files (used with the Legacy build system) vs. using the
enhanced Copy Headers build phase that’s enabled with
APPLY_RULES_IN_COPY_HEADERS=YES (introduced with and used by XCBuild).
The choice of which method to copy headers is used is controlled by
USE_NEW_BUILD_SYSTEM.
There is no built-in build setting that we can probe to help us
determine which approach to take when copying and modifying headers,
which is why we need to define USE_NEW_BUILD_SYSTEM ourselves. But it
turns out that we can *detect* which build system is being used by
taking advantage of a subtle difference between the two systems. As
noted in:
https://developer.apple.com/documentation/xcode-release-notes/build-system-release-notes-for-xcode-10
“When an .xcconfig file contains multiple assignments of the same
build setting, later assignments using $(inherited) or
$(<setting_name>) will inherit from earlier assignments in the
.xcconfig. The legacy build system caused every use of
$(inherited) or $(<setting_name>) skip any other values defined
within the .xcconfig.”
This difference can be exploited as follows:
WK_WHICH_BUILD_SYSTEM = not_
WK_WHICH_BUILD_SYSTEM = $(inherited)legacy
WK_USE_NEW_BUILD_SYSTEM = $(WK_USE_NEW_BUILD_SYSTEM_$(WK_WHICH_BUILD_SYSTEM))
WK_USE_NEW_BUILD_SYSTEM_legacy = NO
WK_USE_NEW_BUILD_SYSTEM_not_legacy = YES
We can then use WK_USE_NEW_BUILD_SYSTEM where we used to use the
externally-defined USE_NEW_BUILD_SYSTEM.
* Configurations/Base.xcconfig:
* Configurations/JavaScriptCore.xcconfig:
* JavaScriptCore.xcodeproj/project.pbxproj:
2020-08-12 Saam Barati <sbarati@apple.com>
Inline cache Replace and Setters on PureForwardingProxy
https://bugs.webkit.org/show_bug.cgi?id=215250
Reviewed by Yusuke Suzuki.
We didn't used to cache any Puts on PureForwardingProxy. This patch
implements Replace and JS/Custom Setters on PureForwardingProxy. We don't support
Transition puts because in our current implementation different global objects
will never share the same structure.
This patch also aligns how our runtime and the ICs invoke Customs when the
passed in |this| value is a JSProxy. For custom accessors, our runtime passes
in the JSProxy, where our ICs used to pass in the target of the JSProxy, for
the receiver value. For custom values, the IC behavior and the runtime were
already aligned in passing in the property owner, which is the JSProxy's
target. This patch aligns our IC behavior to match our runtime behavior.
This patch also renames some of the registers in the IC code to clear
up what they're used for.
This is a 2.5x speedup on the microbenchmark I've added, and a 15-20% speedup
on JetStream2's 3d-cube-SP.
* bytecode/AccessCase.cpp:
(JSC::AccessCase::generateWithGuard):
(JSC::AccessCase::generateImpl):
* bytecode/GetterSetterAccessCase.cpp:
(JSC::GetterSetterAccessCase::create):
* bytecode/GetterSetterAccessCase.h:
* jit/JITOperations.cpp:
* jit/Repatch.cpp:
(JSC::tryCachePutByID):
* runtime/CommonSlowPaths.h:
(JSC::CommonSlowPaths::originalStructureBeforePut):
(JSC::CommonSlowPaths::putDirectWithReify):
2020-08-11 Mark Lam <mark.lam@apple.com>
ScriptExecutable::newCodeBlockFor() neglected to set the exception pointer result in one case.
https://bugs.webkit.org/show_bug.cgi?id=215357
<rdar://problem/57675112>
Reviewed by Yusuke Suzuki.
At the bottom of ScriptExecutable::newCodeBlockFor(), it calls:
RELEASE_AND_RETURN(throwScope, FunctionCodeBlock::create(vm, executable, unlinkedCodeBlock, scope));
However, ScriptExecutable::newCodeBlockFor() has 2 return values: a CodeBlock*,
and a passed in Exception*& that needs to be set if there's an exception.
FunctionCodeBlock::create() is capable of returning a null CodeBlock* because
CodeBlock::finishCreation() can throw exceptions. As a result, we have a scenario
here where ScriptExecutable::newCodeBlockFor() can return a null CodeBlock* without
setting the Exception*& result.
Consequently, Interpreter::executeCall() is relying on this and can end up
crashing while dereferencing a null CodeBlock* because the exception result was
not set.
This patch fixes ScriptExecutable::newCodeBlockFor() to set the exception result.
* runtime/ScriptExecutable.cpp:
(JSC::ScriptExecutable::newCodeBlockFor):
2020-08-10 Lauro Moura <lmoura@igalia.com>
[CMake][JSC] Fix testapiScripts copy location
https://bugs.webkit.org/show_bug.cgi?id=215338
file(COPY src/dir DESTINATION target/dir) copies the entire `dir`
inside target/dir instead of only the contents.
Reviewed by Alex Christensen.
* shell/CMakeLists.txt:
2020-08-10 Alex Christensen <achristensen@webkit.org>
REGRESSION(r261159) PokerBros only shows black screen
https://bugs.webkit.org/show_bug.cgi?id=215293
<rdar://problem/66073740>
Reviewed by Keith Miller.
The PokerBros app has some logic that was broken by the change in behavior of r261159.
It caused the app do do nothing except show a black screen upon opening.
Revert to the old behavior for this app until they update to iOS14.
* runtime/JSObject.cpp:
(JSC::needsOldStringName):
(JSC::JSObject::toStringName):
2020-08-10 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] JSFinalObject::finishCreation's ASSERT has stale condition
https://bugs.webkit.org/show_bug.cgi?id=215317
Reviewed by Mark Lam.
JSFinalObject::finishCreation assumes that there is no out-of-line property storage (inline storage capacity == total storage capacity).
But this is wrong when passing Butterfly* parameter to JSFinalObject. Previously, this feature is not used and we instead used JSObject::createRawObject,
which bypasses this assertion. But now, we start using this when creating an object for MaterializeNewObject in DFG and FTL, and then we hit the crash
because this assertion does not consider about non-nullptr butterfly.
This patch makes create function explicit by introducing `JSFinalObject::createWithButterfly`, which is similar to JSArray::createWithButterfly.
And we fix the assertion by checking butterfly existence. By renaming JSFinalObject::create to JSFinalObject::createWithButterfly when getting butterfly,
this patch also clarifies that only MaterializeNewObject related functions, which were using JSObject::createRawObject to bypass this assertion, is passing
butterfly.
* dfg/DFGOperations.cpp:
* runtime/JSObject.h:
(JSC::JSFinalObject::createWithButterfly):
(JSC::JSFinalObject::create):
2020-08-09 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r265392.
https://bugs.webkit.org/show_bug.cgi?id=215316
Crash ARM64 / ARM64E JSC tests
Reverted changeset:
"REGRESSION(r261159) PokerBros only shows black screen"
https://bugs.webkit.org/show_bug.cgi?id=215293
https://trac.webkit.org/changeset/265392
2020-08-09 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Make CommandLine on Worker agent (JSC shell feature for testing) work on iOS
https://bugs.webkit.org/show_bug.cgi?id=215311
<rdar://problem/66660053>
Reviewed by Mark Lam.
We should not reconfigure Options since this is once initialized. Since Options are frozen,
this results in crash.
* jsc.cpp:
(CommandLine::CommandLine):
(functionDollarAgentStart):
2020-08-09 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r263195, r263252, and r265394.
https://bugs.webkit.org/show_bug.cgi?id=215312
Revert all related GC Bitmap changes because some of perf is
not fully recovered
Reverted changesets:
"Replace JSC::FreeList linked list with a Bitmap."
https://bugs.webkit.org/show_bug.cgi?id=213071
https://trac.webkit.org/changeset/263195
"Unify Bitmap math loops in
MarkedBlock::Handle::specializedSweep()."
https://bugs.webkit.org/show_bug.cgi?id=213345
https://trac.webkit.org/changeset/263252
"[JSC] Disable ENABLE_BITMAP_FREELIST"
https://bugs.webkit.org/show_bug.cgi?id=215285
https://trac.webkit.org/changeset/265394
2020-08-08 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Speculate children first in DFG NewArray
https://bugs.webkit.org/show_bug.cgi?id=215308
<rdar://problem/64749263>
Reviewed by Mark Lam.
SpeculativeJIT::emitAllocateRawObject can create uninitialized butterfly since we later fill them.
However, DFG NewArray node has speculation after that. So if speculation failure happens, we release
half-baked butterfly.
Let's see the example.
8459 emitAllocateRawObject(resultGPR, structure, storageGPR, numElements, vectorLengthHint);
...
8482 case ALL_INT32_INDEXING_TYPES:
8483 case ALL_CONTIGUOUS_INDEXING_TYPES: {
8484 JSValueOperand operand(this, use, ManualOperandSpeculation);
8485 JSValueRegs operandRegs = operand.jsValueRegs();
8486 if (hasInt32(node->indexingType())) {
8487 DFG_TYPE_CHECK(
8488 operandRegs, use, SpecInt32Only,
8489 m_jit.branchIfNotInt32(operandRegs));
8490 }
8491 m_jit.storeValue(operandRegs, MacroAssembler::Address(storageGPR, sizeof(JSValue) * operandIdx));
8492 break;
8493 }
L8487-L8489 is doing speculation check. If it failed, the rest of the butterfly can be filled with garbage. This looks OK since
it is Int32 butterfly so GC never scans it. However, if have-a-bad-time happens and the array is reachable from the conservative root,
this half-baked array is converted from Int32 array to ArrayStorage. At that time, since Int32 butterfly should hold JSInt32,
we store this garbage to ArrayStorage. Later, if conservative root still holds this array, and GC scans this garbage as as JSValue,
this value confuses GC.
In this patch, we first perform speculation before creating uninitialized JSArray so that we can ensure that we never exit after
creating this array until we fill it. This strategy is the same to FTL's NewArray implementation.
And we also found that emitAllocateRawObject is allocating an object from JSFinalObject space while we use it for JSArray too.
We should get per-type allocator to ensure JSArray is allocated in its IsoSubspace.
* dfg/DFGOperations.cpp:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::emitAllocateRawObject):
(JSC::DFG::SpeculativeJIT::compileNewArray):
(JSC::DFG::SpeculativeJIT::compileMaterializeNewObject):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNewArray):
(JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
* runtime/JSObject.h:
(JSC::JSObject::createRawObject): Deleted.
2020-08-07 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Disable ENABLE_BITMAP_FREELIST
https://bugs.webkit.org/show_bug.cgi?id=215285
Reviewed by Mark Lam.
From performance bots, we observed that,
1. MBP11,4 shows 1% regression in Speedometer2.
2. The other MBP / iMac / MBA bots show neutral or slight regression in Speedometer2.
Based on the above result, for now, we disable this feature.
* heap/FreeList.h:
2020-08-07 Alex Christensen <achristensen@webkit.org>
REGRESSION(r261159) PokerBros only shows black screen
https://bugs.webkit.org/show_bug.cgi?id=215293
Reviewed by Keith Miller.
The PokerBros app has some logic that was broken by the change in behavior of r261159.
It caused the app do do nothing except show a black screen upon opening.
Revert to the old behavior for this app until they update to iOS14.
* runtime/JSObject.cpp:
(JSC::needsOldStringName):
(JSC::JSObject::toStringName):
2020-08-07 Michael Saboff <msaboff@apple.com>
RegExp sticky not matching alternates correctly, ignoring lastIndex requirement
https://bugs.webkit.org/show_bug.cgi?id=214181
Reviewed by Yusuke Suzuki.
In the YARR JIT, we need to check for sticky patterns before checking for fixed character
terms when backtracking. The YARR interpreter doesn't have this issue.
* yarr/YarrJIT.cpp:
2020-08-05 Tim Horton <timothy_horton@apple.com>
Remove all references to non-existent 10.16
https://bugs.webkit.org/show_bug.cgi?id=215202
Reviewed by Wenson Hsieh.
* Configurations/Base.xcconfig:
* Configurations/DebugRelease.xcconfig:
* Configurations/Version.xcconfig:
* Configurations/WebKitTargetConditionals.xcconfig:
2020-08-05 Saam Barati <sbarati@apple.com>
Fix returnEarlyFromInfiniteLoopsForFuzzing in DFG and validateDoesGC
https://bugs.webkit.org/show_bug.cgi?id=215194
<rdar://problem/66158641>
Reviewed by Mark Lam.
I already fixed this same issue in the FTL in r264330, but I forgot
to do it in the DFG.
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
2020-08-05 Keith Miller <keith_miller@apple.com>
The various AllowList options should be able to take the function name inline
https://bugs.webkit.org/show_bug.cgi?id=215184
Reviewed by Saam Barati.
Right now when I use the various AllowList JSC options I almost
always only care about a single function. Right now you need to
create a file with that single name in it. That is inconvenient, so
this patch changes the behavior to treat the string as the
function name if no file at that path exists. I'm also
speculatively assuming fopen doesn't return ENOENT when it fails
due to sandboxing... I didn't feel like testing it because this is
a debug option.
* runtime/OptionsList.h:
* tools/FunctionAllowlist.cpp:
(JSC::FunctionAllowlist::FunctionAllowlist):
2020-08-05 Keith Miller <keith_miller@apple.com>
Add assertions / inline capacity to checkpoint side state stacks
https://bugs.webkit.org/show_bug.cgi?id=215175
Reviewed by Saam Barati.
The inline capacity should hopefully avoid unneeded mallocs close to 100% of the time during our OSR exit ramp.
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::compileExit):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
* runtime/VM.cpp:
(JSC::VM::pushCheckpointOSRSideState):
* runtime/VM.h:
2020-08-04 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Use LazyNeverDestroyed & std::call_once for complex singletons
https://bugs.webkit.org/show_bug.cgi?id=215153
<rdar://problem/65718983>
Reviewed by Mark Lam.
We are getting some crashes in RemoteInspector and this speculatively fixes the crash.
My guess is that NeverDestroyed<RemoteInspector> calls constructor twice in heavily contended situation:
WebKit's static does not have thread-safety. If two threads come here at the same time, it is possible that
constructor is invoked twice. In that case, later constructor will clear members, which involves clearing
Lock m_mutex field. This makes Lock's invariant broken.
This patch uses LazyNeverDestroyed and std::call_once to ensure invoking constructor only once.
* API/glib/JSCVirtualMachine.cpp:
* dfg/DFGCommonData.cpp:
* disassembler/Disassembler.cpp:
* inspector/remote/RemoteInspector.h:
* inspector/remote/cocoa/RemoteInspectorCocoa.mm:
(Inspector::RemoteInspector::singleton):
* inspector/remote/glib/RemoteInspectorGlib.cpp:
(Inspector::RemoteInspector::singleton):
* inspector/remote/socket/RemoteInspectorServer.cpp:
(Inspector::RemoteInspectorServer::singleton):
* inspector/remote/socket/RemoteInspectorServer.h:
* inspector/remote/socket/RemoteInspectorSocket.cpp:
(Inspector::RemoteInspector::singleton):
* inspector/remote/socket/RemoteInspectorSocketEndpoint.cpp:
(Inspector::RemoteInspectorSocketEndpoint::singleton):
* interpreter/Interpreter.cpp:
(JSC::Interpreter::opcodeIDTable):
* runtime/IntlObject.cpp:
(JSC::intlAvailableLocales):
(JSC::intlCollatorAvailableLocales):
(JSC::defaultLocale):
(JSC::numberingSystemsForLocale):
2020-08-04 Keith Miller <keith_miller@apple.com>
CheckpointSideState shoud play nicely with StackOverflowException unwinding.
https://bugs.webkit.org/show_bug.cgi?id=215114
Reviewed by Saam Barati.
This patch fixes an issue where we the StackVisitor would
automatically unwind into the first frame before calling into the
provided functor. As a note, we do this because the first frame is
not fully initialized at the time we check for stack
overflow. When this happened we would fail to clear the side state
causing a memory leak. To fix this the unwind function now clears
every checkpoint up to and including the call frame containing our
handler. Some care needs to be taken that we don't clear
checkpoint side state for other threads, which could happen if
there are no checkpoints on the current thread and an API
miggrated us from another thread below the current thread.
This patch also makes two refacorings. The first is to make the
checkpoint side state into a stack, which is how we used it
anyway. The second is that CallFrame::dump and everything associated
with it is now marked const so we can PointerDump a CallFrame*.
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::compileExit):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
* interpreter/CallFrame.cpp:
(JSC::CallFrame::bytecodeIndex const):
(JSC::CallFrame::codeOrigin const):
(JSC::CallFrame::dump const):
(JSC::CallFrame::bytecodeIndex): Deleted.
(JSC::CallFrame::codeOrigin): Deleted.
(JSC::CallFrame::dump): Deleted.
* interpreter/CallFrame.h:
(JSC::CallFrame::argument const):
(JSC::CallFrame::uncheckedArgument const):
(JSC::CallFrame::getArgumentUnsafe const):
(JSC::CallFrame::thisValue const):
(JSC::CallFrame::newTarget const):
(JSC::CallFrame::argument): Deleted.
(JSC::CallFrame::uncheckedArgument): Deleted.
(JSC::CallFrame::getArgumentUnsafe): Deleted.
(JSC::CallFrame::thisValue): Deleted.
(JSC::CallFrame::newTarget): Deleted.
* interpreter/CheckpointOSRExitSideState.h:
(JSC::CheckpointOSRExitSideState::CheckpointOSRExitSideState):
* interpreter/Interpreter.cpp:
(JSC::UnwindFunctor::operator() const):
(JSC::Interpreter::unwind):
(): Deleted.
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::slow_path_checkpoint_osr_exit_from_inlined_call):
(JSC::LLInt::slow_path_checkpoint_osr_exit):
* runtime/VM.cpp:
(JSC::VM::scanSideState const):
(JSC::VM::pushCheckpointOSRSideState):
(JSC::VM::popCheckpointOSRSideState):
(JSC::VM::popAllCheckpointOSRSideStateUntil):
(JSC::VM::addCheckpointOSRSideState): Deleted.
(JSC::VM::findCheckpointOSRSideState): Deleted.
* runtime/VM.h:
2020-08-03 Alberto Garcia <berto@igalia.com>
[GTK] 2.29.4 fails to build in armhf
https://bugs.webkit.org/show_bug.cgi?id=214966
Reviewed by Michael Catanzaro.
SP register cannot be used as a destination register of SUB or ADD
on Thumb mode.
* llint/LowLevelInterpreter32_64.asm:
2020-08-03 Adrian Perez de Castro <aperez@igalia.com>
Non-unified build fixes, early August 20202 edition
https://bugs.webkit.org/show_bug.cgi?id=215082
Unreviewed build fix.
* dfg/DFGOSREntry.h: Add missing inclusion of CodeLocation.h
* ftl/FTLGeneratedFunction.h: Ditto.
* jit/CallFrameShuffler.h: Forward-declare CCallHelpers.
2020-08-02 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, fix CLoop build
https://bugs.webkit.org/show_bug.cgi?id=215010
* tools/SigillCrashAnalyzer.cpp:
2020-08-02 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r265151.
https://bugs.webkit.org/show_bug.cgi?id=215074
Broke ARM64E JSC tests
Reverted changeset:
"validate untagArrayPtr"
https://bugs.webkit.org/show_bug.cgi?id=214953
https://trac.webkit.org/changeset/265151
2020-08-01 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r265097, r265113, and r265122.
https://bugs.webkit.org/show_bug.cgi?id=215065
Broke AppleSilicon Big Sur
Reverted changesets:
"Strip pointers instead of authing for byteOffset to not allow
for a possible way to guess data pac"
https://bugs.webkit.org/show_bug.cgi?id=214952
https://trac.webkit.org/changeset/265097
"Compute number of PAC bits from what the OS says its address
space is"
https://bugs.webkit.org/show_bug.cgi?id=214986
https://trac.webkit.org/changeset/265113
"Remove UB from nonPACBitsMask computation"
https://bugs.webkit.org/show_bug.cgi?id=214996
https://trac.webkit.org/changeset/265122
2020-07-31 Keith Miller <keith_miller@apple.com>
Move Options setter to where we allow access to the Options object
https://bugs.webkit.org/show_bug.cgi?id=215028
Reviewed by Saam Barati.
Right now jsc CLI crashes when assertions are enabled on iOS.
* jsc.cpp:
(main):
(CommandLine::parseArguments):
2020-07-31 Saam Barati <sbarati@apple.com>
Re-enable NO_SMT on Catalina
https://bugs.webkit.org/show_bug.cgi?id=215024
Reviewed by Alexey Proskuryakov.
* runtime/Options.cpp:
(JSC::defaultTCSMValue):
* runtime/OptionsList.h:
2020-07-31 Saam Barati <sbarati@apple.com>
validate untagArrayPtr
https://bugs.webkit.org/show_bug.cgi?id=214953
Reviewed by Keith Miller.
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 shifts 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):
2020-07-31 Keith Miller <keith_miller@apple.com>
Reduce over include usage in JSC
https://bugs.webkit.org/show_bug.cgi?id=215010
Reviewed by Mark Lam.
My first attempt to fix
https://bugs.webkit.org/show_bug.cgi?id=215009 by making it so we
don't include FastJITPermissions.h in TestWebKitAPI, was
unsuccessful. Mostly because I gave up after several hours of
building... I figure it's still worth it to land the last working
version I was able to get building.
* assembler/MacroAssemblerCodeRef.h:
* bytecode/CodeBlock.cpp:
* bytecode/PolymorphicAccess.h:
* inspector/agents/InspectorRuntimeAgent.cpp:
* interpreter/CallFrame.h:
* jit/ThunkGenerators.cpp:
* llint/LLIntOffsetsExtractor.cpp:
* runtime/TypeLocationCache.cpp:
* runtime/VM.cpp:
(JSC::VM::getCTIStub):
* runtime/VM.h:
(JSC::VM::getCTIStub): Deleted.
* tools/JSDollarVM.cpp:
2020-07-31 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Follow-up changes after r265036
https://bugs.webkit.org/show_bug.cgi?id=214982
Reviewed by Darin Adler.
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::compileExit): Remove dupe definitions in OSRExit.
* jit/JITCall32_64.cpp:
(JSC::JIT::emit_op_iterator_open): We should use emitJumpSlowCaseIfNotJSCell(regT1).
2020-07-30 Keith Miller <keith_miller@apple.com>
Remove UB from nonPACBitsMask computation
https://bugs.webkit.org/show_bug.cgi?id=214996
Reviewed by Tadeu Zagallo.
For non-ARM64E we now set numberOfPACBits to zero, which was causing UB in our computation of the nonPACBitsMask.
* assembler/MacroAssemblerARM64E.h:
2020-07-30 Keith Miller <keith_miller@apple.com>
Compute number of PAC bits from what the OS says its address space is
https://bugs.webkit.org/show_bug.cgi?id=214986
Reviewed by Saam Barati.
* assembler/MacroAssemblerARM64E.h:
2020-07-30 Caio Lima <ticaiolima@gmail.com>
[JSC][32-bits] interator_next should check for EmptyValue instead of undefined to execute LLInt fast path
https://bugs.webkit.org/show_bug.cgi?id=214963
Reviewed by Yusuke Suzuki.
There was a bug in previous implementation that allows execution of
`interator_next` fast path if we set ArrayIterator.prototype.next to
0. This happened because we were not properly checking `ValueEmpty`
from `m_next`. This patch is fixing such issue and doing the proper
verification.
* llint/LowLevelInterpreter32_64.asm:
2020-07-30 Saam Barati <sbarati@apple.com>
Strip pointers instead of authing for byteOffset to not allow for a possible way to guess data pac
https://bugs.webkit.org/show_bug.cgi?id=214952
Reviewed by Keith Miller.
In the old way of doing things, we would auth the vector pointer before subtracting
the base from it. Since we never validated the auth, this allowed for a
potential data-PAC bypass by just repeatedly calling byteOffset in a loop
and observing the integer result of the operation.
Since byteOffset does no loads/stores, it suffices to just strip the PAC
bits before doing the subtraction. This eliminates any such attacks like
the above because the PAC bits are ignored.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileGetTypedArrayByteOffset):
2020-07-29 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Add B3::BottomTupleValue node
https://bugs.webkit.org/show_bug.cgi?id=214956
<rdar://problem/65192877>
Reviewed by Keith Miller.
In B3 strength reduction, we convert B3 values to bottom value based on type after Oops kind, and then they are *typically* removed later.
While we support bottom values for usual types, we do not have a bottom value for tuple type. So when replaceWithBottom is called, we
fail to replace Patchpoints producing tuples with bottom values.
This patch newly adds B3 BottomTupleValue, which is just a BottomValue for tuple. We can extend it to generate arbitrary constant
tuple values, but for now, we just support bottom tuple values. We add a new node instead of generating patchpoint which generates bottom
values since BottomTupleValues implementation is simpler: BottomTupleValue just emits bunch of zero clear for Air tmps and Air does everything
automatically. On the other hand, implementing a patchpoint needs to add code which clears things with zero while checking the ValueRep. And
since we have Const32, Const64, etc. values, having this kind of value for tuple too is natural. Plus, this design allows us to remove bunch
of unnecessary instructions after lowering this to Air since Air knows what instructions will be emitted by this BottomTupleValue, and Air
can remove a lot of zero clear instructions if they are not read later by Extract.
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* b3/B3BottomTupleValue.cpp: Copied from Source/JavaScriptCore/b3/B3InsertionSet.cpp.
(JSC::B3::BottomTupleValue::dumpMeta const):
* b3/B3BottomTupleValue.h: Copied from Source/JavaScriptCore/b3/B3InsertionSet.cpp.
* b3/B3InsertionSet.cpp:
(JSC::B3::InsertionSet::insertBottom):
* b3/B3LowerToAir.cpp:
* b3/B3Opcode.cpp:
(WTF::printInternal):
* b3/B3Opcode.h:
* b3/B3Procedure.cpp:
(JSC::B3::Procedure::addBottom):
* b3/B3TypeMap.h:
(JSC::B3::TypeMap::TypeMap): Deleted.
* b3/B3Validate.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::effects const):
(JSC::B3::Value::key const):
* b3/B3Value.h:
* b3/B3ValueInlines.h:
* b3/B3ValueKey.cpp:
(JSC::B3::ValueKey::materialize const):
* b3/testb3_7.cpp:
(testBottomTupleValue):
(addTupleTests):
2020-07-29 Tadeu Zagallo <tzagallo@apple.com>
WebAssembly validation for call_indirect is incorrect
https://bugs.webkit.org/show_bug.cgi?id=214901
<rdar://problem/65189677>
Reviewed by Saam Barati.
There was an incorrect condition when validating call_indirect's arguments, which often resulted in skipping this validation.
* wasm/WasmFunctionParser.h:
(JSC::Wasm::FunctionParser<Context>::parseExpression):
2020-07-29 Mark Lam <mark.lam@apple.com>
Update some JSArrayBufferView comments and add some assertions.
https://bugs.webkit.org/show_bug.cgi?id=214914
Reviewed by Darin Adler.
* runtime/ArrayBuffer.cpp:
(JSC::ArrayBuffer::createAdopted):
* runtime/JSArrayBufferView.cpp:
(JSC::JSArrayBufferView::ConstructionContext::ConstructionContext):
(JSC::JSArrayBufferView::finalize):
* runtime/JSArrayBufferView.h:
2020-07-29 Paulo Matos <pmatos@igalia.com>
for..of intrinsics implementation for 32bits
https://bugs.webkit.org/show_bug.cgi?id=214737
Reviewed by Yusuke Suzuki.
Joint work with Caio Lima <ticaiolima@gmail.com>.
Implements for..of intrinsics for 32bits.
Adds or8 instruction to ARMv7 and MIPS Macro Assembler.
Adds intrinsic operations to LLInt and Baseline for 32bits.
Fixes DFG OSR Exit bug, where checkpoint temporary value is
incorrectly recreated for Baseline.
Refactors code in DFG OSR Exit to be easier to modify and
maintain by separating the switch cases for 32 and 64bits.
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::or8): Adds or8(TrustedImm, AbsoluteAddress)
(JSC::MacroAssemblerARMv7::or32):
(JSC::MacroAssemblerARMv7::store8):
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::or8): Adds or8(TrustedImm, AbsoluteAddress)
(JSC::MacroAssemblerMIPS::store8):
* assembler/testmasm.cpp:
(JSC::testOrImmMem): Tests or8
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitEnumeration):
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::compileExit): Fixes DFG OSR Exit bug, where checkpoint temporary value is
incorrectly recreated for Baseline. Refactors code in DFG OSR Exit to be easier to modify and
maintain by separating the switch cases for 32 and 64bits.
* jit/JIT.h:
* jit/JITCall32_64.cpp:
(JSC::JIT::emitPutCallResult):
(JSC::JIT::compileSetupFrame):
(JSC::JIT::compileOpCall):
(JSC::JIT::emit_op_iterator_open):
(JSC::JIT::emitSlow_op_iterator_open):
(JSC::JIT::emit_op_iterator_next):
(JSC::JIT::emitSlow_op_iterator_next):
* jit/JITInlines.h:
(JSC::JIT::emitJumpSlowCaseIfNotJSCell):
* llint/LowLevelInterpreter32_64.asm:
2020-07-29 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Reflect object should have toStringTag with "Reflect"
https://bugs.webkit.org/show_bug.cgi?id=214909
Reviewed by Mark Lam.
We call JSC_TO_STRING_TAG_WITHOUT_TRANSITION in ReflectObject to set "Reflect" @@toStringTag, which fixes one test262 failure.
* runtime/ReflectObject.cpp:
(JSC::ReflectObject::finishCreation):
2020-07-28 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Add hasCustomGetterSetterProperties to canAccessPropertiesQuicklyForEnumeration
https://bugs.webkit.org/show_bug.cgi?id=214908
<rdar://problem/65883816>
Reviewed by Mark Lam.
canAccessPropertiesQuicklyForEnumeration should filter out hasCustomGetterSetterProperties too.
* runtime/Structure.cpp:
(JSC::Structure::canAccessPropertiesQuicklyForEnumeration const):
2020-07-28 Caitlin Potter <caitp@igalia.com>
[JSC] add IC support for op_get_private_name
https://bugs.webkit.org/show_bug.cgi?id=213545
Reviewed by Saam Barati.
The baseline JIT now supports a fast path for op_private_name,
using a variant of GetByVal IC.
The generated AccessCase has the following qualities:
- Always "direct", relying only on the current structure for cachebility
- Never impure (DOM properties are not supported at this time, ProxyObjects are treated as JSObjects)
Based on the microbenchmark reviewed on https://bugs.webkit.org/show_bug.cgi?id=213544, this sees
an improvement of roughly 50% on average.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
* bytecode/StructureStubInfo.cpp:
(JSC::StructureStubInfo::reset):
* bytecode/StructureStubInfo.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
* jit/ICStats.h:
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
* jit/JIT.h:
* jit/JITInlineCacheGenerator.cpp:
(JSC::JITGetByValGenerator::JITGetByValGenerator):
* jit/JITInlineCacheGenerator.h:
* jit/JITOperations.cpp:
(JSC::getPrivateName):
* jit/JITOperations.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_get_by_val):
(JSC::JIT::emit_op_get_private_name):
(JSC::JIT::emitSlow_op_get_private_name):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_get_by_val):
(JSC::JIT::emit_op_get_private_name):
(JSC::JIT::emitSlow_op_get_private_name):
* jit/Repatch.cpp:
(JSC::appropriateOptimizingGetByFunction):
(JSC::appropriateGetByFunction):
(JSC::tryCacheGetBy):
* jit/Repatch.h:
2020-07-27 Yusuke Suzuki <ysuzuki@apple.com>
[JSC][wasm] Truncating slightly less than INT32_MIN is incorrect
https://bugs.webkit.org/show_bug.cgi?id=214834
Reviewed by Darin Adler.
Wasm trunc_f64_s should handle (INT32_MIN - 1.0, INT32_MIN) range too.
* llint/WebAssembly.asm:
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::addOp<OpType::I32TruncSF64>):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::addOp<OpType::I32TruncSF64>):
2020-07-28 Mark Lam <mark.lam@apple.com>
ASSERTION FAILED: isSymbol() in Source/JavaScriptCore/runtime/JSCell.cpp(188)
https://bugs.webkit.org/show_bug.cgi?id=214837
Reviewed by Darin Adler.
The issue found by this bug was that jsc shell test properties were enumerable.
These properties are only meant for test development use. They will never be
present in a productized JavaScript environment.
This patch helps reduce the change of users of the jsc shell tripping up on these
test properties when enumerating the global object.
* jsc.cpp:
2020-07-28 Yusuke Suzuki <ysuzuki@apple.com>
IndexedDB binding utilities miss exception checks
https://bugs.webkit.org/show_bug.cgi?id=214820
<rdar://problem/66152374>
Reviewed by Mark Lam.
jsStringWithCache does not need to take JSGlobalObject*.
* runtime/JSString.h:
(JSC::jsStringWithCache):
2020-07-27 Mark Lam <mark.lam@apple.com>
DisallowVMEntry needs a copy assignment operator, detected by gcc's -Wdeprecated-copy warning
https://bugs.webkit.org/show_bug.cgi?id=214809
Reviewed by Yusuke Suzuki.
According to https://en.cppreference.com/w/cpp/language/copy_assignment,
"The generation of the implicitly-defined copy assignment operator is deprecated
(since C++11) if T has a user-declared destructor or user-declared copy constructor."
DisallowVMEntry has both a user-declared destructor and a user-declared copy
constructor. Hence, it needs to define its own copy assignment operator to placate
the compiler.
This patch also adds back WTF_FORBID_HEAP_ALLOCATION to DisallowVMEntry.
DisallowVMEntry should always have forbid heap allocation. It was accidentally
removed in a prior patch.
* runtime/DisallowVMEntry.h:
(JSC::DisallowVMEntryImpl::operator=):
2020-07-27 Caio Lima <ticaiolima@gmail.com>
DoesGC failures in debug mode in 32bits
https://bugs.webkit.org/show_bug.cgi?id=214449
Reviewed by Mark Lam.
Adding the DoesGC update code into OSRExit::compileExit for 32-bits.
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::compileExit):
2020-07-24 Mark Lam <mark.lam@apple.com>
pluginElementCustomGetOwnPropertySlot() should support VMInquiry requests.
https://bugs.webkit.org/show_bug.cgi?id=214555
<rdar://problem/65855400>
Reviewed by Yusuke Suzuki.
1. Add handling for VMInquiry failure in JSObject::getPropertySlot() and
JSObject::getNonIndexPropertySlot(). Basically, if the query isTaintedByOpaqueObject,
then we should treat the false result as a failed VMInquiry.
2. Fix JSModuleNamespaceObject::getOwnPropertySlotCommon() and
ProxyObject::getOwnPropertySlotCommon() to initialize the PropertySlot to a
jsUndefined() value if we have a failed VMInquiry. The client shouldn't
be reading the value if the VMInquiry failed, but as a defensive action, we'll
initialize the slot to effectively return an undefined value.
* runtime/JSModuleNamespaceObject.cpp:
(JSC::JSModuleNamespaceObject::getOwnPropertySlotCommon):
* runtime/JSObjectInlines.h:
(JSC::JSObject::getPropertySlot):
(JSC::JSObject::getNonIndexPropertySlot):
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::getOwnPropertySlotCommon):
2020-07-24 Dean Jackson <dino@apple.com>
JavaScriptCore Xcode project has some errors
https://bugs.webkit.org/show_bug.cgi?id=214775
Reviewed by Yusuke Suzuki.
When looking at the build output for JavaScriptCore I noticed two
weird errors in the Xcode project file. Firstly, there was a broken
group called "runtime" that was causing some files to appear
duplicated. Secondly, there was a generated file
WebAssemblyCompileErrorConstructor.lut.h whose location was
incorrectly identified as being part of the project source.
Xcode moved a bunch of other things around, but it seems to compile
fine. Weirdly, the diff shows that the project file had unusual
whitespace. I wonder if it had been edited by hand.
* JavaScriptCore.xcodeproj/project.pbxproj:
2020-07-24 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] DFG::AbstractValue::filterByValue should re-filter configured m_value via m_type
https://bugs.webkit.org/show_bug.cgi?id=214721
<rdar://problem/65882837>
Reviewed by Mark Lam.
Let's consider the following case.
1. Input AbstractValue is saying SpecObjectOther.
2. We have CheckIsConstant with StringPrototype (which is SpecObjectOther | SpecStringObject in the current SpeculatedType).
3. We call filterByValue, which filters m_type by SpecObjectOther | SpecStringObject. But the filtered m_type is SpecObjectOther since (2)'s SpeculatedType is broader.
4. We store the given constant (StringPrototype) to m_value.
5. This AbstractValue's m_type is SpecObjectOther while its m_value's SpeculatedType is SpecObjectOther | SpecStringObject. Contradiction!
When setting m_value by filterByValue, we should filter m_value with m_type to ensure that m_value is the expected one.
This patch also avoid using SpecObjectOther | SpecStringObject for StringPrototype since we can return narrower type for that.
* bytecode/SpeculatedType.cpp:
(JSC::speculationFromStructure):
* dfg/DFGAbstractValue.cpp:
(JSC::DFG::AbstractValue::filterByValue):
(JSC::DFG::AbstractValue::filter):
* dfg/DFGPredictionPropagationPhase.cpp:
* runtime/StringObject.cpp:
(JSC::StringObject::finishCreation):
2020-07-24 Alexey Shvayka <shvaikalesh@gmail.com>
JSON.parse should not modify non-configurable properties.
https://bugs.webkit.org/show_bug.cgi?id=163446
Reviewed by Darin Adler.
This change implements step 2.c.ii.3 of InternalizeJSONProperty [1], replacing
put() with defineOwnProperty(). Using the latter fixes JSON.parse() with
non-configurable (failures are silently ignored; see note in the spec),
non-writable, and accessor properties, aligning JSC with V8 and SpiderMonkey.
Since it's extremely unlikely for userland `reviver` to remove or redefine the
next property, a fast path for PropertyAttribute::None attributes is introduced.
It advances microbenchmarks/json-parse-object-*.js by ~13%.
[1]: https://tc39.es/ecma262/#sec-internalizejsonproperty
* runtime/JSONObject.cpp:
(JSC::Walker::walk):
2020-07-24 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Do not use hardened Array for Intl supportedLocalesOf
https://bugs.webkit.org/show_bug.cgi?id=214676
Reviewed by Mark Lam.
We do not need to call getOwnPropertyNames & defineOwnProperty because hardening array of Intl.XXX.supportedLocalesOf is removed from the spec.
We should just return an array from bestFitSupportedLocales or lookupSupportedLocales, while this change is not observable to users (but it is better
for performance). This fully fixes https://github.com/tc39/ecma402/pull/278.
* runtime/IntlObject.cpp:
(JSC::supportedLocales):
2020-07-23 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Arrow function |this| resolution should not be trapped by with-scope
https://bugs.webkit.org/show_bug.cgi?id=214716
<rdar://problem/65980639>
Reviewed by Darin Adler.
We were using usual "this" named variable in lexical-environment to load and store arrow-function's |this|.
But since this looks normal variable, it can be trapped by "with" scope's object while it should not be.
We use thisPrivateName instead to avoid this behavior since Proxy does not trap private names.
* builtins/BuiltinNames.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::initializeArrowFunctionContextScopeIfNeeded):
(JSC::BytecodeGenerator::variable):
(JSC::BytecodeGenerator::createVariable):
(JSC::BytecodeGenerator::emitLoadThisFromArrowFunctionLexicalEnvironment):
(JSC::BytecodeGenerator::emitPutThisToArrowFunctionContextScope):
* bytecompiler/NodesCodegen.cpp:
(JSC::HasOwnPropertyFunctionCallDotNode::emitBytecode):
(JSC::ForInNode::emitBytecode):
* runtime/CommonIdentifiers.cpp:
(JSC::CommonIdentifiers::CommonIdentifiers):
* runtime/CommonIdentifiers.h:
2020-07-23 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] FTL OSR entry should store boxed |this|
https://bugs.webkit.org/show_bug.cgi?id=214675
<rdar://problem/65474072>
Reviewed by Michael Saboff and Mark Lam.
In this patch, after ensuring that we will go to FTL OSR entry, we store boxed |this| instead of the unboxed value
to agree to the FTL assumption that all arguments should be boxed.
* dfg/DFGOperations.cpp:
* ftl/FTLOSREntry.cpp:
(JSC::FTL::prepareOSREntry):
2020-07-23 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] BigInt can be `false` in boolean context in DFG AI
https://bugs.webkit.org/show_bug.cgi?id=214678
<rdar://problem/65894751>
Reviewed by Mark Lam.
DFG::AbstractInterpreter::booleanResult returns wrong result if finite structure includes HeapBigInt structure
since HeapBigInt 0n can be evaluated `false` in boolean context while this function does not care it. This patch
fixes it and cleans up code by using WTF/TriState.
* dfg/DFGAbstractInterpreter.h:
(): Deleted.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::booleanResult):
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2020-07-23 Caio Lima <ticaiolima@gmail.com>
[32-bits] Fixing the return of doVMEntry into LowLevelInterpreter32_64.asm
https://bugs.webkit.org/show_bug.cgi?id=214641
Reviewed by Mark Lam.
Adjusting the return of `doVMEntry` for 32-bits LLInt to proper set
`EncodedJSValue` return in little-endian architectures. It is expected
that tag is stored in `r1` and payload is stored in `r0`.
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
2020-07-23 Alexey Shvayka <shvaikalesh@gmail.com>
Remove ArrayNode::m_optional
https://bugs.webkit.org/show_bug.cgi?id=214294
Reviewed by Darin Adler.
m_optional, which dates back to KJS era, means "is this an array with optional trailing comma,
with elision, or an empty array". It was used by ArrayNode::streamTo() to preserve a trailing
comma when converting array node to source string, as well as in few other places,
before ECMA-262 clarified trailing comma in array literals [1].
Currently, m_optional is used only by ArrayNode::isSimpleArray(), along with m_elision.
Checking m_elision is enough since trailing comma doesn't add extra `undefined` element.
This patch completely removes m_optional, speeding up destructuring and function.apply()
with empty arrays and arrays with trailing commas by ~55% and a factor of 11 respectively.
Reflect.apply() optimization (https://webkit.org/b/190668) will also benefit from this change.
Also, this change converts isSpreadExpression() check to an ASSERT (was enabled by r196323).
[1]: https://tc39.es/ecma262/#sec-array-initializer
* bytecompiler/NodesCodegen.cpp:
(JSC::ArrayNode::isSimpleArray const):
(JSC::ArrayNode::toArgumentList const):
(JSC::ArrayNode::emitDirectBinding):
* parser/NodeConstructors.h:
(JSC::ArrayNode::ArrayNode):
* parser/Nodes.h:
2020-07-23 Alexey Shvayka <shvaikalesh@gmail.com>
Remove emitIsUndefined() from ClassExprNode::emitBytecode()
https://bugs.webkit.org/show_bug.cgi?id=214645
Reviewed by Darin Adler.
This change removes `superclass === undefined` check because it's missing from
the spec [1] and isn't a common case. No behavior change: values except `null` are
passed to OpIsConstructor, resulting in the same error being thrown for `undefined`.
Test: LayoutTests/js/class-syntax-extends.html
[1]: https://tc39.es/ecma262/#sec-runtime-semantics-classdefinitionevaluation (step 5.e)
* bytecompiler/NodesCodegen.cpp:
(JSC::ClassExprNode::emitBytecode):
2020-07-22 Conrad Shultz <conrad_shultz@apple.com>
Update macOS Version macros
https://bugs.webkit.org/show_bug.cgi?id=214653
Reviewed by Tim Horton.
* Configurations/Base.xcconfig:
* Configurations/DebugRelease.xcconfig:
* Configurations/Version.xcconfig:
* Configurations/WebKitTargetConditionals.xcconfig:
2020-07-22 Geoffrey Garen <ggaren@apple.com>
WTF::Function adoption should be explicit instead of implicit
https://bugs.webkit.org/show_bug.cgi?id=214654
Reviewed by Darin Adler.
* heap/Heap.cpp:
(JSC::Heap::LambdaFinalizerOwner::finalize): Use new adopt function.
2020-07-22 Mark Lam <mark.lam@apple.com>
Disallow VM entry when doing a VMInquiry.
https://bugs.webkit.org/show_bug.cgi?id=214624
<rdar://problem/65915314>
Reviewed by Saam Barati.
1. In PropertySlot's constructor, automatically install a DisallowVMEntry scope
if the passed in internal method type is VMInquiry. This ensures that we won't
be able to enter the VM to call JS code while doing the inquiry. As a result,
the PropertySlot constructor will now take an optional VM pointer, which is
must be passed in in when the internal method type is VMInquiry.
Note that the handling of attempts to enter the VM depends on
Options::crashOnDisallowedVMEntry().
On Debug build (due to ASSERT_ENABLED), Options::crashOnDisallowedVMEntry()
defaults to true and the VM will crash on disallowed entry.
On Release build, Options::crashOnDisallowedVMEntry() defaults to false and
disallow entry attempts into the VM will be treated like calling an empty
function that returns undefined. This is not new behavior in this patch, but
I just want to have a reminder here of how DisallowVMEntry will be enforcing
no entry into the VM while doing a VMInquiry.
2. After VMInquiry gets, sometimes the client code wants to do other work that
do entails entering the VM. In such cases, we need to reset the PropertySlot's
disallowVMEntry scope. Fixed up a few places in client code to do this reset.
3. Make the DisableVMEntry scope copyable. At least one place wants to copy
PropertySlot, and as a result, will need to copy its embedded DisableVMEntry
scope as well if installed.
For DisableVMEntry, we'll handle copying semantics as follows: copying a
DisableVMEntry will ref the VM::disallowVMEntryCount. The count will be
decremented when both instances are destructed. As a result, VM entry will
be disallowed as long as one of the copies are still alive.
4. For the setObjectToStringValue() method of Structure and StructureRareData, we
were previously passing a PropertySlot by copy. We don't really need to do
this. Ultimately, only StructureRareData::setObjectToStringValue() needs to
access a few of the PropertySlot query methods. So, we changed these methods
to pass a `const PropertySlot&` instead to void the needless copying.
* API/JSCallbackObjectFunctions.h:
(JSC::JSCallbackObject<Parent>::put):
(JSC::JSCallbackObject<Parent>::staticFunctionGetter):
* heap/HeapSnapshotBuilder.cpp:
(JSC::HeapSnapshotBuilder::json):
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::queryInstances):
* interpreter/Interpreter.cpp:
(JSC::Interpreter::execute):
* jit/JITOperations.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/DisallowVMEntry.h:
(JSC::DisallowVMEntryImpl::DisallowVMEntryImpl):
* runtime/ErrorInstance.cpp:
(JSC::ErrorInstance::sanitizedToString):
* runtime/JSFunction.cpp:
(JSC::JSFunction::getOwnNonIndexPropertyNames):
(JSC::JSFunction::put):
(JSC::JSFunction::defineOwnProperty):
* runtime/JSGenericTypedArrayViewConstructorInlines.h:
(JSC::constructGenericTypedArrayViewWithArguments):
* runtime/JSGlobalObject.cpp:
(JSC::getGetterById):
(JSC::JSGlobalObject::defineOwnProperty):
(JSC::JSGlobalObject::tryInstallArraySpeciesWatchpoint):
* runtime/JSObject.cpp:
(JSC::JSObject::calculatedClassName):
* runtime/JSObjectInlines.h:
(JSC::JSObject::getPrivateFieldSlot):
* runtime/JSScope.cpp:
(JSC::abstractAccess):
* runtime/PropertySlot.h:
(JSC::PropertySlot::PropertySlot):
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::StackFrame::nameFromCallee):
* runtime/Structure.h:
* runtime/StructureInlines.h:
(JSC::Structure::setObjectToStringValue):
* runtime/StructureRareData.cpp:
(JSC::StructureRareData::setObjectToStringValue):
* runtime/StructureRareData.h:
* tools/JSDollarVM.cpp:
(JSC::functionGetGetterSetter):
2020-07-22 Geoffrey Garen <ggaren@apple.com>
JSRunLoopTimer should use WTF::RunLoop rather than custom CF code
https://bugs.webkit.org/show_bug.cgi?id=214102
Unreviewed, re-landing r264242 with crash fixed.
We needed to synchronize timer destruction with timer firing.
* runtime/DeferredWorkTimer.cpp:
(JSC::DeferredWorkTimer::doWork):
(JSC::DeferredWorkTimer::runRunLoop):
* runtime/JSRunLoopTimer.cpp:
(JSC::epochTime):
(JSC::JSRunLoopTimer::Manager::PerVMData::PerVMData):
(JSC::JSRunLoopTimer::Manager::timerDidFireCallback):
(JSC::JSRunLoopTimer::Manager::PerVMData::~PerVMData):
(JSC::JSRunLoopTimer::Manager::timerDidFire):
(JSC::JSRunLoopTimer::Manager::registerVM):
(JSC::JSRunLoopTimer::Manager::scheduleTimer):
(JSC::JSRunLoopTimer::Manager::cancelTimer):
(JSC::JSRunLoopTimer::Manager::PerVMData::setRunLoop): Deleted.
(JSC::JSRunLoopTimer::Manager::didChangeRunLoop): Deleted.
* runtime/JSRunLoopTimer.h:
(JSC::JSRunLoopTimer::Manager::PerVMData::PerVMData): Deleted.
* runtime/VM.cpp:
(JSC::VM::VM):
(JSC::VM::create):
(JSC::VM::tryCreate):
(JSC::VM::setRunLoop): Deleted.
* runtime/VM.h:
(JSC::VM::runLoop const):
2020-07-21 Mark Lam <mark.lam@apple.com>
Simplify DisallowScope, DisallowGC, and DisallowVMReentry implementations.
https://bugs.webkit.org/show_bug.cgi?id=214539
<rdar://problem/65795729>
Reviewed by Keith Miller.
Previously, DisallowScope needed to support enabling and disabling. This was
only needed to enable the implementation of ObjectInitializationScope. Now, we
can make the DisallowGC and DisallowVMReentry inside ObjectInitializationScope
optional with WTF::Optional. With that we can simplify these scopes and make
them true RAII scope objects.
This patch also does the following:
1. Renamed DisallowVMReentry to DisallowVMEntry.
The scope can be used to disable VM entry completely. There's no need to
restrict it to only re-entries.
2. Enforcement of DisallowVMReentry is now done in the LLInt's doVMEntry() instead
of the VMEntryScope's constructor. This is a stronger guarantee.
If Options::crashOnDisallowedVMEntry() is true, the VM will crash if it sees
an attempt to enter the VM while disallowed.
If Options::crashOnDisallowedVMEntry() is false, an attempt to call into the VM
while disallowed will return immediately with an undefined result without
invoking any script.
By default, Options::crashOnDisallowedVMEntry() is true if ASSERT_ENABLED is
true.
3. Change DisallowScope and DisallowGC to be based on ASSERT_ENABLED instead of NEBUG.
4. Make DisallowVMEntry always enforceable, not just when ASSERT_ENABLED.
It's enforcement action depends on Options::crashOnDisallowedVMEntry() as
described above.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* heap/DeferGC.cpp:
* heap/DeferGC.h:
(JSC::DisallowGC::DisallowGC):
(JSC::DisallowGC::initialize):
* interpreter/Interpreter.cpp:
(JSC::Interpreter::executeProgram):
(JSC::Interpreter::executeCall):
(JSC::Interpreter::executeConstruct):
(JSC::Interpreter::execute):
(JSC::Interpreter::executeModuleProgram):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::llint_check_vm_entry_permission):
* llint/LLIntSlowPaths.h:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/DisallowScope.h:
(JSC::DisallowScope::DisallowScope):
(JSC::DisallowScope::~DisallowScope):
(JSC::DisallowScope::isInEffectOnCurrentThread):
(JSC::DisallowScope::enable): Deleted.
(JSC::DisallowScope::disable): Deleted.
(JSC::DisallowScope::enterScope): Deleted.
(JSC::DisallowScope::exitScope): Deleted.
* runtime/DisallowVMEntry.h: Copied from Source/JavaScriptCore/runtime/DisallowVMReentry.h.
(JSC::DisallowVMEntryImpl::DisallowVMEntryImpl):
(JSC::DisallowVMEntryImpl::~DisallowVMEntryImpl):
(JSC::DisallowVMEntryImpl::isEngaged const):
(JSC::DisallowVMEntryImpl::release):
(JSC::DisallowVMReentry::DisallowVMReentry): Deleted.
(JSC::DisallowVMReentry::initialize): Deleted.
(JSC::DisallowVMReentry::scopeReentryCount): Deleted.
(JSC::DisallowVMReentry::setScopeReentryCount): Deleted.
* runtime/DisallowVMReentry.cpp: Removed.
* runtime/DisallowVMReentry.h: Removed.
* runtime/InitializeThreading.cpp:
(JSC::initialize):
* runtime/JSArray.cpp:
(JSC::JSArray::tryCreateUninitializedRestricted):
* runtime/ObjectInitializationScope.cpp:
(JSC::ObjectInitializationScope::ObjectInitializationScope):
(JSC::ObjectInitializationScope::notifyAllocated):
(JSC::ObjectInitializationScope::notifyInitialized):
* runtime/ObjectInitializationScope.h:
(JSC::ObjectInitializationScope::vm const):
(JSC::ObjectInitializationScope::ObjectInitializationScope):
(JSC::ObjectInitializationScope::~ObjectInitializationScope):
(JSC::ObjectInitializationScope::notifyAllocated):
(JSC::ObjectInitializationScope::notifyInitialized):
* runtime/OptionsList.h:
* runtime/RegExpMatchesArray.h:
(JSC::tryCreateUninitializedRegExpMatchesArray):
* runtime/VM.h:
* runtime/VMEntryScope.cpp:
(JSC::VMEntryScope::VMEntryScope):
2020-07-21 Mark Lam <mark.lam@apple.com>
llint_slow_path_get_private_name() should not be using PropertySlot::InternalMethodType::VMInquiry.
https://bugs.webkit.org/show_bug.cgi?id=214603
Reviewed by Yusuke Suzuki.
VMInquiry means (1) the get operation should not call back into JS, (2) it should
not throw any exceptions (except for OutOfMemoryError or StackOverflowError which
can be thrown at any time), or have any side effects that is observable from JS
code. In this case, llint_slow_path_get_private_name() is just implementating
PrivateFieldGet (https://tc39.es/proposal-class-fields/#sec-privatefieldget) and
should actually be using PropertySlot::InternalMethodType::GetOwnProperty
(according to https://tc39.es/proposal-class-fields/#sec-privatefieldfind).
This patch makes the above change, and also adds an assert in JSObject::getPrivateField
to ensure that no one calls it for a VMInquiry since it is not supported.
Also added a PropertySlot::isVMInquiry() convenience query method.
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/JSObjectInlines.h:
(JSC::JSObject::getPrivateField):
* runtime/PropertySlot.h:
(JSC::PropertySlot::isVMInquiry const):
2020-07-21 Keith Miller <keith_miller@apple.com>
Fix FinalizationRegistry GC finalizer interation
https://bugs.webkit.org/show_bug.cgi?id=214586
<rdar://65854264>
Reviewed by Mark Lam and Yusuke Suzuki.
Turns out when you remove the ith element from a Vector and you
increment the index anyway you skip things... Use the helper
functions instead. This fixes an ASAN crash on our
FinalizationRegistry tests.
* heap/Heap.cpp:
(JSC::Heap::finalizeUnconditionalFinalizers):
* runtime/DeferredWorkTimer.cpp:
(JSC::DeferredWorkTimer::addPendingWork):
(JSC::DeferredWorkTimer::hasPendingWork):
(JSC::DeferredWorkTimer::hasDependancyInPendingWork):
(JSC::DeferredWorkTimer::cancelPendingWork):
* runtime/JSFinalizationRegistry.cpp:
(JSC::JSFinalizationRegistry::finalizeUnconditionally):
(JSC::JSFinalizationRegistry::takeDeadHoldingsValue):
2020-07-21 Saam Barati <sbarati@apple.com>
Disable NO_SMT by default
https://bugs.webkit.org/show_bug.cgi?id=214607
Reviewed by Filip Pizlo.
* runtime/OptionsList.h:
2020-07-21 Caio Lima <ticaiolima@gmail.com>
Debug build is failing after r264537 on Linux
https://bugs.webkit.org/show_bug.cgi?id=214596
Reviewed by Yusuke Suzuki.
Removing `ASSERT_UNDER_CONTEXPR_CONTEXT(0)` to avoid compilation
failure of Debug builds on Linux.
* runtime/IntlObject.cpp:
(JSC::relevantExtensionKeyString):
2020-07-21 Adrian Perez de Castro <aperez@igalia.com>
Unreview non-unified source build fix
* runtime/IntlDisplayNames.cpp: Add missing <unicode/ucurr.h> header.
2020-07-20 Mark Lam <mark.lam@apple.com>
TryGetById clobberize rules are wrong.
https://bugs.webkit.org/show_bug.cgi?id=163834
<rdar://problem/65625807>
Reviewed by Keith Miller.
Theoretically, TryGetById can do the same things GetById does i.e. reify lazy
properties, read the stack, etc. Hence, its clobberize rule should be clobberTop
just like GetById. However, in practice, we don't currently use @tryGetById to
access anything on the stack (and probably never will). But as a conservative
measure, we'll just treat TryGetById like it can. In clobberize terms, this
means we declare TryGetById as doing read(World) (just like GetById) instead of
read(Heap).
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGClobbersExitState.cpp:
(JSC::DFG::clobbersExitState):
2020-07-20 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, fix duplicate forward declaration introduced by merge conflict
https://bugs.webkit.org/show_bug.cgi?id=209779
* runtime/IntlRelativeTimeFormat.h:
2020-07-20 Yusuke Suzuki <ysuzuki@apple.com>
[ECMA-402] Implement Intl.DisplayNames
https://bugs.webkit.org/show_bug.cgi?id=209779
Reviewed by Ross Kirsling.
This patch implements Intl.DisplayNames behind useIntlDisplayNames=1 flag.
Intl.DisplayNames can offer readable "display-name" for ICU language, script, region, currency codes.
For example, it can offer "United States" string for "US" region code.
We use ICU ULocaleDisplayNames to implement it, except for currency since ULocaleDisplayNames is not supporting
currency correctly: it ignores "long", "short", and "narrow" style configurations. We need to call ucurr_getName
directly.
This patch appropriately adds unicode-language-id parsing in IntlLocale.cpp so that we can validate language id
when it is passed to `Intl.DisplayNames#of` as defined in the spec.
* CMakeLists.txt:
* DerivedSources-input.xcfilelist:
* DerivedSources-output.xcfilelist:
* DerivedSources.make:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* runtime/CommonIdentifiers.h:
* runtime/IntlDisplayNames.cpp: Added.
(JSC::IntlDisplayNames::create):
(JSC::IntlDisplayNames::createStructure):
(JSC::IntlDisplayNames::IntlDisplayNames):
(JSC::IntlDisplayNames::finishCreation):
(JSC::IntlDisplayNames::initializeDisplayNames):
(JSC::IntlDisplayNames::of const):
(JSC::IntlDisplayNames::resolvedOptions const):
(JSC::IntlDisplayNames::styleString):
(JSC::IntlDisplayNames::typeString):
(JSC::IntlDisplayNames::fallbackString):
* runtime/IntlDisplayNames.h: Copied from Source/JavaScriptCore/runtime/IntlRelativeTimeFormat.h.
* runtime/IntlDisplayNamesConstructor.cpp: Added.
(JSC::IntlDisplayNamesConstructor::create):
(JSC::IntlDisplayNamesConstructor::createStructure):
(JSC::IntlDisplayNamesConstructor::IntlDisplayNamesConstructor):
(JSC::IntlDisplayNamesConstructor::finishCreation):
(JSC::constructIntlDisplayNames):
(JSC::callIntlDisplayNames):
(JSC::IntlDisplayNamesConstructorSupportedLocalesOf):
* runtime/IntlDisplayNamesConstructor.h: Added.
* runtime/IntlDisplayNamesPrototype.cpp: Added.
(JSC::IntlDisplayNamesPrototype::create):
(JSC::IntlDisplayNamesPrototype::createStructure):
(JSC::IntlDisplayNamesPrototype::IntlDisplayNamesPrototype):
(JSC::IntlDisplayNamesPrototype::finishCreation):
(JSC::IntlDisplayNamesPrototypeFuncOf):
(JSC::IntlDisplayNamesPrototypeFuncResolvedOptions):
* runtime/IntlDisplayNamesPrototype.h: Added.
* runtime/IntlLocale.cpp:
(JSC::isUnicodeLanguageSubtag): Deleted.
(JSC::isUnicodeScriptSubtag): Deleted.
(JSC::isUnicodeRegionSubtag): Deleted.
* runtime/IntlNumberFormat.cpp:
(JSC::IntlNumberFormat::initializeNumberFormat):
* runtime/IntlObject.cpp:
(JSC::createDisplayNamesConstructor):
(JSC::IntlObject::finishCreation):
(JSC::isUnicodeLanguageSubtag):
(JSC::isUnicodeScriptSubtag):
(JSC::isUnicodeRegionSubtag):
(JSC::isUnicodeVariantSubtag):
(JSC::isUnicodeLanguageId):
(JSC::isWellFormedCurrencyCode):
* runtime/IntlObject.h:
(JSC::intlDisplayNamesAvailableLocales):
* runtime/IntlRelativeTimeFormat.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::displayNamesStructure):
* runtime/OptionsList.h:
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2020-07-20 Geoffrey Garen <ggaren@apple.com>
REGRESSION (r264242): [ macOS ] imported/w3c/web-platform-tests/wasm/jsapi/constructor/instantiate.any.html is a flaky crash
https://bugs.webkit.org/show_bug.cgi?id=214572
Unreviewed, reverting r264242.
* runtime/JSRunLoopTimer.cpp:
(JSC::epochTime):
(JSC::JSRunLoopTimer::Manager::timerDidFireCallback):
(JSC::JSRunLoopTimer::Manager::PerVMData::setRunLoop):
(JSC::JSRunLoopTimer::Manager::PerVMData::PerVMData):
(JSC::JSRunLoopTimer::Manager::PerVMData::~PerVMData):
(JSC::JSRunLoopTimer::Manager::timerDidFire):
(JSC::JSRunLoopTimer::Manager::registerVM):
(JSC::JSRunLoopTimer::Manager::scheduleTimer):
(JSC::JSRunLoopTimer::Manager::cancelTimer):
(JSC::JSRunLoopTimer::Manager::didChangeRunLoop):
* runtime/JSRunLoopTimer.h:
(JSC::JSRunLoopTimer::Manager::PerVMData::PerVMData):
* runtime/PromiseTimer.cpp:
(JSC::PromiseTimer::doWork):
(JSC::PromiseTimer::runRunLoop):
* runtime/VM.cpp:
(JSC::VM::VM):
(JSC::VM::create):
(JSC::VM::tryCreate):
(JSC::VM::setRunLoop):
* runtime/VM.h:
(JSC::VM::runLoop const):
2020-07-20 Ross Kirsling <ross.kirsling@sony.com>
[JSC] eval?.() should be indirect eval
https://bugs.webkit.org/show_bug.cgi?id=214568
Reviewed by Keith Miller.
eval?.() is specified as indirect eval, but (virtually) all implementations assumed it should be direct eval.
I raised this topic in today's TC39 meeting and we've decided to keep the spec as it is.
* parser/ASTBuilder.h:
(JSC::ASTBuilder::makeFunctionCallNode):
Don't use EvalFunctionCallNode for optional call of eval.
2020-07-20 Adrian Perez de Castro <aperez@igalia.com>
Non unified build fixes, midsummer 2020 edition
https://bugs.webkit.org/show_bug.cgi?id=213616
Unreviewed build fix.
* b3/air/AirTmpInlines.h:
(JSC::B3::Air::TmpWidth::widths): Moved from AirTmpWidth.h
* b3/air/AirTmpWidth.cpp: Included AirTmpInlines.h
* b3/air/AirTmpWidth.h: TmpWidth::widths() moved out from here.
* runtime/ExceptionFuzz.cpp: Add missing inclusion of JSCJSValueInlines.h
* runtime/StructureIDTable.cpp: Add missing inclusions of wtf/DataLog.h
and wtf/RawPointer.h
* runtime/VMTraps.cpp: Ditto.
2020-07-20 Keith Miller <keith_miller@apple.com>
Add support for FinalizationRegistries
https://bugs.webkit.org/show_bug.cgi?id=199888
Reviewed by Yusuke Suzuki.
This patch adds support for FinalizationRegistries. There are two
main parts to this patch, the first is refactoring PromiseTimer a
more general into DeferredWorkTimer. This allows us to finally
have a "real" setTimeout on the jsc command line. The second part
is adding all the new classes needed for FinalizationRegistries.
The refactoring is mostly a rename but does two main new
things. The first is that it now notifies the VM we have finished
a synchronuous JS execution, so that WeakRefs can be
collected. The second is that it now catches any exceptions and
forwards the to a new method on the global object method
table. For WebCore, this reports the exception to the console. For
API users, this calls their exceptionHandler block. For the CLI,
it exits with exit status 3 (our general exception exit
status). Unfortunately, there's not currently an ergonomic way to
pass the expected exception from the CLI arguments to this handler
so that's not supported here.
In order to support FinalizationRegistry this patch adds a "new"
class JSDestructibleInternalFieldObjectImpl, which allows us to
have a destructible object with internal fields. Since the order
of collection doesn't matter we currently use C++ HashTables on
the FinalizationRegistry. Since users can unregister objects while
the callback is pending we have a hash table for the live entries
and a second hash table for the dead ones. Lastly, because users
are not requred to provide a token for unregistration we have two
extra Vectors containing the live/dead objects that are not
unregisterible.
* API/JSAPIGlobalObject.cpp:
* API/JSAPIGlobalObject.mm:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* heap/Heap.cpp:
(JSC::Heap::finalizeUnconditionalFinalizers):
* jsc.cpp:
(functionSetTimeout):
(functionFinalizationRegistryLiveCount):
(functionFinalizationRegistryDeadCount):
(main):
(checkUncaughtException):
(checkException):
(GlobalObject::reportUncaughtExceptionAtEventLoop):
(runJSC):
* runtime/ArrayIteratorPrototype.cpp:
* runtime/CommonIdentifiers.h:
* runtime/DeferredWorkTimer.cpp: Renamed from Source/JavaScriptCore/runtime/PromiseTimer.cpp.
(JSC::DeferredWorkTimer::DeferredWorkTimer):
(JSC::DeferredWorkTimer::doWork):
(JSC::DeferredWorkTimer::runRunLoop):
(JSC::DeferredWorkTimer::addPendingWork):
(JSC::DeferredWorkTimer::hasPendingWork):
(JSC::DeferredWorkTimer::hasDependancyInPendingWork):
(JSC::DeferredWorkTimer::cancelPendingWork):
(JSC::DeferredWorkTimer::scheduleWorkSoon):
* runtime/DeferredWorkTimer.h: Renamed from Source/JavaScriptCore/runtime/PromiseTimer.h.
* runtime/FinalizationRegistryConstructor.cpp: Added.
(JSC::FinalizationRegistryConstructor::finishCreation):
(JSC::FinalizationRegistryConstructor::FinalizationRegistryConstructor):
(JSC::callFinalizationRegistry):
(JSC::constructFinalizationRegistry):
* runtime/FinalizationRegistryConstructor.h: Copied from Source/JavaScriptCore/API/JSAPIGlobalObject.cpp.
* runtime/FinalizationRegistryPrototype.cpp: Added.
(JSC::FinalizationRegistryPrototype::finishCreation):
(JSC::getFinalizationRegistry):
(JSC::protoFuncFinalizationRegistryRegister):
(JSC::protoFuncFinalizationRegistryUnregister):
* runtime/FinalizationRegistryPrototype.h: Copied from Source/JavaScriptCore/API/JSAPIGlobalObject.cpp.
* runtime/IdentifierInlines.h:
(JSC::Identifier::Identifier):
* runtime/JSFinalizationRegistry.cpp: Added.
(JSC::JSFinalizationRegistry::createStructure):
(JSC::JSFinalizationRegistry::create):
(JSC::JSFinalizationRegistry::finishCreation):
(JSC::JSFinalizationRegistry::visitChildren):
(JSC::JSFinalizationRegistry::destroy):
(JSC::JSFinalizationRegistry::finalizeUnconditionally):
(JSC::JSFinalizationRegistry::runFinalizationCleanup):
(JSC::JSFinalizationRegistry::takeDeadHoldingsValue):
(JSC::JSFinalizationRegistry::registerTarget):
(JSC::JSFinalizationRegistry::unregister):
(JSC::JSFinalizationRegistry::liveCount):
(JSC::JSFinalizationRegistry::deadCount):
(JSC::JSFinalizationRegistry::toStringName):
* runtime/JSFinalizationRegistry.h: Added.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::reportUncaughtExceptionAtEventLoop):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::stackOverflowFrameCallee const):
(JSC::JSGlobalObject::arrayIteratorProtocolWatchpointSet):
(JSC::JSGlobalObject::mapIteratorProtocolWatchpointSet):
(JSC::JSGlobalObject::setIteratorProtocolWatchpointSet):
(JSC::JSGlobalObject::stringIteratorProtocolWatchpointSet):
(JSC::JSGlobalObject::mapSetWatchpointSet):
(JSC::JSGlobalObject::setAddWatchpointSet):
(JSC::JSGlobalObject::arraySpeciesWatchpointSet):
(JSC::JSGlobalObject::arrayJoinWatchpointSet):
(JSC::JSGlobalObject::numberToStringWatchpointSet):
* runtime/JSInternalFieldObjectImpl.h:
* runtime/JSInternalFieldObjectImplInlines.h:
(JSC::Base>::visitChildren):
(JSC::JSInternalFieldObjectImpl<passedNumberOfInternalFields>::visitChildren): Deleted.
* runtime/JSPromise.cpp:
(JSC::JSPromise::resolve):
(JSC::JSPromise::reject):
* runtime/StructureIDTable.cpp:
(JSC::StructureIDTable::allocateID):
(JSC::StructureIDTable::deallocateID):
* runtime/VM.cpp:
(JSC::VM::VM):
(JSC::VM::~VM):
* runtime/VM.h:
* wasm/js/JSWebAssembly.cpp:
(JSC::webAssemblyModuleValidateAsyncInternal):
(JSC::instantiate):
(JSC::compileAndInstantiate):
(JSC::webAssemblyModuleInstantinateAsyncInternal):
(JSC::webAssemblyCompileStreamingInternal):
(JSC::webAssemblyInstantiateStreamingInternal):
* wasm/js/JSWebAssemblyCodeBlock.h:
2020-07-20 Michael Catanzaro <mcatanzaro@gnome.org>
JSC build scripts should be quiet by default
https://bugs.webkit.org/show_bug.cgi?id=214535
Reviewed by Saam Barati.
There's no need for these scripts to print "Nothing changed" when they don't do anything.
* offlineasm/asm.rb:
* offlineasm/generate_offset_extractor.rb:
* offlineasm/generate_settings_extractor.rb:
2020-07-19 Fujii Hironori <Hironori.Fujii@sony.com>
Unreviewed non-unified source build fix
* runtime/IntlDateTimeFormat.cpp:
* runtime/IntlRelativeTimeFormat.h:
2020-07-19 Michael Catanzaro <mcatanzaro@gnome.org>
-Warray-bounds warnings in testb3 and testair
https://bugs.webkit.org/show_bug.cgi?id=214533
Reviewed by Darin Adler.
Suppress these warnings when building testb3 and testair.
* shell/CMakeLists.txt:
2020-07-19 Michael Catanzaro <mcatanzaro@gnome.org>
cpp_generator.py:134: SyntaxWarning: "is" with a literal. Did you mean "=="?
https://bugs.webkit.org/show_bug.cgi?id=214530
Reviewed by Philippe Normand.
* inspector/scripts/codegen/cpp_generator.py:
(CppGenerator.cpp_type_for_unchecked_formal_in_parameter):
2020-07-18 Mark Lam <mark.lam@apple.com>
Fixed regression due to r264507: Math.{min|max} inequality test should use DoubleNotEqualOrUnordered instead DoubleNotEqualAndOrdered.
https://bugs.webkit.org/show_bug.cgi?id=214526
<rdar://problem/65778061>
Reviewed by Yusuke Suzuki.
This bug resulted in NaNs being handled by the "equal" case in some scenarios,
which resulted in an assertion failure in a ValueRep on an internal test.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileArithMinMax):
2020-07-18 Alexey Shvayka <shvaikalesh@gmail.com>
Redefining a property should not change its insertion index (Object.keys order)
https://bugs.webkit.org/show_bug.cgi?id=142933
Reviewed by Saam Barati.
Before this change, JSC used to delete & put back a non-indexed property just to
update attributes, which was less efficient and corrupted observable property order.
This patch:
1. Rewrites validateAndApplyPropertyDescriptor() to closely resemble the spec [1].
2. Drops property deletion, inlines putDescriptor(), and sets necessary Structure
flags in attributeChangeTransition().
3. Simplifies validateAndApplyPropertyDescriptor() a bit by obtaining GetterSetter
instance from current descriptor rather then calling getDirect().
This change aligns property order with V8 and SpiderMonkey, advancing provided
microbenchmarks by 5-85% (especially for objects in dictionary mode).
SixSpeed, SunSpider, and ARES-6 are all neutral.
[1]: https://tc39.es/ecma262/#sec-validateandapplypropertydescriptor
* runtime/JSObject.cpp:
(JSC::validateAndApplyPropertyDescriptor):
(JSC::JSObject::defineOwnNonIndexProperty):
(JSC::putDescriptor): Deleted.
* runtime/JSObjectInlines.h:
(JSC::JSObject::putDirectInternal):
* runtime/PropertyDescriptor.cpp:
(JSC::PropertyDescriptor::slowGetterSetter const):
(JSC::PropertyDescriptor::slowGetterSetter): Deleted.
* runtime/PropertyDescriptor.h:
* runtime/Structure.cpp:
(JSC::Structure::attributeChangeTransition):
2020-07-17 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Clean up resolveLocale
https://bugs.webkit.org/show_bug.cgi?id=214446
Reviewed by Darin Adler.
Introduce RelevantExtensionKey and optimize resolveLocale implementation which avoids using HashMap for input and output.
We instead use std::array<T, numberOfRelevantExtensionKeys> since # of RelevantExtensionKeys is only 6.
For input option, we use std::array<Optional<String>, numberOfRelevantExtensionKeys> since this distinguish non-set-option and null String().
For output extension values, we simply use std::array<String, numberOfRelevantExtensionKeys>.
* runtime/IntlCollator.cpp:
(JSC::IntlCollator::sortLocaleData):
(JSC::IntlCollator::searchLocaleData):
(JSC::IntlCollator::initializeCollator):
* runtime/IntlCollator.h:
* runtime/IntlDateTimeFormat.cpp:
(JSC::IntlDateTimeFormat::localeData):
(JSC::IntlDateTimeFormat::initializeDateTimeFormat):
* runtime/IntlDateTimeFormat.h:
* runtime/IntlNumberFormat.cpp:
(JSC::IntlNumberFormat::localeData):
(JSC::IntlNumberFormat::initializeNumberFormat):
* runtime/IntlNumberFormat.h:
* runtime/IntlObject.cpp:
(JSC::relevantExtensionKeyString):
(JSC::resolveLocale):
* runtime/IntlObject.h:
* runtime/IntlPluralRules.cpp:
(JSC::IntlPluralRules::localeData):
(JSC::IntlPluralRules::initializePluralRules):
* runtime/IntlPluralRules.h:
* runtime/IntlRelativeTimeFormat.cpp:
(JSC::IntlRelativeTimeFormat::localeData):
(JSC::IntlRelativeTimeFormat::initializeRelativeTimeFormat):
* runtime/IntlRelativeTimeFormat.h:
2020-07-17 Xan López <xan@igalia.com>
Math.max() can yield the wrong result for max(0, -0).
https://bugs.webkit.org/show_bug.cgi?id=204457
Reviewed by Mark Lam.
The implementations for Math.{max,min} in both DFG and FTL are not
considering the fact that according to the spec -0.0 < 0.0 (which
is not true for normal double arithmetic).
See: https://tc39.es/ecma262/#sec-math.max and https://tc39.es/ecma262/#sec-math.min
Beyond tweaking the algorithms used in DFG and FTL we must
implement the and/or operations on double in MIPS and ARMv7, since
these are used in the DFG JIT to distinguish between -0.0 and 0.0.
* assembler/ARMv7Assembler.h:
(JSC::ARMv7Assembler::vand):
(JSC::ARMv7Assembler::vorr):
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::andDouble):
(JSC::MacroAssemblerARMv7::orDouble):
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::andDouble):
(JSC::MacroAssemblerMIPS::orDouble):
* assembler/testmasm.cpp:
(JSC::testAndOrDouble):
(JSC::run):
* dfg/DFGAbstractInterpreterInlines.h: consider that -0.0 < 0.0 per the ECMAScript spec.
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGSpeculativeJIT.cpp: ditto.
(JSC::DFG::SpeculativeJIT::compileArithMinMax):
* ftl/FTLLowerDFGToB3.cpp: ditto.
(JSC::FTL::DFG::LowerDFGToB3::compileArithMinOrMax):
2020-07-17 Alexey Shvayka <shvaikalesh@gmail.com>
emitIsUndefined() should not special-case [[IsHTMLDDA]] objects
https://bugs.webkit.org/show_bug.cgi?id=214443
Reviewed by Yusuke Suzuki.
According to Annex B [1], there is only a handful of language constructs
that handle [[IsHTMLDDA]] objects: ToBoolean, abstract equality with `null`
or `undefined`, and `typeof`. Currently, op_is_undefined does special-case
masquarader objects, even though it is used beyond `typeof`.
With this change, emitIsUndefined() produces `=== undefined`, which meets
developer expectations and the spec for all its usages, while op_is_undefined
is renamed to op_typeof_is_undefined. New name offers better semantics and
clearly communicates the op should be avoided when implementing new features.
Apart from fixing default values with [[IsHTMLDDA]] objects [2], this change
brings significant speed-up: +50% for function parameters and +20% for
object destructuring (masqueradesAsUndefinedWatchpoint is not fired).
This patch also introduces similar emitIsNull() method to avoid breaking
masquarader object as superclass test262 case.
[1]: https://tc39.es/ecma262/#sec-IsHTMLDDA-internal-slot
[2]: https://tc39.es/ecma262/#sec-runtime-semantics-keyedbindinginitialization (step 2)
* bytecode/BytecodeList.rb:
* bytecode/BytecodeUseDef.cpp:
(JSC::computeUsesForBytecodeIndexImpl):
(JSC::computeDefsForBytecodeIndexImpl):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitEqualityOpImpl):
(JSC::BytecodeGenerator::emitIsUndefined): Deleted.
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::emitIsNull):
(JSC::BytecodeGenerator::emitIsUndefined):
* bytecompiler/NodesCodegen.cpp:
(JSC::ForInNode::emitBytecode):
(JSC::ClassExprNode::emitBytecode):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGWatchpointCollectionPhase.cpp:
(JSC::DFG::WatchpointCollectionPhase::handle):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileTypeOfIsUndefined):
(JSC::FTL::DFG::LowerDFGToB3::compileIsUndefined): Deleted.
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
* jit/JIT.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_typeof_is_undefined):
(JSC::JIT::emit_op_is_undefined): Deleted.
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_typeof_is_undefined):
(JSC::JIT::emit_op_is_undefined): Deleted.
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
2020-07-16 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Clean up Intl option parsing code by introducing intlOption<>
https://bugs.webkit.org/show_bug.cgi?id=214437
Reviewed by Ross Kirsling.
This patch introduces intlOption<>(...) function and remove redundant string comparisons.
This makes option handling efficient, and it makes code clean.
* runtime/IntlCollator.cpp:
(JSC::IntlCollator::initializeCollator):
* runtime/IntlDateTimeFormat.cpp:
(JSC::IntlDateTimeFormat::initializeDateTimeFormat):
* runtime/IntlNumberFormat.cpp:
(JSC::IntlNumberFormat::initializeNumberFormat):
* runtime/IntlObject.cpp:
(JSC::resolveLocale):
(JSC::supportedLocales):
* runtime/IntlObject.h:
* runtime/IntlObjectInlines.h:
(JSC::intlOption):
* runtime/IntlPluralRules.cpp:
(JSC::IntlPluralRules::initializePluralRules):
* runtime/IntlRelativeTimeFormat.cpp:
(JSC::IntlRelativeTimeFormat::initializeRelativeTimeFormat):
2020-07-16 Fujii Hironori <Hironori.Fujii@sony.com>
[WTF] Remove the unnecessary inner class DefaultHash<T>::Hash
https://bugs.webkit.org/show_bug.cgi?id=214389
Reviewed by Darin Adler.
* assembler/MacroAssemblerCodeRef.h:
* b3/B3CheckSpecial.h:
* b3/B3Kind.h:
* b3/B3ValueKey.h:
* b3/air/AirAllocateRegistersByGraphColoring.cpp:
* b3/air/AirArg.h:
* b3/air/AirTmp.h:
* bytecode/BytecodeIndex.h:
* bytecode/CallVariant.h:
* bytecode/CodeOrigin.h:
* bytecode/DFGExitProfile.h:
* bytecode/LazyOperandValueProfile.h:
* bytecode/ObjectPropertyCondition.h:
* bytecode/PropertyCondition.h:
* dfg/DFGAbstractHeap.h:
* dfg/DFGArgumentsEliminationPhase.cpp:
* dfg/DFGByteCodeParser.cpp:
* dfg/DFGCSEPhase.cpp:
* dfg/DFGCompilationKey.h:
* dfg/DFGDesiredGlobalProperty.h:
* dfg/DFGHeapLocation.h:
* dfg/DFGLivenessAnalysisPhase.cpp:
* dfg/DFGMinifiedID.h:
* dfg/DFGNodeFlowProjection.h:
* dfg/DFGPromotedHeapLocation.h:
* dfg/DFGPropertyTypeKey.h:
* dfg/DFGPureValue.h:
* ftl/FTLLocation.h:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNewArrayWithSpread):
(JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread):
(JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewObject):
* ftl/FTLSlowPathCallKey.h:
* heap/MarkedBlock.h:
* heap/VisitRaceKey.h:
* inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
* inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/expected/enum-values.json-result:
* inspector/scripts/tests/expected/type-declaration-array-type.json-result:
* inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
* inspector/scripts/tests/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
* jit/ICStats.h:
* jit/JITThunks.h:
* jit/Reg.h:
* jit/RegisterSet.h:
* parser/VariableEnvironment.h:
* profiler/ProfilerOrigin.h:
* profiler/ProfilerOriginStack.h:
* profiler/ProfilerUID.h:
* runtime/CachedTypes.cpp:
* runtime/ControlFlowProfiler.h:
* runtime/NativeFunction.h:
* runtime/PrototypeKey.h:
* runtime/RegExpKey.h:
* runtime/TemplateObjectDescriptor.h:
* runtime/TypeProfiler.h:
* runtime/VarOffset.h:
* runtime/WeakGCMap.h:
* wasm/WasmBBQPlan.h:
* wasm/WasmCodeBlock.h:
* wasm/WasmEntryPlan.h:
* wasm/WasmLLIntPlan.h:
* wasm/WasmSignature.h:
2020-07-16 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Use unvalidatedGet instead of get to access UnlinkedCodeBlock from CodeBlock destructor
https://bugs.webkit.org/show_bug.cgi?id=214403
<rdar://problem/65527229>
Reviewed by Mark Lam.
WriteBarrier<>::get has a check whether this is not executed when sweeping cells. This is good assertion since
destruction order of cells are not defined in general, so member cell access from a destructor is almost always wrong.
But in CodeBlock case, this is OK because (1) CodeBlock destructor accesses UnlinkedCodeBlock and (2) GC ensures that
CodeBlock gets destroyed before UnlinkedCodeBlock gets destroyed. So this assertion is hit incorrectly.
In this patch, we use WriteBarrier<>::unvalidatedGet in CodeBlock destructor to bypass the above assertion explicitly.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::~CodeBlock):
* heap/Heap.cpp:
(JSC::Heap::deleteUnmarkedCompiledCode):
2020-07-15 Fujii Hironori <Hironori.Fujii@sony.com>
[CMake][WebDriver] Generating WebDriverAtoms.cpp is rarely failing as "ImportError: No module named jsmin"
https://bugs.webkit.org/show_bug.cgi?id=214339
Reviewed by Don Olmstead.
* CMakeLists.txt: Renamed stageSharedScripts to JavaScriptCoreSharedScripts.
2020-07-15 Mark Lam <mark.lam@apple.com>
Add handling of out of memory handling while adding a worklet module.
https://bugs.webkit.org/show_bug.cgi?id=214354
<rdar://problem/65271931>
Reviewed by Yusuke Suzuki and Keith Miller.
Add VM::tryCreate() that can fail if we encounter an out of memory issue.
As always, we're taking a best effort approach to handling out of memory errors.
Hence, we will not attempt to exhaustively handle every OOME scenario. This patch
only checks for failure to allocate a BigInt due to Gigacage exhaustion. While it
doesn't handle other allocation errors, it does enable us to add handling of other
cases in the future as needed.
* runtime/VM.cpp:
(JSC::VM::VM):
(JSC::VM::tryCreate):
* runtime/VM.h:
2020-07-15 Jim Mason <jmason@ibinx.com>
[WTF] Fix PackedAlignedPtr for X86_64 canonical addresses
https://bugs.webkit.org/show_bug.cgi?id=214142
Reviewed by Mark Lam
Fixed pointer test to use unsigned in place of signed.
* wasm/js/WebAssemblyFunction.cpp:
(JSC::callWebAssemblyFunction):
2020-07-15 Alexey Shvayka <shvaikalesh@gmail.com>
Emit HasOwnPropertyFunctionCallDotNode for "Reflect" identifiers
https://bugs.webkit.org/show_bug.cgi?id=214325
Reviewed by Darin Adler and Saam Barati.
Currently, HasOwnPropertyFunctionCallDotNode is emitted for all ResolveNodes
except ones with "Reflect" identifier. This exception doesn't seem necessary
as ReflectObject inherits ordinary `Object.prototype.hasOwnProperty` method.
This patch removes the exception, advancing provided "Reflect" microbenchmark
by 20%. No behavior change.
* parser/ASTBuilder.h:
(JSC::ASTBuilder::makeFunctionCallNode):
2020-07-15 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Introduce JSCTEST_hardTimeout
https://bugs.webkit.org/show_bug.cgi?id=214343
Reviewed by Mark Lam.
JSC Debug tests are failing consistently these days, https://build.webkit.org/builders/Apple-Catalina-Debug-JSC-Tests/.
My guess is that some tests get stuck inside JSC even if timeout occurs. Let's consider the following case.
1. The test is having `JSC_useConcurrentJIT=0`.
2. The test is building super heavy FTL code in the main thread.
3. The timeout thread notifies the VM about the timeout.
4. But VM does not stop since it is running super heavy FTL compilation.
5. After 1200 seconds, buildbot terminates the entire test.
In the above case, JSC gets stuck, and eventually buildbot terminates.
In this patch, we introduce JSCTEST_hardTimeout. After soft-timeout (usual timeout) happens, we wait another JSCTEST_hardTimeout seconds.
And if the JSC shell is not finished, we forcefully terminates the JSC shell via exit(EXIT_FAILURE), to avoid entire JSC test termination
in buildbot.
We pick 300 seconds. This means, after soft-timeout occurs, we wait for 5 mins, and if the JSC shell is still active, kill it. 5 mins sounds
reasonable amount of time. And this should fit within buildbot's hard timeout (1200 seconds).
* jsc.cpp:
(startTimeoutTimer):
2020-07-14 Saam Barati <sbarati@apple.com>
We must hold the CodeBlock lock when calling StructureStubInfo::reset
https://bugs.webkit.org/show_bug.cgi?id=214332
<rdar://problem/64940787>
Reviewed by Yusuke Suzuki.
There was a race between resetting the StructureStubInfo, and reading from
it from the compiler thread. There was one place inside Repatch where we
didn't hold the CodeBlock's lock when calling StructureStubInfo::reset.
To make it clear which functions require the CodeBlock's lock to be
held when called, I've changed all such functions to take the
LockHolder as a parameter.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finalizeBaselineJITInlineCaches):
* bytecode/StructureStubClearingWatchpoint.cpp:
(JSC::StructureTransitionStructureStubClearingWatchpoint::fireInternal):
(JSC::AdaptiveValueStructureStubClearingWatchpoint::handleFire):
* bytecode/StructureStubInfo.cpp:
(JSC::StructureStubInfo::initGetByIdSelf):
(JSC::StructureStubInfo::initArrayLength):
(JSC::StructureStubInfo::initStringLength):
(JSC::StructureStubInfo::initPutByIdReplace):
(JSC::StructureStubInfo::initInByIdSelf):
(JSC::StructureStubInfo::addAccessCase):
(JSC::StructureStubInfo::reset):
(JSC::StructureStubInfo::visitWeakReferences):
(JSC::StructureStubInfo::setCacheType):
* bytecode/StructureStubInfo.h:
* jit/Repatch.cpp:
(JSC::fireWatchpointsAndClearStubIfNeeded):
(JSC::tryCacheGetBy):
(JSC::tryCachePutByID):
(JSC::tryCacheInByID):
2020-07-14 Mark Lam <mark.lam@apple.com>
Handle out of memory error while creating an error message in the literal parser.
https://bugs.webkit.org/show_bug.cgi?id=214313
<rdar://problem/65031745>
Reviewed by Saam Barati.
* runtime/LiteralParser.cpp:
(JSC::LiteralParser<CharType>::parse):
2020-07-14 Caitlin Potter <caitp@igalia.com>
[JSC] fixup LLInt fast path in op_get_private_name
https://bugs.webkit.org/show_bug.cgi?id=214311
Reviewed by Tadeu Zagallo.
The LLInt slow path would previously always be taken in op_get_private_name,
due to not comparing the operand field name's JSValue payload with the cached
field name, but the register index itself.
This fixup can't really be verified by tests, as it is primarily a
minor performance improvement.
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
2020-07-14 Xan Lopez <xan@igalia.com>
[JSC] Remove compiler warning in JSBigInt
https://bugs.webkit.org/show_bug.cgi?id=214298
Reviewed by Sam Weinig.
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::parseInt): no need to ASSERT >= 0 with an unsigned int.
2020-07-14 Fujii Hironori <Hironori.Fujii@sony.com>
Unreviewed non-unified build fixes
* runtime/IntlObject.cpp:
2020-07-13 Fujii Hironori <Hironori.Fujii@sony.com>
Unreviewed non-unified build fixes
* dfg/DFGCodeOriginPool.h:
2020-07-13 Saam Barati <sbarati@apple.com>
returnEarlyFromInfiniteLoopsForFuzzing and validateDoesGC may fail when used together in the FTL
https://bugs.webkit.org/show_bug.cgi?id=214289
<rdar://problem/65272138>
Reviewed by Keith Miller.
Because the patchpoint we use for returnEarlyFromInfiniteLoopsForFuzzing doesn't
read or write any heap ranges, B3 move memory ops around it. In particular, it
might move the validate DoesGC store above it. In the FTL, we should make returnEarlyFromInfiniteLoopsForFuzzing
mimic what Return does for validating DoesGC.
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileLoopHint):
2020-07-13 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] IntlLocale::initializeLocale should have scope.release
https://bugs.webkit.org/show_bug.cgi?id=214271
<rdar://problem/65467314>
Reviewed by Darin Adler.
Add missing scope.release() to suppress validateExceptionChecks crash.
* runtime/IntlLocale.cpp:
(JSC::IntlLocale::initializeLocale):
2020-07-13 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] FTL isCellOrMisc should be isCellOrMiscOrBigInt32
https://bugs.webkit.org/show_bug.cgi?id=214269
<rdar://problem/65475129>
Reviewed by Mark Lam.
FTL isCellOrMisc's check can accept BigInt32 too. So it should be isCellOrMiscOrBigInt32.
Since our proven type filter does not include SpecBigInt32, isCellOrMisc can be folded into
false for BigInt32 AbstractValue. This patch fixes that filter. And we also reviewed places
using isCellOrMisc / isNotCellOrMisc.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileSwitch):
(JSC::FTL::DFG::LowerDFGToB3::numberOrNotCellNorBigIntToInt32):
(JSC::FTL::DFG::LowerDFGToB3::isCellOrMiscOrBigInt32):
(JSC::FTL::DFG::LowerDFGToB3::isNotCellOrMiscOrBigInt32):
(JSC::FTL::DFG::LowerDFGToB3::isNumber):
(JSC::FTL::DFG::LowerDFGToB3::isNotNumber):
(JSC::FTL::DFG::LowerDFGToB3::isCellOrMisc): Deleted.
(JSC::FTL::DFG::LowerDFGToB3::isNotCellOrMisc): Deleted.
2020-07-13 Geoffrey Garen <ggaren@apple.com>
Unreviewed, re-landing r264242 with crash fixed.
Re-landed changeset:
"JSRunLoopTimer should use WTF::RunLoop rather than custom CF
code"
https://bugs.webkit.org/show_bug.cgi?id=214102
https://trac.webkit.org/changeset/264242
* runtime/JSRunLoopTimer.cpp:
(JSC::epochTime):
(JSC::JSRunLoopTimer::Manager::PerVMData::PerVMData):
(JSC::JSRunLoopTimer::Manager::timerDidFireCallback):
(JSC::JSRunLoopTimer::Manager::PerVMData::~PerVMData):
(JSC::JSRunLoopTimer::Manager::timerDidFire):
(JSC::JSRunLoopTimer::Manager::registerVM):
(JSC::JSRunLoopTimer::Manager::scheduleTimer):
(JSC::JSRunLoopTimer::Manager::cancelTimer):
(JSC::JSRunLoopTimer::Manager::PerVMData::setRunLoop): Deleted.
(JSC::JSRunLoopTimer::Manager::didChangeRunLoop): Deleted.
* runtime/JSRunLoopTimer.h:
(JSC::JSRunLoopTimer::Manager::PerVMData::PerVMData): Deleted.
* runtime/PromiseTimer.cpp:
(JSC::PromiseTimer::doWork):
(JSC::PromiseTimer::runRunLoop):
* runtime/VM.cpp:
(JSC::VM::VM):
(JSC::VM::create):
(JSC::VM::setRunLoop): Deleted.
* runtime/VM.h:
(JSC::VM::runLoop const):
2020-07-13 Keith Miller <keith_miller@apple.com>
Clean up SourceProvider and add caller relative load script to jsc.cpp
https://bugs.webkit.org/show_bug.cgi?id=214205
Reviewed by Yusuke Suzuki.
This patch originally was just to add an optional parameter to our
load function so that any relative path is computed with respect
to calling script. Rather than computing the path relative to the
current working directory. The main advantage of this is now you
can run all the JSTests/stress scripts from anywhere rather than
only from the stress directory. This also matches jsc.cpp's module
loader implementation.
To make this possible a surprising number of changes were
needed. Specifically, it was much easier to get this to work if we
converted SourceOrigin's url to a WTF::URL rather than just a
WTF::String. At the same time it became clear that
SourceProvider's m_sourceURL is really not a URL but more of a
file name, which can sometimes be a URL. It's possible that we
don't need m_sourceURL at all but we should do that in a different
patch.
Additionally, jsc.cpp now uses WTF::URL for handling file
paths. This is cleaner than managing trying to do it ourselves and
should work across all the ports.
Lastly, the JSC CLI no longer accepts "bare-name"
specifiers. i.e. all specifiers must start with "/", "./", or
"../". This matches what we do in our Obj-C API and in
WebCore. While fixing tests I also noticed that the error message
was almost useless since it didn't tell you what the specifier or
referrer in question so that information is now part of the user
visible error.
* API/JSAPIGlobalObject.mm:
(JSC::computeValidImportSpecifier):
(JSC::JSAPIGlobalObject::moduleLoaderImportModule):
* API/JSBase.cpp:
(JSEvaluateScript):
(JSCheckScriptSyntax):
* API/JSObjectRef.cpp:
(JSObjectMakeFunction):
* API/JSScript.mm:
(-[JSScript sourceCode]):
* API/JSScriptRef.cpp:
* API/glib/JSCContext.cpp:
(jsc_context_check_syntax):
* builtins/BuiltinExecutables.cpp:
(JSC::BuiltinExecutables::BuiltinExecutables):
* debugger/DebuggerLocation.cpp:
(JSC::DebuggerLocation::DebuggerLocation):
* debugger/DebuggerLocation.h:
(JSC::DebuggerLocation::DebuggerLocation):
* inspector/ScriptDebugServer.cpp:
(Inspector::ScriptDebugServer::sourceParsed):
* jsc.cpp:
(currentWorkingDirectory):
(absolutePath):
(GlobalObject::moduleLoaderImportModule):
(GlobalObject::moduleLoaderResolve):
(jscSource):
(fetchModuleFromLocalFileSystem):
(GlobalObject::moduleLoaderFetch):
(functionLoad):
(functionCallerSourceOrigin):
(functionDollarAgentStart):
(functionCheckModuleSyntax):
(runWithOptions):
(runInteractive):
(ModuleName::startsWithRoot const): Deleted.
(ModuleName::ModuleName): Deleted.
(extractDirectoryName): Deleted.
(resolvePath): Deleted.
* parser/Nodes.h:
(JSC::ScopeNode::source const):
(JSC::ScopeNode::sourceURL const): Deleted.
* parser/SourceCode.h:
(JSC::makeSource):
* parser/SourceCodeKey.h:
(JSC::SourceCodeKey::host const):
* parser/SourceProvider.cpp:
(JSC::SourceProvider::SourceProvider):
* parser/SourceProvider.h:
(JSC::SourceProvider::sourceURL const):
(JSC::StringSourceProvider::create):
(JSC::StringSourceProvider::StringSourceProvider):
(JSC::SourceProvider::url const): Deleted.
* runtime/CachedTypes.cpp:
(JSC::CachedSourceOrigin::encode):
(JSC::CachedSourceOrigin::decode const):
(JSC::CachedSourceProviderShape::encode):
(JSC::CachedStringSourceProvider::decode const):
(JSC::CachedWebAssemblySourceProvider::decode const):
* runtime/Error.cpp:
(JSC::addErrorInfo):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/ScriptExecutable.h:
(JSC::ScriptExecutable::sourceURL const):
* runtime/SourceOrigin.h:
(JSC::SourceOrigin::SourceOrigin):
(JSC::SourceOrigin::url const):
(JSC::SourceOrigin::string const):
(JSC::SourceOrigin::isNull const):
* runtime/ThrowScope.cpp:
(JSC::ThrowScope::throwException):
* runtime/ThrowScope.h:
(JSC::ThrowScope::throwException):
(JSC::throwVMException):
* tools/FunctionOverrides.cpp:
(JSC::initializeOverrideInfo):
* tools/JSDollarVM.cpp:
(JSC::doPrint):
(JSC::functionCrash):
2020-07-12 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] String.protoytpe.toLocaleLowerCase's availableLocales HashSet is inefficient
https://bugs.webkit.org/show_bug.cgi?id=213158
Reviewed by Darin Adler.
Currently, we are always creating the same HashSet every time String.protoytpe.toLocaleLowerCase is called.
We changed bestAvailableLocale to take predicate function. And we pass a predicate which returns true for
case-sensitive locales.
* runtime/IntlObject.cpp:
(JSC::bestAvailableLocale):
* runtime/IntlObject.h:
* runtime/IntlObjectInlines.h:
(JSC::bestAvailableLocale):
* runtime/StringPrototype.cpp:
(JSC::computeTwoCharacters16Code):
(JSC::toLocaleCase):
2020-07-12 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] We should keep unaligned access feature in certain architectures in macro-assembler
https://bugs.webkit.org/show_bug.cgi?id=214243
Reviewed by Darin Adler.
We introduced the assertion in r263049, but this assertion crashes in testb3 Debug build.
testb3 actually tests unaligned access feature since ARM64 and x64 allow it. And unaligned access is useful
for Yarr etc., so we want to keep unaligned access feature if architecture allows it. We should make this
assertion effective only if CPU(NEEDS_ALIGNED_ACCESS) is true.
* assembler/MacroAssembler.h:
(JSC::MacroAssembler::loadPtr):
2020-07-12 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Avoid JSString creation in Intl.Locale#{minimize,maximize}
https://bugs.webkit.org/show_bug.cgi?id=214231
Reviewed by Darin Adler.
Add initializeLocale function taking String to avoid unnecessary JSString creation
in Intl.Locale#{maximize,minimize}.
* runtime/IntlLocale.cpp:
(JSC::IntlLocale::initializeLocale):
* runtime/IntlLocale.h:
* runtime/IntlLocalePrototype.cpp:
(JSC::IntlLocalePrototypeFuncMaximize):
(JSC::IntlLocalePrototypeFuncMinimize):
2020-07-11 Yusuke Suzuki <ysuzuki@apple.com>
Intl.Locale maximize, minimize should return Intl.Locale instead of String
https://bugs.webkit.org/show_bug.cgi?id=214223
<rdar://problem/65413620>
Reviewed by Ross Kirsling.
Intl.Locale#{maximize,minimize} should return Intl.Locale object instead of generated locale string.
We also add some protection and use jsString instead of jsNontrivialString because it would be still
possible that ICU's locale recognition and our locale interpretation do not agree each other and ICU
failed to produce locale, and then the string becomes empty. Since this is a boundary between third-party
library and JSC, and we are not ensuring our invariant inside third-party library, taking safer path makes
it better.
We also change IntlLocale#{maximize,minimize} C++ function names to maximal and minimal to align them
to the sepc's definitions.
* runtime/IntlLocale.cpp:
(JSC::IntlLocale::maximal):
(JSC::IntlLocale::minimal):
(JSC::IntlLocale::maximize): Deleted.
(JSC::IntlLocale::minimize): Deleted.
* runtime/IntlLocale.h:
* runtime/IntlLocalePrototype.cpp:
(JSC::IntlLocalePrototypeFuncMaximize):
(JSC::IntlLocalePrototypeFuncMinimize):
(JSC::IntlLocalePrototypeFuncToString):
(JSC::IntlLocalePrototypeGetterBaseName):
(JSC::IntlLocalePrototypeGetterCalendar):
(JSC::IntlLocalePrototypeGetterCaseFirst):
(JSC::IntlLocalePrototypeGetterCollation):
(JSC::IntlLocalePrototypeGetterHourCycle):
(JSC::IntlLocalePrototypeGetterNumberingSystem):
(JSC::IntlLocalePrototypeGetterLanguage):
(JSC::IntlLocalePrototypeGetterScript):
(JSC::IntlLocalePrototypeGetterRegion):
2020-07-10 Chris Dumez <cdumez@apple.com>
Unreviewed, reverting r264242.
Caused many crashes on iOS bots
Reverted changeset:
"JSRunLoopTimer should use WTF::RunLoop rather than custom CF
code"
https://bugs.webkit.org/show_bug.cgi?id=214102
https://trac.webkit.org/changeset/264242
2020-07-10 Geoffrey Garen <ggaren@apple.com>
JSRunLoopTimer should use WTF::RunLoop rather than custom CF code
https://bugs.webkit.org/show_bug.cgi?id=214102
Reviewed by Darin Adler.
The generic RunLoop codepath was already mostly right. Just needed to
clarify the API to demonstrate that VMs do not hop from one RunLoop
to another.
* runtime/JSRunLoopTimer.cpp:
(JSC::epochTime): Removed the CF path.
(JSC::JSRunLoopTimer::Manager::PerVMData::PerVMData): Include a RunLoop
as a constructor argument so that the web thread can override it.
(JSC::JSRunLoopTimer::Manager::timerDidFireCallback): Removed the CF path.
(JSC::JSRunLoopTimer::Manager::PerVMData::~PerVMData): No need to
explicitly clear our RunLoop -- the RunLoop::Timer destructor will do
the job.
(JSC::JSRunLoopTimer::Manager::timerDidFire):
(JSC::JSRunLoopTimer::Manager::registerVM):
(JSC::JSRunLoopTimer::Manager::scheduleTimer):
(JSC::JSRunLoopTimer::Manager::cancelTimer): Removed the CF path.
(JSC::JSRunLoopTimer::Manager::PerVMData::setRunLoop): Deleted.
(JSC::JSRunLoopTimer::Manager::didChangeRunLoop): Deleted. Changing
RunLoops is not actually a feature we use.
* runtime/JSRunLoopTimer.h:
(JSC::JSRunLoopTimer::Manager::PerVMData::PerVMData): Deleted.
* runtime/PromiseTimer.cpp:
(JSC::PromiseTimer::doWork):
(JSC::PromiseTimer::runRunLoop): Removed the CF path.
* runtime/VM.cpp:
(JSC::VM::VM):
(JSC::VM::create):
(JSC::VM::setRunLoop): Deleted.
* runtime/VM.h:
(JSC::VM::runLoop const): Require a RunLoop in the VM constructor in
order to clarify that we always know our RunLoop and never change it.
2020-07-09 Brian Burg <bburg@apple.com>
REGRESSION(r262302): ITMLKit debuggables in listings are missing a title, use UUID instead
https://bugs.webkit.org/show_bug.cgi?id=214153
Reviewed by Devin Rousso.
* inspector/remote/cocoa/RemoteInspectorCocoa.mm:
(Inspector::RemoteInspector::listingForInspectionTarget const):
Looks like this is due to copypasta.
2020-07-09 Alexey Shvayka <shvaikalesh@gmail.com>
ErrorInstance::finishCreation() puts "message" twice, with different attributes
https://bugs.webkit.org/show_bug.cgi?id=214089
Reviewed by Yusuke Suzuki.
This change refactors appendSourceToError() to return new message, making it almost pure
and eliminating extra JSString -> String -> JSString conversion and {get,put}Direct() calls
from ErrorInstance::finishCreation(). Also, moves null message check as early as possible.
Removed putDirect() call didn't pass PropertyAttribute::DontEnum. An implementation detail,
that is about to change in https://webkit.org/b/142933, prevented "message" property from
beind redefined with PropertyAttribute::None.
No behavior change. Advances provided microbenchmark by 5%.
* runtime/ErrorInstance.cpp:
(JSC::appendSourceToErrorMessage):
(JSC::ErrorInstance::finishCreation):
(JSC::appendSourceToError): Deleted.
2020-07-08 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] B3 PureCSE should ignore values which are moved to new BasicBlock
https://bugs.webkit.org/show_bug.cgi?id=214115
<rdar://problem/65189470>
Reviewed by Saam Barati.
We are performing "Select" specialization like this.
BB#target
...
@a = Select(@p, @x, 42)
@b = Add(@a, 35)
Check(@b)
@c = ...
becomes this:
BB#predecessor
...
Branch(@p, #truecase, #falsecase)
BB#truecase:
@b_truecase = Add(@x, 35)
Check(@b_truecase)
Upsilon(@x, ^a)
Upsilon(@b_truecase, ^b)
Jump(#continuation)
BB#falsecase:
@b_falsecase = Add(42, 35)
Check(@b_falsecase)
Upsilon(42, ^a)
Upsilon(@b_falsecase, ^b)
Jump(#continuation)
BB#continuation:
@a = Phi()
@b = Phi()
Jump(#target)
BB#target
@c = ...
In the above transformation, we create a new BasicBlock and move @a and @b to that one. This is good since we do not need to rewrite all the use of @a and @b.
However, this confuses PureCSE since @a and @b point to a BasicBlock (BB#continuation) which is not inserted into the graph yet.
This patch changes PureCSE so that it ignores values which owners are not inserted yet.
* b3/B3BasicBlock.h:
(JSC::B3::BasicBlock::isInserted const):
* b3/B3GenericBlockInsertionSet.h:
(JSC::B3::GenericBlockInsertionSet::insert):
* b3/B3PureCSE.cpp:
(JSC::B3::PureCSE::findMatch):
(JSC::B3::PureCSE::process):
* b3/air/AirBasicBlock.h:
2020-07-08 Saam Barati <sbarati@apple.com>
Add a fuzzing toggle for LICM
https://bugs.webkit.org/show_bug.cgi?id=214093
Reviewed by Yusuke Suzuki.
We have an AI based safety checker for LICM, to determine if it's safe to
hoist nodes. Historically, we've had bugs here, where we allow unsafe
hoisting. In practice, we've been saved by safety checks also being hoisted
at the same time as the operation they're protecting, so even if we
have bugs in AI-based safeToExecute, things usually just work. Since
we've had security bugs here before, where the safety checks don't get hoisted,
leading to issues, it's helpful if we can fuzz this area. This patch implements
a way to says we won't hoist a node based on some probability, allowing us to play
with what does and doesn't get hoisted.
* dfg/DFGLICMPhase.cpp:
(JSC::DFG::LICMPhase::run):
* runtime/OptionsList.h:
2020-07-08 Saam Barati <sbarati@apple.com>
Add a way to return early from detected infinite loops to aid the fuzzer
https://bugs.webkit.org/show_bug.cgi?id=214067
Reviewed by Yusuke Suzuki.
It's useful for the fuzzer to not get stuck in infinite loops so its
test cases can make forward progress trying to find bugs. This patch
adds a new mechanism where we can early return if we've exceeded a total
execution count for a static loop in bytecode. Note: this is not on a
per-frame basis, but it's a way to implement this in a non-invasive way
which is also practical for the fuzzer to use.
* b3/air/AirAllocateRegistersAndStackAndGenerateCode.cpp:
(JSC::B3::Air::GenerateAndAllocateRegisters::generate):
* b3/air/AirCode.cpp:
(JSC::B3::Air::Code::emitEpilogue):
* b3/air/AirCode.h:
* b3/air/AirGenerate.cpp:
(JSC::B3::Air::generateWithAlreadyAllocatedRegisters):
* bytecode/BytecodeList.rb:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::~CodeBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileLoopHint):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_loop_hint):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* offlineasm/mips.rb:
* runtime/OptionsList.h:
* runtime/VM.cpp:
(JSC::VM::addLoopHintExecutionCounter):
(JSC::VM::getLoopHintExecutionCounter):
(JSC::VM::removeLoopHintExecutionCounter):
* runtime/VM.h:
2020-07-07 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] BytecodeGenerator should be robust against failed constant generation
https://bugs.webkit.org/show_bug.cgi?id=214062
<rdar://problem/65117916>
Reviewed by Saam Barati.
Some code in NodesCodegen.cpp assumes `jsValue(generator)` call for constant nodes must succeed.
But this can fail when BigInt in source code is too large and becomes OOM. BytecodeGenerator should
be robust against BigInt OOM.
* bytecompiler/NodesCodegen.cpp:
(JSC::ConstantNode::emitBytecodeInConditionContext):
(JSC::ArrayNode::emitBytecode):
(JSC::BinaryOpNode::tryFoldToBranch):
2020-07-07 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Should not pass Exception to JSPromise::reject
https://bugs.webkit.org/show_bug.cgi?id=214061
<rdar://problem/65134450>
Reviewed by Mark Lam.
In some places, we are passing Exception* as JSValue instead of Exception::value()'s JSValue.
Error and Exception are different, and Exception is not an object. We should pass Exception::value()'s
thrown value instead. I checked `reject(` call sites and ensure error is passed.
* API/JSAPIGlobalObject.mm:
(JSC::JSAPIGlobalObject::moduleLoaderImportModule):
(JSC::JSAPIGlobalObject::moduleLoaderFetch):
* jsc.cpp:
(GlobalObject::moduleLoaderImportModule):
(GlobalObject::moduleLoaderFetch):
* runtime/JSModuleLoader.cpp:
(JSC::JSModuleLoader::importModule):
(JSC::JSModuleLoader::resolve):
(JSC::JSModuleLoader::fetch):
(JSC::moduleLoaderParseModule):
* runtime/JSPromise.cpp:
(JSC::JSPromise::resolve):
(JSC::JSPromise::reject):
2020-07-07 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Fix btjs by recovering CallFrame::describeFrame
https://bugs.webkit.org/show_bug.cgi?id=214055
Reviewed by Mark Lam.
While CallFrame::describeFrame is not used in WebKit tree, it is used in LLDB btjs which is invoked from python.
So we need to keep it. We also use std::call_once based buffer allocation instead of `static char buffer[...]`
to avoid spreading debug-use-only buffer in BSS segment.
* interpreter/CallFrame.cpp:
(JSC::CallFrame::describeFrame):
* interpreter/CallFrame.h:
2020-07-07 Keith Miller <keith_miller@apple.com>
Bytecode UseDef should be aware of checkpoints
https://bugs.webkit.org/show_bug.cgi?id=213566
Reviewed by Saam Barati.
Previously, we tried to solve teaching DFG about uses and defs of
locals across checkpoints by asking what locals were def'd at some
checkpoint. However, this was subtly wrong because we couldn't
report any uses at subsequent checkpoints so DFG thought the
local was dead immediately after its birth.
This patch reverts that change and instead teaches BytecodeUseDef
about checkpoints. Right now, BytecodeUseDef only knows about
locals at checkpoints but in the future we may teach it about tmps
at well.
Since the vectors containing our liveness bitmaps were already
sparse (they are indexed by the bytecode offset) we can reuse the
gaps to hold our checkpoint liveness information. To make sure we
don't overlap between the next bytecode and a checkpoint for the
current bytecode there is now a static assert that the length of
the bytecode is greater than the number of checkpoints. This
assumption is already true for existing bytecodes with checkpoints (and
likely to be true for future ones anyway).
Many of the BytecodeLivenessPropegation functions have been
renamed to reflect that they operate over the full instruction,
including checkpoints, rather than just the BytecodeIndex passed.
Lastly, this patch makes a speculative fix to forAllKilledOperands where we
wouldn't report that all tmps die at the end of each bytecode. I can't think
of a case where this would break things but it's probably good hygiene.
* bytecode/BytecodeGeneratorification.cpp:
(JSC::GeneratorLivenessAnalysis::run):
* bytecode/BytecodeIndex.h:
(JSC::BytecodeIndex::BytecodeIndex):
(JSC::BytecodeIndex::checkpoint const):
(JSC::BytecodeIndex::withCheckpoint const):
(JSC::BytecodeIndex::pack):
* bytecode/BytecodeLivenessAnalysis.cpp:
(JSC::BytecodeLivenessAnalysis::computeFullLiveness):
(JSC::BytecodeLivenessAnalysis::dumpResults):
(JSC::tmpLivenessForCheckpoint):
(JSC::BytecodeLivenessAnalysis::getLivenessInfoAtBytecodeIndex): Deleted.
(JSC::livenessForCheckpoint): Deleted.
* bytecode/BytecodeLivenessAnalysis.h:
(JSC::BytecodeLivenessAnalysis::getLivenessInfoAtInstruction):
* bytecode/BytecodeLivenessAnalysisInlines.h:
(JSC::BytecodeLivenessPropagation::stepOverBytecodeIndexDef):
(JSC::BytecodeLivenessPropagation::stepOverBytecodeIndexUse):
(JSC::BytecodeLivenessPropagation::stepOverBytecodeIndexUseInExceptionHandler):
(JSC::BytecodeLivenessPropagation::stepOverBytecodeIndex):
(JSC::BytecodeLivenessPropagation::stepOverInstruction):
(JSC::BytecodeLivenessPropagation::computeLocalLivenessForInstruction):
(JSC::BytecodeLivenessPropagation::computeLocalLivenessForBlock):
(JSC::BytecodeLivenessPropagation::getLivenessInfoAtInstruction):
(JSC::BytecodeLivenessPropagation::stepOverInstructionDef): Deleted.
(JSC::BytecodeLivenessPropagation::stepOverInstructionUse): Deleted.
(JSC::BytecodeLivenessPropagation::stepOverInstructionUseInExceptionHandler): Deleted.
(JSC::BytecodeLivenessPropagation::computeLocalLivenessForBytecodeIndex): Deleted.
(JSC::BytecodeLivenessPropagation::getLivenessInfoAtBytecodeIndex): Deleted.
* bytecode/BytecodeUseDef.cpp:
(JSC::computeUsesForBytecodeIndexImpl):
(JSC::computeDefsForBytecodeIndexImpl):
* bytecode/BytecodeUseDef.h:
(JSC::computeUsesForBytecodeIndex):
(JSC::computeDefsForBytecodeIndex):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::ensureCatchLivenessIsComputedForBytecodeIndexSlow):
(JSC::CodeBlock::validate):
* bytecode/FullBytecodeLiveness.h:
(JSC::FullBytecodeLiveness::getLiveness const):
(JSC::FullBytecodeLiveness::toIndex):
* bytecode/Instruction.h:
(JSC::BaseInstruction::numberOfCheckpoints const):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::ForInContext::finalize):
* dfg/DFGForAllKills.h:
(JSC::DFG::forAllKilledOperands):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::isLiveInBytecode):
* dfg/DFGGraph.h:
* dfg/DFGMovHintRemovalPhase.cpp:
* dfg/DFGPlan.cpp:
(JSC::DFG::Plan::cleanMustHandleValuesIfNecessary):
* generator/Opcode.rb:
* generator/Section.rb:
2020-07-06 Geoffrey Garen <ggaren@apple.com>
callOnMainThread should use the same queue as RunLoop::dispatch
https://bugs.webkit.org/show_bug.cgi?id=213830
Reviewed by Brady Eidson.
* JavaScriptCore.order:
2020-07-05 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r263960.
https://bugs.webkit.org/show_bug.cgi?id=213980
Re-land, because r263959 somehow fixed the build issue caused
by r263953
Reverted changeset:
"Unreviewed, reverting r263953 and r263959."
https://bugs.webkit.org/show_bug.cgi?id=213979
https://trac.webkit.org/changeset/263960
2020-07-05 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r263953 and r263959.
https://bugs.webkit.org/show_bug.cgi?id=213979
Broke internal build
Reverted changesets:
"[Cocoa] Move almost all features from FeatureDefines.xcconfig
to PlatformEnableCocoa.h"
https://bugs.webkit.org/show_bug.cgi?id=212542
https://trac.webkit.org/changeset/263953
"[Cocoa] Remove FEATURE_DEFINES from the Cocoa/Xcode build
system"
https://bugs.webkit.org/show_bug.cgi?id=213976
https://trac.webkit.org/changeset/263959
2020-07-05 Darin Adler <darin@apple.com>
[Cocoa] Remove FEATURE_DEFINES from the Cocoa/Xcode build system
https://bugs.webkit.org/show_bug.cgi?id=213976
Reviewed by Sam Weinig.
* Configurations/Base.xcconfig: Removed FEATURE_DEFINES.
* Configurations/FeatureDefines.xcconfig: Removed.
* Configurations/JSC.xcconfig: Removed include of FeatureDefines.xcconfig.
* Configurations/JavaScriptCore.xcconfig: Ditto.
* Configurations/ToolExecutable.xcconfig: Ditto.
* DerivedSources-input.xcfilelist: Removed FeatureDefines.xcconfig.
* DerivedSources.make: Removed FEATURE_DEFINES and FEATURE_DEFINE_FLAGS.
* JavaScriptCore.xcodeproj/project.pbxproj: Removed FeatureDefines.xcconfig.
2020-07-05 Darin Adler <darin@apple.com>
[Cocoa] Move almost all features from FeatureDefines.xcconfig to PlatformEnableCocoa.h
https://bugs.webkit.org/show_bug.cgi?id=212542
Reviewed by Sam Weinig.
* Configurations/FeatureDefines.xcconfig: Delete everything except
ENABLE_EXPERIMENTAL_FEATURES and ENABLE_WEBRTC.
2020-07-05 Philippe Normand <pnormand@igalia.com>
Web Inspector: Fix python3 build warnings
https://bugs.webkit.org/show_bug.cgi?id=213971
Reviewed by Sam Weinig.
Fix Python3 syntax warnings. Using 'is' with string literals triggers those. Adopt the ==
operator instead, which is more idiomatic anyway.
* inspector/scripts/codegen/cpp_generator.py:
(CppGenerator.cpp_getter_method_for_type):
(CppGenerator.cpp_setter_method_for_type):
* inspector/scripts/codegen/objc_generator.py:
(ObjCTypeCategory.category_for_type):
(ObjCGenerator.objc_type_for_raw_name):
(ObjCGenerator.objc_class_for_raw_name):
(ObjCGenerator.protocol_type_for_raw_name):
(ObjCGenerator.objc_protocol_export_expression_for_variable):
(ObjCGenerator.objc_protocol_import_expression_for_variable):
(ObjCGenerator.objc_to_protocol_expression_for_member):
(ObjCGenerator.protocol_to_objc_expression_for_member):
(ObjCGenerator.payload_to_objc_expression_for_member):
(ObjCGenerator.objc_setter_method_for_member_internal):
(ObjCGenerator.objc_getter_method_for_member_internal):
(ObjCGenerator.objc_protocol_export_expression_for_variable.is): Deleted.
(ObjCGenerator.objc_protocol_import_expression_for_variable.is): Deleted.
(ObjCGenerator.objc_to_protocol_expression_for_member.is): Deleted.
(ObjCGenerator.protocol_to_objc_expression_for_member.is): Deleted.
2020-07-04 Darin Adler <darin@apple.com>
[Cocoa] Remove all features from FeatureDefines.xcconfig that are already mentioned in PlatformEnableCocoa.h
https://bugs.webkit.org/show_bug.cgi?id=213962
Reviewed by Sam Weinig.
* Configurations/FeatureDefines.xcconfig: Removed all features that were mentioned
in PlatformEnableCocoa.h; the rules in that file now define whether they are enabled.
2020-07-04 Alexey Shvayka <shvaikalesh@gmail.com>
%TypedArray%.prototype.{indexOf,lastIndexOf} are not spec-perfect
https://bugs.webkit.org/show_bug.cgi?id=213715
Reviewed by Yusuke Suzuki.
This patch:
1. Implements step 3 of {Array,%TypedArray%}.prototype.indexOf [1] and
%TypedArray%.prototype.lastIndexOf [2] since it is observable when
second argument is an object with userland toString() or valueOf() method.
Advances provided microbenchmark by 100% for Array and by 25% for %TypedArray%.
2. Removes argument count check from %TypedArray%.prototype.{indexOf,lastIndexOf},
allowing these methods to be invoked w/o arguments. The spec treats missing
arguments as `undefined`, always returning -1 for typed arrays.
Both changes align JSC with V8 and SpiderMonkey.
[1]: https://tc39.es/ecma262/#sec-array.prototype.indexof
[2]: https://tc39.es/ecma262/#sec-%typedarray%.prototype.lastindexof
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncIndexOf):
(JSC::arrayProtoFuncLastIndexOf):
* runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
(JSC::genericTypedArrayViewProtoFuncIndexOf):
(JSC::genericTypedArrayViewProtoFuncLastIndexOf):
2020-07-04 Darin Adler <darin@apple.com>
[Cocoa] Remove unconditional features from FeatureDefines.xcconfig, making sure they are covered in PlatformEnableCocoa.h
https://bugs.webkit.org/show_bug.cgi?id=212418
Reviewed by Sam Weinig.
* Configurations/FeatureDefines.xcconfig: Removed features that are either unconditionally not enabled,
or unconditionally enabled. Double checked that all the enabled ones are either in PlatformEnable.h or
PlatformEnableCocoa.h.
2020-07-03 Darin Adler <darin@apple.com>
Make generate-unified-sources.sh not depend on features being listed in FEATURE_DEFINES environment variable
https://bugs.webkit.org/show_bug.cgi?id=212420
Reviewed by Don Olmstead.
* Scripts/generate-unified-sources.sh: Removed many unneeded quote marks from the
invocation of generate-unified-source-bundles.rb.
2020-07-04 Darin Adler <darin@apple.com>
Update comment in FeatureDefines.xcconfig since PlatformEnableCocoa.h should be used instead
https://bugs.webkit.org/show_bug.cgi?id=213952
Reviewed by Sam Weinig.
* Configurations/FeatureDefines.xcconfig: Updated comment.
2020-07-03 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Promise should check whether a user-provided function is set by using `@isUndefinedOrNull`
https://bugs.webkit.org/show_bug.cgi?id=213951
Reviewed by Ross Kirsling.
If a user-provided function is masquerade-as-undefined value, `if (!xxx.@onRejected)` returns wrong
value since this function object is considered as undefined in this context. We should use `@isUndefinedOrNull`
here instead since this if-branch is checking whether this property is null/undefined actually.
And `if (@isUndefinedOrNull(...))` is efficient since we have `jundefined_or_null` / `jnundefined_or_null` bytecodes.
* builtins/PromiseOperations.js:
(globalPrivate.promiseReactionJob):
2020-07-03 Sam Weinig <weinig@apple.com>
Remove support for ENABLE_INPUT_TYPE_DATETIME_INCOMPLETE
https://bugs.webkit.org/show_bug.cgi?id=213932
Reviewed by Darin Adler.
Removes support for non-standard <input type="datetime">, currently being
guarded by the macro ENABLE_INPUT_TYPE_DATETIME_INCOMPLETE. This macro, was
added back in 2013 as a temporary measure to support some engines who shipped
support for <input type="datetime">. It is currently not enabled for any
ports so now seems like as good a time as any to remove it.
* Configurations/FeatureDefines.xcconfig:
2020-07-03 Sam Weinig <weinig@apple.com>
Add "-Wliteral-conversion" warning to Xcode based builds and fix the issues it finds
https://bugs.webkit.org/show_bug.cgi?id=213931
Reviewed by Darin Adler.
* Configurations/Base.xcconfig:
Add -Wliteral-conversion.
2020-07-03 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Add exception checks before and after viewWithUnderlyingString
https://bugs.webkit.org/show_bug.cgi?id=213923
<rdar://problem/65068473>
Reviewed by Sam Weinig.
This patch inserts missing exception checks before and after viewWithUnderlyingString.
* jsc.cpp:
(printInternal):
(functionDebug):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncParseFloat):
* runtime/JSONObject.cpp:
(JSC::JSONProtoFuncParse):
* runtime/StringPrototype.cpp:
(JSC::stringProtoFuncCharAt):
(JSC::stringProtoFuncCharCodeAt):
2020-07-03 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Add exception checks in JSStringBuilder and Array#join
https://bugs.webkit.org/show_bug.cgi?id=213915
<rdar://problem/64878225>
Reviewed by Saam Barati and Mark Lam.
This patch adds missing exception checks into Array#join's certain place and JSStringBuilder.
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncToString):
* runtime/JSStringJoiner.h:
(JSC::JSStringJoiner::append):
2020-07-03 Fujii Hironori <Hironori.Fujii@sony.com>
Builtin internal wrapper implementation files wrap static global initialization code with incorrect guards
https://bugs.webkit.org/show_bug.cgi?id=213792
Reviewed by Youenn Fablet.
Streams API hadn't worked since r263700 for AppleWin and WinCairo
ports. r263700 removed the unused ENABLE_STREAMS_API.
Before r263700, the static global initialization code was wrapped
by "ENABLE(WEB_RTC) || ENABLE(STREAMS_API)". After r263700, it was
wrapped by "ENABLE(WEB_RTC)". AppleWin and WinCairo doesn't turn
on ENABLE_WEB_RTC. So, builtins for Streams API weren't properly
initialized for them.
* Scripts/tests/builtins/expected/WebCoreJSBuiltins.h-result: Rebaselined.
* Scripts/wkbuiltins/builtins_generate_internals_wrapper_implementation.py:
(BuiltinsInternalsWrapperImplementationGenerator.generate_initialize_method):
Removed calling wrap_with_guard for the value of _generate_initialize_static_globals().
2020-07-02 Alex Christensen <achristensen@webkit.org>
Update Mac CMake build
* PlatformMac.cmake:
2020-07-02 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Configure option-offered numberingSystem in Intl.NumberFormat through locale
https://bugs.webkit.org/show_bug.cgi?id=213872
Reviewed by Ross Kirsling.
We need to pass numberingSystem option to ICU through locale when constructing UNumberFormat.
We are passing it when we get "en-US-u-nu-hanidec" locale, but we are not passing it when
we are getting `new Intl.NumberFormat("en-US", { numberingSystem: "hanidec" })`.
* runtime/IntlNumberFormat.cpp:
(JSC::IntlNumberFormat::initializeNumberFormat):
2020-07-01 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Intl.Collator should set usage:"search" option through ICU locale
https://bugs.webkit.org/show_bug.cgi?id=213869
Reviewed by Ross Kirsling.
Intl.Collator has usage:"search" option, and it affects on collation. However, UCollator does not have an interface to set this collation option,
and only way to configure UCollator is setting "-u-co-search" unicode extension to passed locale string. This patch adds "-u-co-search" unicode
extension if Usage::Search is specified.
* runtime/IntlCollator.cpp:
(JSC::IntlCollator::initializeCollator):
2020-07-01 Keith Miller <keith_miller@apple.com>
Rename zeroExtend32ToPtr to zeroExtend32ToWord
https://bugs.webkit.org/show_bug.cgi?id=213866
Reviewed by Saam Barati.
The old name no longer makes sense now that we have configurations
where sizeof(void*) != sizeof(CPURegister).
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::branchTruncateDoubleToInt32):
(JSC::MacroAssemblerARM64::zeroExtend32ToWord):
(JSC::MacroAssemblerARM64::branchMul32):
(JSC::MacroAssemblerARM64::zeroExtend32ToPtr): Deleted.
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::zeroExtend32ToWord):
(JSC::MacroAssemblerARMv7::zeroExtend32ToPtr): Deleted.
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::zeroExtend32ToWord):
(JSC::MacroAssemblerMIPS::zeroExtend32ToPtr): Deleted.
* assembler/MacroAssemblerX86Common.h:
(JSC::MacroAssemblerX86Common::add32):
(JSC::MacroAssemblerX86Common::and32):
(JSC::MacroAssemblerX86Common::mul32):
(JSC::MacroAssemblerX86Common::or32):
(JSC::MacroAssemblerX86Common::xor32):
(JSC::MacroAssemblerX86Common::zeroExtend32ToWord):
(JSC::MacroAssemblerX86Common::branchAdd32):
(JSC::MacroAssemblerX86Common::zeroExtend32ToPtr): Deleted.
* b3/air/AirOpcode.opcodes:
* bytecode/AccessCase.cpp:
(JSC::AccessCase::generateWithGuard):
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::compileExit):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileStringSlice):
(JSC::DFG::SpeculativeJIT::compileValueToInt32):
(JSC::DFG::SpeculativeJIT::compileUInt32ToNumber):
(JSC::DFG::SpeculativeJIT::setIntTypedArrayLoadResult):
(JSC::DFG::SpeculativeJIT::compileArithDiv):
(JSC::DFG::SpeculativeJIT::compileCreateRest):
(JSC::DFG::SpeculativeJIT::compileArraySlice):
(JSC::DFG::SpeculativeJIT::compileArrayIndexOf):
(JSC::DFG::SpeculativeJIT::compileNewTypedArrayWithSize):
(JSC::DFG::SpeculativeJIT::emitAllocateButterfly):
(JSC::DFG::SpeculativeJIT::compileWeakMapGet):
(JSC::DFG::SpeculativeJIT::emitInitializeButterfly):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::reboxAccordingToFormat):
* jit/CallFrameShuffler64.cpp:
(JSC::CallFrameShuffler::emitBox):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_has_indexed_property):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_has_indexed_property):
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_put_by_val):
* jit/JSInterfaceJIT.h:
(JSC::JSInterfaceJIT::emitLoadInt32):
* wasm/js/JSToWasm.cpp:
(JSC::Wasm::boxWasmResult):
* wasm/js/WasmToJS.cpp:
(JSC::Wasm::wasmToJS):
* wasm/js/WebAssemblyFunction.cpp:
(JSC::WebAssemblyFunction::jsCallEntrypointSlow):
* yarr/YarrJIT.cpp:
2020-07-01 Saam Barati <sbarati@apple.com>
Script to copy over testapi.js is redundant in xcodebuild
https://bugs.webkit.org/show_bug.cgi?id=213824
Reviewed by Keith Miller.
We're already copying over the entire testapiScripts directory.
No need to manually copy just one file from it, too.
* JavaScriptCore.xcodeproj/project.pbxproj:
2020-07-01 Tetsuharu Ohzeki <tetsuharu.ohzeki@gmail.com>
Use properly flag names for tests of Tools/Scripts/run-builtins-generator-tests
https://bugs.webkit.org/show_bug.cgi?id=213733
Reviewed by Youenn Fablet.
Test cases under Source/JavaScriptCore/Scripts/tests/builtins/ uses exist compilation flags.
But they can take an arbitary flag name and don't have to use an exist flag.
I think it's better to rename them to more proper ones.
* Scripts/tests/builtins/WebCore-ArbitraryConditionalGuard-Separate.js:
* Scripts/tests/builtins/WebCore-DuplicateKeyValueAnnotation-Separate.js:
* Scripts/tests/builtins/WebCore-GuardedBuiltin-Separate.js:
* Scripts/tests/builtins/WebCore-GuardedInternalBuiltin-Separate.js:
* Scripts/tests/builtins/WebCore-xmlCasingTest-Separate.js:
* Scripts/tests/builtins/expected/WebCore-ArbitraryConditionalGuard-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-GuardedBuiltin-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-GuardedInternalBuiltin-Separate.js-result:
* Scripts/tests/builtins/expected/WebCore-xmlCasingTest-Separate.js-result:
* Scripts/tests/builtins/expected/WebCoreJSBuiltins.h-result:
2020-06-30 Peng Liu <peng.liu6@apple.com>
Enable the support of FULLSCREEN_API in WebKitTestRunner
https://bugs.webkit.org/show_bug.cgi?id=213774
Reviewed by Youenn Fablet.
Replace the definition of ENABLE_FULLSCREEN_API in FeatureDefines.xcconfig with
the one in PlatformEnableCocoa.h. We have to do that because WebKitTestRunner
does not have a FeatureDefines.xcconfig but it uses "ENABLE(FULLSCREEN_API)"
to conditionally compile code to test the element fullscreen API.
WebKitTestRunner can use the macro defined in PlatformEnableCocoa.h.
* Configurations/FeatureDefines.xcconfig:
2020-06-30 Andy Estes <aestes@apple.com>
[Xcode] Enable the "My Mac (Mac Catalyst)" destination in WebKit Xcode projects
https://bugs.webkit.org/show_bug.cgi?id=213740
Reviewed by Darin Adler.
* Configurations/Base.xcconfig: Set SUPPORTS_MACCATALYST to YES to tell Xcode that this
project supports building for Mac Catalyst.
2020-06-29 Tetsuharu Ohzeki <tetsuharu.ohzeki@gmail.com>
Remove ENABLE_STREAMS_API compilation flag
https://bugs.webkit.org/show_bug.cgi?id=213728
Reviewed by Sam Weinig.
test cases under Scripts/tests/builtins/ does not uses
this removed compilation flag. So we don't have to touch them in this change.
But they are confusable so I plan to fix them in bug 213733.
* Configurations/FeatureDefines.xcconfig:
2020-06-29 Keith Miller <keith_miller@apple.com>
ConservativeRoots should mark any cell it finds an interior pointer to
https://bugs.webkit.org/show_bug.cgi?id=213686
Reviewed by Yusuke Suzuki.
Currently, if ConserativeRoots finds an interior pointer to a cell
it will only mark that cell if it's a butterfly of some
kind. However, this can cause problems if the C++ or B3 compilers
pre-compute the offset of some cell member they want to load from
after a call. If this happens and that interior pointer is the
only reference to the cell it can get collected while it is still
"alive".
A naive patch that doesn't return from
findGCObjectPointersForMarking after finding a live non-interior,
non-butterfly cell was a 2% regression on Speedometer2 and
JetStream2. So, this patch immediately returns after
marking some non-butterfly cell, which appears to have fixed the
regression locally. Given this was such a big regression (likely
from running MarkedBlock::isLive) more than once there's possibly
an optimization opportunity here. I filed
https://bugs.webkit.org/show_bug.cgi?id=213687 to investigate
further.
* heap/HeapCell.cpp:
(WTF::printInternal):
* heap/HeapCell.h:
(JSC::isJSCellKind):
(JSC::mayHaveIndexingHeader):
(JSC::hasInteriorPointers): Deleted.
* heap/HeapUtil.h:
(JSC::HeapUtil::findGCObjectPointersForMarking):
* heap/SlotVisitor.cpp:
(JSC::SlotVisitor::appendJSCellOrAuxiliary):
* runtime/VM.cpp:
(JSC::VM::VM):
2020-06-28 Geoffrey Garen <ggaren@apple.com>
Rename initializeThreading to initialize
https://bugs.webkit.org/show_bug.cgi?id=213674
Reviewed by Mark Lam.
* API/JSClassRef.cpp:
* API/JSContextRef.cpp:
(JSContextGroupCreate):
(JSGlobalContextCreate):
(JSGlobalContextCreateInGroup):
* API/JSObjectRef.cpp:
(JSClassCreate):
* API/JSStringRef.cpp:
(JSStringCreateWithCharacters):
(JSStringCreateWithUTF8CString):
(JSStringCreateWithCharactersNoCopy):
* API/JSStringRefCF.cpp:
(JSStringCreateWithCFString):
* API/tests/CompareAndSwapTest.cpp:
(testCompareAndSwap):
* API/tests/ExecutionTimeLimitTest.cpp:
(testExecutionTimeLimit):
* API/tests/FunctionOverridesTest.cpp:
(testFunctionOverrides):
* API/tests/MultithreadedMultiVMExecutionTest.cpp:
(startMultithreadedMultiVMExecutionTest):
* API/tests/PingPongStackOverflowTest.cpp:
(testPingPongStackOverflow):
* JavaScriptCore.order:
* assembler/testmasm.cpp:
(JSC::run):
* b3/air/testair.cpp:
(main):
* b3/testb3_1.cpp:
(main):
* dfg/testdfg.cpp:
(main):
* dynbench.cpp:
(main):
* inspector/remote/cocoa/RemoteInspectorCocoa.mm:
(Inspector::RemoteInspector::singleton):
* jsc.cpp:
(main):
(jscmain):
* runtime/InitializeThreading.cpp:
(JSC::initialize):
(JSC::initializeThreading): Deleted.
* runtime/InitializeThreading.h:
* runtime/JSCConfig.h:
* shell/playstation/TestShell.cpp:
(setupTestRun):
* testRegExp.cpp:
(main):
2020-06-27 Saam Barati <sbarati@apple.com>
BytecodeBasicBlock::addSuccessor should check if the successor already exists
https://bugs.webkit.org/show_bug.cgi?id=213670
Reviewed by Yusuke Suzuki.
It makes it nicer for algorithms using BytecodeGraph to not have to consider
whether or not there are duplicates in the successor list. Also, because of
this, bytecode liveness was doing extra work since it walked the successor list,
including any duplicates in it.
* bytecode/BytecodeBasicBlock.h:
(JSC::BytecodeBasicBlock::addSuccessor):
2020-06-27 Saam Barati <sbarati@apple.com>
Change bytecode dumping to dump the bytecode control flow graph
https://bugs.webkit.org/show_bug.cgi?id=213669
Reviewed by Yusuke Suzuki.
This makes the bytecode control flow graphs much easier to understand, and
puts bytecode dumping in more in line with how we dump other IRs.
The new dumps look like this:
```
foo#Ahf63N:[0x1035bc120->0x1035e5100, NoneFunctionCall, 36]: 13 instructions (0 16-bit instructions, 0 32-bit instructions, 1 instructions with metadata); 156 bytes (120 metadata bytes); 2 parameter(s); 8 callee register(s); 6 variable(s); scope at loc4
bb#1
[ 0] enter
[ 1] get_scope loc4
[ 3] mov loc5, loc4
[ 6] check_traps
[ 7] mov loc6, <JSValue()>(const0)
[ 10] mov loc6, Undefined(const1)
[ 13] mod loc7, arg1, Int32: 2(const2)
[ 17] jfalse loc7, 8(->25)
Successors: [ #3 #2 ]
bb#2
[ 20] mov loc6, Int32: 42(const3)
[ 23] jmp 5(->28)
Successors: [ #4 ]
bb#3
[ 25] mov loc6, Int32: 77(const4)
Successors: [ #4 ]
bb#4
[ 28] add loc7, arg1, loc6, OperandTypes(126, 126)
[ 34] ret loc7
Successors: [ ]
```
* bytecode/BytecodeDumper.cpp:
(JSC::dumpHeader):
(JSC::dumpFooter):
(JSC::CodeBlockBytecodeDumper<Block>::dumpBlock):
(JSC::CodeBlockBytecodeDumper<Block>::dumpGraph):
* bytecode/BytecodeDumper.h:
* bytecode/BytecodeGraph.h:
(JSC::BytecodeGraph::dump):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::dumpBytecode):
2020-06-27 Stephan Szabo <stephan.szabo@sony.com>
[PlayStation] Update test runner for changes to Options and signing
https://bugs.webkit.org/show_bug.cgi?id=213650
Reviewed by Don Olmstead.
* shell/playstation/Initializer.cpp: Load ICU library
* shell/playstation/TestShell.cpp: Update between test options reset
2020-06-26 Geoffrey Garen <ggaren@apple.com>
Initializing the main thread should initialize the main run loop
https://bugs.webkit.org/show_bug.cgi?id=213637
Reviewed by Anders Carlsson.
* JavaScriptCore.order: Removed some defunct stuff.
* shell/playstation/TestShell.cpp:
(setupTestRun): Merged initializeThreading call with
initializeMainThread call because initializeMainThread is a superset.
2020-06-25 Yusuke Suzuki <ysuzuki@apple.com>
REGRESSION(r263035): stress/get-prototype-of.js broken on s390x
https://bugs.webkit.org/show_bug.cgi?id=213307
Reviewed by Ross Kirsling.
Structure::m_outOfLineTypeFlags is uint16_t. If we access this field as 32bit field, we have different value in big endian architectures.
Since we do not have half-size-load branch instructions, we should load this uint16_t value via `loadh` (which zero-extends the loaded value)
and perform branch onto that value.
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitLoadPrototype):
* llint/LowLevelInterpreter64.asm:
2020-06-25 Mark Lam <mark.lam@apple.com>
JSCell constructor needs to ensure that the passed in structure is still alive.
https://bugs.webkit.org/show_bug.cgi?id=213593
<rdar://problem/64597573>
Reviewed by Yusuke Suzuki.
Note that in the initializer list of the `JSCell(VM&, Structure*)` constructor,
we are only using values inside the passed in structure but not necessarily the
structure pointer itself. All these values are contained inside Structure::m_blob.
Note also that this constructor is an inline function. Hence, the compiler may
choose to pre-compute the address of structure->m_blob and discard the structure
pointer itself.
Here's an example:
0x10317a21e <+1054>: movq 0x18(%rsp), %rdx // rdx:vm = &vm
0x10317a223 <+1059>: addq $0x8, %r13 // r13 = &structure.m_blob <== pre-compute address of m_blob !!!
// r13 previously contained the structure pointer.
// Now, there's no more references to the structure base address.
0x10317a227 <+1063>: leaq 0x48(%rdx), %rdi // arg0:heap = &vm.heap
0x10317a22b <+1067>: movl $0x10, %edx // arg2:size = 16.
0x10317a230 <+1072>: movq %rdi, 0x28(%rsp)
0x10317a235 <+1077>: xorl %esi, %esi // arg1:deferralContext = 0
0x10317a237 <+1079>: callq 0x10317ae60 // call JSC::allocateCell<JSC::JSArray> <== Can GC here !!!
0x10317a23c <+1084>: movq %rax, %rbx // rbx:cell = rax:allocation result.
...
0x10317a253 <+1107>: movl (%r13), %eax // eax = m_blob.structureID <== Use pre-computed m_blob address here.
There's a chance that the GC may run while allocating this cell. In the event
that the structure is newly instantiated just before calling this constructor,
there may not be any other references to it. As a result, the structure may get
collected before the cell is even constructed. To avoid this possibility, we need
to ensure that the structure pointer is still alive by the time this constructor
is called.
I am not committing any tests for this issue because the test cases relies on:
1. Manually forcing an O3 ASan Release build.
2. Not running jsc with --useDollarVM=1. Note: the JSC test harness automatically
adds --useDollarVM=1 for all test runs.
3. Memory being allocated in a specific order. The recent Bitmap FreeList change
enabled this issue to manifest. The old linked list FreeList implementation
would have hidden the issue.
4. Adding some logging code can also make the issue stop manifesting.
In short, the test cases will not detect any regression even if we commit them
because the existing automatic regression test runs will not have the necessary
conditions for reproducing the issue. The tests are also somewhat fragile where
any changes in memory layout may stop the issue from manifesting in an observable
way.
* runtime/JSCellInlines.h:
(JSC::JSCell::JSCell):
2020-06-24 Ross Kirsling <ross.kirsling@sony.com>
[Intl] Disprefer using ICU enums directly as instance variables
https://bugs.webkit.org/show_bug.cgi?id=213587
Reviewed by Yusuke Suzuki.
* runtime/IntlPluralRules.cpp:
(JSC::IntlPluralRules::initializePluralRules):
(JSC::IntlPluralRules::resolvedOptions const):
* runtime/IntlPluralRules.h:
* runtime/IntlRelativeTimeFormat.cpp:
(JSC::IntlRelativeTimeFormat::initializeRelativeTimeFormat):
(JSC::IntlRelativeTimeFormat::styleString): Renamed from JSC::styleString.
(JSC::IntlRelativeTimeFormat::resolvedOptions const):
(JSC::numericString): Deleted.
* runtime/IntlRelativeTimeFormat.h:
2020-06-24 Caitlin Potter <caitp@igalia.com>
[JSC] handle Put/DefinePrivateField in resetPutByID
https://bugs.webkit.org/show_bug.cgi?id=213583
Reviewed by Yusuke Suzuki.
r262613 extends and uses PutByValDirect to support updating and defining private fields, in order to reuse
the IC machinery. The necessary resetPutByID change was erroneously omitted, and is presented here.
* jit/Repatch.cpp:
(JSC::resetPutByID):
2020-06-24 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] llintTrue / jitTrue can encounter native functions
https://bugs.webkit.org/show_bug.cgi?id=213442
<rdar://problem/64257914>
Reviewed by Mark Lam.
If the CallFrame is for native function, associated CodeBlock is nullptr.
This patch fixes this case to handle it gracefully.
* tools/JSDollarVM.cpp:
(JSC::CallerFrameJITTypeFunctor::CallerFrameJITTypeFunctor):
(JSC::CallerFrameJITTypeFunctor::operator() const):
(JSC::functionBaselineJITTrue):
(JSC::JSDollarVM::finishCreation):
(JSC::functionJITTrue): Deleted.
2020-06-24 Umar Iqbal <uiqbal@apple.com>
We should resurrect the older patch that collects some statistics of web API calls
https://bugs.webkit.org/show_bug.cgi?id=213319
Reviewed by Brent Fulgham.
+ Enabled ENABLE_WEB_API_STATISTICS flag
* Configurations/FeatureDefines.xcconfig:
2020-06-24 Alexey Shvayka <shvaikalesh@gmail.com>
Add DFG/FTL fast path for GetPrototypeOf based on OverridesGetPrototype flag
https://bugs.webkit.org/show_bug.cgi?id=213191
Reviewed by Yusuke Suzuki.
This patch:
1. Introduces `loadInlineOffset` LLInt macro (64-bit only) and utilizes it in
`get_prototype_of` since we assert that `knownPolyProtoOffset` is an inline offset.
2. Brings baseline JIT fast path to 32-bit builds, progressing `super-getter.js`
microbenchmark by a factor of 10 (w/o DFG).
3. Adds GetPrototypeOf DFG/FTL fast paths that leverage OverridesGetPrototype type
info flag, advancing provided rare objects microbenchmark by ~46% (~37% w/o FTL).
Also, cleans up existing DFG fast path by using AssemblyHelpers::loadValue().
4. Extracts AssemblyHelpers::emitLoadPrototype() and uses it in baseline JIT, DFG, and
InstanceOfGeneric access case. With this change, `instanceof` access case handles all
[[GetPrototypeOf]] overrides (before: only Proxy objects), which is more correct, yet
not observable enough to provide a test case. `instanceof` microbenchmarks are neutral.
* bytecode/AccessCase.cpp:
(JSC::AccessCase::generateWithGuard):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileGetPrototypeOf):
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileGetPrototypeOf):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitLoadPrototype):
* jit/AssemblyHelpers.h:
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_get_prototype_of):
* llint/LowLevelInterpreter64.asm:
2020-06-24 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Clobberize misses `write(Heap)` report in some nodes
https://bugs.webkit.org/show_bug.cgi?id=213525
<rdar://problem/64642067>
Reviewed by Mark Lam.
In some DFG nodes, clobberize phase misses `clobberTopFunctor` call while it is `write(Heap)`,
which confuses clobberizing validation.
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
2020-06-23 Mark Lam <mark.lam@apple.com>
Handle string overflow in DFG graph dump while validating AI.
https://bugs.webkit.org/show_bug.cgi?id=213524
<rdar://problem/64635620>
Not reviewed.
Applying refinement suggested by Darin in https://bugs.webkit.org/show_bug.cgi?id=213524#c3.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::validateAIState):
2020-06-23 Mark Lam <mark.lam@apple.com>
Handle string overflow in DFG graph dump while validating AI.
https://bugs.webkit.org/show_bug.cgi?id=213524
<rdar://problem/64635620>
Reviewed by Saam Barati.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::validateAIState):
2020-06-23 Devin Rousso <drousso@apple.com>
Keyframe animation doesn't 't show up in the Animations timeline
https://bugs.webkit.org/show_bug.cgi?id=213441
Reviewed by Brian Burg.
* inspector/protocol/Animation.json:
An `interationCount` of `Infinity` is not JSON serializable, so represent it as `-1` instead.
2020-06-22 Saam Barati <sbarati@apple.com>
Attempt to fix watchOS simulator build.
* assembler/FastJITPermissions.h:
(threadSelfRestrictRWXToRW):
(threadSelfRestrictRWXToRX):
2020-06-22 Saam Barati <sbarati@apple.com>
Allow building JavaScriptCore Mac+arm64 in public SDK build
https://bugs.webkit.org/show_bug.cgi?id=213472
Reviewed by Sam Weinig.
We used to only builld code for fast permission switching when using the
Apple internal SDK. However, with arm64 on macOS, this is no longer a viable
implementation strategy.
This patch makes it so we can build JSC on macOS+arm64 using the public Xcode
SDK.
- ENABLE_FAST_JIT_PERMISSIONS is removed. We now use runtime checks instead.
- In the new suite of OS betas, pthreads has added API for fast permissions
switching. We now use this API instead of using the non-public SDK found in
the kernel headers.
- We fall back to the separated W/X heaps when fast permissions checking is
not supported. This all happens at runtime.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/ARM64Assembler.h:
(JSC::ARM64Assembler::fillNops):
* assembler/ARMv7Assembler.h:
(JSC::ARMv7Assembler::fillNops):
* assembler/FastJITPermissions.h: Added.
(useFastJITPermissions):
(threadSelfRestrictRWXToRW):
(threadSelfRestrictRWXToRX):
(fastJITPermissionsIsSupported):
* assembler/LinkBuffer.cpp:
(JSC::memcpyWrapper):
(JSC::LinkBuffer::copyCompactAndLinkCode):
* assembler/MIPSAssembler.h:
(JSC::MIPSAssembler::fillNops):
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::link):
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::link):
* jit/ExecutableAllocator.cpp:
(JSC::initializeJITPageReservation):
* jit/ExecutableAllocator.h:
(JSC::performJITMemcpy):
(JSC::useFastJITPermissions): Deleted.
* runtime/JSCConfig.h:
* runtime/Options.cpp:
(JSC::Options::recomputeDependentOptions):
* runtime/OptionsList.h:
2020-06-22 Tim Horton <timothy_horton@apple.com>
Disable the JS JIT when running in a translated process
https://bugs.webkit.org/show_bug.cgi?id=213478
Reviewed by Saam Barati.
* runtime/Options.cpp:
(JSC::Options::recomputeDependentOptions):
Based on our performance experiements, disable the JavaScript JIT
(but not the regular expression, DOM, or Wasm JIT) when running
in a translated process.
2020-06-22 Tim Horton <timothy_horton@apple.com>
Update macOS version macros
https://bugs.webkit.org/show_bug.cgi?id=213484
Reviewed by Alexey Proskuryakov.
* Configurations/Base.xcconfig:
* Configurations/DebugRelease.xcconfig:
* Configurations/Version.xcconfig:
* Configurations/WebKitTargetConditionals.xcconfig:
2020-06-19 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Check Gigacage usage before launching VM
https://bugs.webkit.org/show_bug.cgi?id=213410
Reviewed by Mark Lam.
Since VM allocates JSBigInt from Gigacage, it is possible that VM creation fails when Gigacage is exhausted.
As a work-around for internal testing, we insert ad-hoc Gigacage usage check before launching a new agent.
If 80% of Gigacage is used, we fail to launch a new VM gracefully.
* assembler/testmasm.cpp:
(JSC::testCagePreservesPACFailureBit):
* jsc.cpp:
(functionDollarAgentStart):
2020-06-19 James Darpinian <jdarpinian@chromium.org>
Typed array constructor behaves differently when length is not passed or when undefined is passed
https://bugs.webkit.org/show_bug.cgi?id=184232
Reviewed by Yusuke Suzuki.
Passing undefined for length should have the same effect as omitting the argument. It was being
treated as 0 instead.
* runtime/JSGenericTypedArrayViewConstructorInlines.h:
(JSC::constructGenericTypedArrayView):
2020-06-19 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Attempt to reduce timeout failures on Apple Watch Series 3
https://bugs.webkit.org/show_bug.cgi?id=213419
Reviewed by Mark Lam.
* tools/JSDollarVM.cpp:
(JSC::functionUseJIT):
(JSC::JSDollarVM::finishCreation):
2020-06-19 Mark Lam <mark.lam@apple.com>
toString of String doesn't check integrity of structureID in one path.
https://bugs.webkit.org/show_bug.cgi?id=213338
Reviewed by Saam Barati.
* runtime/StringPrototype.cpp:
(JSC::stringProtoFuncToString):
2020-06-19 Saam Barati <sbarati@apple.com>
Have a memory monitor thread in jsc shell when running tests using --memory-limited
https://bugs.webkit.org/show_bug.cgi?id=213389
Reviewed by Mark Lam.
When testing on iOS, there are times high memory usage from a JSC test
will jetsam our entire test runner. This makes it so we don't get any test
results from that test run, which can make it difficult to track testing
results.
This patch introduces an optional memory monitoring thread to the JSC
shell. It's a best effort approach. If memory usage exceeds the passed
in threshold, we crash the process. Similar to how the timeout mechanism
works. On Cocoa platforms, we also perform this check in the low memory
warning handler.
Currently, we use this feature when running JSC stress tests in
"--memory-limited" mode.
* jsc.cpp:
(crashIfExceedingMemoryLimit):
(startMemoryMonitoringThreadIfNeeded):
(jscmain):
2020-06-19 Mark Lam <mark.lam@apple.com>
Make $vm properties non-configurable, non-enumerable, and non-writable.
https://bugs.webkit.org/show_bug.cgi?id=213395
Reviewed by Saam Barati and Yusuke Suzuki.
$vm provides functions for test development and VM debugging. There's no reason
for them to be configurable, enumerable, and writable.
We particularly don't want them to be enumerable as this can trip up some fuzzers.
Fuzzers should not be fuzzing the $vm object which doesn't exist in real world
uses of JavaScriptCore.
* tools/JSDollarVM.cpp:
(JSC::JSDollarVM::finishCreation):
(JSC::JSDollarVM::addFunction):
(JSC::JSDollarVM::addConstructibleFunction):
2020-06-19 Tuomas Karkkainen <tuomas.webkit@apple.com>
functionCpuClflush checks that the second argument is Int32 but it actually expects it to be UInt32
https://bugs.webkit.org/show_bug.cgi?id=213388
Reviewed by Saam Barati.
This changes the check from isInt32() to isUInt32() so that the logic is consistent.
* tools/JSDollarVM.cpp:
2020-06-18 Mark Lam <mark.lam@apple.com>
Unify Bitmap math loops in MarkedBlock::Handle::specializedSweep().
https://bugs.webkit.org/show_bug.cgi?id=213345
Reviewed by Robin Morisset and Saam Barati.
This change appears to be performance neutral. However, we'll take the change
because we know that it does less work, and the new way of expressing the Bitmap
math in MarkedBlock::Handle::specializedSweep() does appear to be easier to
understand than the old code.
Also addressed feedback from Robin and Saam in https://bugs.webkit.org/show_bug.cgi?id=213071.
Changes made:
1. Use the new Bitmap::words() API to get direct access to the underlying bits
storage. With this, we can do the merging of the marked and newlyAllocated
bits with a single pass looping thru the bitmap words.
2. In MarkedBlock::Handle::specializedSweep()'s Bitmap free list code, moved the
implementation of handleDeadCells lambda down to the call to freeAtoms.forEachSetBit()
because this is the only place it is used.
3. Fixed MarkedBlock::Handle::specializedSweep()'s Bitmap free list code to
handle the dead cells unconditionally. This condition check was wrongly
adapted from the linked list implementation where handleDeadCell() was called
in 2 places depending on the destruction mode. With the Bitmap free list,
there is only once place to handle the dead cells, and it should be executed
unconditionally.
This fixes a bug where the FreeList::originalSize() never gets computed if the
cells in the block does not need destruction.
4. Renamed FreeList::bitmapRows() to FreeList::bitmapRowsMinusOne().
Renamed FreeList::offsetOfBitmapRows() to FreeList::offsetOfBitmapRowsMinusOne().
5. Also fixed some typos in comments.
* heap/FreeList.h:
(JSC::FreeList::bitmapIsEmpty const):
(JSC::FreeList::offsetOfBitmapRowsMinusOne):
(JSC::FreeList::bitmapRowsMinusOne const):
(JSC::FreeList::offsetOfBitmapRows): Deleted.
(JSC::FreeList::bitmapRows const): Deleted.
* heap/FreeListInlines.h:
(JSC::FreeList::allocate):
(JSC::FreeList::forEach const):
* heap/MarkedBlockInlines.h:
(JSC::MarkedBlock::Handle::specializedSweep):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitAllocateWithNonNullAllocator):
2020-06-18 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Remove dead non-ICU locale Date code since we are always using ICU version
https://bugs.webkit.org/show_bug.cgi?id=213362
Reviewed by Ross Kirsling.
There are old non-ICU version of Date locale code. But this is now dead code since we are always using ICU version,
which is invoked from builtin JS DatePrototype.js. We should remove these dead code.
* runtime/DatePrototype.cpp:
(JSC::DatePrototype::finishCreation):
(): Deleted.
(JSC::styleFromArgString): Deleted.
(JSC::formatLocaleDate): Deleted.
(JSC::dateProtoFuncToLocaleString): Deleted.
(JSC::dateProtoFuncToLocaleDateString): Deleted.
(JSC::dateProtoFuncToLocaleTimeString): Deleted.
2020-06-18 Ross Kirsling <ross.kirsling@sony.com>
Unreviewed, address Darin's feedback on r263227.
* runtime/IntlRelativeTimeFormat.cpp:
(JSC::IntlRelativeTimeFormat::UNumberFormatDeleter::operator() const):
(JSC::IntlRelativeTimeFormat::initializeRelativeTimeFormat):
(JSC::IntlRelativeTimeFormat::formatToParts const):
* runtime/IntlRelativeTimeFormat.h:
Keep ownership over our UNumberFormat instance after all,
to avoid relying on behavior ICU isn't explicitly guaranteeing.
2020-06-18 Ross Kirsling <ross.kirsling@sony.com>
[Intl] Enable RelativeTimeFormat and Locale by default
https://bugs.webkit.org/show_bug.cgi?id=213324
Reviewed by Yusuke Suzuki.
* runtime/IntlObject.cpp:
(JSC::createDateTimeFormatConstructor):
(JSC::createLocaleConstructor):
(JSC::createNumberFormatConstructor):
(JSC::createRelativeTimeFormatConstructor):
(JSC::IntlObject::finishCreation):
Unconditionalize creation of RelativeTimeFormat and Locale constructors.
* runtime/IntlRelativeTimeFormat.cpp:
(JSC::IntlRelativeTimeFormat::initializeRelativeTimeFormat):
(JSC::IntlRelativeTimeFormat::formatToParts const):
(JSC::IntlRelativeTimeFormat::UNumberFormatDeleter::operator() const): Deleted.
* runtime/IntlRelativeTimeFormat.h:
Fix an actual bug -- URelativeDateTimeFormatter *adopts* the UNumberFormat it's instantiated with,
so we can't keep a unique_ptr to it.
* runtime/OptionsList.h:
Remove feature flags.
2020-06-18 Alexey Shvayka <shvaikalesh@gmail.com>
Promise built-in functions should be anonymous non-constructors
https://bugs.webkit.org/show_bug.cgi?id=213317
Reviewed by Darin Adler.
This patch makes userland-exposed Promise built-in functions
non-constructors and sets their "name" properties to empty strings
as per spec [1], aligning JSC with V8 and SpiderMonkey.
@createResolvingFunctionsWithoutPromise change is covered by test262's
async-generator/yield-thenable-create-resolving-functions-*.js cases.
Promise microbenchmarks are neutral. Promise constructors bytecode is
unchanged, while @createResolvingFunctions* bytecode is reduced by 2
instructions.
[1]: https://tc39.es/ecma262/#sec-ecmascript-standard-built-in-objects
* builtins/PromiseConstructor.js:
(nakedConstructor.Promise):
(nakedConstructor.InternalPromise):
* builtins/PromiseOperations.js:
(globalPrivate.newPromiseCapabilitySlow):
(globalPrivate.createResolvingFunctions):
(globalPrivate.createResolvingFunctionsWithoutPromise):
(globalPrivate.createResolvingFunctions.resolve): Deleted.
(globalPrivate.createResolvingFunctions.reject): Deleted.
(resolve): Deleted.
(reject): Deleted.
* builtins/PromisePrototype.js:
(globalPrivate.getThenFinally):
(globalPrivate.getCatchFinally):
(valueThunk): Deleted.
(thrower): Deleted.
2020-06-18 Alexey Shvayka <shvaikalesh@gmail.com>
TypedArray.prototype.set is incorrect with primitives
https://bugs.webkit.org/show_bug.cgi?id=212730
Reviewed by Yusuke Suzuki.
This change implements step 14 of %TypedArray%.prototype.set [1],
which coerces primitives to objects instead of throwing an error,
aligning JSC with V8 and SpiderMonkey.
[1]: https://tc39.es/ecma262/#sec-%typedarray%.prototype.set-array-offset
* runtime/JSGenericTypedArrayViewPrototypeFunctions.h:
(JSC::genericTypedArrayViewProtoFuncSet):
2020-06-17 Mark Lam <mark.lam@apple.com>
Replace JSC::FreeList linked list with a Bitmap.
https://bugs.webkit.org/show_bug.cgi?id=213071
Reviewed by Filip Pizlo.
Implement an alternative to the linked list FreeList. This alternative uses
a Bitmap to record which atom in the block is available for allocation.
The intuition here is that allocation using the Bitmap implementation will do:
2 loads - m_currentRowBitmap, m_currentMarkedBlockRowAddress
1 store - m_currentRowBitmap
whereas the linked list implementation will do:
3 loads - m_scrambledHead, m_secret, result->scrambledNext
1 store - m_scrambledHead
and result->scrambledNext is from a different region of code and therefore not
in the same cache line.
The downside of the Bitmap implementation is that it uses more instructions.
This change is currently only enabled for x86_64, which shows about a 0.8%
progression on Speedometer 2.
It appears to be about a 1% regression on ARM64E. Hence, for now, we keep the
linked list implementation for ARM64 builds.
This is how the Bitmap FreeList works:
1. The Bitmap implementation only replaces the linked list implementation. It
does not replace the bump allocator.
2. The Bitmap allocator keeps a m_bitmap that is initialized in
MarkedBlock::Handle::specializedSweep() to have a bit set for each atom
location that is available for allocation (i.e. is free). Note that a cell
is usually allocated using more than 1 atom. Only the bit corresponding to
the first atom (in that cell length range of free atoms) will be set.
This is consistent with how bits in MarkedBlock::Footer::m_marks and
MarkedBlock::Footer::m_newlyAllocated are set i.e. only the bit for the first
atom in the cell can be set.
3. The allocation algorithm thinks of the MarkedBlock as consisting of rows
of atoms, where the number of atoms in a row equals the number of bits in
a AtomsBitmap::Word. On 64-bit CPUs, this would be 64.
We will start allocating from the last (highest numbered) row down to the
first (row 0). As we allocate, we will only update m_currentRowIndex and
m_currentRowBitmap. m_bitmap will not be updated. This is so in order to
reduce the number of instructions executed during an allocation.
When m_currentRowIndex points to N, the AtomsBitmap::Word for row N in
m_bitmap will have been copied into m_currentRowBitmap. This is the row
that we will be allocating from until the row is exhausted.
This is how we know whether an atom is available for allocation or not:
i. Atoms in any rows above m_currentRowIndex are guaranteed to be
allocated already (because we allocate downwards), and hence, are not
available.
ii. For row m_currentRowIndex, m_currentRowBitmap is the source of truth
on which atoms in the row are available for allocation.
iii. For rows below m_currentRowIndex, m_bitmap is the source of truth on
which atoms are available for allocation.
When m_currentRowIndex reaches 0, the info in m_bitmap is completely
obsoleted, and m_currentRowBitmap holds the availability info for row 0.
When both m_currentRowIndex and m_currentRowBitmap are 0, then we have
completely exhausted the block and no more atoms are available for
allocation.
4. Allocation happens in 3 paths: fast, middle, slow.
The fast path checks m_currentRowBitmap. If it's not 0, then we compute the
bit number of the lowest set bit in it. That bit number will be used together
with m_currentMarkedBlockRowAddress to compute the address of the atom
location available for allocation. m_currentRowBitmap will be updated to clear
the bit for the atom that has just ben allocated.
If m_currentRowBitmap is 0, then we'll go to the middle path.
The middle path checks m_currentRowIndex to see if we have more rows to allocate
from. For each m_currentRowIndex, we check its corresponding AtomsBitmap::Word
in m_bitmap. If the word is non-zero, we copy it to m_currentRowBitmap and
jump to the fast path to do the allocation. The middle path will update
m_currentRowIndex to point to the current row we're allocating from.
If we have decremented m_currentRowIndex down to 0 but still can't find a
non-zero AtomsBitmap::Word in m_bitmap, then the block has been exhausted, and
we'll go to the slow path.
The slow path is analogous to the old slow path i.e. we try to refill the
LocalAllocator with a new MarkedBlock.
5. On the layout of fields in FreeList (see changes in FreeList.h), we try to
preserve the positions of the bump allocator fields. The only change we made
there is in the location of m_cellSize. It is now moved up next to m_remaining,
and m_originalSize is moved down. This is because m_originalSize is only
accessed in the slow path, and m_cellSize is accessed in the bump allocation
path.
Next, we try to put Bitmap allocation fields where the linked list fields
would have been. The one bit of trickiness is that we'll put
m_currentMarkedBlockRowAddress in a union with m_payloadEnd. This is because
m_payloadEnd is only used in the bump allocation path. If m_remaining is 0,
then we can reuse this location for m_currentMarkedBlockRowAddress.
With this, we would have 4 bytes of padding after m_currentRowIndex. For
compactness, we put m_originalSize there in that space. For builds that use
the linked list implementation, m_originalSize will be located below after
m_cellSize.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::allocateHeapCell):
* heap/FreeList.cpp:
(JSC::FreeList::clear):
(JSC::FreeList::initializeAtomsBitmap):
(JSC::FreeList::initializeBump):
(JSC::FreeList::contains const):
(JSC::FreeList::dump const):
* heap/FreeList.h:
(JSC::FreeList::bitmapIsEmpty const):
(JSC::FreeList::allocationWillFail const):
(JSC::FreeList::offsetOfCurrentRowBitmap):
(JSC::FreeList::offsetOfBitmapRows):
(JSC::FreeList::offsetOfCurrentRowIndex):
(JSC::FreeList::offsetOfCurrentMarkedBlockRowAddress):
(JSC::FreeList::offsetOfRemaining):
(JSC::FreeList::atomsBitmap):
(JSC::FreeList::bitmapRows const):
(JSC::FreeList::offsetOfOriginalSize): Deleted.
* heap/FreeListInlines.h:
(JSC::FreeList::allocate):
(JSC::FreeList::forEach const):
* heap/LocalAllocator.cpp:
(JSC::LocalAllocator::isFreeListedCell const):
* heap/MarkedBlock.h:
(JSC::MarkedBlock::Handle::atomAt const):
* heap/MarkedBlockInlines.h:
(JSC::MarkedBlock::Handle::specializedSweep):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitAllocateWithNonNullAllocator):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::emitAllocateWithNonNullAllocator):
2020-06-17 Mark Lam <mark.lam@apple.com>
StructureIDTable::validate() doesn't work when compiled with GCC.
https://bugs.webkit.org/show_bug.cgi?id=213302
<rdar://problem/64452172>
Reviewed by Yusuke Suzuki.
I was previously using ensureStillAliveHere() to force the validation load to
not be elided. However, this is not how ensureStillAliveHere() works. The proper
way to force the load is to use a volatile pointer instead, which is applied in
this patch.
With Clang, the ensureStillAliveHere() happened to do what I expected, but with
GCC it did not. The compiler is at liberty to elide the load because there is
no memory clobbering operation between the load and the call to
ensureStillAliveHere(). Switching to using the volatile pointer solution.
* runtime/StructureIDTable.h:
(JSC::StructureIDTable::validate):
2020-06-17 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Freeze JSBigInt when setting it as a constant in AI
https://bugs.webkit.org/show_bug.cgi?id=213310
<rdar://problem/64450410>
Reviewed by Mark Lam.
JSCells should be explicitly frozen via DFG::Graph::freeze or DFG::Graph::freezeStrong. And heap JSBigInt is JSCell.
We should freeze it before setting it as a parameter of setConstant in AI. We use DFG::Graph::freeze since we know
that this is coming from somewhere in DFG graph: this ToNumeric node itself is not newly producing this JSBigInt.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2020-06-17 Keith Miller <keith_miller@apple.com>
$vm.haveABadTime/isHavingABadTime should work with non-globalObject parameters
https://bugs.webkit.org/show_bug.cgi?id=213304
Reviewed by Mark Lam.
Previously, $vm.haveABadTime would crash if passed a
non-globalObject object as the first parameter because it was
missing a `return` in front the error handling case. This patch
resolves that issue but also extends the semantics of
haveABadTime/isHavingABadTime to either use the global object of
the first parameter even if it's not a JSGlobalObject. If no
argument is passed, haveABadTime/isHavingABadTime instead use the
global object of the callee.
* tools/JSDollarVM.cpp:
(JSC::functionHaveABadTime):
(JSC::functionIsHavingABadTime):
2020-06-17 Mark Lam <mark.lam@apple.com>
Gardening: move some unused data inside ENABLE(JIT) to unbreak the CLoop build.
https://bugs.webkit.org/show_bug.cgi?id=213255
Not reviewed.
* assembler/testmasm.cpp:
2020-06-17 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, avoid node access in link-task
https://bugs.webkit.org/show_bug.cgi?id=213266
<rdar://problem/64453001>
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCheckJSCast):
2020-06-17 Mark Lam <mark.lam@apple.com>
Add a shiftAndAdd() emitter in AssemblyHelpers.
https://bugs.webkit.org/show_bug.cgi?id=213255
Reviewed by Michael Saboff.
void shiftAndAdd(RegisterID base, RegisterID index, uint8_t shift, RegisterID dest, Optional<RegisterID> = { });
Emits code to compute: dest = base + index << shift.
* assembler/testmasm.cpp:
(doubleOperands):
(floatOperands):
(int32Operands):
(int64Operands):
(JSC::testShiftAndAdd):
(JSC::run):
(JSC::doubleOperands): Deleted.
(JSC::floatOperands): Deleted.
(JSC::int32Operands): Deleted.
(JSC::int64Operands): Deleted.
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::shiftAndAdd):
2020-06-17 Michael Saboff <msaboff@apple.com>
[Wasm] Reduce the amount of memory used by the Air register coloring allocator
https://bugs.webkit.org/show_bug.cgi?id=212106
Reviewed by Yusuke Suzuki.
Changed InterferenceEdge to be a templated class so we can instantiate an unsigned
short version to cut memory in half for code that has less than 2^16 temps.
Through instrumentation, my testing showed that almost all compilations use the
16bit implementation. Although this change is for all B3/Air compilations at O2,
Wasm compilations are usally larger and therefore get the greatest benefit.
This allowed increasing the default value for the option webAssemblyBBQFallbackSize,
with a small increase in memory usage.
* b3/air/AirAllocateRegistersByGraphColoring.cpp:
* runtime/OptionsList.h:
2020-06-16 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Check NullSetterFunction under strict-mode context since structure / PropertyCondition are unaware of this
https://bugs.webkit.org/show_bug.cgi?id=213266
Reviewed by Mark Lam.
Our PropertyCondition is tracking the shape of Structure. This is enough for IC except for one case: throwing an error when invoking null setters in strict code.
"use strict";
var object = { get value() { return 42; } }
object.value = 42;
In the above case, we need to throw an error. Let's consider the following scenario.
1. Object has valid setter.
2. IC is buffering OPC which includes (1)'s object in [[Prototype]] hit.
3. IC commits buffered AccessCase with OPC. And PropertyCondition says Object + setter-offset => Presence.
4. Object deletes its setter.
5. Just after (4), DFG concurrently reads buffered committed OPCs.
6. DFG see that PropertyCondition is valid even after (4) since accessor property does exist.
7. Set up DFG sequence `GetSetter, Call`.
8. DFG calls null-setter under strict code, which is not assumed to be called.
In this patch, we insert NullSetterFunction check before setter invocation under strict mode. In IC, if we see NullSetterFunction,
we replace the calling target with special function which throws an error. In DFG / FTL, we emit `CheckNotJSCast` DFG node which
ensures that this setter is not null setter.
In IC code, we already have null-setter checking code before. So this change does not have any impact in terms of performance.
In DFG / FTL code, we only insert this check when we do not inline this setter. This is because inlining emits `CheckCell` anyway so
we can know that this is not NullSetterFunction. And this means that DFG Call opcode exists after CheckNotJSCast. Since Call opcode
loads the fields of call target anyway, this also does not affect on performance.
* bytecode/AccessCase.cpp:
(JSC::AccessCase::generateImpl):
* bytecode/PolymorphicAccess.cpp:
(JSC::PolymorphicAccess::regenerate):
* bytecode/PolymorphicAccess.h:
(JSC::AccessGenerationState::AccessGenerationState):
* bytecode/StructureStubInfo.cpp:
(JSC::StructureStubInfo::addAccessCase):
* bytecode/StructureStubInfo.h:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleCall):
(JSC::DFG::ByteCodeParser::handleInlining):
(JSC::DFG::ByteCodeParser::handlePutById):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::hasClassInfo const):
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCheckJSCast):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStructureAbstractValue.cpp:
(JSC::DFG::StructureAbstractValue::isNotSubClassOf const):
* dfg/DFGStructureAbstractValue.h:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileCheckJSCast):
* jit/Repatch.cpp:
(JSC::tryCacheGetBy):
(JSC::tryCacheArrayGetByVal):
(JSC::tryCachePutByID):
(JSC::tryCacheDeleteBy):
(JSC::tryCacheInByID):
(JSC::tryCacheInstanceOf):
* jit/ThunkGenerators.cpp:
(JSC::virtualThunkFor):
* runtime/InternalFunction.cpp:
(JSC::InternalFunction::finishCreation):
* runtime/JSCast.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::nullSetterStrictFunction const):
* runtime/JSType.cpp:
(WTF::printInternal):
* runtime/JSType.h:
* runtime/NullSetterFunction.cpp:
(JSC::NullSetterFunctionInternal::callThrowError):
(JSC::NullSetterFunction::NullSetterFunction):
* runtime/NullSetterFunction.h:
2020-06-16 Mark Lam <mark.lam@apple.com>
Make Options::useJIT() be the canonical source of truth on whether we should use the JIT.
https://bugs.webkit.org/show_bug.cgi?id=212556
<rdar://problem/63780436>
Reviewed by Saam Barati.
After r263055, Options::useJIT() always equals VM::canUseJIT() after canUseJIT()
has been computed. This patch removes VM::canUseJIT(), and replaces all calls to
it with calls to Options::useJIT().
In the old code, VM::canUseJIT() would assert s_canUseJITIsSet to ensure that
its clients will not access s_canUseJIT before it is initialized. We not have an
equivalent mechanism with Options. This is how it works:
1. There are 2 new Options flags in the g_jscConfig:
g_jscConfig.options.isFinalized
g_jscConfig.options.allowUnfinalizedAccess
g_jscConfig.options.isFinalized means that all Options values are finalized
i.e. initialization is complete and ready to be frozen in the Config.
g_jscConfig.options.isFinalized is set by initializeThreading() by calling
Options::finalize() once options initialization is complete.
g_jscConfig.options.allowUnfinalizedAccess is an allowance for clients to
access Options values before they are finalized. This is only needed in
options initialization code where Options values are read and written to.
g_jscConfig.options.allowUnfinalizedAccess is set and cleared using the
Options::AllowUnfinalizedAccessScope RAII object. The few pieces of code that
do options initialization will instantiate this scope object.
2. All Options accessors (e.g. Option::useJIT()) will now assert that either
g_jscConfig.options.allowUnfinalizedAccess or g_jscConfig.options.isFinalized
is set.
3. Since r263055, Options::recomputeDependentOptions() ensures that if useJIT() is
false, all other JIT options (e.g. useBaselineJIT(), useDFTJIT(), useFTLJIT(),
etc.) are also false. This patch also adds useBBQJIT() and useOMGJIT() to that
list.
With this, checks for useJIT() are now redundant if there's also another JIT
option check, e.g. useRegExpJIT() or useDFGJIT(). When redundant, this patch
elides the useJIT() check (which used to be a VM::canUseJIT() check).
Ideally, we should also introduce a separate abstraction for requested option
values before finalization than the finalized option values that will be adopted
by the system. We'll do this as a separate exercise in a later patch.
* API/tests/ExecutionTimeLimitTest.cpp:
(testExecutionTimeLimit):
* API/tests/FunctionOverridesTest.cpp:
(testFunctionOverrides):
* API/tests/PingPongStackOverflowTest.cpp:
(testPingPongStackOverflow):
- Removed redundant calls to Options::initialize().
* API/tests/testapi.c:
(main):
- move the call to testExecutionTimeLimit() to after finalizeMultithreadedMultiVMExecutionTest()
returns. This is because testExecutionTimeLimit() modifies JIT options at runtime
as part of its testing. This can wreak havoc on the rest of the system that expects
the options to be frozen. Ideally, we'll find a way for testExecutionTimeLimit() to
do its work without changing JIT options, but that is not easy to do. For now,
we'll just run it at the end as a workaround.
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::setNumParameters):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::numberOfArgumentValueProfiles):
(JSC::CodeBlock::valueProfileForArgument):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::isSupported):
* heap/Heap.cpp:
(JSC::Heap::completeAllJITPlans):
(JSC::Heap::iterateExecutingAndCompilingCodeBlocks):
(JSC::Heap::gatherScratchBufferRoots):
(JSC::Heap::removeDeadCompilerWorklistEntries):
(JSC::Heap::stopThePeriphery):
(JSC::Heap::suspendCompilerThreads):
(JSC::Heap::resumeCompilerThreads):
(JSC::Heap::addCoreConstraints):
* interpreter/AbstractPC.cpp:
(JSC::AbstractPC::AbstractPC):
* jit/JITThunks.cpp:
(JSC::JITThunks::ctiNativeCall):
(JSC::JITThunks::ctiNativeConstruct):
(JSC::JITThunks::ctiNativeTailCall):
(JSC::JITThunks::ctiNativeTailCallWithoutSavedTags):
(JSC::JITThunks::ctiInternalFunctionCall):
(JSC::JITThunks::ctiInternalFunctionConstruct):
(JSC::JITThunks::hostFunctionStub):
* jsc.cpp:
(CommandLine::parseArguments):
(jscmain):
* llint/LLIntEntrypoint.cpp:
(JSC::LLInt::setFunctionEntrypoint):
(JSC::LLInt::setEvalEntrypoint):
(JSC::LLInt::setProgramEntrypoint):
(JSC::LLInt::setModuleProgramEntrypoint):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::shouldJIT):
(JSC::LLInt::jitCompileAndSetHeuristics):
* runtime/InitializeThreading.cpp:
(JSC::initializeThreading):
* runtime/JSCConfig.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::numberToStringWatchpointSet):
* runtime/Options.cpp:
(JSC::jitEnabledByDefault):
(JSC::disableAllJITOptions):
(JSC::Options::initialize):
- Move the calls to dumpOptionsIfNeeded() and ensureOptionsAreCoherent() to the
end after all the options have been initialized because this where they belong.
(JSC::Options::finalize):
(JSC::Options::setOptions):
(JSC::Options::setOption):
(JSC::Options::dumpAllOptions):
(JSC::Options::ensureOptionsAreCoherent):
* runtime/Options.h:
(JSC::Options::AllowUnfinalizedAccessScope::AllowUnfinalizedAccessScope):
(JSC::Options::AllowUnfinalizedAccessScope::~AllowUnfinalizedAccessScope):
* runtime/OptionsList.h:
* runtime/RegExp.cpp:
(JSC::RegExp::compile):
(JSC::RegExp::compileMatchOnly):
* runtime/SymbolTable.h:
(JSC::SymbolTableEntry::isWatchable const):
* runtime/VM.cpp:
(JSC::VM::computeCanUseJIT):
(JSC::VM::VM):
(JSC::VM::getHostFunction):
(JSC::VM::getCTIInternalFunctionTrampolineFor):
* runtime/VM.h:
(JSC::VM::isInMiniMode):
(JSC::VM::canUseJIT): Deleted.
* wasm/WasmCapabilities.h:
(JSC::Wasm::isSupported):
* wasm/WasmOperations.cpp:
(JSC::Wasm::shouldJIT):
* wasm/WasmSlowPaths.cpp:
(JSC::LLInt::shouldJIT):
2020-06-16 Robin Morisset <rmorisset@apple.com>
Optimize Air::TmpWidth analysis in IRC
https://bugs.webkit.org/show_bug.cgi?id=152478
Reviewed by Filip Pizlo.
AirTmpWidth currently uses a HashMap to map tmps to their width.
Since tmps have consecutive indices, we can instead use vectors (one for GP and one for FP tmps).
As a bonus, we can just compute the width of the tmps of the bank the register allocator is currently looking at.
This cuts the time spent in the register allocator in JetStream2 by about 100ms out of 3.4s
(or sometimes 80ms out of 2.4, the bimodality of the time spent is due to a huge function in tagcloud-SP which usually but not always reach the FTL, I'll check later if it can be fixed by tweaking the inliner).
* b3/air/AirAllocateRegistersByGraphColoring.cpp:
(JSC::B3::Air::allocateRegistersByGraphColoring):
* b3/air/AirTmpWidth.cpp:
(JSC::B3::Air::TmpWidth::TmpWidth):
(JSC::B3::Air::TmpWidth::recompute):
* b3/air/AirTmpWidth.h:
(JSC::B3::Air::TmpWidth::width const):
(JSC::B3::Air::TmpWidth::requiredWidth):
(JSC::B3::Air::TmpWidth::defWidth const):
(JSC::B3::Air::TmpWidth::useWidth const):
(JSC::B3::Air::TmpWidth::Widths::Widths):
(JSC::B3::Air::TmpWidth::widths):
(JSC::B3::Air::TmpWidth::widths const):
(JSC::B3::Air::TmpWidth::addWidths):
(JSC::B3::Air::TmpWidth::widthsVector):
2020-06-16 Fujii Hironori <Hironori.Fujii@sony.com>
[CMake][Visual Studio] CombinedDomains.json is generated twice in JavaScriptCore.vcxproj and InspectorBackendCommands.vcxproj
https://bugs.webkit.org/show_bug.cgi?id=213225
Reviewed by Don Olmstead.
Since r262203 (Bug 210014) added a new target
InspectorBackendCommands, CombinedDomains.json is generated twice
in JavaScriptCore.vcxproj and InspectorBackendCommands.vcxproj.
This caused unnecessary incremental builds.
The fundamental issue of this issue was fixed in CMake side.
<https://gitlab.kitware.com/cmake/cmake/issues/16767>
However, JavaScriptCore target needs to have a direct or indirect
dependency of InspectorBackendCommands target for CMake Visual
Studio generator to eliminate duplicated custom commands.
* CMakeLists.txt: Added add_dependencies(JavaScriptCore InspectorBackendCommands).
2020-06-16 Mark Lam <mark.lam@apple.com>
Add SIGABRT handler for non OS(DARWIN) builds to the jsc shell with the -s option.
https://bugs.webkit.org/show_bug.cgi?id=213200
Reviewed by Michael Catanzaro.
This is needed because non OS(DARWIN) builds uses abort as their "CRASH"ing
mechanism.
* jsc.cpp:
(CommandLine::parseArguments):
2020-06-15 Michael Catanzaro <mcatanzaro@gnome.org>
WTF signal machinery is guarded by #if USE(PTHREADS) && HAVE(MACHINE_CONTEXT) but does not use pthreads or machine context
https://bugs.webkit.org/show_bug.cgi?id=213223
Reviewed by Mark Lam.
Use #if OS(UNIX) here too. This should fix stress/ensure-crash.js when
HAVE(MACHINE_CONTEXT) is false.
* jsc.cpp:
(printUsageStatement):
(CommandLine::parseArguments):
2020-06-15 Pavel Feldman <pavel.feldman@gmail.com>
Web Inspector: introduce request interception
https://bugs.webkit.org/show_bug.cgi?id=207446
Reviewed by Devin Rousso.
This change introduces network request interception to the Network
protocol domain. It adds Network.interceptWithRequest notification that
can be continued, modified or fulfilled. NetworkStage enum can now have
'request' and 'response' values.
* inspector/protocol/Network.json:
2020-06-15 Tadeu Zagallo <tzagallo@apple.com>
op_iterator_open getNext checkpoint needs to declare it uses m_iterator
https://bugs.webkit.org/show_bug.cgi?id=213106
<rdar://problem/63416838>
Reviewed by Keith Miller.
Currently, we have no way of specifying that a checkpoint uses an operand defined at an earlier
point in the same bytecode, which is the case for op_iterator_open: we assume that it will have
already allocated the iterator and stored it in m_iterator by the time we get to the getNext
checkpoint. In order to support that, we change tmpLivenessForCheckpoint to livenessForCheckpoint
and allow it to also declare the use of the operands defined within the bytecode.
* bytecode/BytecodeLivenessAnalysis.cpp:
(JSC::livenessForCheckpoint):
(JSC::tmpLivenessForCheckpoint): Deleted.
* bytecode/BytecodeLivenessAnalysis.h:
* bytecode/FullBytecodeLiveness.h:
* dfg/DFGForAllKills.h:
(JSC::DFG::forAllKilledOperands):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::isLiveInBytecode):
* dfg/DFGGraph.h:
2020-06-15 Alexey Shvayka <shvaikalesh@gmail.com>
Expand JSObject::defineOwnIndexedProperty() fast path for existing properties
https://bugs.webkit.org/show_bug.cgi?id=213133
Reviewed by Yusuke Suzuki.
This patch expands fast path of JSObject::defineOwnIndexedProperty() to cover existing properties
if given data descriptor has no falsy attributes, preventing the object from entering SparseMode.
The optimization is possible due to this invariant: indexed properties of non-SparseMode objects
have attributes of PropertyAttribute::None (except for typed arrays; added assert covers it).
PropertyDescriptor::attributesOverridingCurrent() with PropertyAttribute::None descriptor
is used to support partial descriptors like {value: 1, writable: true}.
This change advances Object.defineProperty microbenchmark by 35%; array read/write benchmark
following property redefinition is progressed by a factor of 16 due to avoiding SparseMode.
* runtime/JSObject.cpp:
(JSC::JSObject::defineOwnIndexedProperty):
2020-06-15 Robin Morisset <rmorisset@apple.com>
testB3::testReportUsedRegistersLateUseFollowedByEarlyDefDoesNotMarkUseAsDead() has a validation failure in debug mode
https://bugs.webkit.org/show_bug.cgi?id=196103
<rdar://problem/57808549>
Reviewed by Keith Miller.
The problem was trivial: patchpoints were referring to constants that were defined after them.
Just exchanging the order of the definition was enough to make this test pass.
* b3/testb3_1.cpp:
(shouldRun):
* b3/testb3_7.cpp:
(testReportUsedRegistersLateUseFollowedByEarlyDefDoesNotMarkUseAsDead):
2020-06-15 Mark Lam <mark.lam@apple.com>
Do not install the VMTraps signal handler if Options::useJIT=false.
https://bugs.webkit.org/show_bug.cgi?id=212543
<rdar://problem/63772519>
Reviewed by Keith Miller.
VMTraps is only needed for JITted code. Hence, if the JIT is disabled, we should
set Options::usePollingTraps() to true to indicate that we won't be using VMTraps.
With this change, we no longer install any signal handling machinery if
Options::useJIT() is false.
Because we may still disable the JIT even if useJIT() is true (due to failure to
allocate JIT memory or a number of other factors), we will also add a check of
VM::canUseJIT() in initializeThreading(), and disable useJIT() if needed. Of
course, this also means we need to call Options::recomputeDependentOptions() to
make other options consistent with useJIT() being false.
* runtime/InitializeThreading.cpp:
(JSC::initializeThreading):
* runtime/Options.cpp:
(JSC::disableAllJITOptions):
(JSC::Options::recomputeDependentOptions):
(JSC::recomputeDependentOptions): Deleted.
* runtime/Options.h:
* runtime/VMTraps.cpp:
(JSC::VMTraps::initializeSignals):
* tools/SigillCrashAnalyzer.cpp:
(JSC::SigillCrashAnalyzer::instance):
2020-06-15 Keith Miller <keith_miller@apple.com>
CheckIsConstant should not use BadCache exit kind
https://bugs.webkit.org/show_bug.cgi?id=213141
Reviewed by Yusuke Suzuki.
The BadCache exit kind causes the OSR exit compilers to try to
update ArrayProfiles. This is just incorrect for CheckIsConstant
since the node's origin may not even have an
ArrayProfile... BadCache also strongly assumes the value it's
profiling is a cell, which is clearly not always the case for
CheckIsConstant.
CheckIsConstant now uses the BadConstantValue (BadValue conflicts
with macros exported by X11 on GTK) exit kind for all use kinds,
which is just a rename of BadCell. All existing places where we
can emit a CheckIsConstant already have a story for BadConstantValue.
* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::computeFromLLInt):
(JSC::CallLinkStatus::computeExitSiteData):
* bytecode/ExitKind.cpp:
(JSC::exitKindToString):
* bytecode/ExitKind.h:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleInlining):
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
(JSC::DFG::ByteCodeParser::handleModuleNamespaceLoad):
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::handlePutByVal):
(JSC::DFG::ByteCodeParser::handleCreateInternalFieldObject):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::isPseudoTerminal):
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCheckIsConstant):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileCheckIsConstant):
(JSC::FTL::DFG::LowerDFGToB3::compileCheckBadValue):
(JSC::FTL::DFG::LowerDFGToB3::compileCheckBadCell): Deleted.
2020-06-15 Yusuke Suzuki <ysuzuki@apple.com>
Webkit Feature BigInt on webkit.org
https://bugs.webkit.org/show_bug.cgi?id=197546
Reviewed by Sam Weinig.
Add BigInt entry to JSC features.json.
* features.json:
2020-06-15 Keith Miller <keith_miller@apple.com>
JIT thunks should work on arm64_32
https://bugs.webkit.org/show_bug.cgi?id=213103
Reviewed by Saam Barati.
This patch fixes various issues when running JSC on arm64_32 with
useJIT=1 and useBaselineJIT=0. In particular this patch makes the
following changes:
1) ScalePtr is now just part of the Scale enum and is set based on
the size of the address space.
2) MacroAssembler::*Ptr functions call 32/64 bit variants based on
Address space size rather than cpu architecture. Vetting of callsites
using Ptr as 64 will happen in future patches since it's hard to
comprehensively vet.
3) Add some missing variants of functions for when pointers are 32-bit.
4) Add a load/storeReg function that stores a full register regardless
of pointer size for storing/loading callee saves.
5) numberOfDFGCompiles should report a big number for
useBaselineJIT=0 as some tests fail by default if useBaselineJIT=0
but useJIT=1.
6) Assert BaseIndex has a scale of PtrSize or TimesOne (for pre-scaled
values) when passed to a load/storePtr function.
* assembler/AbstractMacroAssembler.h:
(JSC::AbstractMacroAssembler::timesPtr): Deleted.
* assembler/MacroAssembler.h:
(JSC::MacroAssembler::rotateRightPtr):
(JSC::MacroAssembler::loadPtr):
(JSC::MacroAssembler::loadPtrWithCompactAddressOffsetPatch):
(JSC::MacroAssembler::branchPtr):
(JSC::MacroAssembler::storePtr):
(JSC::MacroAssembler::shouldBlindDouble):
(JSC::MacroAssembler::moveDouble):
(JSC::MacroAssembler::store64):
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::add32):
(JSC::MacroAssemblerARM64::signExtend32ToPtr):
(JSC::MacroAssemblerARM64::loadPtr):
(JSC::MacroAssemblerARM64::call):
(JSC::MacroAssemblerARM64::farJump):
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::rotateRight32):
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::rotateRight32):
* assembler/MacroAssemblerX86.h:
* assembler/MacroAssemblerX86_64.h:
* b3/B3LowerMacros.cpp:
* b3/testb3_6.cpp:
(testInterpreter):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::emitSwitchIntJump):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitLoadStructure):
(JSC::AssemblyHelpers::emitAllocateVariableSized):
(JSC::AssemblyHelpers::restoreCalleeSavesFromEntryFrameCalleeSavesBuffer):
(JSC::AssemblyHelpers::copyCalleeSavesToEntryFrameCalleeSavesBufferImpl):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::storeReg):
(JSC::AssemblyHelpers::loadReg):
(JSC::AssemblyHelpers::emitMaterializeTagCheckRegisters):
(JSC::AssemblyHelpers::emitGetFromCallFrameHeaderPtr):
(JSC::AssemblyHelpers::emitGetFromCallFrameHeader32):
(JSC::AssemblyHelpers::emitGetFromCallFrameHeader64):
(JSC::AssemblyHelpers::emitPutToCallFrameHeader):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_enumerator_structure_pname):
(JSC::JIT::emit_op_enumerator_generic_pname):
* jit/ThunkGenerators.cpp:
(JSC::nativeForGenerator):
* runtime/TestRunnerUtils.cpp:
(JSC::numberOfDFGCompiles):
2020-06-15 Caitlin Potter <caitp@igalia.com>
[JSC] add machinery to disable JIT tiers when experimental features are enabled
https://bugs.webkit.org/show_bug.cgi?id=213193
Reviewed by Mark Lam.
A new macro FOR_EACH_JSC_EXPERIMENTAL_OPTION() supplies flags indicating the supported
JIT tiers (or, in the future, other options) of a particular feature,
in an easy to understand format. These flags are then used to
recompute dependent feature flags.
This should simplify the incremental development of language features.
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* runtime/Options.cpp:
(JSC::recomputeDependentOptions):
* runtime/OptionsList.h:
2020-06-15 Keith Miller <keith_miller@apple.com>
Signal handlers should have a two phase installation.
https://bugs.webkit.org/show_bug.cgi?id=213160
Reviewed by Mark Lam.
* jsc.cpp:
(CommandLine::parseArguments):
(jscmain):
* runtime/InitializeThreading.cpp:
(JSC::initializeThreading):
* runtime/VMTraps.cpp:
* tools/SigillCrashAnalyzer.cpp:
(JSC::installCrashHandler):
* wasm/WasmFaultSignalHandler.cpp:
(JSC::Wasm::enableFastMemory):
(JSC::Wasm::prepareFastMemory):
* wasm/WasmFaultSignalHandler.h:
2020-06-15 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, fix LLInt
https://bugs.webkit.org/show_bug.cgi?id=157972
loadi only takes address.
* llint/LowLevelInterpreter64.asm:
2020-06-15 Alexey Shvayka <shvaikalesh@gmail.com>
super should not depend on __proto__
https://bugs.webkit.org/show_bug.cgi?id=157972
Reviewed by Saam Barati.
Before this change, both super() call [1] and super.property [2] relied on
Object.prototype.__proto__ to acquire super base, which was observable and
incorrect if __proto__ gets removed.
This patch introduces get_prototype_of bytecode, ensuring returned values
are profiled so the op can be wired to existing DFG and FTL implementations.
In order to avoid performance regression w/o DFG (__proto__ is optimized via
IntrinsicGetterAccessCase), fast paths for LLInt and baseline JIT are added
(64-bit only), utilizing OverridesGetPrototypeOutOfLine type info flag.
This change aligns JSC with V8 and SpiderMonkey, progressing microbenchmarks/
super-get-by-{id,val}-with-this-monomorphic.js by 7-10%. SixSpeed is neutral.
Also, extracts JSValue::getPrototype() method to avoid code duplication and
utilizes it in objectConstructorGetPrototypeOf(), advancing provided
microbenchmark by 40%.
[1]: https://tc39.es/ecma262/#sec-getsuperconstructor (step 5)
[2]: https://tc39.es/ecma262/#sec-getsuperbase (step 5)
* builtins/BuiltinNames.h:
* bytecode/BytecodeIntrinsicRegistry.h:
* bytecode/BytecodeList.rb:
* bytecode/BytecodeUseDef.cpp:
(JSC::computeUsesForBytecodeIndexImpl):
(JSC::computeDefsForBytecodeIndexImpl):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
* bytecode/Opcode.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitGetPrototypeOf):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::emitSuperBaseForCallee):
(JSC::emitGetSuperFunctionForConstruct):
(JSC::BytecodeIntrinsicNode::emit_intrinsic_getPrototypeOf):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsicGetter):
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGOperations.cpp:
* jit/IntrinsicEmitter.cpp:
(JSC::IntrinsicGetterAccessCase::canEmitIntrinsicGetter):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
* jit/JIT.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_get_prototype_of):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
* runtime/JSCJSValue.h:
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::getPrototype const):
* runtime/JSGlobalObjectFunctions.cpp:
(JSC::globalFuncProtoGetter):
* runtime/JSObject.cpp:
(JSC::JSObject::calculatedClassName):
* runtime/JSObject.h:
(JSC::JSObject::getPrototype):
* runtime/JSObjectInlines.h:
(JSC::JSObject::canPerformFastPutInlineExcludingProto):
(JSC::JSObject::getPropertySlot):
(JSC::JSObject::getNonIndexPropertySlot):
* runtime/JSProxy.h:
* runtime/JSTypeInfo.h:
(JSC::TypeInfo::overridesGetPrototype const):
* runtime/ObjectConstructor.cpp:
(JSC::objectConstructorGetPrototypeOf):
* runtime/ProxyObject.h:
* runtime/Structure.h:
* runtime/Structure.cpp:
(JSC::Structure::validateFlags):
2020-06-13 Devin Rousso <drousso@apple.com>
Make `errors` an own property of `AggregateError` instead of a prototype accessor
https://bugs.webkit.org/show_bug.cgi?id=212677
Reviewed by Yusuke Suzuki.
* runtime/AggregateError.h:
(JSC::AggregateError::destroy): Deleted.
(JSC::AggregateError::subspaceFor): Deleted.
(JSC::AggregateError::errors): Deleted.
* runtime/AggregateError.cpp:
(JSC::AggregateError::AggregateError):
(JSC::AggregateError::finishCreation): Added.
(JSC::AggregateError::visitChildren): Deleted.
* runtime/AggregateErrorPrototype.h:
* runtime/AggregateErrorPrototype.cpp:
(JSC::AggregateErrorPrototype::finishCreation):
(JSC::aggregateErrorPrototypeAccessorErrors): Deleted.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::initializeAggregateErrorConstructor):
* runtime/VM.h:
* runtime/VM.cpp:
(JSC::VM::VM):
* heap/Heap.cpp:
(JSC::Heap::finalizeUnconditionalFinalizers):
Remove `aggregateErrorSpace` since `AggregateError` doesn't add any new member variables.
Ensure that it can share an `IsoSubspace` with `ErrorInstance`.
* runtime/CommonIdentifiers.h:
Add `errors`.
2020-06-12 Robin Morisset <rmorisset@apple.com>
The ||= operator (and similar ones) should produce valid bytecode even if the right side is a static error
https://bugs.webkit.org/show_bug.cgi?id=213154
Reviewed by Devin Rousso.
There were two minor issues here that interacted:
- emitThrowReferenceError did not take an optional `dst` argument like everything else, and instead always returned a new temporary.
As a result, the various functions that sometimes did "return emitThrowReferenceError(..);" could return a different RegisterID than the one
provided to them through `dst`, breaking the invariant stated at the top of the file.
- ShortCircuitReadModifyResolveNode::emitBytecode used the result of such a function, unnecessarily, and (correctly) relied on the invariant being upheld.
The combination of these led to the bytecode trying to do a move of a temporary that was only defined in one of the predecessors of the basic block it was on,
which was caught by validateBytecode.
I fixed both issues, and verified that either fix is enough to stop the bug.
I fixed the first because other code may depend on that invariant in more subtle ways.
I fixed the second because it was just unnecessary complexity and made the code misleading.
I also reworded the comment at the top of NodesCodegen.cpp based on Keith's explanation and Mark's advice to make it less cryptic.
* bytecompiler/NodesCodegen.cpp:
(JSC::ThrowableExpressionData::emitThrowReferenceError):
(JSC::PostfixNode::emitBytecode):
(JSC::DeleteBracketNode::emitBytecode):
(JSC::DeleteDotNode::emitBytecode):
(JSC::PrefixNode::emitBytecode):
(JSC::ShortCircuitReadModifyResolveNode::emitBytecode):
(JSC::AssignErrorNode::emitBytecode):
* parser/Nodes.h:
2020-06-12 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] el(Greek) characters' upper-case conversion is locale-sensitive
https://bugs.webkit.org/show_bug.cgi?id=213155
<rdar://problem/55018467>
Reviewed by Darin Adler.
CLDR defines 4 locales which has language-sensitive case conversions. "az", "el", "lt", and "tr", where,
az = Azerbaijani
el = Greek
lt = Lithuanian
tr = Turkish
We can ensure it easily like this.
1. Download CLDR data
2. `ls common/transforms/*Upper.xml`
common/transforms/az-Upper.xml
common/transforms/el-Upper.xml
common/transforms/lt-Upper.xml
common/transforms/tr-Upper.xml
And ECMA-402 String.prototype.{toLocaleLowerCase,toLocaleUpperCase} requires these locales are listed as `availableLocales`.
> 7. Let availableLocales be a List with language tags that includes the languages for which the Unicode Character
> Database contains language sensitive case mappings. Implementations may add additional language tags if they
> support case mapping for additional locales.
https://tc39.es/ecma402/#sup-string.prototype.tolocalelowercase
This patch adds "el" to our maintained availableLocales list. Previously we only had "az", "lt", and "tr".
* runtime/StringPrototype.cpp:
(JSC::toLocaleCase):
(JSC::stringProtoFuncToLocaleUpperCase):
2020-06-12 Keith Miller <keith_miller@apple.com>
Tests expecting a crash should use a signal handler in the JSC CLI process
https://bugs.webkit.org/show_bug.cgi?id=212479
Reviewed by Yusuke Suzuki.
Have the -s option use WTF::Signals and make sure it adds breakpoint catching
as well.
* jsc.cpp:
(printUsageStatement):
(CommandLine::parseArguments):
* tools/SigillCrashAnalyzer.cpp:
(JSC::installCrashHandler):
2020-06-12 Alexey Shvayka <shvaikalesh@gmail.com>
AsyncGenerator should await "return" completions
https://bugs.webkit.org/show_bug.cgi?id=212774
Reviewed by Ross Kirsling.
This patch fixes 2 spec discrepancies, observable with async generators if the
value of "return" completion is a Promise, aligning JSC with V8 and SpiderMonkey.
* builtins/AsyncGeneratorPrototype.js:
(onFulfilled):
This change implements step 8 of AsyncGeneratorYield [1], that is executed after
step 15 of AsyncGeneratorResumeNext [2] (implemented as @doAsyncGeneratorBodyCall).
We are safe to rely on [[AsyncGeneratorState]] being "suspendedYield" (set in
step 6 of AsyncGeneratorYield [1]) instead of adding extra field to AsyncGenerator:
AsyncGeneratorResumeNext [2] does not overwrite "suspendedYield" state.
This change fixes most of test262 cases.
[1]: https://tc39.es/ecma262/#sec-asyncgeneratoryield
[2]: https://tc39.es/ecma262/#sec-asyncgeneratorresumenext
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitDelegateYield):
This change implements step 7.c.iii.1 of yield* runtime semantics [3], that is
observable only if [[Value]] has userland "then" getter. Awaited result is discarded.
This change fixes async-generator/yield-star-return-then-getter-ticks.js test262 case.
[3]: https://tc39.es/ecma262/#sec-generator-function-definitions-runtime-semantics-evaluation
2020-06-12 Ross Kirsling <ross.kirsling@sony.com>
Unreviewed, address Darin's feedback on r262890.
* runtime/IntlObject.cpp:
(JSC::addScriptlessLocaleIfNeeded):
Use != instead of < for clarity.
2020-06-12 Adrian Perez de Castro <aperez@igalia.com>
Build is broken with EVENT_LOOP_TYPE=GLib
https://bugs.webkit.org/show_bug.cgi?id=212987
Reviewed by Konstantin Tokarev.
* PlatformJSCOnly.cmake: Add sources needed to support the remote inspector to
JavaScriptCore_SOURCES.
2020-06-11 Saam Barati <sbarati@apple.com>
Linear Scan uses the wrong Interval for spills for tmps with roles of early def or late use
https://bugs.webkit.org/show_bug.cgi?id=213055
<rdar://problem/59874018>
Reviewed by Yusuke Suzuki.
There was a bug in linear scan when computing the live range interval for
spill tmps that had early defs or late uses. When linear scan spills a
tmp, it creates a new tmp that it loads to and stores from, and replaces the old tmp
with the new tmp, and emits stores/loads around pertinent instructions. The live
interval for such tmps is small by nature, it's contained in the interval for the
instruction itself. However, we'd build this interval purely based off the
original tmp's arg timing. So, for example, let's consider a program like this:
RandoInsn: LateUse:Tmp1, Use:Tmp2, [early = N, late = N+1]
Let's say that Tmp1's last use is RandoInsn, and it had a def before
RandoInsn, therefore, its live range will be something like:
[J where J < N, N+1]
and now imagine we spilled Tmp1 for some reason, and rewrote the
program to be:
Move Addr(spill for Tmp1), TmpSpill
RandoInsn: LateUse:TmpSpill, Use:Tmp2, [early = N, late = N+1]
We used to incorrectly mark the live range for TmpSpill to just be [N+1, N+2).
However, the bug here is that we neglected that TmpSpill actually had an earlier
def at [N, N+1). So, the live range for TmpSpill was wrong. This could incorrectly
lead us to allocate Tmp2 and TmpSpill to the same register, since their live
ranges may not intersect if Tmp2 dies at RandoInsn.
We also had the symmetric bug for EarlyDefs: we wouldn't account for the
store-spill that'd happen after something like RandoInsn.
The fix is to account for the loads/stores of spill tmps when assigning
them a live range.
This patch contains a standalone test in testair. It also fixes crashes we had when
running B3O1 tests using typed arrays on arm64e since we had patchpoints that utilized
LateUse for signing and auth.
* b3/B3Procedure.h:
* b3/air/AirAllocateRegistersAndStackByLinearScan.cpp:
* b3/air/testair.cpp:
2020-06-11 Saam Barati <sbarati@apple.com>
Replace uses of black/white list with block/allow list
https://bugs.webkit.org/show_bug.cgi?id=213084
Reviewed by Keith Miller.
We should be using racially neutral names in our code. From Chromium style guide:
"Terms such as 'blacklist' and 'whitelist' reinforce the notion that
black==bad and white==good."
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* b3/air/AirLowerAfterRegAlloc.cpp:
(JSC::B3::Air::lowerAfterRegAlloc):
* dfg/DFGDriver.cpp:
(JSC::DFG::ensureGlobalDFGAllowlist):
(JSC::DFG::compileImpl):
(JSC::DFG::ensureGlobalDFGWhitelist): Deleted.
* dfg/DFGTierUpCheckInjectionPhase.cpp:
(JSC::DFG::ensureGlobalFTLAllowlist):
(JSC::DFG::TierUpCheckInjectionPhase::run):
(JSC::DFG::ensureGlobalFTLWhitelist): Deleted.
* heap/MachineStackMarker.cpp:
* inspector/scripts/codegen/objc_generator.py:
(ObjCGenerator.should_generate_types_for_domain):
(ObjCGenerator.should_generate_commands_for_domain):
(ObjCGenerator.should_generate_events_for_domain):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::ensureGlobalJITAllowlist):
(JSC::LLInt::shouldJIT):
(JSC::LLInt::ensureGlobalJITWhitelist): Deleted.
* runtime/OptionsList.h:
* tools/FunctionAllowlist.cpp: Copied from Source/JavaScriptCore/tools/FunctionWhitelist.cpp.
(JSC::FunctionAllowlist::FunctionAllowlist):
(JSC::FunctionAllowlist::contains const):
(JSC::FunctionWhitelist::FunctionWhitelist): Deleted.
(JSC::FunctionWhitelist::contains const): Deleted.
* tools/FunctionAllowlist.h: Copied from Source/JavaScriptCore/tools/FunctionWhitelist.h.
* tools/FunctionWhitelist.cpp: Removed.
* tools/FunctionWhitelist.h: Removed.
2020-06-11 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Return DisposableCallSiteIndex when destroying GCAwareJITStubRoutineWithExceptionHandler
https://bugs.webkit.org/show_bug.cgi?id=213069
<rdar://problem/64205186>
Reviewed by Saam Barati.
Inside GCAwareJITStubRoutineWithExceptionHandler::observeZeroRefCount, we are returning DisposableCallSiteIndex to freelist.
However, GCAwareJITStubRoutineWithExceptionHandler::observeZeroRefCount can be called even if the code of GCAwareJITStubRoutineWithExceptionHandler is
on the stack. Let's consider the following scenario.
1. Execute GCAwareJITStubRoutineWithExceptionHandler's code. Set CallSiteIndex to the stack.
2. Execute more code. (1)'s GCAwareJITStubRoutineWithExceptionHandler's code is on the stack.
3. (1)'s GCAwareJITStubRoutineWithExceptionHandler's refcount becomes zero.
4. CallSiteIndex of GCAwareJITStubRoutineWithExceptionHandler is returned.
5. Execute StackVisitor to construct frames. But we cannot find CodeOrigin corresponding to CallSiteIndex stored in (1) since it is already returned.
DisposableCallSiteIndex should be returned after ensuring that GCAwareJITStubRoutineWithExceptionHandler's code is not on the stack. Detecting this is the functionality
what GCAwareJITStubRoutineWithExceptionHandler can offer. It is destroyed after ensuring that GCAwareJITStubRoutineWithExceptionHandler's code is not on the stack.
This patch delays DisposableCallSiteIndex returning until we destroy owner GCAwareJITStubRoutineWithExceptionHandler. But it is possible that CodeBlock* corresponding to
GCAwareJITStubRoutineWithExceptionHandler is already destroyed. To avoid this condition, we extract CodeOrigins vector as Ref<DFG::CodeOriginPool> and keep it alive from
GCAwareJITStubRoutineWithExceptionHandler too. And since CodeOrigin addition / removal happens only from the main thread after finishing the compilation, and
GCAwareJITStubRoutineWithExceptionHandler's destructor is called from the Heap's finalizer, which must be executed from the main thread, we can just modify it without a lock.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::newExceptionHandlingCallSiteIndex):
(JSC::CodeBlock::codeOrigins):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::codeOrigin):
* dfg/DFGCodeOriginPool.cpp: Added.
(JSC::DFG::CodeOriginPool::addCodeOrigin):
(JSC::DFG::CodeOriginPool::addUniqueCallSiteIndex):
(JSC::DFG::CodeOriginPool::lastCallSite const):
(JSC::DFG::CodeOriginPool::addDisposableCallSiteIndex):
(JSC::DFG::CodeOriginPool::removeDisposableCallSiteIndex):
(JSC::DFG::CodeOriginPool::shrinkToFit):
* dfg/DFGCodeOriginPool.h: Added.
(JSC::DFG::CodeOriginPool::create):
(JSC::DFG::CodeOriginPool::get):
(JSC::DFG::CodeOriginPool::size const):
* dfg/DFGCommonData.cpp:
(JSC::DFG::CommonData::shrinkToFit):
(JSC::DFG::CommonData::addCodeOrigin): Deleted.
(JSC::DFG::CommonData::addUniqueCallSiteIndex): Deleted.
(JSC::DFG::CommonData::lastCallSite const): Deleted.
(JSC::DFG::CommonData::addDisposableCallSiteIndex): Deleted.
(JSC::DFG::CommonData::removeDisposableCallSiteIndex): Deleted.
* dfg/DFGCommonData.h:
(JSC::DFG::CommonData::CommonData):
* dfg/DFGJITCompiler.cpp:
(JSC::DFG::JITCompiler::exceptionCheck):
* dfg/DFGJITCompiler.h:
(JSC::DFG::JITCompiler::addCallSite):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compilePutById):
(JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
(JSC::FTL::DFG::LowerDFGToB3::compileDelBy):
(JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstruct):
(JSC::FTL::DFG::LowerDFGToB3::compileDirectCallOrConstruct):
(JSC::FTL::DFG::LowerDFGToB3::compileTailCall):
(JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargsSpread):
(JSC::FTL::DFG::LowerDFGToB3::compileCallOrConstructVarargs):
(JSC::FTL::DFG::LowerDFGToB3::compileCallEval):
(JSC::FTL::DFG::LowerDFGToB3::compileInById):
(JSC::FTL::DFG::LowerDFGToB3::compileInstanceOf):
(JSC::FTL::DFG::LowerDFGToB3::compileLogShadowChickenTail):
(JSC::FTL::DFG::LowerDFGToB3::getById):
(JSC::FTL::DFG::LowerDFGToB3::getByIdWithThis):
(JSC::FTL::DFG::LowerDFGToB3::lazySlowPath):
(JSC::FTL::DFG::LowerDFGToB3::callPreflight):
* ftl/FTLSlowPathCall.cpp:
(JSC::FTL::callSiteIndexForCodeOrigin):
* jit/GCAwareJITStubRoutine.cpp:
(JSC::GCAwareJITStubRoutineWithExceptionHandler::GCAwareJITStubRoutineWithExceptionHandler):
(JSC::GCAwareJITStubRoutineWithExceptionHandler::~GCAwareJITStubRoutineWithExceptionHandler):
(JSC::GCAwareJITStubRoutineWithExceptionHandler::aboutToDie):
(JSC::GCAwareJITStubRoutineWithExceptionHandler::observeZeroRefCount):
* jit/GCAwareJITStubRoutine.h:
2020-06-11 Alexey Shvayka <shvaikalesh@gmail.com>
RegExp.prototype getters should throw on cross-realm access
https://bugs.webkit.org/show_bug.cgi?id=213075
Reviewed by Saam Barati.
This patch makes RegExp.prototype getters throw TypeError when called on
RegExp.prototype object from another realm, aligning JSC with V8 and SpiderMonkey.
The spec [1] allows same-realm access to avoid breaking the web, while makes
RegExp.prototype an ordinary object (rather than RegExp instance) where possible.
[1]: https://tc39.es/ecma262/#sec-get-regexp.prototype.global (step 3.a)
* runtime/RegExpPrototype.cpp:
(JSC::regExpProtoGetterGlobal):
(JSC::regExpProtoGetterIgnoreCase):
(JSC::regExpProtoGetterMultiline):
(JSC::regExpProtoGetterDotAll):
(JSC::regExpProtoGetterSticky):
(JSC::regExpProtoGetterUnicode):
(JSC::regExpProtoGetterSource):
2020-06-11 Paulo Matos <pmatos@igalia.com>
Add missing include to JSONObject.cpp - non-unified build
https://bugs.webkit.org/show_bug.cgi?id=213073
Reviewed by Adrian Perez de Castro.
* runtime/JSONObject.cpp:
2020-06-10 Ross Kirsling <ross.kirsling@sony.com>
REGRESSION(r260697): [Intl] "missing script" locales like zh-TW are no longer mapped
https://bugs.webkit.org/show_bug.cgi?id=213007
Reviewed by Darin Adler.
addMissingScriptLocales was removed from IntlObject when changing our locale resolution to depend more directly
on ICU, but apparently even latest ICU won't perform this legacy "region implies script" mapping for us.
ICU 65+ does have uloc_openAvailableByType which will do the trick, so perhaps we should use this in the future,
but it still doesn't seem to help us with Collator, which has its own separate set of "available locales".
The exact set of locales which should be mapped is currently under discussion here:
https://github.com/tc39/ecma402/issues/159
But the crux seems to be that we should ensure we have an xx-ZZ alias for all available xx-Yyyy-ZZ locales.
* runtime/IntlObject.cpp:
(JSC::addScriptlessLocaleIfNeeded):
(JSC::intlAvailableLocales):
(JSC::intlCollatorAvailableLocales):
2020-06-10 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] JSCallbackObject::deleteProperty should redirect to Parent::deletePropertyByIndex if propertyName is index
https://bugs.webkit.org/show_bug.cgi?id=213041
<rdar://problem/64204300>
Reviewed by Darin Adler.
We have an infinite recursion here.
-> JSCallbackObject::deletePropertyByIndex
-> JSCell::deleteProperty
-> JSCallbackObject::deleteProperty
-> JSObject::deleteProperty
-> JSCallbackObject::deletePropertyByIndex
When propertyName in JSCallbackObject::deleteProperty is an index, we should go to JSObject::deletePropertyByIndex instead of JSObject::deleteProperty.
* API/JSCallbackObjectFunctions.h:
(JSC::JSCallbackObject<Parent>::deleteProperty):
2020-06-09 Mark Lam <mark.lam@apple.com>
Stringifier::appendStringifiedValue() should not assume it is always safe to recurse.
https://bugs.webkit.org/show_bug.cgi?id=213006
<rdar://problem/64154840>
Reviewed by Keith Miller.
In r262727, I suggested that Alexey Shvayka add an assertion in
Stringifier::appendStringifiedValue() to assert that it is safe to recurse because
we don't expect it to recurse into itself. Turns out this is a bad idea because
a client may be doing the recursing before calling Stringifier::appendStringifiedValue().
As a result, Stringifier::appendStringifiedValue() ends up being executed with
the stack pointer already in the reserved zone. This is legal, and is what the
reserved zone is intended for as long as we don't recurse from here. However,
this also means that asserting vm.isSafeToRecurseSoft() here will surely fail
because we are already in the reserved zone area. The fix is simply to remove
this faulty assertion.
* runtime/JSONObject.cpp:
(JSC::Stringifier::appendStringifiedValue):
2020-06-09 Mark Lam <mark.lam@apple.com>
Disambiguate the OverridesGetPropertyNames structure flag
https://bugs.webkit.org/show_bug.cgi?id=212909
<rdar://problem/63823557>
Reviewed by Saam Barati.
Previously, the OverridesGetPropertyNames structure flag could mean 2 different
things:
1. the getPropertyNames() method is overridden, or
2. any of the forms of getPropertyName() is overridden:
getPropertyName, getOwnPropertyNames, getOwnNonIndexPropertyNames
Some parts of the code expects one definition while other parts expect the other.
This patch disambiguates between the 2 by introducing OverridesAnyFormOfGetPropertyNames
for definition (2). OverridesGetPropertyNames now only means definition (1).
Note: we could have implemented overridesGetPropertyNames() by doing a comparison
of the getPropertyNames pointer in the MethodTable. This is a little slower than
checking a TypeInfo flag, but probably doesn't matter a lot in the code paths
where overridesGetPropertyNames() is called. However, we have bits in TypeInfo
left. So, we'll might as well use it.
This ambiguity resulted in JSObject::getPropertyNames() recursing infinitely
when it didn't think it could recurse. This is demonstrated in
JSTests/stress/unexpected-stack-overflow-below-JSObject-getPropertyNames.js as
follows:
1. The test case invokes JSObject::getPropertyNames on a JSArray.
2. In the while loop at the bottom of JSObject::getPropertynames(), we check
`if (prototype->structure(vm)->typeInfo().overridesGetPropertyNames()) {`.
3. The test overrides proto as follows:
`arg0.__proto__ = arr1` where both arg0 and arr1 are JArrays.
4. In the old code, JSArray sets OverridesGetPropertyNames but does not override
getPropertyNames(). It actually meant to set OverridesAnyFormOfGetPropertyNames
(after we disambiguated it) because JSArray overrides getOwnNonIndexPropertyNames().
5. When we get to the check at (2), we ask if the prototype overridesGetPropertyNames().
Since JSArray sets OverridesGetPropertyNames, the answer is yes / true.
JSObject::getPropertynames() then proceeds to invoke
`prototype->methodTable(vm)->getPropertyNames(prototype, globalObject, propertyNames, mode);`
But because JSArray does not actually overrides getPropertyNames(), we're
actually invoking JSObject::getPropertyNames() here. Viola! Infinite loop.
With this patch, JSArray is disambiguated to set OverridesAnyFormOfGetPropertyNames
instead of OverridesGetPropertyNames, and this infinite loop no longer exists.
This patch also made the following changes:
1. Templatized TypeInfo::isSetOnFlags1() and TypeInfo::isSetOnFlags2() so that
we can used static_asserts instead of a debug ASSERT to verify the integrity of
the flag we're checking against.
2. Added a Structure::validateFlags() called from the Structure constructor.
validateFlags() will verify the following:
a. OverridesGetOwnPropertySlot must be set in the flags if getOwnPropertySlot
is overridden in the MethodTable.
b. InterceptsGetOwnPropertySlotByIndexEvenWhenLengthIsNotZero must be set in
the flags if getOwnPropertySlotByIndex is overridden in the MethodTable.
c. HasPutPropertySecurityCheck must be set in the flags if doPutPropertySecurityCheck
is overridden in the MethodTable.
d. OverridesGetPropertyNames must be set in the flags if getPropertyNames
is overridden in the MethodTable.
e. OverridesAnyFormOfGetPropertyNames must be set in the flags if any of
getPropertyNames, getOwnPropertyNames, or getOwnNonIndexPropertyNames are
overridden in the MethodTable.
An alternate solution would be to automatically set these flags if we detect
their corresponding methods are overridden. However, this alternate solution
requires this laundry list to be checked every time a structure is constructed.
The current implementation of having the required flags already pre-determined
as a constant is more efficient in terms of performance and code space.
Also, it only takes one instantiation of the structure to verify that the flags
are valid. Since we only write JSCell / JSObject classes when we need them
and we always write tests to exercise new code (especially such classes), we're
guaranteed the flags validation will be exercised.
3. Made JSObject::getOwnPropertySlot() and JSObject::doPutPropertySecurityCheck()
not inlined when ASSERT_ENABLED. This is needed in order for Structure::validateFlags()
to do its checks using function pointer comparisons. Otherwise, the inline
functions can result in multiple instantiations of these functions. For
example, WebCore can get its own copy of JSObject::getOwnPropertySlot() and
the comparisons will think the function is overridden even when it's not.
4. Structure::validateFlags() found the following problems which are now fixed:
GetterSetter was not using its StructureFlags. As a result, it was missing the
OverridesGetOwnPropertySlot flag.
JSDataView did not define its StructureFlags. It was missing the
OverridesGetOwnPropertySlot and OverridesAnyFormOfGetPropertyNames flags.
5. Changed a TypeInfo constructor to not have a default argument for the flags value.
Also grepped for all uses of this constructor to make sure that it is passed
the StructureFlags field. This exercise found the following issue:
JSAPIValueWrapper was not using its StructureFlags when creating its structure.
Previously, it was just ignoring the StructureIsImmortal flag in StructureFlags.
6. Hardened the assertions for hasReadOnlyOrGetterSetterPropertiesExcludingProto()
and hasGetterSetterProperties() in the Structure constructor.
Previously, if the flag is set, it verifies that the ClassInfo has the
appropriate data expected by the flag. However, it does not assert the reverse
i.e. that if the ClassInfo data exists, then the flag must also be set.
The new assertions now checks both.
Moved the overridesGetCallData() assertion into Structure::validateFlags()
because it concerns the OverridesGetCallData flag. This assertion has also
ben hardened.
* API/JSAPIValueWrapper.h:
* API/JSCallbackObject.h:
* debugger/DebuggerScope.h:
* inspector/JSInjectedScriptHostPrototype.h:
* inspector/JSJavaScriptCallFramePrototype.h:
* runtime/ClonedArguments.h:
* runtime/ErrorInstance.h:
* runtime/GenericArguments.h:
* runtime/GetterSetter.h:
* runtime/JSArray.h:
* runtime/JSDataView.h:
* runtime/JSFunction.h:
* runtime/JSGenericTypedArrayView.h:
* runtime/JSGlobalObject.h:
* runtime/JSLexicalEnvironment.h:
* runtime/JSModuleEnvironment.h:
* runtime/JSModuleNamespaceObject.h:
* runtime/JSObject.cpp:
(JSC::JSObject::doPutPropertySecurityCheck):
(JSC::JSObject::getOwnPropertySlot):
* runtime/JSObject.h:
(JSC::JSObject::getOwnPropertySlotImpl):
(JSC::JSObject::getOwnPropertySlot):
* runtime/JSProxy.h:
* runtime/JSString.h:
* runtime/JSSymbolTableObject.h:
* runtime/JSTypeInfo.h:
(JSC::TypeInfo::TypeInfo):
(JSC::TypeInfo::masqueradesAsUndefined const):
(JSC::TypeInfo::implementsHasInstance const):
(JSC::TypeInfo::implementsDefaultHasInstance const):
(JSC::TypeInfo::overridesGetCallData const):
(JSC::TypeInfo::overridesToThis const):
(JSC::TypeInfo::structureIsImmortal const):
(JSC::TypeInfo::overridesGetPropertyNames const):
(JSC::TypeInfo::overridesAnyFormOfGetPropertyNames const):
(JSC::TypeInfo::prohibitsPropertyCaching const):
(JSC::TypeInfo::getOwnPropertySlotIsImpure const):
(JSC::TypeInfo::getOwnPropertySlotIsImpureForPropertyAbsence const):
(JSC::TypeInfo::hasPutPropertySecurityCheck const):
(JSC::TypeInfo::newImpurePropertyFiresWatchpoints const):
(JSC::TypeInfo::isImmutablePrototypeExoticObject const):
(JSC::TypeInfo::interceptsGetOwnPropertySlotByIndexEvenWhenLengthIsNotZero const):
(JSC::TypeInfo::isSetOnFlags1 const):
(JSC::TypeInfo::isSetOnFlags2 const):
* runtime/ObjectConstructor.cpp:
(JSC::objectConstructorAssign):
* runtime/ProxyObject.h:
* runtime/RegExpObject.h:
* runtime/StringObject.h:
* runtime/Structure.cpp:
(JSC::Structure::validateFlags):
(JSC::Structure::Structure):
* runtime/Structure.h:
* runtime/StructureInlines.h:
(JSC::Structure::canCacheOwnKeys const):
* tools/JSDollarVM.cpp:
2020-06-09 Jonathan Bedard <jbedard@apple.com>
JavaScriptCore: Support tvOS and watchOS builds with the public SDK
https://bugs.webkit.org/show_bug.cgi?id=212788
<rdar://problem/64000087>
Reviewed by Tim Horton.
* Configurations/Base.xcconfig: Link to tvOS and watchOS framework stubs.
* Configurations/JavaScriptCore.xcconfig: Use iOS flags for all embedded platforms.
2020-06-09 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Shrink __DATA,(__data,__bss,__common) more
https://bugs.webkit.org/show_bug.cgi?id=212863
Reviewed by Sam Weinig.
1. Use `unsigned` instead of `size_t` in GC size-class array. We know that this number never exceeds largeCutoff,
which must be much maller than UINT32_MAX.
2. Add missing const to various variables to put them DATA,__const instead of DATA,__data etc.
* heap/MarkedSpace.cpp:
(JSC::MarkedSpace::initializeSizeClassForStepSize):
* heap/MarkedSpace.h:
* heap/VisitRaceKey.cpp:
* heap/VisitRaceKey.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
* inspector/agents/InspectorDebuggerAgent.h:
* runtime/PropertyDescriptor.cpp:
* runtime/PropertyDescriptor.h:
2020-06-08 Keith Miller <keith_miller@apple.com>
Removed unneeded POINTER_WIDTH macro from b3
https://bugs.webkit.org/show_bug.cgi?id=212927
Reviewed by Yusuke Suzuki.
C++20 has real constexpr functions so we don't need the
POINTER_WIDTH macro anymore.
* b3/B3Width.h:
(JSC::B3::pointerWidth):
* b3/air/opcode_generator.rb:
2020-06-08 Alexey Shvayka <shvaikalesh@gmail.com>
JSON.stringify should throw stack overflow error
https://bugs.webkit.org/show_bug.cgi?id=143511
Reviewed by Ross Kirsling and Mark Lam.
This change adds m_holderStack.size() check, reusing the limit of JSON.parse,
and throws StackOverflowError if exceeded, aligning JSC with V8 and SpiderMonkey.
Even with all the cyclic structure checks in place, excess is possible due to
very deeply nested object, user-provided "toJSON" method or functional replacer.
While Stringifier::appendStringifiedValue() and Holder::appendNextProperty()
mutually call each other, recursion is avoided by !holderStackWasEmpty check and
do/while loop at the end of appendStringifiedValue(), as well as cyclic structure
check as per spec [1].
[1]: https://tc39.es/ecma262/#sec-serializejsonobject (step 1)
* runtime/JSONObject.cpp:
(JSC::Stringifier::appendStringifiedValue):
(JSC::Walker::walk):
2020-06-08 Jonathan Bedard <jbedard@apple.com>
JavaScriptCore: Fix PLATFORM(TVOS) macro
https://bugs.webkit.org/show_bug.cgi?id=212900
<rdar://problem/64118879>
Unreviewed build fix.
* tools/JSDollarVM.cpp:
(JSC::functionIsMemoryLimited): PLATFORM(TVOS) should be PLATFORM(APPLETV).
2020-06-07 Philippe Normand <pnormand@igalia.com>
Remove ENABLE_VIDEO_TRACK ifdef guards
https://bugs.webkit.org/show_bug.cgi?id=212568
Reviewed by Youenn Fablet.
* Configurations/FeatureDefines.xcconfig: Remove ENABLE_VIDEO_TRACK, which is now enabled by
default under the ENABLE_VIDEO guard.
2020-06-07 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Checksum for generated files should be emitted at the end of the files
https://bugs.webkit.org/show_bug.cgi?id=212875
Reviewed by Mark Lam.
If the offlineasm file generation is interrupted in the middle of the generation, it already emitted checksum.
So next file generation can accept this broken file as a result of offlineasm and skip file generation.
We should emit checksum at the end of files. For now, this patch takes a quick way: just iterating lines, getting
a last line and use it for checksum comparison.
* generator/GeneratedFile.rb:
* offlineasm/asm.rb:
2020-06-06 Mark Lam <mark.lam@apple.com>
Make CodeBlockHash robust against unreasonably long source code.
https://bugs.webkit.org/show_bug.cgi?id=212847
<rdar://problem/64024279>
Reviewed by Saam Barati.
This patch adds a heuristic to avoid trying to compute the CodeBlockHash on
unreasonably long source code strings. This is done by first applying a length
check and, if needed, computing the hash with an alternate method.
This is OK to do because:
1. CodeBlockHash is not a critical hash.
2. In practice, reasonable source code are not that long.
3. And if they are that long, then we are still diversifying the hash on their
length. But if they do collide, it's OK.
The only invariant here is that we should always produce the same hash for the
same source string. Since the algorithm is deterministic, this invariant is not
violated.
* bytecode/CodeBlockHash.cpp:
(JSC::CodeBlockHash::CodeBlockHash):
2020-06-06 Devin Rousso <drousso@apple.com>
Web Inspector: unify the naming scheme for agents used by instrumentation
https://bugs.webkit.org/show_bug.cgi?id=212859
Reviewed by Timothy Hatcher.
Inspector agents fall into one of three categories:
- "persistent" when Web Inspector is connected
- "enabled" when that agent is `enable`d, such as if the corresponding tab is visible
- "tracking" when that agent is part of a timeline recording.
The only exception to this is the Console agent, as that exists regardless of whether Web
Inspector is connected as it needs to preserve messages logged before Web Inspector connects.
Also remove the "Inspector" prefix from getter/setter methods as it adds confusion if that
agent also has subclasses (e.g. `InspectorRuntimeAgent` and `PageRuntimeAgent`).
* inspector/JSGlobalObjectConsoleClient.h:
* inspector/JSGlobalObjectInspectorController.cpp:
* inspector/agents/InspectorConsoleAgent.h:
2020-06-05 Michael Saboff <msaboff@apple.com>
Make FAST_JIT_PERMISSIONS check in LinkBuffer::copyCompactAndLinkCode a runtime check
https://bugs.webkit.org/show_bug.cgi?id=212825
Reviewed by Saam Barati.
Added useFastJITPermissions() for runtime checks of FAST_JIT_PERMISSIONS
including the cases where it is conditional on OS settings. This is now
used in a few places to declutter the code.
When using the fast JIT permissions path, the JIT memory is the direct output
of the linking. Modified BranchCompactionLinkBuffer to hold a pointer to that
output "buffer" or a temporarily allocated buffer depending on if fast JIT
permissions are enabled.
Broke out the "verify hash" conditionally compiled code with a file local
ENABLE_VERIFY_JIT_HASH macro for readability.
* assembler/LinkBuffer.cpp:
(JSC::BranchCompactionLinkBuffer::BranchCompactionLinkBuffer):
(JSC::BranchCompactionLinkBuffer::~BranchCompactionLinkBuffer):
Changed this to use a provided buffer or a malloc'ed buffer. When using
a malloc'ed buffer, we put it in a thread local cache.
(JSC::LinkBuffer::copyCompactAndLinkCode):
* jit/ExecutableAllocator.h:
(JSC::useFastJITPermissions):
(JSC::performJITMemcpy):
2020-06-05 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Put dfgOpNames in __DATA,__const section instead of __DATA,__data
https://bugs.webkit.org/show_bug.cgi?id=212840
Reviewed by Saam Barati.
dfgOpNames array itself is not const annotated, and the compiler makes it __DATA,__data instead of __DATA,__const.
We should annotate it with const to ensure that this is compiled into __DATA,__const. We also remove unused CallFrame::describeFrame
since it allocates some bss memory, while we have more sophisticated mechanism (VMInspector) for this functionality and this function
is no longer used.
* dfg/DFGDoesGCCheck.cpp:
(JSC::DFG::DoesGCCheck::verifyCanGC):
* dfg/DFGGraph.cpp:
* dfg/DFGGraph.h:
* interpreter/CallFrame.cpp:
(JSC::CallFrame::describeFrame): Deleted.
* interpreter/CallFrame.h:
2020-06-05 Tadeu Zagallo <tzagallo@apple.com>
REGRESSION(r262523): Fix testb3
https://bugs.webkit.org/show_bug.cgi?id=212791
Reviewed by Mark Lam.
* b3/testb3_1.cpp:
(run):
(main):
2020-06-05 Paulo Matos <pmatos@igalia.com>
Add missing ECMAMode header to fix NonUnified Build
https://bugs.webkit.org/show_bug.cgi?id=212838
Reviewed by Darin Adler.
* bytecode/PutByValFlags.h:
2020-06-05 Saam Barati <sbarati@apple.com>
Audit safe to execute
https://bugs.webkit.org/show_bug.cgi?id=207075
<rdar://problem/59085094>
Reviewed by Yusuke Suzuki.
This audit found one interesting case for DOMJIT nodes. We emit safety checks
for CallDOM/CallDOMGetter inside fixup phase and the bytecode parser. When
determining if these nodes are safe to execute, we need to also ensure that
these checks hold.
I've also added a helper to JSDollarVM to ensure that this patch doesn't break
LICM of DOMJIT.
This patch also moves some nodes we will never hoist to return false.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleDOMJITGetter):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::attemptToMakeCallDOM):
* dfg/DFGNode.h:
(JSC::DFG::Node::classInfo):
(JSC::DFG::Node::requiredDOMJITClassInfo):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* tools/JSDollarVM.cpp:
(JSC::functionCreateDOMJITGetterNoEffectsObject):
(JSC::JSDollarVM::finishCreation):
2020-06-05 Devin Rousso <drousso@apple.com>
Logical Assignment: perform NamedEvaluation of anonymous functions
https://bugs.webkit.org/show_bug.cgi?id=212679
Reviewed by Ross Kirsling.
* parser/ASTBuilder.h:
(JSC::ASTBuilder::makeAssignNode):
2020-06-05 Yusuke Suzuki <ysuzuki@apple.com>
DOM constructor should only accept Ref<> / ExceptionOr<Ref<>> for creation to ensure toJSNewlyCreated is always returning object
https://bugs.webkit.org/show_bug.cgi?id=212767
Reviewed by Darin Adler.
* runtime/JSObject.h:
(JSC::asObject):
2020-06-05 Andy Estes <aestes@apple.com>
[Apple Pay] Remove conditionals for ENABLE_APPLE_PAY_SESSION_V(3|4)
https://bugs.webkit.org/show_bug.cgi?id=212541
<rdar://problem/63781452>
Reviewed by Darin Adler.
APPLE_PAY_SESSION_V(3|4) is now enabled whenever APPLE_PAY itself is enabled.
* Configurations/FeatureDefines.xcconfig:
2020-06-05 Caitlin Potter <caitp@igalia.com>
[JSC] Add support for private class fields
https://bugs.webkit.org/show_bug.cgi?id=206431
Reviewed by Saam Barati.
Expanding upon the earlier public class fields patch, we implement the remaining (and
significant parts) of the instance fields (https://tc39.es/proposal-class-fields/).
There are a variety of key changes here:
- Parser now understands the concept of private names (Token PRIVATENAME).
- 1 new opcode (op_get_private_name), one changed opcode (op_put_by_val_direct).
- A method for creating Symbol objects with a null PrivateSymbolImpl is exposed as a
LinkTimeConstant (@createPrivateSymbol).
- Null Private Symbols are stored by name (not a valid identifier) in a JSScope, and
are loaded from the outer scope whenever they are used by the modified opcodes.
The changes to op_put_by_val_direct include a new bytecode operand (PutByValFlags) which are
used to distinguish between overwriting or defining a new private field. Specifically, when it
comes to private field accesses, it's necessary to throw an exception when accessing a field
which does not exist, or when attempting to define a private field which has already been
defined.
During the evaluation of a class expression, before the class element list is evaluated (in case
any computed property names expressions refer to a new private field), a new PrivateSymbol is
created for each individual private field name, and stored in the class lexical scope.
Private field names are loaded from scope before their use. This prevents multiple evaluations
of the same class source from accessing each other's private fields, because the values of the
symbols loaded from the class scope would be distinct. This is required by the proposal text,
and is the key reason why we use ByVal lookups rather than ById lookups.
To illustrate, typical private field access will look like:
<Field Reads>
resolve_scope <scope=>, <currentScope>, "#x", GlobalProperty, 0
get_from_scope <symbol=>, <scope>, "#x", 1050624<DoNotThrowIfNotFound|GlobalProperty|NotInitialization>, 0, 0
get_private_name <value=>, <receiver --- probably 'this'>, <symbol>
<Field Writes>
resolve_scope <scope=>, <currentScope>, "#x", GlobalProperty, 0
get_from_scope <symbol=>, <scope>, "#x", 1050624<DoNotThrowIfNotFound|GlobalProperty|NotInitialization>, 0, 0
put_by_val_direct <receiver, probably 'this'>, <symbol>, <value>, <PutByValPrivateName>
<Field Definition>
resolve_scope <scope=>, <currentScope>, "#x", GlobalProperty, 0
get_from_scope <symbol=>, <scope>, "#x", 1050624<DoNotThrowIfNotFound|GlobalProperty|NotInitialization>, 0, 0
put_by_val_direct <receiver, probably 'this'>, <symbol>, <value>, <PutByValPrivateName|PutByValThrowIfExists>
The feature is currently hidden behind the feature flag JSC::Options::usePrivateClassFields.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* builtins/BuiltinNames.h:
* bytecode/BytecodeList.rb:
* bytecode/BytecodeUseDef.cpp:
(JSC::computeUsesForBytecodeIndexImpl):
(JSC::computeDefsForBytecodeIndexImpl):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finalizeLLIntInlineCaches):
* bytecode/Fits.h:
* bytecode/LinkTimeConstant.h:
* bytecode/PutByValFlags.cpp: Copied from Source/JavaScriptCore/bytecode/PutKind.h.
(WTF::printInternal):
* bytecode/PutByValFlags.h: Added.
(JSC::PutByValFlags::create):
(JSC::PutByValFlags::createDirect):
(JSC::PutByValFlags::createDefinePrivateField):
(JSC::PutByValFlags::createPutPrivateField):
(JSC::PutByValFlags::isDirect const):
(JSC::PutByValFlags::ecmaMode const):
(JSC::PutByValFlags::privateFieldAccessKind const):
(JSC::PutByValFlags::isPrivateFieldAccess const):
(JSC::PutByValFlags::isPrivateFieldPut const):
(JSC::PutByValFlags::isPrivateFieldAdd const):
(JSC::PutByValFlags::PutByValFlags):
* bytecode/PutKind.h:
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::generateUnlinkedFunctionCodeBlock):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::instantiateLexicalVariables):
(JSC::BytecodeGenerator::emitDirectGetByVal):
(JSC::BytecodeGenerator::emitDirectPutByVal):
(JSC::BytecodeGenerator::emitDefinePrivateField):
(JSC::BytecodeGenerator::emitPrivateFieldPut):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::PropertyListNode::emitDeclarePrivateFieldNames):
(JSC::PropertyListNode::emitBytecode):
(JSC::PropertyListNode::emitPutConstantProperty):
(JSC::DotAccessorNode::emitBytecode):
(JSC::BaseDotNode::emitGetPropertyValue):
(JSC::BaseDotNode::emitPutProperty):
(JSC::FunctionCallDotNode::emitBytecode):
(JSC::PostfixNode::emitDot):
(JSC::PrefixNode::emitDot):
(JSC::AssignDotNode::emitBytecode):
(JSC::ReadModifyDotNode::emitBytecode):
(JSC::DefineFieldNode::emitBytecode):
(JSC::ClassExprNode::emitBytecode):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ecmaMode):
(JSC::DFG::ecmaMode<OpPutByValDirect>):
(JSC::DFG::ByteCodeParser::handlePutByVal):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::cachedPutById):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compilePutById):
* generator/DSL.rb:
* jit/ICStats.h:
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
* jit/JIT.h:
* jit/JITInlineCacheGenerator.cpp:
(JSC::JITPutByIdGenerator::JITPutByIdGenerator):
(JSC::JITPutByIdGenerator::slowPathFunction):
* jit/JITInlineCacheGenerator.h:
(JSC::JITPutByIdGenerator::JITPutByIdGenerator):
* jit/JITInlines.h:
(JSC::JIT::ecmaMode):
(JSC::JIT::ecmaMode<OpPutById>):
(JSC::JIT::ecmaMode<OpPutByValDirect>):
(JSC::JIT::privateFieldAccessKind):
(JSC::JIT::privateFieldAccessKind<OpPutByValDirect>):
* jit/JITOperations.cpp:
(JSC::putPrivateField):
(JSC::definePrivateField):
* jit/JITOperations.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitPutByValWithCachedId):
(JSC::JIT::emitSlow_op_put_by_val):
(JSC::JIT::emit_op_put_by_id):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emitSlow_op_put_by_val):
(JSC::JIT::emit_op_put_by_id):
* jit/Repatch.cpp:
(JSC::appropriateGenericPutByIdFunction):
(JSC::appropriateOptimizingPutByIdFunction):
(JSC::tryCachePutByID):
* llint/LLIntOffsetsExtractor.cpp:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* llint/LLIntSlowPaths.h:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* parser/ASTBuilder.h:
(JSC::ASTBuilder::createDotAccess):
(JSC::ASTBuilder::isPrivateLocation):
(JSC::ASTBuilder::makeFunctionCallNode):
(JSC::ASTBuilder::makeAssignNode):
* parser/Lexer.cpp:
(JSC::Lexer<LChar>::parseIdentifier):
(JSC::Lexer<UChar>::parseIdentifier):
(JSC::Lexer<CharacterType>::parseIdentifierSlowCase):
(JSC::Lexer<T>::lexWithoutClearingLineTerminator):
* parser/NodeConstructors.h:
(JSC::BaseDotNode::BaseDotNode):
(JSC::DotAccessorNode::DotAccessorNode):
(JSC::FunctionCallDotNode::FunctionCallDotNode):
(JSC::CallFunctionCallDotNode::CallFunctionCallDotNode):
(JSC::ApplyFunctionCallDotNode::ApplyFunctionCallDotNode):
(JSC::HasOwnPropertyFunctionCallDotNode::HasOwnPropertyFunctionCallDotNode):
(JSC::AssignDotNode::AssignDotNode):
(JSC::ReadModifyDotNode::ReadModifyDotNode):
* parser/Nodes.cpp:
(JSC::PropertyListNode::shouldCreateLexicalScopeForClass):
* parser/Nodes.h:
(JSC::ExpressionNode::isPrivateLocation const):
(JSC::BaseDotNode::base const):
(JSC::BaseDotNode::identifier const):
(JSC::BaseDotNode::type const):
(JSC::BaseDotNode::isPrivateField const):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseVariableDeclarationList):
(JSC::Parser<LexerType>::parseDestructuringPattern):
(JSC::Parser<LexerType>::parseClass):
(JSC::Parser<LexerType>::parseInstanceFieldInitializerSourceElements):
(JSC::Parser<LexerType>::usePrivateName):
(JSC::Parser<LexerType>::parseMemberExpression):
(JSC::Parser<LexerType>::parseUnaryExpression):
(JSC::Parser<LexerType>::printUnexpectedTokenText):
* parser/Parser.h:
(JSC::Scope::isPrivateNameScope const):
(JSC::Scope::setIsPrivateNameScope):
(JSC::Scope::hasPrivateName):
(JSC::Scope::copyUndeclaredPrivateNamesTo):
(JSC::Scope::hasUsedButUndeclaredPrivateNames const):
(JSC::Scope::usePrivateName):
(JSC::Scope::declarePrivateName):
(JSC::Parser::findPrivateNameScope):
(JSC::Parser::privateNameScope):
(JSC::Parser::copyUndeclaredPrivateNamesToOuterScope):
(JSC::Parser::matchAndUpdate):
(JSC::Parser<LexerType>::parse):
(JSC::parse):
* parser/ParserTokens.h:
* parser/SyntaxChecker.h:
(JSC::SyntaxChecker::createDotAccess):
(JSC::SyntaxChecker::operatorStackPop):
* parser/VariableEnvironment.cpp:
(JSC::VariableEnvironment::operator=):
(JSC::VariableEnvironment::swap):
(JSC::CompactVariableEnvironment::CompactVariableEnvironment):
* parser/VariableEnvironment.h:
(JSC::VariableEnvironmentEntry::isPrivateName const):
(JSC::VariableEnvironmentEntry::setIsPrivateName):
(JSC::PrivateNameEntry::PrivateNameEntry):
(JSC::PrivateNameEntry::isUsed const):
(JSC::PrivateNameEntry::isDeclared const):
(JSC::PrivateNameEntry::setIsUsed):
(JSC::PrivateNameEntry::setIsDeclared):
(JSC::PrivateNameEntry::bits const):
(JSC::PrivateNameEntry::operator== const):
(JSC::VariableEnvironment::VariableEnvironment):
(JSC::VariableEnvironment::size const):
(JSC::VariableEnvironment::mapSize const):
(JSC::VariableEnvironment::declarePrivateName):
(JSC::VariableEnvironment::usePrivateName):
(JSC::VariableEnvironment::privateNames const):
(JSC::VariableEnvironment::privateNamesSize const):
(JSC::VariableEnvironment::hasPrivateName):
(JSC::VariableEnvironment::copyPrivateNamesTo const):
(JSC::VariableEnvironment::copyUndeclaredPrivateNamesTo const):
(JSC::VariableEnvironment::RareData::RareData):
(JSC::VariableEnvironment::getOrAddPrivateName):
* runtime/CachedTypes.cpp:
(JSC::CachedOptional::decodeAsPtr const):
(JSC::CachedVariableEnvironmentRareData::encode):
(JSC::CachedVariableEnvironmentRareData::decode const):
(JSC::CachedVariableEnvironment::encode):
(JSC::CachedVariableEnvironment::decode const):
(JSC::CachedSymbolTableRareData::encode):
(JSC::CachedSymbolTableRareData::decode const):
(JSC::CachedSymbolTable::encode):
(JSC::CachedSymbolTable::decode const):
* runtime/CodeCache.cpp:
(JSC::generateUnlinkedCodeBlockImpl):
* runtime/CommonIdentifiers.cpp:
(JSC::CommonIdentifiers::CommonIdentifiers):
* runtime/CommonIdentifiers.h:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
* runtime/ExceptionHelpers.cpp:
(JSC::createInvalidPrivateNameError):
(JSC::createRedefinedPrivateNameError):
* runtime/ExceptionHelpers.h:
* runtime/JSGlobalObject.cpp:
(JSC::createPrivateSymbol):
(JSC::JSGlobalObject::init):
* runtime/JSObject.h:
* runtime/JSObjectInlines.h:
(JSC::JSObject::getPrivateFieldSlot):
(JSC::JSObject::getPrivateField):
(JSC::JSObject::putPrivateField):
(JSC::JSObject::definePrivateField):
* runtime/JSScope.cpp:
(JSC::JSScope::collectClosureVariablesUnderTDZ):
* runtime/OptionsList.h:
* runtime/SymbolTable.cpp:
(JSC::SymbolTable::cloneScopePart):
* runtime/SymbolTable.h:
2020-06-05 Paulo Matos <pmatos@igalia.com>
Fix includes to fix latest non-unified builds breakages
https://bugs.webkit.org/show_bug.cgi?id=212802
Reviewed by Adrian Perez de Castro.
* dfg/DFGDoesGCCheck.cpp:
* runtime/JSDateMath.h:
2020-06-04 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Report extra memory allocation from PropertyTable
https://bugs.webkit.org/show_bug.cgi?id=212793
Reviewed by Saam Barati.
This patch adds extra memory reporting from PropertyTable to make GC
responsive to the increase of memory in PropertyTable.
* runtime/PropertyMapHashTable.h:
(JSC::PropertyTable::add):
(JSC::PropertyTable::remove):
(JSC::PropertyTable::rehash):
(JSC::PropertyTable::dataSize):
* runtime/PropertyTable.cpp:
(JSC::PropertyTable::finishCreation):
(JSC::PropertyTable::visitChildren):
* runtime/Structure.cpp:
(JSC::Structure::materializePropertyTable):
* runtime/StructureInlines.h:
(JSC::Structure::add):
(JSC::Structure::remove):
2020-06-04 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r262583.
https://bugs.webkit.org/show_bug.cgi?id=212799
Internal source code has the same bug, needs to be landed
after fixing internal source
Reverted changeset:
"DOM constructor should only accept Ref<> / ExceptionOr<Ref<>>
for creation to ensure toJSNewlyCreated is always returning
object"
https://bugs.webkit.org/show_bug.cgi?id=212767
https://trac.webkit.org/changeset/262583
2020-06-04 Michael Saboff <msaboff@apple.com>
Add a Thread Specific Cache for LinkBuffer::CompactAndLinkCode()
https://bugs.webkit.org/show_bug.cgi?id=212765
Reviewed by Saam Barati.
Added a thread local buffer for CPU types that use a second buffer when compacting.
This is very similary to the work done in https://bugs.webkit.org/show_bug.cgi?id=212562.
* assembler/LinkBuffer.cpp:
(JSC::threadSpecificBranchCompactionLinkBuffer):
(JSC::BranchCompactionLinkBuffer::BranchCompactionLinkBuffer):
(JSC::BranchCompactionLinkBuffer::~BranchCompactionLinkBuffer):
(JSC::BranchCompactionLinkBuffer::data):
(JSC::BranchCompactionLinkBuffer::takeBufferIfLarger):
(JSC::BranchCompactionLinkBuffer::size):
(JSC::LinkBuffer::copyCompactAndLinkCode):
2020-06-04 Mark Lam <mark.lam@apple.com>
Add Options::validateDoesGC() for turning DoesGC validation on/off.
https://bugs.webkit.org/show_bug.cgi?id=212773
Reviewed by Saam Barati.
It will default to on if ASSERT_ENABLED because we want testing to be done with
the validation on. When needed, we can turn it off if we need to e.g. to
de-clutter disassembly dumps while debugging.
If Options::validateDoesGC() is false, we turn off JIT code emission for this
check, as well as skip the validation checks. There are still places in C++
code that store to DoesGC::m_value without checking Options::validateDoesGC().
It doesn't hurt to just let these stores proceed, and performance-wise, it's
probably cheaper to just do the store unconditionally than to gate it on a load of
Options::validateDoesGC() first.
Also made it explicit that the check on validateDFGDoesGC is a constexpr check.
* dfg/DFGDoesGCCheck.cpp:
(JSC::DFG::DoesGCCheck::verifyCanGC):
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::compileExit):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
* runtime/OptionsList.h:
2020-06-04 Ross Kirsling <ross.kirsling@sony.com>
Intl classes should have meaningful @@toStringTag values
https://bugs.webkit.org/show_bug.cgi?id=212769
Reviewed by Yusuke Suzuki.
Implementation of https://github.com/tc39/ecma402/pull/430, which achieved consensus this week.
This ensures we get "[object Intl.Collator]" (etc.) instead "[object Object]" for older Intl classes.
* runtime/IntlCollatorPrototype.cpp:
* runtime/IntlDateTimeFormatPrototype.cpp:
* runtime/IntlNumberFormatPrototype.cpp:
* runtime/IntlPluralRulesPrototype.cpp:
2020-06-04 Alexey Shvayka <shvaikalesh@gmail.com>
GetMethod isn't performed properly on iterators
https://bugs.webkit.org/show_bug.cgi?id=212771
Reviewed by Saam Barati.
Before this change, iterator's "return" and "throw" methods with value of `null` were
considered incorrect rather than missing, causing TypeError to be thrown.
This patch aligns method lookup of iterators with the spec [1], V8, and SpiderMonkey
by utilizing isUndefinedOrNull(), which doesn't special-case [[IsHTMLDDA]] objects [2],
fixing a few Annex B tests.
for/of microbenchmarks are neutral.
[1]: https://tc39.es/ecma262/#sec-getmethod (step 3)
[2]: https://tc39.es/ecma262/#sec-IsHTMLDDA-internal-slot
* builtins/AsyncFromSyncIteratorPrototype.js:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitIteratorGenericClose):
(JSC::BytecodeGenerator::emitGetAsyncIterator):
(JSC::BytecodeGenerator::emitDelegateYield):
* runtime/IteratorOperations.cpp:
(JSC::iteratorClose):
* runtime/JSGenericTypedArrayViewConstructorInlines.h:
(JSC::constructGenericTypedArrayViewWithArguments):
2020-06-04 Mark Lam <mark.lam@apple.com>
Reduce DFGDoesGCCheck to only storing a uint32_t.
https://bugs.webkit.org/show_bug.cgi?id=212734
Reviewed by Saam Barati and Caio Lima.
This patch changes the encoding of DoesGCCheck so that it will fit better in a
uint32_t. This has the following benefits:
1. speed improvement for debug builds because it now takes less instructions
(especially in JITted code) to store to DoesGCCheck::m_value.
2. enables this check for 32-bit platforms as well.
Fun fact: we currently have 373 DFG::NodeTypes. Hence, 9 bits for nodeOp.
The new encoding provides 21 bis for the nodeIndex. This gives us up to 2097152
node indexes. In my experience, I've never seen more than 3 decimal digits for
the nodeIndex so far. If we ever find that we need more than 21 bits of nodeIndex,
we have 2 options to deal with it:
1. We can just ignore the high bits. After all, it is the nodeOp that is the
most interesting piece of data we need to debug doesGC issues.
2. We can make DoesGCCheck use uint64_t for storage. This encoding automatically
scales to 64-bit, while still allowing the more efficient form of storing a
32-bit immediate to be used for the common cases.
This patch also makes ENABLE_DFG_DOES_GC_VALIDATION dependent on ENABLE(DFG_JIT).
DoesGC is only relevant for the DFG and FTL JITs.
* dfg/DFGDoesGCCheck.cpp:
(JSC::DFG::DoesGCCheck::verifyCanGC):
* dfg/DFGDoesGCCheck.h:
(JSC::DFG::DoesGCCheck::encode):
(JSC::DFG::DoesGCCheck::expectDoesGC const):
(JSC::DFG::DoesGCCheck::isSpecial const):
(JSC::DFG::DoesGCCheck::special):
(JSC::DFG::DoesGCCheck::nodeOp):
(JSC::DFG::DoesGCCheck::nodeIndex):
(JSC::DFG::DoesGCCheck::expectDoesGC): Deleted.
(JSC::DFG::DoesGCCheck::isSpecial): Deleted.
(JSC::DFG::DoesGCCheck::specialIndex): Deleted.
(JSC::DFG::DoesGCCheck::bits): Deleted.
* dfg/DFGNodeType.h:
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::compileExit):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
* heap/Heap.h:
2020-06-04 Tim Horton <timothy_horton@apple.com>
Work around broken system version macro
https://bugs.webkit.org/show_bug.cgi?id=212726
Reviewed by Dan Bernstein.
* Configurations/DebugRelease.xcconfig:
2020-06-04 Andy Estes <aestes@apple.com>
[watchOS] Re-enable content filtering in the simulator build
https://bugs.webkit.org/show_bug.cgi?id=212711
<rdar://problem/63938350>
Reviewed by Wenson Hsieh.
* Configurations/FeatureDefines.xcconfig:
2020-06-04 Mark Lam <mark.lam@apple.com>
SpeculativeJIT::compileDateGet()'s slow path does not need an exception check.
https://bugs.webkit.org/show_bug.cgi?id=212645
Reviewed by Yusuke Suzuki.
SpeculativeJIT::compileDateGet() implements a bunch of Date intrinsics which call
into a C++ operation function do their work. However, the call to these operation
functions were done using a slow path generator configured to automatically
emit exception checks after the call. These exception checks are unneeded because
those functions will not throw any exceptions.
This issue was found with JSC stress test runs on a debug build. The doesGC
verifier was failing on the exceptionFuzz/date-format-xparb.js test. The reason
is because doesGC does not expect any these Date intrinsics to throw any exceptions,
but SpeculativeJIT was emitting the unneeded exception checks there. These
exception check sites get turned into throw sites by the exceptionFuzzer, and
they allocate an Error object there. This allocation made the doesGC verifier
not happy.
This patch fixes this issue by changing SpeculativeJIT::compileDateGet() to
pass ExceptionCheckRequirement::CheckNotNeeded to the slow path generator.
The patch also proves that all the operation functions cannot throw any exceptions.
Previously, the operations passes a VM& to the Date functions. The purpose for
doing this is so that the Date functions can work with a few date cache data
structures stored as VM fields.
This patch refactors those VM fields into a VM::DateCache struct, and changed all
those Date functions to take a VM::DateCache& instead of a VM&. Since the Date
functions no longer take a VM&, this proves that they cannot throw because they
would need a VM& to make a ThrowScope in order to throw.
Update: Yusuke pointed out that the lack of a JSGlobalObject* argument is sufficient
to guarantee that the Date functions cannot throw. However, we'll keep this
DateCache refactoring since it provides additional info that the Date functions
only operate on the DateCache fields and nothing else in VM.
Also removed DFG::JITCompile's fastExceptionCheck() which is unused.
* dfg/DFGJITCompiler.h:
(JSC::DFG::JITCompiler::fastExceptionCheck): Deleted.
* dfg/DFGOperations.cpp:
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compileDateGet):
* runtime/DateConstructor.cpp:
(JSC::millisecondsFromComponents):
(JSC::callDate):
* runtime/DateInstance.cpp:
(JSC::DateInstance::calculateGregorianDateTime const):
(JSC::DateInstance::calculateGregorianDateTimeUTC const):
* runtime/DateInstance.h:
* runtime/DatePrototype.cpp:
(JSC::formatLocaleDate):
(JSC::formateDateInstance):
(JSC::dateProtoFuncToISOString):
(JSC::dateProtoFuncGetFullYear):
(JSC::dateProtoFuncGetUTCFullYear):
(JSC::dateProtoFuncGetMonth):
(JSC::dateProtoFuncGetUTCMonth):
(JSC::dateProtoFuncGetDate):
(JSC::dateProtoFuncGetUTCDate):
(JSC::dateProtoFuncGetDay):
(JSC::dateProtoFuncGetUTCDay):
(JSC::dateProtoFuncGetHours):
(JSC::dateProtoFuncGetUTCHours):
(JSC::dateProtoFuncGetMinutes):
(JSC::dateProtoFuncGetUTCMinutes):
(JSC::dateProtoFuncGetSeconds):
(JSC::dateProtoFuncGetUTCSeconds):
(JSC::dateProtoFuncGetTimezoneOffset):
(JSC::setNewValueFromTimeArgs):
(JSC::setNewValueFromDateArgs):
(JSC::dateProtoFuncSetYear):
(JSC::dateProtoFuncGetYear):
* runtime/JSDateMath.cpp:
(JSC::localTimeOffset):
(JSC::gregorianDateTimeToMS):
(JSC::msToGregorianDateTime):
(JSC::parseDate):
* runtime/JSDateMath.h:
* runtime/VM.cpp:
(JSC::VM::resetDateCache):
* runtime/VM.h:
2020-06-04 Paulo Matos <pmatos@igalia.com>
Fix 32bit build broken at r262513
https://bugs.webkit.org/show_bug.cgi?id=212735
Unreviewed Gardening.
Proper fix is being worked out under https://bugs.webkit.org/show_bug.cgi?id=212734
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::compileExit):
2020-06-03 Tadeu Zagallo <tzagallo@apple.com>
Disable B3 hoistLoopInvariantValues by default
https://bugs.webkit.org/show_bug.cgi?id=212511
<rdar://problem/63813245>
Reviewed by Mark Lam.
The hoistLoopInvariantValues optimization in B3 does not calculate the cost of hoisting the candidates.
For example, in the test case provided with the bug, a switch inside a loop can lead to hoisting the body
of several switch cases which would never be executed. Other than leading to worse runtime, this also
increases the pressure in the register allocate, leading to worse compile times (~10x worse in this case).
I have added a FIXME to consider adding cost calculation and re-enabling this pass, but given that we
already have LICM in DFG, it should be ok to disable it for now.
* b3/B3Generate.cpp:
(JSC::B3::generateToAir):
* runtime/OptionsList.h:
2020-06-03 Mark Lam <mark.lam@apple.com>
Gardening: fix broken Windows debug build.
https://bugs.webkit.org/show_bug.cgi?id=212680
Not reviewed.
* dfg/DFGDoesGCCheck.cpp:
(JSC::DFG::DoesGCCheck::verifyCanGC):
* dfg/DFGDoesGCCheck.h:
2020-06-03 Mark Lam <mark.lam@apple.com>
[Re-landing] Enhance DoesGC verification to print more useful info when verification fails.
https://bugs.webkit.org/show_bug.cgi?id=212680
Reviewed by Yusuke Susuki.
When DoesGC verification fails, the first step of debugging it would be to find
out what and which DFG node resulted in the failed verification. In pre-existing
code, all we get is an assertion failure.
This patch makes it so that the verifier will dump useful info. Here's an example:
Error: DoesGC failed @ D@34 DateGetInt32OrNaN in #DtCHMz:[0x1135bd1d0->0x1135bcab0->0x1135e5c80, DFGFunctionCall, 150 (DidTryToEnterInLoop)]
[0] frame 0x7ffee8285660 {
name:
sourceURL:
isInlinedFrame: false
callee: 0x1135f6820
returnPC: 0x50ce61248ae6
callerFrame: 0x7ffee82856f0
rawLocationBits: 5 0x5
codeBlock: 0x1135bd1d0 #DtCHMz:[0x1135bd1d0->0x1135bcab0->0x1135e5c80, DFGFunctionCall, 150 (DidTryToEnterInLoop)]
hasCodeOrigins: true
callSiteIndex: 5 of 13
jitCode: 0x113020200 start 0x50ce61214c60 end 0x50ce61219b00
line: 1
column: 60
EntryFrame: 0x7ffee8285860
}
[1] frame 0x7ffee82856f0 {
name:
sourceURL: date-format-xparb.js
isInlinedFrame: false
callee: 0x1135f65a0
returnPC: 0x50ce61227e99
callerFrame: 0x7ffee8285770
rawLocationBits: 4 0x4
codeBlock: 0x1135bd0a0 #BU6Zcd:[0x1135bd0a0->0x1135bc260->0x1135e5180, DFGFunctionCall, 112 (DidTryToEnterInLoop)]
hasCodeOrigins: true
callSiteIndex: 4 of 12
jitCode: 0x113004000 start 0x50ce61212c60 end 0x50ce61214960
line: 26
column: 22
EntryFrame: 0x7ffee8285860
}
[2] frame 0x7ffee8285770 {
name:
sourceURL: date-format-xparb.js
isInlinedFrame: false
callee: 0x1135f64e0
returnPC: 0x108058eb1
callerFrame: 0x7ffee82857e0
rawLocationBits: 1001 0x3e9
codeBlock: 0x1135bc130 #DAS9xe:[0x1135bc130->0x1135e5100, BaselineFunctionCall, 1149]
bc#1001 of 1149
line: 417
column: 38
EntryFrame: 0x7ffee8285860
}
[3] frame 0x7ffee82857e0 {
name: global code
sourceURL: date-format-xparb.js
isInlinedFrame: false
callee: 0x1130f97b8
returnPC: 0x108039043
callerFrame: 0x0
rawLocationBits: 23 0x17
codeBlock: 0x1135bc000 <global>#CukXvt:[0x1135bc000->0x1130cd768, LLIntGlobal, 81]
bc#23 of 81
line: 425
column: 3
EntryFrame: 0x7ffee8285860
}
ASSERTION FAILED: expectDoesGC()
The error message now comes with the node index, NodeType, codeBlock which this
failure was found in, and the JS call stack that led to the failure.
Changes made:
1. Introduced a DoesGCCheck value that is used to encode some of the above data.
Previously, we only recorded whether doesGC() returns true or false for the
Node. Now, we record the nodeIndex and nodeOp as well.
Note that we also set DoesGC expectations for OSR exits. So, DoesGCCheck
includes Special cases for those.
2. Added store64(TrustedImm64 imm, const void* address) emitters for X86_64 and ARM64.
Also added a test for this new emitter in testmasm.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::store64):
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::store64):
* assembler/testmasm.cpp:
(JSC::testStore64Imm64AddressPointer):
(JSC::run):
* dfg/DFGDoesGCCheck.cpp: Copied from Source/JavaScriptCore/dfg/DFGDoesGCCheck.cpp.
* dfg/DFGDoesGCCheck.h: Copied from Source/JavaScriptCore/dfg/DFGDoesGCCheck.h.
* dfg/DFGGraph.cpp:
* dfg/DFGOSRExit.cpp:
(JSC::DFG::operationCompileOSRExit):
(JSC::DFG::OSRExit::compileExit):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
(JSC::FTL::operationCompileFTLOSRExit):
* heap/CompleteSubspace.cpp:
(JSC::CompleteSubspace::tryAllocateSlow):
(JSC::CompleteSubspace::reallocatePreciseAllocationNonVirtual):
* heap/CompleteSubspaceInlines.h:
(JSC::CompleteSubspace::allocateNonVirtual):
* heap/DeferGC.h:
(JSC::DeferGC::~DeferGC):
* heap/GCDeferralContextInlines.h:
(JSC::GCDeferralContext::~GCDeferralContext):
* heap/Heap.cpp:
(JSC::Heap::collectNow):
(JSC::Heap::collectAsync):
(JSC::Heap::collectSync):
(JSC::Heap::stopIfNecessarySlow):
(JSC::Heap::collectIfNecessaryOrDefer):
* heap/Heap.h:
(JSC::Heap::addressOfDoesGC):
(JSC::Heap::setDoesGCExpectation):
(JSC::Heap::verifyCanGC):
(JSC::Heap::expectDoesGC const): Deleted.
(JSC::Heap::setExpectDoesGC): Deleted.
(JSC::Heap::addressOfExpectDoesGC): Deleted.
* heap/HeapInlines.h:
(JSC::Heap::acquireAccess):
(JSC::Heap::stopIfNecessary):
* heap/LocalAllocatorInlines.h:
(JSC::LocalAllocator::allocate):
* heap/PreciseAllocation.cpp:
(JSC::PreciseAllocation::tryCreate):
(JSC::PreciseAllocation::createForLowerTier):
* runtime/JSString.h:
(JSC::jsSingleCharacterString):
(JSC::JSString::toAtomString const):
(JSC::JSString::toExistingAtomString const):
(JSC::JSString::value const):
(JSC::JSString::tryGetValue const):
(JSC::JSRopeString::unsafeView const):
(JSC::JSRopeString::viewWithUnderlyingString const):
(JSC::JSString::unsafeView const):
* runtime/RegExpMatchesArray.h:
(JSC::createRegExpMatchesArray):
2020-06-03 Mark Lam <mark.lam@apple.com>
DFGSSAConversionPhase.cpp needs to #include OperandsInlines.h.
https://bugs.webkit.org/show_bug.cgi?id=212687
Reviewed by Keith Miller.
Without this, strange build failures can happen with unified builds.
For example, the Windows build started failing due a linkage error in this file
when the patch from https://bugs.webkit.org/show_bug.cgi?id=212680 landed.
212680 introduced a new .cpp file, and that probably bumped DFGSSAConversionPhase.cpp
into another unified unit, thereby depriving it from seeing the OperandsInlines.h
#include'd by another .cpp.
* dfg/DFGSSAConversionPhase.cpp:
2020-06-03 Mark Lam <mark.lam@apple.com>
Fix non-unified --jsc-only build.
https://bugs.webkit.org/show_bug.cgi?id=212707
Reviewed by Yusuke Suzuki.
These files need JSGlobalObjectInlines.h. But rather than adding yet another
#include, we'll just remove many individual ones and just #include JSCInlines.h
instead.
* wasm/js/JSToWasmICCallee.cpp:
* wasm/js/WebAssemblyCompileErrorConstructor.cpp:
* wasm/js/WebAssemblyCompileErrorPrototype.cpp:
* wasm/js/WebAssemblyGlobalPrototype.cpp:
* wasm/js/WebAssemblyInstanceConstructor.cpp:
* wasm/js/WebAssemblyInstancePrototype.cpp:
* wasm/js/WebAssemblyLinkErrorConstructor.cpp:
* wasm/js/WebAssemblyLinkErrorPrototype.cpp:
* wasm/js/WebAssemblyModulePrototype.cpp:
* wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
* wasm/js/WebAssemblyRuntimeErrorPrototype.cpp:
2020-06-03 Rob Buis <rbuis@igalia.com>
Make generated C++ code use modern C++
https://bugs.webkit.org/show_bug.cgi?id=190714
Reviewed by Jonathan Bedard.
Update inspector protocol generator and rebaseline the tests.
* inspector/scripts/codegen/cpp_generator_templates.py:
* inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
* inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
* inspector/scripts/tests/expected/enum-values.json-result:
* inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
* inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
* inspector/scripts/tests/expected/type-declaration-array-type.json-result:
* inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
* inspector/scripts/tests/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
* yarr/generateYarrUnicodePropertyTables.py:
2020-06-02 Mark Lam <mark.lam@apple.com>
Rolling out r262475 to unbreak Windows bot.
https://bugs.webkit.org/show_bug.cgi?id=212680
Not reviewed.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* assembler/MacroAssemblerARM64.h:
* assembler/MacroAssemblerX86_64.h:
* assembler/testmasm.cpp:
(JSC::testCountTrailingZeros64WithoutNullCheck):
(JSC::run):
(JSC::testStore64Imm64AddressPointer): Deleted.
* dfg/DFGDoesGCCheck.cpp: Removed.
* dfg/DFGDoesGCCheck.h: Removed.
* dfg/DFGGraph.cpp:
* dfg/DFGOSRExit.cpp:
(JSC::DFG::operationCompileOSRExit):
(JSC::DFG::OSRExit::compileExit):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
(JSC::FTL::operationCompileFTLOSRExit):
* heap/CompleteSubspace.cpp:
(JSC::CompleteSubspace::tryAllocateSlow):
(JSC::CompleteSubspace::reallocatePreciseAllocationNonVirtual):
* heap/CompleteSubspaceInlines.h:
(JSC::CompleteSubspace::allocateNonVirtual):
* heap/DeferGC.h:
(JSC::DeferGC::~DeferGC):
* heap/GCDeferralContextInlines.h:
(JSC::GCDeferralContext::~GCDeferralContext):
* heap/Heap.cpp:
(JSC::Heap::collectNow):
(JSC::Heap::collectAsync):
(JSC::Heap::collectSync):
(JSC::Heap::stopIfNecessarySlow):
(JSC::Heap::collectIfNecessaryOrDefer):
* heap/Heap.h:
(JSC::Heap::expectDoesGC const):
(JSC::Heap::setExpectDoesGC):
(JSC::Heap::addressOfExpectDoesGC):
(JSC::Heap::addressOfDoesGC): Deleted.
(JSC::Heap::setDoesGCExpectation): Deleted.
(JSC::Heap::verifyCanGC): Deleted.
* heap/HeapInlines.h:
(JSC::Heap::acquireAccess):
(JSC::Heap::stopIfNecessary):
* heap/LocalAllocatorInlines.h:
(JSC::LocalAllocator::allocate):
* heap/PreciseAllocation.cpp:
(JSC::PreciseAllocation::tryCreate):
(JSC::PreciseAllocation::createForLowerTier):
* runtime/JSString.h:
(JSC::jsSingleCharacterString):
(JSC::JSString::toAtomString const):
(JSC::JSString::toExistingAtomString const):
(JSC::JSString::value const):
(JSC::JSString::tryGetValue const):
(JSC::JSRopeString::unsafeView const):
(JSC::JSRopeString::viewWithUnderlyingString const):
(JSC::JSString::unsafeView const):
* runtime/RegExpMatchesArray.h:
(JSC::createRegExpMatchesArray):
2020-06-02 Mark Lam <mark.lam@apple.com>
Enhance DoesGC verification to print more useful info when verification fails.
https://bugs.webkit.org/show_bug.cgi?id=212680
Reviewed by Yusuke Suzuki.
When DoesGC verification fails, the first step of debugging it would be to find
out what and which DFG node resulted in the failed verification. In pre-existing
code, all we get is an assertion failure.
This patch makes it so that the verifier will dump useful info. Here's an example:
Error: DoesGC failed @ D@34 DateGetInt32OrNaN in #DtCHMz:[0x1135bd1d0->0x1135bcab0->0x1135e5c80, DFGFunctionCall, 150 (DidTryToEnterInLoop)]
[0] frame 0x7ffee8285660 {
name:
sourceURL:
isInlinedFrame: false
callee: 0x1135f6820
returnPC: 0x50ce61248ae6
callerFrame: 0x7ffee82856f0
rawLocationBits: 5 0x5
codeBlock: 0x1135bd1d0 #DtCHMz:[0x1135bd1d0->0x1135bcab0->0x1135e5c80, DFGFunctionCall, 150 (DidTryToEnterInLoop)]
hasCodeOrigins: true
callSiteIndex: 5 of 13
jitCode: 0x113020200 start 0x50ce61214c60 end 0x50ce61219b00
line: 1
column: 60
EntryFrame: 0x7ffee8285860
}
[1] frame 0x7ffee82856f0 {
name:
sourceURL: date-format-xparb.js
isInlinedFrame: false
callee: 0x1135f65a0
returnPC: 0x50ce61227e99
callerFrame: 0x7ffee8285770
rawLocationBits: 4 0x4
codeBlock: 0x1135bd0a0 #BU6Zcd:[0x1135bd0a0->0x1135bc260->0x1135e5180, DFGFunctionCall, 112 (DidTryToEnterInLoop)]
hasCodeOrigins: true
callSiteIndex: 4 of 12
jitCode: 0x113004000 start 0x50ce61212c60 end 0x50ce61214960
line: 26
column: 22
EntryFrame: 0x7ffee8285860
}
[2] frame 0x7ffee8285770 {
name:
sourceURL: date-format-xparb.js
isInlinedFrame: false
callee: 0x1135f64e0
returnPC: 0x108058eb1
callerFrame: 0x7ffee82857e0
rawLocationBits: 1001 0x3e9
codeBlock: 0x1135bc130 #DAS9xe:[0x1135bc130->0x1135e5100, BaselineFunctionCall, 1149]
bc#1001 of 1149
line: 417
column: 38
EntryFrame: 0x7ffee8285860
}
[3] frame 0x7ffee82857e0 {
name: global code
sourceURL: date-format-xparb.js
isInlinedFrame: false
callee: 0x1130f97b8
returnPC: 0x108039043
callerFrame: 0x0
rawLocationBits: 23 0x17
codeBlock: 0x1135bc000 <global>#CukXvt:[0x1135bc000->0x1130cd768, LLIntGlobal, 81]
bc#23 of 81
line: 425
column: 3
EntryFrame: 0x7ffee8285860
}
ASSERTION FAILED: expectDoesGC()
The error message now comes with the node index, NodeType, codeBlock which this
failure was found in, and the JS call stack that led to the failure.
Changes made:
1. Introduced a DoesGCCheck value that is used to encode some of the above data.
Previously, we only recorded whether doesGC() returns true or false for the
Node. Now, we record the nodeIndex and nodeOp as well.
Note that we also set DoesGC expectations for OSR exits. So, DoesGCCheck
includes Special cases for those.
2. Added store64(TrustedImm64 imm, const void* address) emitters for X86_64 and ARM64.
Also added a test for this new emitter in testmasm.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::store64):
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::store64):
* assembler/testmasm.cpp:
(JSC::testStore64Imm64AddressPointer):
(JSC::run):
* dfg/DFGDoesGCCheck.cpp: Added.
(JSC::DFG::DoesGCCheck::verifyCanGC):
* dfg/DFGDoesGCCheck.h: Added.
(JSC::DFG::DoesGCCheck::DoesGCCheck):
(JSC::DFG::DoesGCCheck::encode):
(JSC::DFG::DoesGCCheck::set):
(JSC::DFG::DoesGCCheck::expectDoesGC):
(JSC::DFG::DoesGCCheck::special):
(JSC::DFG::DoesGCCheck::nodeIndex):
(JSC::DFG::DoesGCCheck::nodeOp):
(JSC::DFG::DoesGCCheck::isSpecial):
(JSC::DFG::DoesGCCheck::specialIndex):
(JSC::DFG::DoesGCCheck::bits):
* dfg/DFGGraph.cpp:
* dfg/DFGOSRExit.cpp:
(JSC::DFG::operationCompileOSRExit):
(JSC::DFG::OSRExit::compileExit):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
(JSC::FTL::operationCompileFTLOSRExit):
* heap/CompleteSubspace.cpp:
(JSC::CompleteSubspace::tryAllocateSlow):
(JSC::CompleteSubspace::reallocatePreciseAllocationNonVirtual):
* heap/CompleteSubspaceInlines.h:
(JSC::CompleteSubspace::allocateNonVirtual):
* heap/DeferGC.h:
(JSC::DeferGC::~DeferGC):
* heap/GCDeferralContextInlines.h:
(JSC::GCDeferralContext::~GCDeferralContext):
* heap/Heap.cpp:
(JSC::Heap::collectNow):
(JSC::Heap::collectAsync):
(JSC::Heap::collectSync):
(JSC::Heap::stopIfNecessarySlow):
(JSC::Heap::collectIfNecessaryOrDefer):
* heap/Heap.h:
(JSC::Heap::addressOfDoesGC):
(JSC::Heap::setDoesGCExpectation):
(JSC::Heap::verifyCanGC):
(JSC::Heap::expectDoesGC const): Deleted.
(JSC::Heap::setExpectDoesGC): Deleted.
(JSC::Heap::addressOfExpectDoesGC): Deleted.
* heap/HeapInlines.h:
(JSC::Heap::acquireAccess):
(JSC::Heap::stopIfNecessary):
* heap/LocalAllocatorInlines.h:
(JSC::LocalAllocator::allocate):
* heap/PreciseAllocation.cpp:
(JSC::PreciseAllocation::tryCreate):
(JSC::PreciseAllocation::createForLowerTier):
* runtime/JSString.h:
(JSC::jsSingleCharacterString):
(JSC::JSString::toAtomString const):
(JSC::JSString::toExistingAtomString const):
(JSC::JSString::value const):
(JSC::JSString::tryGetValue const):
(JSC::JSRopeString::unsafeView const):
(JSC::JSRopeString::viewWithUnderlyingString const):
(JSC::JSString::unsafeView const):
* runtime/RegExpMatchesArray.h:
(JSC::createRegExpMatchesArray):
2020-06-02 Mark Lam <mark.lam@apple.com>
VMInspector APIs should be taking a VM* instead of a JSGlobalObject*.
https://bugs.webkit.org/show_bug.cgi?id=212676
Reviewed by Saam Barati and Robin Morisset.
This because:
1. None of the functions currently taking a JSGlobalObject* actually need the
globalObject. All of them need the VM.
2. The role of the VMInspector is to enable inspection of the VM. By requiring
that it be passed a JSGlobalObject*, we were actually preventing the VMInspector
from being used in code that have a VM to inspect but don't have a JSGlobalObject
to use.
The reason I'm choosing to pass VM* instead of VM& is because it makes these
functions trivial to call using lldb interactively. The VMInspector functions
are also intentionally designed so that they can be used for this purpose.
On occasion, I may have to cast literal numbers (addresses) to VM*. Technically,
I could cast a number to VM* and dereference it to get a VM& too. However, at
present, lldb is often buggy and not always reliable with casts. I would like to
lessen the chance that lldb fails on me when I'm deep in the middle of a debugging
session, and have a need to call one of these functions.
* tools/JSDollarVM.cpp:
(JSC::functionGC):
(JSC::functionEdenGC):
(JSC::functionCodeBlockForFrame):
(JSC::codeBlockFromArg):
(JSC::functionDumpCallFrame):
(JSC::functionDumpStack):
* tools/VMInspector.cpp:
(JSC::VMInspector::currentThreadOwnsJSLock):
(JSC::ensureCurrentThreadOwnsJSLock):
(JSC::VMInspector::gc):
(JSC::VMInspector::edenGC):
(JSC::VMInspector::isValidCodeBlock):
(JSC::VMInspector::codeBlockForFrame):
(JSC::VMInspector::dumpCallFrame):
(JSC::VMInspector::dumpStack):
* tools/VMInspector.h:
2020-06-02 Keith Rollin <krollin@apple.com>
Revert FEATURES_DEFINES related changes
https://bugs.webkit.org/show_bug.cgi?id=212664
<rdar://problem/63893033>
Reviewed by Andy Estes.
Bug 262310, Bug 262311, Bug 262318, and Bug 262331 involve changes to
FEATURE_DEFINES and how the values there relate to those found in the
Platform*.h files. Those changes break XCBuild (by removing the
.xcfilelist related to UnifiedSources and the process for generating
them), and so are being reverted.
* Configurations/FeatureDefines.xcconfig:
2020-06-02 Ryan Haddad <ryanhaddad@apple.com>
Unreviewed, reverting r262424.
Caused webkitpy test failure
Reverted changeset:
"Make generated C++ code use modern C++"
https://bugs.webkit.org/show_bug.cgi?id=190714
https://trac.webkit.org/changeset/262424
2020-06-02 Mark Lam <mark.lam@apple.com>
Change Gigacage::Config to use storage in WebConfig::g_config instead of its own.
https://bugs.webkit.org/show_bug.cgi?id=212585
<rdar://problem/63812487>
Reviewed by Yusuke Suzuki.
* assembler/testmasm.cpp:
(JSC::testCagePreservesPACFailureBit):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::cageTypedArrayStorage):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::caged):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::cageConditionally):
* llint/LowLevelInterpreter64.asm:
* runtime/JSCConfig.h:
(JSC::Config::isPermanentlyFrozen):
2020-06-02 Saam Barati <sbarati@apple.com>
MultiDeleteByOffset should not always def
https://bugs.webkit.org/show_bug.cgi?id=212621
<rdar://problem/63824182>
Reviewed by Yusuke Suzuki.
Clobberize used to claim that MultiDeleteByOffset always defd a value.
That's an incorrect modeling of MultiDeleteByOffset though, since it might
have delete misses in its variant list. This would lead us to incorrectly
CSE when we shouldn't. This patch fixes this by saying MultiDeleteByOffset
only defs when all its cases write out a value (are hits).
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGNode.cpp:
(JSC::DFG::MultiDeleteByOffsetData::allVariantsStoreEmpty const):
* dfg/DFGNode.h:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileMultiDeleteByOffset):
2020-06-02 Rob Buis <rbuis@igalia.com>
Make generated C++ code use modern C++
https://bugs.webkit.org/show_bug.cgi?id=190714
Reviewed by Sam Weinig.
Update inspector protocol generator and rebaseline the tests.
* inspector/scripts/codegen/cpp_generator_templates.py:
* inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
* inspector/scripts/tests/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result:
* inspector/scripts/tests/expected/enum-values.json-result:
* inspector/scripts/tests/expected/events-with-optional-parameters.json-result:
* inspector/scripts/tests/expected/same-type-id-different-domain.json-result:
* inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result:
* inspector/scripts/tests/expected/type-declaration-array-type.json-result:
* inspector/scripts/tests/expected/type-declaration-enum-type.json-result:
* inspector/scripts/tests/expected/type-declaration-object-type.json-result:
* inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result:
* yarr/generateYarrUnicodePropertyTables.py:
2020-06-02 Paulo Matos <pmatos@igalia.com>
Fix assert message formatting
https://bugs.webkit.org/show_bug.cgi?id=212591
Reviewed by Adrian Perez de Castro.
Fixes warning by gcc - lineParts.size() is size_t, %zu should be used.
* runtime/FuzzerPredictions.cpp:
(JSC::FuzzerPredictions::FuzzerPredictions):
2020-06-01 Devin Rousso <drousso@apple.com>
Web Inspector: Graphics: should use the `id` (name) of the animation if it exists
https://bugs.webkit.org/show_bug.cgi?id=212618
Reviewed by Timothy Hatcher.
* inspector/protocol/Animation.json:
- added an optional `name` property to the `Animation.Animation` type
- created a new `Animation.nameChanged` event
2020-06-01 Saam Barati <sbarati@apple.com>
Correct misunderstandings on how ThreadSpecific work
https://bugs.webkit.org/show_bug.cgi?id=212616
Reviewed by Michael Saboff.
There were two misunderstandings I had when writing code using ThreadSpecific
when doing LLInt bytecode buffer caching in Wasm.
1. For ThreadSpecific<Vector>, I was calling Vector's constructor twice
unnecessarily, and incorrectly, since we ended up constructing over an
already constructed Vector for the second call. When doing operator* or
operator-> on a ThreadSpecific<T>, T() is called if it has not been
initialized yet. So there is no need to do manually call the constructor
the second time.
2. There is no need to try to destroy entries for ThreadSpecific manually
since we already run destructors when the thread goes away.
This patch removes code for (1) and (2) both from the Wasm bytecode
buffer and from AssemblerData.
* assembler/AssemblerBuffer.cpp:
(JSC::clearAssembleDataThreadSpecificCache): Deleted.
* assembler/AssemblerBuffer.h:
(JSC::AssemblerBuffer::AssemblerBuffer):
(JSC::AssemblerBuffer::~AssemblerBuffer):
(JSC::AssemblerBuffer::getThreadSpecificAssemblerData): Deleted.
* dfg/DFGWorklist.cpp:
* jit/JITWorklist.cpp:
* wasm/WasmLLIntGenerator.cpp:
(JSC::Wasm::LLIntGenerator::LLIntGenerator):
(JSC::Wasm::clearLLIntThreadSpecificCache): Deleted.
* wasm/WasmLLIntGenerator.h:
* wasm/WasmWorklist.cpp:
2020-06-01 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, fix build failure in ARMv7k
https://bugs.webkit.org/show_bug.cgi?id=212595
* runtime/JSCJSValue.cpp:
(JSC::JSValue::toThisSlowCase const):
2020-06-01 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] JSBigInt::rightTrim can miss |this| pointer and leads to incorrect GC collection
https://bugs.webkit.org/show_bug.cgi?id=212601
Reviewed by Saam Barati.
This is pretty rare case. But in some optimization level, JSBigInt::rightTrim could store |this| + offset pointer into the stack instead of |this|
and make conservative GC think that |this| JSBigInt is unreachable. We put ensureStillAliveHere(this) to ensure that this is alive.
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::rightTrim):
2020-06-01 Mark Lam <mark.lam@apple.com>
x86.rb's LabelReference.x86LoadOperand()'s address operand should be a pointer type.
https://bugs.webkit.org/show_bug.cgi?id=212603
Reviewed by Saam Barati.
The current implementation mistakenly sets the address type to that of the value
being loaded. I encountered this issue when I was trying to do a loadb from a
global address. Because of this bug, the emitted code was trying do a load using
%al (8 byte register) as the pointer to load from. With this fix, it now loads
from %rax.
* offlineasm/x86.rb:
2020-06-01 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] JSValue::toThis should not throw exception
https://bugs.webkit.org/show_bug.cgi?id=212595
Reviewed by Mark Lam.
Including WebCore code, there are a lot of code which assume JSValue::toThis should not throw an exception.
This assumption was now broken after making JSBigInt allocation graceful for OOM. But for this particular JSValue::toThis case,
we can make it non-throwing code.
This patch makes JSValue::toThis non-throwing code to fix exception-missing debug assertions.
We ensure that BigIntObject can hold BigInt32 (actually, it can already if toObjectSlowCase path is taken).
* runtime/BigIntObject.cpp:
(JSC::BigIntObject::create):
* runtime/JSCJSValue.cpp:
(JSC::JSValue::toThisSlowCase const):
2020-06-01 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] BigInt operations should handle exception correctly
https://bugs.webkit.org/show_bug.cgi?id=212596
Reviewed by Mark Lam.
Some places miss exception check / explicit scope-release while BigInt operations can now throw an exception.
This patch adds them. They are covered by existing stress tests with Debug build.
* runtime/Operations.h:
(JSC::compareBigIntToOtherPrimitive):
(JSC::compareBigInt32ToOtherPrimitive):
(JSC::jsInc):
(JSC::jsDec):
(JSC::jsBitwiseNot):
2020-05-31 Michael Saboff <msaboff@apple.com>
Consider a Thread Specific Cache for AssemblerBuffers
https://bugs.webkit.org/show_bug.cgi?id=212562
Reviewed by Filip Pizlo.
This patch creates a thread local cache of AssemblerData in the hopes that it will reduce
memory allocation churn. The cache is cleared when a thread is destroyed.
If an AssemblerData is destroyed in another thread, its storage is cached by the
destroying thread.
Made a few changes described below to facilite the swap as well as returning a
clear()'ed AssemblerData back to its original state.
Reviewed by Filip Pizlo.
* assembler/AssemblerBuffer.cpp:
(JSC::threadSpecificAssemblerData):
(JSC::clearAssembleDataThreadSpecificCache):
* assembler/AssemblerBuffer.h:
(JSC::AssemblerData::AssemblerData):
(JSC::AssemblerData::operator=):
The copy constructor and assignment operator now perform complete AssemblerBuffer swaps.
(JSC::AssemblerData::takeBufferIfLarger):
A new method that will conditionally copy the enclosed buffer of the argument to "this"
if the argument's buffer is larger than the current buffer of "this".
(JSC::AssemblerData::~AssemblerData):
(JSC::AssemblerData::clear):
The destructor now calls clear which has been changed to reset the buffer to one with
inline capacity.
(JSC::AssemblerBuffer::AssemblerBuffer):
Take the cached out of line buffer if there is one.
(JSC::AssemblerBuffer::~AssemblerBuffer):
Cache the enclosed out of line buffer if it is larger than the currently cached one.
(JSC::AssemblerBuffer::getThreadSpecificAssemblerData):
* dfg/DFGWorklist.cpp:
* jit/JITWorklist.cpp:
* wasm/WasmWorklist.cpp:
2020-05-31 Mark Lam <mark.lam@apple.com>
Change JSC::Config to use storage in WTF::Config instead of its own.
https://bugs.webkit.org/show_bug.cgi?id=212575
<rdar://problem/63796584>
Reviewed by Yusuke Suzuki.
Since Configs must be rounded up to CeilingOnPageSize, this will save us some
memory since the contents of both Configs do not add up to CeilingOnPageSize.
g_jscConfig is now located at g_wtfConfig.spaceForExtensions.
* runtime/JSCConfig.cpp:
(JSC::Config::disableFreezingForTesting):
(JSC::Config::enableRestrictedOptions):
(JSC::Config::permanentlyFreeze): Deleted.
* runtime/JSCConfig.h:
(JSC::Config::permanentlyFreeze):
(JSC::Config::isPermanentlyFrozen):
(): Deleted.
* runtime/Options.cpp:
(JSC::Options::setOptions):
* tools/JSDollarVM.cpp:
(JSC::functionCallWithStackSize):
2020-05-30 Mark Lam <mark.lam@apple.com>
Rename Signal::BadAccess to Signal::AccessFault.
https://bugs.webkit.org/show_bug.cgi?id=212577
Reviewed by Yusuke Suzuki.
* runtime/VMTraps.cpp:
* wasm/WasmFaultSignalHandler.cpp:
(JSC::Wasm::enableFastMemory):
2020-05-30 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] for-in should allocate new temporary register for base
https://bugs.webkit.org/show_bug.cgi?id=212519
<rdar://problem/63722044>
Reviewed by Saam Barati.
While r262233 keeps for-in's enumerated object in variable register if possible to use this register for heuristics driving an optimization,
for-in body can replace the content of this register during enumeration and confuse enumerator.
Instead, we record Variable information in StructureForInContext. This allows us to detect patterns using heap-variables too.
Further, this patch extends pattern-matching code to support ThisNode too.
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::pushStructureForInScope):
* bytecompiler/BytecodeGenerator.h:
(JSC::Variable::Variable):
(JSC::Variable::isResolved const):
(JSC::Variable::symbolTableConstantIndex const):
(JSC::Variable::ident const):
(JSC::Variable::offset const):
(JSC::Variable::isLocal const):
(JSC::Variable::local const):
(JSC::Variable::isReadOnly const):
(JSC::Variable::isSpecial const):
(JSC::Variable::isConst const):
(JSC::Variable::setIsReadOnly):
(JSC::Variable::operator== const):
(JSC::StructureForInContext::StructureForInContext):
(JSC::StructureForInContext::baseVariable const):
(JSC::StructureForInContext::base const): Deleted.
* bytecompiler/NodesCodegen.cpp:
(JSC::HasOwnPropertyFunctionCallDotNode::emitBytecode):
(JSC::ForInNode::emitBytecode):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::makeFunctionCallNode):
* parser/Nodes.h:
(JSC::ExpressionNode::isThisNode const):
2020-05-30 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, fix JSC debug tests' exception checking
https://bugs.webkit.org/show_bug.cgi?id=212512
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::createWithLength):
(JSC::JSBigInt::allocateFor):
2020-05-30 Mark Lam <mark.lam@apple.com>
AssemblyHelpers::callExceptionFuzz() is passing a wrong argument to operationExceptionFuzz().
https://bugs.webkit.org/show_bug.cgi?id=212561
Reviewed by Yusuke Suzuki.
There's 2 possible solution to this issue:
1. Thread the globalObject from all the way up the clients calling into
callExceptionFuzz(), or
2. Introduce a operationExceptionFuzzWithCallFrame() wrapper take receives a VM*
and CallFrame*, and use these to get the lexicalGlobalObject.
This patch applies solution 2.
Solution 1 is too unwieldy because it will cause the threading of the globalObject
argument to fan out to many clients, and almost all of those clients currently
do not need the globalObject. Hence, implementing this solution may incur some
performance penalty in normal code, for the sole benefit of this one fuzzing tool.
Secondly, the exception fuzzer doesn't really care which globalObject is used.
It only cares that an exception is thrown, and we need a globalObject in order to
throw that exception. Hence, there is no benefit to threading the globalObject
down from all the clients.
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::callExceptionFuzz):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
2020-05-29 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] JSBigInt allocation should be graceful for OOM
https://bugs.webkit.org/show_bug.cgi?id=212512
Reviewed by Mark Lam.
This patch allows JSBigInt's storage allocation to fail gracefully if OOM condition happens.
We thread JSGlobalObject* instead of VM& and throw OOM error if storage allocation failed.
We also rename `JSGlobalObject* globalObject` parameter to `JSGlobalObject* nullOrGlobalObjectForOOM`
if it can be nullptr.
* jit/JITOperations.cpp:
* jsc.cpp:
(functionCreateHeapBigInt):
* parser/ParserArena.cpp:
(JSC::IdentifierArena::makeBigIntDecimalIdentifier):
* runtime/BigIntConstructor.cpp:
(JSC::toBigInt):
(JSC::callBigIntConstructor):
* runtime/BigIntPrototype.cpp:
(JSC::toThisBigIntValue):
(JSC::bigIntProtoFuncToString):
(JSC::bigIntProtoFuncToLocaleString):
(JSC::bigIntProtoFuncValueOf):
* runtime/CachedTypes.cpp:
(JSC::CachedBigInt::decode const):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/IntlNumberFormatPrototype.cpp:
(JSC::IntlNumberFormatFuncFormat):
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::createZero):
(JSC::JSBigInt::tryCreateZero):
(JSC::JSBigInt::createWithLength):
(JSC::JSBigInt::tryCreateWithLength):
(JSC::JSBigInt::createFrom):
(JSC::JSBigInt::tryCreateFrom):
(JSC::JSBigInt::createFromImpl):
(JSC::JSBigInt::parseInt):
(JSC::HeapBigIntImpl::toHeapBigInt):
(JSC::Int32BigIntImpl::toHeapBigInt):
(JSC::zeroImpl):
(JSC::JSBigInt::exponentiateImpl):
(JSC::JSBigInt::multiplyImpl):
(JSC::JSBigInt::divideImpl):
(JSC::JSBigInt::copy):
(JSC::JSBigInt::unaryMinusImpl):
(JSC::JSBigInt::unaryMinus):
(JSC::JSBigInt::remainderImpl):
(JSC::JSBigInt::incImpl):
(JSC::JSBigInt::decImpl):
(JSC::JSBigInt::addImpl):
(JSC::JSBigInt::subImpl):
(JSC::JSBigInt::bitwiseAndImpl):
(JSC::JSBigInt::bitwiseOrImpl):
(JSC::JSBigInt::bitwiseXorImpl):
(JSC::JSBigInt::absoluteAdd):
(JSC::JSBigInt::absoluteSub):
(JSC::JSBigInt::absoluteDivWithDigitDivisor):
(JSC::JSBigInt::absoluteDivWithBigIntDivisor):
(JSC::JSBigInt::absoluteLeftShiftAlwaysCopy):
(JSC::JSBigInt::absoluteBitwiseOp):
(JSC::JSBigInt::absoluteAnd):
(JSC::JSBigInt::absoluteOr):
(JSC::JSBigInt::absoluteAndNot):
(JSC::JSBigInt::absoluteXor):
(JSC::JSBigInt::absoluteAddOne):
(JSC::JSBigInt::absoluteSubOne):
(JSC::JSBigInt::leftShiftByAbsolute):
(JSC::JSBigInt::rightShiftByAbsolute):
(JSC::JSBigInt::rightShiftByMaximum):
(JSC::JSBigInt::toStringBasePowerOfTwo):
(JSC::JSBigInt::toStringGeneric):
(JSC::JSBigInt::rightTrim):
(JSC::JSBigInt::tryRightTrim):
(JSC::JSBigInt::allocateFor):
(JSC::JSBigInt::asIntNImpl):
(JSC::JSBigInt::asUintNImpl):
(JSC::JSBigInt::truncateToNBits):
(JSC::JSBigInt::truncateAndSubFromPowerOfTwo):
(JSC::JSBigInt::createWithLengthUnchecked): Deleted.
* runtime/JSBigInt.h:
* runtime/JSCJSValue.cpp:
(JSC::JSValue::toThisSlowCase const):
* runtime/VM.cpp:
(JSC::VM::VM):
2020-05-29 Saam Barati <sbarati@apple.com>
We need to properly model heap ranges of Delete in DFG/B3
https://bugs.webkit.org/show_bug.cgi?id=212538
<rdar://problem/63670964>
Reviewed by Filip Pizlo.
We need to properly model the aliasing dependencies of an inlined delete
operation.
We had a bug in the B3 IR we generated from code like this for a delete
followed by a property addition:
```
const o = { y: 0 };
delete o.y;
o.z = 0;
```
generated:
```
note: bb#5 dominates bb#10, bb#10 dominates bb#15
bb#5
Void b@125 = Store($-562949953421312(b@282), b@112, offset = 16, ControlDependent|Writes:129, D@30)
bb#10
Void b@171 = Store($0(b@2), b@112, offset = 16, ControlDependent|Writes:129, D@37)
bb#15
Void b@217 = Store($-562949953421312(b@282), b@112, offset = 16, ControlDependent|Writes:130, D@44)
```
Notice that "y" and "z" ended up at the same property offset.
In the above program, B3 proves the pointer we're storing to is the same value
in all three stores (b@112). However, because of how it does store forwarding,
it determined it could eliminate b@217 because b@125 already stored the same
value to the same pointer. It didn't know that b@171 was a write because its
heap range is different than @217. Generally, when using two heap ranges, it's
telling B3 that two pointers don't alias.
```
@A, Heap_H
@B, Heap_H
```
In the above program,
- If @B reads H and @A writes H, then @B is dependent on @A.
- If @B writes H, then @B is dependent on @A if @A reads or writes H.
So for delete, we need to model the deletion of a property as actually
writing to all named properties that may exist at that slot given a
series of structure transitions. We model this by saying the PutStructure
for an inlined delete, or MultiDeleteByOffset, writes to all named properties
(which is a superset of all named properties that may exist at that slot
through a series of transitions).
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* ftl/FTLAbstractHeap.cpp:
(JSC::FTL::IndexedAbstractHeap::dump):
(JSC::FTL::NumberedAbstractHeap::dump):
(JSC::FTL::AbsoluteAbstractHeap::dump):
(JSC::FTL::IndexedAbstractHeap::dump const): Deleted.
(JSC::FTL::NumberedAbstractHeap::dump const): Deleted.
(JSC::FTL::AbsoluteAbstractHeap::dump const): Deleted.
* ftl/FTLAbstractHeap.h:
(JSC::FTL::IndexedAbstractHeap::atAnyIndex):
(JSC::FTL::NumberedAbstractHeap::atAnyNumber):
(JSC::FTL::AbsoluteAbstractHeap::atAnyAddress):
(JSC::FTL::IndexedAbstractHeap::atAnyIndex const): Deleted.
(JSC::FTL::NumberedAbstractHeap::atAnyNumber const): Deleted.
(JSC::FTL::AbsoluteAbstractHeap::atAnyAddress const): Deleted.
* ftl/FTLAbstractHeapRepository.cpp:
(JSC::FTL::AbstractHeapRepository::AbstractHeapRepository):
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compilePutStructure):
(JSC::FTL::DFG::LowerDFGToB3::compileMultiDeleteByOffset):
2020-05-29 Andy Estes <aestes@apple.com>
[Apple Pay] Remove conditionals for ENABLE_APPLE_PAY_SESSION_V(3|4)
https://bugs.webkit.org/show_bug.cgi?id=212541
Reviewed by Darin Adler.
APPLE_PAY_SESSION_V(3|4) is now enabled whenever APPLE_PAY itself is enabled.
* Configurations/FeatureDefines.xcconfig:
2020-05-29 Darin Adler <darin@apple.com>
Remove things from FeatureDefines.xcconfig that are covered by PlatformEnableCocoa.h
https://bugs.webkit.org/show_bug.cgi?id=212418
Rubber-stamped by Simon Fraser.
* Configurations/FeatureDefines.xcconfig: Add back ENABLE_CSS_CONIC_GRADIENTS, removed
by accident.
2020-05-27 Darin Adler <darin@apple.com>
Remove things from FeatureDefines.xcconfig that are covered by PlatformEnableCocoa.h
https://bugs.webkit.org/show_bug.cgi?id=212418
Reviewed by Andy Estes.
* Configurations/FeatureDefines.xcconfig: Removed 83 of the 119 things defined in
this file. There are 36 more that are slightly more complex that we can remove
carefully later.
2020-05-29 Darin Adler <darin@apple.com>
[Cocoa] Pass all defines from Platform.h to various scripts, not just the ones from .xcconfig
https://bugs.webkit.org/show_bug.cgi?id=212451
Reviewed by Sam Weinig.
* DerivedSources.make: Run the preprocessor on Platform.h and parse the output into
FEATURE_AND_PLATFORM_DEFINES. Use that and FEATURE_AND_PLATFORM_DEFINE_DEPENDENCIES
whenever we need a list of defines. Also took out some Windows-specific stuff since
this is now only used on Mac platforms. Use ":=" when calling $(shell) to make sure
the same shell command is not invoked over and over again.
2020-05-29 Keith Rollin <krollin@apple.com>
Revert switch to XCBuild
https://bugs.webkit.org/show_bug.cgi?id=212530
<rdar://problem/63764632>
Unreviewed build fix.
Bug 209890 enabled the use of XCBuild by default. Since then, some
build issues have shown up. While addressing them, temporarily turn
off the use of XCBuild by default.
* Configurations/JavaScriptCore.xcconfig:
* JavaScriptCore.xcodeproj/project.pbxproj:
2020-05-29 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r262245.
https://bugs.webkit.org/show_bug.cgi?id=212531
"Caused WebCore's 'Check .xcfilelists' build phase to be ~100x
slower"
Reverted changeset:
"[Cocoa] Pass all defines from Platform.h to various scripts,
not just the ones from .xcconfig"
https://bugs.webkit.org/show_bug.cgi?id=212451
https://trac.webkit.org/changeset/262245
2020-05-29 Devin Rousso <drousso@apple.com>
Web Inspector: add ITML debuggable/target type
https://bugs.webkit.org/show_bug.cgi?id=203300
<rdar://problem/56545896>
Reviewed by Joseph Pecoraro and Brian Burg.
* API/JSContextPrivate.h:
* API/JSContext.mm:
(-[JSContext _setITMLDebuggableType]): Added.
* runtime/JSGlobalObject.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::setIsITML): Added.
Create an SPI for marking a `JSContext` as an ITML context for Web Inspector.
* runtime/JSGlobalObjectDebuggable.h:
(isType):
* inspector/remote/RemoteControllableTarget.h:
* inspector/remote/RemoteInspectionTarget.h:
* inspector/remote/RemoteInspectorConstants.h:
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::connectFrontend):
Don't dispatch `Inspector.activateExtraDomains` unless we're a basic `JavaScript` debuggable.
* inspector/remote/cocoa/RemoteInspectorCocoa.mm:
(Inspector::RemoteInspector::listingForInspectionTarget const):
* inspector/scripts/codegen/models.py:
(validate_target_types):
* inspector/scripts/codegen/objc_generator.py:
(ObjCGenerator):
* inspector/scripts/tests/expected/fail-on-command-targetTypes-value.json-error:
* inspector/scripts/tests/expected/fail-on-domain-debuggableTypes-value.json-error:
* inspector/scripts/tests/expected/fail-on-domain-targetTypes-value.json-error:
* inspector/scripts/tests/expected/fail-on-event-targetTypes-value.json-error:
* inspector/protocol/Audit.json:
* inspector/protocol/CSS.json:
* inspector/protocol/Console.json:
* inspector/protocol/DOM.json:
* inspector/protocol/DOMStorage.json:
* inspector/protocol/Database.json:
* inspector/protocol/Debugger.json:
* inspector/protocol/Heap.json:
* inspector/protocol/Inspector.json:
* inspector/protocol/Network.json:
* inspector/protocol/Page.json:
* inspector/protocol/Runtime.json:
* inspector/protocol/Security.json:
Add support for `itml` debuggables and targets, marking non-ITML commands/events with `page`.
2020-05-29 Mark Lam <mark.lam@apple.com>
Add a check for errors when computing a utf string in jsc shell's runInteractive().
https://bugs.webkit.org/show_bug.cgi?id=212526
<rdar://problem/63757892>
Reviewed by Michael Saboff.
* jsc.cpp:
(runInteractive):
2020-05-28 Devin Rousso <drousso@apple.com>
Web Inspector: add missing condition guards when generating objc protocol files
https://bugs.webkit.org/show_bug.cgi?id=212494
Reviewed by Timothy Hatcher.
* inspector/scripts/codegen/generate_objc_backend_dispatcher_header.py:
(ObjCBackendDispatcherHeaderGenerator._generate_objc_forward_declarations):
* inspector/scripts/codegen/generate_objc_configuration_header.py:
(ObjCConfigurationHeaderGenerator._generate_properties_for_domain):
* inspector/scripts/codegen/generate_objc_configuration_implementation.py:
(ObjCConfigurationImplementationGenerator._generate_configuration_implementation_for_domains):
(ObjCConfigurationImplementationGenerator._generate_ivars):
(ObjCConfigurationImplementationGenerator._generate_dealloc):
(ObjCConfigurationImplementationGenerator._generate_event_dispatcher_getter_for_domain):
(ObjCConfigurationImplementationGenerator._variable_name_prefix_for_domain): Deleted.
* inspector/scripts/codegen/generate_objc_frontend_dispatcher_implementation.py:
(ObjCFrontendDispatcherImplementationGenerator._generate_event_dispatcher_implementations):
(ObjCFrontendDispatcherImplementationGenerator._generate_event):
* inspector/scripts/codegen/generate_objc_header.py:
(ObjCHeaderGenerator._generate_forward_declarations):
(ObjCHeaderGenerator._generate_enums):
(ObjCHeaderGenerator._generate_types):
(ObjCHeaderGenerator._generate_command_protocols):
(ObjCHeaderGenerator._generate_event_interfaces):
(ObjCHeaderGenerator._generate_single_event_interface):
* inspector/scripts/codegen/generate_objc_internal_header.py:
(ObjCInternalHeaderGenerator._generate_event_dispatcher_private_interfaces):
* inspector/scripts/codegen/generate_objc_protocol_type_conversions_header.py:
(ObjCProtocolTypeConversionsHeaderGenerator._generate_enum_conversion_functions):
* inspector/scripts/tests/definitions-with-mac-platform.json:
* inspector/scripts/tests/expected/definitions-with-mac-platform.json-result:
2020-05-27 Keith Miller <keith_miller@apple.com>
for-of should check the iterable is a JSArray for FastArray in DFG iterator_open
https://bugs.webkit.org/show_bug.cgi?id=212383
Reviewed by Saam Barati.
This patch fixes an issue where we didn't check that the iterable operand to
iterator_open was a JSArray when lowering the FastArray only variant of the bytecode to the DFG.
This meant we would OSR exit at the iterator_next's lowering then assertion failure in the
checkpoint OSR exit helper. To make this work, this patch extends (and renames from CheckSubClass)
CheckJSCast to use the same JSType information that we use for the jsCast function. In order to
get the JSType range from a ClassInfo* the macro that autogenerates MethodTable now also fills
a Optional<JSTypeRange> into the ClassInfo as well.
Lastly, speculationFromClassInfo was misused by AI. This patch
renames it to speculationFromClassInfoInheritance to better
reflect how AI was using it. The only other user of
speculationFromClassInfo was speculationFromStructure. Any case
where speculationFromClassInfoInteritance would differ from what a
Structure would tell you has been hoisted to
speculationFromStructure.
* assembler/testmasm.cpp:
(JSC::testBranchIfType):
(JSC::testBranchIfNotType):
* bytecode/SpeculatedType.cpp:
(JSC::speculationFromClassInfoInheritance):
(JSC::speculationFromStructure):
(JSC::speculationFromClassInfo): Deleted.
* bytecode/SpeculatedType.h:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGAbstractValue.cpp:
(JSC::DFG::AbstractValue::filterClassInfo):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleDOMJITGetter):
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::attemptToMakeCallDOM):
(JSC::DFG::FixupPhase::fixupCheckJSCast):
(JSC::DFG::FixupPhase::fixupCheckSubClass): Deleted.
* dfg/DFGNode.h:
(JSC::DFG::Node::hasClassInfo const):
* dfg/DFGNodeType.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::checkArray):
(JSC::DFG::SpeculativeJIT::compileCheckJSCast):
(JSC::DFG::SpeculativeJIT::compileCheckSubClass): Deleted.
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileCheckJSCast):
(JSC::FTL::DFG::LowerDFGToB3::isCellWithType):
(JSC::FTL::DFG::LowerDFGToB3::isTypedArrayView):
(JSC::FTL::DFG::LowerDFGToB3::compileCheckSubClass): Deleted.
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::branchIfType):
(JSC::AssemblyHelpers::branchIfNotType):
* runtime/ClassInfo.h:
* runtime/JSCast.h:
(JSC::JSTypeRange::contains const):
(JSC::JSCastingHelpers::inheritsJSTypeImpl):
* runtime/JSFunction.cpp:
(JSC::JSFunction::assertTypeInfoFlagInvariants):
* tools/JSDollarVM.cpp:
(JSC::functionCreateDOMJITCheckJSCastObject):
(JSC::JSDollarVM::finishCreation):
(JSC::functionCreateDOMJITCheckSubClassObject): Deleted.
2020-05-27 Darin Adler <darin@apple.com>
[Cocoa] Pass all defines from Platform.h to various scripts, not just the ones from .xcconfig
https://bugs.webkit.org/show_bug.cgi?id=212451
Reviewed by Sam Weinig.
* DerivedSources.make: Run the preprocessor on Platform.h and parse the output into
FEATURE_AND_PLATFORM_DEFINES. Use that and FEATURE_AND_PLATFORM_DEFINE_DEPENDENCIES
whenever we need a list of defines. Also took out some Windows-specific stuff since
this is now only used on Mac platforms.
2020-05-28 Michael Catanzaro <mcatanzaro@gnome.org>
Web Inspector: generate_cpp_protocol_types_header.py:294: SyntaxWarning: "is" with a literal. Did you mean "=="?
https://bugs.webkit.org/show_bug.cgi?id=212468
Reviewed by Timothy Hatcher.
Use "==" instead of "is" to compare against 0.
* inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
2020-05-28 Mark Lam <mark.lam@apple.com>
Gardening: Add an assertNoException() to placate the exception checker and green the bots.
https://bugs.webkit.org/show_bug.cgi?id=212248
Not reviewed.
This solution was pointed out by Caio Lima in https://bugs.webkit.org/show_bug.cgi?id=212248#c10.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
2020-05-27 Saam Barati <sbarati@apple.com>
hasOwnProperty inside structure property for-in loop should use an opcode like has_structure_property but for hasOwnProperty
https://bugs.webkit.org/show_bug.cgi?id=212248
Reviewed by Keith Miller.
This patch applies the same principles from r262083 but to hasOwnProperty.
In this patch, we have a fast path for this syntactic pattern when
iterating structure properties:
for (let <p> in <o>)
if (<o>.hasOwnProperty(<p>))
We look for both <p> and <o> as resolve nodes, and we look for them being the
same values both in the header and inside the body.
Using a simple static analysis, when we detect this pattern, we compare the
result of `<o>.hasOwnProperty` to the original hasOwnProperty function. If
it's the same, we execute the fast path new bytecode has_own_structure_property,
which on the fast path is two loads, a compare and branch, and a materialization of
the boolean constant true.
On the slow path, has_own_structure_property just executes the runtime code
for hasOwnProperty.
In my testing, this seems like it might be 3-5% faster on Speedometer 2's
react subtests. I was getting some noise when running the tests locally,
so I can't say for certain it's a definite speedup. But the data implies
it has a good chance at being a speedup.
* builtins/BuiltinNames.h:
* bytecode/BytecodeList.rb:
* bytecode/BytecodeUseDef.cpp:
(JSC::computeUsesForBytecodeIndexImpl):
(JSC::computeDefsForBytecodeIndexImpl):
* bytecode/LinkTimeConstant.h:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitWideJumpIfNotFunctionHasOwnProperty):
(JSC::BytecodeGenerator::recordHasOwnStructurePropertyInForInLoop):
(JSC::BytecodeGenerator::emitHasOwnStructureProperty):
(JSC::BytecodeGenerator::pushStructureForInScope):
(JSC::StructureForInContext::finalize):
(JSC::BytecodeGenerator::findStructureForInContext):
* bytecompiler/BytecodeGenerator.h:
(JSC::StructureForInContext::StructureForInContext):
(JSC::StructureForInContext::base const):
(JSC::StructureForInContext::addHasOwnPropertyJump):
* bytecompiler/Label.h:
(JSC::GenericBoundLabel::GenericBoundLabel):
* bytecompiler/NodesCodegen.cpp:
(JSC::HasOwnPropertyFunctionCallDotNode::emitBytecode):
(JSC::ForInNode::emitBytecode):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileHasStructureProperty):
(JSC::DFG::SpeculativeJIT::compileHasOwnStructurePropertyImpl):
(JSC::DFG::SpeculativeJIT::compileHasOwnStructureProperty):
(JSC::DFG::SpeculativeJIT::compileInStructureProperty):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileHasOwnStructureProperty):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
* jit/JIT.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_has_structure_propertyImpl):
(JSC::JIT::emit_op_has_structure_property):
(JSC::JIT::emit_op_has_own_structure_property):
(JSC::JIT::emit_op_in_structure_property):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_has_structure_propertyImpl):
(JSC::JIT::emit_op_has_structure_property):
(JSC::JIT::emit_op_has_own_structure_property):
(JSC::JIT::emit_op_in_structure_property):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter64.asm:
* parser/ASTBuilder.h:
(JSC::ASTBuilder::makeFunctionCallNode):
* parser/NodeConstructors.h:
(JSC::HasOwnPropertyFunctionCallDotNode::HasOwnPropertyFunctionCallDotNode):
* parser/Nodes.h:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/ObjectPrototype.cpp:
(JSC::objectPrototypeHasOwnProperty):
(JSC::objectProtoFuncHasOwnProperty):
* runtime/ObjectPrototype.h:
2020-05-27 Yusuke Suzuki <ysuzuki@apple.com>
[ macOS iOS ] REGRESSION(r261600?): imported/w3c/web-platform-tests/html/dom/reflection-embedded.html & imported/w3c/web-platform-tests/html/dom/reflection-forms.html are flaky failures
https://bugs.webkit.org/show_bug.cgi?id=212430
Reviewed by Saam Barati.
r261600 added IsConstructor rule to DFG AI. That rule is saying that if the object is not JSFunction and not ProxyObject,
then it must not be a constructor. But this is wrong since any objects can implement getConstructData and DOM constructors
are actually implementing it while it is not JSFunction and it is not ProxyObject. This patch removes that rule.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* tools/JSDollarVM.cpp:
2020-05-27 Saam Barati <sbarati@apple.com>
Limit memory used by wasm/references/multitable.js on memory limited devices
https://bugs.webkit.org/show_bug.cgi?id=212437
Reviewed by Keith Miller.
* tools/JSDollarVM.cpp:
(JSC::functionIsMemoryLimited):
(JSC::JSDollarVM::finishCreation):
2020-05-27 David Kilzer <ddkilzer@apple.com>
REGRESSION: Build errors during JavaScriptCore "Generate Derived Sources" about missing Availability.h header and invalid SDKROOT [-Wmissing-sysroot]
<https://webkit.org/b/212436>
Unreviewed build fix.
* Scripts/generate-derived-sources.sh: Pass SDKROOT to `make`
command from the current environment.
2020-05-27 Mark Lam <mark.lam@apple.com>
Add missing #include for when LLINT_TRACING is enabled.
https://bugs.webkit.org/show_bug.cgi?id=212433
Reviewed by Tadeu Zagallo.
* llint/LLIntExceptions.cpp:
2020-05-27 Devin Rousso <drousso@apple.com>
Web Inspector: replace `featureGuard` and `availability` with a combined `condition` that accepts any macro
https://bugs.webkit.org/show_bug.cgi?id=210014
Reviewed by Brian Burg.
Previously, the generated InspectorBackendCommands.js would include code for things that the
backend doesn't actually support. By using actual macros and preprocessing that file, we can
ensure that the frontend doesn't incorrectly think that something is supported by the page
being inspected:
- the `Canvas` commands and events related to shader programs/pipelines should only exist
when the corresponding context type exists, namely `ENABLE(WEBGL)` and `ENABLE(WEBGPU)`.
- iOS doesn't support showing rulers, so create a variant of `DOM.setInspectModeEnabled`
that only exists for `PLATFORM(IOS_FAMILY)` that doesn't have the `showRulers` optional
parameter, as well as removing `Page.setShowRulers` entirely.
- setting the forced appearance should only be possible if dark mode is supported.
- web archives only exist if CF is used.
* inspector/protocol/CPUProfiler.json:
* inspector/protocol/Canvas.json:
* inspector/protocol/DOM.json:
* inspector/protocol/IndexedDB.json:
* inspector/protocol/Inspector.json:
* inspector/protocol/Memory.json:
* inspector/protocol/Page.json:
* inspector/protocol/ServiceWorker.json:
* Scripts/generate-derived-sources.sh:
Set `CC` if it hasn't already been set.
* DerivedSources.make:
* DerivedSources-input.xcfilelist:
Preprocess `InspectorBackendCommands.js.in` to get an accurate `InspectorBackendCommands.js`
that follows the logic/description above.
* CMakeLists.txt:
Create a new `InspectorBackendCommands` target now that `InspectorBackendCommands.js` is
generated seprately from the rest of the protocol files.
* Configurations/FeatureDefines.xcconfig:
Add `ENABLE_WEB_ARCHIVE` since it's always enabled in wtf/PlatformEnableCocoa.h.
* inspector/scripts/generate-inspector-protocol-bindings.py:
(generate_from_specification):
(generate_from_specification.load_specification):
* inspector/scripts/codegen/generator.py:
(Generator.__init__):
(Generator.model):
(Generator.set_generator_setting):
(Generator.type_declarations_for_domain):
(Generator.commands_for_domain):
(Generator.events_for_domain):
(Generator.wrap_with_guard_for_condition): Added.
(Generator.platform): Deleted.
(Generator.can_generate_platform): Deleted.
(Generator.wrap_with_guard_for_domain): Deleted.
(Generator.wrap_with_guard): Deleted.
* inspector/scripts/codegen/models.py:
(Frameworks):
(Protocol.parse_domain):
(Protocol.parse_type_declaration):
(Protocol.parse_command):
(Protocol.parse_event):
(Domain.__init__):
(TypeDeclaration.__init__):
(Command.__init__):
(Event.__init__):
(Platform): Deleted.
(Platform.__init__): Deleted.
(Platform.fromString): Deleted.
(Platforms): Deleted.
(Platforms.__metaclass__): Deleted.
(Platforms.__metaclass__.__iter__): Deleted.
* inspector/scripts/codegen/generator_templates.py:
Remove `platform` as it is handled by `condition`.
* inspector/scripts/codegen/preprocess.pl: Copied from Source/WebCore/bindings/scripts/preprocessor.pm.
* inspector/scripts/codegen/generate_js_backend_commands.py:
(JSBackendCommandsGenerator.output_filename):
(JSBackendCommandsGenerator.generate_domain):
Output to `InspectorBackendCommands.js.in` that includes `#if` for preprocessing.
* inspector/scripts/codegen/cpp_generator_templates.py:
* inspector/scripts/codegen/generate_cpp_alternate_backend_dispatcher_header.py:
(CppAlternateBackendDispatcherHeaderGenerator.generate_output):
(CppAlternateBackendDispatcherHeaderGenerator._generate_handler_declarations_for_domain):
(CppAlternateBackendDispatcherHeaderGenerator._generate_handler_declaration_for_command):
* inspector/scripts/codegen/generate_cpp_backend_dispatcher_header.py:
(CppBackendDispatcherHeaderGenerator._generate_alternate_handler_forward_declarations_for_domains.Alternate):
(CppBackendDispatcherHeaderGenerator._generate_handler_declarations_for_domain):
(CppBackendDispatcherHeaderGenerator._generate_handler_declaration_for_command):
(CppBackendDispatcherHeaderGenerator._generate_async_handler_declaration_for_command):
(CppBackendDispatcherHeaderGenerator._generate_dispatcher_declarations_for_domain):
(CppBackendDispatcherHeaderGenerator._generate_dispatcher_declaration_for_command):
* inspector/scripts/codegen/generate_cpp_backend_dispatcher_implementation.py:
(CppBackendDispatcherImplementationGenerator.generate_output):
(CppBackendDispatcherImplementationGenerator._generate_handler_class_destructor_for_domain):
(CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementations_for_domain):
(CppBackendDispatcherImplementationGenerator._generate_small_dispatcher_switch_implementation_for_domain):
(CppBackendDispatcherImplementationGenerator._generate_large_dispatcher_switch_implementation_for_domain):
(CppBackendDispatcherImplementationGenerator._generate_async_dispatcher_class_for_domain):
(CppBackendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_command):
* inspector/scripts/codegen/generate_cpp_frontend_dispatcher_header.py:
(CppFrontendDispatcherHeaderGenerator._generate_dispatcher_declarations_for_domain):
(CppFrontendDispatcherHeaderGenerator._generate_dispatcher_declaration_for_event):
* inspector/scripts/codegen/generate_cpp_frontend_dispatcher_implementation.py:
(CppFrontendDispatcherImplementationGenerator._generate_dispatcher_implementations_for_domain):
(CppFrontendDispatcherImplementationGenerator._generate_dispatcher_implementation_for_event):
* inspector/scripts/codegen/generate_cpp_protocol_types_header.py:
(CppProtocolTypesHeaderGenerator._generate_versions):
* inspector/scripts/codegen/generate_cpp_protocol_types_implementation.py:
(CppProtocolTypesImplementationGenerator._generate_enum_conversion_methods_for_domain.generate_conversion_method_body):
(CppProtocolTypesImplementationGenerator._generate_enum_conversion_methods_for_domain):
(CppProtocolTypesImplementationGenerator._generate_open_field_names):
(CppProtocolTypesImplementationGenerator._generate_builders_for_domain):
* inspector/scripts/codegen/objc_generator_templates.py:
* inspector/scripts/codegen/generate_objc_backend_dispatcher_header.py:
(ObjCBackendDispatcherHeaderGenerator._generate_objc_handler_declarations_for_domain):
(ObjCBackendDispatcherHeaderGenerator._generate_objc_handler_declaration_for_command):
* inspector/scripts/codegen/generate_objc_backend_dispatcher_implementation.py:
(ObjCBackendDispatcherImplementationGenerator._generate_handler_implementation_for_domain):
(ObjCBackendDispatcherImplementationGenerator._generate_handler_implementation_for_command):
* inspector/scripts/codegen/generate_objc_header.py:
(add_newline):
(ObjCHeaderGenerator.generate_output):
(ObjCHeaderGenerator._generate_forward_declarations):
(ObjCHeaderGenerator._generate_enums):
(ObjCHeaderGenerator._generate_types):
(ObjCHeaderGenerator._generate_type_interface):
(ObjCHeaderGenerator._generate_command_protocols):
(ObjCHeaderGenerator._generate_single_command_protocol):
(ObjCHeaderGenerator._generate_event_interfaces):
(ObjCHeaderGenerator._generate_single_event_interface):
(ObjCHeaderGenerator._generate_enum_for_platforms): Deleted.
* inspector/scripts/codegen/generate_objc_protocol_type_conversions_header.py:
(add_newline):
(ObjCProtocolTypeConversionsHeaderGenerator.generate_output):
(ObjCProtocolTypeConversionsHeaderGenerator._generate_enum_conversion_functions):
(ObjCProtocolTypeConversionsHeaderGenerator._generate_enum_conversion_for_platforms): Deleted.
* inspector/scripts/codegen/generate_objc_protocol_type_conversions_implementation.py:
(add_newline):
(ObjCProtocolTypeConversionsImplementationGenerator._generate_type_factory_category_interface):
(ObjCProtocolTypeConversionsImplementationGenerator._generate_type_factory_method_declaration):
(ObjCProtocolTypeConversionsImplementationGenerator._generate_type_factory_category_implementation):
(ObjCProtocolTypeConversionsImplementationGenerator._generate_type_factory_method_implementation):
* inspector/scripts/codegen/generate_objc_protocol_types_implementation.py:
(add_newline):
(ObjCProtocolTypesImplementationGenerator.generate_type_implementations):
(ObjCProtocolTypesImplementationGenerator.generate_type_implementation):
Wrap each domain, type, command, and event with the associated `condition` (if it exists).
* inspector/scripts/tests/command-targetType-matching-domain-debuggableType.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/command-targetType-matching-domain-debuggableType.json.
* inspector/scripts/tests/commands-with-async-attribute.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/commands-with-async-attribute.json.
* inspector/scripts/tests/commands-with-optional-call-return-parameters.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/commands-with-optional-call-return-parameters.json.
* inspector/scripts/tests/definitions-with-mac-platform.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/mac/definitions-with-mac-platform.json.
* inspector/scripts/tests/domain-debuggableTypes.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/domain-debuggableTypes.json.
* inspector/scripts/tests/domain-targetType-matching-domain-debuggableType.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/domain-targetType-matching-domain-debuggableType.json.
* inspector/scripts/tests/domain-targetTypes.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/domain-targetTypes.json.
* inspector/scripts/tests/domains-with-varying-command-sizes.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/domains-with-varying-command-sizes.json.
* inspector/scripts/tests/enum-values.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/enum-values.json.
* inspector/scripts/tests/event-targetType-matching-domain-debuggableType.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/event-targetType-matching-domain-debuggableType.json.
* inspector/scripts/tests/events-with-optional-parameters.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/events-with-optional-parameters.json.
* inspector/scripts/tests/expected/command-targetType-matching-domain-debuggableType.json-result: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/command-targetType-matching-domain-debuggableType.json-result.
* inspector/scripts/tests/expected/commands-with-async-attribute.json-result: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/commands-with-async-attribute.json-result.
* inspector/scripts/tests/expected/commands-with-optional-call-return-parameters.json-result: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/commands-with-optional-call-return-parameters.json-result.
* inspector/scripts/tests/expected/definitions-with-mac-platform.json-result: Renamed from Source/JavaScriptCore/inspector/scripts/tests/mac/expected/definitions-with-mac-platform.json-result.
* inspector/scripts/tests/expected/domain-debuggableTypes.json-result: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/domain-debuggableTypes.json-result.
* inspector/scripts/tests/expected/domain-targetType-matching-domain-debuggableType.json-result: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/domain-targetType-matching-domain-debuggableType.json-result.
* inspector/scripts/tests/expected/domain-targetTypes.json-result: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/domain-targetTypes.json-result.
* inspector/scripts/tests/expected/domains-with-varying-command-sizes.json-result: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/domains-with-varying-command-sizes.json-result.
* inspector/scripts/tests/expected/enum-values.json-result: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/enum-values.json-result.
* inspector/scripts/tests/expected/event-targetType-matching-domain-debuggableType.json-result: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/event-targetType-matching-domain-debuggableType.json-result.
* inspector/scripts/tests/expected/events-with-optional-parameters.json-result: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/events-with-optional-parameters.json-result.
* inspector/scripts/tests/expected/fail-on-command-targetType-matching-domain-debuggableType.json-error: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/fail-on-command-targetType-matching-domain-debuggableType.json-error.
* inspector/scripts/tests/expected/fail-on-command-targetTypes-type.json-error: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/fail-on-command-targetTypes-type.json-error.
* inspector/scripts/tests/expected/fail-on-command-targetTypes-value.json-error: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/fail-on-command-targetTypes-value.json-error.
* inspector/scripts/tests/expected/fail-on-domain-debuggableTypes-type.json-error: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/fail-on-domain-debuggableTypes-type.json-error.
* inspector/scripts/tests/expected/fail-on-domain-debuggableTypes-value.json-error: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/fail-on-domain-debuggableTypes-value.json-error.
* inspector/scripts/tests/expected/fail-on-domain-targetType-matching-domain-debuggableType.json-error: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/fail-on-domain-targetType-matching-domain-debuggableType.json-error.
* inspector/scripts/tests/expected/fail-on-domain-targetTypes-type.json-error: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/fail-on-domain-targetTypes-type.json-error.
* inspector/scripts/tests/expected/fail-on-domain-targetTypes-value.json-error: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/fail-on-domain-targetTypes-value.json-error.
* inspector/scripts/tests/expected/fail-on-duplicate-command-call-parameter-names.json-error: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/fail-on-duplicate-command-call-parameter-names.json-error.
* inspector/scripts/tests/expected/fail-on-duplicate-command-return-parameter-names.json-error: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/fail-on-duplicate-command-return-parameter-names.json-error.
* inspector/scripts/tests/expected/fail-on-duplicate-event-parameter-names.json-error: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/fail-on-duplicate-event-parameter-names.json-error.
* inspector/scripts/tests/expected/fail-on-duplicate-type-declarations.json-error: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/fail-on-duplicate-type-declarations.json-error.
* inspector/scripts/tests/expected/fail-on-duplicate-type-member-names.json-error: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/fail-on-duplicate-type-member-names.json-error.
* inspector/scripts/tests/expected/fail-on-enum-with-no-values.json-error: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/fail-on-enum-with-no-values.json-error.
* inspector/scripts/tests/expected/fail-on-event-targetType-matching-domain-debuggableType.json-error: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/fail-on-event-targetType-matching-domain-debuggableType.json-error.
* inspector/scripts/tests/expected/fail-on-event-targetTypes-type.json-error: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/fail-on-event-targetTypes-type.json-error.
* inspector/scripts/tests/expected/fail-on-event-targetTypes-value.json-error: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/fail-on-event-targetTypes-value.json-error.
* inspector/scripts/tests/expected/fail-on-number-typed-optional-parameter-flag.json-error: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/fail-on-number-typed-optional-parameter-flag.json-error.
* inspector/scripts/tests/expected/fail-on-number-typed-optional-type-member.json-error: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/fail-on-number-typed-optional-type-member.json-error.
* inspector/scripts/tests/expected/fail-on-string-typed-optional-parameter-flag.json-error: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/fail-on-string-typed-optional-parameter-flag.json-error.
* inspector/scripts/tests/expected/fail-on-string-typed-optional-type-member.json-error: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/fail-on-string-typed-optional-type-member.json-error.
* inspector/scripts/tests/expected/fail-on-type-declaration-using-type-reference.json-error: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/fail-on-type-declaration-using-type-reference.json-error.
* inspector/scripts/tests/expected/fail-on-type-reference-as-primitive-type.json-error: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/fail-on-type-reference-as-primitive-type.json-error.
* inspector/scripts/tests/expected/fail-on-type-with-lowercase-name.json-error: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/fail-on-type-with-lowercase-name.json-error.
* inspector/scripts/tests/expected/fail-on-unknown-type-reference-in-type-declaration.json-error: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/fail-on-unknown-type-reference-in-type-declaration.json-error.
* inspector/scripts/tests/expected/fail-on-unknown-type-reference-in-type-member.json-error: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/fail-on-unknown-type-reference-in-type-member.json-error.
* inspector/scripts/tests/expected/generate-domains-with-feature-guards.json-result: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/generate-domains-with-feature-guards.json-result.
* inspector/scripts/tests/expected/same-type-id-different-domain.json-result: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/same-type-id-different-domain.json-result.
* inspector/scripts/tests/expected/shadowed-optional-type-setters.json-result: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/shadowed-optional-type-setters.json-result.
* inspector/scripts/tests/expected/should-strip-comments.json-result: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/should-strip-comments.json-result.
* inspector/scripts/tests/expected/type-declaration-aliased-primitive-type.json-result: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/type-declaration-aliased-primitive-type.json-result.
* inspector/scripts/tests/expected/type-declaration-array-type.json-result: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/type-declaration-array-type.json-result.
* inspector/scripts/tests/expected/type-declaration-enum-type.json-result: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/type-declaration-enum-type.json-result.
* inspector/scripts/tests/expected/type-declaration-object-type.json-result: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/type-declaration-object-type.json-result.
* inspector/scripts/tests/expected/type-requiring-runtime-casts.json-result: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/type-requiring-runtime-casts.json-result.
* inspector/scripts/tests/expected/type-with-open-parameters.json-result: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/type-with-open-parameters.json-result.
* inspector/scripts/tests/expected/version.json-result: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/expected/version.json-result.
* inspector/scripts/tests/fail-on-command-targetType-matching-domain-debuggableType.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/fail-on-command-targetType-matching-domain-debuggableType.json.
* inspector/scripts/tests/fail-on-command-targetTypes-type.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/fail-on-command-targetTypes-type.json.
* inspector/scripts/tests/fail-on-command-targetTypes-value.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/fail-on-command-targetTypes-value.json.
* inspector/scripts/tests/fail-on-domain-debuggableTypes-type.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/fail-on-domain-debuggableTypes-type.json.
* inspector/scripts/tests/fail-on-domain-debuggableTypes-value.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/fail-on-domain-debuggableTypes-value.json.
* inspector/scripts/tests/fail-on-domain-targetType-matching-domain-debuggableType.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/fail-on-domain-targetType-matching-domain-debuggableType.json.
* inspector/scripts/tests/fail-on-domain-targetTypes-type.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/fail-on-domain-targetTypes-type.json.
* inspector/scripts/tests/fail-on-domain-targetTypes-value.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/fail-on-domain-targetTypes-value.json.
* inspector/scripts/tests/fail-on-duplicate-command-call-parameter-names.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/fail-on-duplicate-command-call-parameter-names.json.
* inspector/scripts/tests/fail-on-duplicate-command-return-parameter-names.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/fail-on-duplicate-command-return-parameter-names.json.
* inspector/scripts/tests/fail-on-duplicate-event-parameter-names.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/fail-on-duplicate-event-parameter-names.json.
* inspector/scripts/tests/fail-on-duplicate-type-declarations.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/fail-on-duplicate-type-declarations.json.
* inspector/scripts/tests/fail-on-duplicate-type-member-names.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/fail-on-duplicate-type-member-names.json.
* inspector/scripts/tests/fail-on-enum-with-no-values.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/fail-on-enum-with-no-values.json.
* inspector/scripts/tests/fail-on-event-targetType-matching-domain-debuggableType.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/fail-on-event-targetType-matching-domain-debuggableType.json.
* inspector/scripts/tests/fail-on-event-targetTypes-type.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/fail-on-event-targetTypes-type.json.
* inspector/scripts/tests/fail-on-event-targetTypes-value.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/fail-on-event-targetTypes-value.json.
* inspector/scripts/tests/fail-on-number-typed-optional-parameter-flag.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/fail-on-number-typed-optional-parameter-flag.json.
* inspector/scripts/tests/fail-on-number-typed-optional-type-member.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/fail-on-number-typed-optional-type-member.json.
* inspector/scripts/tests/fail-on-string-typed-optional-parameter-flag.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/fail-on-string-typed-optional-parameter-flag.json.
* inspector/scripts/tests/fail-on-string-typed-optional-type-member.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/fail-on-string-typed-optional-type-member.json.
* inspector/scripts/tests/fail-on-type-declaration-using-type-reference.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/fail-on-type-declaration-using-type-reference.json.
* inspector/scripts/tests/fail-on-type-reference-as-primitive-type.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/fail-on-type-reference-as-primitive-type.json.
* inspector/scripts/tests/fail-on-type-with-lowercase-name.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/fail-on-type-with-lowercase-name.json.
* inspector/scripts/tests/fail-on-unknown-type-reference-in-type-declaration.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/fail-on-unknown-type-reference-in-type-declaration.json.
* inspector/scripts/tests/fail-on-unknown-type-reference-in-type-member.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/fail-on-unknown-type-reference-in-type-member.json.
* inspector/scripts/tests/generate-domains-with-feature-guards.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/generate-domains-with-feature-guards.json.
* inspector/scripts/tests/same-type-id-different-domain.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/same-type-id-different-domain.json.
* inspector/scripts/tests/shadowed-optional-type-setters.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/shadowed-optional-type-setters.json.
* inspector/scripts/tests/should-strip-comments.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/should-strip-comments.json.
* inspector/scripts/tests/type-declaration-aliased-primitive-type.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/type-declaration-aliased-primitive-type.json.
* inspector/scripts/tests/type-declaration-array-type.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/type-declaration-array-type.json.
* inspector/scripts/tests/type-declaration-enum-type.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/type-declaration-enum-type.json.
* inspector/scripts/tests/type-declaration-object-type.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/type-declaration-object-type.json.
* inspector/scripts/tests/type-requiring-runtime-casts.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/type-requiring-runtime-casts.json.
* inspector/scripts/tests/type-with-open-parameters.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/type-with-open-parameters.json.
* inspector/scripts/tests/version.json: Renamed from Source/JavaScriptCore/inspector/scripts/tests/generic/version.json.
* inspector/scripts/tests/generic/definitions-with-mac-platform.json: Removed.
* inspector/scripts/tests/generic/expected/definitions-with-mac-platform.json-result: Removed.
* inspector/scripts/tests/generic/fail-on-command-with-invalid-platform.json: Removed.
* inspector/scripts/tests/generic/expected/fail-on-command-with-invalid-platform.json-error: Removed.
* inspector/scripts/tests/generic/fail-on-type-with-invalid-platform.json: Removed.
* inspector/scripts/tests/generic/expected/fail-on-type-with-invalid-platform.json-error: Removed.
* inspector/scripts/tests/ios/definitions-with-mac-platform.json: Removed.
* inspector/scripts/tests/ios/expected/definitions-with-mac-platform.json-result: Removed.
* inspector/scripts/tests/all/definitions-with-mac-platform.json: Removed.
* inspector/scripts/tests/all/expected/definitions-with-mac-platform.json-result: Removed.
Don't separate the inspector generator tests by platform.
2020-05-27 Keith Miller <keith_miller@apple.com>
in_structure_property needs to handle constants on the RHS of the "in"
https://bugs.webkit.org/show_bug.cgi?id=212399
Reviewed by Saam Barati.
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
2020-05-27 Keith Rollin <krollin@apple.com>
Enable the use of XCBuild by default in Apple builds
https://bugs.webkit.org/show_bug.cgi?id=209890
<rdar://problem/44182078>
Unreviewed build fix. Check the value of XCODE_VERSION_ACTUAL rather
than XCODE_VERSION_MAJOR when determining whether to use the XCBuild
or non-XCBuild method of running header post-processing scripts.
* JavaScriptCore.xcodeproj/project.pbxproj:
2020-05-26 Mark Lam <mark.lam@apple.com>
Add some new emitters to the X86_64 and ARM64 MacroAssemblers.
https://bugs.webkit.org/show_bug.cgi?id=212385
Reviewed by Robin Morisset.
This patch adds these MacroAssembler emitters:
clearBit64
clearBits64WithMask
countTrailingZeros64WithoutNullCheck
clearBit64 clears a bit.
clearBits64WithMask does the equivalent of and64 with the 1's complement of the
provided mask.
countTrailingZeros64WithoutNullCheck does the same thing as countTrailingZeros64,
except that it assumes that the word in the register it is processing will never
be null, and therefore skips the null check. This is useful in code generation
that already does a null check ahead of time. So, there's no need to do a
redundant null check.
Also added testmasm tests for these emitters.
* assembler/AbortReason.h:
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::clearBit64):
(JSC::MacroAssemblerARM64::clearBits64WithMask):
(JSC::MacroAssemblerARM64::countTrailingZeros64WithoutNullCheck):
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::countTrailingZeros64WithoutNullCheck):
(JSC::MacroAssemblerX86_64::clearBit64):
(JSC::MacroAssemblerX86_64::clearBits64WithMask):
* assembler/X86Assembler.h:
(JSC::X86Assembler::btrq_rr):
* assembler/testmasm.cpp:
(JSC::testClearBit64):
(JSC::testClearBits64WithMask):
(JSC::testClearBits64WithMaskTernary):
(JSC::testCountTrailingZeros64Impl):
(JSC::testCountTrailingZeros64):
(JSC::testCountTrailingZeros64WithoutNullCheck):
(JSC::run):
2020-05-26 Yoshiaki JITSUKAWA <yoshiaki.jitsukawa@sony.com>
[PlayStation] Enable RemoteWebInspector
https://bugs.webkit.org/show_bug.cgi?id=212312
Reviewed by Don Olmstead.
* API/JSRemoteInspectorServer.cpp:
Fix compile error.
* PlatformPlayStation.cmake:
Add JSRemoteInspectorServer.h to the public header list.
* inspector/remote/socket/posix/RemoteInspectorSocketPOSIX.cpp:
Set PlayStation specific socket option.
2020-05-26 Alexey Shvayka <shvaikalesh@gmail.com>
IteratorClose should suppress GetMethod errors
https://bugs.webkit.org/show_bug.cgi?id=212378
Reviewed by Keith Miller.
This patch implements recent spec change [1] that prevents "return" method lookup error
from overriding outer exception, aligning JSC with V8 and SpiderMonkey.
It is accomplished by moving pushTry() before emitGetById() in BytecodeGenerator.cpp
(covered by test262 suite) and removal of RETURN_IF_EXCEPTION in IteratorOperations.cpp
(added a stress test).
Before this patch, JSC partly implemented the spec change [1] by suppressing TypeError
if "return" method of iterator was not callable.
BytecodeGenerator::emitDelegateYield() is intentionally left unchanged.
Also, this patch utilizes emitIteratorGenericClose() to avoid code duplication.
for/of microbenchmarks are neutral.
[1]: https://github.com/tc39/ecma262/pull/1408
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitGenericEnumeration):
(JSC::BytecodeGenerator::emitEnumeration):
* runtime/IteratorOperations.cpp:
(JSC::iteratorClose):
2020-05-26 Mark Lam <mark.lam@apple.com>
SamplingProfiler::takeSample() should not assume that ENABLE(WEBASSEMBLY) means Wasm is enabled.
https://bugs.webkit.org/show_bug.cgi?id=212382
Reviewed by Saam Barati.
Wasm can still be disabled at runtime with JSC options. Fixing this will allow
sampling profiler tests to run with JSC_useJIT=0 without crashing.
* runtime/SamplingProfiler.cpp:
(JSC::FrameWalker::FrameWalker):
(JSC::FrameWalker::recordJITFrame):
(JSC::CFrameWalker::CFrameWalker):
(JSC::SamplingProfiler::takeSample):
2020-05-26 Keith Rollin <krollin@apple.com>
Enable the use of XCBuild by default in Apple builds
https://bugs.webkit.org/show_bug.cgi?id=209890
<rdar://problem/44182078>
Reviewed by Darin Adler.
Switch from the "legacy" Xcode build system to the "new" build system
(also known as "XCBuild"). Switching to the new system speeds up
builds by a small percentage, better validates projects for
build-related issues (such as dependency cycles), lets WebKit benefit
from future improvements in XCBuild such as those coming from the
underlying llbuild open source project, and prepares us for any other
tools built for this new ecosystem.
Specific changes:
- Remove Xcode project and workspace settings that selected the Build
system, allowing the default to take hold (which is currently the
New build system).
- Updated webkitdirs.pm with a terser check for Xcode version.
- Update build-webkit and Makefile.shared to be explicit when using
the old build system (no longer treat it as a default or fall-back
configuration).
- Update various xcconfig files similarly to treat the default as
using the new build system.
- Update various post-processing build steps to check for Xcode 11.4
and to no longer treat the default as using the old build system.
* Configurations/JavaScriptCore.xcconfig:
* JavaScriptCore.xcodeproj/project.pbxproj:
2020-05-23 Paulo Matos <pmatos@igalia.com>
Fix non-unified builds for x86_64
https://bugs.webkit.org/show_bug.cgi?id=212297
Reviewed by Adrian Perez de Castro.
* b3/B3BasicBlock.cpp:
* b3/B3CaseCollection.cpp:
* b3/B3DuplicateTails.cpp:
* b3/B3EnsureLoopPreHeaders.cpp:
* b3/B3FenceValue.cpp:
* b3/B3HoistLoopInvariantValues.cpp:
* b3/B3LegalizeMemoryOffsets.cpp:
* b3/B3LowerMacrosAfterOptimizations.cpp:
* b3/B3LowerToAir.cpp:
* b3/B3MathExtras.cpp:
* b3/B3MemoryValue.cpp:
* b3/B3Procedure.cpp:
* b3/B3StackmapValue.cpp:
* b3/B3SwitchValue.cpp:
* b3/B3UseCounts.cpp:
* b3/B3Validate.cpp:
* b3/B3VariableValue.cpp:
* b3/B3WasmAddressValue.cpp:
* b3/B3WasmBoundsCheckValue.cpp:
* ftl/FTLCommonValues.cpp:
* ftl/FTLCompile.cpp:
* ftl/FTLOSREntry.cpp:
* ftl/FTLOSRExitCompiler.cpp:
* wasm/WasmInstance.cpp:
* wasm/WasmStreamingParser.cpp:
* wasm/js/JSToWasm.cpp:
* wasm/js/JSToWasmICCallee.cpp:
* wasm/js/JSWebAssembly.cpp:
* wasm/js/JSWebAssemblyCodeBlock.cpp:
* wasm/js/WebAssemblyCompileErrorConstructor.cpp:
* wasm/js/WebAssemblyCompileErrorPrototype.cpp:
* wasm/js/WebAssemblyFunction.cpp:
* wasm/js/WebAssemblyFunctionBase.cpp:
* wasm/js/WebAssemblyGlobalPrototype.cpp:
* wasm/js/WebAssemblyInstanceConstructor.cpp:
* wasm/js/WebAssemblyInstancePrototype.cpp:
* wasm/js/WebAssemblyLinkErrorConstructor.cpp:
* wasm/js/WebAssemblyLinkErrorPrototype.cpp:
* wasm/js/WebAssemblyMemoryConstructor.cpp:
* wasm/js/WebAssemblyMemoryPrototype.cpp:
* wasm/js/WebAssemblyModuleConstructor.cpp:
* wasm/js/WebAssemblyModulePrototype.cpp:
* wasm/js/WebAssemblyModuleRecord.cpp:
* wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
* wasm/js/WebAssemblyRuntimeErrorPrototype.cpp:
* wasm/js/WebAssemblyTableConstructor.cpp:
* wasm/js/WebAssemblyTablePrototype.cpp:
2020-05-22 Yoshiaki JITSUKAWA <yoshiaki.jitsukawa@sony.com>
[PlayStation] Enable JSC shell to run
https://bugs.webkit.org/show_bug.cgi?id=212294
Reviewed by Ross Kirsling.
* shell/PlatformPlayStation.cmake:
Set working directory for Visual Studio
* shell/playstation/Initializer.cpp:
Load libJavaScriptCore as we now build it as SHARED.
2020-05-22 Alexey Shvayka <shvaikalesh@gmail.com>
Array.prototype.splice doesn't set "length" of returned object
https://bugs.webkit.org/show_bug.cgi?id=212285
Reviewed by Darin Adler.
This change implements step 12 of Array.prototype.splice [1], which is observable
if result object is not JSArray, aligning JSC with V8 and SpiderMonkey.
Only slow path of splice() is affected by this patch; zero-argument case already
performs setLength(). Microbenchmarks are neutral.
[1]: https://tc39.es/ecma262/#sec-array.prototype.splice
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncSplice):
2020-05-22 Saam Barati <sbarati@apple.com>
in_by_val inside structure property for-in loop should use an opcode like has_structure_property but for "in"
https://bugs.webkit.org/show_bug.cgi?id=212239
Reviewed by Tadeu Zagallo.
There is code inside Speedometer 2 that is like:
```
for (let p in o) {
if (p in o2)
...
}
```
Where o and o2 frequently share the same structure. Elm does this when it's
diffing two objects. We already optimize o2[p] (get_by_val) in the above loop
for structure properties. This patch adds that same optimization for in_by_val.
Because we already emit a "structure" loop for for-in, where we iterate structure
properties, the fast path for the above, where o and o2 have the same
structure is simply a structure check followed by return true.
This patch introduces the new opcode: op_in_structure_property. Its fast path is identical
to op_has_structure_property. Its slow path, however, behaves like "in", which
uses the HasProperty internal method, unlike op_has_structure_property,
which uses the GetOwnProperty internal method. This behavior difference is
observable using Proxy.
This a 5% perf improvement in the Elm subtest in Speedometer 2.
* bytecode/BytecodeList.rb:
* bytecode/BytecodeUseDef.cpp:
(JSC::computeUsesForBytecodeIndexImpl):
(JSC::computeDefsForBytecodeIndexImpl):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitInByVal):
(JSC::rewriteOp):
(JSC::StructureForInContext::finalize):
* bytecompiler/BytecodeGenerator.h:
(JSC::StructureForInContext::addInInst):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileInStructureProperty):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileHasStructurePropertyImpl):
(JSC::FTL::DFG::LowerDFGToB3::compileHasStructureProperty):
(JSC::FTL::DFG::LowerDFGToB3::compileInStructureProperty):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
* jit/JIT.h:
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_in_structure_property):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_in_structure_property):
* llint/LLIntOffsetsExtractor.cpp:
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter64.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
* runtime/JSObject.cpp:
(JSC::JSObject::hasPropertyGeneric const):
* runtime/JSPropertyNameEnumerator.h:
2020-05-22 Keith Miller <keith_miller@apple.com>
Checkpoint inlined call return handler needs an exception check when dispatching
https://bugs.webkit.org/show_bug.cgi?id=212104
Reviewed by Yusuke Suzuki.
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::dispatchToNextInstruction):
(JSC::LLInt::slow_path_checkpoint_osr_exit_from_inlined_call):
(JSC::LLInt::slow_path_checkpoint_osr_exit):
2020-05-22 Paulo Matos <pmatos@igalia.com>
Fix non-unified builds for i386 build
https://bugs.webkit.org/show_bug.cgi?id=212258
Reviewed by Adrian Perez de Castro.
* API/JSContextRef.cpp:
* bytecode/IntrinsicGetterAccessCase.cpp:
* inspector/InjectedScriptHost.cpp:
* llint/LLIntData.cpp:
* llint/LLIntThunks.cpp:
* runtime/Exception.cpp:
* runtime/ExecutableBase.cpp:
* runtime/JSBigInt.cpp:
* runtime/JSInternalPromiseConstructor.cpp:
* runtime/JSString.cpp:
* runtime/ScopedArgumentsTable.cpp:
* runtime/ScriptExecutable.cpp:
* runtime/SparseArrayValueMap.cpp:
* runtime/StructureRareData.cpp:
2020-05-22 Paulo Matos <pmatos@igalia.com>
Fix typo in JSCVirtualMachine documentation
Unreviewed Typo Fix.
* API/glib/JSCVirtualMachine.cpp:
2020-05-21 Robin Morisset <rmorisset@apple.com>
Various compile-time boolean flags could/should be marked constexpr
https://bugs.webkit.org/show_bug.cgi?id=212244
Reviewed by Mark Lam.
This trivial patch saves roughly 16kB from the JavaScriptCore binary in release mode.
* b3/B3OptimizeAssociativeExpressionTrees.cpp:
* b3/air/AirAllocateRegistersByGraphColoring.cpp:
* b3/air/AirSimplifyCFG.cpp:
(JSC::B3::Air::simplifyCFG):
* b3/air/AirTmpWidth.cpp:
(JSC::B3::Air::TmpWidth::recompute):
* dfg/DFGPredictionPropagationPhase.cpp:
* heap/GCIncomingRefCountedInlines.h:
(JSC::GCIncomingRefCounted<T>::filterIncomingReferences):
* heap/Heap.cpp:
(JSC::Heap::updateAllocationLimits):
* wasm/WasmEntryPlan.cpp:
2020-05-21 Robin Morisset <rmorisset@apple.com>
Remove AssemblerBufferWithConstantPool.h (as it has been dead for years)
https://bugs.webkit.org/show_bug.cgi?id=212241
Reviewed by Yusuke Suzuki.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/AssemblerBufferWithConstantPool.h: Removed.
2020-05-21 Alexey Shvayka <shvaikalesh@gmail.com>
Use @isUndefinedOrNull instead of abstract equality with null
https://bugs.webkit.org/show_bug.cgi?id=210954
Reviewed by Yusuke Suzuki.
This patch:
a) Replaces 2 `!== @undefined` comparisons in String.prototype.{replace,replaceAll}
with @isUndefinedOrNull() as per spec [1], aligning JSC with V8 and SpiderMonkey.
b) Replaces 3 `!= @undefined` and 7 `!= null` comparisons with @isUndefinedOrNull()
as only the latter is correct with [[IsHTMLDDA]] aka MasqueradesAsUndefined objects [2].
c) Removes @isDictionary() since it is unused, easy to inline and its name is quite
misleading: one might expect it to perform Structure::isDictionary().
[1]: https://tc39.es/ecma262/#sec-getmethod (step 3)
[2]: https://tc39.es/ecma262/#sec-IsHTMLDDA-internal-slot
* builtins/ArrayConstructor.js:
* builtins/GlobalOperations.js:
(globalPrivate.isDictionary): Deleted.
* builtins/RegExpPrototype.js:
(Symbol.split): Unobservable as there is `=== null` check in @regExpExec.
* builtins/StringPrototype.js:
(match):
(replace):
(replaceAll):
(search):
(split):
* builtins/TypedArrayConstructor.js:
2020-05-21 Saam Barati <sbarati@apple.com>
Add an option that exposes functions on the global object to turn on and off the sampling profiler and the super sampler
https://bugs.webkit.org/show_bug.cgi?id=212178
Reviewed by Yusuke Suzuki.
When profiling things like Speedometer inside the browser, it's important to
to only enable the super sampler and the sampling profiler around the code
that you want profiled. Otherwise, you will be profiling things that aren't
relevant to the benchmark score. This patch adds a new option, exposeProfilersOnGlobalObject,
which when true, will expose JS functions on the global object that allow
enabling/disabling the super sampler and the sampling profiler. This way,
we can change the Speedometer source code locally such that these profilers
are only sampling code accounted for in the benchmark score.
* bytecode/SuperSampler.cpp:
(JSC::initializeSuperSampler):
(JSC::enableSuperSampler):
(JSC::disableSuperSampler):
* bytecode/SuperSampler.h:
* jsc.cpp:
(jscmain):
* runtime/JSGlobalObject.cpp:
(JSC::enableSamplingProfiler):
(JSC::disableSamplingProfiler):
(JSC::enableSuperSampler):
(JSC::disableSuperSampler):
(JSC::JSGlobalObject::init):
* runtime/OptionsList.h:
2020-05-21 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Fix 32bit JSBigInt with INT32_MAX < x <= UINT32_MAX
https://bugs.webkit.org/show_bug.cgi?id=212193
Reviewed by Mark Lam.
In 32bit architecture, we are creating one-length JSBigInt for INT32_MIN <= x <= INT32_MAX, and two-length JSBigInt otherwise.
This is wrong since one-length JSBigInt should cover from -UINT32_MAX <= x <= UINT32_MAX.
This patch fixes the bug and cleans up createFrom(VM&, int64_t). And it also adds JSBigInt::createFrom(VM&, uint64_t) in preparation for [1]
Currently, this path is not used while it was used previously because BigIntConstructor starts using JSBigInt::createFrom(VM&, double). But this
will be used in [1], and simply the existing implementation is wrong.
[1]: https://bugs.webkit.org/show_bug.cgi?id=190800
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::createFromImpl):
(JSC::JSBigInt::createFrom):
* runtime/JSBigInt.h:
2020-05-21 Paulo Matos <pmatos@igalia.com>
Further non-unified build fixes
https://bugs.webkit.org/show_bug.cgi?id=212195
Reviewed by Adrian Perez de Castro.
* bytecode/InstanceOfStatus.cpp:
* heap/MarkedSpace.cpp:
* runtime/ObjectInitializationScope.cpp:
* runtime/ThrowScope.cpp:
2020-05-21 Alexey Shvayka <shvaikalesh@gmail.com>
Array.prototype.concat is incorrect with objects whose "length" exceeds 2 ** 32 - 1
https://bugs.webkit.org/show_bug.cgi?id=212167
Reviewed by Saam Barati.
This patch increases "length" limit of Array.prototype.concat result to @MAX_SAFE_INTEGER
and changes thrown error to TypeError, aligning JSC with the spec [1], V8, and SpiderMonkey.
Also, adds missing @MAX_SAFE_INTEGER overflow check in Array.from [2] (we implement similar
checks in other methods). SunSpider and microbenchmarks/concat-append-one.js are both neutral.
[1]: https://tc39.es/ecma262/#sec-array.prototype.concat (steps 5.c.iii, 5.d.ii)
[2]: https://tc39.es/ecma262/#sec-array.from (step 5.e.i)
* builtins/ArrayConstructor.js:
(from):
* builtins/ArrayPrototype.js:
(globalPrivate.concatSlowPath):
2020-05-20 Michael Saboff <msaboff@apple.com>
[Wasm] Limit the size of Wasm function we optimize in OMG mode
https://bugs.webkit.org/show_bug.cgi?id=212105
Reviewed by Filip Pizlo.
Given that memory grows O(N^2) compiling Wasm code through the OMG path,
we can run out of memory when compiling large Wasm functions. This change adds
a limit option, webAssemblyBBQFallbackSize, When the Wasm function size is
equal to or greater than this limit we always compile using BBQ optimization
parameters.
As part of this change, we still go through the OMG loop entry OSR code
generation path for functions that are at or above the threshold, but we
compile such functions with BBQ compilation optimization levels.
Also for Wasm functions at or above the threashold, we don't tier up to an
OMG compiled normal entry function. Instead we stay with the BBQ compiled version.
* runtime/OptionsList.h:
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::AirIRGenerator):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::B3IRGenerator):
(JSC::Wasm::parseAndCompile):
* wasm/WasmCompilationMode.cpp:
(JSC::Wasm::wasmFunctionSizeCanBeOMGCompiled):
* wasm/WasmCompilationMode.h:
* wasm/WasmOperations.cpp:
(JSC::Wasm::operationWasmTriggerOSREntryNow):
2020-05-19 Ross Kirsling <ross.kirsling@sony.com>
REGRESSION(r261755): Win/Linux non-unified builds have hundreds of link failures
https://bugs.webkit.org/show_bug.cgi?id=212111
Unreviewed build fix.
* API/:
* bindings/:
* bytecode/:
* bytecompiler/NodesCodegen.cpp:
* debugger/:
* dfg/:
* heap/:
* inspector/:
* interpreter/:
* jit/:
* llint/LLIntEntrypoint.cpp:
* parser/:
* profiler/:
* runtime/:
Restore *Inlines.h includes for >300 files,
but try to preserve the spirit of the original patch by pruning redundancies along the way.
2020-05-19 Mark Lam <mark.lam@apple.com>
Put PtrTagLookup data structures in Configs for freezing.
https://bugs.webkit.org/show_bug.cgi?id=212089
<rdar://problem/63401487>
Reviewed by Robin Morisset.
PtrTagLookup data structures were always meant to only be initialized once at
initialization time and never modified thereafter. This patch puts them in the
Configs for freezing to document and enforce this invariant.
* runtime/JSCConfig.h:
* runtime/JSCPtrTag.cpp:
(JSC::initializePtrTagLookup):
2020-05-19 Youenn Fablet <youenn@apple.com>
[ Mac wk1 Debug ] imported/w3c/web-platform-tests/fetch/api/basic/stream-safe-creation.any.html is flaky crashing with alerts - WTFCrashWithInfo - SC::JSObject::get(JSC::JSGlobalObject*, JSC::PropertyName)
https://bugs.webkit.org/show_bug.cgi?id=211923
<rdar://problem/63244249>
Reviewed by Mark Lam.
* runtime/JSObject.h:
(JSC::JSObject::get const):
When calling get, a terminate exception might happen if running in workers.
Return early in that case. Add an ASSERT that only terminated exceptions can actually happen.
2020-05-18 Andy Estes <aestes@apple.com>
http/tests/ssl/applepay/ApplePayInstallmentConfiguration.https.html fails in public SDK builds
https://bugs.webkit.org/show_bug.cgi?id=212000
<rdar://problem/63323082>
Reviewed by Youenn Fablet.
* Configurations/FeatureDefines.xcconfig:
2020-05-18 Saam Barati <sbarati@apple.com>
Do more speculation that a GetByVal/PutByVal will have an int32 index based on data from ArrayProfile
https://bugs.webkit.org/show_bug.cgi?id=211877
Reviewed by Yusuke Suzuki.
Before this patch, when a GetByVal or PutByVal had a non int32 prediction for
their incoming index, they'd fall completely off the fast path. However, there
are programs where an int32 is boxed inside a double, but our notion of
predicted types don't fully capture this fact. For example, if we have a double Add
to produce an array index, that double Add will predict a full double result,
not a SpecAnyIntAsDouble. However, for GetByVal and PutByVal, there is information
from ArrayProfile we can use to determine if the incoming value is expected to
be in int32 range. The heuristic this patch introduces is:
isFullNumberSpeculation(indexSpeculation)
&& node->arrayMode().isSpecific()
&& node->arrayMode().isInBounds()
&& !m_graph.hasExitSite(node->origin.semantic, Overflow) // DoubleAsInt32 will exit with Overflow on failure
If these conditions are met, we'll now emit a DoubleAsInt32 conversion node
for the index. This puts along the fast path for GetByVal and PutByVal on
array accesses where the incoming index is an int32 boxed in a double.
To make the above isFullNumberSpeculation check more robust, this patch also
makes it so non index double accesses result in marking the array profile as
out of bounds. So this means indices greater than max safe index, and also,
fractional doubles.
This is a 3.75x speedup on microbenchmarks/get-and-put-by-val-double-index-dont-fall-off-a-cliff.js
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* jit/JITOperations.cpp:
(JSC::getByVal):
2020-05-18 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] BigInt peephole compare should speculate appropriately
https://bugs.webkit.org/show_bug.cgi?id=212037
<rdar://problem/63346966>
Reviewed by Saam Barati.
SpeculativeJIT::nonSpeculativePeepholeBranch missed BigInt speculation. This patch renames it
to SpeculativeJIT::genericJSValuePeepholeBranch and adds speculation checks appropriately.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compilePeepHoleBranch):
(JSC::DFG::SpeculativeJIT::genericJSValuePeepholeBranch):
(JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeBranch): Deleted.
* dfg/DFGSpeculativeJIT.h:
2020-05-18 Keith Miller <keith_miller@apple.com>
OSR loop entry to iterator_next generic needs to CheckNotEmpty on m_next
https://bugs.webkit.org/show_bug.cgi?id=212001
Reviewed by Saam Barati.
If we happen to OSR enter into iterator_next during a for-of loop
that has only profiled a generic iterator but is actually running
a fast iterator we will incorrectly perform the Call node This
could happen if we loop_hint OSR enter the first time have seen a
fast iterator. If this happens right now, we generate the following
code:
D@113:<!2:loc15> GetLocal(Check:Untyped:D@198, JS|MustGen|UseAsOther, Function|Empty, loc13(W~/FlushedJSValue), machine:loc10, R:Stack(loc13),Stack(loc5), bc#46, ExitValid) predicting Function|Empty
0x4913f1806151: mov -0x58(%rbp), %rsi
D@114:<!0:-> FilterCallLinkStatus(Check:Untyped:D@113, MustGen, (Function: Object: 0x1053f47e0 with butterfly 0x0 (Structure 0x1053f9260:[0x6dad, Function, {}, NonArray, Proto:0x1050fc248]), StructureID: 28077; Executable: next#Ddkruz:[0x1053c0480->0x1053e4a80, BaselineFunctionCall, 54 (StrictMode)]), R:Stack(loc5), W:SideState, bc#46, ExitValid)
D@115:<!6:loc15> Call(Check:Untyped:D@113, Check:Untyped:D@110, JS|MustGen|VarArgs|UseAsOther, Final, R:World,Stack(loc5), W:Heap, ExitsForExceptions, ClobbersExit, bc#46, ExitValid) predicting Final
0x4913f1806155: mov $0x1, 0x10(%rsp)
0x4913f180615d: mov %rax, 0x18(%rsp)
0x4913f1806162: mov %rsi, 0x8(%rsp)
0x4913f1806167: mov %rax, -0xa0(%rbp)
0x4913f180616e: mov $0x0, 0x24(%rbp)
0x4913f1806175: mov $0x0, %r11
0x4913f180617f: cmp %r11, %rsi
0x4913f1806182: jnz 0x4913f1806192
0x4913f1806188: call 0x4913f180618d
0x4913f180618d: jmp 0x4913f18061ae
0x4913f1806192: mov %rsi, %rax
0x4913f1806195: mov $0x1050cfcb0, %rdx
0x4913f180619f: mov $0x1052fab68, %rcx
0x4913f18061a9: call 0x4913f1801680
0x4913f18061ae: lea -0xd0(%rbp), %rsp
D@116:<!0:-> MovHint(Check:Untyped:D@115, MustGen, tmp0, R:Stack(loc5), W:SideState, ClobbersExit, bc#46, ExitInvalid)
D@332:<!0:-> InvalidationPoint(MustGen, R:Stack(loc5), W:SideState, Exits, bc#46, exit: bc#46cp#1, ExitValid)
D@335:<!0:-> CheckStructure(Check:Cell:D@115, MustGen, [%B2:Object], R:Stack(loc5),JSCell_structureID, Exits, bc#46, exit: bc#46cp#1, ExitValid)
0x4913f18061b5: test %rax, %r15
0x4913f18061b8: jnz 0x4913f18068db
0x4913f18061be: cmp $0xcaae, (%rax)
0x4913f18061c4: jnz 0x4913f18068f1
Loc13 in this IR is the location of the next function. Since it's
nullptr, we will pass the initial fast-path value of 0 and make a
garbage call. This is because Call does not know how to handle
empty values. Subsequently, we will fail a structure check for the
Call's result and OSR exit to the getDone checkpoint. The fix for
this is to simply put a CheckNotEmpty at the top of the generic
case. 99.9% of the time this check will be eliminated so it
doesn't really cost anything.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
2020-05-17 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, link fix for our internal Debug build
* heap/AlignedMemoryAllocator.cpp:
2020-05-17 Lauro Moura <lmoura@igalia.com>
[JSC] Silence unused-but-set-parameter warnings for older compilers
https://bugs.webkit.org/show_bug.cgi?id=212006
Reviewed by Mark Lam.
GCC up to 9.x will emit unused-but-set-parameter for the sources
parameter when NumberOfRegisters is zero (the if block is eliminated)
and for destinations when also ASSERT_ENABLED is false.
* jit/CCallHelpers.h:
(JSC::CCallHelpers::setupStubArgs):
2020-05-16 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Make OutOfMemory error as instance of RangeError
https://bugs.webkit.org/show_bug.cgi?id=211952
Reviewed by Mark Lam.
The spec sometimes requires "check parameters and throw RangeError" before allocating an object.
But we are just allocating an object and throwing an out-of-memory error since wrong parameter will
cause out-of-memory. If out-of-memory error is RangeError, then we can keep our current behavior while
we can make us spec compliant. And note that out-of-memory error is RangeError in SpiderMonkey and V8.
This patch makes out-of-memory error as RangeError instead of Error. We also fix @throwOutOfMemoryError
in builtin code: the previous thrown errors are not marked as out-of-memory error.
* bytecode/BytecodeList.rb:
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitThrowStaticError):
(JSC::BytecodeGenerator::emitThrowReferenceError):
(JSC::BytecodeGenerator::emitThrowTypeError):
(JSC::BytecodeGenerator::emitThrowRangeError):
(JSC::BytecodeGenerator::emitThrowOutOfMemoryError):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::RegExpNode::emitBytecode):
(JSC::BytecodeIntrinsicNode::emit_intrinsic_throwTypeError):
(JSC::BytecodeIntrinsicNode::emit_intrinsic_throwRangeError):
* dfg/DFGOperations.cpp:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/Error.cpp:
(JSC::createError):
(JSC::createOutOfMemoryError):
* runtime/Error.h:
* runtime/ErrorType.cpp:
(JSC::errorTypeName):
(WTF::printInternal):
* runtime/ErrorType.h: We introduced ErrorTypeWithExtension separately from ErrorType to keep ErrorType one-on-one to spec-specified error types.
2020-05-15 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] getFunctionRealm should not use recursion
https://bugs.webkit.org/show_bug.cgi?id=211965
<rdar://problem/63268287>
Reviewed by Saam Barati.
This patch avoids using recursion in getFunctionRealm to avoid stack-overflow.
* runtime/InternalFunction.cpp:
(JSC::getFunctionRealm):
2020-05-15 Keith Miller <keith_miller@apple.com>
Unreviewed, fix internal arm64e build.
* dfg/DFGSpeculativeJIT.cpp:
2020-05-15 Keith Miller <keith_miller@apple.com>
Unreviewed, fix internal fast tls build.
* jit/AssemblyHelpers.cpp:
2020-05-15 Ross Kirsling <ross.kirsling@sony.com>
[IWYU] Remove unnecessary includes from JSC implementation files
https://bugs.webkit.org/show_bug.cgi?id=211867
Reviewed by Keith Miller.
* API/:
* assembler/:
* b3/:
* bindings/:
* builtins/BuiltinExecutables.cpp:
* bytecode/:
* bytecompiler/:
* debugger/:
* dfg/:
* disassembler/:
* ftl/:
* heap/:
* inspector/:
* interpreter/:
* jit/:
* jsc.cpp:
* llint/:
* parser/:
* profiler/:
* runtime/:
* testRegExp.cpp:
* tools/:
* wasm/:
* yarr/:
2020-05-15 Michael Catanzaro <mcatanzaro@gnome.org>
-Wtype-limits warning spam from CCallHelpers.h
https://bugs.webkit.org/show_bug.cgi?id=211701
Reviewed by Darin Adler.
Skip the problematic loops when TargetSize or NumberOfRegisters is 0 using constexpr if.
Solution suggested by Mark Lam.
* jit/CCallHelpers.h:
(JSC::CCallHelpers::setupStubArgs):
(JSC::CCallHelpers::clampArrayToSize):
2020-05-15 Mark Lam <mark.lam@apple.com>
Remove debugging dataLogs in LinkBuffer::copyCompactAndLinkCode() for release builds.
https://bugs.webkit.org/show_bug.cgi?id=211961
<rdar://problem/63264848>
Reviewed by Keith Miller.
* assembler/LinkBuffer.cpp:
(JSC::LinkBuffer::copyCompactAndLinkCode):
2020-05-15 Paulo Matos <pmatos@igalia.com>
Fix ARM NEON only assert
https://bugs.webkit.org/show_bug.cgi?id=211889
Reviewed by Mark Lam.
Fix assert that breaks if ARM does not contain NEON extensions -
the register d16 is only defined if NEON exists.
* assembler/ARMv7Assembler.h:
(JSC::RegisterNames::asSingle):
(JSC::RegisterNames::asSingleUpper):
2020-05-14 Saam Barati <sbarati@apple.com>
GetByVal and PutByVal runtime operations shouldn't fall off a performance cliff when the property is an integer boxed as a double
https://bugs.webkit.org/show_bug.cgi?id=211935
Reviewed by Yusuke Suzuki and Mark Lam.
There were parts in the runtime for get_by_val that weren't properly handling
ints boxed as doubles along the fast path. This could lead to terrible
performance as we could go from double -> string -> int while converting the
subscript into a property to access.
This patch fixes that, and removes the duplicate code we had throughout the
codebase that does this conversion. I'm adding a new functions tryGetAsUint32Index
and tryGetAsInt32 which will handle the double to int conversion.
This is a 10x speedup on the microbenchmark get-and-put-by-val-double-index-dont-fall-off-a-cliff.js
* dfg/DFGOperations.cpp:
(JSC::DFG::putByValInternal):
* jit/JITOperations.cpp:
(JSC::getByVal):
* jsc.cpp:
(functionAsDoubleNumber):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::getByVal):
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/JSCJSValue.h:
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::tryGetAsUint32Index):
(JSC::JSValue::tryGetAsInt32):
2020-05-14 Devin Rousso <drousso@apple.com>
[ESNext] enable logical assignment operators by default
https://bugs.webkit.org/show_bug.cgi?id=211921
Reviewed by Yusuke Suzuki.
* runtime/OptionsList.h:
* parser/Lexer.cpp:
(JSC::Lexer<T>::lexWithoutClearingLineTerminator):
Remove `useLogicalAssignmentOperators` option.
2020-05-14 Keith Miller <keith_miller@apple.com>
Undecided Arrays shouldn't need to be OriginalArray to covert to GetArrayLength
https://bugs.webkit.org/show_bug.cgi?id=211914
Reviewed by Saam Barati.
Also, fix a bug that arrayModesThatPassFiltering() can't handle
Undecided arrays. Because we can now emit a CheckArray on
Undecided AI will try to figure out what types flow out of the
check. Since Undecided was unhandled by filtering, AI will assume
bottom is the only possible value and the DFG/FTL will insert a
breakpoint, causing a crash.
* dfg/DFGArrayMode.cpp:
(JSC::DFG::ArrayMode::refine const):
* dfg/DFGArrayMode.h:
(JSC::DFG::ArrayMode::arrayModesThatPassFiltering const):
2020-05-14 Keith Miller <keith_miller@apple.com>
GetArrayLength should be "blessed" during Fixup phase in the DFG
https://bugs.webkit.org/show_bug.cgi?id=211540
Reviewed by Saam Barati.
If we got an ArrayMode during bytecode parsing for-of that expects
to be configured during Fixup, then right now we will crash on
GetArrayLength. This fixes GetArrayLength to properly call
blessArrayOperation and fixes clobberize to know that
GetArrayLength could have a ForceExit ArrayMode briefly before
being cleaned up.
When blessing GetArrayLength we can now produce CheckArrays that
have an AnyTypedArray ArrayMode::Type. So this patch expands
CheckArray to properly handle that. To help with this we expand
branchIfType to have a starting JSType and an optional ending
JSType. Additionally, to prevent extra checks AI has been taught
to fold more ArrayModes so we should almost always avoid new
runtime checks.
Lastly, make sure that Undecided Arrays don't fall back to generic
because GetArrayLength can't be converted to...
GetArrayLenth. Also, GetArrayLength would previously pass it's own
speculation for the speculation of the index, which logically
doesn't make sense. So this patch adds a new constant, which is
SpecInt32Only, that can be passed if a DFG node doesn't have an
index.
* assembler/testmasm.cpp:
(JSC::testBranchIfType):
(JSC::testBranchIfNotType):
(JSC::run):
* dfg/DFGArrayMode.cpp:
(JSC::DFG::canBecomeGetArrayLength):
* dfg/DFGArrayMode.h:
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::blessArrayOperation):
(JSC::DFG::FixupPhase::attemptToMakeGetArrayLength):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::checkArray):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::isArrayTypeForCheckArray):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::branchIfType):
(JSC::AssemblyHelpers::branchIfNotType):
* runtime/JSType.h:
2020-05-13 Keith Miller <keith_miller@apple.com>
iteration bytecodes need to handle osr exiting from inlined getter frames
https://bugs.webkit.org/show_bug.cgi?id=211873
Reviewed by Saam Barati.
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::slow_path_checkpoint_osr_exit_from_inlined_call):
2020-05-13 Devin Rousso <drousso@apple.com>
Web Inspector: rename CSS.StyleSheetOrigin.Regular to CSS.StyleSheetOrigin.Author to match the spec
https://bugs.webkit.org/show_bug.cgi?id=211827
Reviewed by Timothy Hatcher.
* inspector/protocol/CSS.json:
2020-05-13 Yusuke Suzuki <ysuzuki@apple.com>
JSDOMWindowBase m_windowCloseWatchpoints must be Ref<>
https://bugs.webkit.org/show_bug.cgi?id=211844
Reviewed by Mark Lam.
* bytecode/Watchpoint.cpp:
(JSC::InlineWatchpointSet::inflateSlow):
* bytecode/Watchpoint.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::JSGlobalObject):
* runtime/Structure.cpp:
(JSC::Structure::ensurePropertyReplacementWatchpointSet):
* runtime/SymbolTable.cpp:
(JSC::SymbolTableEntry::prepareToWatch):
* runtime/VM.cpp:
(JSC::VM::ensureWatchpointSetForImpureProperty):
2020-05-13 Caio Lima <ticaiolima@gmail.com>
Making 32-bits JIT build without Unified Build system
https://bugs.webkit.org/show_bug.cgi?id=211853
Reviewed by Adrian Perez de Castro.
This patch is moving some templates to allow non-unified builds on
32-bits JIT configurations.
Those templates were from JITArithmetic32_64 and JITPropertyAccess32_64.
* jit/JITArithmetic.cpp:
(JSC::JIT::emit_compareAndJump):
(JSC::JIT::emit_compareUnsignedAndJump):
(JSC::JIT::emit_compareUnsigned):
(JSC::JIT::emit_compareAndJumpSlow):
(JSC::JIT::emitBinaryDoubleOp):
* jit/JITArithmetic32_64.cpp:
(JSC::JIT::emit_compareAndJump): Deleted.
(JSC::JIT::emit_compareUnsignedAndJump): Deleted.
(JSC::JIT::emit_compareUnsigned): Deleted.
(JSC::JIT::emit_compareAndJumpSlow): Deleted.
(JSC::JIT::emitBinaryDoubleOp): Deleted.
* jit/JITOpcodes32_64.cpp:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emitPutByValWithCachedId):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emitPutByValWithCachedId): Deleted.
2020-05-13 Caio Lima <ticaiolima@gmail.com>
[JSC] Support delete by val/id IC on 32-bits
https://bugs.webkit.org/show_bug.cgi?id=208207
Reviewed by Saam Barati.
This patch implements DeleteById and DeleteByVal IC on 32-bits JIT. It
includes both Baseline and DFG changes.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileDeleteById):
(JSC::DFG::SpeculativeJIT::compileDeleteByVal):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compileDeleteById): Deleted.
(JSC::DFG::SpeculativeJIT::compileDeleteByVal): Deleted.
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compileDeleteById): Deleted.
(JSC::DFG::SpeculativeJIT::compileDeleteByVal): Deleted.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileDelBy):
* jit/JITInlineCacheGenerator.cpp:
(JSC::JITDelByValGenerator::JITDelByValGenerator):
(JSC::JITDelByIdGenerator::JITDelByIdGenerator):
* jit/JITInlineCacheGenerator.h:
* jit/JITPropertyAccess.cpp:
(JSC::JIT::emit_op_del_by_id):
(JSC::JIT::emit_op_del_by_val):
* jit/JITPropertyAccess32_64.cpp:
(JSC::JIT::emit_op_del_by_id):
(JSC::JIT::emit_op_del_by_val):
(JSC::JIT::emitSlow_op_del_by_val):
(JSC::JIT::emitSlow_op_del_by_id):
2020-05-13 Saam Barati <sbarati@apple.com>
MovHint can see an arguments object be MovHinted to a Tmp
https://bugs.webkit.org/show_bug.cgi?id=211820
<rdar://problem/62882158>
Reviewed by Keith Miller.
We had an assert that it wasn't possible to have a MovHint from an arguments
object to a Tmp. However, this is possible with for-of. There is nothing
about the current algorithm that is specific to only VirtualRegisters. The
algorithm also works over Tmps. So I've generalized the algorithm to just work
over Operand.
* dfg/DFGVarargsForwardingPhase.cpp:
2020-05-13 Alexey Shvayka <shvaikalesh@gmail.com>
Move @isConstructor checks from fast paths of Array.from and Array.of
https://bugs.webkit.org/show_bug.cgi?id=211805
Reviewed by Keith Miller.
This semantically equivalent change advances provided Array.{from,of} microbenchmarks by ~60%.
Also, this patch removes @isConstructor check from @newPromiseCapabilitySlow (that is heavily
used by Promise subclasses) since it comes right before [[Construct]], its message doesn't add
more clarity, and constructability of its argument was likely checked by @speciesConstructor.
* builtins/ArrayConstructor.js:
(of):
(from):
* builtins/PromiseOperations.js:
(globalPrivate.newPromiseCapabilitySlow):
2020-05-12 Alexey Shvayka <shvaikalesh@gmail.com>
Implement @isConstructor bytecode intrinsic and bytecode for that
https://bugs.webkit.org/show_bug.cgi?id=144093
Reviewed by Keith Miller.
This change replaces @isConstructor link-time-constant with bytecode intrinsic and utilizes it
in ClassExprNode::emitBytecode() according to the spec [1], aligning JSC with V8 and SpiderMonkey.
Before this patch, we checked if "prototype" of superclass is an object, which is incorrect for
generators and bound non-constructor functions with own "prototype".
OpIsConstructor's fast path can't be easily compiled, and it's not a hot code anyway, so instead
we reduce code bloat by just calling slow ops from DFG and FTL (if we bail out, we slow down all
@isConstructor call sites). This advances microbenchmarks/is-constructor.js by ~35%.
[1]: https://tc39.es/ecma262/#sec-runtime-semantics-classdefinitionevaluation (step 5.f)
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* builtins/BuiltinNames.h:
* bytecode/BytecodeIntrinsicRegistry.h:
* bytecode/BytecodeList.rb:
* bytecode/BytecodeUseDef.cpp:
(JSC::computeUsesForBytecodeIndexImpl):
(JSC::computeDefsForBytecodeIndexImpl):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitIsConstructor):
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::ClassExprNode::emitBytecode):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGHeapLocation.cpp:
(WTF::printInternal):
* dfg/DFGHeapLocation.h:
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileIsConstructor):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileIsConstructor):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
* llint/LowLevelInterpreter.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/CommonSlowPaths.h:
* runtime/ECMAScriptSpecInternalFunctions.cpp: Removed.
* runtime/ECMAScriptSpecInternalFunctions.h: Removed.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
2020-05-12 Robin Morisset <rmorisset@apple.com>
Exception check for OOM is a bit too late in JSBigInt::exponentiate.
https://bugs.webkit.org/show_bug.cgi?id=211823
Reviewed by Mark Lam.
We were doing multiplyImpl(...).payload.asHeapBigInt(), but multiplyImpl can return a null payload if it causes an exception.
So we must first check whether an exception was raised, and only if not can we do asHeapBigInt.
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::exponentiateImpl):
2020-05-12 Saam Barati <sbarati@apple.com>
handling of Check in VarargsForwardingPhase is too pessimistic
https://bugs.webkit.org/show_bug.cgi?id=211810
Reviewed by Keith Miller and Filip Pizlo.
We were treating a check, even if it wasn't on the sink candidate,
as if it could escape the candidate. That's wrong. Only checks on the
candidate have the escaping ability.
* dfg/DFGVarargsForwardingPhase.cpp:
2020-05-12 Keith Miller <keith_miller@apple.com>
The bottom value set for m_value in iterator_next should be materialized after a done getter
https://bugs.webkit.org/show_bug.cgi?id=211811
Reviewed by Saam Barati.
Right now, if the done getter contains control flow, then we will
have the bottom value in a different block from the
MovHint/SetLocal and we will fail to validate.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
2020-05-12 Ross Kirsling <ross.kirsling@sony.com>
Fix existing usage of final/override/virtual in JSC and WTF
https://bugs.webkit.org/show_bug.cgi?id=211772
Reviewed by Darin Adler.
* API/JSAPIWrapperObject.mm:
* API/JSManagedValue.mm:
* API/JSScriptSourceProvider.h:
* API/ObjCCallbackFunction.mm:
* API/glib/JSAPIWrapperGlobalObject.cpp:
* API/glib/JSAPIWrapperObjectGLib.cpp:
* API/glib/JSCWeakValue.cpp:
* bytecode/AccessCaseSnippetParams.cpp:
* bytecode/AccessCaseSnippetParams.h:
* bytecode/CodeBlock.cpp:
* bytecode/StructureStubClearingWatchpoint.h:
* bytecode/VariableWriteFireDetail.h:
* bytecode/Watchpoint.h:
* dfg/DFGAdaptiveInferredPropertyValueWatchpoint.h:
* dfg/DFGArrayifySlowPathGenerator.h:
* dfg/DFGCallArrayAllocatorSlowPathGenerator.h:
* dfg/DFGCallCreateDirectArgumentsSlowPathGenerator.h:
* dfg/DFGSaneStringGetByValSlowPathGenerator.h:
* dfg/DFGSlowPathGenerator.h:
* dfg/DFGSnippetParams.h:
* dfg/DFGWorklist.cpp:
* ftl/FTLSnippetParams.h:
* heap/BlockDirectory.cpp:
* heap/EdenGCActivityCallback.h:
* heap/FullGCActivityCallback.h:
* heap/Heap.cpp:
* heap/Heap.h:
* heap/IncrementalSweeper.h:
* heap/IsoCellSet.cpp:
* heap/IsoCellSetInlines.h:
* heap/IsoHeapCellType.h:
* heap/IsoInlinedHeapCellType.h:
* heap/ParallelSourceAdapter.h:
* heap/StopIfNecessaryTimer.h:
* heap/Subspace.cpp:
* heap/SubspaceInlines.h:
* inspector/InjectedScript.h:
* inspector/JSGlobalObjectConsoleClient.h:
* inspector/JSGlobalObjectInspectorController.h:
* inspector/JSGlobalObjectScriptDebugServer.h:
* inspector/JSInjectedScriptHost.cpp:
* inspector/agents/InspectorAgent.h:
* inspector/agents/InspectorScriptProfilerAgent.h:
* inspector/agents/InspectorTargetAgent.h:
* inspector/agents/JSGlobalObjectAuditAgent.h:
* inspector/agents/JSGlobalObjectDebuggerAgent.h:
* inspector/agents/JSGlobalObjectRuntimeAgent.h:
* inspector/augmentable/AlternateDispatchableAgent.h:
* inspector/remote/RemoteConnectionToTarget.h:
* inspector/remote/RemoteInspector.h:
* inspector/remote/socket/RemoteInspectorServer.h:
* inspector/scripts/codegen/cpp_generator_templates.py:
* inspector/scripts/codegen/generate_objc_backend_dispatcher_header.py:
* inspector/scripts/tests/all/expected/definitions-with-mac-platform.json-result:
* inspector/scripts/tests/generic/expected/command-targetType-matching-domain-debuggableType.json-result:
* inspector/scripts/tests/generic/expected/commands-with-async-attribute.json-result:
* inspector/scripts/tests/generic/expected/commands-with-optional-call-return-parameters.json-result:
* inspector/scripts/tests/generic/expected/domain-debuggableTypes.json-result:
* inspector/scripts/tests/generic/expected/domain-targetType-matching-domain-debuggableType.json-result:
* inspector/scripts/tests/generic/expected/domain-targetTypes.json-result:
* inspector/scripts/tests/generic/expected/domains-with-varying-command-sizes.json-result:
* inspector/scripts/tests/generic/expected/enum-values.json-result:
* inspector/scripts/tests/generic/expected/event-targetType-matching-domain-debuggableType.json-result:
* inspector/scripts/tests/generic/expected/generate-domains-with-feature-guards.json-result:
* inspector/scripts/tests/mac/expected/definitions-with-mac-platform.json-result:
* jit/JITWorklist.cpp:
* parser/Nodes.h:
* parser/SourceProvider.h:
* runtime/DataView.h:
* runtime/DoublePredictionFuzzerAgent.h:
* runtime/FileBasedFuzzerAgent.h:
* runtime/GenericTypedArrayView.h:
* runtime/JSMicrotask.cpp:
* runtime/NarrowingNumberPredictionFuzzerAgent.h:
* runtime/ObjectPropertyChangeAdaptiveWatchpoint.h:
* runtime/PredictionFileCreatingFuzzerAgent.h:
* runtime/PromiseTimer.h:
* runtime/RandomizingFuzzerAgent.h:
* runtime/RegExpCache.h:
* runtime/Structure.cpp:
* runtime/StructureRareData.cpp:
* runtime/VMTraps.cpp:
* runtime/WideningNumberPredictionFuzzerAgent.h:
* tools/JSDollarVM.cpp:
* wasm/WasmBBQPlan.h:
* wasm/WasmCallee.h:
* wasm/WasmLLIntPlan.h:
* wasm/WasmOMGForOSREntryPlan.h:
* wasm/WasmOMGPlan.h:
* wasm/WasmWorklist.cpp:
* yarr/YarrJIT.cpp:
2020-05-12 Ross Kirsling <ross.kirsling@sony.com>
[clang-tidy] Run modernize-use-override over JSC, then ensure as much as possible is final
https://bugs.webkit.org/show_bug.cgi?id=211743
Reviewed by Saam Barati.
* API/JSScriptRef.cpp:
* b3/B3ArgumentRegValue.h:
* b3/B3AtomicValue.h:
* b3/B3CCallValue.h:
* b3/B3CheckSpecial.h:
* b3/B3CheckValue.h:
* b3/B3Const32Value.h:
* b3/B3Const64Value.h:
* b3/B3ConstDoubleValue.h:
* b3/B3ConstFloatValue.h:
* b3/B3DataSection.h:
* b3/B3ExtractValue.h:
* b3/B3FenceValue.h:
* b3/B3MemoryValue.h:
* b3/B3PatchpointSpecial.h:
* b3/B3PatchpointValue.h:
* b3/B3SlotBaseValue.h:
* b3/B3StackmapSpecial.h:
* b3/B3StackmapValue.h:
* b3/B3SwitchValue.h:
* b3/B3UpsilonValue.h:
* b3/B3VariableValue.h:
* b3/B3WasmAddressValue.h:
* b3/B3WasmBoundsCheckValue.h:
* b3/air/AirCCallSpecial.h:
* b3/air/AirPrintSpecial.h:
* bytecode/BytecodeDumper.h:
* bytecode/GetterSetterAccessCase.h:
* bytecode/InstanceOfAccessCase.h:
* bytecode/IntrinsicGetterAccessCase.h:
* bytecode/ModuleNamespaceAccessCase.h:
* bytecode/ProxyableAccessCase.h:
* bytecode/Watchpoint.h:
* dfg/DFGFailedFinalizer.h:
* dfg/DFGGraph.h:
* dfg/DFGJITCode.h:
* dfg/DFGJITFinalizer.h:
* dfg/DFGToFTLDeferredCompilationCallback.h:
* dfg/DFGToFTLForOSREntryDeferredCompilationCallback.h:
* ftl/FTLForOSREntryJITCode.h:
* ftl/FTLJITCode.h:
* ftl/FTLJITFinalizer.h:
* heap/CompleteSubspace.h:
* heap/FastMallocAlignedMemoryAllocator.h:
* heap/GigacageAlignedMemoryAllocator.h:
* heap/HeapSnapshotBuilder.h:
* heap/IsoAlignedMemoryAllocator.h:
* heap/IsoSubspace.h:
* heap/IsoSubspacePerVM.cpp:
* heap/IsoSubspacePerVM.h:
* heap/MarkStackMergingConstraint.h:
* heap/SimpleMarkingConstraint.h:
* heap/SpaceTimeMutatorScheduler.h:
* heap/StochasticSpaceTimeMutatorScheduler.h:
* heap/SynchronousStopTheWorldMutatorScheduler.h:
* jit/GCAwareJITStubRoutine.h:
* jit/JITCode.h:
* jit/JITThunks.h:
* jit/JITToDFGDeferredCompilationCallback.h:
* jit/PolymorphicCallStubRoutine.h:
* jsc.cpp:
* parser/Lexer.cpp: Address warning.
* runtime/JSDestructibleObjectHeapCellType.h:
* runtime/SimpleTypedArrayController.h:
* runtime/Structure.h:
* runtime/WeakGCMap.h:
* wasm/WasmEntryPlan.h:
2020-05-12 Michael Catanzaro <mcatanzaro@gnome.org>
-Wsign-compare warnings in FTLLowerDFGToB3.cpp and DFGSpeculativeJIT.cpp
https://bugs.webkit.org/show_bug.cgi?id=211783
Reviewed by Darin Adler.
This fixes -Wsign-compare warnings introduced in r260331.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileValueBitNot):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileValueBitNot):
2020-05-12 Truitt Savell <tsavell@apple.com>
Unreviewed, reverting r261542.
Broke internal builds
Reverted changeset:
"[clang-tidy] Run modernize-use-override over JSC, then ensure
as much as possible is final"
https://bugs.webkit.org/show_bug.cgi?id=211743
https://trac.webkit.org/changeset/261542
2020-05-12 Mark Lam <mark.lam@apple.com>
Wasm::enableFastMemory() was called too late.
https://bugs.webkit.org/show_bug.cgi?id=211773
Reviewed by Yusuke Suzuki.
If Wasm fast memory is to be enabled, we should just do it in initializeThreading()
just like for all the other signal handlers that need to be initialized for JSC.
This simplifies its initialization and ensures that it is done in a timely manner
before Configs are frozen.
* jsc.cpp:
(jscmain):
* runtime/InitializeThreading.cpp:
(JSC::initializeThreading):
2020-05-11 Darin Adler <darin@apple.com>
Fix problems caught by replacing WTF::Optional with std::optional
https://bugs.webkit.org/show_bug.cgi?id=211703
Reviewed by Chris Dumez.
* runtime/MachineContext.h:
(JSC::MachineContext::instructionPointer): Use explcit makeOptional here,
to work around the fact that MacroAssemblerCodePtr uses an unusual technique
to disable conversions to everything except bool.
2020-05-11 Yoshiaki JITSUKAWA <yoshiaki.jitsukawa@sony.com>
Fix build errors after r260992
https://bugs.webkit.org/show_bug.cgi?id=211756
Reviewed by Darin Adler.
Add JSC namespace specifier to NonIntrinsic and PropertyAttribute
in the macros in JSObject.h since those can be used outside of
or without introducing JSC namespace.
* runtime/JSObject.h:
2020-05-11 Ross Kirsling <ross.kirsling@sony.com>
[clang-tidy] Run modernize-use-override over JSC, then ensure as much as possible is final
https://bugs.webkit.org/show_bug.cgi?id=211743
Reviewed by Saam Barati.
* API/JSScriptRef.cpp:
* b3/B3ArgumentRegValue.h:
* b3/B3AtomicValue.h:
* b3/B3CCallValue.h:
* b3/B3CheckSpecial.h:
* b3/B3CheckValue.h:
* b3/B3Const32Value.h:
* b3/B3Const64Value.h:
* b3/B3ConstDoubleValue.h:
* b3/B3ConstFloatValue.h:
* b3/B3DataSection.h:
* b3/B3ExtractValue.h:
* b3/B3FenceValue.h:
* b3/B3MemoryValue.h:
* b3/B3PatchpointSpecial.h:
* b3/B3PatchpointValue.h:
* b3/B3SlotBaseValue.h:
* b3/B3StackmapSpecial.h:
* b3/B3StackmapValue.h:
* b3/B3SwitchValue.h:
* b3/B3UpsilonValue.h:
* b3/B3VariableValue.h:
* b3/B3WasmAddressValue.h:
* b3/B3WasmBoundsCheckValue.h:
* b3/air/AirCCallSpecial.h:
* b3/air/AirPrintSpecial.h:
* bytecode/BytecodeDumper.h:
* bytecode/GetterSetterAccessCase.h:
* bytecode/InstanceOfAccessCase.h:
* bytecode/IntrinsicGetterAccessCase.h:
* bytecode/ModuleNamespaceAccessCase.h:
* bytecode/ProxyableAccessCase.h:
* bytecode/Watchpoint.h:
* dfg/DFGFailedFinalizer.h:
* dfg/DFGGraph.h:
* dfg/DFGJITCode.h:
* dfg/DFGJITFinalizer.h:
* dfg/DFGToFTLDeferredCompilationCallback.h:
* dfg/DFGToFTLForOSREntryDeferredCompilationCallback.h:
* ftl/FTLForOSREntryJITCode.h:
* ftl/FTLJITCode.h:
* ftl/FTLJITFinalizer.h:
* heap/CompleteSubspace.h:
* heap/FastMallocAlignedMemoryAllocator.h:
* heap/GigacageAlignedMemoryAllocator.h:
* heap/HeapSnapshotBuilder.h:
* heap/IsoAlignedMemoryAllocator.h:
* heap/IsoSubspace.h:
* heap/IsoSubspacePerVM.cpp:
* heap/IsoSubspacePerVM.h:
* heap/MarkStackMergingConstraint.h:
* heap/SimpleMarkingConstraint.h:
* heap/SpaceTimeMutatorScheduler.h:
* heap/StochasticSpaceTimeMutatorScheduler.h:
* heap/SynchronousStopTheWorldMutatorScheduler.h:
* jit/GCAwareJITStubRoutine.h:
* jit/JITCode.h:
* jit/JITThunks.h:
* jit/JITToDFGDeferredCompilationCallback.h:
* jit/PolymorphicCallStubRoutine.h:
* jsc.cpp:
* parser/Lexer.cpp: Address warning.
* runtime/JSDestructibleObjectHeapCellType.h:
* runtime/SimpleTypedArrayController.h:
* runtime/Structure.h:
* runtime/WeakGCMap.h:
* wasm/WasmEntryPlan.h:
2020-05-11 Mark Lam <mark.lam@apple.com>
Introduce WTF::Config and put Signal.cpp's init-once globals in it.
https://bugs.webkit.org/show_bug.cgi?id=211729
<rdar://problem/62938878>
Reviewed by Keith Miller and Saam Barati.
1. Initialize VMTraps' signals early now that we'll be freezing signals at the end
of the first VM initialization.
2. Move the !initializeThreadingHasBeenCalled RELEASE_ASSERT in initializeThreading()
to the bottom of the function. This way, we'll also catch bugs which may cause
us to jump into the middle of the function.
Added a compilerFence there to ensure that the RELEASE_ASSERT is only executed
after all initialization is done. This guarantees that it will only be executed
at the end.
3. Call WTF::Config::permanentlyFreeze() from JSC::Config::permanentlyFreeze()
for obvious reasons: freezing one should freeze the other.
* runtime/InitializeThreading.cpp:
(JSC::initializeThreading):
* runtime/JSCConfig.cpp:
(JSC::Config::permanentlyFreeze):
* runtime/VMTraps.cpp:
(JSC::VMTraps::initializeSignals):
* runtime/VMTraps.h:
2020-05-11 Keith Miller <keith_miller@apple.com>
Remove unused BytecodeKills.h
https://bugs.webkit.org/show_bug.cgi?id=211753
Reviewed by Yusuke Suzuki.
No one uses this class anymore, we should get rid of it.
* JavaScriptCore.xcodeproj/project.pbxproj:
* bytecode/BytecodeKills.h: Removed.
* bytecode/BytecodeLivenessAnalysis.cpp:
(JSC::BytecodeLivenessAnalysis::computeKills): Deleted.
* bytecode/BytecodeLivenessAnalysis.h:
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::killsFor): Deleted.
* dfg/DFGGraph.h:
2020-05-10 Ross Kirsling <ross.kirsling@sony.com>
[clang-tidy] Run modernize-use-nullptr over JSC
https://bugs.webkit.org/show_bug.cgi?id=211706
Reviewed by Darin Adler.
* API/APICallbackFunction.h:
* API/JSAPIGlobalObject.h:
* API/JSBase.cpp:
* API/JSCallbackObjectFunctions.h:
* API/JSClassRef.cpp:
* API/JSContextRef.cpp:
* API/JSObjectRef.cpp:
* API/JSScriptRef.cpp:
* API/JSValueRef.cpp:
* API/JSWeakObjectMapRefPrivate.cpp:
* API/tests/ExecutionTimeLimitTest.cpp:
* API/tests/PingPongStackOverflowTest.cpp:
* assembler/AbstractMacroAssembler.h:
* assembler/CPU.cpp:
* bytecode/CodeBlock.cpp:
* bytecode/DeleteByIdVariant.cpp:
* bytecode/GetByIdVariant.cpp:
* bytecode/InByIdVariant.cpp:
* bytecode/InlineCallFrame.cpp:
* bytecode/LazyOperandValueProfile.cpp:
* bytecode/PutByIdVariant.cpp:
* bytecode/ValueProfile.h:
* bytecode/ValueRecovery.cpp:
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
* debugger/DebuggerScope.h:
* dfg/DFGAbstractValue.cpp:
* dfg/DFGAdjacencyList.h:
* dfg/DFGArgumentPosition.h:
* dfg/DFGArrayifySlowPathGenerator.h:
* dfg/DFGAvailability.h:
* dfg/DFGByteCodeParser.cpp:
* dfg/DFGCFGSimplificationPhase.cpp:
* dfg/DFGCPSRethreadingPhase.cpp:
* dfg/DFGCompilationKey.h:
* dfg/DFGConstantFoldingPhase.cpp:
* dfg/DFGDisassembler.cpp:
* dfg/DFGDoubleFormatState.h:
* dfg/DFGEdge.h:
* dfg/DFGFixupPhase.cpp:
* dfg/DFGFrozenValue.cpp:
* dfg/DFGGenerationInfo.h:
* dfg/DFGGraph.h:
* dfg/DFGInPlaceAbstractState.cpp:
* dfg/DFGIntegerCheckCombiningPhase.cpp:
* dfg/DFGLazyJSValue.cpp:
* dfg/DFGNode.h:
* dfg/DFGOSREntrypointCreationPhase.cpp:
* dfg/DFGOSRExit.cpp:
* dfg/DFGOperations.cpp:
* dfg/DFGSilentRegisterSavePlan.h:
* dfg/DFGSpeculativeJIT.cpp:
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT64.cpp:
* dfg/DFGStructureAbstractValue.cpp:
* dfg/DFGTransition.cpp:
* dfg/DFGTypeCheckHoistingPhase.cpp:
* dfg/DFGWorklist.cpp:
* ftl/FTLAbstractHeapRepository.h:
* ftl/FTLAvailableRecovery.h:
* ftl/FTLExitValue.cpp:
* ftl/FTLFormattedValue.h:
* ftl/FTLJITCode.cpp:
* ftl/FTLLink.cpp:
* ftl/FTLLowerDFGToB3.cpp:
* ftl/FTLLoweredNodeValue.h:
* ftl/FTLOSREntry.cpp:
* ftl/FTLOSRExitCompiler.cpp:
* ftl/FTLTypedPointer.h:
* ftl/FTLValueFromBlock.h:
* ftl/FTLValueRange.h:
* heap/GCSegmentedArray.h:
* heap/Handle.h:
* heap/HandleSet.h:
* heap/HandleTypes.h:
* heap/HeapSnapshotBuilder.cpp:
* heap/MarkedBlockInlines.h:
* heap/Strong.h:
* heap/WeakImpl.h:
* heap/WeakInlines.h:
* heap/WeakSet.cpp:
* heap/WeakSet.h:
* interpreter/CallFrame.cpp:
* interpreter/CallFrame.h:
* interpreter/Interpreter.cpp:
* interpreter/ProtoCallFrame.h:
* interpreter/StackVisitor.cpp:
* interpreter/StackVisitor.h:
* jit/AssemblyHelpers.h:
* jit/CCallHelpers.h:
* jit/JITCode.cpp:
* jit/JITOperations.cpp:
* jit/Repatch.cpp:
* jit/ThunkGenerators.cpp:
* jsc.cpp:
* llint/LLIntSlowPaths.cpp:
* parser/ASTBuilder.h:
* parser/Lexer.cpp:
* parser/Lexer.h:
* parser/Nodes.cpp:
* parser/Nodes.h:
* parser/Parser.cpp:
* parser/Parser.h:
* parser/ParserArena.cpp:
* parser/ParserArena.h:
* parser/ParserFunctionInfo.h:
* parser/SyntaxChecker.h:
* parser/UnlinkedSourceCode.h:
* profiler/ProfilerBytecodeSequence.cpp:
* profiler/ProfilerCompilation.cpp:
* profiler/ProfilerDatabase.cpp:
* profiler/ProfilerOSRExitSite.cpp:
* profiler/ProfilerOriginStack.cpp:
* runtime/ArgList.h:
* runtime/ArrayPrototype.cpp:
* runtime/ClonedArguments.cpp:
* runtime/CommonSlowPaths.cpp:
* runtime/Completion.h:
* runtime/DataView.h:
* runtime/DatePrototype.cpp:
* runtime/DirectEvalExecutable.cpp:
* runtime/DumpContext.cpp:
* runtime/FunctionExecutable.cpp:
* runtime/IndirectEvalExecutable.cpp:
* runtime/JSArray.cpp:
* runtime/JSArrayBufferView.cpp:
* runtime/JSCJSValue.cpp:
* runtime/JSCJSValueInlines.h:
* runtime/JSCell.cpp:
* runtime/JSDataView.cpp:
* runtime/JSDestructibleObject.h:
* runtime/JSFunction.cpp:
* runtime/JSGlobalObject.cpp:
* runtime/JSGlobalObject.h:
* runtime/JSONObject.cpp:
* runtime/JSObject.cpp:
* runtime/JSObject.h:
* runtime/JSScope.cpp:
* runtime/JSScope.h:
* runtime/LiteralParser.cpp:
* runtime/OptionsList.h:
* runtime/PropertyDescriptor.cpp:
* runtime/PropertyMapHashTable.h:
* runtime/PropertySlot.h:
* runtime/PutPropertySlot.h:
* runtime/RegExpMatchesArray.h:
* runtime/RegExpPrototype.cpp:
* runtime/StringPrototype.cpp:
* runtime/Structure.cpp:
* runtime/Structure.h:
* runtime/TestRunnerUtils.cpp:
* runtime/TypedArrayType.cpp:
* runtime/VM.cpp:
* runtime/Watchdog.cpp:
* runtime/Watchdog.h:
* runtime/WriteBarrier.h:
* testRegExp.cpp:
* tools/JSDollarVM.cpp:
* wasm/WasmSlowPaths.cpp:
* yarr/RegularExpression.h:
* yarr/YarrInterpreter.cpp:
* yarr/YarrJIT.cpp:
* yarr/YarrJIT.h:
* yarr/YarrPattern.cpp:
* yarr/YarrPattern.h:
2020-05-09 Ross Kirsling <ross.kirsling@sony.com>
Fix build errors and warnings for non-unified JSCOnly
https://bugs.webkit.org/show_bug.cgi?id=211655
Reviewed by Darin Adler and Yusuke Suzuki.
* bytecode/BytecodeDumper.cpp:
(JSC::isConstantRegisterIndex): Deleted.
Remove unused function.
* llint/LLIntEntrypoint.cpp:
* llint/LLIntThunks.cpp:
* llint/LLIntThunks.h:
* runtime/AggregateErrorConstructor.cpp:
* runtime/AggregateErrorPrototype.cpp:
* wasm/js/WebAssemblyFunction.cpp:
Fix includes.
* tools/JSDollarVM.cpp:
Deal with "unused constant" warnings for needsDestruction.
* wasm/WasmLLIntPlan.cpp:
* wasm/WasmSignature.cpp:
Remove unused constants.
2020-05-08 Darin Adler <darin@apple.com>
Streamline MarkupAccumulator to improve efficiency a bit
https://bugs.webkit.org/show_bug.cgi?id=211656
Reviewed by Anders Carlsson.
* b3/air/AirFixPartialRegisterStalls.h: Fix spelling of "explicitly".
2020-05-08 Alexey Shvayka <shvaikalesh@gmail.com>
Array.prototype.concat fast path checks should not be observable
https://bugs.webkit.org/show_bug.cgi?id=211643
Reviewed by Ross Kirsling.
This change utilizes @tryGetByIdWithWellKnownSymbol intrinsic to make
off the spec Symbol.isConcatSpreadable lookups unobservable to userland code,
aligning JSC with V8 and SpiderMonkey.
Since @tryGetById uses PropertySlot::getPureResult(), which returns `null`
for Proxy [[Get]] traps and JS getters (covered by stress/try-get-by-id.js),
we can safely compare its result `undefined`. Also, this allows us to remove
@isProxyObject check as Proxy argument is never a fast path anyway.
This patch is neutral on microbenchmarks/concat-append-one.js.
* builtins/ArrayPrototype.js:
(concat):
2020-05-07 Michael Catanzaro <mcatanzaro@gnome.org>
Simplify preprocessor guards in GCMemoryOperations.h
https://bugs.webkit.org/show_bug.cgi?id=211588
Reviewed by Darin Adler.
If we adjust the guards a bit, then we don't need to repeat the fallback path.
* heap/GCMemoryOperations.h:
(JSC::gcSafeMemmove):
(JSC::gcSafeZeroMemory):
2020-05-07 Mark Lam <mark.lam@apple.com>
Give the DFG and FTL WorkList threads more stack space on ASAN builds.
https://bugs.webkit.org/show_bug.cgi?id=211535
<rdar://problem/62947884>
Reviewed by Geoffrey Garen.
* dfg/DFGWorklist.cpp:
(JSC::DFG::Worklist::ThreadBody::ThreadBody):
- Mark the AutomaticThread as ThreadType::Compiler.
2020-05-07 Daniel Kolesa <daniel@octaforge.org>
REGRESSION(r251875): Crash in JSC::StructureIDTable::get on ppc64le: gcSafeMemcpy broken on JSVALUE64 platforms other than x86_64 and aarch64
https://bugs.webkit.org/show_bug.cgi?id=210685
Reviewed by Michael Catanzaro.
Fix gcSafeMemcpy on non-x86_64/aarch64 64-bit architectures.
We were hitting an incorrect x86_64 assertion on values larger than
mediumCutoff on JSVALUE64 architectures other than x86_64 and aarch64,
as the control flow is wrong.
* heap/GCMemoryOperations.h:
(JSC::gcSafeMemcpy):
2020-05-07 Mark Lam <mark.lam@apple.com>
Add stack checks to the DFG and FTL bytecode parser.
https://bugs.webkit.org/show_bug.cgi?id=211547
<rdar://problem/62958880>
Reviewed by Yusuke Suzuki.
Inlining can cause some level of recursion of the DFG bytecode parser. We should
do a stack check at each inlining check before recursing. If a stack overflow
appears to be imminent, then just refuse to inline, and therefore, don't recurse
deeper into the parser.
This issue is more noticeable on ASan debug builds where stack frames can be
humongous.
Removed the SUPPRESS_ASAN on cloberrize() and the associated comment from r260692.
It was a mis-diagnosis. The stack checks are what we need.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleVarargsInlining):
(JSC::DFG::ByteCodeParser::handleInlining):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGGraph.h:
2020-05-07 Darin Adler <darin@apple.com>
REGRESSION (r261257): Lifetime problem with upconverted characters in toLocaleCase
https://bugs.webkit.org/show_bug.cgi?id=211580
rdar://62980449
Reviewed by Yusuke Suzuki.
The problem comes from the fact that callBufferProducingFunction is moving the same
arguments multiple times. At the moment, this works around the only practical
problem with that, but later it should be fixed in callBufferProducingFunction.
* runtime/IntlDateTimeFormat.cpp:
(JSC::IntlDateTimeFormat::initializeDateTimeFormat): Work around mistakes in how
callBufferProducingFunction works with arguments by calling get() explicitly on the
result of upconvertedCharacters. Later we could fix callBufferProducingFunction to
be safer, but for now this solves the problem.
* runtime/StringPrototype.cpp:
(JSC::toLocaleCase): Ditto.
2020-05-07 Keith Miller <keith_miller@apple.com>
Fix ArrayMode nodes after r261260
https://bugs.webkit.org/show_bug.cgi?id=211543
Reviewed by Yusuke Suzuki.
I accidentally ran tests with a release build rather than
release+assert when uploading r261260. This patch skips the
CheckArray node in the ArrayMode clobbersTop() logic before
Fixup. And also marks a GetArrayLength in the TypedArray
intrsinics as ExitOK.
This patch also relands r261260.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsicGetter):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
2020-05-07 Ryan Haddad <ryanhaddad@apple.com>
Unreviewed, reverting r261260.
Caused 26 JSC test failures
Reverted changeset:
"DFG ByVal nodes with ArrayModes should clobberTop until Fixup
phase runs."
https://bugs.webkit.org/show_bug.cgi?id=211531
https://trac.webkit.org/changeset/261260
2020-05-07 Mark Lam <mark.lam@apple.com>
Fix broken exceptionFuzz tests.
https://bugs.webkit.org/show_bug.cgi?id=211550
Reviewed by Yusuke Suzuki.
Remove the bad and now unused utility function to set Options::useExceptionFuzz().
* tools/JSDollarVM.cpp:
(JSC::JSDollarVM::finishCreation):
(JSC::functionEnableExceptionFuzz): Deleted.
2020-05-06 Keith Miller <keith_miller@apple.com>
DFG ByVal nodes with ArrayModes should clobberTop until Fixup phase runs.
https://bugs.webkit.org/show_bug.cgi?id=211531
Reviewed by Yusuke Suzuki.
When parsing bytecode we may pick a relatively constrained
ArrayMode based on our profiling. Some of these modes may not
clobber exit state. However, Fixup sometimes wants to widen this
to a more generic mode based on other data. This causes us to
think it was valid to exit immediately after the
GetByVal/HasIndexedProperty, which would be wrong with the wider
ArrayMode. We may also incorrectly insert invalidition points
if clobberize gives us the wrong data.
To fix this clobberize should say All ByVal nodes clobberTop()
until after fixup. Additionally, this patch adds an assertion that
nodes don't go from not clobbering exit state to clobbering exit
state during fixup.
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::performFixup):
* dfg/DFGGraph.h:
2020-05-06 Darin Adler <darin@apple.com>
Make a helper for the pattern of ICU functions that may need to be called twice to populate a buffer
https://bugs.webkit.org/show_bug.cgi?id=211499
Reviewed by Ross Kirsling.
* runtime/IntlDateTimeFormat.cpp:
(JSC::defaultTimeZone): Use callBufferProducingFunction.
(JSC::canonicalizeTimeZoneName): Ditto.
(JSC::IntlDateTimeFormat::initializeDateTimeFormat): Ditto.
(JSC::IntlDateTimeFormat::format const): Ditto.
(JSC::IntlDateTimeFormat::formatToParts const): Ditto.
* runtime/IntlLocale.cpp:
(JSC::LocaleIDBuilder::toCanonical): Ditto.
(JSC::IntlLocale::language): Ditto.
(JSC::IntlLocale::script): Ditto.
(JSC::IntlLocale::region): Ditto.
* runtime/IntlNumberFormat.cpp:
(JSC::IntlNumberFormat::format const): Ditto.
(JSC::IntlNumberFormat::formatToParts const): Ditto.
* runtime/IntlObject.cpp:
(JSC::languageTagForLocaleID): Ditto.
* runtime/IntlRelativeTimeFormat.cpp:
(JSC::IntlRelativeTimeFormat::formatInternal const): Ditto.
(JSC::IntlRelativeTimeFormat::formatToParts const): Ditto.
* runtime/StringPrototype.cpp:
(JSC::toLocaleCase): Ditto.
2020-05-06 Devin Rousso <drousso@apple.com>
ASSERT_WITH_MESSAGE(m_isOwnedByMainThread == isMainThread()) when web inspecting
https://bugs.webkit.org/show_bug.cgi?id=203638
<rdar://problem/56761893>
Reviewed by Brian Burg.
Mark the `InspectorEnvironment::executionStopwatch` abstract function as `const` and have it
return a `Stopwatch&` instead of a `RefPtr<Stopwatch>&` as callers assume that it exists.
By not using a `RefPtr`, an additional `copyRef` can be avoided.
* inspector/InspectorEnvironment.h:
* inspector/JSGlobalObjectInspectorController.h:
* inspector/JSGlobalObjectInspectorController.cpp:
(Inspector::JSGlobalObjectInspectorController::executionStopwatch const): Added.
(Inspector::JSGlobalObjectInspectorController::executionStopwatch): Deleted.
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::didPause):
(Inspector::InspectorDebuggerAgent::breakpointActionProbe):
(Inspector::InspectorDebuggerAgent::didContinue):
* inspector/agents/InspectorHeapAgent.cpp:
(Inspector::InspectorHeapAgent::snapshot):
(Inspector::InspectorHeapAgent::willGarbageCollect):
(Inspector::InspectorHeapAgent::didGarbageCollect):
* inspector/agents/InspectorScriptProfilerAgent.cpp:
(Inspector::InspectorScriptProfilerAgent::startTracking):
(Inspector::InspectorScriptProfilerAgent::willEvaluateScript):
(Inspector::InspectorScriptProfilerAgent::didEvaluateScript):
(Inspector::InspectorScriptProfilerAgent::trackingComplete):
* runtime/SamplingProfiler.h:
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::SamplingProfiler):
* runtime/VM.h:
* runtime/VM.cpp:
(JSC::VM::ensureSamplingProfiler):
2020-05-05 Ross Kirsling <ross.kirsling@sony.com>
[ECMA-402] Implement Intl.Locale
https://bugs.webkit.org/show_bug.cgi?id=209772
Reviewed by Darin Adler and Saam Barati.
This patch implements the recent ECMA-402 feature Intl.Locale.
This is effectively a wrapper class for all the pieces of uloc.h that ECMA-402 cares about.
(If we used the C++ API, there's a LocaleBuilder that would make this much easier, but in sticking to the C API,
it's basically an object that has an ICU localeID as data and uloc_* functions as methods / getters.
Furthermore, there's no way to modify said data, so every method / getter can be lazy and cache its result.)
Usage example:
>>> locale = new Intl.Locale('ja', { region: 'JP', calendar: 'japanese', numeric: false })
"ja-JP-u-ca-japanese-kn-false"
>>> locale.baseName
"ja-JP"
Intl.Locale can be used anywhere that Intl APIs accept locale strings as input parameters,
and is moreover hoped to be the class by which future Web APIs will handle the current locale.
This feature is runtime-guarded by the `useIntlLocale` option.
* CMakeLists.txt:
* DerivedSources-input.xcfilelist:
* DerivedSources-output.xcfilelist:
* DerivedSources.make:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* runtime/CommonIdentifiers.h:
* runtime/IntlLocale.cpp: Added.
* runtime/IntlLocale.h: Added.
* runtime/IntlLocaleConstructor.cpp: Added.
* runtime/IntlLocaleConstructor.h: Added.
* runtime/IntlLocalePrototype.cpp: Added.
* runtime/IntlLocalePrototype.h: Added.
* runtime/IntlObject.cpp:
(JSC::IntlObject::finishCreation):
(JSC::localeIDBufferForLanguageTag): Added.
(JSC::languageTagForLocaleID): Renamed from JSC::convertICULocaleToBCP47LanguageTag.
(JSC::intlAvailableLocales):
(JSC::intlCollatorAvailableLocales):
(JSC::canonicalizeLanguageTag):
(JSC::canonicalizeLocaleList):
(JSC::defaultLocale):
* runtime/IntlObject.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::collatorStructure):
(JSC::JSGlobalObject::numberFormatStructure):
(JSC::JSGlobalObject::localeStructure):
* runtime/OptionsList.h:
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
2020-05-05 Keith Miller <keith_miller@apple.com>
clobberize validator should use branchTest8 directly.
https://bugs.webkit.org/show_bug.cgi?id=211469
Reviewed by Yusuke Suzuki.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCurrentBlock):
2020-05-05 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Implement BigInt.asIntN and BigInt.asUintN
https://bugs.webkit.org/show_bug.cgi?id=181144
Reviewed by Darin Adler.
This patch implements BigInt.asIntN[1] and BigInt.asUintN[2] features.
As the same to the other BigInt runtime C++ code, we port V8 code to JSC to implement both.
BigInt.asIntN is `static_cast<intN_t>(BigInt value)` and BigInt.asUintN is `static_cast<uintN_t>(BigInt value)`.
They are getting slice of N bits from two's complement representation of the given BigInt. The difference between
asIntN and asUintN is asIntN renders MSB as a sign.
This patch is once rolled out due to ARM64_32 build failure, which is caused by the existing bug[3]. Relanding it
since it is now fixed.
[1]: https://tc39.es/ecma262/#sec-bigint.asintn
[2]: https://tc39.es/ecma262/#sec-bigint.asuintn
[3]: https://trac.webkit.org/changeset/261174/webkit
* runtime/BigIntConstructor.cpp:
(JSC::toBigInt):
(JSC::bigIntConstructorFuncAsUintN):
(JSC::bigIntConstructorFuncAsIntN):
* runtime/JSBigInt.cpp:
(JSC::zeroImpl):
(JSC::JSBigInt::divideImpl):
(JSC::JSBigInt::unaryMinusImpl):
(JSC::JSBigInt::remainderImpl):
(JSC::JSBigInt::digitDiv):
(JSC::JSBigInt::absoluteSub):
(JSC::JSBigInt::asIntNImpl):
(JSC::JSBigInt::asUintNImpl):
(JSC::JSBigInt::truncateToNBits):
(JSC::JSBigInt::truncateAndSubFromPowerOfTwo):
(JSC::JSBigInt::asIntN):
(JSC::JSBigInt::asUintN):
* runtime/JSBigInt.h:
2020-05-05 Ross Kirsling <ross.kirsling@sony.com>
[Intl] Alphabetize extension keys and correctly mark const methods
https://bugs.webkit.org/show_bug.cgi?id=211359
Reviewed by Darin Adler.
Two cleanup items for Intl classes:
1. Ensure `resolvedOptions().locale` returns relevant extension keys in alphabetical order.
ICU does this for us via Intl.getCanonicalLocales / Intl.*.supportedLocalesOf but not via ResolveLocale.
However, we don't need to do any sorting in ResolveLocale; we can just pre-alphabetize relevantExtensionKeys.
(See also https://github.com/tc39/ecma402/pull/433.)
2. Ensure Intl classes are marking const methods correctly.
* runtime/IntlCollator.cpp:
(JSC::IntlCollator::sortLocaleData):
(JSC::IntlCollator::searchLocaleData):
(JSC::IntlCollator::compareStrings const): Add const specifier.
(JSC::IntlCollator::resolvedOptions const): Add const specifier.
* runtime/IntlCollator.h:
* runtime/IntlDateTimeFormat.cpp:
(JSC::IntlDateTimeFormat::localeData):
(JSC::IntlDateTimeFormat::resolvedOptions const): Add const specifier.
(JSC::IntlDateTimeFormat::format const): Add const specifier.
(JSC::IntlDateTimeFormat::formatToParts const): Add const specifier.
* runtime/IntlDateTimeFormat.h:
* runtime/IntlNumberFormat.cpp:
(JSC::IntlNumberFormat::format const): Add const specifier.
(JSC::IntlNumberFormat::resolvedOptions const): Add const specifier.
(JSC::IntlNumberFormat::formatToParts const): Add const specifier.
* runtime/IntlNumberFormat.h:
* runtime/IntlPluralRules.cpp:
(JSC::IntlPluralRules::resolvedOptions const): Add const specifier.
(JSC::IntlPluralRules::select const): Add const specifier.
* runtime/IntlPluralRules.h:
* runtime/IntlRelativeTimeFormat.cpp:
(JSC::IntlRelativeTimeFormat::resolvedOptions const): Add const specifier.
(JSC::IntlRelativeTimeFormat::formatInternal const): Add const specifier.
(JSC::IntlRelativeTimeFormat::format const): Add const specifier.
(JSC::IntlRelativeTimeFormat::formatToParts const): Add const specifier.
* runtime/IntlRelativeTimeFormat.h:
2020-05-05 Keith Miller <keith_miller@apple.com>
Add Clobberize validator for clobber top.
https://bugs.webkit.org/show_bug.cgi?id=209432
Reviewed by Yusuke Suzuki.
* assembler/MacroAssemblerARMv7.h:
(JSC::MacroAssemblerARMv7::scratchRegister):
* assembler/MacroAssemblerMIPS.h:
(JSC::MacroAssemblerMIPS::scratchRegister):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCurrentBlock):
* dfg/DFGSpeculativeJIT64.cpp:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::lower):
(JSC::FTL::DFG::LowerDFGToB3::compileBlock):
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
* interpreter/Interpreter.cpp:
(JSC::eval):
(JSC::Interpreter::executeProgram):
(JSC::Interpreter::executeCall):
(JSC::Interpreter::executeConstruct):
(JSC::Interpreter::execute):
(JSC::Interpreter::executeModuleProgram):
* jit/JITCodeInlines.h:
(JSC::JITCode::execute):
* llint/LLIntThunks.h:
(JSC::vmEntryToWasm):
* runtime/OptionsList.h:
* runtime/VM.h:
2020-05-05 Mark Lam <mark.lam@apple.com>
Allow Bitmap to use up to a UCPURegister word size for internal bit storage.
https://bugs.webkit.org/show_bug.cgi?id=211328
<rdar://problem/62755865>
Reviewed by Yusuke Suzuki.
* assembler/CPU.h:
2020-05-05 Keith Miller <keith_miller@apple.com>
iterator_open should remap the symbolIterator argument correctly when inlined.
https://bugs.webkit.org/show_bug.cgi?id=211308
<rdar://problem/62287877>
Reviewed by Mark Lam.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
2020-05-05 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] JSBigInt::maxLengthBits and JSBigInt::maxLength are wrong
https://bugs.webkit.org/show_bug.cgi?id=211445
Reviewed by Mark Lam.
JSBigInt::maxLengthBits and JSBigInt::maxLength definitions are wrong.
1. We are defining maxLength and maxLengthBits as an unrelated value to each other. This is wrong.
maxLength should be defined as maxLengthBits / (sizeof(Digit) * bitsPerByte).
2. We use `sizeof(void*)` and assume that `sizeof(Digit) == sizeof(void*)`. This is wrong in ARM64_32 environment
where Digit size is sizeof(uint64_t) while the pointer size is sizeof(uint32_t). This causes compile errors in ARM64_32
when the code is using these values with static_assert.
* runtime/JSBigInt.h:
2020-05-05 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, reverting r261156.
Break ARM64_32 build due to existing bug
Reverted changeset:
"[JSC] Implement BigInt.asIntN and BigInt.asUintN"
https://bugs.webkit.org/show_bug.cgi?id=181144
https://trac.webkit.org/changeset/261156
2020-05-05 Alexey Shvayka <shvaikalesh@gmail.com>
Object.prototype.toString is not spec-perfect
https://bugs.webkit.org/show_bug.cgi?id=199138
Reviewed by Darin Adler and Keith Miller.
Before ES6, Object.prototype.toString relied only on internal [[Class]] slot. Starting with ES6,
Object.prototype.toString checks for a handful of internal slots, mimicing [[Class]], to ensure
backwards compatibility for pre-ES6 instances. Newly-added built-ins provide @@toStringTag for
the method to use.
Before this change, Object.prototype.toString in JSC relied on className() a.k.a [[Class]] for
all instances. For (almost all) new built-ins, it was overriden by toStringName() returning
"Object", while @@toStringTag was set to correct value. This is quite an error-prone approach
and observable spec discrepancy if @@toStringTag is deleted or set to a non-string.
This change eliminates the above-mentioned discrepancy and fixes Object.prototype.toString
to return "[object Function]" for callable Proxy objects, aligning JSC with the spec [1], V8,
and SpiderMonkey.
For Object.prototype.toString to work through DebuggerScope and JSProxy, we perform all checks
in JSObject::toStringName(). Given that isArray() may throw a TypeError [2], we invoke
toStringName() before @@toStringTag lookup to accomodate revoked Proxy case.
Also, this patch defines @@toStringTag for WebAssembly namespace object (to match Chrome),
JSC shell, and ConsoleObject.
[1]: https://tc39.es/ecma262/#sec-object.prototype.tostring
[2]: https://tc39.es/ecma262/#sec-isarray (step 3.a)
* jsc.cpp:
* runtime/BigIntObject.cpp:
(JSC::BigIntObject::toStringName): Deleted.
* runtime/BigIntObject.h:
* runtime/BooleanObject.cpp:
(JSC::BooleanObject::toStringName):
* runtime/BooleanObject.h:
* runtime/ConsoleObject.cpp:
(JSC::ConsoleObject::finishCreation):
* runtime/DateInstance.cpp:
(JSC::DateInstance::toStringName):
* runtime/DateInstance.h:
* runtime/ErrorInstance.cpp:
(JSC::ErrorInstance::toStringName):
* runtime/ErrorInstance.h:
* runtime/JSArrayBufferView.cpp:
(JSC::JSArrayBufferView::toStringName): Deleted.
* runtime/JSArrayBufferView.h:
* runtime/JSMap.cpp:
(JSC::JSMap::toStringName): Deleted.
* runtime/JSMap.h:
* runtime/JSObject.cpp:
(JSC::JSObject::toStringName):
* runtime/JSSet.cpp:
(JSC::JSSet::toStringName): Deleted.
* runtime/JSSet.h:
* runtime/JSWeakMap.cpp:
(JSC::JSWeakMap::toStringName): Deleted.
* runtime/JSWeakMap.h:
* runtime/JSWeakObjectRef.cpp:
(JSC::JSWeakObjectRef::toStringName): Deleted.
* runtime/JSWeakObjectRef.h:
* runtime/JSWeakSet.cpp:
(JSC::JSWeakSet::toStringName): Deleted.
* runtime/JSWeakSet.h:
* runtime/NumberObject.cpp:
(JSC::NumberObject::toStringName):
* runtime/NumberObject.h:
* runtime/ObjectPrototype.cpp:
(JSC::objectProtoFuncToString):
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::toStringName): Deleted.
* runtime/ProxyObject.h:
* runtime/RegExpObject.cpp:
(JSC::RegExpObject::toStringName):
* runtime/RegExpObject.h:
* runtime/StringObject.cpp:
(JSC::StringObject::toStringName):
* runtime/StringObject.h:
* runtime/SymbolObject.cpp:
(JSC::SymbolObject::toStringName): Deleted.
* runtime/SymbolObject.h:
* wasm/js/JSWebAssembly.cpp:
(JSC::JSWebAssembly::finishCreation):
2020-05-04 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Implement BigInt.asIntN and BigInt.asUintN
https://bugs.webkit.org/show_bug.cgi?id=181144
Reviewed by Darin Adler.
This patch implements BigInt.asIntN[1] and BigInt.asUintN[2] features.
As the same to the other BigInt runtime C++ code, we port V8 code to JSC to implement both.
BigInt.asIntN is `static_cast<intN_t>(BigInt value)` and BigInt.asUintN is `static_cast<uintN_t>(BigInt value)`.
They are getting slice of N bits from two's complement representation of the given BigInt. The difference between
asIntN and asUintN is asIntN renders MSB as a sign.
[1]: https://tc39.es/ecma262/#sec-bigint.asintn
[2]: https://tc39.es/ecma262/#sec-bigint.asuintn
* runtime/BigIntConstructor.cpp:
(JSC::toBigInt):
(JSC::bigIntConstructorFuncAsUintN):
(JSC::bigIntConstructorFuncAsIntN):
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::zeroImpl):
(JSC::JSBigInt::divideImpl):
(JSC::JSBigInt::unaryMinusImpl):
(JSC::JSBigInt::remainderImpl):
(JSC::JSBigInt::digitDiv):
(JSC::JSBigInt::asIntNImpl):
(JSC::JSBigInt::asUintNImpl):
(JSC::JSBigInt::truncateToNBits):
(JSC::JSBigInt::truncateAndSubFromPowerOfTwo):
(JSC::JSBigInt::asIntN):
(JSC::JSBigInt::asUintN):
* runtime/JSBigInt.h:
2020-05-04 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] DFG NotCellUse is used without considering about BigInt32
https://bugs.webkit.org/show_bug.cgi?id=211395
Reviewed by Saam Barati.
When we see CompareXXX(BigInt32, Double), we are emitting CompareXXX(DoubleRep(BigInt:NotCellUse), Double). But this has two problems.
1. We should emit CompareXXX(UntypedUse, UntypedUse) in this case.
2. DoubleRep(NotCellUse) does not support converting BigInt32 to double. Since DoubleRep's semantics is for ToNumber, it should not
accept BigInt32 since it should throw an error. However, DoubleRep currently assumes that NotCellUse value can be converted to double
without any errors.
To keep DoubleRep's semantics ToNumber, we replace NotCellUse with NotCellNorBigIntUse, which rejects BigInt32. This patch also uses NotCellNorBigIntUse
for ValueToInt32 because of the same reason.
For CompareXXX and CompareEq nodes, we can optimize it if we introduce new DoubleRepAcceptingBigInt32 DFG node which can convert BigInt32 to Double, since
CompareXXX and CompareEq are not requiring toNumber semantics. This should be done in a separate bug https://bugs.webkit.org/show_bug.cgi?id=211407.
* bytecode/SpeculatedType.h:
(JSC::isNotCellNorBigIntSpeculation):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::fixIntConvertingEdge):
(JSC::DFG::FixupPhase::fixupChecksInBlock):
* dfg/DFGNode.h:
(JSC::DFG::Node::shouldSpeculateNotCellNorBigInt):
* dfg/DFGSafeToExecute.h:
(JSC::DFG::SafeToExecuteEdge::operator()):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileValueToInt32):
(JSC::DFG::SpeculativeJIT::compileDoubleRep):
(JSC::DFG::SpeculativeJIT::speculateNotCellNorBigInt):
(JSC::DFG::SpeculativeJIT::speculate):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGUseKind.cpp:
(WTF::printInternal):
* dfg/DFGUseKind.h:
(JSC::DFG::typeFilterFor):
(JSC::DFG::checkMayCrashIfInputIsEmpty):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileDoubleRep):
(JSC::FTL::DFG::LowerDFGToB3::compileValueToInt32):
(JSC::FTL::DFG::LowerDFGToB3::numberOrNotCellNorBigIntToInt32):
(JSC::FTL::DFG::LowerDFGToB3::speculate):
(JSC::FTL::DFG::LowerDFGToB3::speculateNotCellNorBigInt):
(JSC::FTL::DFG::LowerDFGToB3::numberOrNotCellToInt32): Deleted.
2020-05-04 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Add @@toStringTag to WebAssembly.Global
https://bugs.webkit.org/show_bug.cgi?id=211372
Reviewed by Sam Weinig.
As r260992 did for the other wasm prototypes, we should put @@toStringTag to WebAssembly.Global's prototype too.
* wasm/js/WebAssemblyGlobalPrototype.cpp:
(JSC::WebAssemblyGlobalPrototype::finishCreation):
2020-05-04 Devin Rousso <drousso@apple.com>
Web Inspector: Worker: should use the name of the worker if it exists
https://bugs.webkit.org/show_bug.cgi?id=211244
Reviewed by Brian Burg.
* inspector/protocol/Worker.json:
Include the `name` in `Worker.workerCreated`.
2020-05-04 Devin Rousso <drousso@apple.com>
Web Inspector: provide a way for inspector to turn on/off ITP debug mode and AdClickAttribution debug mode
https://bugs.webkit.org/show_bug.cgi?id=209763
Reviewed by Brian Burg.
* inspector/protocol/Page.json:
Add new enum values to `Page.Setting`:
- `AdClickAttributionDebugModeEnabled`
- `ITPDebugModeEnabled`
2020-05-03 Maciej Stachowiak <mjs@apple.com>
Remove no longer needed WebKitAdditions include for JavaScriptCorePrefix.h
https://bugs.webkit.org/show_bug.cgi?id=211357
Reviewed by Mark Lam.
* JavaScriptCorePrefix.h:
2020-05-02 Mark Lam <mark.lam@apple.com>
Gardening: rolling out r261050 and r261051.
https://bugs.webkit.org/show_bug.cgi?id=211328
<rdar://problem/62755865>
Not reviewed.
* assembler/CPU.h:
2020-05-01 Mark Lam <mark.lam@apple.com>
Allow Bitmap to use up to a UCPURegister word size for internal bit storage.
https://bugs.webkit.org/show_bug.cgi?id=211328
<rdar://problem/62755865>
Reviewed by Yusuke Suzuki.
* assembler/CPU.h:
2020-05-01 Saam Barati <sbarati@apple.com>
Have a thread local cache for the Wasm LLInt bytecode buffer
https://bugs.webkit.org/show_bug.cgi?id=211317
Reviewed by Filip Pizlo and Mark Lam.
One of the main things slowing down Wasm compile times is the banging
on bmalloc's global heap lock. This patch makes it so for the bytecode
instruction buffer, we keep a thread local cache with latest capacity
the thread needed to compile. This makes it so that in the average case,
we only do one malloc at the end of a compile to memcpy the final result.
We clear these thread local caches when the WasmWorklist's automatic threads
underlying machine thread is destroyed.
This is a 15% speedup in zen garden compile times on a 16-core Mac Pro.
This is a 4-5% speedup in zen garden compile times on a 6-core MBP.
* bytecode/InstructionStream.h:
(JSC::InstructionStreamWriter::setInstructionBuffer):
(JSC::InstructionStreamWriter::finalize):
* wasm/WasmLLIntGenerator.cpp:
(JSC::Wasm::threadSpecificBuffer):
(JSC::Wasm::clearLLIntThreadSpecificCache):
(JSC::Wasm::LLIntGenerator::LLIntGenerator):
(JSC::Wasm::LLIntGenerator::finalize):
* wasm/WasmLLIntGenerator.h:
* wasm/WasmWorklist.cpp:
2020-05-01 Per Arne Vollan <pvollan@apple.com>
[Win] Fix AppleWin build
https://bugs.webkit.org/show_bug.cgi?id=211324
Reviewed by Don Olmstead.
Check if target WTF_CopyHeaders exists before using it.
* CMakeLists.txt:
2020-05-01 Don Olmstead <don.olmstead@sony.com>
[GTK] Add additional exports to support hidden visibility
https://bugs.webkit.org/show_bug.cgi?id=211246
Reviewed by Michael Catanzaro.
* API/glib/JSCContextPrivate.h:
* API/glib/JSCValuePrivate.h:
* inspector/remote/glib/RemoteInspectorServer.h:
* inspector/remote/glib/RemoteInspectorUtils.h:
2020-05-01 Don Olmstead <don.olmstead@sony.com>
Use export macros on all platforms
https://bugs.webkit.org/show_bug.cgi?id=211293
Reviewed by Michael Catanzaro.
Allow overriding of JS_EXPORT_PRIVATE if desired otherwise use the defaults.
* runtime/JSExportMacros.h:
2020-05-01 Saam Barati <sbarati@apple.com>
Unreviewed. Non-speculative build fix for watchOS build.
* runtime/ArrayPrototype.cpp:
(JSC::shift):
(JSC::unshift):
(JSC::arrayProtoFuncToLocaleString):
(JSC::arrayProtoFuncReverse):
(JSC::arrayProtoFuncSlice):
(JSC::arrayProtoFuncSplice):
* runtime/JSONObject.cpp:
(JSC::Stringifier::Stringifier):
2020-05-01 Saam Barati <sbarati@apple.com>
Unreviewed. Speculative build fix for watchOS build.
* runtime/ArrayPrototype.cpp:
(JSC::shift):
2020-05-01 Alexey Shvayka <shvaikalesh@gmail.com>
[WebIDL] Interface prototype objects should define @@toStringTag
https://bugs.webkit.org/show_bug.cgi?id=211020
Unreviewed follow-up to r260992.
* runtime/JSArrayBufferPrototype.cpp:
(JSC::JSArrayBufferPrototype::finishCreation): Revert change in attempt to fix ARMv7 test.
2020-05-01 David Kilzer <ddkilzer@apple.com>
JSC::PropertySlot::m_attributes is uninitialized in constructor
<https://webkit.org/b/211267>
Reviewed by Mark Lam.
* runtime/PropertySlot.h:
(JSC::PropertySlot::PropertySlot):
- Initialize m_attributes and m_additionalData, and make use of
default initializers.
2020-05-01 Alexey Shvayka <shvaikalesh@gmail.com>
[WebIDL] Interface prototype objects should define @@toStringTag
https://bugs.webkit.org/show_bug.cgi?id=211020
Reviewed by Darin Adler.
WebIDL spec was recently updated [1] to define @@toStringTag on interface prototype objects.
This change aligns WebIDL with ECMA-262 built-ins and Blink's behavior. Gecko have also
expressed implementation commitment.
This patch implements the spec change, making `X.prototype.toString()` return "[object X]"
instead of "[object XPrototype]", where X is WebIDL interface. This behavior is proven to
be web compatible (shipping in Chrome since Q2 2016) and matches class strings of iterator
prototype objects [2] introduced in r253855.
We define @@toStringTag for all WebAssembly interfaces but Error subclasses since they
are not defined using WebIDL [3].
This change also introduces JSC_TO_STRING_TAG_WITHOUT_TRANSITION() macro that sets up
@@toStringTag using ClassInfo to avoid extra strings creation, ensuring `className` equality
between prototype and instance classes (fixing a few discrepancies), as well as correct
descriptors. It also ensures using faster jsNontrivialString() and relieves from putting
more code into CodeGeneratorJS.pm.
[1]: https://github.com/heycam/webidl/pull/357
[2]: https://heycam.github.io/webidl/#es-iterator-prototype-object
[3]: https://webassembly.github.io/spec/js-api/#error-objects
Tests: imported/w3c/web-platform-tests/wasm/jsapi/instance/toString.any.js
imported/w3c/web-platform-tests/wasm/jsapi/memory/toString.any.js
imported/w3c/web-platform-tests/wasm/jsapi/module/toString.any.js
imported/w3c/web-platform-tests/wasm/jsapi/table/toString.any.js
* runtime/ArrayIteratorPrototype.cpp:
(JSC::ArrayIteratorPrototype::finishCreation):
* runtime/AsyncFunctionPrototype.cpp:
(JSC::AsyncFunctionPrototype::finishCreation):
* runtime/AsyncGeneratorFunctionPrototype.cpp:
(JSC::AsyncGeneratorFunctionPrototype::finishCreation):
* runtime/AsyncGeneratorPrototype.cpp:
(JSC::AsyncGeneratorPrototype::finishCreation):
* runtime/BigIntPrototype.cpp:
(JSC::BigIntPrototype::finishCreation):
* runtime/GeneratorFunctionPrototype.cpp:
(JSC::GeneratorFunctionPrototype::finishCreation):
* runtime/GeneratorPrototype.cpp:
(JSC::GeneratorPrototype::finishCreation):
* runtime/IntlCollatorPrototype.cpp:
(JSC::IntlCollatorPrototype::finishCreation):
* runtime/IntlDateTimeFormatPrototype.cpp:
(JSC::IntlDateTimeFormatPrototype::finishCreation):
* runtime/IntlNumberFormatPrototype.cpp:
(JSC::IntlNumberFormatPrototype::finishCreation):
* runtime/IntlPluralRulesPrototype.cpp:
(JSC::IntlPluralRulesPrototype::finishCreation):
* runtime/IntlRelativeTimeFormatPrototype.cpp:
(JSC::IntlRelativeTimeFormatPrototype::finishCreation):
* runtime/JSArrayBufferPrototype.cpp:
(JSC::JSArrayBufferPrototype::finishCreation):
* runtime/JSDataViewPrototype.cpp:
(JSC::JSDataViewPrototype::finishCreation):
* runtime/JSONObject.cpp:
(JSC::JSONObject::finishCreation):
* runtime/JSObject.h:
* runtime/JSPromisePrototype.cpp:
(JSC::JSPromisePrototype::finishCreation):
* runtime/MapIteratorPrototype.cpp:
(JSC::MapIteratorPrototype::finishCreation):
* runtime/MapPrototype.cpp:
(JSC::MapPrototype::finishCreation):
* runtime/MathObject.cpp:
(JSC::MathObject::finishCreation):
* runtime/RegExpStringIteratorPrototype.cpp:
(JSC::RegExpStringIteratorPrototype::finishCreation):
* runtime/SetIteratorPrototype.cpp:
(JSC::SetIteratorPrototype::finishCreation):
* runtime/SetPrototype.cpp:
(JSC::SetPrototype::finishCreation):
* runtime/StringIteratorPrototype.cpp:
(JSC::StringIteratorPrototype::finishCreation):
* runtime/SymbolPrototype.cpp:
(JSC::SymbolPrototype::finishCreation):
* runtime/WeakMapPrototype.cpp:
(JSC::WeakMapPrototype::finishCreation):
* runtime/WeakObjectRefPrototype.cpp:
(JSC::WeakObjectRefPrototype::finishCreation):
* runtime/WeakSetPrototype.cpp:
(JSC::WeakSetPrototype::finishCreation):
* wasm/js/WebAssemblyInstancePrototype.cpp:
(JSC::WebAssemblyInstancePrototype::finishCreation):
* wasm/js/WebAssemblyMemoryPrototype.cpp:
(JSC::WebAssemblyMemoryPrototype::finishCreation):
* wasm/js/WebAssemblyModulePrototype.cpp:
(JSC::WebAssemblyModulePrototype::finishCreation):
* wasm/js/WebAssemblyTablePrototype.cpp:
(JSC::WebAssemblyTablePrototype::finishCreation):
2020-05-01 Saam Barati <sbarati@apple.com>
We can't cast toLength result to unsigned
https://bugs.webkit.org/show_bug.cgi?id=211205
<rdar://problem/62625562>
Reviewed by Yusuke Suzuki.
toLength, according to the spec, returns a 53-bit integer. In our
implementation, we return a double. However, there were many callsites
that did something like:
```
unsigned length = toLength(obj);
```
This is bad for a few reasons:
- Casting to unsigned from double is undefined behavior when the integer
is greater than UINT_MAX. In practice, this means that we'd have different
engine behavior depending on what architecture we'd be running on. For
example, if the length were UINT_MAX + 1, on x86, we'd treat the
length as zero. On arm64, we'd treat it as UINT_MAX. Both are wrong.
- We weren't spec compliant. We were just ignoring that these numbers could
be 53-bit integers.
This patch addresses each bad use of the undefined behavior, and by doing so,
makes us more spec compliant.
* dfg/DFGOperations.cpp:
* jit/JITOperations.cpp:
(JSC::getByVal):
* runtime/ArrayPrototype.cpp:
(JSC::getProperty):
(JSC::setLength):
(JSC::argumentClampedIndexFromStartOrEnd):
(JSC::shift):
(JSC::unshift):
(JSC::arrayProtoFuncToLocaleString):
(JSC::arrayProtoFuncPop):
(JSC::arrayProtoFuncPush):
(JSC::arrayProtoFuncReverse):
(JSC::arrayProtoFuncShift):
(JSC::arrayProtoFuncSlice):
(JSC::arrayProtoFuncSplice):
(JSC::arrayProtoFuncUnShift):
(JSC::fastIndexOf):
(JSC::arrayProtoFuncIndexOf):
(JSC::arrayProtoFuncLastIndexOf):
* runtime/Identifier.h:
(JSC::Identifier::from):
* runtime/IntlObject.cpp:
(JSC::canonicalizeLocaleList):
* runtime/JSONObject.cpp:
(JSC::Stringifier::Stringifier):
(JSC::Stringifier::Holder::appendNextProperty):
(JSC::Walker::walk):
* runtime/JSObject.cpp:
(JSC::JSObject::hasProperty const):
* runtime/JSObject.h:
(JSC::JSObject::putByIndexInline):
(JSC::JSObject::putDirectIndex):
(JSC::JSObject::canGetIndexQuickly const):
(JSC::JSObject::tryGetIndexQuickly const):
* runtime/JSObjectInlines.h:
(JSC::JSObject::getPropertySlot):
(JSC::JSObject::deleteProperty):
(JSC::JSObject::get const):
* runtime/PropertySlot.h:
(JSC::PropertySlot::getValue const):
* tools/JSDollarVM.cpp:
(JSC::functionSetUserPreferredLanguages):
2020-04-30 Ross Kirsling <ross.kirsling@sony.com>
TriState should be an enum class and use "Indeterminate" instead of "Mixed"
https://bugs.webkit.org/show_bug.cgi?id=211268
Reviewed by Mark Lam.
* b3/B3Const32Value.cpp:
(JSC::B3::Const32Value::equalConstant const):
(JSC::B3::Const32Value::notEqualConstant const):
(JSC::B3::Const32Value::lessThanConstant const):
(JSC::B3::Const32Value::greaterThanConstant const):
(JSC::B3::Const32Value::lessEqualConstant const):
(JSC::B3::Const32Value::greaterEqualConstant const):
(JSC::B3::Const32Value::aboveConstant const):
(JSC::B3::Const32Value::belowConstant const):
(JSC::B3::Const32Value::aboveEqualConstant const):
(JSC::B3::Const32Value::belowEqualConstant const):
* b3/B3Const64Value.cpp:
(JSC::B3::Const64Value::equalConstant const):
(JSC::B3::Const64Value::notEqualConstant const):
(JSC::B3::Const64Value::lessThanConstant const):
(JSC::B3::Const64Value::greaterThanConstant const):
(JSC::B3::Const64Value::lessEqualConstant const):
(JSC::B3::Const64Value::greaterEqualConstant const):
(JSC::B3::Const64Value::aboveConstant const):
(JSC::B3::Const64Value::belowConstant const):
(JSC::B3::Const64Value::aboveEqualConstant const):
(JSC::B3::Const64Value::belowEqualConstant const):
* b3/B3ConstDoubleValue.cpp:
(JSC::B3::ConstDoubleValue::equalConstant const):
(JSC::B3::ConstDoubleValue::notEqualConstant const):
(JSC::B3::ConstDoubleValue::lessThanConstant const):
(JSC::B3::ConstDoubleValue::greaterThanConstant const):
(JSC::B3::ConstDoubleValue::lessEqualConstant const):
(JSC::B3::ConstDoubleValue::greaterEqualConstant const):
(JSC::B3::ConstDoubleValue::equalOrUnorderedConstant const):
* b3/B3ConstFloatValue.cpp:
(JSC::B3::ConstFloatValue::equalConstant const):
(JSC::B3::ConstFloatValue::notEqualConstant const):
(JSC::B3::ConstFloatValue::lessThanConstant const):
(JSC::B3::ConstFloatValue::greaterThanConstant const):
(JSC::B3::ConstFloatValue::lessEqualConstant const):
(JSC::B3::ConstFloatValue::greaterEqualConstant const):
(JSC::B3::ConstFloatValue::equalOrUnorderedConstant const):
* b3/B3Procedure.cpp:
(JSC::B3::Procedure::addBoolConstant):
* b3/B3Procedure.h:
* b3/B3ReduceStrength.cpp:
* b3/B3Value.cpp:
(JSC::B3::Value::equalConstant const):
(JSC::B3::Value::notEqualConstant const):
(JSC::B3::Value::lessThanConstant const):
(JSC::B3::Value::greaterThanConstant const):
(JSC::B3::Value::lessEqualConstant const):
(JSC::B3::Value::greaterEqualConstant const):
(JSC::B3::Value::aboveConstant const):
(JSC::B3::Value::belowConstant const):
(JSC::B3::Value::aboveEqualConstant const):
(JSC::B3::Value::belowEqualConstant const):
(JSC::B3::Value::equalOrUnorderedConstant const):
(JSC::B3::Value::asTriState const):
* b3/B3Value.h:
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::~CodeBlock):
(JSC::CodeBlock::thresholdForJIT):
* bytecode/UnlinkedCodeBlock.cpp:
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* bytecode/UnlinkedFunctionExecutable.cpp:
(JSC::UnlinkedFunctionExecutable::visitChildren):
* bytecompiler/NodesCodegen.cpp:
(JSC::ConstantNode::emitBytecodeInConditionContext):
(JSC::BinaryOpNode::emitBytecodeInConditionContext):
(JSC::BinaryOpNode::tryFoldToBranch):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
* dfg/DFGCFGSimplificationPhase.cpp:
(JSC::DFG::CFGSimplificationPhase::run):
* dfg/DFGLazyJSValue.cpp:
(JSC::DFG::equalToSingleCharacter):
(JSC::DFG::equalToStringImpl):
(JSC::DFG::LazyJSValue::strictEqual const):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileDataViewGet):
(JSC::FTL::DFG::LowerDFGToB3::compileDataViewSet):
* ftl/FTLOutput.cpp:
(JSC::FTL::Output::equal):
(JSC::FTL::Output::notEqual):
(JSC::FTL::Output::above):
(JSC::FTL::Output::aboveOrEqual):
(JSC::FTL::Output::below):
(JSC::FTL::Output::belowOrEqual):
(JSC::FTL::Output::greaterThan):
(JSC::FTL::Output::greaterThanOrEqual):
(JSC::FTL::Output::lessThan):
(JSC::FTL::Output::lessThanOrEqual):
* jit/JITOperations.cpp:
* runtime/CachedTypes.cpp:
(JSC::UnlinkedCodeBlock::UnlinkedCodeBlock):
* runtime/DefinePropertyAttributes.h:
(JSC::DefinePropertyAttributes::DefinePropertyAttributes):
(JSC::DefinePropertyAttributes::hasWritable const):
(JSC::DefinePropertyAttributes::writable const):
(JSC::DefinePropertyAttributes::hasConfigurable const):
(JSC::DefinePropertyAttributes::configurable const):
(JSC::DefinePropertyAttributes::hasEnumerable const):
(JSC::DefinePropertyAttributes::enumerable const):
(JSC::DefinePropertyAttributes::setWritable):
(JSC::DefinePropertyAttributes::setConfigurable):
(JSC::DefinePropertyAttributes::setEnumerable):
* runtime/IntlCollator.cpp:
(JSC::IntlCollator::initializeCollator):
* runtime/IntlDateTimeFormat.cpp:
(JSC::IntlDateTimeFormat::initializeDateTimeFormat):
* runtime/IntlNumberFormat.cpp:
(JSC::IntlNumberFormat::initializeNumberFormat):
* runtime/IntlObject.cpp:
(JSC::intlBooleanOption):
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::pureStrictEqual):
(JSC::JSValue::pureToBoolean const):
* runtime/JSCellInlines.h:
(JSC::JSCell::pureToBoolean const):
2020-04-30 Ross Kirsling <ross.kirsling@sony.com>
[JSC] intlBooleanOption should return TriState instead of taking an out param
https://bugs.webkit.org/show_bug.cgi?id=211256
Reviewed by Darin Adler and Mark Lam.
Boolean options for Intl constructors can have default values of true, false, or undefined.
To handle the undefined case, intlBooleanOption currently has a `bool& usesFallback` param;
we should have the return type simply be a TriState instead.
* runtime/IntlCollator.cpp:
(JSC::IntlCollator::initializeCollator):
* runtime/IntlDateTimeFormat.cpp:
(JSC::IntlDateTimeFormat::initializeDateTimeFormat):
* runtime/IntlNumberFormat.cpp:
(JSC::IntlNumberFormat::initializeNumberFormat):
* runtime/IntlObject.cpp:
(JSC::intlBooleanOption):
* runtime/IntlObject.h:
2020-04-30 Devin Rousso <drousso@apple.com>
WebKit.WebContent process crashes when web developer tools are opened in Safari
https://bugs.webkit.org/show_bug.cgi?id=210794
<rdar://problem/62214651>
Reviewed by Brian Burg.
* inspector/InjectedScriptManager.cpp:
(Inspector::InjectedScriptManager::injectedScriptFor):
Don't crash if a `TerminatedExecutionError` is thrown.
* inspector/InjectedScriptBase.cpp:
(Inspector::InjectedScriptBase::makeCall):
Report the actual error message. Check that the result has a value before attempting to make
a `JSON::Value` out of it.
2020-04-29 Ross Kirsling <ross.kirsling@sony.com>
Ensure Intl classes don't have naming conflicts with unified builds
https://bugs.webkit.org/show_bug.cgi?id=211213
Reviewed by Yusuke Suzuki.
Each Intl class usually has an array named relevantExtensionsKeys and a function named localeData.
This can result in redefinition errors when unified builds put two of them into the same translation unit.
Some are already guarding against this with an internal namespace while others are not.
As a uniform approach, this patch makes each localeData function a static method and
puts each relevantExtensionsKeys array (as well as any constants for its indices) into an internal namespace.
Furthermore, since three different classes are defining an identical UFieldPositionIteratorDeleter,
this patch consolidates them into one definition in IntlObject.
* runtime/IntlCollator.cpp:
(JSC::IntlCollator::sortLocaleData): Renamed from JSC::sortLocaleData.
(JSC::IntlCollator::searchLocaleData): Renamed from JSC::searchLocaleData.
(JSC::IntlCollator::initializeCollator):
* runtime/IntlCollator.h:
* runtime/IntlDateTimeFormat.cpp:
(JSC::IntlDateTimeFormat::localeData): Renamed from JSC::IntlDTFInternal::localeData.
(JSC::toDateTimeOptionsAnyDate): Renamed from JSC::IntlDTFInternal::toDateTimeOptionsAnyDate.
(JSC::IntlDateTimeFormat::initializeDateTimeFormat):
(JSC::UFieldPositionIteratorDeleter::operator() const): Deleted.
* runtime/IntlDateTimeFormat.h:
* runtime/IntlNumberFormat.cpp:
(JSC::IntlNumberFormat::localeData): Renamed from JSC::IntlNFInternal::localeData.
(JSC::IntlNumberFormat::initializeNumberFormat):
(JSC::UFieldPositionIteratorDeleter::operator() const): Deleted.
* runtime/IntlNumberFormat.h:
* runtime/IntlObject.cpp:
(JSC::UFieldPositionIteratorDeleter::operator() const): Added.
* runtime/IntlObject.h:
* runtime/IntlPluralRules.cpp:
(JSC::IntlPluralRules::localeData): Renamed from JSC::localeData.
* runtime/IntlPluralRules.h:
* runtime/IntlRelativeTimeFormat.cpp:
(JSC::IntlRelativeTimeFormat::localeData): Renamed from JSC::localeData.
(JSC::IntlRelativeTimeFormat::initializeRelativeTimeFormat):
(JSC::UFieldPositionIteratorDeleter::operator() const): Deleted.
* runtime/IntlRelativeTimeFormat.h:
2020-04-29 Ross Kirsling <ross.kirsling@sony.com>
Unreviewed follow-up to r260848.
LowerDFGToB3 has its own isFunction which should NOT have been renamed.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCreateThis):
(JSC::FTL::DFG::LowerDFGToB3::compileCreatePromise):
(JSC::FTL::DFG::LowerDFGToB3::compileCreateInternalFieldObject):
(JSC::FTL::DFG::LowerDFGToB3::compileIsObjectOrNull):
(JSC::FTL::DFG::LowerDFGToB3::compileIsFunction):
(JSC::FTL::DFG::LowerDFGToB3::buildTypeOf):
(JSC::FTL::DFG::LowerDFGToB3::isFunction): Renamed from isCallable.
2020-04-29 Alexey Shvayka <shvaikalesh@gmail.com>
AsyncFromSyncIterator methods should not pass absent values
https://bugs.webkit.org/show_bug.cgi?id=211147
Reviewed by Ross Kirsling.
This patch implements minor spec change [1] to match async and sync iteration
from the perspective of userland `next` and `return` iterator methods.
`throw` method always receives an argument, yet we align with others to be
consistent and future-proof.
This change is already implemented in SpiderMonkey.
[1]: https://github.com/tc39/ecma262/pull/1776
* builtins/AsyncFromSyncIteratorPrototype.js:
2020-04-29 Mark Lam <mark.lam@apple.com>
Freezing of Gigacage and JSC Configs should be thread safe.
https://bugs.webkit.org/show_bug.cgi?id=211201
<rdar://problem/62597619>
Reviewed by Yusuke Suzuki.
If a client creates multiple VM instances in different threads concurrently, the
following race can occur:
Config::permanentlyFreeze() contains the following code:
if (!g_jscConfig.isPermanentlyFrozen) // Point P1
g_jscConfig.isPermanentlyFrozen = true; // Point P2
Let's say there are 2 threads T1 and T2.
1. T1 creates a VM and gets to point P1, and sees that g_jscConfig.isPermanentlyFrozen is not set.
T1 is about to execute P2 when it gets pre-empted.
2. T2 creates a VM and gets to point P1, and sees that g_jscConfig.isPermanentlyFrozen is not set.
T2 proceeds to point P2 and sets g_jscConfig.isPermanentlyFrozen to true.
T2 goes on to freeze the Config and makes it not writable.
3. T1 gets to run again, and proceeds to point P2.
T1 tries to set g_jscConfig.isPermanentlyFrozen to true.
But because the Config has been frozen against writes, the write to
g_jscConfig.isPermanentlyFrozen results in a crash.
This is a classic TOCTOU bug. The fix is simply to ensure that only one thread
can enter Config::permanentlyFreeze() at a time.
Ditto for Gigacage::permanentlyFreezeGigacageConfig().
* runtime/JSCConfig.cpp:
(JSC::Config::permanentlyFreeze):
2020-04-29 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] JSStringJoiner is missing BigInt handling
https://bugs.webkit.org/show_bug.cgi?id=211174
Reviewed by Mark Lam.
JSStringJoiner missed handling of BigInt (specifically BigInt32) and appending empty string incorrectly.
In debug build, assertion hits. We should support BigInt in JSStringJoiner.
* runtime/JSStringJoiner.h:
(JSC::JSStringJoiner::appendWithoutSideEffects):
2020-04-29 Saam Barati <sbarati@apple.com>
U_STRING_NOT_TERMINATED_WARNING ICU must be handled when using the output buffer as a C string
https://bugs.webkit.org/show_bug.cgi?id=211142
<rdar://problem/62530860>
Reviewed by Darin Adler.
* runtime/IntlDateTimeFormat.cpp:
(JSC::defaultTimeZone):
(JSC::canonicalizeTimeZoneName):
(JSC::IntlDateTimeFormat::initializeDateTimeFormat):
(JSC::IntlDateTimeFormat::format):
(JSC::IntlDateTimeFormat::formatToParts):
* runtime/IntlNumberFormat.cpp:
(JSC::IntlNumberFormat::format):
(JSC::IntlNumberFormat::formatToParts):
* runtime/IntlObject.cpp:
(JSC::convertICULocaleToBCP47LanguageTag):
(JSC::canonicalizeLanguageTag):
* runtime/IntlRelativeTimeFormat.cpp:
(JSC::IntlRelativeTimeFormat::formatInternal):
(JSC::IntlRelativeTimeFormat::formatToParts):
* runtime/StringPrototype.cpp:
(JSC::toLocaleCase):
(JSC::normalize):
2020-04-28 Saam Barati <sbarati@apple.com>
Unreviewed. Fix 32-bit build.
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::createFrom):
(JSC::Int32BigIntImpl::digit):
2020-04-28 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r260876 and r260877.
https://bugs.webkit.org/show_bug.cgi?id=211165
Broke build (Requested by yusukesuzuki on #webkit).
Reverted changesets:
"Unreviewed, build fix on watchOS"
https://bugs.webkit.org/show_bug.cgi?id=210978
https://trac.webkit.org/changeset/260876
"Unreviewed, speculative build fix on watchOS part 2"
https://bugs.webkit.org/show_bug.cgi?id=210978
https://trac.webkit.org/changeset/260877
2020-04-28 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, speculative build fix on watchOS part 2
https://bugs.webkit.org/show_bug.cgi?id=210978
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::createFrom):
(JSC::Int32BigIntImpl::digit):
* runtime/JSBigInt.h:
2020-04-28 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, build fix on watchOS
https://bugs.webkit.org/show_bug.cgi?id=210978
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::createFrom):
(JSC::Int32BigIntImpl::digit):
* runtime/JSBigInt.h:
2020-04-28 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] BigInt constructor should accept larger integers than safe-integers
https://bugs.webkit.org/show_bug.cgi?id=210755
Reviewed by Darin Adler.
While our implementation of BigInt constructor only accepts safe integers, it should accept all integers.
This patch implements it by creating JSBigInt::createFrom(double). We port double bit processing part from
V8 as the same to the other part of JSBigInt.
* runtime/BigIntConstructor.cpp:
(JSC::callBigIntConstructor):
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::createFrom):
* runtime/JSBigInt.h:
* runtime/MathCommon.h:
(JSC::isInteger):
(JSC::isSafeInteger):
* runtime/NumberConstructor.cpp:
(JSC::numberConstructorFuncIsSafeInteger):
* runtime/NumberConstructor.h:
2020-04-28 Ross Kirsling <ross.kirsling@sony.com>
[JSC] Align upon the name isCallable instead of isFunction
https://bugs.webkit.org/show_bug.cgi?id=211140
Reviewed by Darin Adler.
Follow-up to r260722. Usage is now cleanly separated between isFunction / getCallData,
but the name isCallable is still clearer than isFunction so let's flip that after all.
* API/JSContextRef.cpp:
(JSGlobalContextSetUnhandledRejectionCallback):
* API/JSObjectRef.cpp:
(JSObjectIsFunction):
* dfg/DFGOperations.cpp:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCreateThis):
(JSC::FTL::DFG::LowerDFGToB3::compileCreatePromise):
(JSC::FTL::DFG::LowerDFGToB3::compileCreateInternalFieldObject):
(JSC::FTL::DFG::LowerDFGToB3::compileIsObjectOrNull):
(JSC::FTL::DFG::LowerDFGToB3::compileIsFunction):
(JSC::FTL::DFG::LowerDFGToB3::buildTypeOf):
(JSC::FTL::DFG::LowerDFGToB3::isCallable):
(JSC::FTL::DFG::LowerDFGToB3::isFunction): Deleted.
* ftl/FTLOperations.cpp:
(JSC::FTL::operationTypeOfObjectAsTypeofType):
* jsc.cpp:
(functionSetUnhandledRejectionCallback):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/ExceptionHelpers.cpp:
(JSC::errorDescriptionForValue):
* runtime/FunctionPrototype.cpp:
(JSC::functionProtoFuncToString):
* runtime/InternalFunction.cpp:
(JSC::getFunctionRealm):
* runtime/JSCJSValue.h:
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::isCallable const):
(JSC::JSValue::isFunction const): Deleted.
* runtime/JSCell.h:
* runtime/JSCellInlines.h:
(JSC::JSCell::isCallable):
(JSC::JSCell::isFunction): Deleted.
* runtime/JSONObject.cpp:
(JSC::Stringifier::appendStringifiedValue):
* runtime/ObjectConstructor.cpp:
(JSC::toPropertyDescriptor):
* runtime/ObjectPrototype.cpp:
(JSC::objectProtoFuncDefineGetter):
(JSC::objectProtoFuncDefineSetter):
* runtime/Operations.cpp:
(JSC::jsTypeStringForValue):
(JSC::jsIsObjectTypeOrNull):
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::structureForTarget):
(JSC::ProxyObject::finishCreation):
* runtime/RuntimeType.cpp:
(JSC::runtimeTypeForValue):
* tools/JSDollarVM.cpp:
(JSC::functionCallWithStackSize):
(JSC::functionFindTypeForExpression):
(JSC::functionReturnTypeFor):
(JSC::functionHasBasicBlockExecuted):
(JSC::functionBasicBlockExecutionCount):
* wasm/WasmInstance.cpp:
(JSC::Wasm::Instance::setFunctionWrapper):
* wasm/WasmOperations.cpp:
(JSC::Wasm::operationIterateResults):
(JSC::Wasm::operationWasmRefFunc):
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::link):
* wasm/js/WebAssemblyWrapperFunction.cpp:
(JSC::WebAssemblyWrapperFunction::finishCreation):
2020-04-28 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] NumberConstructor should accept BigInt
https://bugs.webkit.org/show_bug.cgi?id=210835
Reviewed by Mark Lam.
This patch fixes our Number constructor behavior to accept BigInt. According to the spec[1],
Number constructor should accept BigInt and should generate numbers from that.
We port V8's BigInt to double conversion code as we did for the other HeapBigInt runtime functions.
And we introduce CallNumberConstructor DFG node and handle Number constructor call with BigInt correctly
in DFG and FTL. Previously we were emitting ToNumber DFG node for Number constructor. But this is wrong
now since ToNumber does not accept BigInt and throws an error, and Number constructor should not use
ToNumber to implement its implementation. So we should introduce slightly different semantics: CallNumberConstructor
as we introduced CallStringConstructor in addition to ToString DFG node. And we add appropriate BigInt32 path
to emit efficient CallNumberConstructor machine code.
[1]: https://tc39.es/ecma262/#sec-number-constructor-number-value
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGBackwardsPropagationPhase.cpp:
(JSC::DFG::BackwardsPropagationPhase::propagate):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::fixupToNumberOrToNumericOrCallNumberConstructor):
(JSC::DFG::FixupPhase::fixupToNumeric): Deleted.
(JSC::DFG::FixupPhase::fixupToNumber): Deleted.
* dfg/DFGNode.h:
(JSC::DFG::Node::hasHeapPrediction):
* dfg/DFGNodeType.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileToNumeric):
(JSC::DFG::SpeculativeJIT::compileCallNumberConstructor):
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileCallNumberConstructor):
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::decideRounding):
(JSC::JSBigInt::toNumberHeap):
* runtime/JSBigInt.h:
* runtime/NumberConstructor.cpp:
(JSC::constructNumberConstructor):
(JSC::callNumberConstructor):
2020-04-27 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Throw OutOfMemoryError instead of RangeError if BigInt is too big
https://bugs.webkit.org/show_bug.cgi?id=211111
Reviewed by Saam Barati.
Currently, we are throwing a RangeError if we detect that JSBigInt becomes too large. But this is not consistent with our JSString's policy.
We should throw OutOfMemoryError in this case. This also makes DFG simple since DFG allows throwing OutOfMemoryError in any places which node
is even removed.
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* runtime/ExceptionHelpers.cpp:
(JSC::throwOutOfMemoryError):
* runtime/ExceptionHelpers.h:
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::tryCreateWithLength):
(JSC::JSBigInt::exponentiateHeap):
(JSC::JSBigInt::leftShiftByAbsolute):
(JSC::JSBigInt::allocateFor):
2020-04-27 Saam Barati <sbarati@apple.com>
BigInt math runtime shouldn't convert BigInt32 input operands to a heap cell when doing math
https://bugs.webkit.org/show_bug.cgi?id=210978
Reviewed by Yusuke Suzuki.
This patch adds support in the runtime for doing alomst all BigInt math
operations on the inputs either being Int32, HeapBigInt, or a mixing
of both. Before, if we detected a binary operation on an Int32 and a
HeapBigInt, this would lead us to convert the Int32 operand into a HeapBigInt.
This is especially bad because we'd repeat this for all math ops. For example,
if x is a BigInt32, and all rhs are a HeapBigInt, we'd repeatedly convert x
to a HeapBigInt for each operation:
```
x + y
x * y
x - y
x >> y
x << y
etc
```
To teach the runtime how to operate both over a BigInt32 and a HeapBigInt, I
templatized the runtime math operations to work both over BigInt32 and
HeapBigInt wrapper classes that expose the same interface.
This is a ~28% speedup on microbenchmarks/sunspider-sha1-big-int.js
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compare):
* jit/JITOperations.cpp:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/JSBigInt.cpp:
(JSC::HeapBigIntImpl::HeapBigIntImpl):
(JSC::HeapBigIntImpl::isZero):
(JSC::HeapBigIntImpl::sign):
(JSC::HeapBigIntImpl::length):
(JSC::HeapBigIntImpl::digit):
(JSC::HeapBigIntImpl::toHeapBigInt):
(JSC::Int32BigIntImpl::Int32BigIntImpl):
(JSC::Int32BigIntImpl::isZero):
(JSC::Int32BigIntImpl::sign):
(JSC::Int32BigIntImpl::length):
(JSC::Int32BigIntImpl::digit):
(JSC::Int32BigIntImpl::toHeapBigInt):
(JSC::JSBigInt::ImplResult::ImplResult):
(JSC::tryConvertToBigInt32):
(JSC::JSBigInt::inplaceMultiplyAdd):
(JSC::JSBigInt::exponentiateImpl):
(JSC::JSBigInt::exponentiate):
(JSC::JSBigInt::multiplyImpl):
(JSC::JSBigInt::multiply):
(JSC::JSBigInt::divideImpl):
(JSC::JSBigInt::divide):
(JSC::JSBigInt::copy):
(JSC::JSBigInt::unaryMinusImpl):
(JSC::JSBigInt::unaryMinus):
(JSC::JSBigInt::remainderImpl):
(JSC::JSBigInt::remainder):
(JSC::JSBigInt::incImpl):
(JSC::JSBigInt::inc):
(JSC::JSBigInt::decImpl):
(JSC::JSBigInt::dec):
(JSC::JSBigInt::addImpl):
(JSC::JSBigInt::add):
(JSC::JSBigInt::subImpl):
(JSC::JSBigInt::sub):
(JSC::JSBigInt::bitwiseAndImpl):
(JSC::JSBigInt::bitwiseAnd):
(JSC::JSBigInt::bitwiseOrImpl):
(JSC::JSBigInt::bitwiseOr):
(JSC::JSBigInt::bitwiseXorImpl):
(JSC::JSBigInt::bitwiseXor):
(JSC::JSBigInt::leftShiftImpl):
(JSC::JSBigInt::leftShift):
(JSC::JSBigInt::leftShiftSlow):
(JSC::JSBigInt::signedRightShiftImpl):
(JSC::JSBigInt::signedRightShift):
(JSC::JSBigInt::bitwiseNotImpl):
(JSC::JSBigInt::bitwiseNot):
(JSC::JSBigInt::internalMultiplyAdd):
(JSC::JSBigInt::multiplyAccumulate):
(JSC::JSBigInt::absoluteCompare):
(JSC::JSBigInt::compareImpl):
(JSC::JSBigInt::compare):
(JSC::JSBigInt::absoluteAdd):
(JSC::JSBigInt::absoluteSub):
(JSC::JSBigInt::absoluteDivWithDigitDivisor):
(JSC::JSBigInt::absoluteDivWithBigIntDivisor):
(JSC::JSBigInt::absoluteLeftShiftAlwaysCopy):
(JSC::JSBigInt::absoluteBitwiseOp):
(JSC::JSBigInt::absoluteAnd):
(JSC::JSBigInt::absoluteOr):
(JSC::JSBigInt::absoluteAndNot):
(JSC::JSBigInt::absoluteXor):
(JSC::JSBigInt::absoluteAddOne):
(JSC::JSBigInt::absoluteSubOne):
(JSC::JSBigInt::leftShiftByAbsolute):
(JSC::JSBigInt::rightShiftByAbsolute):
(JSC::JSBigInt::rightShiftByMaximum):
(JSC::JSBigInt::toStringGeneric):
(JSC::JSBigInt::toShiftAmount):
(JSC::JSBigInt::exponentiateHeap): Deleted.
(JSC::JSBigInt::multiplyHeap): Deleted.
(JSC::JSBigInt::divideHeap): Deleted.
(JSC::JSBigInt::unaryMinusHeap): Deleted.
(JSC::JSBigInt::remainderHeap): Deleted.
(JSC::JSBigInt::incHeap): Deleted.
(JSC::JSBigInt::decHeap): Deleted.
(JSC::JSBigInt::addHeap): Deleted.
(JSC::JSBigInt::subHeap): Deleted.
(JSC::JSBigInt::bitwiseAndHeap): Deleted.
(JSC::JSBigInt::bitwiseOrHeap): Deleted.
(JSC::JSBigInt::bitwiseXorHeap): Deleted.
(JSC::JSBigInt::leftShiftHeap): Deleted.
(JSC::JSBigInt::signedRightShiftHeap): Deleted.
(JSC::JSBigInt::bitwiseNotHeap): Deleted.
(JSC::JSBigInt::compareToInt32): Deleted.
* runtime/JSBigInt.h:
* runtime/Operations.cpp:
(JSC::jsAddSlowCase):
* runtime/Operations.h:
(JSC::compareBigInt):
(JSC::compareBigInt32ToOtherPrimitive):
(JSC::arithmeticBinaryOp):
(JSC::jsSub):
(JSC::jsMul):
(JSC::jsDiv):
(JSC::jsRemainder):
(JSC::jsPow):
(JSC::jsInc):
(JSC::jsDec):
(JSC::jsBitwiseNot):
(JSC::shift):
(JSC::jsLShift):
(JSC::jsRShift):
(JSC::bitwiseBinaryOp):
(JSC::jsBitwiseAnd):
(JSC::jsBitwiseOr):
(JSC::jsBitwiseXor):
2020-04-27 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] >>> should call ToNumeric
https://bugs.webkit.org/show_bug.cgi?id=211065
Reviewed by Ross Kirsling.
While BigInt does not support >>> operator, >>> operator should call ToNumeric (in this case, toBigIntOrInt32) for both before throwing an error.
We call toBigIntOrInt32 for both operands, and throw an error. And after that, casting int32_t to uint32_t to perform >>> operator. This is correct
since the only difference between toUint32 and toInt32 is casting int32_t result to uint32_t.
* dfg/DFGOperations.cpp:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/Operations.h:
(JSC::shift):
(JSC::jsURShift):
2020-04-27 Keith Miller <keith_miller@apple.com>
OSR Exit compiler should know and print the exiting DFG node's index
https://bugs.webkit.org/show_bug.cgi?id=210998
Reviewed by Mark Lam.
The only interesting thing here is that we set the node to index 0 if there is no node.
AFAICT, we only don't have a node when we are checking arguments.
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::OSRExit):
(JSC::DFG::operationCompileOSRExit):
* dfg/DFGOSRExitBase.h:
(JSC::DFG::OSRExitBase::OSRExitBase):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileInvalidationPoint):
(JSC::FTL::DFG::LowerDFGToB3::compileCheckSubClass):
(JSC::FTL::DFG::LowerDFGToB3::blessSpeculation):
* ftl/FTLOSRExit.cpp:
(JSC::FTL::OSRExitDescriptor::emitOSRExit):
(JSC::FTL::OSRExitDescriptor::emitOSRExitLater):
(JSC::FTL::OSRExitDescriptor::prepareOSRExitHandle):
(JSC::FTL::OSRExit::OSRExit):
* ftl/FTLOSRExit.h:
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
2020-04-27 Saam Barati <sbarati@apple.com>
compilePeepHoleBigInt32Branch needs to handle all conditions
https://bugs.webkit.org/show_bug.cgi?id=211096
<rdar://problem/62469971>
Reviewed by Yusuke Suzuki.
We were falling through to the generic path for all conditions which
weren't Equal/NotEqual. The generic path does not do speculation, so
it was leading to potential miscompiles because we omitted a type check.
Defining compilePeepHoleBigInt32Branch for other conditions is trivial,
so this patch just implements that.
This failure is caught by microbenchmarks/sunspider-sha1-big-int.js
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compilePeepHoleBranch):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compilePeepHoleBigInt32Branch):
2020-04-27 Jason Lawrence <lawrence.j@apple.com>
Unreviewed, reverting r260772.
This commit caused tests to start failing internally.
Reverted changeset:
"OSR Exit compiler should know and print the exiting DFG
node's index"
https://bugs.webkit.org/show_bug.cgi?id=210998
https://trac.webkit.org/changeset/260772
2020-04-27 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Add $vm.assertEnabled() to suppress Debug crash expected tests in release+assert build
https://bugs.webkit.org/show_bug.cgi?id=211089
Reviewed by Keith Miller.
Expose ASSERT_ENABLED condition to the shell to control crash expected tests.
* tools/JSDollarVM.cpp:
(JSC::functionAssertEnabled):
(JSC::JSDollarVM::finishCreation):
2020-04-27 Keith Miller <keith_miller@apple.com>
OSR Exit compiler should know and print the exiting DFG node's index
https://bugs.webkit.org/show_bug.cgi?id=210998
Reviewed by Mark Lam.
The only interesting thing here is that we set the node to index 0 if there is no node.
AFAICT, we only don't have a node when we are checking arguments.
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::OSRExit):
(JSC::DFG::operationCompileOSRExit):
* dfg/DFGOSRExitBase.h:
(JSC::DFG::OSRExitBase::OSRExitBase):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileInvalidationPoint):
(JSC::FTL::DFG::LowerDFGToB3::compileCheckSubClass):
(JSC::FTL::DFG::LowerDFGToB3::blessSpeculation):
* ftl/FTLOSRExit.cpp:
(JSC::FTL::OSRExitDescriptor::emitOSRExit):
(JSC::FTL::OSRExitDescriptor::emitOSRExitLater):
(JSC::FTL::OSRExitDescriptor::prepareOSRExitHandle):
(JSC::FTL::OSRExit::OSRExit):
* ftl/FTLOSRExit.h:
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
2020-04-27 Ross Kirsling <ross.kirsling@sony.com>
[JSC] CallData/ConstructData should include CallType/ConstructType
https://bugs.webkit.org/show_bug.cgi?id=211059
Reviewed by Darin Adler.
getCallData/getConstructData return a CallType/ConstructType and have a CallData/ConstructData out param,
and then *both* of these are passed side-by-side to `call`/`construct`, which all seems a bit silly.
This patch merges CallType/ConstructType into CallData/ConstructData such that getCallData/getConstructData
no longer need an out param and `call`/`construct` require one less overt parameter.
In so doing, it also:
- removes ConstructData entirely as it's an exact duplicate of CallData
- renames enum value Host to Native in alignment with CallData's union
* API/JSCallbackConstructor.cpp:
(JSC::JSCallbackConstructor::getConstructData):
* API/JSCallbackConstructor.h:
* API/JSCallbackObject.h:
* API/JSCallbackObjectFunctions.h:
(JSC::JSCallbackObject<Parent>::getConstructData):
(JSC::JSCallbackObject<Parent>::getCallData):
* API/JSObjectRef.cpp:
(JSObjectCallAsFunction):
(JSObjectCallAsConstructor):
* bindings/ScriptFunctionCall.cpp:
(Deprecated::ScriptFunctionCall::call):
* bindings/ScriptFunctionCall.h:
* dfg/DFGOperations.cpp:
* inspector/InjectedScriptManager.cpp:
(Inspector::InjectedScriptManager::createInjectedScript):
* inspector/InspectorEnvironment.h:
* interpreter/Interpreter.cpp:
(JSC::Interpreter::executeProgram):
(JSC::Interpreter::executeCall):
(JSC::Interpreter::executeConstruct):
* interpreter/Interpreter.h:
* jit/JITOperations.cpp:
* jsc.cpp:
(functionDollarAgentReceiveBroadcast):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::handleHostCall):
* runtime/ArrayPrototype.cpp:
(JSC::arrayProtoFuncToString):
(JSC::arrayProtoFuncToLocaleString):
* runtime/CallData.cpp:
(JSC::call):
(JSC::profiledCall):
* runtime/CallData.h:
* runtime/ClassInfo.h:
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/ConstructData.cpp:
(JSC::construct):
(JSC::profiledConstruct):
* runtime/ConstructData.h:
(JSC::construct):
(JSC::profiledConstruct):
(): Deleted.
* runtime/DatePrototype.cpp:
(JSC::dateProtoFuncToJSON):
* runtime/GetterSetter.cpp:
(JSC::callGetter):
(JSC::callSetter):
* runtime/InternalFunction.cpp:
(JSC::InternalFunction::getCallData):
(JSC::InternalFunction::getConstructData):
* runtime/InternalFunction.h:
* runtime/IteratorOperations.cpp:
(JSC::iteratorNext):
(JSC::iteratorClose):
(JSC::hasIteratorMethod):
(JSC::iteratorMethod):
(JSC::iteratorForIterable):
* runtime/JSBoundFunction.cpp:
(JSC::boundThisNoArgsFunctionCall):
(JSC::boundFunctionCall):
(JSC::boundThisNoArgsFunctionConstruct):
(JSC::boundFunctionConstruct):
* runtime/JSCJSValue.h:
* runtime/JSCell.cpp:
(JSC::JSCell::getCallData):
(JSC::JSCell::getConstructData):
* runtime/JSCell.h:
* runtime/JSCellInlines.h:
(JSC::JSCell::isFunction):
(JSC::JSCell::isConstructor):
* runtime/JSFunction.cpp:
(JSC::JSFunction::getCallData):
(JSC::JSFunction::getConstructData):
* runtime/JSFunction.h:
* runtime/JSInternalPromise.cpp:
(JSC::JSInternalPromise::then):
* runtime/JSMicrotask.cpp:
(JSC::JSMicrotask::run):
* runtime/JSModuleLoader.cpp:
(JSC::JSModuleLoader::dependencyKeysIfEvaluated):
(JSC::JSModuleLoader::provideFetch):
(JSC::JSModuleLoader::loadAndEvaluateModule):
(JSC::JSModuleLoader::loadModule):
(JSC::JSModuleLoader::linkAndEvaluateModule):
(JSC::JSModuleLoader::requestImportModule):
* runtime/JSONObject.cpp:
(JSC::Stringifier::isCallableReplacer const):
(JSC::Stringifier::Stringifier):
(JSC::Stringifier::toJSON):
(JSC::Stringifier::appendStringifiedValue):
(JSC::Walker::Walker):
(JSC::Walker::callReviver):
(JSC::JSONProtoFuncParse):
* runtime/JSObject.cpp:
(JSC::ordinarySetSlow):
(JSC::callToPrimitiveFunction):
(JSC::JSObject::hasInstance):
(JSC::JSObject::getMethod):
* runtime/JSObject.h:
* runtime/JSObjectInlines.h:
(JSC::getCallData):
(JSC::getConstructData):
* runtime/JSPromise.cpp:
(JSC::JSPromise::createDeferredData):
(JSC::JSPromise::resolvedPromise):
(JSC::callFunction):
* runtime/MapConstructor.cpp:
(JSC::constructMap):
* runtime/ObjectPrototype.cpp:
(JSC::objectProtoFuncToLocaleString):
* runtime/ProxyObject.cpp:
(JSC::performProxyGet):
(JSC::ProxyObject::performInternalMethodGetOwnProperty):
(JSC::ProxyObject::performHasProperty):
(JSC::ProxyObject::performPut):
(JSC::performProxyCall):
(JSC::ProxyObject::getCallData):
(JSC::performProxyConstruct):
(JSC::ProxyObject::getConstructData):
(JSC::ProxyObject::performDelete):
(JSC::ProxyObject::performPreventExtensions):
(JSC::ProxyObject::performIsExtensible):
(JSC::ProxyObject::performDefineOwnProperty):
(JSC::ProxyObject::performGetOwnPropertyNames):
(JSC::ProxyObject::performSetPrototype):
(JSC::ProxyObject::performGetPrototype):
* runtime/ProxyObject.h:
* runtime/ReflectObject.cpp:
(JSC::reflectObjectConstruct):
* runtime/SamplingProfiler.cpp:
(JSC::SamplingProfiler::processUnverifiedStackTraces):
* runtime/SetConstructor.cpp:
(JSC::constructSet):
* runtime/StringPrototype.cpp:
(JSC::replaceUsingRegExpSearch):
(JSC::operationStringProtoFuncReplaceRegExpEmptyStr):
(JSC::operationStringProtoFuncReplaceRegExpString):
(JSC::replaceUsingStringSearch):
* runtime/VM.cpp:
(JSC::VM::callPromiseRejectionCallback):
* runtime/WeakMapConstructor.cpp:
(JSC::constructWeakMap):
* runtime/WeakSetConstructor.cpp:
(JSC::constructWeakSet):
* tools/JSDollarVM.cpp:
(JSC::callWithStackSizeProbeFunction):
* wasm/js/WebAssemblyModuleRecord.cpp:
(JSC::WebAssemblyModuleRecord::evaluate):
* wasm/js/WebAssemblyWrapperFunction.cpp:
(JSC::callWebAssemblyWrapperFunction):
2020-04-26 Ross Kirsling <ross.kirsling@sony.com>
[JSC] Clearly distinguish isConstructor from getConstructData
https://bugs.webkit.org/show_bug.cgi?id=211053
Reviewed by Sam Weinig.
Follow-up to r260722. Remove the isConstructor overload that duplicates getConstructData
and clearly distinguish the usage of these two functions.
* runtime/JSCJSValue.h:
* runtime/JSCJSValueInlines.h:
* runtime/JSCell.h:
* runtime/JSCellInlines.h:
(JSC::JSCell::isConstructor):
Remove isConstructor overload.
* runtime/JSBoundFunction.cpp:
(JSC::JSBoundFunction::create):
Don't use getConstructData if you don't need ConstructData.
* runtime/ReflectObject.cpp:
(JSC::reflectObjectConstruct):
Use getConstructData if you need ConstructData.
* API/JSObjectRef.cpp:
(JSObjectIsFunction):
Use isFunction (leftover spot from last patch).
2020-04-26 Alexey Shvayka <shvaikalesh@gmail.com>
Symbol should have [[Construct]] internal method
https://bugs.webkit.org/show_bug.cgi?id=211050
Reviewed by Yusuke Suzuki.
This change introduces constructSymbol() method, which unconditionally throws
a TypeError, since its presence is observable when, for example, Symbol is a
[[ProxyTarget]] itself [1]. Aligns JSC with the spec [2], V8, and SpiderMonkey.
[1]: https://tc39.es/ecma262/#sec-proxycreate (step 7.b)
[2]: https://tc39.es/ecma262/#constructor
* runtime/SymbolConstructor.cpp:
(JSC::SymbolConstructor::SymbolConstructor):
(JSC::constructSymbol):
2020-04-26 Alexey Shvayka <shvaikalesh@gmail.com>
InternalFunction::createSubclassStructure should use newTarget's globalObject
https://bugs.webkit.org/show_bug.cgi?id=202599
Reviewed by Yusuke Suzuki.
If "prototype" of NewTarget is not an object, built-in constructors [1] should acquire
default [[Prototype]] from realm of NewTarget, utilizing GetFunctionRealm helper [2].
Before this change, realm of active constructor was used instead. This patch introduces
GetFunctionRealm and aligns all subclassable constructors with the spec, V8, and SpiderMonkey.
This change inlines fast paths checks of InternalFunction::createSubclassStructure() and
simplifies its signature; getFunctionRealm() is invoked in slow paths only.
While a dynamically created function uses NewTarget's realm for its default [[Prototype]]
similar to other built-ins, its "prototype" object inherit from ObjectPrototype
of active constructor's realm [3] (just like their scope), making it retain references
to 2 different global objects. To accomodate this behavior, this change introduces
`scopeGlobalObject` in JSFunction.cpp methods.
Above-mentioned behavior also simplifies creation of JSGenerator and JSAsyncGenerator
instances since NewTarget's realm is irrelevant to them.
IntlCollatorConstructor::collatorStructure() and 6 similar methods are removed:
a) to impose good practice of using newTarget's globalObject;
b) with this change, each of them have 1 call site max;
c) other JSC constructors have no methods alike.
[1]: https://tc39.es/ecma262/#sec-map-constructor (step 2)
[2]: https://tc39.es/ecma262/#sec-getfunctionrealm
[3]: https://tc39.es/ecma262/#sec-createdynamicfunction (steps 23-25)
* dfg/DFGOperations.cpp:
* runtime/AggregateErrorConstructor.cpp:
(JSC::callAggregateErrorConstructor):
(JSC::constructAggregateErrorConstructor):
* runtime/AggregateErrorConstructor.h:
* runtime/AsyncFunctionConstructor.cpp:
(JSC::constructAsyncFunctionConstructor):
* runtime/AsyncGeneratorFunctionConstructor.cpp:
(JSC::constructAsyncGeneratorFunctionConstructor):
* runtime/BooleanConstructor.cpp:
(JSC::constructWithBooleanConstructor):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
(JSC::createInternalFieldObject):
* runtime/DateConstructor.cpp:
(JSC::constructDate):
* runtime/ErrorConstructor.cpp:
(JSC::constructErrorConstructor):
* runtime/FunctionConstructor.cpp:
(JSC::constructFunctionSkippingEvalEnabledCheck):
* runtime/InternalFunction.cpp:
(JSC::InternalFunction::createSubclassStructure):
(JSC::getFunctionRealm):
(JSC::InternalFunction::createSubclassStructureSlow): Deleted.
* runtime/InternalFunction.h:
(JSC::InternalFunction::createSubclassStructure): Deleted.
* runtime/IntlCollatorConstructor.cpp:
(JSC::constructIntlCollator):
(JSC::callIntlCollator):
* runtime/IntlCollatorConstructor.h:
* runtime/IntlDateTimeFormatConstructor.cpp:
(JSC::constructIntlDateTimeFormat):
(JSC::callIntlDateTimeFormat):
* runtime/IntlDateTimeFormatConstructor.h:
* runtime/IntlNumberFormatConstructor.cpp:
(JSC::constructIntlNumberFormat):
(JSC::callIntlNumberFormat):
* runtime/IntlNumberFormatConstructor.h:
* runtime/IntlPluralRulesConstructor.cpp:
(JSC::constructIntlPluralRules):
* runtime/IntlPluralRulesConstructor.h:
* runtime/IntlRelativeTimeFormatConstructor.cpp:
(JSC::constructIntlRelativeTimeFormat):
* runtime/IntlRelativeTimeFormatConstructor.h:
* runtime/JSArrayBufferConstructor.cpp:
(JSC::JSGenericArrayBufferConstructor<sharingMode>::constructArrayBuffer):
* runtime/JSFunction.cpp:
(JSC::JSFunction::prototypeForConstruction):
(JSC::JSFunction::getOwnPropertySlot):
* runtime/JSGenericTypedArrayViewConstructorInlines.h:
(JSC::constructGenericTypedArrayView):
* runtime/JSGlobalObjectInlines.h:
(JSC::JSGlobalObject::arrayStructureForIndexingTypeDuringAllocation const):
* runtime/MapConstructor.cpp:
(JSC::constructMap):
* runtime/NativeErrorConstructor.cpp:
(JSC::NativeErrorConstructor<errorType>::constructNativeErrorConstructor):
(JSC::NativeErrorConstructor<errorType>::callNativeErrorConstructor):
* runtime/NativeErrorConstructor.h:
* runtime/NumberConstructor.cpp:
(JSC::constructNumberConstructor):
* runtime/ObjectConstructor.cpp:
(JSC::constructObjectWithNewTarget):
* runtime/RegExpConstructor.cpp:
(JSC::getRegExpStructure):
(JSC::constructRegExp):
(JSC::esSpecRegExpCreate):
* runtime/RegExpConstructor.h:
* runtime/SetConstructor.cpp:
(JSC::constructSet):
* runtime/StringConstructor.cpp:
(JSC::constructWithStringConstructor):
* runtime/WeakMapConstructor.cpp:
(JSC::constructWeakMap):
* runtime/WeakObjectRefConstructor.cpp:
(JSC::constructWeakRef):
* runtime/WeakSetConstructor.cpp:
(JSC::constructWeakSet):
* wasm/js/WebAssemblyCompileErrorConstructor.cpp:
(JSC::constructJSWebAssemblyCompileError):
* wasm/js/WebAssemblyInstanceConstructor.cpp:
(JSC::constructJSWebAssemblyInstance):
* wasm/js/WebAssemblyLinkErrorConstructor.cpp:
(JSC::constructJSWebAssemblyLinkError):
* wasm/js/WebAssemblyModuleConstructor.cpp:
(JSC::WebAssemblyModuleConstructor::createModule):
* wasm/js/WebAssemblyRuntimeErrorConstructor.cpp:
(JSC::constructJSWebAssemblyRuntimeError):
2020-04-26 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] ValueAdd, VaueSub, ValueMul, Inc, Dec should say SpecBigInt32 prediction based on ArithProfile
https://bugs.webkit.org/show_bug.cgi?id=211038
Reviewed by Filip Pizlo.
This patch adds profile feedback to ValueAdd, ValueSub, ValueMul, Inc, Dec to say SpecBigInt32 prediction.
Our HeapBigInt v.s. BigInt32 strategy is simpler than Double v.s. Int32 strategy: we always
prefer BigInt32 over HeapBigInt. This is because HeapBigInt calculation and conversion require
much higher cost than BigInt32. This tradeoff is largely different from Double v.s. Int32.
So keeping HeapBigInt is simply inefficient when we can use BigInt32.
This means that ArithProfile's feedback is also very simple. If we see HeapBigInt, this means
overflow happens. In DFG, we propagate this information to ValueAdd, ValueSub, and ValueMul nodes
and record it in DFGNodeFlags. And based on this information, we change the prediction and
speculation in prediction propagation and fixup phase.
We change exit reason from Overflow to BigInt32Overflow since Overflow is solely used for Int32 case,
and we have Int52Overflow for Int52 case. We should have BigInt32Overflow for BigInt32 to precisely
record and tell about what happens in DFG as a feedback for the next compilation.
We add BigInt32 speculation for ValueSub. Previously, we missed that in fixup phase and we always
speculate ValueSub with AnyBigIntUse or HeapBigIntUse. Now it can use BigInt32Use.
We also fix Inc / Dec's fixup phase to use BigInt path. Previously, it was always using UntypedUse since
`node->child1()->shouldSpeculateUntypedForArithmetic()` returns true for BigInt. We fix the ordering of
speculation attempts as it is done in the other places in fixup phase.
This patch offers 7.9% performance improvement in sunspider-sha1-big-int.
ToT Patched
sunspider-sha1-big-int 134.5668+-2.8695 ^ 124.6743+-0.7541 ^ definitely 1.0793x faster
* bytecode/ExitKind.cpp:
(JSC::exitKindToString):
* bytecode/ExitKind.h:
* bytecode/SpeculatedType.h:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::makeSafe):
(JSC::DFG::ByteCodeParser::makeDivSafe):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGGraph.h:
(JSC::DFG::Graph::binaryArithShouldSpeculateBigInt32):
(JSC::DFG::Graph::unaryArithShouldSpeculateBigInt32):
* dfg/DFGNode.h:
(JSC::DFG::Node::mayHaveBigInt32Result):
(JSC::DFG::Node::mayHaveHeapBigIntResult):
(JSC::DFG::Node::mayHaveBigIntResult):
(JSC::DFG::Node::canSpeculateBigInt32):
(JSC::DFG::Node::canSpeculateInt52):
* dfg/DFGNodeFlags.cpp:
(JSC::DFG::dumpNodeFlags):
* dfg/DFGNodeFlags.h:
(JSC::DFG::nodeMayHaveHeapBigInt):
(JSC::DFG::nodeCanSpeculateBigInt32):
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileValueAdd):
(JSC::DFG::SpeculativeJIT::compileValueSub):
(JSC::DFG::SpeculativeJIT::compileValueMul):
(JSC::DFG::SpeculativeJIT::compileValueDiv):
(JSC::DFG::SpeculativeJIT::speculateHeapBigInt):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
(JSC::FTL::DFG::LowerDFGToB3::compileValueSub):
(JSC::FTL::DFG::LowerDFGToB3::compileValueMul):
(JSC::FTL::DFG::LowerDFGToB3::compileValueDiv):
2020-04-25 Ross Kirsling <ross.kirsling@sony.com>
[JSC] isCallable is redundant with isFunction
https://bugs.webkit.org/show_bug.cgi?id=211037
Reviewed by Yusuke Suzuki.
isCallable is only being used in two places and has the same definition as isFunction (aside from out params).
Where CallData is needed, getCallData should be used; where CallData is not needed, isFunction should be used.
* runtime/JSCJSValue.h:
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::isCallable const): Deleted.
* runtime/JSCell.h:
* runtime/JSCellInlines.h:
(JSC::JSCell::isCallable): Deleted.
Remove isCallable.
* runtime/JSONObject.cpp:
(JSC::Stringifier::Stringifier):
(JSC::Stringifier::toJSON):
Use getCallData if you need CallData.
* runtime/ExceptionHelpers.cpp:
(JSC::errorDescriptionForValue):
* runtime/ObjectConstructor.cpp:
(JSC::toPropertyDescriptor):
* runtime/ObjectPrototype.cpp:
(JSC::objectProtoFuncDefineGetter):
(JSC::objectProtoFuncDefineSetter):
Don't use getCallData if you don't need CallData.
2020-04-25 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Handle BigInt32 INT32_MIN shift amount
https://bugs.webkit.org/show_bug.cgi?id=211030
Reviewed by Darin Adler.
Our BigInt shift-operation does not correctly handle INT32_MIN shift amount, and producing a wrong result.
This patch fixes it.
* runtime/Operations.h:
(JSC::shift):
2020-04-25 Darin Adler <darin@apple.com>
[Cocoa] Deal with another round of Xcode upgrade checks
https://bugs.webkit.org/show_bug.cgi?id=211027
Reviewed by Alexey Proskuryakov.
* JavaScriptCore.xcodeproj/project.pbxproj: Bump the upgrade check version.
Add a harmless base localization; this project contains nothing localized.
2020-04-25 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Add fast path for BigInt32 left-shift
https://bugs.webkit.org/show_bug.cgi?id=211029
Reviewed by Saam Barati.
Currently, the left-shift operation misses the fast path for BigInt32 <> BigInt32 case. This patch adds it. We also fixes
prediction-propagation for left/right shift to use existing heap prediction instead of polluting the result with SpecBigInt.
This offer 4.5% improvement in microbenchmarks/sunspider-sha1-big-int.js.
* dfg/DFGPredictionPropagationPhase.cpp:
* runtime/Operations.h:
(JSC::shift):
2020-04-25 Ross Kirsling <ross.kirsling@sony.com>
Unreviewed fix for JSC Debug tests following r210853.
* runtime/IntlObject.cpp:
(JSC::canonicalizeLanguageTag):
(JSC::canonicalizeLocaleList):
(JSC::defaultLocale):
Deal with unchecked exception by moving tryGetUtf8 call out of canonicalizeLanguageTag; it's meant to
verify the user input from canonicalizeLocaleList and needn't change the noexcept-ness of defaultLocale.
2020-04-25 Alex Christensen <achristensen@webkit.org>
Prepare to remove automatic URL->String conversion operators
https://bugs.webkit.org/show_bug.cgi?id=211007
Reviewed by Darin Adler.
* API/JSAPIGlobalObject.mm:
(JSC::JSAPIGlobalObject::moduleLoaderResolve):
(JSC::JSAPIGlobalObject::moduleLoaderImportModule):
* API/JSScript.mm:
(validateBytecodeCachePath):
(+[JSScript scriptOfType:memoryMappedFromASCIIFile:withSourceURL:andBytecodeCache:inVirtualMachine:error:]):
* inspector/ScriptDebugServer.cpp:
(Inspector::ScriptDebugServer::sourceParsed):
* parser/Nodes.h:
(JSC::ScopeNode::sourceURL const):
* runtime/CachedTypes.cpp:
(JSC::CachedSourceProviderShape::encode):
* runtime/Error.cpp:
(JSC::addErrorInfo):
* runtime/ScriptExecutable.h:
(JSC::ScriptExecutable::sourceURL const):
2020-04-25 Ross Kirsling <ross.kirsling@sony.com>
[Intl] Locale validation/canonicalization should defer to ICU
https://bugs.webkit.org/show_bug.cgi?id=210853
Reviewed by Darin Adler.
The mappings for locale canonicalization in latest CLDR are sufficiently complex
that it really no longer makes sense not to have ICU do this work for us.
This means the UTS 35 canonicalization desired by ECMA-402 will not be fully achievable until ICU ~67,
but it's better than reaching right into CLDR and pretending that we *are* ICU.
(On this point, we thus align with V8 and diverge from SM.)
Of course, we can still add our own pre-validations / post-canonicalizations if desired.
* CMakeLists.txt:
* DerivedSources-input.xcfilelist:
* DerivedSources-output.xcfilelist:
* DerivedSources.make:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Scripts/generateIntlCanonicalizeLanguage.py: Removed.
* runtime/IntlObject.cpp:
(JSC::intlAvailableLocales):
(JSC::intlCollatorAvailableLocales):
(JSC::canonicalizeLanguageTag):
(JSC::canonicalizeLocaleList):
(JSC::defaultLocale):
(JSC::removeUnicodeLocaleExtension):
(JSC::addMissingScriptLocales): Deleted. This one was ostensibly a fix for an old ICU bug.
(JSC::privateUseLangTag): Deleted.
(JSC::preferredLanguage): Deleted.
(JSC::preferredRegion): Deleted.
(JSC::canonicalLangTag): Deleted.
* ucd/language-subtag-registry.txt: Removed.
2020-04-24 Yusuke Suzuki <ysuzuki@apple.com>
Fix internal build by using strcmp instead of using string literal comparison
https://bugs.webkit.org/show_bug.cgi?id=211011
Reviewed by Keith Miller.
Use strcmp for string literal comparison to expect that this is fully handled by compiler and converted into constant at compile time.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
2020-04-24 Mark Lam <mark.lam@apple.com>
Suppress ASan on DFG::clobberize() to work around an ASan bug.
https://bugs.webkit.org/show_bug.cgi?id=211012
<rdar://problem/62275430>
Reviewed by Yusuke Suzuki.
ASan was incorrectly thinking that we're accessing invalid stack memory when we're not.
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
2020-04-24 Alexey Shvayka <shvaikalesh@gmail.com>
Fix WASM Error classes and re-sync wpt/wasm/jsapi from upstream
https://bugs.webkit.org/show_bug.cgi?id=210980
Reviewed by Keith Miller.
assert_throws_js() harness, which is extensively used by wpt/wasm/jsapi tests,
was recently updated to assert that passed constructors subclass Error in
spec-perfect way.
With this patch, WebAssembly errors have Error as [[Prototype]] of their constructors
and define correct "name" and "message" properties on their prototypes, aligning JSC
with the spec [1], V8 and SpiderMonkey.
[1]: https://webassembly.github.io/spec/js-api/#error-objects
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* wasm/js/WebAssemblyCompileErrorPrototype.cpp:
(JSC::WebAssemblyCompileErrorPrototype::finishCreation):
* wasm/js/WebAssemblyLinkErrorPrototype.cpp:
(JSC::WebAssemblyLinkErrorPrototype::finishCreation):
* wasm/js/WebAssemblyRuntimeErrorPrototype.cpp:
(JSC::WebAssemblyRuntimeErrorPrototype::finishCreation):
2020-04-24 Saam Barati <sbarati@apple.com>
Return BigInt32 whenever we can
https://bugs.webkit.org/show_bug.cgi?id=210922
Reviewed by Yusuke Suzuki.
This patch makes it so our runtime functions for big int math on heap
big ints converts the result to a big int 32 when possible.
The inspiration for this patch came from converting SunSpider's sha1 benchmark to
using big ints. I found that that original implementation of big int 32
was a ~35% slowdown here. This patch speeds it up by 86% from ToT, and
36% faster than before big int 32 was introduced.
To make this sound in the DFG/FTL, we are currently reporting that all
HeapBigInt math ops return SpecBigInt, instead of SpecHeapBigInt.
However, we want to do better in a follow up. We need some kind of profiling
system where we determine if we should speculate if the result is big int
32, a heap big int, or both:
https://bugs.webkit.org/show_bug.cgi?id=210982
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileValueBitNot):
(JSC::DFG::SpeculativeJIT::compileValueBitwiseOp):
(JSC::DFG::SpeculativeJIT::compileValueLShiftOp):
(JSC::DFG::SpeculativeJIT::compileValueBitRShift):
(JSC::DFG::SpeculativeJIT::compileValueAdd):
(JSC::DFG::SpeculativeJIT::compileValueSub):
(JSC::DFG::SpeculativeJIT::compileValueMul):
(JSC::DFG::SpeculativeJIT::compileValueDiv):
(JSC::DFG::SpeculativeJIT::compileValueMod):
(JSC::DFG::SpeculativeJIT::compileValuePow):
* jit/JITOperations.cpp:
* jsc.cpp:
(functionCreateBigInt32):
* runtime/BigIntConstructor.cpp:
(JSC::toBigInt):
(JSC::callBigIntConstructor):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::exponentiateHeap):
(JSC::JSBigInt::multiplyHeap):
(JSC::JSBigInt::divideHeap):
(JSC::JSBigInt::unaryMinusHeap):
(JSC::JSBigInt::remainderHeap):
(JSC::JSBigInt::incHeap):
(JSC::JSBigInt::decHeap):
(JSC::JSBigInt::addHeap):
(JSC::JSBigInt::subHeap):
(JSC::JSBigInt::bitwiseAndHeap):
(JSC::JSBigInt::bitwiseOrHeap):
(JSC::JSBigInt::bitwiseXorHeap):
(JSC::JSBigInt::leftShiftHeap):
(JSC::JSBigInt::signedRightShiftHeap):
(JSC::JSBigInt::bitwiseNotHeap):
(JSC::JSBigInt::absoluteAdd):
(JSC::JSBigInt::absoluteSub):
(JSC::JSBigInt::parseInt):
(JSC::JSBigInt::exponentiate): Deleted.
(JSC::JSBigInt::multiply): Deleted.
(JSC::JSBigInt::divide): Deleted.
(JSC::JSBigInt::unaryMinus): Deleted.
(JSC::JSBigInt::remainder): Deleted.
(JSC::JSBigInt::inc): Deleted.
(JSC::JSBigInt::dec): Deleted.
(JSC::JSBigInt::add): Deleted.
(JSC::JSBigInt::sub): Deleted.
(JSC::JSBigInt::bitwiseAnd): Deleted.
(JSC::JSBigInt::bitwiseOr): Deleted.
(JSC::JSBigInt::bitwiseXor): Deleted.
(JSC::JSBigInt::leftShift): Deleted.
(JSC::JSBigInt::signedRightShift): Deleted.
(JSC::JSBigInt::bitwiseNot): Deleted.
* runtime/JSBigInt.h:
* runtime/JSCJSValue.h:
(JSC::jsBigInt32):
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::JSValue):
* runtime/Operations.cpp:
(JSC::jsAddSlowCase):
* runtime/Operations.h:
(JSC::jsSub):
(JSC::jsMul):
(JSC::jsDiv):
(JSC::jsInc):
(JSC::jsDec):
(JSC::jsBitwiseNot):
(JSC::shift):
(JSC::bitwiseBinaryOp):
2020-04-24 Michael Catanzaro <mcatanzaro@gnome.org>
[GTK][WPE][JSCOnly] compile error when -DWTF_CPU_ARM64_CORTEXA53=ON set for arm64
https://bugs.webkit.org/show_bug.cgi?id=197192
Reviewed by Yusuke Suzuki.
This workaround is supposed to fix WebKit on old Cortex A53 CPUs, but it has been broken
since 2018, and people would like to use WebKit on modern Cortex A53. If anyone using WebKit
on the original hardware wants to fix and reimplement the workaround, feel free.
* assembler/ARM64Assembler.h:
(JSC::ARM64Assembler::adrp):
(JSC::ARM64Assembler::madd):
(JSC::ARM64Assembler::msub):
(JSC::ARM64Assembler::smaddl):
(JSC::ARM64Assembler::smsubl):
(JSC::ARM64Assembler::umaddl):
(JSC::ARM64Assembler::umsubl):
(JSC::ARM64Assembler::nopCortexA53Fix835769): Deleted.
(JSC::ARM64Assembler::nopCortexA53Fix843419): Deleted.
* offlineasm/arm64.rb:
* offlineasm/instructions.rb:
2020-04-24 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Fix DataFormatJSBigInt32 missing part
https://bugs.webkit.org/show_bug.cgi?id=210986
Reviewed by Mark Lam.
Add missing part of DataFormatJSBigInt32 implementation.
* bytecode/DataFormat.h:
(JSC::dataFormatToString):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::checkGeneratedTypeForToInt32):
2020-04-24 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, build fix in Windows
https://bugs.webkit.org/show_bug.cgi?id=210892
Windows MSVC does not have proper understanding of IGNORE_RETURN_TYPE_WARNINGS_BEGIN.
* runtime/JSBigInt.h:
(JSC::invertBigIntCompareResult):
2020-04-24 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] DFG compare should speculate BigInt well
https://bugs.webkit.org/show_bug.cgi?id=210892
Reviewed by Saam Barati.
Compare operations in DFG does not support BigInt related speculations. As a result, DFG fixup phase emits DoubleRep for operands, and
causes OSR exit. This patch adds BigInt32, HeapBigInt, and AnyBigIntUse support to DFG compare operations to avoid OSR exits.
We also introduce JSBigInt::compareToInt32 to avoid allocating JSBigInt only for comparison, and optimize C++ runtime for JSBigInt comparison.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileValueAdd):
(JSC::DFG::SpeculativeJIT::compileValueSub):
(JSC::DFG::SpeculativeJIT::compileValueMul):
(JSC::DFG::SpeculativeJIT::compare):
(JSC::DFG::SpeculativeJIT::genericJSValueNonPeepholeCompare):
(JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeCompare): Deleted.
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compileBigInt32Compare):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCompareEq):
(JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
(JSC::FTL::DFG::LowerDFGToB3::compare):
(JSC::FTL::DFG::LowerDFGToB3::genericJSValueCompare):
(JSC::FTL::DFG::LowerDFGToB3::nonSpeculativeCompare): Deleted.
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::unboxBigInt32):
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::compareToInt32):
* runtime/JSBigInt.h:
(JSC::swapBigIntCompareResult):
* runtime/Operations.h:
(JSC::compareBigInt):
(JSC::compareBigInt32ToOtherPrimitive):
(JSC::bigIntCompare):
2020-04-24 Alexey Shvayka <shvaikalesh@gmail.com>
Proxy.revocable should not have [[Construct]] slot
https://bugs.webkit.org/show_bug.cgi?id=210959
Reviewed by Darin Adler.
This change removes proxyRevocableConstructorThrowError() since its presence is
observable when, for example, Proxy.revocable is a [[ProxyTarget]] itself [1].
Also removes unnecessary newTarget() check in constructProxyObject() and
2 extra ArgList instances.
This patch aligns JSC with the spec [2], V8 and SpiderMonkey.
[1]: https://tc39.es/ecma262/#sec-proxycreate (step 7.b)
[2]: https://tc39.es/ecma262/#sec-ecmascript-standard-built-in-objects
* runtime/ProxyConstructor.cpp:
(JSC::makeRevocableProxy):
(JSC::ProxyConstructor::finishCreation):
(JSC::constructProxyObject):
(JSC::proxyRevocableConstructorThrowError): Deleted.
2020-04-24 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] DFG AI for some bitops + BigInt32 should be precise
https://bugs.webkit.org/show_bug.cgi?id=210956
Reviewed by Keith Miller.
Use SpecBigInt32 for ValueBitXor, ValueBitAnd, and ValueBitOr since they are always producing BigInt32 and they have inlined implementations in DFG / FTL.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2020-04-23 Alexey Shvayka <shvaikalesh@gmail.com>
Remove revoked Proxy checks from ProxyCreate
https://bugs.webkit.org/show_bug.cgi?id=210862
Reviewed by Ross Kirsling.
This change removes revoked Proxy checks from ProxyCreate [1], implementing
https://github.com/tc39/ecma262/pull/1814 and aligning JSC with SpiderMonkey.
Also cleans up ProxyObject creation by using isFunction() instead of
isCallable(), which are identical.
[1]: https://tc39.es/ecma262/#sec-proxycreate (steps 2, 4)
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::structureForTarget):
(JSC::ProxyObject::finishCreation):
2020-04-22 Keith Miller <keith_miller@apple.com>
Fix OSR exiting/iterator object checks in for-of bytecodes
https://bugs.webkit.org/show_bug.cgi?id=210882
Reviewed by Saam Barati.
This patch fixes some bugs in the DFGBytecodeParser where we would
set the exit origin for the SetLocal following the iterator_open/next
first call to the next bytecode. This meant that if out-of-line
Symbol.iterator or next functions returned an unexpected non-cell
we would OSR past the rest of the next bytecode rather than to the
first checkpoint.
This patch also makes sure we properly throw for non-objects returned
from either of the above functions in all tiers (and adds tests).
Finally, this patch makes a small optimization where we just ArithBitOr the
iterator's closed state (index == -1) and index is out of bounds. We can't
do a CompareBelow check because the index is effectively an int33_t.
* bytecode/BytecodeIndex.h:
(JSC::BytecodeIndex::withCheckpoint const):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::nextOpcodeIndex const):
(JSC::DFG::ByteCodeParser::nextCheckpoint const):
(JSC::DFG::ByteCodeParser::progressToNextCheckpoint):
(JSC::DFG::ByteCodeParser::handleCall):
(JSC::DFG::ByteCodeParser::handleCallVariant):
(JSC::DFG::ByteCodeParser::handleInlining):
(JSC::DFG::ByteCodeParser::handleGetById):
(JSC::DFG::ByteCodeParser::handlePutById):
(JSC::DFG::ByteCodeParser::parseGetById):
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::handlePutByVal):
* jit/JITCall.cpp:
(JSC::JIT::emitSlow_op_iterator_open):
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
(JSC::LLInt::handleIteratorNextCheckpoint):
2020-04-22 Darin Adler <darin@apple.com>
[Cocoa] Build with UChar as char16_t even in builds that use Apple's internal SDK
https://bugs.webkit.org/show_bug.cgi?id=210845
Reviewed by Anders Carlsson.
* Configurations/Base.xcconfig: Move ICU-configuring macros to Platform.h.
2020-04-22 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] branchIfBigInt32 can use BigInt32Mask and remove branchIfNumber filter
https://bugs.webkit.org/show_bug.cgi?id=210870
Reviewed by Saam Barati.
By using BigInt32Mask, we can detect BigInt32 without filtering Numbers. In this patch,
1. Remove branchIfBigInt32KnownNotNumber and branchIfNotBigInt32KnownNotNumber. And always use branchBigInt32 and branchNotBigInt32 instead.
2. Remove branchIfNumber type filtering in DFG.
3. Use BigInt32Mask based scheme in FTL.
4. Add and64(TrustedImm64, RegisterID) implementations in MacroAssembler.
5. Add TagRegistersMode version in branchIfBigInt. We use numberTagRegister to produce really efficient code[1] by avoiding large constant materialization.
[1]: From
mov %rax, %rdx
mov $0xfffe000000000012, %r11
and %r11, %rdx
cmp $0x12, %rdx
To
lea 0x12(%r14), %rdx
and %rax, %rdx
cmp $0x12, %rdx
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::and64):
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::and64):
* bytecode/ArithProfile.cpp:
(JSC::ArithProfile<BitfieldType>::emitObserveResult):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::fillSpeculateBigInt32):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileToNumeric):
(JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
(JSC::FTL::DFG::LowerDFGToB3::compileIsBigInt):
(JSC::FTL::DFG::LowerDFGToB3::boolify):
(JSC::FTL::DFG::LowerDFGToB3::buildTypeOf):
(JSC::FTL::DFG::LowerDFGToB3::lowBigInt32):
(JSC::FTL::DFG::LowerDFGToB3::isBigInt32):
(JSC::FTL::DFG::LowerDFGToB3::isNotBigInt32):
(JSC::FTL::DFG::LowerDFGToB3::isNotAnyBigInt):
(JSC::FTL::DFG::LowerDFGToB3::speculateBigInt32):
(JSC::FTL::DFG::LowerDFGToB3::speculateAnyBigInt):
(JSC::FTL::DFG::LowerDFGToB3::isBigInt32KnownNotCell): Deleted.
(JSC::FTL::DFG::LowerDFGToB3::isBigInt32KnownNotNumber): Deleted.
(JSC::FTL::DFG::LowerDFGToB3::isNotBigInt32KnownNotNumber): Deleted.
(JSC::FTL::DFG::LowerDFGToB3::isNotAnyBigIntKnownNotNumber): Deleted.
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitConvertValueToBoolean):
(JSC::AssemblyHelpers::branchIfValue):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::branchIfBigInt32):
(JSC::AssemblyHelpers::branchIfNotBigInt32):
(JSC::AssemblyHelpers::emitTypeOf):
(JSC::AssemblyHelpers::branchIfBigInt32KnownNotNumber): Deleted.
(JSC::AssemblyHelpers::branchIfNotBigInt32KnownNotNumber): Deleted.
2020-04-22 Saam Barati <sbarati@apple.com>
BigInt32 parsing should be precise
https://bugs.webkit.org/show_bug.cgi?id=210869
Reviewed by Robin Morisset.
Our algorithm before was conservative, and might produce a heap big int even
if the value could be an int32. This patch makes the algorithm precise on
64-bit, always producing a bigint32 if the number is indeed an int32.
* jsc.cpp:
(functionUseBigInt32):
(functionIsBigInt32):
(functionIsHeapBigInt):
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::parseInt):
2020-04-22 Saam Barati <sbarati@apple.com>
Edge use kind asserts are wrong for BigInt32 on ValueBitLShift
https://bugs.webkit.org/show_bug.cgi?id=210872
Reviewed by Yusuke Suzuki, Mark Lam, and Robin Morisset.
This is already covered by the v8 tests Yusuke checked in.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::emitUntypedOrAnyBigIntBitOp):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileValueBitLShift):
(JSC::FTL::DFG::LowerDFGToB3::emitBinaryBitOpSnippet):
2020-04-22 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] JSBigInt inc operation does not produce right HeapBigInt zero
https://bugs.webkit.org/show_bug.cgi?id=210860
Reviewed by Mark Lam.
JSBigInt::inc can produce signed HeapBigInt zero, which is not meeting the invariant of JSBigInt.
This patch fixes it by checking zero status before setting `setSign(true)`.
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::inc):
* runtime/JSCJSValue.cpp:
(JSC::JSValue::dumpInContextAssumingStructure const):
2020-04-22 Devin Rousso <drousso@apple.com>
Web Inspector: Debugger: Step Over should only step through comma expressions if they are comma statements
https://bugs.webkit.org/show_bug.cgi?id=210588
Reviewed by Brian Burg.
* parser/Nodes.h:
(JSC::ExpressionNode::isStatement const): Added.
(JSC::ExpressionNode::setIsStatement): Added.
* parser/NodeConstructors.h:
(JSC::ExprStatementNode::ExprStatementNode):
(JSC::DeclarationStatement::DeclarationStatement):
(JSC::ReturnNode::ReturnNode):
(JSC::ThrowNode::ThrowNode):
* bytecompiler/NodesCodegen.cpp:
(JSC::CommaNode::emitBytecode):
Only emit `WillExecuteStatement` debug hooks inside `CommaNode` if it's the only child of a
statement parent node (e.g. `a(), b(), c()` vs `true && (a(), b(), c()) && true`).
* parser/Parser.h:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseReturnStatement):
(JSC::Parser<LexerType>::parseThrowStatement):
(JSC::Parser<LexerType>::parseExpressionOrLabelStatement):
(JSC::Parser<LexerType>::parseExpressionStatement):
(JSC::Parser<LexerType>::parseExpression):
Only record a pause location for each sub-expression in a comma separated expression if it's
the only child of a statement (e.g. `a(), b(), c()` vs `true && (a(), b(), c()) && true`).
2020-04-22 Saam Barati <sbarati@apple.com>
ValueBitNot is wrong in FTL with AnyBigIntUse
https://bugs.webkit.org/show_bug.cgi?id=210846
Reviewed by Yusuke Suzuki.
We forgot to speculate.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileValueBitNot):
2020-04-22 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] AI results of BigInt32 Bitwise shift operation does not match to runtime results
https://bugs.webkit.org/show_bug.cgi?id=210839
Reviewed by Saam Barati.
While runtime function of bitwise ops with BigInt32 sometimes returns HeapBigInt, DFG AI is setting SpecBigInt32
as a result value. This leads to miscompilation particularly in FTL since FTL uses this information to remove
a lot of branches.
And we found that FTL BigInt32 predicate is not correctly checking state. This patch fixes it too.
Added test case found this (v8-bigint32-sar.js).
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileValueBitRShift):
(JSC::FTL::DFG::LowerDFGToB3::compileToNumeric):
(JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
(JSC::FTL::DFG::LowerDFGToB3::compileIsBigInt):
(JSC::FTL::DFG::LowerDFGToB3::boolify):
(JSC::FTL::DFG::LowerDFGToB3::buildTypeOf):
(JSC::FTL::DFG::LowerDFGToB3::lowBigInt32):
(JSC::FTL::DFG::LowerDFGToB3::isBigInt32KnownNotCell):
(JSC::FTL::DFG::LowerDFGToB3::isBigInt32KnownNotNumber):
(JSC::FTL::DFG::LowerDFGToB3::isNotBigInt32KnownNotNumber):
(JSC::FTL::DFG::LowerDFGToB3::isNotAnyBigIntKnownNotNumber):
(JSC::FTL::DFG::LowerDFGToB3::isNotHeapBigIntUnknownWhetherCell):
(JSC::FTL::DFG::LowerDFGToB3::speculateBigInt32):
(JSC::FTL::DFG::LowerDFGToB3::speculateAnyBigInt):
(JSC::FTL::DFG::LowerDFGToB3::isBigInt32): Deleted.
(JSC::FTL::DFG::LowerDFGToB3::isNotBigInt32): Deleted.
(JSC::FTL::DFG::LowerDFGToB3::isNotAnyBigInt): Deleted.
2020-04-21 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, build fix for watchOS
https://bugs.webkit.org/show_bug.cgi?id=210832
If function is not defined, static declaration should not be declared, otherwise, unused-function-error happens.
* jsc.cpp:
2020-04-21 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewd, speculative Windows build fix part 2
https://bugs.webkit.org/show_bug.cgi?id=210834
* runtime/Options.cpp:
(JSC::strncasecmp):
2020-04-21 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, fix windows build failure
https://bugs.webkit.org/show_bug.cgi?id=210834
* runtime/Options.cpp:
(JSC::strncasecmp):
2020-04-21 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq should expect AnyBigIntUse
https://bugs.webkit.org/show_bug.cgi?id=210832
Reviewed by Mark Lam.
SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq will get AnyBigIntUse now. We should use ManualOperandSpeculation
and speculate function to perform speculation check.
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq):
(JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq):
* jsc.cpp:
(functionCreateHeapBigInt):
(functionCreateBigInt32):
* runtime/BigIntConstructor.cpp:
(JSC::toBigInt):
(JSC::callBigIntConstructor):
* runtime/BigIntConstructor.h:
* runtime/JSBigInt.h:
2020-04-21 Yusuke Suzuki <ysuzuki@apple.com>
Canonicalize JSBigInt generated by structured-cloning by calling rightTrim
https://bugs.webkit.org/show_bug.cgi?id=210816
Reviewed by Keith Miller and Darin Adler.
* runtime/JSBigInt.h:
2020-04-21 Peng Liu <peng.liu6@apple.com>
Fix MACCATALYST build failures
https://bugs.webkit.org/show_bug.cgi?id=210815
Reviewed by Tim Horton.
* Configurations/FeatureDefines.xcconfig:
2020-04-21 Keith Miller <keith_miller@apple.com>
JSC's options should be case insensitive
https://bugs.webkit.org/show_bug.cgi?id=210834
Reviewed by Yusuke Suzuki.
* runtime/Options.cpp:
(JSC::Options::setOptionWithoutAlias):
(JSC::Options::setAliasedOption):
* runtime/OptionsList.h:
2020-04-21 Alexey Shvayka <shvaikalesh@gmail.com>
constructObjectFromPropertyDescriptor() is incorrect with partial descriptors
https://bugs.webkit.org/show_bug.cgi?id=184629
Reviewed by Ross Kirsling.
Before this change, constructObjectFromPropertyDescriptor() serialized a value-only descriptor
with nullish m_seenAttributes to {value, writable: false, enumerable: false, configurable: false}
instead of just {value}. This was observable when ordinarySetSlow() was called on a Proxy
`receiver` with "defineProperty" trap.
This patch makes constructObjectFromPropertyDescriptor() 1:1 with the spec [2], aligning JSC
with V8 and SpiderMonkey, and also cleans up its call sites from handling exceptions and
`undefined` value returns.
[1]: https://tc39.es/ecma262/#sec-ordinarysetwithowndescriptor (step 3.d.iv)
[2]: https://tc39.es/ecma262/#sec-frompropertydescriptor
* runtime/ObjectConstructor.cpp:
(JSC::objectConstructorGetOwnPropertyDescriptor):
(JSC::objectConstructorGetOwnPropertyDescriptors):
* runtime/ObjectConstructor.h:
(JSC::constructObjectFromPropertyDescriptor):
* runtime/ProxyObject.cpp:
(JSC::ProxyObject::performDefineOwnProperty):
2020-04-20 Yusuke Suzuki <ysuzuki@apple.com>
Check Structure attributes in Object.assign exhaustively
https://bugs.webkit.org/show_bug.cgi?id=210782
<rdar://problem/62065853>
Reviewed by Mark Lam.
* runtime/ObjectConstructor.cpp:
(JSC::objectConstructorAssign):
2020-04-21 Adrian Perez de Castro <aperez@igalia.com>
Non-unified build fixes late February 2020 edition
https://bugs.webkit.org/show_bug.cgi?id=210767
Unreviewed build fix.
* dfg/DFGValueRepReductionPhase.cpp: Add missing JSCJSValueInlines.h header.
* jit/JITCall.cpp: Add missing SlowPathCall.h header.
* runtime/AggregateError.cpp: Add missing JSCJSValueInlines.h, JSCellInlines.h, and
JSGlobalObjectInlines.h headers.
* runtime/AggregateErrorConstructor.cpp: Added missing JSCJSValueInlines.h, JSCellInlines.h,
and VMInlines.h headers.
* runtime/AggregateErrorPrototype.cpp: Added missing AggregateError.h, IdentifierInlines.h,
JSCJSValueInlines.h, JSCellInlines.h, JSGlobalObjectInlines.h, and VMInlines.h headers.
* runtime/Intrinsic.h: Added missing wtf/Optional.h header.
2020-04-20 Ross Kirsling <ross.kirsling@sony.com>
Classes marked final should not use protected access specifier
https://bugs.webkit.org/show_bug.cgi?id=210775
Reviewed by Daniel Bates.
* API/JSAPIValueWrapper.h:
* API/JSCallbackConstructor.h:
* API/JSCallbackObject.h:
* b3/B3ExtractValue.h:
* bytecode/UnlinkedFunctionExecutable.h:
* inspector/JSGlobalObjectConsoleClient.h:
* inspector/JSInjectedScriptHost.h:
* inspector/JSJavaScriptCallFrame.h:
* jsc.cpp:
* runtime/AggregateError.h:
* runtime/AggregateErrorPrototype.h:
* runtime/ArrayConstructor.h:
* runtime/ArrayPrototype.h:
* runtime/AsyncFunctionPrototype.h:
* runtime/AsyncGeneratorFunctionPrototype.h:
* runtime/AtomicsObject.h:
* runtime/BigIntConstructor.h:
* runtime/BigIntObject.h:
* runtime/BigIntPrototype.h:
* runtime/BooleanConstructor.h:
* runtime/BooleanPrototype.h:
* runtime/ConsoleObject.h:
* runtime/DateConstructor.h:
* runtime/DatePrototype.h:
* runtime/ErrorConstructor.h:
* runtime/ErrorPrototype.h:
* runtime/FileBasedFuzzerAgent.h:
* runtime/FunctionPrototype.h:
* runtime/FunctionRareData.h:
* runtime/GeneratorFunctionPrototype.h:
* runtime/GenericTypedArrayView.h:
* runtime/InspectorInstrumentationObject.h:
* runtime/IntlCollator.h:
* runtime/IntlCollatorConstructor.h:
* runtime/IntlCollatorPrototype.h:
* runtime/IntlDateTimeFormat.h:
* runtime/IntlDateTimeFormatConstructor.h:
* runtime/IntlDateTimeFormatPrototype.h:
* runtime/IntlNumberFormat.h:
* runtime/IntlNumberFormatConstructor.h:
* runtime/IntlNumberFormatPrototype.h:
* runtime/IntlPluralRules.h:
* runtime/IntlPluralRulesConstructor.h:
* runtime/IntlPluralRulesPrototype.h:
* runtime/IntlRelativeTimeFormatConstructor.h:
* runtime/IntlRelativeTimeFormatPrototype.h:
* runtime/JSArrayBuffer.h:
* runtime/JSArrayBufferConstructor.h:
* runtime/JSArrayBufferPrototype.h:
* runtime/JSAsyncGenerator.h:
* runtime/JSBoundFunction.h:
* runtime/JSCustomGetterSetterFunction.h:
* runtime/JSDataView.h:
* runtime/JSDataViewPrototype.h:
* runtime/JSGenerator.h:
* runtime/JSGenericTypedArrayView.h:
* runtime/JSGenericTypedArrayViewConstructor.h:
* runtime/JSGenericTypedArrayViewPrototype.h:
* runtime/JSGlobalLexicalEnvironment.h:
* runtime/JSModuleLoader.h:
* runtime/JSModuleNamespaceObject.h:
* runtime/JSNativeStdFunction.h:
* runtime/JSONObject.h:
* runtime/JSObject.h:
* runtime/JSTemplateObjectDescriptor.h:
* runtime/JSTypedArrayViewConstructor.h:
* runtime/JSTypedArrayViewPrototype.h:
* runtime/MathObject.h:
* runtime/NativeExecutable.h:
* runtime/NumberConstructor.h:
* runtime/NumberPrototype.h:
* runtime/ObjectConstructor.h:
* runtime/ObjectPrototype.h:
* runtime/PredictionFileCreatingFuzzerAgent.h:
* runtime/ReflectObject.h:
* runtime/RegExp.h:
* runtime/RegExpConstructor.h:
* runtime/RegExpObject.h:
* runtime/RegExpPrototype.h:
* runtime/StringPrototype.h:
* runtime/Structure.h:
* runtime/Symbol.h:
* runtime/SymbolConstructor.h:
* runtime/SymbolObject.h:
* runtime/SymbolPrototype.h:
* runtime/VMTraps.cpp:
* testRegExp.cpp:
* wasm/WasmBBQPlan.h:
* wasm/WasmLLIntPlan.h:
* wasm/WasmWorklist.cpp:
* wasm/js/JSWebAssembly.h:
* wasm/js/JSWebAssemblyCompileError.h:
* wasm/js/JSWebAssemblyInstance.h:
* wasm/js/JSWebAssemblyLinkError.h:
* wasm/js/JSWebAssemblyRuntimeError.h:
* wasm/js/WebAssemblyCompileErrorConstructor.h:
* wasm/js/WebAssemblyCompileErrorPrototype.h:
* wasm/js/WebAssemblyGlobalConstructor.h:
* wasm/js/WebAssemblyGlobalPrototype.h:
* wasm/js/WebAssemblyInstanceConstructor.h:
* wasm/js/WebAssemblyInstancePrototype.h:
* wasm/js/WebAssemblyLinkErrorConstructor.h:
* wasm/js/WebAssemblyLinkErrorPrototype.h:
* wasm/js/WebAssemblyMemoryConstructor.h:
* wasm/js/WebAssemblyMemoryPrototype.h:
* wasm/js/WebAssemblyModuleConstructor.h:
* wasm/js/WebAssemblyModulePrototype.h:
* wasm/js/WebAssemblyRuntimeErrorConstructor.h:
* wasm/js/WebAssemblyRuntimeErrorPrototype.h:
* wasm/js/WebAssemblyTableConstructor.h:
* wasm/js/WebAssemblyTablePrototype.h:
* wasm/js/WebAssemblyWrapperFunction.h:
2020-04-20 Peng Liu <peng.liu6@apple.com>
Fix build failures when video fullscreen and picture-in-picture is disabled
https://bugs.webkit.org/show_bug.cgi?id=210777
Reviewed by Eric Carlson.
* Configurations/FeatureDefines.xcconfig:
2020-04-20 Ross Kirsling <ross.kirsling@sony.com>
Intl classes shouldn't need an m_initialized* field
https://bugs.webkit.org/show_bug.cgi?id=210764
Reviewed by Darin Adler.
Existing Intl classes each have a field like m_initializedNumberFormat, but this is unnecessary on two levels:
1. The thing that gets initialized is a unique pointer to an ICU struct, so we can check it directly.
2. Everywhere we're checking this is redundant since we've already done the same check on the prototype side,
therefore we can just ASSERT before using said ICU struct.
While we're at it, clean up other stuff like:
- Move stuff that doesn't need to be part of the class to the CPP file (e.g. UFieldPositionIteratorDeleter).
- Merge createCollator into initializeCollator (seems like this is probably the oldest code in this space).
* runtime/IntlCollator.cpp:
(JSC::IntlCollator::initializeCollator):
(JSC::IntlCollator::compareStrings):
(JSC::IntlCollator::resolvedOptions):
(JSC::IntlCollator::createCollator): Deleted.
* runtime/IntlCollator.h:
* runtime/IntlDateTimeFormat.cpp:
(JSC::UFieldPositionIteratorDeleter::operator() const):
(JSC::IntlDateTimeFormat::initializeDateTimeFormat):
(JSC::IntlDateTimeFormat::resolvedOptions):
(JSC::IntlDateTimeFormat::format):
(JSC::partTypeString):
(JSC::IntlDateTimeFormat::formatToParts):
(JSC::IntlDateTimeFormat::UFieldPositionIteratorDeleter::operator() const): Deleted.
(JSC::IntlDateTimeFormat::partTypeString): Deleted.
* runtime/IntlDateTimeFormat.h:
* runtime/IntlNumberFormat.cpp:
(JSC::UFieldPositionIteratorDeleter::operator() const):
(JSC::IntlNumberFormatField::IntlNumberFormatField):
(JSC::IntlNumberFormat::initializeNumberFormat):
(JSC::IntlNumberFormat::format):
(JSC::IntlNumberFormat::resolvedOptions):
(JSC::partTypeString):
(JSC::IntlNumberFormat::formatToParts):
(JSC::IntlNumberFormat::UFieldPositionIteratorDeleter::operator() const): Deleted.
(JSC::IntlNumberFormat::partTypeString): Deleted.
* runtime/IntlNumberFormat.h:
* runtime/IntlPluralRules.cpp:
(JSC::localeData):
(JSC::IntlPluralRules::initializePluralRules):
(JSC::IntlPluralRules::resolvedOptions):
(JSC::IntlPluralRules::select):
(JSC::IntlPRInternal::localeData): Deleted.
* runtime/IntlPluralRules.h:
2020-04-20 Keith Miller <keith_miller@apple.com>
FTL doesn't observe the use kind of CheckIsConstant's child1
https://bugs.webkit.org/show_bug.cgi?id=210763
Reviewed by Yusuke Suzuki.
Somehow, this didn't get added when I changed CheckIsConstant and didn't show up
when I tested r260377 because I tested in release. Fortunately, the produced
DFG IR will be the same.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileCheckIsConstant):
2020-04-20 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Skip test262 for non-safe-integer range BigIntConstructor
https://bugs.webkit.org/show_bug.cgi?id=210749
Reviewed by Keith Miller.
* runtime/BigIntConstructor.cpp:
(JSC::callBigIntConstructor):
2020-04-20 Keith Miller <keith_miller@apple.com>
Fix CheckIsConstant for non-constant values and checking for empty
https://bugs.webkit.org/show_bug.cgi?id=210752
Reviewed by Saam Barati.
We need to make sure that we only have one speculated type if our value
is empty.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
2020-04-20 Darin Adler <darin@apple.com>
Use #import instead of #include in Objective-C and don't use #pragma once
https://bugs.webkit.org/show_bug.cgi?id=210724
Reviewed by David Kilzer.
* API/JSAPIWrapperObject.mm:
* API/JSContext.h:
* API/JSContext.mm:
* API/JSScriptInternal.h:
* API/JSValue.mm:
* API/JSVirtualMachine.mm:
* API/JSVirtualMachinePrivate.h:
* API/JSWrapperMap.mm:
* API/ObjCCallbackFunction.mm:
* API/tests/CurrentThisInsideBlockGetterTest.mm:
More #import, less #pragma once.
2020-04-20 Yusuke Suzuki <ysuzuki@apple.com>
StructuredClone algorithm should be aware of BigInt
https://bugs.webkit.org/show_bug.cgi?id=210728
Reviewed by Mark Lam.
* CMakeLists.txt:
* runtime/BigIntObject.h:
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::digit): Deleted.
(JSC::JSBigInt::setDigit): Deleted.
* runtime/JSBigInt.h:
(JSC::JSBigInt::digit):
(JSC::JSBigInt::setDigit):
2020-04-19 Ross Kirsling <ross.kirsling@sony.com>
[ECMA-402] Intl.RelativeTimeFormat missing in WebKit
https://bugs.webkit.org/show_bug.cgi?id=209770
Reviewed by Darin Adler.
This patch implements the recent ECMA-402 feature Intl.RelativeTimeFormat.
RelativeTimeFormat has format / formatToParts functions like NumberFormat / DateTimeFormat
and is used to turn a number and unit into a formatted relative time string, e.g.:
new Intl.RelativeTimeFormat('en').format(10, 'day')
> 'in 10 days'
new Intl.RelativeTimeFormat('en', { numeric: 'auto' }).format(0, 'day')
> 'today'
Implementation of RelativeTimeFormat#formatToParts makes direct use of NumberFormat#formatToParts,
as the relative time string consists of at most one formatted number with optional literal text on either side.
This feature is runtime-guarded by the `useIntlRelativeTimeFormat` option.
* CMakeLists.txt:
* DerivedSources-input.xcfilelist:
* DerivedSources-output.xcfilelist:
* DerivedSources.make:
* JavaScriptCore.xcodeproj/project.pbxproj:
* Sources.txt:
* runtime/CommonIdentifiers.h:
* runtime/IntlRelativeTimeFormat.cpp: Added.
* runtime/IntlRelativeTimeFormat.h: Added.
* runtime/IntlRelativeTimeFormatConstructor.cpp: Added.
* runtime/IntlRelativeTimeFormatConstructor.h: Added.
* runtime/IntlRelativeTimeFormatPrototype.cpp: Added.
* runtime/IntlRelativeTimeFormatPrototype.h: Added.
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::relativeTimeFormatStructure):
* runtime/OptionsList.h:
* runtime/VM.cpp:
(JSC::VM::VM):
* runtime/VM.h:
Add feature and runtime option.
* runtime/IntlDateTimeFormat.cpp:
(JSC::IntlDateTimeFormat::formatToParts):
* runtime/IntlPluralRules.cpp:
(JSC::IntlPluralRules::initializePluralRules):
(JSC::IntlPluralRules::resolvedOptions):
Make "type" a property name.
* runtime/IntlNumberFormat.cpp:
(JSC::IntlNumberFormat::initializeNumberFormat):
(JSC::IntlNumberFormat::resolvedOptions):
(JSC::IntlNumberFormat::formatToPartsInternal):
(JSC::IntlNumberFormat::formatToParts):
* runtime/IntlNumberFormat.h:
Factor out formatToPartsInternal so that RelativeTimeFormat can use it with its own UNumberFormat.
(This logic is too complicated to duplicate; it's because ICU won't split, e.g., "10,000" into parts for us.)
* runtime/IntlObject.cpp:
(JSC::IntlObject::IntlObject):
(JSC::IntlObject::create):
(JSC::IntlObject::finishCreation):
(JSC::intlAvailableLocales):
(JSC::intlCollatorAvailableLocales):
(JSC::isUnicodeLocaleIdentifierType):
(JSC::supportedLocales):
(JSC::intlDateTimeFormatAvailableLocales): Deleted.
(JSC::intlNumberFormatAvailableLocales): Deleted.
* runtime/IntlObject.h:
(JSC::intlDateTimeFormatAvailableLocales):
(JSC::intlNumberFormatAvailableLocales):
(JSC::intlPluralRulesAvailableLocales):
(JSC::intlRelativeTimeFormatAvailableLocales):
Perform three corrections for Intl classes:
1. Collator should be the only class with unique "available locales".
[unum|udat]_getAvailable exist but they've deferred to uloc_getAvailable for 20 years.
2. isUnicodeLocaleIdentifierType isn't just `alphanum{3,8}` but rather `alphanum{3,8} (sep alphanum{3,8})*`.
This is my own mistake from r239941.
3. supportedLocalesOf entries should not be frozen.
Changed in https://github.com/tc39/ecma402/pull/278.
* tools/JSDollarVM.cpp:
(JSC::functionICUVersion):
(JSC::JSDollarVM::finishCreation):
Add $vm.icuVersion so that we can add per-line skips to stress tests.
2020-04-19 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] SlowPathCall is not supported by callOperation in Windows
https://bugs.webkit.org/show_bug.cgi?id=210727
Reviewed by Ross Kirsling.
In Windows, SlowPathCall should be handled by JITSlowPathCall, otherwise, stack is not correctly allocated.
* jit/JITCall.cpp:
(JSC::JIT::emit_op_iterator_open):
(JSC::JIT::emit_op_iterator_next):
* jit/SlowPathCall.h:
(JSC::JITSlowPathCall::call):
2020-04-19 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Enable BigInt
https://bugs.webkit.org/show_bug.cgi?id=210726
Reviewed by Mark Lam.
* runtime/OptionsList.h:
2020-04-19 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] LLInt slow path call should not have third argument
https://bugs.webkit.org/show_bug.cgi?id=210721
Reviewed by Mark Lam.
LLInt callSlowPath does not work with third argument in Windows, CLoop etc. LLInt slow-path should not take third argument,
instead, use `bytecode.metadata(...)` to get metadata.
* jit/JITCall.cpp:
(JSC::JIT::emit_op_iterator_open):
(JSC::JIT::emit_op_iterator_next):
* llint/LowLevelInterpreter64.asm:
* runtime/CommonSlowPaths.cpp:
(JSC::iterator_open_try_fast):
(JSC::SLOW_PATH_DECL):
(JSC::iterator_next_try_fast):
(JSC::iterator_open_try_fast_narrow): Deleted.
(JSC::iterator_open_try_fast_wide16): Deleted.
(JSC::iterator_open_try_fast_wide32): Deleted.
(JSC::iterator_next_try_fast_narrow): Deleted.
(JSC::iterator_next_try_fast_wide16): Deleted.
(JSC::iterator_next_try_fast_wide32): Deleted.
* runtime/CommonSlowPaths.h:
2020-04-19 Mark Lam <mark.lam@apple.com>
Fix missing exception checks and handling in JSC APIs.
https://bugs.webkit.org/show_bug.cgi?id=210715
<rdar://problem/61599658>
Reviewed by Saam Barati.
* API/APICallbackFunction.h:
(JSC::APICallbackFunction::call):
- We should return early if an exception was thrown. We should not be using the
result in any way since we cannot rely on it having any sane value.
(JSC::APICallbackFunction::construct):
- For consistency, also return an undefined here when an exception was thrown.
* API/JSCallbackObjectFunctions.h:
(JSC::JSCallbackObject<Parent>::construct):
(JSC::JSCallbackObject<Parent>::call):
- Return an undefined if an exception was thrown. Don't return the potentially
garbage result value. Who knows what the client code will do with it. Returning
an undefined here makes the code more robust.
* API/JSObjectRef.cpp:
(JSObjectGetProperty):
(JSObjectHasPropertyForKey):
(JSObjectGetPropertyForKey):
(JSObjectDeletePropertyForKey):
(JSObjectGetPropertyAtIndex):
(JSObjectDeleteProperty):
- Explicitly return a nullptr if an exception was thrown. The toRef() on the
result that follows the exception check may or may not return a nullptr
(also see toRef(JSC::VM& vm, JSC::JSValue v) for !CPU(ADDRESS64)).
* API/JSValueRef.cpp:
(JSValueIsEqual):
(JSValueIsInstanceOfConstructor):
- For consistency, make these return false if an exception is thrown.
* API/ObjCCallbackFunction.mm:
(JSC::objCCallbackFunctionCallAsFunction):
(JSC::objCCallbackFunctionCallAsConstructor):
(JSC::ObjCCallbackFunctionImpl::call):
- Add some assertions and return early if an exception was thrown.
2020-04-18 Keith Miller <keith_miller@apple.com>
Fix CLoop build for iterator opcodes
https://bugs.webkit.org/show_bug.cgi?id=210709
Reviewed by Robin Morisset.
We need to add a default paramater for the metadata pointer
in the CLoop build. Additionally, the helper declarations need
to be in the various slow path header files. Lastly we need
opcode labels for our new JS call return points.
* bytecode/BytecodeList.rb:
* llint/LLIntSlowPaths.cpp:
* llint/LLIntSlowPaths.h:
* runtime/CommonSlowPaths.h:
2020-04-18 Robin Morisset <rmorisset@apple.com>
Support an inlined representation in JSValue of small BigInts ("BigInt32")
https://bugs.webkit.org/show_bug.cgi?id=206182
Reviewed by Yusuke Suzuki.
This patch attempts to optimize the performance of BigInts, when they are small (32 bit or less).
It works by inlining them into JSValue on 64-bit platforms, avoiding the allocation of a JSBigInt.
The bit pattern we use is 0000:XXXX:XXXX:0012
This representation works because of the following things:
- It cannot be confused with a Double or Integer thanks to the top bits
- It cannot be confused with a pointer to a Cell, thanks to bit 1 which is set to true
- It cannot be confused with a pointer to wasm thanks to bit 0 which is set to false
- It cannot be confused with true/false because bit 2 is set to false
- It cannot be confused for null/undefined because bit 4 is set to true
This entire change is gated by USE(BIGINT32), to make it easier to disable if it turns out to have bugs.
It should also make it much easier to verify if a given bug comes from it or from something else.
Note that in this patch we create BigInt32s when parsing small BigInt constants, and most operations (e.g. Add or BitOr) produce a BigInt32 if both of their operands are BigInt32,
but we don't produce a BigInt32 from for example the substraction/division of two large heap-allocated JSBigInts, even if the result fits in 32-bits.
As a result, small BigInts can now either be heap-allocated or inlined in the JSValue.
This patch includes a significant refactor of various slow paths, which are now grouped together in Operations.h
Because this increased the size of Operations.h significantly, I split the parts of Operations.h which are only used by the GC into Scribble.h, to avoid bloating compile times.
In the DFG and FTL we now have 3 UseKinds for BigInts: HeapBigIntUse, BigInt32Use and AnyBigIntUse.
The latter is useful when we know that we are receiving BigInts, but speculation indicates a mix of heap-allocated and small (inlined) big-ints.
Unfortunately, a naive implementation of this patch significantly regresses the performance of StrictEq (and its variants), as it is no longer true that a cell and a non-cell cannot be equal.
Before this patch, the code was jumping to a slow path if either:
- at least one operand is a double
- or both operands are cells
Now, it also needs to jump to the slow path if at least one is a cell.
To recover this performance cost, I significantly rewrote this code, from
if (left is Cell && right is Cell) {
if (left == right)
return true;
goto slowPath;
}
if (! left is Int32) {
if (left is Number)
goto slowPath
}
if (! right is Int32) {
if (right is Number)
goto slowPath
}
return left == right
To the following:
if (left is Double || right is Double)
goto slowPath
if (left == right)
return true;
if (left is Cell || right is Cell)
goto slowPath
return false;
I believe this to be faster than just replacing (left is Cell && right is Cell) by an ||, because I found a bit-trick to check (left is Double || right is Double) which should help reduce the pressure on the branch predictor.
Early JetStream2 tests appear to confirm that this patch is roughly neutral while it was a 0.5% regression before I used this trick, but the numbers are still too noisy, I plan to do more measurements before landing this patch.
I don't yet have performance numbers for this patch on a BigInt benchmark, I will get such numbers before trying to land it, but I'd like some review in the meantime.
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/X86Assembler.h:
(JSC::X86Assembler::X86InstructionFormatter::SingleInstructionBufferWriter::memoryModRM):
* bytecode/ArithProfile.cpp:
(JSC::ArithProfile<BitfieldType>::emitObserveResult):
(JSC::ArithProfile<BitfieldType>::shouldEmitSetBigInt32 const):
(JSC::ArithProfile<BitfieldType>::shouldEmitSetHeapBigInt const):
(JSC::ArithProfile<BitfieldType>::emitSetHeapBigInt const):
(JSC::ArithProfile<BitfieldType>::emitSetBigInt32 const):
(WTF::printInternal):
* bytecode/ArithProfile.h:
(JSC::ObservedResults::didObserveNonInt32):
(JSC::ObservedResults::didObserveBigInt):
(JSC::ObservedResults::didObserveHeapBigInt):
(JSC::ObservedResults::didObserveBigInt32):
(JSC::ArithProfile::didObserveHeapBigInt const):
(JSC::ArithProfile::didObserveBigInt32 const):
(JSC::ArithProfile::setObservedHeapBigInt):
(JSC::ArithProfile::setObservedBigInt32):
(JSC::ArithProfile::observeResult):
* bytecode/BytecodeList.rb:
* bytecode/BytecodeLivenessAnalysisInlines.h:
* bytecode/BytecodeUseDef.cpp:
(JSC::computeUsesForBytecodeIndexImpl):
(JSC::computeDefsForBytecodeIndexImpl):
* bytecode/CodeBlock.cpp:
* bytecode/DataFormat.h:
* bytecode/MethodOfGettingAValueProfile.cpp:
(JSC::MethodOfGettingAValueProfile::emitReportValue const):
* bytecode/MethodOfGettingAValueProfile.h:
* bytecode/SpeculatedType.cpp:
(JSC::dumpSpeculation):
(JSC::speculationFromClassInfo):
(JSC::speculationFromStructure):
(JSC::speculationFromValue):
(JSC::speculationFromJSType):
(JSC::leastUpperBoundOfStrictlyEquivalentSpeculations):
* bytecode/SpeculatedType.h:
(JSC::isBigInt32Speculation):
(JSC::isHeapBigIntSpeculation):
(JSC::isBigIntSpeculation):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitEqualityOpImpl):
(JSC::BytecodeGenerator::addBigIntConstant):
* bytecompiler/BytecodeGenerator.h:
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::isToThisAnIdentity):
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::fixupToThis):
(JSC::DFG::FixupPhase::fixupToNumeric):
(JSC::DFG::FixupPhase::observeUseKindOnNode):
(JSC::DFG::FixupPhase::fixupCompareStrictEqAndSameValue):
* dfg/DFGMayExit.cpp:
* dfg/DFGNode.h:
(JSC::DFG::Node::shouldSpeculateBigInt32):
(JSC::DFG::Node::shouldSpeculateHeapBigInt):
* dfg/DFGNodeType.h:
* dfg/DFGOSRExit.cpp:
(JSC::DFG::OSRExit::compileExit):
* dfg/DFGOSRExit.h:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::SafeToExecuteEdge::operator()):
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compilePeepHoleBranch):
(JSC::DFG::SpeculativeJIT::compileValueBitNot):
(JSC::DFG::SpeculativeJIT::emitUntypedOrAnyBigIntBitOp):
(JSC::DFG::SpeculativeJIT::compileValueBitwiseOp):
(JSC::DFG::SpeculativeJIT::emitUntypedOrBigIntRightShiftBitOp):
(JSC::DFG::SpeculativeJIT::compileValueLShiftOp):
(JSC::DFG::SpeculativeJIT::compileValueBitRShift):
(JSC::DFG::SpeculativeJIT::compileShiftOp):
(JSC::DFG::SpeculativeJIT::compileValueAdd):
(JSC::DFG::SpeculativeJIT::compileValueSub):
(JSC::DFG::SpeculativeJIT::compileIncOrDec):
(JSC::DFG::SpeculativeJIT::compileValueNegate):
(JSC::DFG::SpeculativeJIT::compileValueMul):
(JSC::DFG::SpeculativeJIT::compileValueDiv):
(JSC::DFG::SpeculativeJIT::compileValueMod):
(JSC::DFG::SpeculativeJIT::compileValuePow):
(JSC::DFG::SpeculativeJIT::compare):
(JSC::DFG::SpeculativeJIT::compileStrictEq):
(JSC::DFG::SpeculativeJIT::speculateHeapBigInt):
(JSC::DFG::SpeculativeJIT::speculate):
(JSC::DFG::SpeculativeJIT::compileToNumeric):
(JSC::DFG::SpeculativeJIT::compileHeapBigIntEquality):
* dfg/DFGSpeculativeJIT.h:
(JSC::DFG::SpeculateBigInt32Operand::SpeculateBigInt32Operand):
(JSC::DFG::SpeculateBigInt32Operand::~SpeculateBigInt32Operand):
(JSC::DFG::SpeculateBigInt32Operand::edge const):
(JSC::DFG::SpeculateBigInt32Operand::node const):
(JSC::DFG::SpeculateBigInt32Operand::gpr):
(JSC::DFG::SpeculateBigInt32Operand::use):
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::fillJSValue):
(JSC::DFG::SpeculativeJIT::nonSpeculativePeepholeStrictEq):
(JSC::DFG::SpeculativeJIT::nonSpeculativeNonPeepholeStrictEq):
(JSC::DFG::SpeculativeJIT::fillSpeculateInt32Internal):
(JSC::DFG::SpeculativeJIT::fillSpeculateCell):
(JSC::DFG::SpeculativeJIT::fillSpeculateBoolean):
(JSC::DFG::SpeculativeJIT::speculateBigInt32):
(JSC::DFG::SpeculativeJIT::speculateAnyBigInt):
(JSC::DFG::SpeculativeJIT::fillSpeculateBigInt32):
(JSC::DFG::SpeculativeJIT::compileBigInt32Compare):
(JSC::DFG::SpeculativeJIT::compilePeepHoleBigInt32Branch):
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStrengthReductionPhase.cpp:
(JSC::DFG::StrengthReductionPhase::handleNode):
* dfg/DFGUseKind.cpp:
(WTF::printInternal):
* dfg/DFGUseKind.h:
(JSC::DFG::typeFilterFor):
(JSC::DFG::isCell):
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLCommonValues.cpp:
(JSC::FTL::CommonValues::initializeConstants):
* ftl/FTLCommonValues.h:
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileValueAdd):
(JSC::FTL::DFG::LowerDFGToB3::compileValueSub):
(JSC::FTL::DFG::LowerDFGToB3::compileValueMul):
(JSC::FTL::DFG::LowerDFGToB3::compileBinaryMathIC):
(JSC::FTL::DFG::LowerDFGToB3::compileValueDiv):
(JSC::FTL::DFG::LowerDFGToB3::compileValueMod):
(JSC::FTL::DFG::LowerDFGToB3::compileValuePow):
(JSC::FTL::DFG::LowerDFGToB3::compileValueBitNot):
(JSC::FTL::DFG::LowerDFGToB3::compileValueBitAnd):
(JSC::FTL::DFG::LowerDFGToB3::compileValueBitOr):
(JSC::FTL::DFG::LowerDFGToB3::compileValueBitXor):
(JSC::FTL::DFG::LowerDFGToB3::compileValueBitRShift):
(JSC::FTL::DFG::LowerDFGToB3::compileArithBitRShift):
(JSC::FTL::DFG::LowerDFGToB3::compileArithBitLShift):
(JSC::FTL::DFG::LowerDFGToB3::compileValueBitLShift):
(JSC::FTL::DFG::LowerDFGToB3::compileBitURShift):
(JSC::FTL::DFG::LowerDFGToB3::compileToNumeric):
(JSC::FTL::DFG::LowerDFGToB3::compileCompareEq):
(JSC::FTL::DFG::LowerDFGToB3::compileCompareStrictEq):
(JSC::FTL::DFG::LowerDFGToB3::compileIsBigInt):
(JSC::FTL::DFG::LowerDFGToB3::emitBinarySnippet):
(JSC::FTL::DFG::LowerDFGToB3::emitBinaryBitOpSnippet):
(JSC::FTL::DFG::LowerDFGToB3::boolify):
(JSC::FTL::DFG::LowerDFGToB3::buildTypeOf):
(JSC::FTL::DFG::LowerDFGToB3::lowHeapBigInt):
(JSC::FTL::DFG::LowerDFGToB3::lowBigInt32):
(JSC::FTL::DFG::LowerDFGToB3::isBigInt32):
(JSC::FTL::DFG::LowerDFGToB3::isNotBigInt32):
(JSC::FTL::DFG::LowerDFGToB3::unboxBigInt32):
(JSC::FTL::DFG::LowerDFGToB3::boxBigInt32):
(JSC::FTL::DFG::LowerDFGToB3::isNotAnyBigInt):
(JSC::FTL::DFG::LowerDFGToB3::speculate):
(JSC::FTL::DFG::LowerDFGToB3::isNotHeapBigIntUnknownWhetherCell):
(JSC::FTL::DFG::LowerDFGToB3::isNotHeapBigInt):
(JSC::FTL::DFG::LowerDFGToB3::isHeapBigInt):
(JSC::FTL::DFG::LowerDFGToB3::speculateHeapBigInt):
(JSC::FTL::DFG::LowerDFGToB3::speculateHeapBigIntUnknownWhetherCell):
(JSC::FTL::DFG::LowerDFGToB3::speculateBigInt32):
(JSC::FTL::DFG::LowerDFGToB3::speculateAnyBigInt):
* ftl/FTLOSRExitCompiler.cpp:
(JSC::FTL::compileStub):
* heap/HeapSnapshotBuilder.cpp:
(JSC::HeapSnapshotBuilder::json):
* heap/MarkedBlockInlines.h:
* heap/PreciseAllocation.cpp:
* inspector/agents/InspectorHeapAgent.cpp:
(Inspector::InspectorHeapAgent::getPreview):
* interpreter/Interpreter.cpp:
(JSC::sizeOfVarargs):
* jit/AssemblyHelpers.cpp:
(JSC::AssemblyHelpers::emitConvertValueToBoolean):
(JSC::AssemblyHelpers::branchIfValue):
* jit/AssemblyHelpers.h:
(JSC::AssemblyHelpers::branchIfBigInt32):
(JSC::AssemblyHelpers::branchIfBigInt32KnownNotNumber):
(JSC::AssemblyHelpers::branchIfNotBigInt32KnownNotNumber):
(JSC::AssemblyHelpers::branchIfHeapBigInt):
(JSC::AssemblyHelpers::branchIfNotHeapBigInt):
(JSC::AssemblyHelpers::unboxBigInt32):
(JSC::AssemblyHelpers::boxBigInt32):
(JSC::AssemblyHelpers::emitTypeOf):
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
* jit/JIT.h:
* jit/JITArithmetic.cpp:
(JSC::JIT::emit_op_negate):
(JSC::JIT::emitSlow_op_negate):
* jit/JITOpcodes.cpp:
(JSC::JIT::emit_op_is_big_int):
(JSC::JIT::compileOpStrictEq):
(JSC::JIT::compileOpStrictEqJump):
(JSC::JIT::emit_op_to_numeric):
* jit/JITOpcodes32_64.cpp:
(JSC::JIT::emit_op_is_big_int):
(JSC::JIT::emit_op_to_numeric):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* llint/LLIntOfflineAsmConfig.h:
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter64.asm:
* parser/ParserArena.cpp:
(JSC::IdentifierArena::makeBigIntDecimalIdentifier):
* runtime/ArrayPrototype.cpp:
* runtime/BigIntConstructor.cpp:
(JSC::toBigInt):
(JSC::callBigIntConstructor):
* runtime/BigIntObject.cpp:
(JSC::BigIntObject::create):
(JSC::BigIntObject::finishCreation):
* runtime/BigIntObject.h:
* runtime/BigIntPrototype.cpp:
(JSC::toThisBigIntValue):
(JSC::bigIntProtoFuncToStringImpl):
* runtime/CommonSlowPaths.cpp:
(JSC::SLOW_PATH_DECL):
(JSC::updateArithProfileForUnaryArithOp):
(JSC::updateArithProfileForBinaryArithOp):
* runtime/JSBigInt.cpp:
(JSC::JSBigInt::createStructure):
(JSC::JSBigInt::parseInt):
(JSC::JSBigInt::stringToBigInt):
(JSC::JSBigInt::inc):
(JSC::JSBigInt::dec):
(JSC::JSBigInt::bitwiseAnd):
(JSC::JSBigInt::toStringGeneric):
(JSC::JSBigInt::equalsToNumber):
(JSC::JSBigInt::equalsToInt32):
* runtime/JSBigInt.h:
(JSC::asHeapBigInt):
* runtime/JSCJSValue.cpp:
(JSC::JSValue::toNumberSlowCase const):
(JSC::JSValue::toObjectSlowCase const):
(JSC::JSValue::toThisSlowCase const):
(JSC::JSValue::synthesizePrototype const):
(JSC::JSValue::dumpInContextAssumingStructure const):
(JSC::JSValue::dumpForBacktrace const):
(JSC::JSValue::toStringSlowCase const):
* runtime/JSCJSValue.h:
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::JSValue):
(JSC::JSValue::asHeapBigInt const):
(JSC::JSValue::isBigInt const):
(JSC::JSValue::isHeapBigInt const):
(JSC::JSValue::isBigInt32 const):
(JSC::JSValue::bigInt32AsInt32 const):
(JSC::JSValue::isPrimitive const):
(JSC::JSValue::getPrimitiveNumber):
(JSC::JSValue::toNumeric const):
(JSC::JSValue::toBigIntOrInt32 const):
(JSC::JSValue::equalSlowCaseInline):
(JSC::JSValue::strictEqualForCells):
(JSC::JSValue::strictEqual):
(JSC::JSValue::pureStrictEqual):
(JSC::JSValue::pureToBoolean const):
* runtime/JSCell.cpp:
(JSC::JSCell::put):
(JSC::JSCell::putByIndex):
(JSC::JSCell::toPrimitive const):
(JSC::JSCell::getPrimitiveNumber const):
(JSC::JSCell::toNumber const):
(JSC::JSCell::toObjectSlow const):
* runtime/JSCell.h:
* runtime/JSCellInlines.h:
(JSC::JSCell::isHeapBigInt const):
(JSC::JSCell::toBoolean const):
(JSC::JSCell::pureToBoolean const):
* runtime/JSString.h:
(JSC::JSValue::toBoolean const):
* runtime/JSType.cpp:
(WTF::printInternal):
* runtime/JSType.h:
* runtime/JSTypeInfo.h:
* runtime/ObjectInitializationScope.cpp:
* runtime/Operations.cpp:
(JSC::jsAddSlowCase):
(JSC::jsIsObjectTypeOrNull):
* runtime/Operations.h:
(JSC::compareBigIntToOtherPrimitive):
(JSC::bigIntCompare):
(JSC::jsLess):
(JSC::jsLessEq):
(JSC::arithmeticBinaryOp):
(JSC::jsSub):
(JSC::jsMul):
(JSC::jsDiv):
(JSC::jsRemainder):
(JSC::jsPow):
(JSC::jsInc):
(JSC::jsDec):
(JSC::jsBitwiseNot):
(JSC::shift):
(JSC::jsLShift):
(JSC::jsRShift):
(JSC::bitwiseBinaryOp):
(JSC::jsBitwiseAnd):
(JSC::jsBitwiseOr):
(JSC::jsBitwiseXor):
* runtime/Scribble.h: Copied from Source/JavaScriptCore/runtime/BigIntObject.h.
(JSC::scribbleFreeCells):
(JSC::isScribbledValue):
(JSC::scribble):
* runtime/StructureInlines.h:
(JSC::prototypeForLookupPrimitiveImpl):
2020-04-18 Keith Miller <keith_miller@apple.com>
Unreviewed, remove commented out/dead code that didn't failed to
get removed when landing r260323.
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
* runtime/CommonSlowPaths.cpp:
(JSC::iterator_next_try_fast):
2020-04-18 Keith Miller <keith_miller@apple.com>
Redesign how we do for-of iteration for JSArrays
https://bugs.webkit.org/show_bug.cgi?id=175454
Reviewed by Filip Pizlo and Saam Barati.
This patch intrinsics for-of iteration for JSArrays when they are
being iterated with the built-in Symbol.iterator. We do this by
adding two new bytecodes op_iterator_open and
op_iterator_next. These bytecodes are essentially a fused set of
existing bytecodes with a special case for our intrinsiced JSArray
case. This patch only adds support for these instructions on
64-bit.
The op_iterator_open bytecode is semantically the same as:
iterator = symbolIterator.@call(iterable);
next = iterator.next;
where iterable is the rhs of the for-of and symbolIterator is the
result of running iterable.symbolIterator;
The op_iterator_next bytecode is semantically the same as:
nextResult = next.@call(iterator);
done = nextResult.done;
value = done ? (undefined / bottom) : nextResult.value;
where nextResult is a temporary (the value VirtualRegister in the
LLInt/Baseline and a tmp in the DFG).
In order to make sure these bytecodes have the same perfomance as
the existing bytecode sequence, we need to make sure we have the
same profiling data and inline caching. Most of the existing
get_by_id code assumed a particular bytecode member name was the
same in each flavor get_by_id access. This patch adds template
specialized functions that vend the correct
Profile/VirtualRegister for the current bytecode/checkpoint. This
means we can have meaningful names for our Bytecode structs and
still use the generic functions.
In the LLInt most of the logic for calls/get_by_id had to be
factored into helper macros, so we could have bytecodes that are
some combination of those.
The trickiest part of this patch was getting the hand rolled DFG
IR to work correctly. This is because we don't have a great way to
express large chucks of DFG graph that doesn't involve manually
tracking all the DFG's invariants. Such as:
1) Flushing/Phantoming values at the end of each block.
2) Rolling forwards and backwards the BytecodeIndex when switching
blocks.
3) Remembering to GetLocal each variable at the top of every block.
4) Ensuring that the JSValue stored to the op_iterator_next.m_value
local does not cause us to OSR exit at the set local.
(4) is handled by a new function, bottomValueMatchingSpeculation,
on DFGGraph that produces a FrozenValue that is roughly the bottom
for a given speculated type. In a future patch we should make this
more complete, probably by adding a VM::bottomCellForSetLocal that
prediction propagation and AI know how treat as a true bottom
value. See: https://bugs.webkit.org/show_bug.cgi?id=210694
Lastly, this patch changes the DFG NodeType, CheckCell to be
CheckIsConstant. CheckIsConstant is equivalent to the == operator
on JSValue where it just checks the register values are the
same. In order to keep the same perf that we had for CheckCell,
CheckIsConstant supports CellUse.
* CMakeLists.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
* assembler/MacroAssemblerARM64.h:
(JSC::MacroAssemblerARM64::or8):
(JSC::MacroAssemblerARM64::store8):
* assembler/MacroAssemblerX86_64.h:
(JSC::MacroAssemblerX86_64::or8):
* bytecode/ArrayProfile.h:
(JSC::ArrayProfile::observeStructureID):
(JSC::ArrayProfile::observeStructure):
* bytecode/BytecodeList.rb:
* bytecode/BytecodeLivenessAnalysis.cpp:
(JSC::tmpLivenessForCheckpoint):
* bytecode/BytecodeOperandsForCheckpoint.h: Added.
(JSC::arrayProfileForImpl):
(JSC::hasArrayProfileFor):
(JSC::arrayProfileFor):
(JSC::valueProfileForImpl):
(JSC::hasValueProfileFor):
(JSC::valueProfileFor):
(JSC::destinationFor):
(JSC::calleeFor):
(JSC::argumentCountIncludingThisFor):
(JSC::stackOffsetInRegistersForCall):
(JSC::callLinkInfoFor):
* bytecode/BytecodeUseDef.cpp:
(JSC::computeUsesForBytecodeIndexImpl):
(JSC::computeDefsForBytecodeIndexImpl):
* bytecode/CallLinkInfo.cpp:
(JSC::CallLinkInfo::callTypeFor):
* bytecode/CallLinkStatus.cpp:
(JSC::CallLinkStatus::computeFromLLInt):
* bytecode/CodeBlock.cpp:
(JSC::CodeBlock::finishCreation):
(JSC::CodeBlock::finalizeLLIntInlineCaches):
(JSC::CodeBlock::tryGetValueProfileForBytecodeIndex):
* bytecode/CodeBlock.h:
(JSC::CodeBlock::instructionAt const):
* bytecode/CodeBlockInlines.h:
(JSC::CodeBlock::forEachValueProfile):
(JSC::CodeBlock::forEachArrayProfile):
* bytecode/GetByStatus.cpp:
(JSC::GetByStatus::computeFromLLInt):
* bytecode/Instruction.h:
(JSC::BaseInstruction::width const):
(JSC::BaseInstruction::hasCheckpoints const):
(JSC::BaseInstruction::asKnownWidth const):
(JSC::BaseInstruction::wide16 const):
(JSC::BaseInstruction::wide32 const):
* bytecode/InstructionStream.h:
* bytecode/IterationModeMetadata.h: Copied from Source/JavaScriptCore/bytecode/SuperSampler.h.
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.cpp:
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::fireInternal):
(JSC::LLIntPrototypeLoadAdaptiveStructureWatchpoint::clearLLIntGetByIdCache):
* bytecode/LLIntPrototypeLoadAdaptiveStructureWatchpoint.h:
* bytecode/Opcode.h:
* bytecode/SpeculatedType.h:
(JSC::isSubtypeSpeculation):
(JSC::speculationContains):
* bytecode/SuperSampler.h:
(JSC::SuperSamplerScope::release):
* bytecompiler/BytecodeGenerator.cpp:
(JSC::BytecodeGenerator::emitGenericEnumeration):
(JSC::BytecodeGenerator::emitEnumeration):
(JSC::BytecodeGenerator::emitIsEmpty):
(JSC::BytecodeGenerator::emitIteratorOpen):
(JSC::BytecodeGenerator::emitIteratorNext):
(JSC::BytecodeGenerator::emitGetGenericIterator):
(JSC::BytecodeGenerator::emitIteratorGenericNext):
(JSC::BytecodeGenerator::emitIteratorGenericNextWithValue):
(JSC::BytecodeGenerator::emitIteratorGenericClose):
(JSC::BytecodeGenerator::emitGetAsyncIterator):
(JSC::BytecodeGenerator::emitDelegateYield):
(JSC::BytecodeGenerator::emitIteratorNextWithValue): Deleted.
(JSC::BytecodeGenerator::emitIteratorClose): Deleted.
(JSC::BytecodeGenerator::emitGetIterator): Deleted.
* bytecompiler/BytecodeGenerator.h:
* bytecompiler/NodesCodegen.cpp:
(JSC::ArrayPatternNode::bindValue const):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
(JSC::DFG::AbstractInterpreter<AbstractStateType>::forAllValues):
* dfg/DFGAtTailAbstractState.h:
(JSC::DFG::AtTailAbstractState::size const):
(JSC::DFG::AtTailAbstractState::numberOfTmps const):
(JSC::DFG::AtTailAbstractState::atIndex):
(JSC::DFG::AtTailAbstractState::tmp):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::progressToNextCheckpoint):
(JSC::DFG::ByteCodeParser::get):
(JSC::DFG::ByteCodeParser::set):
(JSC::DFG::ByteCodeParser::jsConstant):
(JSC::DFG::ByteCodeParser::weakJSConstant):
(JSC::DFG::ByteCodeParser::addCall):
(JSC::DFG::ByteCodeParser::allocateUntargetableBlock):
(JSC::DFG::ByteCodeParser::handleCall):
(JSC::DFG::ByteCodeParser::emitFunctionChecks):
(JSC::DFG::ByteCodeParser::inlineCall):
(JSC::DFG::ByteCodeParser::handleCallVariant):
(JSC::DFG::ByteCodeParser::handleVarargsInlining):
(JSC::DFG::ByteCodeParser::handleInlining):
(JSC::DFG::ByteCodeParser::handleMinMax):
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
(JSC::DFG::ByteCodeParser::handleDOMJITCall):
(JSC::DFG::ByteCodeParser::handleIntrinsicGetter):
(JSC::DFG::ByteCodeParser::handleDOMJITGetter):
(JSC::DFG::ByteCodeParser::handleModuleNamespaceLoad):
(JSC::DFG::ByteCodeParser::handleTypedArrayConstructor):
(JSC::DFG::ByteCodeParser::handleConstantInternalFunction):
(JSC::DFG::ByteCodeParser::handleGetById):
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):
(JSC::DFG::ByteCodeParser::handlePutByVal):
(JSC::DFG::ByteCodeParser::handleCreateInternalFieldObject):
(JSC::DFG::ByteCodeParser::parse):
* dfg/DFGCFGSimplificationPhase.cpp:
(JSC::DFG::CFGSimplificationPhase::keepOperandAlive):
(JSC::DFG::CFGSimplificationPhase::jettisonBlock):
(JSC::DFG::CFGSimplificationPhase::mergeBlocks):
* dfg/DFGCapabilities.cpp:
(JSC::DFG::capabilityLevel):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
(JSC::DFG::FixupPhase::addStringReplacePrimordialChecks):
* dfg/DFGForAllKills.h:
(JSC::DFG::forAllKilledOperands):
* dfg/DFGGraph.cpp:
(JSC::DFG::Graph::bottomValueMatchingSpeculation):
* dfg/DFGGraph.h:
* dfg/DFGInPlaceAbstractState.cpp:
(JSC::DFG::InPlaceAbstractState::beginBasicBlock):
(JSC::DFG::InPlaceAbstractState::initialize):
(JSC::DFG::InPlaceAbstractState::endBasicBlock):
(JSC::DFG::InPlaceAbstractState::merge):
* dfg/DFGInPlaceAbstractState.h:
(JSC::DFG::InPlaceAbstractState::size const):
(JSC::DFG::InPlaceAbstractState::numberOfTmps const):
(JSC::DFG::InPlaceAbstractState::atIndex):
(JSC::DFG::InPlaceAbstractState::operand):
(JSC::DFG::InPlaceAbstractState::local):
(JSC::DFG::InPlaceAbstractState::argument):
(JSC::DFG::InPlaceAbstractState::variableAt): Deleted.
* dfg/DFGLazyJSValue.h:
(JSC::DFG::LazyJSValue::speculatedType const):
* dfg/DFGNode.h:
(JSC::DFG::Node::hasConstant):
(JSC::DFG::Node::hasCellOperand):
* dfg/DFGNodeType.h:
* dfg/DFGOSRExitCompilerCommon.cpp:
(JSC::DFG::callerReturnPC):
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileCheckIsConstant):
(JSC::DFG::SpeculativeJIT::compileCheckCell): Deleted.
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGValidate.cpp:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileCheckIsConstant):
(JSC::FTL::DFG::LowerDFGToB3::compileCheckCell): Deleted.
* generator/DSL.rb:
* generator/Metadata.rb:
* generator/Section.rb:
* jit/JIT.cpp:
(JSC::JIT::privateCompileMainPass):
(JSC::JIT::privateCompileSlowCases):
* jit/JIT.h:
* jit/JITCall.cpp:
(JSC::JIT::emitPutCallResult):
(JSC::JIT::compileSetupFrame):
(JSC::JIT::compileOpCall):
(JSC::JIT::emit_op_iterator_open):
(JSC::JIT::emitSlow_op_iterator_open):
(JSC::JIT::emit_op_iterator_next):
(JSC::JIT::emitSlow_op_iterator_next):
* jit/JITCall32_64.cpp:
(JSC::JIT::emit_op_iterator_open):
(JSC::JIT::emitSlow_op_iterator_open):
(JSC::JIT::emit_op_iterator_next):
(JSC::JIT::emitSlow_op_iterator_next):
* jit/JITInlines.h:
(JSC::JIT::updateTopCallFrame):
(JSC::JIT::advanceToNextCheckpoint):
(JSC::JIT::emitJumpSlowToHotForCheckpoint):
(JSC::JIT::emitValueProfilingSite):
* jit/JITOperations.cpp:
* jit/JITOperations.h:
* llint/LLIntSlowPaths.cpp:
(JSC::LLInt::setupGetByIdPrototypeCache):
(JSC::LLInt::performLLIntGetByID):
(JSC::LLInt::LLINT_SLOW_PATH_DECL):
(JSC::LLInt::genericCall):
(JSC::LLInt::handleIteratorOpenCheckpoint):
(JSC::LLInt::handleIteratorNextCheckpoint):
(JSC::LLInt::slow_path_checkpoint_osr_exit):
(JSC::LLInt::llint_dump_value):
* llint/LowLevelInterpreter.asm:
* llint/LowLevelInterpreter32_64.asm:
* llint/LowLevelInterpreter64.asm:
* offlineasm/transform.rb:
* runtime/CommonSlowPaths.cpp:
(JSC::iterator_open_try_fast):
(JSC::iterator_open_try_fast_narrow):
(JSC::iterator_open_try_fast_wide16):
(JSC::iterator_open_try_fast_wide32):
(JSC::iterator_next_try_fast):
(JSC::iterator_next_try_fast_narrow):
(JSC::iterator_next_try_fast_wide16):
(JSC::iterator_next_try_fast_wide32):
* runtime/CommonSlowPaths.h:
* runtime/Intrinsic.cpp:
(JSC::interationKindForIntrinsic):
* runtime/Intrinsic.h:
* runtime/JSArrayIterator.h:
* runtime/JSCJSValue.h:
* runtime/JSCJSValueInlines.h:
(JSC::JSValue::isCallable const):
* runtime/JSCast.h:
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::arrayProtoValuesFunctionConcurrently const):
* runtime/OptionsList.h:
* runtime/Structure.cpp:
(JSC::Structure::dumpBrief const):
2020-04-18 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Replace DFG NewPromise with NewInternalFieldObject
https://bugs.webkit.org/show_bug.cgi?id=210687
Reviewed by Saam Barati.
The feature of DFG::NewPromise can be implemented completely with DFG::NewInternalFieldObject. This reduces code duplication, and furthermore,
this offers Object Allocation Sinking support for free. This patch replaces DFG::NewPromise with DFG::NewInternalFieldObject and remove DFG::NewPromise
completely.
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::parseBlock):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGClobbersExitState.cpp:
(JSC::DFG::clobbersExitState):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGNode.h:
(JSC::DFG::Node::convertToNewInternalFieldObject):
(JSC::DFG::Node::convertToNewInternalFieldObjectWithInlineFields):
(JSC::DFG::Node::hasIsInternalPromise):
(JSC::DFG::Node::hasStructure):
(JSC::DFG::Node::convertToNewPromise): Deleted.
* dfg/DFGNodeType.h:
* dfg/DFGObjectAllocationSinkingPhase.cpp:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileNewInternalFieldObject):
(JSC::DFG::SpeculativeJIT::compileNewPromise): Deleted.
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStoreBarrierInsertionPhase.cpp:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileNewInternalFieldObject):
(JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewInternalFieldObject):
(JSC::FTL::DFG::LowerDFGToB3::compileNewPromise): Deleted.
* ftl/FTLOperations.cpp:
(JSC::FTL::operationPopulateObjectInOSR):
(JSC::FTL::operationMaterializeObjectInOSR):
* runtime/JSInternalPromise.cpp:
(JSC::JSInternalPromise::createWithInitialValues):
* runtime/JSInternalPromise.h:
* runtime/JSPromise.cpp:
(JSC::JSPromise::createWithInitialValues):
(JSC::JSPromise::finishCreation):
(JSC::JSPromise::status const):
(JSC::JSPromise::result const):
(JSC::JSPromise::flags const):
(JSC::JSPromise::resolve):
(JSC::JSPromise::reject):
(JSC::JSPromise::rejectAsHandled):
* runtime/JSPromise.h:
(JSC::JSPromise::initialValues):
(JSC::JSPromise::internalField const):
(JSC::JSPromise::internalField):
2020-04-18 Yusuke Suzuki <ysuzuki@apple.com>
Unreviewed, build fix for ARM64E after r260310
https://bugs.webkit.org/show_bug.cgi?id=207330
r260310 uses undefined function Instruction.cloneWithNewOperands in arm64e.rb and throws an error.
This patch calls `node.cloneWithNewOperands`.
* offlineasm/arm64e.rb:
2020-04-18 Alexey Shvayka <shvaikalesh@gmail.com>
RegExp.prototype[@@search] should use SameValue
https://bugs.webkit.org/show_bug.cgi?id=173226
Reviewed by Yusuke Suzuki.
This change exposes Object.is implementation as link-time-constant @sameValue and utilizes
it in RegExp.prototype[@@search] per spec [1], aligning JSC with V8 and SpiderMonkey.
[1]: https://tc39.es/ecma262/#sec-regexp.prototype-@@search (steps 5, 8)
* builtins/BuiltinNames.h:
* builtins/RegExpPrototype.js:
(Symbol.search):
* bytecode/LinkTimeConstant.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
* runtime/ObjectConstructor.cpp:
* runtime/ObjectConstructor.h:
2020-04-18 Angelos Oikonomopoulos <angelos@igalia.com>
Fix code origin when lowering offlineasm instructions on MIPS/ARM64E
https://bugs.webkit.org/show_bug.cgi?id=207330
Reviewed by Mark Lam.
Instruction operands are mapped to RegisterID in RegisterID.forName
and the operation is memoized. Therefore, we can't use the codeOrigin
of the operand at that point. Use the codeOrigin of the original
instruction instead.
* offlineasm/arm64e.rb:
* offlineasm/ast.rb:
* offlineasm/mips.rb:
* offlineasm/risc.rb:
2020-04-18 Angelos Oikonomopoulos <angelos@igalia.com>
REGRESSION(r260246): It broke build on MIPS32
https://bugs.webkit.org/show_bug.cgi?id=210665
Reviewed by Aakash Jain.
The mnemonic for 'store halfword' is 'sh', not 'shv'. This appears to
be a typo in a path that was never exercised.
Exposed by r260246; riscLowerMisplacedAddresses now calls into
riscAsRegisters with an 'h' suffix, which results in a 'storeh'
instruction. The storeh is then lowered to the non-existent 'shv'.
* offlineasm/mips.rb:
2020-04-17 Commit Queue <commit-queue@webkit.org>
Unreviewed, reverting r260279.
https://bugs.webkit.org/show_bug.cgi?id=210678
Throwing error would be more efficient, having a generic code
is still worth doing (Requested by yusukesuzuki on #webkit).
Reverted changeset:
"[JSC] We do not need to have exit-check for Map/Set iterator
functions"
https://bugs.webkit.org/show_bug.cgi?id=210667
https://trac.webkit.org/changeset/260279
2020-04-17 Saam Barati <sbarati@apple.com>
GetTypedArrayByteOffset is broken on arm64e
https://bugs.webkit.org/show_bug.cgi?id=210631
Reviewed by Mark Lam.
The vector of JSArrayBufferView is signed even when null on arm64e. However, we were
comparing against zero, which is wrong. This patch changes it so we do the right thing
and instead compare against whatever constant (ptr=nullptr,size=0) signs as.
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileGetTypedArrayByteOffset):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileGetTypedArrayByteOffset):
* runtime/CagedBarrierPtr.h:
(JSC::CagedBarrierPtr::rawBits const):
* runtime/JSArrayBufferView.h:
(JSC::JSArrayBufferView::nullVectorPtr):
2020-04-17 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] We do not need to have exit-check for Map/Set iterator functions
https://bugs.webkit.org/show_bug.cgi?id=210667
Reviewed by Michael Saboff.
If the intrinsic's DFG node does not support general cases, we should check exit-frequency to avoid exit-recompile loop.
However, Map/Set iterator creation functions (values, keys, entries) always require Map / Set types. And throwing an error
when this is not met. So, the current DFG nodes for these intrinsic supports all the cases except for the case throwing an
error, and error will exit anyway. So we do not need to have this exit-frequency guard here.
This path is already tested by map-iterator-check-before-fail.js / set-iterator-check-before-fail.js.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
2020-04-17 Devin Rousso <drousso@apple.com>
Rename NullishEq / NULLISHEQUAL to CoalesceEq / COALESCEEQUAL to match the spec
https://bugs.webkit.org/show_bug.cgi?id=210663
Reviewed by Ross Kirsling.
* bytecompiler/NodesCodegen.cpp:
(JSC::emitShortCircuitAssignment):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::makeAssignNode):
* parser/Lexer.cpp:
(JSC::Lexer<T>::lexWithoutClearingLineTerminator):
* parser/Nodes.h:
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseAssignmentExpression):
* parser/ParserTokens.h:
2020-04-17 Devin Rousso <drousso@apple.com>
Implement Promise.any and AggregateError
https://bugs.webkit.org/show_bug.cgi?id=202566
Reviewed by Yusuke Suzuki.
`Promise.any` resolves when any of the given `promises` resolve, but only rejects if _all_
of the given `promises` reject. In order to support aggregating all of the `reason` values
for all of the rejections, a new error type `AggregateError` is introduced which has an
`get errors` that returns an aggregated array of the `reason` values.
* builtins/PromiseConstructor.js:
(all.newResolveElement):
(allSettled.newResolveRejectElements):
(any): Added.
(any.newRejectElement): Added.
* runtime/JSPromiseConstructor.cpp:
* builtins/BuiltinNames.h:
* bytecode/LinkTimeConstant.h:
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::errorStructure const):
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::initializeAggregateErrorConstructor): Added.
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
Expose `@AggregateError` for builtins.
* runtime/AggregateError.h: Added.
(JSC::AggregateError::destroy):
(JSC::AggregateError::subspaceFor):
(JSC::AggregateError::createStructure):
(JSC::AggregateError::create):
(JSC::AggregateError::errors const):
* runtime/AggregateError.cpp: Added.
(JSC::AggregateError::AggregateError):
(JSC::AggregateError::visitChildren):
(JSC::AggregateError::create):
(JSC::AggregateError::finishCreation):
* runtime/AggregateErrorPrototype.h: Added.
* runtime/AggregateErrorPrototype.cpp: Added.
(JSC::AggregateErrorPrototype::AggregateErrorPrototype):
(JSC::AggregateErrorPrototype::finishCreation):
(JSC::aggregateErrorPrototypeAccessorErrors):
* runtime/AggregateErrorConstructor.h: Added.
* runtime/AggregateErrorConstructor.cpp: Added.
(JSC::callAggregateErrorConstructor):
(JSC::constructAggregateErrorConstructor):
(JSC::AggregateErrorConstructor::AggregateErrorConstructor):
(JSC::AggregateErrorConstructor::finishCreation):
* runtime/ErrorType.h:
* runtime/ErrorType.cpp:
(JSC::errorTypeName):
* runtime/VM.h:
* runtime/VM.cpp:
(JSC::VM::VM):
Make an `IsoSubspace` for `AggregateError` as it has a different size than `ErrorInstance`.
* runtime/ErrorInstance.h:
(JSC::ErrorInstance::create):
* runtime/ErrorInstance.cpp:
(JSC::ErrorInstance::finishCreation):
* wasm/js/JSWebAssemblyCompileError.cpp:
(JSC::JSWebAssemblyCompileError::create):
* wasm/js/JSWebAssemblyLinkError.cpp:
(JSC::JSWebAssemblyLinkError::create):
* wasm/js/JSWebAssemblyRuntimeError.cpp:
(JSC::JSWebAssemblyRuntimeError::create):
Assign to `ErrorInstance` member variables inside `ErrorInstance::finishCreation` instead of
inside `ErrorInstance::create` so that subclasses don't have to do the work as well.
* runtime/Error.cpp:
(JSC::createError):
* runtime/ErrorPrototype.h:
(JSC::ErrorPrototype::createStructure):
* runtime/NativeErrorPrototype.h:
(JSC::NativeErrorPrototype::createStructure):
Drive-by: fix incorrect usage of `ErrorInstanceType` since `ErrorPrototype` does not inherit
from `ErrorInstance` (and therefore neither does `NativeErrorPrototype`).
* runtime/ArgList.h:
Add `WTF_MAKE_NONMOVABLE` to `MarkedArgumentBuffer`.
* Sources.txt:
* JavaScriptCore.xcodeproj/project.pbxproj:
2020-04-17 Ross Kirsling <ross.kirsling@sony.com>
Clean up some Intl classes following the ICU upgrade
https://bugs.webkit.org/show_bug.cgi?id=210637
Reviewed by Yusuke Suzuki.
In r259606, I removed the compile-time guards for {DateTimeFormat, NumberFormat}.prototype.formatToParts,
but I forgot to move the method setup back to the lookup table.
This patch addresses that and prunes various other unnecessary includes and forward declarations.
* runtime/IntlCollator.h:
* runtime/IntlCollatorConstructor.h:
* runtime/IntlDateTimeFormat.h:
* runtime/IntlDateTimeFormatConstructor.h:
* runtime/IntlDateTimeFormatPrototype.cpp:
(JSC::IntlDateTimeFormatPrototype::create):
(JSC::IntlDateTimeFormatPrototype::finishCreation):
* runtime/IntlDateTimeFormatPrototype.h:
* runtime/IntlNumberFormat.h:
* runtime/IntlNumberFormatConstructor.h:
* runtime/IntlNumberFormatPrototype.cpp:
(JSC::IntlNumberFormatPrototype::create):
(JSC::IntlNumberFormatPrototype::finishCreation):
* runtime/IntlNumberFormatPrototype.h:
* runtime/IntlObject.h:
* runtime/IntlPluralRules.h:
* runtime/IntlPluralRulesConstructor.h:
* runtime/IntlPluralRulesPrototype.cpp:
(JSC::IntlPluralRulesPrototype::create):
(JSC::IntlPluralRulesPrototype::finishCreation):
* runtime/IntlPluralRulesPrototype.h:
2020-04-17 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Map/Set iterator creation functions should fail with BadType etc. before executing insertChecks
https://bugs.webkit.org/show_bug.cgi?id=210649
<rdar://problem/61925452>
Reviewed by Mark Lam.
Since insertChecks adds some DFG nodes, we should determine whether this intrinsic handling is OK or not before executing insertChecks.
Otherwise, we will hit an assertion with `!didInsertChecks`.
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
2020-04-17 Mark Lam <mark.lam@apple.com>
offlineasm is generating the wrong load/store for the "orh" instruction.
https://bugs.webkit.org/show_bug.cgi?id=210639
<rdar://problem/21501876>
Reviewed by Robin Morisset.
For example, on ARM64E, the "orh" instruction was generating the following:
"\tldr w17, [x1, #0]\n" // JavaScriptCore/llint/LowLevelInterpreter64.asm:919
"\torr w17, w17, #64\n" // JavaScriptCore/llint/LowLevelInterpreter64.asm:919
"\tstr w17, [x1, #0]\n" // JavaScriptCore/llint/LowLevelInterpreter64.asm:919
i.e. a 32-bit load, followed by a 32-bit OR, followed by a 32-bit store.
Instead, it should be generating the following:
"\tldrh w17, [x1, #0]\n" // JavaScriptCore/llint/LowLevelInterpreter64.asm:919
"\torr w17, w17, #64\n" // JavaScriptCore/llint/LowLevelInterpreter64.asm:919
"\tstrh w17, [x1, #0]\n" // JavaScriptCore/llint/LowLevelInterpreter64.asm:919
i.e. a 16-bit load, followed by a 32-bit OR, followed by a 16-bit store.
This bug also affects ARM64, ARMv7, and MIPS (basically any backend that uses
riscLowerMisplacedAddresses() from rise.rb). It does not affect x86, x86_64, and
C_LOOP (which was written based on x86).
* offlineasm/risc.rb:
2020-04-16 Ross Kirsling <ross.kirsling@sony.com>
REGRESSION(r259480): Two new failing i18n tests
https://bugs.webkit.org/show_bug.cgi?id=210605
Reviewed by Darin Adler.
* runtime/IntlDateTimeFormat.cpp:
(JSC::isUTCEquivalent):
(JSC::defaultTimeZone):
(JSC::canonicalizeTimeZoneName):
The default time zone needs to be canonicalized too.
* runtime/IntlObject.cpp:
(JSC::canonicalLangTag):
(JSC::resolveLocale):
Deal with some odd ""_s cases from my previous patch.
(Drive-by fix inspired by Darin's comments on this one.)
2020-04-16 Sergio Villar Senin <svillar@igalia.com>
Unreviewed build fix for non unified builds.
* dfg/DFGOperations.cpp: Added missing includes.
2020-04-16 Mark Lam <mark.lam@apple.com>
[Re-landing] Use more PAC diversity for JIT probe code.
https://bugs.webkit.org/show_bug.cgi?id=210252
<rdar://problem/54490367>
Reviewed by Keith Miller.
Introducing new PtrTags:
JITProbePtrTag - for the client probe function.
JITProbeTrampolinePtrTag - for calling the ctiMasmProbeTrampoline.
JITProbeExecutorPtrTag - for calling the probe executor.
Currently, this is only the Probe::executeProbe().
JITProbeStackInitializationFunctionPtrTag - for calling the optional stack
initialization function that the client probe function may set.
We'll now use these in the JIT probe mechanism instead of adopting the default
CFunctionPtrTag.
Fixed an assert in MacroAssemblerARM64.cpp which does not apply to non ARM64E
builds.
* assembler/MacroAssembler.cpp:
(JSC::MacroAssembler::probe):
* assembler/MacroAssemblerARM64.cpp:
(JSC::MacroAssembler::probe):
* assembler/MacroAssemblerPrinter.h:
(JSC::MacroAssembler::print):
* assembler/ProbeContext.h:
* runtime/JSCPtrTag.h:
* tools/JSDollarVM.cpp:
(JSC::callWithStackSizeProbeFunction):
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::emitLoopTierUpCheck):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::emitLoopTierUpCheck):
2020-04-16 Mark Lam <mark.lam@apple.com>
Rolling out r259897: Causing crashes on iOS.
https://bugs.webkit.org/show_bug.cgi?id=210252
Not reviewed.
* assembler/MacroAssembler.cpp:
(JSC::MacroAssembler::probe):
* assembler/MacroAssemblerARM64.cpp:
(JSC::MacroAssembler::probe):
* assembler/MacroAssemblerPrinter.h:
(JSC::MacroAssembler::print):
* assembler/ProbeContext.h:
* runtime/JSCPtrTag.h:
* tools/JSDollarVM.cpp:
(JSC::callWithStackSizeProbeFunction):
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::emitLoopTierUpCheck):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::emitLoopTierUpCheck):
2020-04-16 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Implement JSMapIterator/JSSetIterator with JSInternalFieldObjectImpl
https://bugs.webkit.org/show_bug.cgi?id=210023
Reviewed by Keith Miller.
This patch reimplement JSMapIterator/JSSetIterator with JSInternalFieldObjectImpl.
This makes current JSFinalObject-based Map/SetIterator simple and small.
We generalize NewArrayIterator/PhantomNewArrayIterator to convert them to NewInternalFieldObject/PhantomNewInternalFieldObject
to support JSMapIterator/JSSetIterator too in DFG / FTL. This makes allocation efficient and object-allocation-sinking aware.
* builtins/BuiltinNames.h:
* builtins/MapIteratorPrototype.js:
(globalPrivate.mapIteratorNext):
(next):
* builtins/MapPrototype.js:
(globalPrivate.MapIterator): Deleted.
(values): Deleted.
(keys): Deleted.
(entries): Deleted.
* builtins/SetIteratorPrototype.js:
(globalPrivate.setIteratorNext):
(next):
* builtins/SetPrototype.js:
(globalPrivate.SetIterator): Deleted.
(values): Deleted.
(entries): Deleted.
* bytecode/BytecodeIntrinsicRegistry.cpp:
(JSC::BytecodeIntrinsicRegistry::BytecodeIntrinsicRegistry):
* bytecode/BytecodeIntrinsicRegistry.h:
* bytecompiler/BytecodeGenerator.h:
(JSC::BytecodeGenerator::emitIsMapIterator):
(JSC::BytecodeGenerator::emitIsSetIterator):
* bytecompiler/NodesCodegen.cpp:
(JSC::mapIteratorInternalFieldIndex):
(JSC::setIteratorInternalFieldIndex):
(JSC::BytecodeIntrinsicNode::emit_intrinsic_getMapIteratorInternalField):
(JSC::BytecodeIntrinsicNode::emit_intrinsic_getSetIteratorInternalField):
(JSC::BytecodeIntrinsicNode::emit_intrinsic_putMapIteratorInternalField):
(JSC::BytecodeIntrinsicNode::emit_intrinsic_putSetIteratorInternalField):
* dfg/DFGAbstractInterpreterInlines.h:
(JSC::DFG::AbstractInterpreter<AbstractStateType>::executeEffects):
* dfg/DFGByteCodeParser.cpp:
(JSC::DFG::ByteCodeParser::handleIntrinsicCall):
* dfg/DFGClobberize.h:
(JSC::DFG::clobberize):
* dfg/DFGClobbersExitState.cpp:
(JSC::DFG::clobbersExitState):
* dfg/DFGConstantFoldingPhase.cpp:
(JSC::DFG::ConstantFoldingPhase::foldConstants):
* dfg/DFGDoesGC.cpp:
(JSC::DFG::doesGC):
* dfg/DFGFixupPhase.cpp:
(JSC::DFG::FixupPhase::fixupNode):
* dfg/DFGMayExit.cpp:
* dfg/DFGNode.h:
(JSC::DFG::Node::convertToPhantomNewInternalFieldObject):
(JSC::DFG::Node::hasStructure):
(JSC::DFG::Node::isPhantomAllocation):
(JSC::DFG::Node::convertToPhantomNewArrayIterator): Deleted.
* dfg/DFGNodeType.h:
* dfg/DFGObjectAllocationSinkingPhase.cpp:
* dfg/DFGOperations.cpp:
* dfg/DFGOperations.h:
* dfg/DFGPredictionPropagationPhase.cpp:
* dfg/DFGSafeToExecute.h:
(JSC::DFG::safeToExecute):
* dfg/DFGSpeculativeJIT.cpp:
(JSC::DFG::SpeculativeJIT::compileNewInternalFieldObjectImpl):
(JSC::DFG::SpeculativeJIT::compileNewGenerator):
(JSC::DFG::SpeculativeJIT::compileNewAsyncGenerator):
(JSC::DFG::SpeculativeJIT::compileNewInternalFieldObject):
(JSC::DFG::SpeculativeJIT::compileNewArrayIterator): Deleted.
* dfg/DFGSpeculativeJIT.h:
* dfg/DFGSpeculativeJIT32_64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGSpeculativeJIT64.cpp:
(JSC::DFG::SpeculativeJIT::compile):
* dfg/DFGStoreBarrierInsertionPhase.cpp:
* ftl/FTLCapabilities.cpp:
(JSC::FTL::canCompile):
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileNode):
(JSC::FTL::DFG::LowerDFGToB3::compileNewInternalFieldObjectImpl):
(JSC::FTL::DFG::LowerDFGToB3::compileNewGenerator):
(JSC::FTL::DFG::LowerDFGToB3::compileNewAsyncGenerator):
(JSC::FTL::DFG::LowerDFGToB3::compileNewInternalFieldObject):
(JSC::FTL::DFG::LowerDFGToB3::compileMaterializeNewInternalFieldObject):
(JSC::FTL::DFG::LowerDFGToB3::compileNewArrayIterator): Deleted.
* ftl/FTLOperations.cpp:
(JSC::FTL::operationPopulateObjectInOSR):
(JSC::FTL::operationMaterializeObjectInOSR):
* inspector/JSInjectedScriptHost.cpp:
(Inspector::JSInjectedScriptHost::subtype):
(Inspector::JSInjectedScriptHost::getInternalProperties):
(Inspector::cloneMapIteratorObject):
(Inspector::cloneSetIteratorObject):
(Inspector::JSInjectedScriptHost::iteratorEntries):
* runtime/CommonIdentifiers.h:
* runtime/Intrinsic.cpp:
(JSC::intrinsicName):
* runtime/Intrinsic.h:
* runtime/JSArrayIterator.h:
* runtime/JSGlobalObject.cpp:
(JSC::JSGlobalObject::init):
(JSC::JSGlobalObject::visitChildren):
* runtime/JSGlobalObject.h:
(JSC::JSGlobalObject::mapIteratorPrototype const):
(JSC::JSGlobalObject::setIteratorPrototype const):
(JSC::JSGlobalObject::mapIteratorStructure const):
(JSC::JSGlobalObject::setIteratorStructure const):
* runtime/JSMapIterator.cpp:
(JSC::JSMapIterator::createWithInitialValues):
(JSC::JSMapIterator::finishCreation):
(JSC::JSMapIterator::visitChildren):
* runtime/JSMapIterator.h:
* runtime/JSSetIterator.cpp:
(JSC::JSSetIterator::createWithInitialValues):
(JSC::JSSetIterator::finishCreation):
(JSC::JSSetIterator::visitChildren):
* runtime/JSSetIterator.h:
* runtime/JSType.cpp:
(WTF::printInternal):
* runtime/JSType.h:
* runtime/JSTypedArrayViewPrototype.cpp:
(JSC::JSTypedArrayViewPrototype::finishCreation):
* runtime/MapPrototype.cpp:
(JSC::MapPrototype::finishCreation):
(JSC::createMapIteratorObject):
(JSC::mapProtoFuncValues):
(JSC::mapProtoFuncKeys):
(JSC::mapProtoFuncEntries):
* runtime/SetPrototype.cpp:
(JSC::SetPrototype::finishCreation):
(JSC::createSetIteratorObject):
(JSC::setProtoFuncValues):
(JSC::setProtoFuncEntries):
* runtime/VM.cpp:
(JSC::VM::setIteratorStructureSlow): Deleted.
(JSC::VM::mapIteratorStructureSlow): Deleted.
* runtime/VM.h:
(JSC::VM::setIteratorStructure): Deleted.
(JSC::VM::mapIteratorStructure): Deleted.
2020-04-15 Yusuke Suzuki <ysuzuki@apple.com>
[JSC] Use ensureStillAliveHere in FTL when content of storage should be kept alive
https://bugs.webkit.org/show_bug.cgi?id=210583
<rdar://problem/61831515>
Reviewed by Mark Lam.
The content of Butterfly / ArrayStorage is kept alive only when the owner JSCell is alive.
This means that we should keep the owner JSCell alive if we are loading content of storage
which includes JSCells. This patch inserts ensureStillAliveHere in FTL to ensure this invariant.
* ftl/FTLJITCode.cpp:
(JSC::FTL::JITCode::~JITCode): Found that we get crash with `dumpDisassembly` if FTL::JITCode is destroyed while it fails to generate code while testing this.
* ftl/FTLLowerDFGToB3.cpp:
(JSC::FTL::DFG::LowerDFGToB3::compileGetByVal):
(JSC::FTL::DFG::LowerDFGToB3::compileArrayIndexOf):
(JSC::FTL::DFG::LowerDFGToB3::compileArrayPop):
(JSC::FTL::DFG::LowerDFGToB3::compileStringCharAt):
(JSC::FTL::DFG::LowerDFGToB3::compileStringCharCodeAt):
(JSC::FTL::DFG::LowerDFGToB3::compileStringCodePointAt):
(JSC::FTL::DFG::LowerDFGToB3::compileGetByOffset):
(JSC::FTL::DFG::LowerDFGToB3::compileMultiGetByOffset):
2020-04-15 Keith Miller <keith_miller@apple.com>
Disable Store-load pair auto-vectorization for JSC
https://bugs.webkit.org/show_bug.cgi?id=210574
Reviewed by Geoffrey Garen.
slp-vectorization appears to make our slow path code significantly
slower. That's because when we materialize our constant bytecode
structs into C++ we load all the fields at the same time then
widen them to the struct's member C++ size. Since we have 3
different possible sizes Clang generates a total mess of
code. Disabling this does not appear to be a regression on any
platform I tested and improves the performance of slow path code
significantly in micro benchmarks.
* CMakeLists.txt:
* Configurations/JavaScriptCore.xcconfig:
2020-04-15 Robin Morisset <rmorisset@apple.com>
Flaky Test: fetch/fetch-worker-crash.html
https://bugs.webkit.org/show_bug.cgi?id=187257
<rdar://problem/48527526>
Reviewed by Yusuke Suzuki.
The crash is coming from setExceptionPorts which is inlined in WTF::registerThreadForMachExceptionHandling.
From the error message we know that the problem is an "invalid port right".
http://web.mit.edu/darwin/src/modules/xnu/osfmk/man/thread_set_exception_ports.html tells us that the "port right" is the third parameter to thread_set_exception_ports, which is exceptionPort in our case.
exceptionPort is a global variable defined at the top of Signals.cpp:
static mach_port_t exceptionPort;
It is set in exactly one place:
kern_return_t kr = mach_port_allocate(mach_task_self(), MACH_PORT_RIGHT_RECEIVE, &exceptionPort);
in a std::call_once, in startMachExceptionHandlerThread().
Note that startMachExceptionHandlerThread() is called from the main thread just before the point where we are stuck.. and there is no synchronization to make sure it completed and its effect is visible to the worker thread before it uses exceptionPort.
So I think the crash is due to this race between allocating exceptionPort and using it, resulting in an invalid exceptionPort being sometimes passed to the kernel.
So this patch is a simple speculative fix, by running startMachExceptionHandlerThread() in initializeThreading(), before JSLock()::lock() can be run.
* runtime/InitializeThreading.cpp:
(JSC::initializeThreading):
2020-04-15 Ross Kirsling <ross.kirsling@sony.com>
Unreviewed build fix for r260161.
* runtime/IntlObject.cpp:
(JSC::canonicalLangTag):
2020-04-15 Ross Kirsling <ross.kirsling@sony.com>
Unreviewed, address Darin's feedback on r260151.
* runtime/IntlObject.cpp:
(JSC::canonicalLangTag):
2020-04-15 Ross Kirsling <ross.kirsling@sony.com>
[ECMA-402] Extension values should default to true, canonicalize without "-true"
https://bugs.webkit.org/show_bug.cgi?id=210457
Reviewed by Yusuke Suzuki.
This patch implements two simple intertwining updates to ECMA-402:
- Valueless extension keys should not be dropped when resolving locale
https://tc39.es/ecma402/#sec-resolvelocale (9.h.4.b)
- Following UTS 35, "-true" should not appear in canonicalized locale ids
https://tc39.es/ecma402/#sec-canonicalizeunicodelocaleid
https://unicode.org/reports/tr35/#Canonical_Unicode_Locale_Identifiers
('Any type or tfield value "true" is removed.')
* runtime/IntlObject.cpp:
(JSC::canonicalLangTag):
(JSC::resolveLocale):
2020-04-15 Ross Kirsling <ross.kirsling@sony.com>
[ECMA-402] Fix Intl.DateTimeFormat patterns and fields in WebKit
https://bugs.webkit.org/show_bug.cgi?id=209783
Reviewed by Keith Miller.
This patch implements two intertwining normative changes to Intl.DateTimeFormat:
- Calendar setting must be taken into account when choosing a date-time pattern
https://github.com/tc39/ecma402/pull/349
- formatToParts must recognize relatedYear and yearName parts
https://github.com/tc39/ecma402/pull/349
* runtime/IntlDateTimeFormat.cpp:
(JSC::IntlDateTimeFormat::initializeDateTimeFormat):
(JSC::IntlDateTimeFormat::partTypeString):
2020-04-15 Devin Rousso <drousso@apple.com>
[ESNext] Implement logical assignment operators
https://bugs.webkit.org/show_bug.cgi?id=209716
Reviewed by Ross Kirsling.
Implement the logical assignment operators proposal, which is now Stage 3. It introduces
three new assignment operators which will only store the result of the rhs in the lhs if the
lhs meets the given condition:
- `??=`, for if the lhs is nullish (`null` or `undefined`)
- `||=`, for if the lhs is falsy
- `&&=`, for if the lhs is truthy
This short circuiting can be beneficial as it can avoid a redundant store when used in the
common JavaScript programming pattern of "defaulting" a parameter.
```js
function foo(x) {
x = x || 42;
}
```
If `x` is a truthy value, it would result in the rhs `x` being stored back into the lhs `x`.
In some situations, this can have negative unintended side-effects, such as for `innerHTML`.
Logical assignment operators, however, are defined such that they only store if the rhs is
to actually be needed/used, skipping the redundant store and simply returning lhs otherwise.
In the case of readonly references, this means that an error is only thrown when the
assignment occurs, meaning that if the lhs already satisfies the condition it will be used
and returned with no error.
* parser/ParserTokens.h:
* parser/Lexer.cpp:
(JSC::Lexer<T>::lexWithoutClearingLineTerminator):
* parser/Parser.cpp:
(JSC::Parser<LexerType>::parseAssignmentExpression):
* parser/ASTBuilder.h:
(JSC::ASTBuilder::makeAssignNode):
* parser/Nodes.h:
* parser/NodeConstructors.h:
(JSC::ShortCircuitReadModifyResolveNode::ShortCircuitReadModifyResolveNode): Added.
(JSC::ShortCircuitReadModifyBracketNode::ShortCircuitReadModifyBracketNode): Added.
(JSC::ShortCircuitReadModifyDotNode::ShortCircuitReadModifyDotNode): Added.
* bytecompiler/NodesCodegen.cpp:
(JSC::emitShortCircuitAssignment): Added.
(JSC::ShortCircuitReadModifyResolveNode::emitBytecode): Added.
(JSC::ShortCircuitReadModifyDotNode::emitBytecode): Added.
(JSC::ShortCircuitReadModifyBracketNode::emitBytecode): Added.
* runtime/OptionsList.h:
Add a `useLogicalAssignmentOperators` setting for controlling this feature.
2020-04-14 Devin Rousso <drousso@apple.com>
Web Inspector: Debugger: add a Step next that steps by expression
https://bugs.webkit.org/show_bug.cgi?id=210324
Reviewed by Timothy Hatcher.
Step next is a hybrid of Step over and Step into which continues execution to the next pause
opportunity within the current (or ancestor) call frame. It is especially useful when trying
to debug minified code, such as trying to continue to `c()` in `a() && b() && c();`, where
Step over would continue to the next statement (i.e. after the `;`) and Step in would
continue to the first line inside `a()` (and would require a Step out to get back).
* inspector/protocol/Debugger.json:
* inspector/agents/InspectorDebuggerAgent.h:
* inspector/agents/InspectorDebuggerAgent.cpp:
(Inspector::InspectorDebuggerAgent::stepNext): Added.
* debugger/Debugger.h:
* debugger/Debugger.cpp:
(JSC::Debugger::stepNextExpression): Added.
(JSC::Debugger::atExpression):
(JSC::Debugger::clearNextPauseState):
2020-04-13 Alexey Shvayka <shvaikalesh@gmail.com>
REGRESSION (r259587): bterlson/eshost throws during init in strict mode
https://bugs.webkit.org/show_bug.cgi?id=210470
Reviewed by Ross Kirsling.
This change makes $262.IsHTMLDDA of JSC shell a CustomValue, allowing it to be reassigned
and restoring compatibility with any version of https://github.com/bterlson/eshost.
Since putDirectCustomAccessor() is now used instead of putGetter(), scope exception assert
is no longer needed and can be safely removed, as well as JSObject::putGetter() export.
* jsc.cpp:
* runtime/JSObject.h:
2020-04-13 David Kilzer <ddkilzer@apple.com>
Replace use of Checked<size_t, RecordOverflow> with CheckedSize
<https://webkit.org/b/210461>
Reviewed by Mark Lam.
* heap/Heap.cpp:
(JSC::Heap::deprecatedReportExtraMemorySlowCase):
(JSC::Heap::extraMemorySize):
(JSC::Heap::updateAllocationLimits):
(JSC::Heap::reportExtraMemoryVisited):
* heap/SlotVisitor.h:
* runtime/ArgList.cpp:
(JSC::MarkedArgumentBuffer::expandCapacity):
2020-04-10 Michael Saboff <msaboff@apple.com>
[YARR] Allow for Unicode named capture group identifiers in non-Unicode regular expressions
https://bugs.webkit.org/show_bug.cgi?id=210309
Reviewed by Ross Kirsling.
Update YARR pattern processing to allow for non-BMP unicode identifier characters in named capture groups.
This change was discussed and approved at the March/April 2020 TC-39 meeting.
See https://github.com/tc39/ecma262/pull/1869 for the discussion and change.
Updated tryConsumeUnicodeEscape() to allow for unicode escapes in non-unicode flagged regex's.
Added the same support to consumePossibleSurrogatePair().
* yarr/YarrParser.h:
(JSC::Yarr::Parser::consumePossibleSurrogatePair):
(JSC::Yarr::Parser::parseCharacterClass):
(JSC::Yarr::Parser::parseTokens):
(JSC::Yarr::Parser::tryConsumeUnicodeEscape):
(JSC::Yarr::Parser::tryConsumeIdentifierCharacter):
2020-04-13 Michael Catanzaro <mcatanzaro@gnome.org>
Fix various build warnings
https://bugs.webkit.org/show_bug.cgi?id=210429
Reviewed by Mark Lam.
Fix -Wimplicit-fallthrough warning by adding a default case CRASH() to prevent the inner
switch from falling through to the outer switch.
* dfg/DFGArrayMode.cpp:
(JSC::DFG::ArrayMode::alreadyChecked const):
2020-04-12 Mark Lam <mark.lam@apple.com>
Enable the ability to build the ASM LLInt for ARMv7k.
https://bugs.webkit.org/show_bug.cgi?id=210412
Reviewed by Sam Weinig.
Fix the offlineasm so that it can build the ASM LLInt for ARMv7k. This patch does
not actually enable the ASM LLInt. The ARMv7k port still build the C Loop LLInt.
Also, the ARMv7k ASM LLInt is still broken and needs additional work before it
can run. This patch only fixes things so that it will build.
* JavaScriptCore.xcodeproj/project.pbxproj:
- Added generate_settings_extractor.rb to the project so that we can view it from
inside Xcode.
* offlineasm/arm.rb:
- Added support for the globaladdr LLInt instruction for ARMv7k.
* offlineasm/backends.rb:
- Fix the backend to enable ARMV7 also when building for ARMv7k.
2020-04-12 Darin Adler <darin@apple.com>
Fix a few mispellings of descendant and propagation
https://bugs.webkit.org/show_bug.cgi?id=210409
Reviewed by Mark Lam.
* ftl/FTLAbstractHeap.h: "descendants"
* offlineasm/ast.rb: "descendants"
2020-04-12 Ross Kirsling <ross.kirsling@sony.com>
[ECMA-402] WebKit Intl does not allow calendar and numberingSystem options
https://bugs.webkit.org/show_bug.cgi?id=209784
Reviewed by Myles C. Maxfield.
As an alternative to using `ca` and `nu` extensions in the locale string:
- the Intl.DateTimeFormat constructor needs to be able to take `calendar` and `numberingSystem` options
https://tc39.es/ecma402/#sec-initializedatetimeformat
- the Intl.NumberFormat needs to be able to take a `numberingSystem` option
https://tc39.es/ecma402/#sec-initializenumberformat
Since we already support `ca` and `nu`, this is a very simple addition.
The only interesting part is that we must verify that values for these options are 3-8 alphanumeric characters.
* runtime/IntlDateTimeFormat.cpp:
(JSC::IntlDateTimeFormat::initializeDateTimeFormat):
* runtime/IntlNumberFormat.cpp:
(JSC::IntlNumberFormat::initializeNumberFormat):
(JSC::IntlNumberFormat::resolvedOptions):
* runtime/IntlObject.cpp:
(JSC::isUnicodeLocaleIdentifierType):
* runtime/IntlObject.h:
2020-04-10 Ross Kirsling <ross.kirsling@sony.com>
[ECMA-402] Properly implement BigInt.prototype.toLocaleString
https://bugs.webkit.org/show_bug.cgi?id=209782
Reviewed by Darin Adler.
Our BigInt's toLocaleString has been simply falling back to toString instead of following ECMA-402.
(https://tc39.es/ecma402/#sup-bigint.prototype.tolocalestring)
Since {Number, BigInt}.prototype.toLocaleString are internally the same as Intl.NumberFormat.prototype.format,
this patch simultaneously lets the latter method take a BigInt argument.
(https://tc39.es/ecma402/#sec-number-format-functions)
This patch continues to use the old unum_* API instead of ICU 62's new unumf_* API,
as the latter would require a large refactor as well as fallback paths.
(This will, however, be a prerequisite for https://bugs.webkit.org/show_bug.cgi?id=209774.)
* runtime/BigIntPrototype.cpp:
(JSC::bigIntProtoFuncToString):
(JSC::bigIntProtoFuncToLocaleString):
(JSC::bigIntProtoFuncToStringImpl): Deleted.
* runtime/IntlNumberFormat.cpp:
(JSC::IntlNumberFormat::format):
(JSC::IntlNumberFormat::formatNumber): Deleted.
* runtime/IntlNumberFormat.h:
* runtime/IntlNumberFormatPrototype.cpp:
(JSC::IntlNumberFormatFuncFormat):
(JSC::IntlNumberFormatPrototypeGetterFormat):
(JSC::IntlNumberFormatFuncFormatNumber): Deleted.
* runtime/NumberPrototype.cpp:
(JSC::numberProtoFuncToLocaleString):
2020-04-10 Devin Rousso <drousso@apple.com>
The rhs in `ReadModifyResolveNode` should be evaluated before throwing an exception if the lhs is read-only
https://bugs.webkit.org/show_bug.cgi?id=210317
Reviewed by Ross Kirsling.
* bytecompiler/NodesCodegen.cpp:
(JSC::emitReadModifyAssignment):
(JSC::ReadModifyResolveNode::emitBytecode):
If the corresponding `Variable` is read-only, pass it to `emitReadModifyAssignment` as an
additional optionl argument, where it will be used to `emitReadOnlyExceptionIfNeeded` after
the rhs is emitted.
2020-04-10 Mark Lam <mark.lam@apple.com>
Use more PAC diversity for JIT probe code.
https://bugs.webkit.org/show_bug.cgi?id=210252
<rdar://problem/54490367>
Reviewed by Keith Miller.
Introducing new PtrTags:
JITProbePtrTag - for the client probe function.
JITProbeTrampolinePtrTag - for calling the ctiMasmProbeTrampoline.
JITProbeExecutorPtrTag - for calling the probe executor.
Currently, this is only the Probe::executeProbe().
JITProbeStackInitializationFunctionPtrTag - for calling the optional stack
initialization function that the client probe function may set.
We'll now use these in the JIT probe mechanism instead of adopting the default
CFunctionPtrTag.
* assembler/MacroAssembler.cpp:
(JSC::MacroAssembler::probe):
* assembler/MacroAssemblerARM64.cpp:
(JSC::MacroAssembler::probe):
* assembler/MacroAssemblerPrinter.h:
(JSC::MacroAssembler::print):
* assembler/ProbeContext.h:
* runtime/JSCPtrTag.h:
* tools/JSDollarVM.cpp:
(JSC::callWithStackSizeProbeFunction):
* wasm/WasmAirIRGenerator.cpp:
(JSC::Wasm::AirIRGenerator::emitLoopTierUpCheck):
* wasm/WasmB3IRGenerator.cpp:
(JSC::Wasm::B3IRGenerator::emitLoopTierUpCheck):
2020-04-10 Mark Lam <mark.lam@apple.com>
[Follow up] Fix bad tests in testmasm's testCagePreservesPACFailureBit().
https://bugs.webkit.org/show_bug.cgi?id=210314
<rdar://problem/61556785>
Not reviewed.
Applying Keith's feedback in https://bugs.webkit.org/show_bug.cgi?id=210314#c5:
added the stronger test but kept the weaker one as well.
* assembler/testmasm.cpp:
(JSC::testCagePreservesPACFailureBit):
== Rolled over to ChangeLog-2020-04-10 ==