[webkit-changes] [WebKit/WebKit] dd4b91: Fold CallFrameClosure into CachedCall.
EWS
noreply at github.com
Mon Mar 6 23:29:47 PST 2023
Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: dd4b91af70c52e54e959a591d7ab08735950423d
https://github.com/WebKit/WebKit/commit/dd4b91af70c52e54e959a591d7ab08735950423d
Author: Mark Lam <mark.lam at apple.com>
Date: 2023-03-06 (Mon, 06 Mar 2023)
Changed paths:
M Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj
M Source/JavaScriptCore/debugger/DebuggerCallFrame.cpp
M Source/JavaScriptCore/interpreter/CachedCall.h
R Source/JavaScriptCore/interpreter/CallFrameClosure.h
M Source/JavaScriptCore/interpreter/Interpreter.cpp
M Source/JavaScriptCore/interpreter/Interpreter.h
M Source/JavaScriptCore/interpreter/InterpreterInlines.h
M Source/JavaScriptCore/runtime/CallData.cpp
M Source/JavaScriptCore/runtime/ConstructData.cpp
M Source/JavaScriptCore/runtime/JSGlobalObjectFunctions.cpp
M Source/JavaScriptCore/runtime/ShadowRealmPrototype.cpp
Log Message:
-----------
Fold CallFrameClosure into CachedCall.
https://bugs.webkit.org/show_bug.cgi?id=253481
rdar://106341933
Reviewed by Yusuke Suzuki.
CallFrameClosure is always embedded into and used with a CachedCall. This patch makes
the following changes:
1. By folding it into CachedCall, we can remove many redundancies e.g. a protoCallFrame
pointer, a JSFunction pointer, a VM pointer, and argumentCountIncludingThis.
2. CallFrameClosure::parameterCountIncludingThis was also never used. So, remove it.
3. Remove CachedCall::m_interpreter because it is always as an offset from CachedCall::m_vm.
4. Make use of Interpreter::vm() to compute VM&. This eliminates the need to pass
globalObject to a few Interpreter::executeXXX functions where the sole purpose
of the globalObject is for computing VM&.
5. Add an optimization in Interpreter::executeCachedCall where we can skip the call to
ScriptExecutable::prepareForExecution if the addressForCall is unchanged.
6. Remove the now unneeded CallFrameClosure.
7. Rename Interpreter::prepareForRepeatCall to prepareForCachedCall to match what it's
actually preparing for.
This patch produces the following gains on microbenchmarks:
base new
cpp-to-js-call-as-first-entry 77.6193+-5.2323 74.1395+-0.7745 might be 1.0469x faster
cpp-to-js-call 70.7867+-0.4565 70.5623+-0.3648
cpp-to-js-cached-call 80.8428+-0.2077 ^ 58.5465+-0.1468 ^ definitely 1.3808x faster
* Source/JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj:
* Source/JavaScriptCore/debugger/DebuggerCallFrame.cpp:
(JSC::DebuggerCallFrame::evaluateWithScopeExtension):
* Source/JavaScriptCore/interpreter/CachedCall.h:
(JSC::CachedCall::CachedCall):
(JSC::CachedCall::call):
(JSC::CachedCall::function):
(JSC::CachedCall::functionExecutable):
(JSC::CachedCall::scope):
* Source/JavaScriptCore/interpreter/CallFrameClosure.h: Removed.
* Source/JavaScriptCore/interpreter/Interpreter.cpp:
(JSC::eval):
(JSC::Interpreter::executeProgram):
(JSC::Interpreter::executeCall):
(JSC::Interpreter::executeConstruct):
(JSC::Interpreter::prepareForCachedCall):
(JSC::Interpreter::executeEval):
(JSC::Interpreter::executeModuleProgram):
(JSC::Interpreter::prepareForRepeatCall): Deleted.
* Source/JavaScriptCore/interpreter/Interpreter.h:
* Source/JavaScriptCore/interpreter/InterpreterInlines.h:
(JSC::Interpreter::executeCachedCall):
* Source/JavaScriptCore/runtime/CallData.cpp:
(JSC::call):
* Source/JavaScriptCore/runtime/ConstructData.cpp:
(JSC::construct):
* Source/JavaScriptCore/runtime/JSGlobalObjectFunctions.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* Source/JavaScriptCore/runtime/ShadowRealmPrototype.cpp:
(JSC::JSC_DEFINE_HOST_FUNCTION):
* Source/JavaScriptCore/runtime/VM.h:
Canonical link: https://commits.webkit.org/261311@main
More information about the webkit-changes
mailing list