Changes between Version 2 and Version 3 of JavaScriptCore
- Timestamp:
- Feb 14, 2013 9:47:21 PM (11 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
JavaScriptCore
v2 v3 11 11 == Core Engine == 12 12 13 Like a typical scripting engine, JavaScriptCore consists of the following building blocks: lexer, parser, and interpreter.13 JavaScriptCore is an optimizing virtual machine. JavaScriptCore consists of the following building blocks: lexer, parser, start-up interpreter ('''LLInt'''), baseline JIT, and an optimizing JIT ('''DFG'''). 14 14 15 15 '''Lexer''' is responsible for the [http://en.wikipedia.org/wiki/Lexical_analysis lexical analysis], i.e. breaking down the script source into a series of ''tokens''. JavaScriptCore lexer is hand-written, it is mostly in [http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/parser/Lexer.h parser/Lexer.h] and [http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/parser/Lexer.cpp parser/Lexer.cpp]. … … 18 18 [http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/parser/JSParser.h parser/JSParser.h] and [http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/parser/JSParser.cpp parser/JSParser.cpp]. 19 19 20 ''' Interpreter''' executes the bytecodes produced by the parser. JavaScriptCore has two types of interpreter: bytecode-based and JIT-based. The former runs the bytecodes in a virtual machine, the latter uses JIT (Just-in-time) compiling approach to produce native machine codes in order to have a faster execution. The bulk of the interpreter code is in [http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/interpreter interpreter/] subdirectory with the JIT compiler in [http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/jit jit/] subdirectory.20 '''LLInt''', short for Low Level Interpreter, executes the bytecodes produced by the parser. The bulk of the Low Level Interpreter is in [http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/llint llint/]. The LLInt is written in a portable assembly called offlineasm (see [http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/offlineasm offlineasm/], which can compile to x86, ARMv7, and C. The LLInt is intended to have zero start-up cost besides lexing and parsing, while obeying the calling, stack, and register conventions used by the just-in-time compilers. For example, calling a LLInt function works "as if" the function was compiled to native code, except that the machine code entrypoint is actually a shared LLInt prologue. The LLInt includes optimizations such as inline caching to ensure fast property access. 21 21 22 (More to be written) 22 '''Baseline JIT''' kicks in for functions that are invoked at least 6 times, or take a loop at least 100 times (or some combination - like 3 invocations with 50 loop iterations total). Note, these numbers are approximate; the actual heuristics depend on function size and current memory pressure. The LLInt will on-stack-replace (OSR) to the JIT if it is stuck in a loop; as well all callers of the function are relinked to point to the compiled code as opposed to the LLInt prologue. The Baseline JIT also acts as a fall-back for functions that are compiled by the optimizing JIT: if the optimized code encounters a case it cannot handle, it bails (via an OSR exit) to the Baseline JIT. The Baseline JIT is in [http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/jit jit/]. The Baseline JIT also performs sophisticated polymorphic inline caching for almost all heap accesses. 23 23 24 == Runtime == 24 Both the LLInt and Baseline JIT collect light-weight profiling information to enable speculative execution by the next tier of execution (the DFG). Information collected includes recent values loaded into arguments, loaded from the heap, or loaded from a call return. Additionally, all inline caching in the LLInt and Baseline JIT is engineered to enable the DFG to scrape type information easily: for example the DFG can detect that a heap access sometimes, often, or always sees a particular type just by looking at the current state of an inline cache; this can be used to determine the most profitable level of speculation. 25 25 26 (To be written) 26 '''DFG JIT''' kicks in for functions that are invoked at least 60 times, or that took a loop at least 1000 times. Again, these numbers are approximate and are subject to additional heuristics. The DFG performs aggressive type speculation based on profiling information collected by the lower tiers. This allows it to forward-propagate type information, eliding many type checks. Sometimes the DFG goes further and speculates on values themselves - for example it may speculate that a value loaded from the heap is always some known function in order to enable inlining. The DFG uses deoptimization (we call it "OSR exit") to handle cases where speculation fails. Deoptimization may be synchronous (for example, a branch that checks that the type of a value is that which was expected) or asynchronous (for example, the runtime may observe that the shape or value of some object or variable has changed in a way that contravenes assumptions made by the DFG). The latter is referred to as "watchpointing" in the DFG codebase. The DFG is in [http://trac.webkit.org/browser/trunk/Source/JavaScriptCore/dfg dfg/]. 27 27 28 == Binding == 29 30 (To be written) 28 Attached are some slides from a recent talk about JavaScriptCore.
