Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: dd4b91af70c52e54e959a591d7ab08735950423d
      
https://github.com/WebKit/WebKit/commit/dd4b91af70c52e54e959a591d7ab08735950423d
  Author: Mark Lam <[email protected]>
  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


_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes

Reply via email to