Bug 25559 - Improve native function call performance
Summary: Improve native function call performance
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: JavaScriptCore (show other bugs)
Version: 528+ (Nightly build)
Hardware: All OS X 10.5
: P2 Normal
Assignee: Oliver Hunt
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-05-05 00:47 PDT by Oliver Hunt
Modified: 2009-05-05 04:34 PDT (History)
0 users

See Also:


Attachments
Patcheration (85.05 KB, patch)
2009-05-05 00:58 PDT, Oliver Hunt
barraclough: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Oliver Hunt 2009-05-05 00:47:52 PDT
Native functions calls are currently much much slower than js calls
Comment 1 Oliver Hunt 2009-05-05 00:58:40 PDT
Created attachment 30013 [details]
Patcheration
Comment 2 Gavin Barraclough 2009-05-05 02:19:42 PDT
Comment on attachment 30013 [details]
Patcheration

emitGetFromCallFrameHeader

    - please rename this to emitGetFromCallFrameHeaderPtr (I understand that you plan to do this as a separate patch.)

loadPtr(Address(regT1, RegisterFile::ScopeChain * (int32_t)sizeof(Register)), regT1);

    - it would be easier to read what this is doing if you changed this to be a call to emitGetFromCallFrameHeader[Ptr], passing the register to use as the callframe as a third optional argument.

// ArgList is passed by reference so is stackPointerRegister + 4 * sizeof(Register)
move(stackPointerRegister, X86::ecx);

    - comment in wrong in 64-bit
    - other comments in 64-bit are also lies.

as discussed, use of sizeof(Register) is confusing:

sizeof(ArgList)
COMPILE_ASSERT(sizeof(ArgList) & 0xf == 0);
poke -> storePtr(X86::ecx, Address(...));
Comment 3 Gavin Barraclough 2009-05-05 04:23:14 PDT
Comment on attachment 30013 [details]
Patcheration

loadPtr(Address(X86::esi, FIELD_OFFSET(JSFunction, m_data)), scratchRegister);
call(scratchRegister);

I would recommend not using scratchRegister outside of MacroAssembler, I would suggest adding call(Address) to avoid requiring a register here at all (jump(Address) already exists to base this on).

It would be so awesome if functions didn't have a function body node.
So awesome.
Comment 4 Oliver Hunt 2009-05-05 04:34:59 PDT
Committing to http://svn.webkit.org/repository/webkit/trunk ...
	M	JavaScriptCore/ChangeLog
	M	JavaScriptCore/JavaScriptCore.exp
	M	JavaScriptCore/JavaScriptCore.xcodeproj/project.pbxproj
	M	JavaScriptCore/assembler/MacroAssemblerX86Common.h
	M	JavaScriptCore/assembler/MacroAssemblerX86_64.h
	M	JavaScriptCore/assembler/X86Assembler.h
	M	JavaScriptCore/interpreter/Interpreter.cpp
	M	JavaScriptCore/jit/JIT.cpp
	M	JavaScriptCore/jit/JIT.h
	M	JavaScriptCore/jit/JITCall.cpp
	M	JavaScriptCore/jit/JITCode.h
	M	JavaScriptCore/jit/JITInlineMethods.h
	M	JavaScriptCore/jit/JITStubs.cpp
	M	JavaScriptCore/jit/JITStubs.h
	M	JavaScriptCore/jsc.cpp
	M	JavaScriptCore/parser/Nodes.cpp
	M	JavaScriptCore/parser/Nodes.h
	M	JavaScriptCore/profiler/Profiler.cpp
	M	JavaScriptCore/runtime/ArgList.h
	M	JavaScriptCore/runtime/ArrayPrototype.cpp
	M	JavaScriptCore/runtime/BooleanPrototype.cpp
	M	JavaScriptCore/runtime/DateConstructor.cpp
	M	JavaScriptCore/runtime/ErrorPrototype.cpp
	M	JavaScriptCore/runtime/FunctionPrototype.cpp
	M	JavaScriptCore/runtime/FunctionPrototype.h
	M	JavaScriptCore/runtime/JSFunction.cpp
	M	JavaScriptCore/runtime/JSFunction.h
	M	JavaScriptCore/runtime/JSGlobalData.cpp
	M	JavaScriptCore/runtime/JSGlobalData.h
	M	JavaScriptCore/runtime/JSGlobalObject.cpp
	M	JavaScriptCore/runtime/JSGlobalObject.h
	M	JavaScriptCore/runtime/Lookup.cpp
	M	JavaScriptCore/runtime/Lookup.h
	M	JavaScriptCore/runtime/NumberPrototype.cpp
	M	JavaScriptCore/runtime/ObjectPrototype.cpp
	M	JavaScriptCore/runtime/RegExpPrototype.cpp
	M	JavaScriptCore/runtime/StringConstructor.cpp
	M	WebCore/ChangeLog
	A	WebCore/ForwardingHeaders/jit/JITCode.h
	M	WebCore/inspector/JavaScriptDebugServer.cpp
Committed r43220