Posts on Zon8 Research

V8 Vulnerability PoCs

Sat, 05 Jun 2021 00:00:00 +0000

https://github.com/zon8research/v8-vulnerabilities

As part of our research into JavaScript Engines, we’ve collated a set of V8 vulnerability PoCs. These may be useful for studying common trends and bug styles, in addition to importing these PoCs into your fuzzing corpus.

Three sources were used to gather the dataset:

In-line PoC payloads on public V8 bug reports.
Attachments on V8 bug reports.
If there is no PoC available uploaded to the bug report, we have found the added regress/stress testcase in the V8 codebase associated with the bug report.

The following Chromium Bug Tracker search queries were useful in finding vulnerabilities that may contain PoCs:

Find Bug Reports with In-line PoC Payloads:

component:Blink>JavaScript  (status:Verified OR status:Fixed) label:Security_Severity -label:Security_Severity-Low ("function" OR "main()" OR "var " OR "v1 " OR "proto")

Find Bug Reports with PoC Attachments, or Links to External PoCs:

component:Blink>JavaScript  (status:Verified OR status:Fixed) label:Security_Severity -label:Security_Severity-Low ".js"

Using this approach, we have managed to gather a large set of PoCs from both external researchers as well as Clusterfuzz.

Note: This is not an exhaustive list, we have ignored duplicates and low severity bugs, additionally, there are likely bugs that we have missed.

JavaScriptCore Internals Part III: The DFG (Data Flow Graph) JIT -- Graph Building

Wed, 26 May 2021 00:00:00 +0000

Introduction

The DFG (Data Flow Graph) and the FTL (Faster Than Light) are the two optimising compilers used by JavaScriptCore and have been the source of a number of JIT bugs that lead to type confusions, OOB (Out-Of-Bounds) access, information leaks, etc. Some of these have been successfully exploited as part of various Pwn2Own¹ ² ³ competitions targeting Safari.

Part II examined the LLInt and Baseline JIT and explored how JavaScriptCore tiers up from one to the other and how the Baseline JIT optimises bytecode execution. This blog post will cover the DFG internals and focus on parsing bytecode to generate a DFG graph and reading DFG IR. The screenshot⁴ below shows the previously explored stages of JSC and the DFG pipeline:

This blog begins with a review of how the Baseline JIT tiers up to the DFG and triggers compilation by the DFG. It then explores the process of parsing bytecode to generate an unoptimised graph and provides the reader with an understanding of the DFG IR syntax and semantics. The blog post concludes by examining various examples of JS program constructs and the DFG graphs generated.

Existing Work

As we’ve seen in Part II a key body of work that will be revisited is the WebKit blog: Speculation in JavascriptCore. The relevant sections from this blog are Compilation and OSR which discusses in great detail the theoretical aspects of the DFG, including its IR, optimisation phases and compilation.

Tiering Up

In Part II, explored how the LLInt Tiers up into the Baseline JIT. This section looks into how the Baseline JIT tiers up into the DFG. The graph⁵ below shows the timeline on how this tiering up process pans out:

We begin by updating our debugging environment. The Baseline JIT tracing flags have been removed from launch.json and reset the internal flags in LLIntCommon.h and JIT.cpp. We’ve enabled the DFG compiler and also disabled the FTL compiler by adding the --useFTLJIT=false flag.

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(gdb) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "/home/amar/workspace/WebKit/WebKitBuild/Debug/bin/jsc",
            "args": [
                "--useConcurrentJIT=false",
                "--useFTLJIT=false",
                "--verboseOSR=true",
        
                "--thresholdForJITSoon=10", 
                "--thresholdForJITAfterWarmUp=10",

                "--reportCompileTimes=true",
                "--dumpGeneratedBytecodes=true",

                "/home/amar/workspace/WebKit/WebKitBuild/Debug/bin/test.js"
            ],
            // truncated for brevity
        }
    ]
}

With the debugging environment setup, let’s review the static execution count thresholds required to tier up from the Baseline JIT to the DFG. These static counter values are defined in OptionsList.h

v(Int32, thresholdForOptimizeAfterWarmUp, 1000, Normal, nullptr) \
v(Int32, thresholdForOptimizeAfterLongWarmUp, 1000, Normal, nullptr) \
v(Int32, thresholdForOptimizeSoon, 1000, Normal, nullptr) \

The ExecutionCounter object m_jitExecuteCounter is initialised in the generated CodeBlock to track the threshold values for DFG optimisation. The functions that set these values in the CodeBlock are defined in CodeBlock.h:

    // Call this to reinitialize the counter to its starting state,
    // forcing a warm-up to happen before the next optimization trigger
    // fires.
    void optimizeAfterWarmUp();

    // Call this to force an optimization trigger to fire only after
    // a lot of warm-up.
    void optimizeAfterLongWarmUp();

    //... truncated for brevity
    void optimizeSoon();

For an unoptimised CodeBlock, the tier-up threshold is set by the call to optimizeAfterWarmUp. If a CodeBlock was previously compiled but execution in the optimised code either OSR exited or the optimised code entered into a loop, then the tier-up threshold for re-compilation is set with the call to optimizeAfterLongWarmUp. The function optimizeSoon, is used to set the tier-up threshold when there are call frames still executing a CodeBlock and determines that it’s cheaper to delay tier-up and continue executing in a lower tier for a little longer.

Similar to the JSC flags that provides the ability to modify the static Baseline JIT thresholds at runtime (i.e. --thresholdForJITAfterWarmUp and --thresholdForJITSoon), JSC provides the following DFG JIT flags to do the same; which as we’ve seen above are: --thresholdForOptimizeAfterWarmUp,-- thresholdForOptimizeAfterLongWarmUp, --thresholdForOptimizeSoon.

Let’s now construct a test script test.js to observe DFG tiering up. The program below attempts to optimise the function jitMe using the DFG by executing it in a loop over, 1000 iterations:

$ cat test.js

function jitMe(x,y){
    return x + y;
}

let x = 1;

for(let y = 0; y < 1000; y++){
    jitMe(x,y)
}

The bytecode generated for the function jitMe is as follows:

jitMe#BcU0vO:[0x7fffae3c4130->0x7fffae3e5100, NoneFunctionCall, 15]: 6 instructions (0 16-bit instructions, 0 32-bit instructions, 1 instructions with metadata); 135 bytes (120 metadata bytes); 3 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] add                loc6, arg1, arg2, OperandTypes(126, 126)
[  13] ret                loc6
Successors: [ ]

When the opcode enter is compiled by the Baseline JIT, it emits an optimisation check to count executions of the CodeBlock in the Baseline JIT. One can inspect the emitted JIT code in the debugger by setting a breakpoint in the LLInt as described in Part II. In the screenshot below, a breakpoint is set at the jump instruction to the Baseline JIT compiled on_enter opcode pointed to by rax.

Examining the disassembly for op_enter, observe that r11 stores the reference pointer to m_jitExecuteCounter.m_counter for the CodeBlock and is set to -1000:

-exec x/10i $rip
=> 0x7fffaed00474:  movabs r11,0x7fffae3c40f4
   0x7fffaed0047e:  add    DWORD PTR [r11],0x1
   0x7fffaed00482:  jns    0x7fffaed00809
   0x7fffaed00488:  movabs r11,0x7fffeed9ac38
   0x7fffaed00492:  inc    QWORD PTR [r11]
   0x7fffaed00495:  movabs r11,0x7fffaeb0bd20
   0x7fffaed0049f:  cmp    BYTE PTR [r11],0x0
   0x7fffaed004a3:  jne    0x7fffaed008c0
   0x7fffaed004a9:  movabs r11,0x7fffeed9ac40
   0x7fffaed004b3:  inc    QWORD PTR [r11]

-exec si

[Switching to thread 2 (Thread 0x7fffef6eb700 (LWP 6093))](running)
=thread-selected,id="2"
0x00007fffaed0047e in ?? ()
-exec x/wd $r11
0x7fffae3c40f4: -1000

The jump to address 0x7fffaed00809 in the snippet above is taken when the sign flag is unset (i.e. the value referenced by the pointer stored in r11) is incremented to 0. This jump takes execution to the prologue to the function call JSC::operationOptimize(JSC::VM*, uint32_t):

-exec x/20i 0x7fffaed00809
   0x7fffaed00809:  movabs r9,0x7fffaeb09fd0
   0x7fffaed00813:  mov    r9,QWORD PTR [r9]
   0x7fffaed00816:  add    r9,0xffffffffffffffd0
#... truncated for brevity
   0x7fffaed0083d:  mov    esi,0xf0
   0x7fffaed00842:  movabs rdi,0x7fffaeb00000
   0x7fffaed0084c:  mov    DWORD PTR [rbp+0x24],0x3c
   0x7fffaed00853:  movabs r11,0x7fffaeb09fd8
   0x7fffaed0085d:  mov    QWORD PTR [r11],rbp
   0x7fffaed00860:  movabs r11,0x7ffff5e1f50a
=> 0x7fffaed0086a:  call   r11

The call to operationOptimize() is a slow path call into the Baseline JIT which is the trigger to initiate DFG compilation of the CodeBlock and eventually performs OSR Entry into the compiled CodeBlock if the compilation succeeds. A truncated version of the function with the two key actions that it takes highlighted below:

SlowPathReturnType JIT_OPERATION operationOptimize(VM* vmPointer, uint32_t bytecodeIndexBits)
{
    //... truncated for brevity

    dataLogLnIf(Options::verboseOSR(), "Triggering optimized compilation of ", *codeBlock);

    //... code truncated for brevity

    CodeBlock* replacementCodeBlock = codeBlock->newReplacement();
    CompilationResult result = DFG::compile(vm, replacementCodeBlock, nullptr, DFG::DFGMode, bytecodeIndex,
        mustHandleValues, JITToDFGDeferredCompilationCallback::create());  <-- CodeBlock compilation with DFG
        
    //... code truncated for brevity
    
    CodeBlock* optimizedCodeBlock = codeBlock->replacement();
    //... code truncated for brevity
    
    if (void* dataBuffer = DFG::prepareOSREntry(vm, callFrame, optimizedCodeBlock, bytecodeIndex)) {
        //... truncated for brevity

        codeBlock->optimizeSoon();
        codeBlock->unlinkedCodeBlock()->setDidOptimize(TriState::True);
        void* targetPC = vm.getCTIStub(DFG::osrEntryThunkGenerator).code().executableAddress();
        targetPC = retagCodePtr(targetPC, JITThunkPtrTag, bitwise_cast<PtrTag>(callFrame));
        return encodeResult(targetPC, dataBuffer);   <-- Return target address for OSR Entry into the optimised CodeBlock
    }

    //... code truncated for brevity

    return encodeResult(nullptr, nullptr);
}

In the snippet above, DFG compilation is initiated with the call to DFG::compile. Once compilation succeeds, a target address for OSR Entry into the optimised CodeBlock is acquired and returned to the BaselineJIT.

With this high level overview of now the Baseline JIT tiers-up to the DFG, let’s now dive into the details of DFG compilation. The sections that follow being by explaining how bytecode is parsed to generate a DFG, the DFG IR, and some examples typical JS programs that are represented in DFG IR.

Graph Building

Now that JSC has determined that the CodeBlock is hot enough to be compiled by the DFG, the next step is to parse the bytecodes generated for the CodeBlock into a graph that the DFG can then optimise and finally lower to machine code. Before getting started, there are some command line flags that should be enabled which will aid in debugging the DFG:

reportDFGCompileTimes : We’ve previously seen the use of the reportCompileTimes flag and the statistics it prints about compilation in the Baseline JIT. Whilst reportCompileTimes would print compile times for all JIT tiers one can restrict logging to just the DFG compile times by using the reportDFGCompileTimes flag. This is mainly to tidy up our output to stdout,
dumpBytecodeAtDFGTime : Enabling this flag will dump the bytecodes in the CodeBlock that will be compiled by the DFG,
verboseDFGBytecodeParsing : Enabling this flag will print snippets of DFG IR as each bytecode in the CodeBlock is parsed,
dumpGraphAfterParsing : Enabling this flag will print the generated unoptimised DFG to stdout

The debugging environment was updated by modifying launch.json as follows (Note that the DFG tier-up thresholds have now been reduced by adding the thresholdForOptimize flags):

{
    // truncated for brevity
    "program": "/home/amar/workspace/WebKit/WebKitBuild/Debug/bin/jsc",
    "args": [
        "--useConcurrentJIT=false",
        "--useFTLJIT=false",
        "--verboseOSR=true",
        
        "--thresholdForJITSoon=10", 
        "--thresholdForJITAfterWarmUp=10",
        "--thresholdForOptimizeAfterWarmUp=100", 
        "--thresholdForOptimizeAfterLongWarmUp=100", 
        "--thresholdForOptimizeSoon=100", 
        
        "--reportDFGCompileTimes=true",        
        "--dumpBytecodeAtDFGTime=true",
        "--verboseDFGBytecodeParsing=true",
        "--dumpGraphAfterParsing=true",

        "/home/amar/workspace/WebKit/WebKitBuild/Debug/bin/test.js"
    ],
    //truncated for brevity
}

Let’s now resume our debug tracing at DFG::Compile in JITOperations.cpp, which through a series of calls, ends up calling DFG::Plan::compileInThreadImpl. The call stack should resemble something similar to the one below:

libJavaScriptCore.so.1!JSC::DFG::Plan::compileInThreadImpl(JSC::DFG::Plan * const this) (/home/amar/workspace/WebKit/Source/JavaScriptCore/dfg/DFGPlan.cpp:240)
libJavaScriptCore.so.1!JSC::DFG::Plan::compileInThread(JSC::DFG::Plan * const this, JSC::DFG::ThreadData * threadData) (/home/amar/workspace/WebKit/Source/JavaScriptCore/dfg/DFGPlan.cpp:189)
libJavaScriptCore.so.1!JSC::DFG::compileImpl(JSC::VM & vm, JSC::CodeBlock * codeBlock, JSC::CodeBlock * profiledDFGCodeBlock, JSC::DFG::CompilationMode mode, JSC::BytecodeIndex osrEntryBytecodeIndex, const JSC::Operands<WTF::Optional<JSC::JSValue> > & mustHandleValues, WTF::Ref<JSC::DeferredCompilationCallback, WTF::DumbPtrTraits<JSC::DeferredCompilationCallback> > && callback) (/home/amar/workspace/WebKit/Source/JavaScriptCore/dfg/DFGDriver.cpp:104)
libJavaScriptCore.so.1!JSC::DFG::compile(JSC::VM & vm, JSC::CodeBlock * codeBlock, JSC::CodeBlock * profiledDFGCodeBlock, JSC::DFG::CompilationMode mode, JSC::BytecodeIndex osrEntryBytecodeIndex, const JSC::Operands<WTF::Optional<JSC::JSValue> > & mustHandleValues, WTF::Ref<JSC::DeferredCompilationCallback, WTF::DumbPtrTraits<JSC::DeferredCompilationCallback> > && callback) (/home/amar/workspace/WebKit/Source/JavaScriptCore/dfg/DFGDriver.cpp:121)
libJavaScriptCore.so.1!JSC::operationOptimize(JSC::VM * vmPointer, uint32_t bytecodeIndexBits) (/home/amar/workspace/WebKit/Source/JavaScriptCore/jit/JITOperations.cpp:1787)
[Unknown/Just-In-Time compiled code] (Unknown Source:0)
libJavaScriptCore.so.1!llint_op_call() (/home/amar/workspace/WebKit/Source/JavaScriptCore/llint/LowLevelInterpreter.asm:1047)
[Unknown/Just-In-Time compiled code] (Unknown Source:0)

The function compileInThreadImpl is responsible for three main tasks:

Parsing the bytecodes in the CodeBlock to a graph,
Optimising the graph,
Generating machine code from the optimised graph.

These have been highlighted in the truncated code snippet below:

Plan::CompilationPath Plan::compileInThreadImpl()
{
    //... code truncated for brevity
    Graph dfg(*m_vm, *this);
    {
        parse(dfg);   <-- Bytecode parsed and unoptimised graph generated.
    }

    //... code truncated for brevity
    RUN_PHASE(performLiveCatchVariablePreservationPhase);   <-- Begin graph optimisation
    RUN_PHASE(performCPSRethreading);
    RUN_PHASE(performUnification);
    //... code truncated for brevity
    switch (m_mode) {
    case DFGMode: {
        dfg.m_fixpointState = FixpointConverged;

        RUN_PHASE(performTierUpCheckInjection);
        //... truncated for brevity
        RUN_PHASE(performWatchpointCollection);
        dumpAndVerifyGraph(dfg, "Graph after optimization:");   <-- Graph optimisation complete
        
        {
            JITCompiler dataFlowJIT(dfg);     
            if (m_codeBlock->codeType() == FunctionCode)
                dataFlowJIT.compileFunction();
            else
                dataFlowJIT.compile();  <-- The optimised dfg is now compiled to machine code
        }
        
        return DFGPath;
    }
    //... code truncated for brevity
    }
}

This function is particularly important and this blog will return to it periodically in blog posts to follow. Now that one has an overview of the three main activities performed by compileInThreadImpl, the rest of this blog post will focus on the first activity which is bytecode parsing and graph generation.

Bytecode Parsing

The first step in DFG compilation is parsing bytecode to generate a graph. This is done by creating a Graph object which is initialised with the CodeBlock to be parsed and then calling the DFG::parse function on this graph object.

The DFG::parse function which is essentially a wrapper to ByteCodeParser::parse(). The function begins parsing the CodeBlock with a call to ByteCodeParser::parseCodeBlock. The function parseCodeBlock collects information about the various jump targets that the bytecodes in the CodeBlock may have. This is done by the function JSC::getJumpTargetsForInstruction.

Once jump targets have been recorded, the function parseCodeBlock enters a loop that iterates over each jump target and performs the following actions; first it allocates a BasicBlock and appends it to the graph object. If this is the first block in the graph, it is marked as an OSR target and a reference to the block is appended to the list of root nodes in the graph:

for (unsigned jumpTargetIndex = 0; jumpTargetIndex <= jumpTargets.size(); ++jumpTargetIndex) {
    unsigned limit = jumpTargetIndex < jumpTargets.size() ? jumpTargets[jumpTargetIndex] : codeBlock->instructions().size();

    // Loop until we reach the current limit (i.e. next jump target).
    do {
        if (!m_currentBlock) {
            m_currentBlock = allocateTargetableBlock(m_currentIndex);

            // The first block is definitely an OSR target.
            if (m_graph.numBlocks() == 1) {
                m_currentBlock->isOSRTarget = true;
                m_graph.m_roots.append(m_currentBlock);
            }
            prepareToParseBlock();
        }

        parseBlock(limit);

        //... code truncated for brevity
    } while (m_currentIndex.offset() < limit);
}

Once the BasicBlock has been allocated, it then calls ByteCodeParser::parseBlock with the argument limit. This argument determines the number of bytecode instructions within the CodeBlock that need to be included in the BasicBlock that was allocated.The function parseBlock is responsible for the parsing of this set of bytecode instructions and generating nodes and edges for the BasicBlock.

The function begins by evaluating if the basic block that is being parsed is the first block in the graph, if this is the case then each argument value to the basic block is appended as a Node to the graph. In the example script test.js above, argument values would be the parameters (i.e. x, y and this) passed to the function jitMe.

Nodes represent a single DFG operation. With the arguments added to the graph, the function then loops over each opcode in the bytecode list and appends one or more Nodes to the graph with the call to the overloaded function addToGraph. The truncated parseBlock with the key functionalities annotated with comments is shown below:

void ByteCodeParser::parseBlock(unsigned limit)
{
    auto& instructions = m_inlineStackTop->m_codeBlock->instructions();
    BytecodeIndex blockBegin = m_currentIndex;

    if (m_currentBlock == m_graph.block(0) && !inlineCallFrame()) {
        //... code truncated for brevity
        for (unsigned argument = 0; argument < m_numArguments; ++argument) {
            VariableAccessData* variable = newVariableAccessData(
                virtualRegisterForArgumentIncludingThis(argument));
           //... code truncated for brevity
            
            /* Add argument to graph */
            Node* setArgument = addToGraph(SetArgumentDefinitely, OpInfo(variable));     
            //... code truncated for brevity
        }
    }

    CodeBlock* codeBlock = m_inlineStackTop->m_codeBlock;

    auto jumpTarget = [&](int target) {
        if (target)
            return target;
        return codeBlock->outOfLineJumpOffset(m_currentInstruction);
    };

    /* Loop over each opcode in the list of bytecode instruction list */
    while (true) {
        //... code truncated for brevity
        
        // Switch on the current bytecode opcode.
        const Instruction* currentInstruction = instructions.at(m_currentIndex).ptr();
        m_currentInstruction = currentInstruction; // Some methods want to use this, and we'd rather not thread it through calls.
        OpcodeID opcodeID = currentInstruction->opcodeID();
        
        //... code truncated for brevity
        
        switch (opcodeID) {

        // === Function entry opcodes ===

        case op_enter: {
            Node* undefined = addToGraph(JSConstant, OpInfo(m_constantUndefined));
            // Initialize all locals to undefined.
            for (int i = 0; i < m_inlineStackTop->m_codeBlock->numVars(); ++i)
                set(virtualRegisterForLocal(i), undefined, ImmediateNakedSet);

            NEXT_OPCODE(op_enter);
        }
            
        //... code truncated for brevity

        // === Arithmetic operations ===

        case op_add: {
            auto bytecode = currentInstruction->as<OpAdd>();
            Node* op1 = get(bytecode.m_lhs);
            Node* op2 = get(bytecode.m_rhs);
            if (op1->hasNumberResult() && op2->hasNumberResult())
                set(bytecode.m_dst, makeSafe(addToGraph(ArithAdd, op1, op2)));
            else
                set(bytecode.m_dst, makeSafe(addToGraph(ValueAdd, op1, op2)));
            NEXT_OPCODE(op_add);
        }

        //... code truncated for brevity

        case op_mov: {
            auto bytecode = currentInstruction->as<OpMov>();
            Node* op = get(bytecode.m_src);
            set(bytecode.m_dst, op);
            NEXT_OPCODE(op_mov);
        }

        //... code truncated for brevity
        }
    }
}

Each basic block in the CodeBlock is parsed by the function parseBlock and adds Nodes to an unoptimised graph before returning to its calling function parseCodeBlock. The function parseCodeBlock returns once all basic blocks in the CodeBlock have been parsed and BasicBlocks, Nodes and Edges have been appended to the unoptimised graph.

As the instructions in the CodeBlock are parsed, each parsing step is logged to stdout when the --verboseDFGBytecodeParsing=true is added. Using our test script test.js and initiating DFG compilation of the jitMe function, the following output is logged to stdout:

Parsing jitMe#BcU0vO:[0x7fffae3c4260->0x7fffae3c4130->0x7fffae3e5100, NoneFunctionCall, 15]
Parsing jitMe#BcU0vO:[0x7fffae3c4260->0x7fffae3c4130->0x7fffae3e5100, NoneFunctionCall, 15]
jitMe#BcU0vO:[0x7fffae3c4130->0x7fffae3e5100, BaselineFunctionCall, 15]: 6 instructions (0 16-bit instructions, 0 32-bit instructions, 1 instructions with metadata); 135 bytes (120 metadata bytes); 3 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] add                loc6, arg1, arg2, OperandTypes(126, 126)
[  13] ret                loc6
Successors: [ ]


Jump targets: 
        appended D@0 SetArgumentDefinitely
        appended D@1 SetArgumentDefinitely
        appended D@2 SetArgumentDefinitely
    parsing bc#0: op_enter
        appended D@3 CountExecution
        appended D@4 JSConstant
        appended D@5 MovHint
        appended D@6 SetLocal

//... truncated for brevity
    
    parsing bc#7: op_add
        appended D@27 CountExecution
        appended D@28 GetLocal
        appended D@29 GetLocal
        appended D@30 ValueAdd
        appended D@31 MovHint
        appended D@32 SetLocal
    parsing bc#13: op_ret
        appended D@33 CountExecution
        appended D@34 Return
        appended D@35 Flush
        appended D@36 Flush
        appended D@37 Flush
Done parsing jitMe#BcU0vO:[0x7fffae3c4260->0x7fffae3c4130->0x7fffae3e5100, NoneFunctionCall, 15] (fell off end)

The snippet above lists the bytecodes that comprise the jitMe function and the DFG Nodes that were generated for each bytecode. The values D@1, D@2, D@3, etc represent the Node and the values SetArgumentDefinitely, CountExecution, JSConstant, etc represent the DFG opcode.

The function DFG::parse returns when a complete unoptimised DFG for the function jitMe has been generated. With the --dumpGraphAfterParsing=true flag set, one can see the final graph printed to stdout:

Graph after parsing:

         : DFG for jitMe#BcU0vO:[0x7fffae3c4260->0x7fffae3c4130->0x7fffae3e5100, DFGFunctionCall, 15]:
         :   Fixpoint state: BeforeFixpoint; Form: LoadStore; Unification state: LocallyUnified; Ref count state: EverythingIsLive
         :   Arguments for block#0: D@0, D@1, D@2

     0   : Block #0 (bc#0): (OSR target)
     0   :   Execution count: 1.000000
     0   :   Predecessors:
     0   :   Successors:
     0   :   States: StructuresAreWatched, CurrentlyCFAUnreachable
     0   :   Vars Before: <empty>
     0   :   Intersected Vars Before: arg2:(FullTop, TOP, TOP, none:StructuresAreClobbered) arg1:(FullTop, TOP, TOP, none:StructuresAreClobbered) arg0:(FullTop, TOP, TOP, none:StructuresAreClobbered) loc0:(FullTop, TOP, TOP, none:StructuresAreClobbered) loc1:(FullTop, TOP, TOP, none:StructuresAreClobbered) loc2:(FullTop, TOP, TOP, none:StructuresAreClobbered) loc3:(FullTop, TOP, TOP, none:StructuresAreClobbered) loc4:(FullTop, TOP, TOP, none:StructuresAreClobbered) loc5:(FullTop, TOP, TOP, none:StructuresAreClobbered) loc6:(FullTop, TOP, TOP, none:StructuresAreClobbered) loc7:(FullTop, TOP, TOP, none:StructuresAreClobbered)
     0   :   Var Links: 
  0  0   :    D@0:< 1:->        SetArgumentDefinitely(this(a), W:SideState, bc#0, ExitValid)  predicting None
  1  0   :    D@1:< 1:->        SetArgumentDefinitely(arg1(B~/FlushedJSValue), W:SideState, bc#0, ExitValid)  predicting None
  2  0   :    D@2:< 1:->        SetArgumentDefinitely(arg2(C~/FlushedJSValue), W:SideState, bc#0, ExitValid)  predicting None
  3  0   :    D@3:0:->        CountExecution(MustGen, 0x7fffeed961b0, R:InternalState, W:InternalState, bc#0, ExitValid)
  4  0   :    D@4:< 1:->        JSConstant(JS|PureInt, Undefined, bc#0, ExitValid)
//... truncated for brevity
 30  0   :   D@30:0:->        ValueAdd(Check:Untyped:D@28, Check:Untyped:D@29, JS|MustGen|PureInt, R:World, W:Heap, Exits, ClobbersExit, bc#7, ExitValid)
 31  0   :   D@31:0:->        MovHint(Check:Untyped:D@30, MustGen, loc6, W:SideState, ClobbersExit, bc#7, ExitInvalid)
 32  0   :   D@32:< 1:->        SetLocal(Check:Untyped:D@30, loc6(L~/FlushedJSValue), W:Stack(loc6), bc#7, exit: bc#13, ExitValid)  predicting None
 33  0   :   D@33:0:->        CountExecution(MustGen, 0x7fffeed96228, R:InternalState, W:InternalState, bc#13, ExitValid)
 34  0   :   D@34:0:->        Return(Check:Untyped:D@30, MustGen, W:SideState, Exits, bc#13, ExitValid)
 35  0   :   D@35:0:->        Flush(MustGen, arg2(C~/FlushedJSValue), R:Stack(arg2), W:SideState, bc#13, ExitValid)  predicting None
 36  0   :   D@36:0:->        Flush(MustGen, arg1(B~/FlushedJSValue), R:Stack(arg1), W:SideState, bc#13, ExitValid)  predicting None
 37  0   :   D@37:0:->        Flush(MustGen, this(a), R:Stack(this), W:SideState, bc#13, ExitValid)  predicting None
     0   :   States: InvalidBranchDirection, StructuresAreWatched
     0   :   Vars After: <empty>
     0   :   Var Links: arg2:D@35 arg1:D@36 arg0:D@37 loc0:D@6 loc1:D@8 loc2:D@10 loc3:D@12 loc4:D@21 loc5:D@24 loc6:D@32

         : GC Values:
         :     Weak:Object: 0x7fffeedbb068 with butterfly (nil) (Structure %Bw:JSGlobalLexicalEnvironment), StructureID: 7676
//... truncated for brevity

The graph above is represented in DFG IR and in the next section we explore the three main IR constructs (i.e. BasicBlocks, Nodes and Edges) and how to read and interpret graphs.

DFG IR

The DFG IR is the intermediate representation that is generated by the DFG bytecode parser. A DFG graph as seen in the example above is made up of one or more BasicBlocks and each BasicBlock is an ordered collection of Nodes. A Node in a BasicBlock represents a DFG instruction/opcode and can also be linked to child nodes via Edges. This IR is used by both the DFG and FTL tiers.

Let’s attempt to generate DFG graphs for some common JavaScript language constructs and review the graph output. This will provide a more practical exploration of Nodes and Edges. To get familiar with the IR and its representation, let’s being with the following test program that does trivial arithmetic and some load and store operations:

$ cat test.js

function jitMe(y){
    arr[y] += obj.sum;
    obj.sum += y
}

let arr = [];
let obj = {sum: 0}

for(let y = 0; y < 1000; y++){
    jitMe(y)
}

The goal of the program above is to DFG compile the jitMe function and this is achieved by invoking it a 1000 times in a for loop to trigger DFG compilation. The bytecodes generated for the function jitMe are listed below:

jitMe#EGS36l:[0x7fffae3c4130->0x7fffae3e5100, BaselineFunctionCall, 99]: 20 instructions (0 16-bit instructions, 0 32-bit instructions, 13 instructions with metadata); 219 bytes (120 metadata bytes); 2 parameter(s); 12 callee register(s); 6 variable(s); scope at loc4

bb#1
[   0] enter              
[   1] get_scope          loc4
[   3] mov                loc5, loc4

//... truncated for brevity

[  80] get_by_id          loc8, loc7, 2
[  85] add                loc8, loc8, arg1, OperandTypes(126, 126)
[  91] put_by_id          loc7, 2, loc8, 
[  97] ret                Undefined(const0)
Successors: [ ]


Identifiers:
  id0 = arr
  id1 = obj
  id2 = sum

Let’s attempt to print the unoptimised DFG generated from parsing these bytecodes. DFG printing is done by the function Graph::dump, one can set a breakpoint at this function to observe the graph output generation. The graph generated for this function is as follows:

Graph after parsing:

         : DFG for jitMe#EGS36l:[0x7fffae3c4260->0x7fffae3c4130->0x7fffae3e5100, DFGFunctionCall, 99]:
         :   Fixpoint state: BeforeFixpoint; Form: LoadStore; Unification state: LocallyUnified; Ref count state: EverythingIsLive
         :   Arguments for block#0: D@0, D@1

     0   : Block #0 (bc#0): (OSR target)
     0   :   Execution count: 1.000000
     0   :   Predecessors:
     0   :   Successors:
     0   :   States: StructuresAreWatched, CurrentlyCFAUnreachable
     0   :   Vars Before: <empty>
     0   :   Intersected Vars Before: arg1:(FullTop, TOP, TOP, none:StructuresAreClobbered) arg0:(FullTop, TOP, TOP, none:StructuresAreClobbered) loc0:(FullTop, TOP, TOP, none:StructuresAreClobbered) loc1:(FullTop, TOP, TOP, none:StructuresAreClobbered) loc2:(FullTop, TOP, TOP, none:StructuresAreClobbered) loc3:(FullTop, TOP, TOP, none:StructuresAreClobbered) loc4:(FullTop, TOP, TOP, none:StructuresAreClobbered) loc5:(FullTop, TOP, TOP, none:StructuresAreClobbered) loc6:(FullTop, TOP, TOP, none:StructuresAreClobbered) loc7:(FullTop, TOP, TOP, none:StructuresAreClobbered) loc8:(FullTop, TOP, TOP, none:StructuresAreClobbered) loc9:(FullTop, TOP, TOP, none:StructuresAreClobbered) loc10:(FullTop, TOP, TOP, none:StructuresAreClobbered) loc11:(FullTop, TOP, TOP, none:StructuresAreClobbered)
     0   :   Var Links: 
  0  0   :    D@0:< 1:->        SetArgumentDefinitely(this(a), W:SideState, bc#0, ExitValid)  predicting None
  1  0   :    D@1:< 1:->        SetArgumentDefinitely(arg1(B~/FlushedJSValue), W:SideState, bc#0, ExitValid)  predicting None
  2  0   :    D@2:0:->        CountExecution(MustGen, 0x7fffeed99310, R:InternalState, W:InternalState, bc#0, ExitValid)
  3  0   :    D@3:< 1:->        JSConstant(JS|PureInt, Undefined, bc#0, ExitValid)
  4  0   :    D@4:0:->        MovHint(Check:Untyped:D@3, MustGen, loc0, W:SideState, ClobbersExit, bc#0, ExitValid)
  5  0   :    D@5:< 1:->        SetLocal(Check:Untyped:D@3, loc0(C~/FlushedJSValue), W:Stack(loc0), bc#0, ExitInvalid)  predicting None
  6  0   :    D@6:0:->        MovHint(Check:Untyped:D@3, MustGen, loc1, W:SideState, ClobbersExit, bc#0, ExitInvalid)
  7  0   :    D@7:< 1:->        SetLocal(Check:Untyped:D@3, loc1(D~/FlushedJSValue), W:Stack(loc1), bc#0, ExitInvalid)  predicting None
  8  0   :    D@8:0:->        MovHint(Check:Untyped:D@3, MustGen, loc2, W:SideState, ClobbersExit, bc#0, ExitInvalid)
  9  0   :    D@9:< 1:->        SetLocal(Check:Untyped:D@3, loc2(E~/FlushedJSValue), W:Stack(loc2), bc#0, ExitInvalid)  predicting None

//... truncated for brevity

 92  0   :   D@92:0:->        FilterPutByIdStatus(Check:Untyped:D@77, MustGen, (<Replace: [0x7fffae3c8230:[0xb538, Object, {sum:0}, NonArray, Proto:0x7fffeedf2ee8, Leaf]], offset = 0, >), W:SideState, bc#91, ExitValid)
 93  0   :   D@93:0:->        PutByOffset(Check:Untyped:D@77, Check:Untyped:D@77, Check:Untyped:D@88, MustGen, id2{sum}, 0, W:NamedProperties(2), ClobbersExit, bc#91, ExitValid)
 94  0   :   D@94:0:->        CountExecution(MustGen, 0x7fffeed99480, R:InternalState, W:InternalState, bc#97, ExitValid)
 95  0   :   D@95:< 1:->        JSConstant(JS|PureInt, Undefined, bc#97, ExitValid)
 96  0   :   D@96:0:->        Return(Check:Untyped:D@95, MustGen, W:SideState, Exits, bc#97, ExitValid)
 97  0   :   D@97:0:->        Flush(MustGen, arg1(B~/FlushedJSValue), R:Stack(arg1), W:SideState, bc#97, ExitValid)  predicting None
 98  0   :   D@98:0:->        Flush(MustGen, this(a), R:Stack(this), W:SideState, bc#97, ExitValid)  predicting None
     0   :   States: InvalidBranchDirection, StructuresAreWatched
     0   :   Vars After: <empty>
     0   :   Var Links: arg1:D@97 arg0:D@98 loc0:D@5 loc1:D@7 loc2:D@9 loc3:D@11 loc4:D@20 loc5:D@23 loc6:D@74 loc7:D@79 loc8:D@90 loc9:D@63 loc10:D@51 loc11:D@56

         : GC Values:
         :     Weak:Object: 0x7fffae3c0000 with butterfly (nil) (Structure %Cv:Object), StructureID: 46392
         :     Weak:Object: 0x7fffeeda5868 with butterfly 0x7ff8652e84d8 (Structure %CM:Array,ArrayWithContiguous), StructureID: 1743
         :     Weak:Object: 0x7fffeedbb068 with butterfly (nil) (Structure %DU:JSGlobalLexicalEnvironment), StructureID: 20457
         :     Weak:Object: 0x7fffae3f59e0 with butterfly (nil) (Structure %BK:Function), StructureID: 13677
         : Desired watchpoints:
         :     Watchpoint sets: 0x7fffeeda7940, 0x7fffeeda7920
         :     Inline watchpoint sets: 0x7fffae3f9478, 0x7fffae3c8288, 0x7fffeedca280, 0x7fffae3f8448, 0x7fffae3f91d8, 0x7fffeedca0c0
         :     SymbolTables: 
         :     FunctionExecutables: 0x7fffae3e5100
         :     Buffer views: 
         :     Object property conditions: <Object: 0x7fffae3c0000 with butterfly (nil) (Structure %Cv:Object), StructureID: 46392: Presence of sum at 0 with attributes 0>
         : Structures:
         :     %BK:Function                   = 0x7fffae3f9420:[0x356d, Function, {}, NonArray, Proto:0x7fffeedfc248, Leaf]
         :     %CM:Array,ArrayWithContiguous  = 0x7fffae3f9ce0:[0x6cf, Array, {}, ArrayWithContiguous, Proto:0x7fffeedb62e8]
         :     %Cv:Object                     = 0x7fffae3c8230:[0xb538, Object, {sum:0}, NonArray, Proto:0x7fffeedf2ee8, Leaf]
         :     %DU:JSGlobalLexicalEnvironment = 0x7fffae3f9180:[0x4fe9, JSGlobalLexicalEnvironment, {}, NonArray, Leaf]

The graph dump lists the various blocks that represent the bytecodes being optimised. Each DFG block represents a basic block in the bytecode dump. A DFG block consists of a Head, the block Body and a block Tail. The end of the graph dump lists information on the various JSC objects, watchpoints and structures that are referenced by the graph and their locations in memory. Let’s now dissect the various sections of this graph and explore them in greater detail.

Graph Header

The start of the output prints the header information for the graph:

: DFG for jitMe#EGS36l:[0x7fffae3c4260->0x7fffae3c4130->0x7fffae3e5100, DFGFunctionCall, 99]:
:   Fixpoint state: BeforeFixpoint; Form: LoadStore; Unification state: LocallyUnified; Ref count state: EverythingIsLive
:   Arguments for block#0: D@0, D@1

The first line prints details about the CodeBlock being parsed, the codeType which is DFGFunctionCall and the number of instructions in the CodeBlock. The second line prints the OptimizationFixpointState which can be thought of as a flag that tracks state changes during the various optimisation phases. the WebKit blog⁶ describes fixpoint as follows:

fixpoint: we keep executing every instruction until we no longer observe any changes.

The DFG GraphForm which can be one of three values LoadStore, ThreadedCPS and SSA, these are described in greater detail in the developer comments. The GraphForm gets modified depending on the various stages of optimisation that have occurred. For example, DFG optimisations are applied on graphs that are in ThreadedCPS form whereas majority of FTL optimisations require that the graph be in SSA form.

The UnificationState and RefCountState present additional statistics about the graph at various optimisation phases. The last line in the header lists the argument nodes that have been generated for the block #0 which is the entry block into the graph. These argument nodes are D@0 and D@1 which represent the JavaScript values this and num.

Block Head

What follows the graph header is a dump of each BasicBlock in the graph. The block dump is comprised of a head, a block body and a tail. Let’s examine the only block in this dump which is Block #0. In the snippet below the interesting details are the Var listings, this is essentially a dump of all the arguments, locals and temporary variables used by the basic block.

     0   : Block #0 (bc#0): (OSR target)
     0   :   Execution count: 1.000000
     0   :   Predecessors:
     0   :   Successors:
     0   :   States: StructuresAreWatched, CurrentlyCFAUnreachable
     0   :   Vars Before: <empty>
     0   :   Intersected Vars Before: arg1:(FullTop, TOP, TOP, none:StructuresAreClobbered) arg0:(FullTop, TOP, TOP, none:StructuresAreClobbered) loc0:(FullTop, TOP, TOP, none:StructuresAreClobbered) loc1:(FullTop, TOP, TOP, none:StructuresAreClobbered) loc2:(FullTop, TOP, TOP, none:StructuresAreClobbered) loc3:(FullTop, TOP, TOP, none:StructuresAreClobbered) loc4:(FullTop, TOP, TOP, none:StructuresAreClobbered) loc5:(FullTop, TOP, TOP, none:StructuresAreClobbered) loc6:(FullTop, TOP, TOP, none:StructuresAreClobbered) loc7:(FullTop, TOP, TOP, none:StructuresAreClobbered) loc8:(FullTop, TOP, TOP, none:StructuresAreClobbered) loc9:(FullTop, TOP, TOP, none:StructuresAreClobbered) loc10:(FullTop, TOP, TOP, none:StructuresAreClobbered) loc11:(FullTop, TOP, TOP, none:StructuresAreClobbered)
     0   :   Var Links:

The Vars Before list in the Block Head represents a list of values at the head. This list is populated after the CFA optimisation phase and contains a list of AbstractValues that were recorded at the start of the block. AbstractValues are speculated values that are inferred by the Abstract Interpreter

The Intersected Vars Before list is an intersection of assumptions we have made previously at the head of this block and assumptions we had used for optimizing the given basic block. Each operand (i.e. args and locs) is represented by a tuple of four values. The first value (e.g. FullTop) represents the speculated type of the argument or local variable. Since this is the graph generated after parsing the bytecodes, it hasn’t been optimised yet to include predicted values. The second and third value in the tuple (e.g. TOP) represent the AbstractHeap::Payload, more on this will be covered in Part IV which is dedicated to graph optimisation. The final value in the tuple represents the ClobberState of the structure which can be one of two values:

enum StructureClobberState : uint8_t {
    StructuresAreWatched, // Constants with watchable structures must have those structures.
    StructuresAreClobbered // Constants with watchable structures could have any structure.
};

The Var Links list in the block head refer to the list of variables at head. This list maps arguments, locals and temporary variable to nodes in the various blocks of the DFG.

Note: The term variable and operand are used interchangeably in the context of the DFG IR. These should not be confused with JS variables defined in the example script.

Predecessors and Successors define the basic blocks that allow control and data to flow from and to the current block (in this instance the current block is Block #0). Since the bytecodes generated for the program above don’t include any branching opcodes (e.g. comparison operators, loops, etc) the values of Predecessor and Successors are empty. Examples of branching code will be demonstrated in sections to follow.

Block Body

Now that we’ve reviewed the header, lets look into node representation. The developer comments provide a very helpful explanation on how to read this representation. This is shown in the code listing below:

// Example/explanation of dataflow dump output
//
//   D@14:     GetByVal(@3, @13)
//     ^1     ^2 ^3     ^4       ^5
//
// (1) The nodeIndex of this operation.
// (2) The reference count. The number printed is the 'real' count,
//     not including the 'mustGenerate' ref. If the node is
//     'mustGenerate' then the count it prefixed with '!'.
// (3) The virtual register slot assigned to this node.
// (4) The name of the operation.
// (5) The arguments to the operation. The may be of the form:
//         D@#  - a NodeIndex referencing a prior node in the graph.
//         arg# - an argument number.
//         id#  - the index in the CodeBlock of an identifier { if codeBlock is passed to dump(), the string representation is displayed }.
//         var# - the index of a var on the global object, used by GetGlobalVar/GetGlobalLexicalVariable/PutGlobalVariable operations.

Nodes

Let’s look at the nodes generated for the add opcode in bytecode bc#85 from the graph dump above:

 87  0   :   D@87:0:->  CountExecution(MustGen, 0x7fffeed99440, R:InternalState, W:InternalState, bc#85, ExitValid)
 88  0   :   D@88:0:->  ValueAdd(Check:Untyped:D@84, Check:Untyped:D@40, JS|MustGen|PureInt, R:World, W:Heap, Exits, ClobbersExit, bc#85, ExitValid)
 89  0   :   D@89:0:->  MovHint(Check:Untyped:D@88, MustGen, loc8, W:SideState, ClobbersExit, bc#85, ExitInvalid)
 90  0   :   D@90:< 1:->  SetLocal(Check:Untyped:D@88, loc8(W~/FlushedJSValue), W:Stack(loc8), bc#85, exit: bc#91, ExitValid)  predicting None

The column on the left indicates the node index followed by BasicBlock index. The values of the form D@ represent the Node. Let’s examine the following node:

87  0   :   D@87:0:->  CountExecution(MustGen, 0x7fffeed99440, R:InternalState, W:InternalState, bc#85, ExitValid)

D@87 represents the 87th Node in the block #0. The expression !0 indicates that the Node must be generated and has a reference count of zero and the - in indicates that there isn’t a virtual register that’s assigned to the node. Reference counts and spill registers will become more relevant during the discussion on graph optimisation covered in Part IV.

The DFG opcode or node type is CountExecution. The NodeType defines the DFG operation performed by the node itself. Various NodeTypes are defined in dfg/DFGNodeType.h along with helpful comments on their functions. The snippet below shows some of the NodeTypes that can be defined:

#define FOR_EACH_DFG_OP(macro) \
    /* A constant in the CodeBlock's constant pool. */\
    macro(JSConstant, NodeResultJS) \
    \
    /* Constants with specific representations. */\
    macro(DoubleConstant, NodeResultDouble) \
    macro(Int52Constant, NodeResultInt52) \
    \
    /* Lazy JSValue constant. We don't know the JSValue bits of it yet. */\
    macro(LazyJSConstant, NodeResultJS) \
    \
    /* Marker to indicate that an operation was optimized entirely and all that is left */\
    /* is to make one node alias another. CSE will later usually eliminate this node, */\
    /* though it may choose not to if it would corrupt predictions (very rare). */\
    macro(Identity, NodeResultJS) \
    /* Used for debugging to force a profile to appear as anything we want. */ \

    //... truncated for brevity

The DFG opcode is followed by the node flags which is this case is MustGen. NodeFlags help define properties of the result from node computation. These flags are defined in dfg/DFGNodeFlags.h.

Tip: Another useful source to learn more about NodeTypes and NodeFlags is to grep through the several changelogs in the WebKit repo. The developer comments in the changelog provide helpful insight on nodes and their functionality within the graph.

Nodes also define operands which are represented by the OpInfo structure. The developer comments describes the structure as follows:

This type used in passing an immediate argument to Node constructor; distinguishes an immediate value (typically an index into a CodeBlock data structure - a constant index, argument, or identifier) from a Node*.

In the snippet above the value 0x7fffeed99440 is the raw pointer to the execution counter which is stored as an immediate value.

The R and W values determine what parts of the program state (i.e. Abstract Heaps) the node can read and write to. This is defined by the function clobberize which records aliasing information about a Node. clobberize is described in great detail in the WebKit blog⁶.

The value bc#85 indicates the bytecode index for which the node was generated for and is known as the NodeOrigin. This bytecode index is also the exit bytecode for the node unless an explicit exit bytecode is specified. The last value in the snippet above is ExitValid which indicates if the node is a valid point for OSR exit to occur. These three values define the NodeOrigin which are defined in dfg/DFGNodeOrigin.h and describe three properties of the Node.

Edges

Let’s now examine a node with Edges form the nodes generated for the add opcode:

 88  0   :   D@88:0:->  ValueAdd(Check:Untyped:D@84, Check:Untyped:D@40, JS|MustGen|PureInt, R:World, W:Heap, Exits, ClobbersExit, bc#85, ExitValid)

Here the DFG node D@88 defines part of the add operation. ValueAdd has edges to two child nodes, D@84 and D@40 on which it performs an addition operation. It isn’t specified what type of addition operation will be performed (e.g. arithmetic addition, string concatenation, etc.) on these two nodes and as a result, the DFG will add Check flags to these nodes. The value Check indicates that the edge is unproven for the edge type, which is described by the value Untyped. The value D@84 and D@40 are child nodes associated with the edges from the ValueAdd node. The constructor of an Edge object is shown below:

explicit Edge(Node* node = nullptr, UseKind useKind = UntypedUse, ProofStatus proofStatus = NeedsCheck, KillStatus killStatus = DoesNotKill)
        : m_encodedWord(makeWord(node, useKind, proofStatus, killStatus))
    {
    }

The constructor takes four parameters and generates an encodedWord to represent an edge in the graph. The node represents the child node that the parent links to, the UseKind parameter determines the representation of values used by the DFG IR. Essentially, the UseKind defines the type of Edge and determines the value type that is being propagated from one node to the other. The DFG has three value types that it uses which are all defined in dfg/DFGUseKind.h:

    // The DFG has 3 representations of values used:

    // 1. The JSValue representation for a JSValue that must be stored in a GP
    //    register (or a GP register pair), and follows rules for boxing and unboxing
    //    that allow the JSValue to be stored as either fully boxed JSValues, or
    //    unboxed Int32, Booleans, Cells, etc. in 32-bit as appropriate.
    UntypedUse, // UntypedUse must come first (value 0).
    Int32Use,
    KnownInt32Use,
    AnyIntUse,
    
    //... code truncated for brevity

    // 2. The Double representation for an unboxed double value that must be stored
    //    in an FP register.
    DoubleRepUse,
    DoubleRepRealUse,
    DoubleRepAnyIntUse,

    // 3. The Int52 representation for an unboxed integer value that must be stored
    //    in a GP register.
    Int52RepUse,

    LastUseKind // Must always be the last entry in the enum, as it is used to denote the number of enum elements.

One can inspect the Edge properties in more detail by setting a breakpoint at Edge::dump and stepping through the function as it dumps edge data. The last two parameters that define an edge are ProofStatus and KillStatus parameters indicate if a edge needs to be proved and if a node will be killed. These two properties of an edge will be revisited in Part IV on graph optimisation. Edges are bidirectional with DFG values flowing from parent to child nodes and execution control flowing from child nodes to parent nodes.

Block Tail

The block dump also includes details about State, Vars After and Var Links.

     0   :   States: InvalidBranchDirection, StructuresAreWatched
     0   :   Vars After: <empty>
     0   :   Var Links: arg2:D@35 arg1:D@36 arg0:D@37 loc0:D@6 loc1:D@8 loc2:D@10 loc3:D@12 loc4:D@21 loc5:D@24

The Vars After list represents the values at tail for the block. This is a list of AbstractValues that are collected by the Abstract Interpreter after CFA.

Var Links is a list of variables at the end of the block. The links represent a mapping between DFG node and variable that helps the OSR Exit generator identify the node it would need to look up in order to reconstruct the state of the variable. More on this in the OSR Exit blog post.

At the end of our graph dump lists the GC Values which is a list of references the CodeBlock has to objects on the heap. This instance lists references to four JSC Objects, two of which are defined in our JS script (i.e. arr and obj). The footer also prints information about the various Watchpoints and a list of structures associated with the CodeBlock.

Branching Instructions

Let’s now look at an example of a program that generates branches:

function jitMe(num) {
    if(num % 2 == 0){
        arr[num] = num;
    }else{
        obj.sum += num;
    }
}

let arr = [];
let obj = {sum : 0}

for (let y = 0; y < 1000; y++) {
    jitMe(y)
}

The program above generates the following bytecodes:

jitMe#DFCAbp:[0x7fffae3c4130->0x7fffae3e5100, BaselineFunctionCall, 72]: 16 instructions (0 16-bit instructions, 0 32-bit instructions, 8 instructions with metadata); 192 bytes (120 metadata bytes); 2 parameter(s); 10 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] mod                loc6, arg1, Int32: 2(const0)
[  11] jneq               loc6, Int32: 0(const1), 27(->38)
Successors: [ #3 #2 ]

bb#2
[  15] resolve_scope      loc6, loc4, 0, GlobalProperty, 0
[  22] get_from_scope     loc7, loc6, 0, 2048<ThrowIfNotFound|GlobalProperty|NotInitialization|NotStrictMode>, 0, 0
[  30] put_by_val         loc7, arg1, arg1, NotStrictMode
[  36] jmp                34(->70)
Successors: [ #4 ]

bb#3
[  38] resolve_scope      loc6, loc4, 1, GlobalProperty, 0
[  45] get_from_scope     loc7, loc6, 1, 2048<ThrowIfNotFound|GlobalProperty|NotInitialization|NotStrictMode>, 0, 0
[  53] get_by_id          loc8, loc7, 2
[  58] add                loc8, loc8, arg1, OperandTypes(126, 126)
[  64] put_by_id          loc7, 2, loc8, 
Successors: [ #4 ]

bb#4
[  70] ret                Undefined(const2)
Successors: [ ]


Identifiers:
  id0 = arr
  id1 = obj
  id2 = sum

Constants:
   k0 = Int32: 2: in source as integer
   k1 = Int32: 0: in source as integer
   k2 = Undefined

Jump targets: 38, 70

The dump above lists four basic blocks that form the function jitMe. The block bb#1 has a conditional opcode jneq at bc#11. Should the condition evaluate to true, execution jumps to bytecode bc#50 which is in basic block bb#3. If the condition evaluates to false, execution continues on to bc#15 in basic block bb#2. The dump also lists the two jump targets which are at bc#38 and bc#70.

Let’s now examine what the graph generated for each of these blocks would look like. The snippet below shows a truncated graph representation for the bytecodes generated for bb#0:

0   : Block #0 (bc#0): (OSR target)
     0   :   Execution count: 1.000000
     0   :   Predecessors:
     0   :   Successors: #1 #2
//... truncated for brevity
 28  0   :   D@28:< 1:->        JSConstant(JS|PureInt, Int32: 2, bc#7, ExitValid)
 29  0   :   D@29:0:->        ValueMod(Check:Untyped:D@27, Check:Untyped:D@28, JS|MustGen|PureInt, R:World, W:Heap, Exits, ClobbersExit, bc#7, ExitValid)
 30  0   :   D@30:0:->        MovHint(Check:Untyped:D@29, MustGen, loc6, W:SideState, ClobbersExit, bc#7, ExitInvalid)
 31  0   :   D@31:< 1:->        SetLocal(Check:Untyped:D@29, loc6(K~/FlushedJSValue), W:Stack(loc6), bc#7, exit: bc#11, ExitValid)  predicting None
 32  0   :   D@32:0:->        CountExecution(MustGen, 0x7fffeeda3458, R:InternalState, W:InternalState, bc#11, ExitValid)
 33  0   :   D@33:< 1:->        JSConstant(JS|PureInt, Int32: 0, bc#11, ExitValid)
 34  0   :   D@34:0:->        CompareEq(Check:Untyped:D@29, Check:Untyped:D@33, Boolean|MustGen|PureInt, R:World, W:Heap, Exits, ClobbersExit, bc#11, ExitValid)
 35  0   :   D@35:0:->        Branch(Check:Untyped:D@34, MustGen, T:#1, F:#2, W:SideState, bc#11, ExitInvalid)
//... truncated for brevity

There are two items of note in the dump above. Successors have now been populated with values #1 and #2. These are references to DFG blocks #1 and #2 which represent bb#2 and bb#3 respectively. This indicates that the Block #0 has edges to blocks #1 or #2 and as such allows control and data to transfer to these blocks. Note that DFG basic blocks don’t necessarily have a 1:1 mapping with bytecode basic blocks.

The nodes D@34 and D@35 are responsible for evaluating the branching condition and determining how control and data should be directed.

34  0   :   D@34:0:->        CompareEq(Check:Untyped:D@29, Check:Untyped:D@33, Boolean|MustGen|PureInt, R:World, W:Heap, Exits, ClobbersExit, bc#11, ExitValid)
35  0   :   D@35:0:->        Branch(Check:Untyped:D@34, MustGen, T:#1, F:#2, W:SideState, bc#11, ExitInvalid)

The CompareEq operation is self explanatory, it has two edges to nodes D@29 and D@33 and defines flags to indicate the type of the operation result (i.e. either a boolean value or an Integer). The Branch operation evaluates the node D@34 and uses the result to determine which DFG block to jump to. If the operation returns true, the jump to block #1 is taken and if the operation returns false, the jump to block #2 is taken.

For the sake of completion, DFG blocks #1 and #2 are listed below:

     1   : Block #1 (bc#15):
     1   :   Execution count: 1.000000
     1   :   Predecessors: #0
     1   :   Successors: #3
     1   :   States: StructuresAreWatched, CurrentlyCFAUnreachable
     1   :   Vars Before: <empty>
//... truncated for brevity
 12  1   :   D@48:0:->        GetLocal(JS|MustGen|PureInt, arg1(O~/FlushedJSValue), R:Stack(arg1), bc#30, ExitValid)  predicting None
 13  1   :   D@49:0:->        PutByVal(Check:Untyped:D@44, Check:Untyped:D@48, Check:Untyped:D@48, MustGen|VarArgs, Int32+OriginalArray+OutOfBounds+AsIs+Write, R:World, W:Heap, Exits, ClobbersExit, bc#30, ExitValid)
 14  1   :   D@50:0:->        CountExecution(MustGen, 0x7fffeeda3498, R:InternalState, W:InternalState, bc#36, ExitValid)
 15  1   :   D@51:0:->        Jump(MustGen, T:#3, W:SideState, bc#36, ExitValid)
     1   :   States: InvalidBranchDirection, StructuresAreWatched
     1   :   Vars After: <empty>
     1   :   Var Links: arg1:D@48 loc4:D@39 loc6:D@41 loc7:D@46

//... truncated for brevity

     2   : Block #2 (bc#38):
     2   :   Execution count: 1.000000
     2   :   Predecessors: #0
     2   :   Successors: #3
     2   :   States: StructuresAreWatched, CurrentlyCFAUnreachable
//... truncated for brevity
 20  2   :   D@72:0:->        ValueAdd(Check:Untyped:D@67, Check:Untyped:D@71, JS|MustGen|PureInt, R:World, W:Heap, Exits, ClobbersExit, bc#58, ExitValid)
 21  2   :   D@73:0:->        MovHint(Check:Untyped:D@72, MustGen, loc8, W:SideState, ClobbersExit, bc#58, ExitInvalid)
 22  2   :   D@74:< 1:->        SetLocal(Check:Untyped:D@72, loc8(U~/FlushedJSValue), W:Stack(loc8), bc#58, exit: bc#64, ExitValid)  predicting None
 23  2   :   D@75:0:->        CountExecution(MustGen, 0x7fffeeda34f8, R:InternalState, W:InternalState, bc#64, ExitValid)
 24  2   :   D@76:0:->        FilterPutByIdStatus(Check:Untyped:D@60, MustGen, (<Replace: [0x7fffae3c8230:[0x88e8, Object, {sum:0}, NonArray, Proto:0x7fffeedf2ee8, Leaf]], offset = 0, >), W:SideState, bc#64, ExitValid)
 25  2   :   D@77:0:->        PutByOffset(Check:Untyped:D@60, Check:Untyped:D@60, Check:Untyped:D@72, MustGen, id2{sum}, 0, W:NamedProperties(2), ClobbersExit, bc#64, ExitValid)
 26  2   :   D@78:0:->        Jump(MustGen, T:#3, W:SideState, bc#70, ExitValid)
     2   :   States: InvalidBranchDirection, StructuresAreWatched
     2   :   Vars After: <empty>
     2   :   Var Links: arg1:D@71 loc4:D@55 loc6:D@57 loc7:D@62 loc8:D@74

Note how both these blocks, listed above, list #0 as a Predecessor and #3 as the Successor.

Function Inlining

Another interesting construct utilised by the bytecode parser is function inlining. Consider the following program:

function jitMe(num) {
    obj.sum += num
    inlineFunc(obj.sum)
}

function inlineFunc(num){
    arr[num] = num;
}

let arr = []
let obj = {sum: 0}

for (let y = 0; y < 1000; y++) {
    jitMe(y)
}

In the program above, the function jitMe calls the function inlineFunc and when the DFG decides to optimise jitMe it evaluates the call to the function inlineFunc and determines that this function can be inlined into jitMe. The snippet below is the bytecode dump for the jitMe function and the bytecode of interest to this discussion is bc#74 which is the call to the function ìnlineFunc.

jitMe#Bslwax:[0x7fffaf2c4130->0x7fffaf2e5100, BaselineFunctionCall, 82]: 16 instructions (0 16-bit instructions, 0 32-bit instructions, 11 instructions with metadata); 202 bytes (120 metadata bytes); 2 parameter(s); 16 callee register(s); 6 variable(s); scope at loc4

bb#1
//... truncated for brevity
[  69] get_by_id          loc9, loc12, 1
[  74] call               loc6, loc6, 2, 16
[  80] ret                Undefined(const0)
Successors: [ ]


Identifiers:
  id0 = obj
  id1 = sum
  id2 = inlineFunc

When the DFGBytecodeParser encounters the bytecode call, it performs a number of checks to determine if the callee can be inlined. With the verboseDFGBytecodeParsing command line flag enabled one would be able to observe how the call bytecode is parsed and inlined:

parsing bc#74: op_call
    Handling call at bc#74: Statically Proved, (Function: Object: 0x7fffaf2f5a00 with butterfly (nil) (Structure 0x7fffaf2f9420:[0xa836, Function, {}, NonArray, Proto:0x7fffefcfc248, Leaf (Watched)]), StructureID: 43062; Executable: inlineFunc#EfyD9C:[0x7fffaf2c4390->0x7fffaf2c4260->0x7fffaf2e5180, DFGFunctionCall, 30 (DidTryToEnterInLoop)])
        appended D@64 FilterCallLinkStatus
Handling inlining...
Stack: bc#74
    Considering callee (Function: Object: 0x7fffaf2f5a00 with butterfly (nil) (Structure 0x7fffaf2f9420:[0xa836, Function, {}, NonArray, Proto:0x7fffefcfc248, Leaf (Watched)]), StructureID: 43062; Executable: inlineFunc#EfyD9C:[0x7fffaf2c4390->0x7fffaf2c4260->0x7fffaf2e5180, DFGFunctionCall, 30 (DidTryToEnterInLoop)])
Considering inlining (Function: Object: 0x7fffaf2f5a00 with butterfly (nil) (Structure 0x7fffaf2f9420:[0xa836, Function, {}, NonArray, Proto:0x7fffefcfc248, Leaf (Watched)]), StructureID: 43062; Executable: inlineFunc#EfyD9C:[0x7fffaf2c4390->0x7fffaf2c4260->0x7fffaf2e5180, DFGFunctionCall, 30 (DidTryToEnterInLoop)]) into bc#74
    Call mode: Call
    Is closure call: false
    Capability level: CanCompileAndInline
    Might inline function: true
    Might compile function: true
    Is supported for inlining: true
    Is inlining candidate: true
    Inlining should be possible.
        appended D@65 CheckIsConstant
        appended D@66 Phantom
   ensureLocals: trying to raise m_numLocals from 16 to 24
   ensureTmps: trying to raise m_numTmps from 0 to 0
        appended D@67 ExitOK

If the DFGBytecodeParser determines that the function can be inlined, it parses the function bytecode and appends appropriate nodes to the DFG graph. The snippet below shows the output generated by verboseDFGBytecodeParsing when a function is inlined.

Parsing inlineFunc#EfyD9C:[0x7fffaf2c4260->0x7fffaf2e5180, BaselineFunctionCall, 30 (DidTryToEnterInLoop) (FTLFail)] for inlining at jitMe#Bslwax:[0x7fffaf2c44c0->0x7fffaf2c4130->0x7fffaf2e5100, DFGFunctionCall, 82] bc#74
inlineFunc#EfyD9C:[0x7fffaf2c4260->0x7fffaf2e5180, BaselineFunctionCall, 30 (DidTryToEnterInLoop) (FTLFail)]: 8 instructions (0 16-bit instructions, 0 32-bit instructions, 3 instructions with metadata); 150 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] resolve_scope      loc6, loc4, 0, GlobalProperty, 0
[  14] get_from_scope     loc7, loc6, 0, 2048<ThrowIfNotFound|GlobalProperty|NotInitialization|NotStrictMode>, 0, 0
[  22] put_by_val         loc7, arg1, arg1, NotStrictMode
[  28] ret                Undefined(const0)
Successors: [ ]


Identifiers:
  id0 = arr

Constants:
   k0 = Undefined

Jump targets: 
    parsing bc#74 --> inlineFunc#EfyD9C:<0x7fffaf2c4260> bc#0: op_enter
        appended D@68 JSConstant
        appended D@69 MovHint

        //... truncated for brevity

        parsing bc#74 --> inlineFunc#EfyD9C:<0x7fffaf2c4260> bc#1: op_get_scope
        appended D@81 JSConstant
        appended D@82 JSConstant
        appended D@83 MovHint
        appended D@84 SetLocal
    parsing bc#74 --> inlineFunc#EfyD9C:<0x7fffaf2c4260> bc#3: op_mov
        appended D@85 MovHint
        appended D@86 SetLocal
    parsing bc#74 --> inlineFunc#EfyD9C:<0x7fffaf2c4260> bc#6: op_check_traps
        appended D@87 InvalidationPoint

        //... truncated for brevity

Once the bytecodes for the function jitMe and the inlined function inlineFunc have been parsed the following unoptimised graph is generated. Note the representation of the inlined function between nodes D@67 to D@101:

Graph after parsing:

         : DFG for jitMe#Bslwax:[0x7fffaf2c44c0->0x7fffaf2c4130->0x7fffaf2e5100, DFGFunctionCall, 82]:
         :   Fixpoint state: BeforeFixpoint; Form: LoadStore; Unification state: LocallyUnified; Ref count state: EverythingIsLive
         :   Arguments for block#0: D@0, D@1

     0   : Block #0 (bc#0): (OSR target)
     0   :   Execution count: 1.000000
    
    //... truncated for brevity 
  
  0  0   :    D@0:< 1:->        SetArgumentDefinitely(this(a), W:SideState, bc#0, ExitValid)  predicting None
  1  0   :    D@1:< 1:->        SetArgumentDefinitely(arg1(B~/FlushedJSValue), W:SideState, bc#0, ExitValid)  predicting None
  2  0   :    D@2:< 1:->        JSConstant(JS|PureInt, Undefined, bc#0, ExitValid)
  3  0   :    D@3:0:->        MovHint(Check:Untyped:D@2, MustGen, loc0, W:SideState, ClobbersExit, bc#0, ExitValid)

    //... truncated for brevity
 
 66  0   :   D@66:0:->        Phantom(Check:Untyped:D@42, MustGen, bc#74, ExitValid)
     0   :   --> inlineFunc#EfyD9C:<0x7fffaf2c4260, bc#74, Call, known callee: Object: 0x7fffaf2f5a00 with butterfly (nil) (Structure %A1:Function), StructureID: 43062, numArgs+this = 2, numFixup = 0, stackOffset = -16 (loc0 maps to loc16)>
 67  0   :     D@67:0:->      ExitOK(MustGen, W:SideState, bc#0, ExitValid)
 68  0   :     D@68:< 1:->      JSConstant(JS|PureInt, Undefined, bc#0, ExitValid)
 69  0   :     D@69:0:->      MovHint(Check:Untyped:D@68, MustGen, loc16, W:SideState, ClobbersExit, bc#0, ExitValid)
 70  0   :     D@70:< 1:->      SetLocal(Check:Untyped:D@68, loc16(T~/FlushedJSValue), W:Stack(loc16), bc#0, ExitInvalid)  predicting None
 71  0   :     D@71:0:->      MovHint(Check:Untyped:D@68, MustGen, loc17, W:SideState, ClobbersExit, bc#0, ExitInvalid)
 
     //... truncated for brevity

 93  0   :     D@93:< 1:->      JSConstant(JS|PureInt, Weak:Object: 0x7fffefca46e8 with butterfly 0x7fe0833e0008 (Structure %CA:Array,ArrayWithInt32), StructureID: 46376, bc#14, ExitValid)
 94  0   :     D@94:0:->      MovHint(Check:Untyped:D@93, MustGen, loc23, W:SideState, ClobbersExit, bc#14, ExitValid)
 95  0   :     D@95:< 1:->      SetLocal(Check:Untyped:D@93, loc23(CB~/FlushedJSValue), W:Stack(loc23), bc#14, exit: bc#74 --> inlineFunc#EfyD9C:<0x7fffaf2c4260> bc#22, ExitValid)  predicting None
 96  0   :     D@96:0:->      PutByVal(Check:Untyped:D@93, Check:Untyped:D@61, Check:Untyped:D@61, MustGen|VarArgs, Int32+OriginalArray+OutOfBounds+AsIs+Write, R:World, W:Heap, Exits, ClobbersExit, bc#22, ExitValid)
 97  0   :     D@97:0:->      Flush(MustGen, loc9(S~/FlushedJSValue), R:Stack(loc9), W:SideState, bc#28, ExitValid)  predicting None
 98  0   :     D@98:0:->      Flush(MustGen, loc10(O~/FlushedJSValue), R:Stack(loc10), W:SideState, bc#28, ExitValid)  predicting None
 99  0   :     D@99:< 1:->      JSConstant(JS|PureInt, Undefined, bc#28, ExitValid)
100  0   :    D@100:0:->      MovHint(Check:Untyped:D@99, MustGen, loc6, W:SideState, ClobbersExit, bc#28, ExitValid)
101  0   :    D@101:< 1:->      SetLocal(Check:Untyped:D@99, loc6(DB~/FlushedJSValue), W:Stack(loc6), bc#28, ExitInvalid)  predicting None
     0   :   <-- inlineFunc#EfyD9C:<0x7fffaf2c4260, bc#74, Call, known callee: Object: 0x7fffaf2f5a00 with butterfly (nil) (Structure %A1:Function), StructureID: 43062, numArgs+this = 2, numFixup = 0, stackOffset = -16 (loc0 maps to loc16)>
102  0   :  D@102:< 1:->        JSConstant(JS|PureInt, Undefined, bc#80, ExitValid)
103  0   :  D@103:0:->        Return(Check:Untyped:D@102, MustGen, W:SideState, Exits, bc#80, ExitValid)
104  0   :  D@104:0:->        Flush(MustGen, arg1(B~/FlushedJSValue), R:Stack(arg1), W:SideState, bc#80, ExitValid)  predicting None

//... truncated for brevity

Conclusion

This post explored the various components that make up the DFG JIT tier in JavaScriptCore by understanding how bytecode is parsed to generate a graph in the DFG and reading DFG IR. Part IV of this blog series will dive into the details of graph optimisation that’s performed by the DFG.

Appendix

JavaScriptCore Internals Part IV: The DFG (Data Flow Graph) JIT -- Graph Optimisation

Wed, 26 May 2021 00:00:00 +0000

Introduction

This blog post continues from where we left off in Part III and will cover each DFG graph optimisation. The graph generated at the end of the bytecode parsing phase is passed through the DFG pipeline which optimises the graph before lowering it to machine code. DFG Optimisation phases add, remove and update nodes in the various blocks that make up the graph. The optimisation phases will also re-order nodes (via Hoisting or Sinking) within the same basic block. However, the DFG optimisations do not move nodes between basic blocks. The the screenshot¹ below shows the various optimisation phases that form part of the DFG pipeline:

The goal of DFG optimisation is to enable Fast Compilation by removing as many type checks as possible, quickly. The DFG performs majority of its optimisations via static analysis of the generated graph. The WebKit blog¹ describes three key static analyses in the DFG that have a significant impact on optimisation choices:

We use prediction propagation to fill in predicted types for all values based on value profiling of some values. This helps us figure out where to speculate on type.

We use the abstract interpreter (or just AI for short in JavaScriptCore jargon) to find redundant OSR speculations. This helps us emit fewer OSR checks. Both the DFG and FTL include multiple optimization passes in their pipelines that can find and remove redundant checks but the abstract interpreter is the most powerful one. The abstract interpreter is the DFG tier’s primary optimization and it is reused with small enhancements in the FTL.

We use clobberize to get aliasing information about DFG operations. Given a DFG instruction, clobberize can describe the aliasing properties. In almost all cases that description is O(1) in time and space. That description implicitly describes a rich dependency graph.

Graph Optimisations

The DFG pipeline itself has 30 optimisation passes of which 25 are unique optimisation phases. The optimisation phases indicated previously are located in DFGPlan.cpp.

    RUN_PHASE(performLiveCatchVariablePreservationPhase);

    RUN_PHASE(performCPSRethreading);
    RUN_PHASE(performUnification);
    RUN_PHASE(performPredictionInjection);
    
    RUN_PHASE(performStaticExecutionCountEstimation);

    //... truncated for brevity

With a high level understanding of the three static analysis performed, let’s now dive into the details of each optimisation phase. To being, there are a couple of command line line flags that one can add to our debugging environment that will aid our evaluation:

verboseCompilation: This flag will enable printing of logging information at before and after each optimisation phase of the DFG. This will also help identify which optimisation phase the DFG is currently in and if the phase modified the DFG IR. This will also print the final optimised graph at the end of the optimisation phases.
dumpGraphAtEachPhase: As the name suggests, setting this flag will enable printing of the graph at the start of each optimisation phase.

Our launch.json should resemble something similar to the one below:

{
    //... trunvated for brevity
           "program": "/home/amar/workspace/WebKit/WebKitBuild/Debug/bin/jsc",
            "args": [
                "--useConcurrentJIT=false",
                "--useFTLJIT=false",
                "--verboseOSR=true",

                "--thresholdForJITSoon=10", 
                "--thresholdForJITAfterWarmUp=10", 
                "--thresholdForOptimizeAfterWarmUp=100", 
                "--thresholdForOptimizeAfterLongWarmUp=100", 
                "--thresholdForOptimizeSoon=100", 

                "--reportDFGCompileTimes=true",     
                "--dumpBytecodeAtDFGTime=true",
                "--dumpSourceAtDFGTime=true",
                "--verboseDFGBytecodeParsing=false", 
                "--dumpGraphAfterParsing=false",
                
                "--dumpGraphAtEachPhase=true",
                "--verboseCompilation=true",
                
                "/home/amar/workspace/WebKit/WebKitBuild/Debug/bin/test.js"
            ],
    //... truncated for brevity
}

Live Catch Variable Preservation

The first optimisation phase in the pipeline is LiveCatchVariablePreservationPhase. The header files for each phase include developer comments on the function of the optimistaion phase. The LiveCatchVariablePreservationPhase is described by the developer comments as follows:

This phase ensures that we maintain liveness for locals that are live in the “catch” block. Because a “catch” block will not be in the control flow graph, we need to ensure anything live inside the “catch” block in bytecode will maintain liveness inside the “try” block for an OSR exit from the “try” block into the “catch” block in the case of an exception being thrown.

The mechanism currently used to demonstrate liveness to OSR exit is ensuring all variables live in a “catch” are flushed to the stack inside the “try” block.

This phase iterates over each basic block in the graph and attempts to determine which operands from the catch block would need to be preserved in the graph so that at the time of OSR Exit, the catch block can be correctly reconstructed in the Baseline JIT. Live values in the DFG relevant to the catch block are preserved by inserting Flush nodes at the end of the basic block which will push these values to the stack. Flush nodes ensure that the DFG optimisation will preserve the value of an operand at OSR Exit.

The function performLiveCatchVariablePreservationPhase is implemented as the run function. A snippet of which is shown below:

bool run()
{
    DFG_ASSERT(m_graph, nullptr, m_graph.m_form == LoadStore);

    if (!m_graph.m_hasExceptionHandlers)
        return false;

    InsertionSet insertionSet(m_graph);
    if (m_graph.m_hasExceptionHandlers) {
        for (BasicBlock* block : m_graph.blocksInNaturalOrder()) {
            handleBlockForTryCatch(block, insertionSet);
            insertionSet.execute(block);
        }
    }

    return true;
}

The object insertionSet is an ordered collection of new nodes that are generated when the graph is put through an optimisation phase. At the end of the phase, the insertionSet is executed which adds these new nodes to the various basic blocks in the graph.

CPS Rethreading

The next stage in the optimistaion pipeline is CPSRethreading. Before this stage the graph generated is in the LoadStore form and this phase converts the graph to a ThreadedCPS form. The properties of a ThreadedCPS graph are described as follows:

ThreadedCPS form means that basic blocks list up-front which locals they expect to be live at the head, and which locals they make available at the tail. ThreadedCPS form also implies that:

GetLocals and SetLocals are not redundant within a basic block.

All GetLocals and Flushes are linked directly to the last access point of the variable, which must not be another GetLocal.

Phantom(Phi) is not legal, but PhantomLocal is.

ThreadedCPS form is suitable for data flow analysis (CFA, prediction propagation), register allocation, and code generation.

Before we dive into the phase implementation, it’s worth reviewing the functionality of some of the most common nodes in a graph:

MovHint(@a, rK): This operation indicates that node @a contains the value that would have now been placed into virtual register rK. Does not actually cause @a to be stored into rK. MovHints are always dead.
SetLocal(@a, rK): This is a store operation that causes the result of @a is stored to the virtual register rK, if the SetLocal is live.
GetLocal(@a, rK): This is a load operation that causes the result of @a to be loaded from the virtual register rK.

The developer comments describe the phase as follows:

CPS Rethreading:

Takes a graph in which there are arbitrary GetLocals/SetLocals with no connections between them. Removes redundant ones in the case of uncaptured variables. Connects all of them with Phi functions to represent live ranges.

The phase implementation consists of a series of function calls which transform the graph. The functions that perform key transformations are briefly described below:

bool run()
{
    RELEASE_ASSERT(m_graph.m_refCountState == EverythingIsLive);
        
    if (m_graph.m_form == ThreadedCPS)
        return false;
        
    clearIsLoadedFrom();
    freeUnnecessaryNodes();
    m_graph.clearReplacements();
    canonicalizeLocalsInBlocks();
    specialCaseArguments();
    propagatePhis<OperandKind::Local>();
    propagatePhis<OperandKind::Argument>();
    propagatePhis<OperandKind::Tmp>();
    computeIsFlushed();
        
    m_graph.m_form = ThreadedCPS;
    return true;
}

freeUnnecessaryNodes: Adds an empty child node to GetLocal, Flush and PhantomLocal nodes in the graph. When iterating through the nodes in the graph, if it encounters a Phantom node it removes the node if the node has no children. If the node has a child which is either a Phi, SetArgumentDefinitely or a SetLocal, it converts the node to a PhantomLocal. At the end of parsing each block it purges any Phi nodes that exist from previous optimisation passes.

canonicalizeLocalsInBlocks: This function defines the rules for threaded CPS. Basic Block evaluation begins from the last basic block in the graph to and terminates at the root block. Nodes within each block however are parsed in natural order. This phase is also responsible for updating the varaiblesAtHead list as well as generating (also regenerating since this phase is called several times in the DFG pipeline) Phi nodes and adding them to the graph. The Phi nodes generated can be viewed from the graph dump printed to stdout, an example of this is shown below:

: Block #5 (bc#463 --> isFinite#DJEgRe:<0x7fffaefc7b60> bc#21):
:   Execution count: 1.000000
:   Predecessors: #4
:   Successors: #6
:   Phi Nodes: D@559<loc39,1>->(), D@558<loc40,1>->(), D@557<loc5,1>->(), D@556<this,1>->()
:   States: StructuresAreWatched, CurrentlyCFAUnreachable
:   Vars Before: <empty>
//... truncated for brevity
:   Var Links: arg0:D@592 loc5:D@593 loc39:D@464 loc40:D@465

In the snippet above D@559 is a Phi node that’s been added to the graph. The value loc39 represents the operand to Phi node. The value 1 that follows loc39 is the reference count for the Phi.

propogatePhis: This group of functions propagates Phi nodes through the basic blocks. This propagation process updates the Phi nodes with child nodes from a predecessor block who’s value would flow into the Phi node.

//... truncated for brevity
4   :    D@427:< 1:->      SetLocal(Check:Untyped:D@410, loc40(FF~/FlushedJSValue), W:Stack(loc40), bc#0, ExitValid)  predicting None
4   :    D@428:< 1:->      SetLocal(Check:Untyped:D@423, loc39(GF~/FlushedJSValue), W:Stack(loc39), bc#0, ExitValid)  predicting None
//... truncated for brevity

5   : Block #5 (bc#463 --> isFinite#DJEgRe:<0x7fffaefc7b60> bc#21):
5   :   Execution count: 1.000000
5   :   Predecessors: #4
5   :   Successors: #6
5   :   Phi Nodes: D@559<loc39,1>->(D@428), D@558<loc40,1>->(D@427), D@557<loc5,1>->(D@554), D@556<this,1>->(D@553), D@655<loc23,1>->(D@651), D@650<loc24,1>->(D@646), D@165<loc26,1>->(D@409), D@680<loc34,1>->(D@403), D@684<loc30,1>->(D@397), D@688<loc4,1>->(D@555), D@696<arg1,1>->(D@700), D@703<arg2,1>->(D@707)
5   :   States: StructuresAreWatched, CurrentlyCFAUnreachable
5   :   Vars Before: <empty>
     //... truncated for brevity
5   :   Var Links: arg2:D@703 arg1:D@696 arg0:D@592 loc4:D@688 loc5:D@593 loc23:D@655 loc24:D@650 loc26:D@165 loc30:D@684 loc34:D@680 loc39:D@464 loc40:D@465

In the snippet above the Phi node D@559 has an edge to the child node pointing to the SetLocal node D@428 which is in the predecessor block #4. The children of a Phi node can only be SetLocal, SetArgumentDefinitely, SetArgumentMaybe or another Phi node.

Unification

Examines all Phi functions and ensures that the variable access datas are unified. This creates our “live-range split” view of variables.

This phase iterates over all Phi nodes and attempts to unify the VariableAccessData for the Phi nodes and the children of the node.

for (unsigned phiIndex = block->phis.size(); phiIndex--;) {
    Node* phi = block->phis[phiIndex];
    for (unsigned childIdx = 0; childIdx < AdjacencyList::Size; ++childIdx) {
        if (!phi->children.child(childIdx))
            break;
        phi->variableAccessData()->unify(phi->children.child(childIdx)->variableAccessData());
    }
}

If the child node has a different VariableAccessData to the parent then then the child is made the parent of the Phi node. The snippet from WebKit/WebKitBuild/Debug/DerivedSources/ForwardingHeaders/wtf/UnionFind.h:

void unify(T* other)
{
    T* a = static_cast<T*>(this)->find();
    T* b = other->find();
        
    ASSERT(!a->m_parent);
    ASSERT(!b->m_parent);
        
    if (a == b)
        return;
        
    a->m_parent = b;
}

VariableAccessData contains operand information and are stored in a vector defined in dfg/DFGGraph.h.

SegmentedVector<VariableAccessData, 16> m_variableAccessData;

The DFG nodes, SetArgumentDefinitely, SetArgumentMaybe, GetLocal and SetLocal store VariableAccessData as an opInfo parameter. This can be retrieved with a call to node->tryGetVariableAccessData(). See Graph::dump for the VariableAccessData dumping section.

Prediction Injection

Takes miscellaneous data about variable type predictions and injects them. This includes argument predictions and OSR entry predictions.

As the developer comments suggest, this phase takes the the profiling data collected from the profiling tier and then injects them into the IR. This affects GetLocal, SetLocal and Flush nodes. As an example, let’s consider nodes generated for an arithmetic add instruction whose operands have been profiled as integer values:

D@28:0:-> GetLocal(JS|MustGen|PureInt, arg1(B~/FlushedJSValue), R:Stack(arg1), bc#7, ExitValid)  predicting None
D@29:0:-> GetLocal(JS|MustGen|PureInt, arg2(C~/FlushedJSValue), R:Stack(arg2), bc#7, ExitValid)  predicting None
D@30:0:-> ValueAdd(Check:Untyped:D@28, Check:Untyped:D@29, JS|MustGen|PureInt, R:World, W:Heap, Exits, ClobbersExit, bc#7, ExitValid)

Prediction Injection phase takes the profile information gathered for each block (e.g. arguments to the block) and injects this to the node. From the snippet above, the nodes D@28 and D@29 above, after prediction injection, would be updated as follows:

D@28:0:-> GetLocal(Check:Untyped:D@1, JS|MustGen|PureInt, arg1(B~<BoolInt32>/FlushedJSValue), R:Stack(arg1), bc#7, ExitValid)  predicting BoolInt32
D@29:0:-> GetLocal(Check:Untyped:D@2, JS|MustGen|PureInt, arg2(C~<Int32>/FlushedJSValue), R:Stack(arg2), bc#7, ExitValid)  predicting NonBoolInt32
D@30:0:-> ValueAdd(Check:Untyped:D@28, Check:Untyped:D@29, JS|MustGen|PureInt, R:World, W:Heap, Exits, ClobbersExit, bc#7, ExitValid)

Notice how the graph now contains predicted types for arg1 and arg2 which is BoolInt32 and Int32 respectively. Additionally, it has added prediction information that the nodes D@28 and D@29 will result in generating BoolInt32 and NonBoolInt32 types.

D@28: ... arg1(B~<BoolInt32>/FlushedJSValue) ... predicting BoolInt32

D@29: ... arg2(C~<Int32>/FlushedJSValue) ... predicting NonBoolInt32

Static Execution Count Estimation

Estimate execution counts (branch execution counts, in particular) based on presently available static information. This phase is important because subsequent CFG transformations, such as OSR entrypoint creation, perturb our ability to do accurate static estimations. Hence we lock in the estimates early. Ideally, we would have dynamic information, but we don’t right now, so this is as good as it gets.

This phase adds the static execution counts to each block as well as adds execution weights to each branch and switch node.This phase also calculates dominators for the various blocks in the graph, this is useful for the CFG Simplification phase. See details about this in WebKit/WebKitBuild/Debug/DerivedSources/ForwardingHeaders/wtf/Dominators.h. An example of this is is shown in the graph dump below:

: Block #7 (bc#463 --> isFinite#DJEgRe:<0x7fffaefc7b60> bc#23):
:   Execution count: 1.000000
:   Predecessors: #4
:   Successors: #8 #9
:   Dominated by: #root #0 #2 #3 #4 #7
:   Dominates: #7 #8 #9
:   Dominance Frontier: #6
:   Iterated Dominance Frontier: #6
//... truncated for brevity
:    D@473:0:-> MovHint(Check:Untyped:D@472, MustGen, loc54, W:SideState, ClobbersExit, bc#23, ExitValid)
:    D@474:< 1:-> SetLocal(Check:Untyped:D@472, loc54(YF~/FlushedJSValue), W:Stack(loc54), bc#23, exit: bc#463 --> isFinite#DJEgRe:<0x7fffaefc7b60> bc#27, ExitValid)  predicting None
:    D@475:0:-> Branch(Check:Untyped:D@472, MustGen, T:#8/w:1.000000, F:#9/w:1.000000, W:SideState, bc#27, ExitValid)

Backwards Propagation

Infer basic information about how nodes are used by doing a block-local backwards flow analysis.

This phase starts by looping over the blocks in the graph from the last to the first and evaluates the NodeFlags on each node. For each node evaluated, it attempts to merge the flags of the node with the NodeBytecodeBackPropMask flags:

void propagate(Node* node)
{
    NodeFlags flags = node->flags() & NodeBytecodeBackPropMask;
        
    switch (node->op()) {
    case GetLocal: {
        VariableAccessData* variableAccessData = node->variableAccessData();
        flags &= ~NodeBytecodeUsesAsInt; // We don't care about cross-block uses-as-int.
        m_changed |= variableAccessData->mergeFlags(flags);
        break;
    }
            
    case SetLocal: {
        VariableAccessData* variableAccessData = node->variableAccessData();
        if (!variableAccessData->isLoadedFrom())
            break;
        flags = variableAccessData->flags();
        RELEASE_ASSERT(!(flags & ~NodeBytecodeBackPropMask));
        flags |= NodeBytecodeUsesAsNumber; // Account for the fact that control flow may cause overflows that our modeling can't handle.
        node->child1()->mergeFlags(flags);
        break;
    }
    //... truncated for brevity
    }
}

Backwards Propagation updates the node flags to provide additional information on how the resultant computation of a node is used.

Prediction Propagation

Propagate predictions gathered at heap load sites by the value profiler, and from slow path executions, to generate a prediction for each node in the graph. This is a crucial phase of compilation, since before running this phase, we have no idea what types any node (or most variables) could possibly have, unless that node is either a heap load, a call, a GetLocal for an argument, or an arithmetic op that had definitely taken slow path. Most nodes (even most arithmetic nodes) do not qualify for any of these categories. But after running this phase, we’ll have full information for the expected type of each node.

Consider the following graph snippet for an arithmetic add operation before the Prediction Propagation phase:

D@28:0:-> GetLocal(Check:Untyped:D@1, JS|MustGen|PureInt, arg1(B~<BoolInt32>/FlushedJSValue), R:Stack(arg1), bc#7, ExitValid)  predicting BoolInt32
D@29:0:-> GetLocal(Check:Untyped:D@2, JS|MustGen|PureInt, arg2(C~<Int32>/FlushedJSValue), R:Stack(arg2), bc#7, ExitValid)  predicting NonBoolInt32
D@30:0:-> ValueAdd(Check:Untyped:D@28, Check:Untyped:D@29, JS|MustGen|PureInt, R:World, W:Heap, Exits, ClobbersExit, bc#7, ExitValid)

The Prediction Propagation phase then traverses the graph to add additional speculative type information on the node itself. The nodes D@28, D@29 and D@30 after the prediction propagation phase are listed below:

D@28:0:-> GetLocal(Check:Untyped:D@1, JS|MustGen|PureNum, BoolInt32, arg1(B<BoolInt32>/FlushedInt32), R:Stack(arg1), bc#7, ExitValid)  predicting BoolInt32
D@29:0:-> GetLocal(Check:Untyped:D@2, JS|MustGen|PureNum, NonBoolInt32, arg2(C<Int32>/FlushedInt32), R:Stack(arg2), bc#7, ExitValid)  predicting NonBoolInt32
D@30:0:-> ArithAdd(Check:Int32:D@28, Check:Int32:D@29, JS|MustGen|PureInt, Int32, Unchecked, Exits, bc#7, ExitValid)

In the listing above, notice the two changes to the node D@30, it now contains speculative type information on what the opcode is likely to return. Which in this case is Int32. It has also updated (technically this is the Fixup phase that updates the node as a consequence of the Prediction Propagation phase) the node to an ArithAdd node type and added an Int32 type check on the edges D@28 and D@29.

ArithAdd(Check:Int32:D@28, Check:Int32:D@29 ...

The nodes D@28 and D@29 have also been updated to include speculative type information for each of them.

Fixup

Fix portions of the graph that are inefficient given the predictions that we have. This should run after prediction propagation but before CSE.

This phase performs a number of optimisations on the graph such as updating the flush formats, type checks, adding nodes (e.g. adding DoubleRep and ArrayifyToStructure) and removing nodes (e.g. decaying Phantoms to Checks). An example of such a node optimisation is the conversion of the ValueAdd node to to a ArithAdd node and the removal of type checks on the node’s children as see in the previous section on Prediction Propagation.

The Fixup rules are defined in the phase implementation. The key functions within the phase that the reader should examine are fixupNode, fixupGetAndSetLocalsInBlock and fixupChecksInBlock.

Invalidation Point Injection

Inserts an invalidation check at the beginning of any CodeOrigin that follows a CodeOrigin that had a call (clobbered World).

As the name of this phase suggests, it adds InvalidationPoint nodes after a node, which has had a call to clobberWorld. InvalidationPoints check if any watchpoints have fired and as a result would trigger an OSR Exit from the optimised code. Consider the following graph dump:

D@287:< 1:-> SetLocal(Check:Untyped:D@284, loc24(QD~<Object>/FlushedJSValue), W:Stack(loc24), bc#283, exit: bc#291, ExitValid)  predicting OtherObj
D@288:0:-> PutById(Check:Cell:D@284, Check:Untyped:D@275, MustGen, cachable-id {uid:(__proto__)}, R:World, W:Heap, Exits, ClobbersExit, bc#291, ExitValid)
D@730:0:-> InvalidationPoint(MustGen, W:SideState, Exits, bc#297, ExitValid)
D@289:0:-> MovHint(Check:Untyped:D@241, MustGen, loc24, W:SideState, ClobbersExit, bc#297, ExitValid)

An InvalidationPoint was added at the beginning of the bytecode instruction boundary at bc#297 since the DFG node PutById triggers a call to clobberWorld when evaluated by the Abstract Interpreter.

Type Check Hoisting

Hoists CheckStructure on variables to assignments to those variables, if either of the following is true:

A) The structure’s transition watchpoint set is valid.

B) The span of code within which the variable is live has no effects that might clobber the structure.

This phase begins by looping over the nodes in the graph to identify any variables with redundant structure and array checks and earmarks their checks for hoisting. It then loops over the SetArgumentDefinitely and SetLocal nodes in the graph and adds CheckStructure nodes on the variables that were earmarked for hoisting. A truncated snippet of the phase implementation is listed below:

bool run()
{
    clearVariableVotes();
    identifyRedundantStructureChecks();
    disableHoistingForVariablesWithInsufficientVotes<StructureTypeCheck>();

    clearVariableVotes();
    identifyRedundantArrayChecks();
    disableHoistingForVariablesWithInsufficientVotes<ArrayTypeCheck>();

    disableHoistingAcrossOSREntries<StructureTypeCheck>();
    disableHoistingAcrossOSREntries<ArrayTypeCheck>();

    bool changed = false;

    // Place CheckStructure's at SetLocal sites.
    InsertionSet insertionSet(m_graph);
    for (BlockIndex blockIndex = 0; blockIndex < m_graph.numBlocks(); ++blockIndex) {
        BasicBlock* block = m_graph.block(blockIndex);
            
        //... truncated for brevity

        for (unsigned indexInBlock = 0; indexInBlock < block->size(); ++indexInBlock) {
            Node* node = block->at(indexInBlock);
                
            //... truncated for brevity

            switch (node->op()) {
            case SetArgumentDefinitely: {
                //... truncated for brevity (GetLocal and CheckStructure/CheckArray nodes added)
            }    
            case SetLocal: {
                //... truncated for brevity (CheckStructure/CheckArray nodes added)
            }    
            default:
                break;
            }
        }
        insertionSet.execute(block);
    }
        
    return changed;
}

Strength Reduction

Performs simplifications that don’t depend on CFA or CSE but that should be fixpointed with CFA and CSE.

The developer comments in DFGStrengthReductionPhase.h aren’t very descriptive on how this phase optimises the graph. However, on digging into the ChangeLog from 2014, we have the following comments that shed more light on what this phase was designed to accomplish:

This was meant to be easy. The problem is that there was no good place for putting the folding of typedArray.length to a constant. You can’t quite do it in the bytecode parser because at that point you don’t yet know if typedArray is really a typed array. You can’t do it as part of constant folding because the folder assumes that it can opportunistically forward-flow a constant value without changing the IR; this doesn’t work since we need to first change the IR to register a desired watchpoint and only after that can we introduce that constant. We could have done it in Fixup but that would have been awkward since Fixup’s code for turning a GetById of “length” into GetArrayLength is already somewhat complex. We could have done it in CSE but CSE is already fairly gnarly and will probably get rewritten.

So I introduced a new phase, called StrengthReduction. This phase should have any transformations that don’t requite CFA or CSE and that it would be weird to put into those other phases.

Essentially this is a dumping ground for transformations that don’t rely on CFA or CSE phases. This phase iterates over each node in the graph and applies transformations that are defined in the function DFGStrengthRedutionPhase::handleNode()

Control Flow Analysis

Global control flow analysis. This phase transforms the combination of type predictions and type guards into type proofs, and flows them globally within the code block. It’s also responsible for identifying dead code, and in the future should be used as a hook for constant propagation.

These phases perform several check eliminations with the help of the Abstract Interpreter (AI). It can eliminate checks in the same block, in different blocks and eliminate checks by merging information from predecessor blocks¹.

The AI achieves this by executing each node in the every block and updating the proof status of edges as it traverses the graph. An edge is proved if the values gathered by the AI match the edges’ type (i.e. useKind). There are four sub values that the AI captures and the WebKit blog¹ describes them as follows:

The DFG abstract value representation has four sub-values:

Whether the value is known to be a constant, and if so, what that constant is.

The set of possible types (i.e. a SpeculatedType bitmap, shown in Figure 13).

The set of possible indexing types (also known as array modes) that the object pointed to by this value can have.

The set of possible structures that the object pointed to by this value can have. This set has special infinite set powers.

The AI runs to fixpoint, what that means is that it traverses the graph repeatedly until it observes no changes in the abstract values it has recorded. Once it has converged at fixpoint it then proceeds to determine which checks on nodes can be removed by consulting the abstract values it has gathered and clobberize. This will be discussed in the next section.

Let’s attempt to trace this optimisation phase in the DFG. To being let’s enable another very handy JSC flag that will enable verbose logging of the Control Flow Analysis. To do this add the --verboseCFA=true to launch.json. This will print the various abstract values that are gathered as the AI traverses the graph.

The key function in this phase is performBlockCFA. This function iterates over the basic blocks in the graph and calls performBlockCFA on each block. A truncated listing is shown below:

void performBlockCFA(BasicBlock* block)
{
    //... code truncated for brevity

    m_state.beginBasicBlock(block);
        
    for (unsigned i = 0; i < block->size(); ++i) {
        Node* node = block->at(i);
        //... code truncated for brevity 
        if (!m_interpreter.execute(i)) {
            break;
        }
            
        //... code truncated for brevity
    }
        
    m_changed |= m_state.endBasicBlock();
        
}

This function first updates the AI state with the call to m_state.beginBasicBlock(block). It then iterates over each node in the basic block and executes them in the AI with the call to AbstractInterpreter::execute. With the verboseCFA flag enabled, the AI will print the active variables in the block as it iterates over each node. The function AbstractInterpreter::execute is described below:

template<typename AbstractStateType>
bool AbstractInterpreter<AbstractStateType>::execute(unsigned indexInBlock)
{
    Node* node = m_state.block()->at(indexInBlock);

    startExecuting();
    executeEdges(node);
    return executeEffects(indexInBlock, node);
}

The function begins by first clearing the state of the node with the call to startExecuting. Once the node state in the AI has been reset, the next step is to call executeEdges on the node which evaluates the edge type against the speculated type. The function executeEdges through a series of calls ends up calling filterEdgeByUse. This function inturn calls filterByType which is responsible for updating proof about the edges and this determining if checks on the node can be removed. This function is listed below:

ALWAYS_INLINE void AbstractInterpreter<AbstractStateType>::filterByType(Edge& edge, SpeculatedType type)
{
    AbstractValue& value = m_state.forNodeWithoutFastForward(edge);
    if (value.isType(type)) {
        m_state.setProofStatus(edge, IsProved);
        return;
    }
    m_state.setProofStatus(edge, NeedsCheck);
    m_state.fastForwardAndFilterUnproven(value, type);
}

If the abstract value for the node matches the speculated type of the edge, the AI will set the proof status of the edge to IsProved. This effectively removes the checks in place on the node for the child elements. Let’s use the example of ArithAdd on integer operands. Before the performCFA phase the node representation is as follows:

D@28:0:-> GetLocal(Check:Untyped:D@1, JS|MustGen|PureNum, BoolInt32, arg1(B<BoolInt32>/FlushedInt32), R:Stack(arg1), bc#7, ExitValid)  predicting BoolInt32
D@29:0:-> GetLocal(Check:Untyped:D@2, JS|MustGen|PureNum, NonBoolInt32, arg2(C<Int32>/FlushedInt32), R:Stack(arg2), bc#7, ExitValid)  predicting NonBoolInt32
D@30:0:-> ArithAdd(Check:Int32:D@28, Check:Int32:D@29, JS|MustGen|PureInt, Int32, Unchecked, Exits, bc#7, ExitValid)

After the performCFA phase the checks on child nodes D@28 and D@29 are removed, since the AI proved that the edge types to these node matches the abstract values collected by the AI:

D@28:0:-> GetLocal(Check:Untyped:D@1, JS|MustGen|PureNum, BoolInt32, arg1(B<BoolInt32>/FlushedInt32), R:Stack(arg1), bc#7, ExitValid)  predicting BoolInt32
D@29:0:-> GetLocal(Check:Untyped:D@2, JS|MustGen|PureNum, NonBoolInt32, arg2(C<Int32>/FlushedInt32), R:Stack(arg2), bc#7, ExitValid)  predicting NonBoolInt32
D@30:0:-> ArithAdd(Int32:D@28, Int32:D@29, JS|MustGen|PureInt, Int32, Unchecked, Exits, bc#7, ExitValid)

Constant Folding

CFA-based constant folding. Walks those blocks marked by the CFA as having inferred constants, and replaces those nodes with constants whilst injecting Phantom nodes to keep the children alive (which is necessary for OSR exit).

This phase loops over each node in the graph and attempts to constant fold values. Consider the following DFG graph snippet:

D@725:< 1:-> DoubleConstant(Double|PureInt, BytecodeDouble, Double: 9218868437227405312, inf, bc#30, ExitValid)
D@477:< 1:-> ArithNegate(DoubleRep:D@725<Double>, Double|PureNum|UseAsOther, AnyIntAsDouble|NonIntAsDouble, NotSet, Exits, bc#30, ExitValid)
D@478:0:-> MovHint(DoubleRep:D@477<Double>, MustGen, loc55, W:SideState, ClobbersExit, bc#30, ExitInvalid)
D@726:< 1:-> ValueRep(DoubleRep:D@477<Double>, JS|PureInt, BytecodeDouble, bc#30, exit: bc#463 --> isFinite#DJEgRe:<0x7fffaefc7b60> bc#35, ExitValid)

In the snippet above the node D@477 attempts to negate a constant double value which is referenced by the node D@725. Additionally, the node D@726 references the negated value that is generated by the node D@477. Following the constant folding phase, the node D@477 is replaced with a DoubleConstant node thus eliminating the need for an ArithNegate operation. The constant folding phase also replaces node D@726 with a JSConstant eliminating the need to reference D@477. The graph dump below shows the substitutions performed by this phase:

D@725:< 1:-> DoubleConstant(Double|PureInt, BytecodeDouble, Double: 9218868437227405312, inf, bc#30, ExitValid)
D@477:< 1:-> DoubleConstant(Double|PureNum|UseAsOther, AnyIntAsDouble|NonIntAsDouble, Double: -4503599627370496, -inf, bc#30, ExitValid)
D@478:0:-> MovHint(DoubleRep:D@477<Double>, MustGen, loc55, W:SideState, ClobbersExit, bc#30, ExitInvalid)
D@726:< 1:-> JSConstant(JS|PureInt, BytecodeDouble, Double: -4503599627370496, -inf, bc#30, exit: bc#463 --> isFinite#DJEgRe:<0x7fffaefc7b60> bc#35, ExitValid)

CFG Simplification

CFG simplification:

jump to single predecessor -> merge blocks branch on constant -> jump branch to same blocks -> jump jump-only block -> remove kill dead code

As the developer comments indicate, this phase, will look for optimisation opportunities to simply control flow within the graph. The comments then go on to list the aspects of the graph that the phase will attempt to identify as candidates for optimisation. This phase has the potential to massively change the graph as blocks may be merged or removed entirely (due to dead code elimination). The graph form is reset to LoadStore due to the de-threading of the graph when blocks are merged/removed.

Local Common Subexpression Elimination

Block-local common subexpression elimination. It uses clobberize() for heap modeling, which is quite precise. This phase is known to produce big wins on a few benchmarks, and is relatively cheap to run.

This phase perform block local CSE. As an example, consider the following DFG graph snippet:

D@87:< 1:-> JSConstant(JS|UseAsOther, OtherObj, Weak:Object: 0x7fffaefd4000 with butterfly 0x7fe0261fce68 (Structure %Dr:Function), StructureID: 39922, bc#85, ExitValid)
    
D@105:< 1:-> JSConstant(JS|UseAsOther, OtherObj, Weak:Object: 0x7fffaefd4000 with butterfly 0x7fe0261fce68 (Structure %Dr:Function), StructureID: 39922, bc#106, ExitValid)

D@107:0:-> MovHint(Check:Untyped:D@105, MustGen, loc25, W:SideState, ClobbersExit, bc#106, ExitValid)
D@108:< 1:-> SetLocal(Check:Untyped:D@105, loc25(NB~<Object>/FlushedJSValue), W:Stack(loc25), bc#106, exit: bc#114, ExitValid)  predicting OtherObj
D@109:0:-> MovHint(Check:Untyped:D@105, MustGen, loc24, W:SideState, ClobbersExit, bc#114, ExitValid)
D@110:< 1:-> SetLocal(Check:Untyped:D@105, loc24(OB~<Object>/FlushedJSValue), W:Stack(loc24), bc#114, exit: bc#117, ExitValid)  predicting OtherObj

In the snippet above the nodes D@87 and D@105 represent the same JSObject. The nodes from D@107 to D@110 reference this JSObject via the child node D@105. Node D@105 is redundant since we already have an existing node that represents the JSObject in D@87. The Local CSE phase identifies D@105 as a candidate for elimination and replaces all edges to this node with edges to D@87 and converts the node D@105 to a Check node. The snippet above is then transformed as follows:

D@87:< 1:-> JSConstant(JS|UseAsOther, OtherObj, Weak:Object: 0x7fffaefd4000 with butterfly 0x7fe0261fce68 (Structure %Dr:Function), StructureID: 39922, bc#85, ExitValid)

D@105:0:-> Check(MustGen, OtherObj, bc#106, ExitValid)

D@107:0:-> MovHint(Check:Untyped:D@87, MustGen, loc25, W:SideState, ClobbersExit, bc#106, ExitValid)
D@108:< 1:-> SetLocal(Check:Untyped:D@87, loc25(NB~<Object>/FlushedJSValue), W:Stack(loc25), bc#106, exit: bc#114, ExitValid)  predicting OtherObj
D@109:0:-> MovHint(Check:Untyped:D@87, MustGen, loc24, W:SideState, ClobbersExit, bc#114, ExitValid)
D@110:< 1:-> SetLocal(Check:Untyped:D@87, loc24(OB~<Object>/FlushedJSValue), W:Stack(loc24), bc#114, exit: bc#117, ExitValid)  predicting OtherObj

This phase has an internal verbose flag that when enabled will print debug information to stdout on the changes being performed by this phase to the graph.

Variable Arguments Forwarding

Eliminates allocations of Arguments-class objects when they flow into CallVarargs, ConstructVarargs, or LoadVarargs.

This phase loops over the nodes in the graph to identify any CreateDirectArguments and CreateClonedArguments nodes. These are referred to in the phase implementation as candidate nodes.

Once a candidate node is identified, the phase then proceeds to find a node (i.e. lastUserIndex) in the same block that last used the CreateDirectArguments or CreateClonedArguments node. It also attempts to find any escape sites when determining the last used node.

Once a valid lastUserIndex has been identified and there are no nodes between the candidate that can cause side effects, the phase begins forwarding. The changes to the graph performed by forwarding can be reviewed by inspecting the source code.

This phase has an internal verbose flag that can be enabled to print debug information on the phase changes to stdout.

Tier Up Check Injection

This phase checks if the this code block could be recompiled with the FTL, and if so, it injects tier-up checks.

This phase inserts tier-up check nodes to the graph when the FTL tier is enabled. These nodes are added at the head of a loop (i.e. after a LoopHint node) and before a return from a function call (i.e. before a Return node). the DFG snippets below provides an example of the tier-up check (addition of the CheckTierUpInLoop node) at the head of a loop:

D@372:0:-> LoopHint(MustGen, W:SideState, bc#401, ExitValid)
D@610:0:-> CheckTierUpInLoop(MustGen, W:SideState, Exits, bc#401, ExitValid)
D@373:0:-> InvalidationPoint(MustGen, W:SideState, Exits, bc#402, ExitValid)

Similarly, before a function returns, a CheckTierUpAtReturn node is inserted before the Return node as show in the example snippet below:

D@624:< 1:-> JSConstant(JS|UseAsOther, Other, Undefined, bc#647, ExitValid)
D@582:0:-> CheckTierUpAtReturn(MustGen, W:SideState, Exits, bc#647, ExitValid)
D@625:0:-> Return(Check:Untyped:D@624, MustGen, W:SideState, Exits, bc#647, ExitValid)

Fast Store Barrier Insertion

Inserts store barriers in a block-local manner without consulting the abstract interpreter. Uses a simple epoch-based analysis to avoid inserting barriers on newly allocated objects. This phase requires that we are not in SSA.

StoreBarriers are nodes that perform a function similar to write barriers, that this phase inserts before operations that write to an allocated JSObject. These nodes ensure memory ordering. Consider the following DFG graph dump:

D@284:< 1:-> JSConstant(JS|UseAsOther, OtherObj, Weak:Object: 0x7fffef9fca68 with butterfly 0x7ff802ffcc68 (Structure %Ec:Function), StructureID: 50667, bc#283, ExitValid)

D@288:0:-> PutById(Cell:D@284, Check:Untyped:D@275, MustGen, cachable-id {uid:(__proto__)}, R:World, W:Heap, Exits, ClobbersExit, bc#291, ExitValid)

In the snippet above, the node D@288 performs a memory write operation on the JSObject referenced by node D@284. The phase determines that it would require a StoreBarrier and inserts one just after D@288. The updated graph after this phase completes would be as follows:

D@284:< 1:-> JSConstant(JS|UseAsOther, OtherObj, Weak:Object: 0x7fffef9fca68 with butterfly 0x7ff802ffcc68 (Structure %Ec:Function), StructureID: 50667, bc#283, ExitValid)

D@288:0:-> PutById(Cell:D@284, Check:Untyped:D@275, MustGen, cachable-id {uid:(__proto__)}, R:World, W:Heap, Exits, ClobbersExit, bc#291, ExitValid)
D@583:0:-> FencedStoreBarrier(KnownCell:D@284, MustGen, R:Heap, W:JSCell_cellState, bc#291, ExitInvalid)

This phase has an internal verbose flag that when enabled allows printing of additional debug information how nodes in the graph are evaluated and when and where StoreBarriers are inserted.

Store Barrier Clustering

Picks up groups of barriers that could be executed in any order with respect to each other and places then at the earliest point in the program where the cluster would be correct. This phase makes only the first of the cluster be a FencedStoreBarrier while the rest are normal StoreBarriers. This phase also removes redundant barriers - for example, the cluster may end up with two or more barriers on the same object, in which case it is totally safe for us to drop one of them.

Essentially, this phase looks for opportunities to remove redundant FencedStoreBarriers nodes where possible. An example of this is documented in the developer comments for the phase.

Cleanup

Cleans up unneeded nodes, like empty Checks and Phantoms.

This phase simply scans the graph and removes redundant nodes such as empty Check and Phantom nodes.

Dead Code Elimination

Global dead code elimination. Eliminates any node that is not NodeMustGenerate, not used by any other live node, and not subject to any type check.

DCE in traditional compilers attempts to identify and remove code that is unreachable (i.e. code that never executes). However, in the context of the DFG graph optimisation, DCE attempts to identify nodes that generate a result but the result is never used by any other node. This phase loops over the nodes in the graph and attempts to remove such redundant nodes.

Phantom Insertion

Inserts Phantoms based on bytecode liveness.

Phantom nodes are described by the developers as follows:

In CPS form, Phantom means three things: (1) that the children should be kept alive so long as they are relevant to OSR (due to a MovHint), (2) that the children are live-in-bytecode at the point of the Phantom, and (3) that some checks should be performed.

When a node is killed, the DFG needs a way to ensure that any children of the node are kept alive if these children are required to reconstruct values that would be live in bytecode at the time of OSR Exit.

This phase loops over the nodes in the graph to determine if any nodes that have been killed have children that need to be preserved for OSR and inserts a Phantom node for these children. This evaluation is performed by the lambda processKilledOperand.

The internal verbose flag dumps debug information how each node in the graph is processed, how operands of the nodes are evaluated and when a Phantom node is inserted.

Stack Layout

Figures out the stack layout of VariableAccessData’s. This enumerates the locals that we actually care about and packs them. So for example if we use local 1, 3, 4, 5, 7, then we remap them: 1->0, 3->1, 4->2, 5->3, 7->4. We treat a variable as being “used” if there exists an access to it (SetLocal, GetLocal, Flush, PhantomLocal).

This phase packs the stack layout for locals to ensure there are no holes. This is done by looping over all the SetLocal, PhantomLocal, Flush and GetLocal nodes in the graph and remapping stack slots. As an example, the DFG graph dump below show how this assignment is represented:

GetLocal(Check:Untyped:D@652, JS|MustGen|PureInt, Function, loc34(AF~<Function>/FlushedJSValue), machine:loc14, R:Stack(loc34), bc#514, ExitValid)  predicting Function

In the snippet above, the GetLocal node uses loc34 as the virtual register to retrieve a Function object. However, after the Stack Layout phase, the virtual register is re-mapped to loc14. This is represented using: machine:loc14.

Virtual Register Allocation

Prior to running this phase, we have no idea where in the call frame nodes will have their values spilled. This phase fixes that by giving each node a spill slot. The spill slot index (i.e. the virtual register) is also used for look-up tables for the linear scan register allocator that the backend uses.

This phase adds virtual registers for nodes that generate a result (e.g. JSConstant, CompareLess, etc). An example of how these spill registers are represented is shown in the graph dump below:

D@74:< 2:loc24> GetClosureVar(KnownCell:D@27, JS|PureInt, Int32, scope0, R:ScopeProperties(0), Exits, bc#64, ExitValid)  predicting Int32

D@77:< 1:loc25> JSConstant(JS|PureInt, NonBoolInt32, Int32: 127, bc#72, ExitValid)
D@78:1:loc25> ArithAdd(Check:Int32:D@74, Int32:D@77, JS|MustGen|PureInt, Int32, Unchecked, Exits, bc#72, ExitValid)

In this snippet, the node D@74 has loc24 added to the IR to represent the spill register that the node should use. Some nodes and their children may also share a spill register as is the case with nodes D@77 and D@78.

Watchpoint Collection

Collects all desired watchpoints into the Graph::watchpoints() data structure.

This phase loops over the nodes in the graph starting with the last block to the first and attempts to add watchpoints for DFG nodes that meet certain conditions. These conditions are is described in the snippet from the phase implementation:

void handle()
{
    switch (m_node->op()) {
    case TypeOfIsUndefined:
        handleMasqueradesAsUndefined();
        break;
            
    case CompareEq:
        if (m_node->isBinaryUseKind(ObjectUse)
            || (m_node->child1().useKind() == ObjectUse && m_node->child2().useKind() == ObjectOrOtherUse)
            || (m_node->child1().useKind() == ObjectOrOtherUse && m_node->child2().useKind() == ObjectUse)
            || (m_node->child1().useKind() == KnownOtherUse || m_node->child2().useKind() == KnownOtherUse)
            handleMasqueradesAsUndefined();
        break;
            
    case LogicalNot:
    case Branch:
        switch (m_node->child1().useKind()) {
        case ObjectOrOtherUse:
        case UntypedUse:
            handleMasqueradesAsUndefined();
            break;
        default:
            break;
        }
        break;
            
    default:
        break;
    }
}
    
void handleMasqueradesAsUndefined()
{
    if (m_graph.masqueradesAsUndefinedWatchpointIsStillValid(m_node->origin.semantic))
        addLazily(globalObject()->masqueradesAsUndefinedWatchpoint());
}

The function handleMasqueradesAsUndefined when invoked adds a watchpoint to the WatchpointSet m_masqueradesAsUndefinedWatchpoint. Note that changes to the WatchpointSets are not reflected in the DFG graph dump.

Conclusion

This post explored the various components that make up the DFG optimisation pipeline by understanding how each optimisation phase transforms the graph. In Part V of this blog series we dive into the details of how the DFG compiles this optimised graph into machine code and how execution enters to and exits from this optimised machine code.

Appendix

https://webkit.org/blog/10308/speculation-in-javascriptcore/ ↩︎ ↩︎ ↩︎ ↩︎

JavaScriptCore Internals Part V: The DFG (Data Flow Graph) JIT -- On Stack Replacement

Wed, 26 May 2021 00:00:00 +0000

Introduction

This blog post concludes this review of the DFG with a discussion on the final two stages of the optimisation pipeline: Code generation and OSR. This post begins by examining how an optimised DFG graph is lowered to machine code and how one can inspect the generated machine code. Finally, the blog covers OSR Entry and OSR Exit to and from this optimised compiled code.

Graph Compilation

To begin exploring graph compilation, consider the following JavaScript program and the function jitMe that will be compiled with in the DFG:

function jitMe(x,y) {
    return x + y
}

let x = 1;

for (let y = 0; y < 1000; y++) {
    jitMe(x,y)
}

The function jitMe is executed in a loop over a thousand iterations to trigger DFG optimisation and generation of a DFG graph that is then optimised by running it through the optimisation phases described in Part IV.

Code Generation

Once an optimised graph has been generated for the function jitMe, it’s now time to lower this to machine code. Let’s continue our inspection in DFG::Plan::compileInThreadImpl after the optimisation phases:

JITCompiler dataFlowJIT(dfg);
if (m_codeBlock->codeType() == FunctionCode)
    dataFlowJIT.compileFunction();
else
dataFlowJIT.compile();

First a JITCompiler object is initialised using the optimised graph. This sets up references to the CodeBlock, the optimised graph, a pointer to JIT memory and a reference to the JSC vm. The JITCompiler constructor is listed below:

JITCompiler::JITCompiler(Graph& dfg)
    : CCallHelpers(dfg.m_codeBlock)
    , m_graph(dfg)
    , m_jitCode(adoptRef(new JITCode()))
    , m_blockHeads(dfg.numBlocks())
    , m_pcToCodeOriginMapBuilder(dfg.m_vm)
{
//... code truncated for brevity.
}

With the JITCompiler initialised, the next step is to compile the dfg to machine code. This is done by calling one of two functions. If the CodeBlock being compiled is a JS Function, the function JITCompiler::compileFunction is called. For all other CodeBlock types, the JITCompiler::compile function is called. In our example above, the goal is to compile the jitMe function in the DFG and that leads to the call to compileFunction:

void JITCompiler::compileFunction()
{
    // === Function header code generation ===
    //... code truncated for brevity
    
    // === Function body code generation ===
    m_speculative = makeUnique<SpeculativeJIT>(*this);
    compileBody();
    setEndOfMainPath();

    // === Function footer code generation ===
    //... code truncated for brevity

    // Generate slow path code.
    m_speculative->runSlowPathGenerators(m_pcToCodeOriginMapBuilder);
    m_pcToCodeOriginMapBuilder.appendItem(labelIgnoringWatchpoints(), PCToCodeOriginMapBuilder::defaultCodeOrigin());
    
    compileExceptionHandlers();
    linkOSRExits();
    
    // Create OSR entry trampolines if necessary.
    m_speculative->createOSREntries();
    setEndOfCode();

    // === Link ===
    auto linkBuffer = makeUnique<LinkBuffer>(*this, m_codeBlock, JITCompilationCanFail);
    if (linkBuffer->didFailToAllocate()) {
        m_graph.m_plan.setFinalizer(makeUnique<FailedFinalizer>(m_graph.m_plan));
        return;
    }
    link(*linkBuffer);
    m_speculative->linkOSREntries(*linkBuffer);
    
    //... code truncated for brevity

    MacroAssemblerCodePtr<JSEntryPtrTag> withArityCheck = linkBuffer->locationOf<JSEntryPtrTag>(arityCheck);

    m_graph.m_plan.setFinalizer(makeUnique<JITFinalizer>(
        m_graph.m_plan, m_jitCode.releaseNonNull(), WTFMove(linkBuffer), withArityCheck));
}

This function begins by emitting code for the function header, this involves saving frame preservation, stack pointer adjustments to accommodate local variables and other function prologue activities. This is then followed by instantiating the SpeculativeJIT and initiating compilation using this instance:

// === Function body code generation ===
m_speculative = makeUnique<SpeculativeJIT>(*this);
compileBody();

The function JITCompiler::compileBody listed above ends up calling SpeculativeJIT::compile which loops over the blocks in the DFG and emits machine code for each of them. Once this compilation is completed, it then links the various blocks to complete the compilation:

bool SpeculativeJIT::compile()
{
    checkArgumentTypes();
    
    ASSERT(!m_currentNode);
    for (BlockIndex blockIndex = 0; blockIndex < m_jit.graph().numBlocks(); ++blockIndex) {
        m_jit.setForBlockIndex(blockIndex);
        m_block = m_jit.graph().block(blockIndex);
        compileCurrentBlock();
    }
    linkBranches();
    return true;
}

The function compileCurrentBlock iterates over each node in the block and invokes the function SpeculativeJIT::compile(Node*) on each node:

void SpeculativeJIT::compile(Node* node)
{
    NodeType op = node->op();

    //... code truncated for brevity

    switch (op) {
    case JSConstant:
    case DoubleConstant:
    //... code truncated for brevity

    case GetLocal: {
        AbstractValue& value = m_state.operand(node->operand());

        // If the CFA is tracking this variable and it found that the variable
        // cannot have been assigned, then don't attempt to proceed.
        if (value.isClear()) {
            m_compileOkay = false;
            break;
        }
        
        switch (node->variableAccessData()->flushFormat()) {
        case FlushedDouble: {
            //... code truncated for brevity
            break;
        }
        
        case FlushedInt32: {
            GPRTemporary result(this);
            m_jit.load32(JITCompiler::payloadFor(node->machineLocal()), result.gpr());
            
            // Like strictInt32Result, but don't useChildren - our children are phi nodes,
            // and don't represent values within this dataflow with virtual registers.
            VirtualRegister virtualRegister = node->virtualRegister();
            m_gprs.retain(result.gpr(), virtualRegister, SpillOrderInteger);
            generationInfoFromVirtualRegister(virtualRegister).initInt32(node, node->refCount(), result.gpr());
            break;
        }
            
        case FlushedInt52: {
            //... code truncated for brevity
            break;
        }
            
        default:
            //... code truncated for brevity
        }
        break;
    }

    case MovHint: {
        compileMovHint(m_currentNode);
        noResult(node);
        break;
    }

    //... code truncated for brevity

    case ArithAdd:
        compileArithAdd(node);
        break;

    //... code turncated for brevity
    }
}

From the snippet above, one can see that each node is filtered through a switch case and depending on the node type, a set of actions is selected to compile the node. Let’s attempt to trace the code generated for the following nodes, generated from parsing and optimising our test script:

function jitMe(x,y) {
    return x + y
}

let x = 1;

for (let y = 0; y < 1000; y++) {
    jitMe(x,y)
}

A truncated version of the final optimised graph and the nodes that compilation will be traced for are listed below:

D@28:1:loc5> GetLocal(Check:Untyped:D@1, JS|MustGen|UseAsOther, BoolInt32, arg1(B<BoolInt32>/FlushedInt32), machine:arg1, R:Stack(arg1), bc#7, ExitValid)  predicting BoolInt32
D@29:1:loc6> GetLocal(Check:Untyped:D@2, JS|MustGen|UseAsOther, NonBoolInt32, arg2(C<Int32>/FlushedInt32), machine:arg2, R:Stack(arg2), bc#7, ExitValid)  predicting NonBoolInt32
D@30:2:loc6> ArithAdd(Int32:D@28, Int32:D@29, JS|MustGen|UseAsOther, Int32, CheckOverflow, Exits, bc#7, ExitValid)

A couple useful flags that help with tracing compilation and code generation are listed below:

verboseCompilation: This enables printing compilation information form the SpeculativeJIT as each node is compiled.
dumpDFGDisassembly: This enables dumping of compiled code for each node at the end of the code generation stage.

These should be enabled in launch.json. Returning back to our discussion of SpeculativeJIT::compile(Node*), lets set a breakpoint at the GetLocal switch case and step through the generation of machine code. With the verboseCompilation flag enabled one should see logging similar to the output below:

SpeculativeJIT generating Node @0 (0) at JIT offset 0x209
SpeculativeJIT generating Node @1 (0) at JIT offset 0x226
SpeculativeJIT generating Node @2 (0) at JIT offset 0x243

//... truncated for brevity

SpeculativeJIT generating Node @31 (7) at JIT offset 0x746
SpeculativeJIT generating Node @33 (13) at JIT offset 0x763
SpeculativeJIT generating Node @34 (13) at JIT offset 0x793
Bailing compilation.

Let’s examine node D@30, from the graph dump listed previously, which is an ArithAdd node. Compiling this node results in a call to compileArithAdd(Node*):

void SpeculativeJIT::compileArithAdd(Node* node)
{
    switch (node->binaryUseKind()) {
    case Int32Use: {
        ASSERT(!shouldCheckNegativeZero(node->arithMode()));

        if (node->child2()->isInt32Constant()) {
            //... code truncated for brevity
        }
                
        SpeculateInt32Operand op1(this, node->child1());
        SpeculateInt32Operand op2(this, node->child2());
        GPRTemporary result(this, Reuse, op1, op2);

        GPRReg gpr1 = op1.gpr();
        GPRReg gpr2 = op2.gpr();
        GPRReg gprResult = result.gpr();

        if (!shouldCheckOverflow(node->arithMode()))
            m_jit.add32(gpr1, gpr2, gprResult);
        else {
            MacroAssembler::Jump check = m_jit.branchAdd32(MacroAssembler::Overflow, gpr1, gpr2, gprResult);
                
            if (gpr1 == gprResult && gpr2 == gprResult)
                speculationCheck(Overflow, JSValueRegs(), nullptr, check, SpeculationRecovery(SpeculativeAddSelf, gprResult, gpr2));
            else if (gpr1 == gprResult)
                speculationCheck(Overflow, JSValueRegs(), nullptr, check, SpeculationRecovery(SpeculativeAdd, gprResult, gpr2));
            else if (gpr2 == gprResult)
                speculationCheck(Overflow, JSValueRegs(), nullptr, check, SpeculationRecovery(SpeculativeAdd, gprResult, gpr1));
            else
                speculationCheck(Overflow, JSValueRegs(), nullptr, check);
        }

        strictInt32Result(gprResult, node);
        return;
    }
        
    //... code truncated for brevity
}

The function above first generates SpeculateInt32Operand objects for the two operands of the addition operation. It then extracts the general purpose registers for these two operands as well as the gpr of the result. Next it performs a check to determine if the addition would cause an overflow. From the optimisation phases, it was determined that the ArithAdd operation is unchecked and does not need checks for overflows. This results in a call to add32 which is defined in MacroAssemblerX86Common.h.

void add32(RegisterID a, RegisterID b, RegisterID dest)
    {
        x86Lea32(BaseIndex(a, b, TimesOne), dest);
    }

    void x86Lea32(BaseIndex index, RegisterID dest)
    {
        if (!index.scale && !index.offset) {
            if (index.base == dest) {
                add32(index.index, dest);
                return;
            }
            if (index.index == dest) {
                add32(index.base, dest);
                return;
            }
        }
        m_assembler.leal_mr(index.offset, index.base, index.index, index.scale, dest);
    }

The functions above then invoke the assembler which results in the generation of the following machine code:

D@30:2:loc6>    ArithAdd(Int32:D@28, Int32:D@29, JS|MustGen|UseAsOther, Int32, CheckOverflow, Exits, bc#7, ExitValid)
          0x7fffeecfeb1a: mov $0x7fffaeb0bba0, %r11
          0x7fffeecfeb24: mov (%r11), %r11
          0x7fffeecfeb27: test %r11, %r11
          0x7fffeecfeb2a: jz 0x7fffeecfeb37
          0x7fffeecfeb30: mov $0x113, %r11d
          0x7fffeecfeb36: int3 
          0x7fffeecfeb37: mov $0x7fffaeb000e4, %r11
          0x7fffeecfeb41: mov $0xf0f4, (%r11)
          0x7fffeecfeb48: add %esi, %eax
          0x7fffeecfeb4a: jo 0x7fffeecfedd2
          0x7fffeecfeb50: mov $0xffffffff, %r11
          0x7fffeecfeb5a: cmp %r11, %rax
          0x7fffeecfeb5d: jbe 0x7fffeecfeb6a
          0x7fffeecfeb63: mov $0x32, %r11d
          0x7fffeecfeb69: int3

In this fashion, each block and node in each block are compiled to machine code. One can evaluate compilation for each node type by adding breakpoints at the various case statements within compile(Node*) as demonstrate for GetLocal and ArithAdd.

At the end of this compilation, execution returns back to SpeculativeJIT::compile which then calls linkBranches. This function as the name suggests links the various blocks in the graph by iterating over the branches that have been generated as part node compilation and linking them to the corresponding blocks:

void SpeculativeJIT::linkBranches()
{
    for (auto& branch : m_branches)
        branch.jump.linkTo(m_jit.blockHeads()[branch.destination->index], &m_jit);
}

The current test script, test.js does not contain any branching instructions such as loops or if-else statements but one can generate a test script with branching instructions as demonstrated in DFG IR section on branching.

After linkBranches completes and through a series of returns, execution ends up back in JITCompiler::compileFunction at the start of the footer code generation. The snippet of the function listed below performs four main tasks. It performs a number of checks on stack overflows and an arity check if required. An arity check ensures that the correct number of arguments is passed to the CodeBlock before execution of the optimised code.

    // === Function footer code generation ===
    //
    // Generate code to perform the stack overflow handling (if the stack check in
    // the function header fails), and generate the entry point with arity check.

    //... truncated for brevity
    Call callArityFixup;
    Label arityCheck;
    bool requiresArityFixup = m_codeBlock->numParameters() != 1;
    if (requiresArityFixup) {
        arityCheck = label();
        compileEntry();

        load32(AssemblyHelpers::payloadFor((VirtualRegister)CallFrameSlot::argumentCountIncludingThis), GPRInfo::regT1);
        branch32(AboveOrEqual, GPRInfo::regT1, TrustedImm32(m_codeBlock->numParameters())).linkTo(fromArityCheck, this);
        emitStoreCodeOrigin(CodeOrigin(BytecodeIndex(0)));
        //... code truncated for brevity
    } else
        arityCheck = entryLabel;

    //... truncated for brevity

Slow Path Generation and OSR Linking

Once the various nodes in the graph have been lowered to machine code, the next step in the code generation phase is to emit slow path code, link the optimised code to OSR Exit sites and finally creates OSR Entries into the optimised code.

    // Generate slow path code.
    m_speculative->runSlowPathGenerators(m_pcToCodeOriginMapBuilder);
    m_pcToCodeOriginMapBuilder.appendItem(labelIgnoringWatchpoints(), PCToCodeOriginMapBuilder::defaultCodeOrigin());
    
    compileExceptionHandlers();
    linkOSRExits();
    
    // Create OSR entry trampolines if necessary.
    m_speculative->createOSREntries();
    setEndOfCode();

Slow Paths are generated for operations that require additional checks that the DFG cannot optimise out. Examples of JavaScript constructs that generate slow paths are array push operations, array slice operations, Calling toObject or an object constructor, etc. The function runSlowPathGenerators is listed below:

void SpeculativeJIT::runSlowPathGenerators(PCToCodeOriginMapBuilder& pcToCodeOriginMapBuilder)
{
    for (auto& slowPathGenerator : m_slowPathGenerators) {
        pcToCodeOriginMapBuilder.appendItem(m_jit.labelIgnoringWatchpoints(), slowPathGenerator->origin().semantic);
        slowPathGenerator->generate(this);
    }
    for (auto& slowPathLambda : m_slowPathLambdas) {
        Node* currentNode = slowPathLambda.currentNode;
        m_currentNode = currentNode;
        m_outOfLineStreamIndex = slowPathLambda.streamIndex;
        pcToCodeOriginMapBuilder.appendItem(m_jit.labelIgnoringWatchpoints(), currentNode->origin.semantic);
        slowPathLambda.generator();
        m_outOfLineStreamIndex = WTF::nullopt;
    }
}

The snippet above, lists two loops, one that iterates over m_slowPathGenerators and the other over m_slowPathLambdas. In the first loop for each slowPathGenerator, the generate function is invoked which through a series of function calls ends up calling CallResultAndArgumentsSlowPathGenerator::unpackAndGenerate:

void unpackAndGenerate(SpeculativeJIT* jit, std::index_sequence<ArgumentsIndex...>)
    {
        this->setUp(jit);
        if constexpr (std::is_same<ResultType, NoResultTag>::value)
            this->recordCall(jit->callOperation(this->m_function, std::get<ArgumentsIndex>(m_arguments)...));
        else
            this->recordCall(jit->callOperation(this->m_function, extractResult(this->m_result), std::get<ArgumentsIndex>(m_arguments)...));
        this->tearDown(jit);
    }

In the snippet above, the function begins by calling setUp which emits code that generates jump instructions from the JIT code to the slow path call. It then invokes the function callOperation which emits machine code for the specific slow path call identified by m_function. Finally, once callOperation returns, the call to tearDown generates jump instructions from the slow path back into the JIT code. One of the design principles of slow paths is that they are shared across the four JSC tiers and can be accessed via the JIT ABI.

Once code for slow paths have been generated, the various OSR Exits are linked with the call to linkOSRExits. The essentially loops over the OSR Exit sites that have been recorded at the time of graph generation and uses this information to generate jump instructions from the JIT code to a OSR Exit handler. The OSR Exit section of this blog will cover how these exits are handled in further detail.

Finally, a call to createOSREntries which loops over the list of blocks in the graph and identifies blocks that are either OSR Entry targets or entry points to Catch blocks to generate a list of OSR Entry points that will be linked as part of the final stage of compilation.

Code Linking

Following the code generation stage, execution reaches the end of the JITCompiler::compileFunction which is the final stage of the JIT compilation and does the linking and finalisation of the compilation process:

    //... code truncated for brevity

    // === Link ===
    auto linkBuffer = makeUnique<LinkBuffer>(*this, m_codeBlock, JITCompilationCanFail);
    if (linkBuffer->didFailToAllocate()) {
        m_graph.m_plan.setFinalizer(makeUnique<FailedFinalizer>(m_graph.m_plan));
        return;
    }
    link(*linkBuffer);
    m_speculative->linkOSREntries(*linkBuffer);
    
    if (requiresArityFixup)
        linkBuffer->link(callArityFixup, FunctionPtr<JITThunkPtrTag>(vm().getCTIStub(arityFixupGenerator).code()));

    disassemble(*linkBuffer);

    MacroAssemblerCodePtr<JSEntryPtrTag> withArityCheck = linkBuffer->locationOf<JSEntryPtrTag>(arityCheck);

    m_graph.m_plan.setFinalizer(makeUnique<JITFinalizer>(
        m_graph.m_plan, m_jitCode.releaseNonNull(), WTFMove(linkBuffer), withArityCheck));
}

The function first allocates memory of the LinkBuffer and retrieves a pointer to this object. It then calls the function JITCompiler::link which performs a number of linking operations on the LinkBuffer. These operations include linking switch statements, function calls within the optimised code and from the optimised code to external targets (e.g. stack overflow checks, arity checks, etc), inline cache accesses, OSR Exit targets and finally any exception handlers generated by the DFG.

Once the JITCompiler::link function returns, the call the function SpeculativeJIT::linkOSREntries(LinkBuffer& linkBuffer) is invoked. This function loops over each block in the graph to determine if the block is an OSR Entry Target and makes a record of it. With the verboseCompilation flag enabled, you should be able to see the various OSR Entry sites printed to stdout. For example, the OSR entries generated for test script test.js are listed below:

OSR Entries:
    bc#0, machine code = 0x7fffeecfe917, stack rules = [arg2:(Int32, none:StructuresAreClobbered) (maps to arg2), arg1:(Int32, none:StructuresAreClobbered) (maps to arg1), arg0:(BytecodeTop, TOP, TOP, none:StructuresAreClobbered) (maps to this), loc0:(BytecodeTop, TOP, TOP, none:StructuresAreClobbered) (ignored), loc1:(BytecodeTop, TOP, TOP, none:StructuresAreClobbered) (ignored), loc2:(BytecodeTop, TOP, TOP, none:StructuresAreClobbered) (ignored), loc3:(BytecodeTop, TOP, TOP, none:StructuresAreClobbered) (ignored), loc4:(BytecodeTop, TOP, TOP, none:StructuresAreClobbered) (ignored), loc5:(BytecodeTop, TOP, TOP, none:StructuresAreClobbered) (ignored), loc6:(BytecodeTop, TOP, TOP, none:StructuresAreClobbered) (ignored), loc7:(BytecodeTop, TOP, TOP, none:StructuresAreClobbered) (ignored)], machine stack used = ---------------------------------------------------------------

The function that dumps the various OSR entries is OSREntryData::dumpInContext. Setting a break point at this function will allow inspection of the individual fields on the OSR Entry site.

Lastly a JITFinalizer is initialised which takes four arguments: a reference to the optimised graph, a reference to the JIT memory for the CodeBlock, a reference to the LinkBuffer which contains the DFG compiled code and finally an entry pointer into the LinkBuffer (i.e. withArityCheck).

m_graph.m_plan.setFinalizer(makeUnique<JITFinalizer>(
        m_graph.m_plan, m_jitCode.releaseNonNull(), WTFMove(linkBuffer), withArityCheck));

The JITFinalizer sets up pointer references from the CodeBlock to the JIT code located in the linkBuffer and other housekeeping activities. At this point in the compilation phase one can dump all the DFG generated optimised code to stdout by enabling the --dumpDFGDisassembly=true flag. An example of what the disassembly dump would look like is listed below:

Generated DFG JIT code for jitMe#Dsl1pz:[0x7fffae3c4260->0x7fffae3c4130->0x7fffae3e5100, DFGFunctionCall, 15], instructions size = 15:
    Optimized with execution counter = 1005.000000/1072.000000, 5
    Code at [0x7fffeecfe880, 0x7fffeecfee00):
          0x7fffeecfe880: push %rbp
          0x7fffeecfe881: mov %rsp, %rbp
          0x7fffeecfe884: mov $0x7fffae3c4260, %r11

//... truncated for brevity

          0x7fffeecfe8ed: cmp %r14, 0x38(%rbp)
          0x7fffeecfe8f1: jb 0x7fffeecfed84
    Block #0 (bc#0): (OSR target)
      Execution count: 1.000000
      Predecessors:
      Successors:
      Dominated by: #root #0
      Dominates: #0
      Dominance Frontier: 
      Iterated Dominance Frontier: 
          0x7fffeecfe8f7: test $0x7, %bpl
          0x7fffeecfe8fb: jz 0x7fffeecfe908
          0x7fffeecfe901: mov $0xa, %r11d

//... truncated for brevity

          0x7fffeecfe950: int3 
       D@0:< 1:->       SetArgumentDefinitely(IsFlushed, this(a), machine:this, W:SideState, bc#0, ExitValid)  predicting OtherObj
          0x7fffeecfe951: mov $0x7fffaeb000e4, %r11
          0x7fffeecfe95b: mov $0x94, (%r11)
       D@1:< 2:->       SetArgumentDefinitely(IsFlushed, arg1(B<BoolInt32>/FlushedInt32), machine:arg1, W:SideState, bc#0, ExitValid)  predicting BoolInt32
          0x7fffeecfe962: mov $0x7fffaeb000e4, %r11
          0x7fffeecfe96c: mov $0x894, (%r11)
       D@2:< 2:->       SetArgumentDefinitely(IsFlushed, arg2(C<Int32>/FlushedInt32), machine:arg2, W:SideState, bc#0, ExitValid)  predicting NonBoolInt32
          0x7fffeecfe973: mov $0x7fffaeb000e4, %r11
          0x7fffeecfe97d: mov $0x1094, (%r11)
       D@3:0:->       CountExecution(MustGen, 0x7fffeed96190, R:InternalState, W:InternalState, bc#0, ExitValid)
          0x7fffeecfe984: mov $0x7fffaeb000e4, %r11
          0x7fffeecfe98e: mov $0x1d1c, (%r11)
          0x7fffeecfe995: mov $0x7fffeed96190, %r11
          0x7fffeecfe99f: inc (%r11)

//... truncated for brevity

      D@28:1:loc5>    GetLocal(Check:Untyped:D@1, JS|MustGen|UseAsOther, BoolInt32, arg1(B<BoolInt32>/FlushedInt32), machine:arg1, R:Stack(arg1), bc#7, ExitValid)  predicting BoolInt32
          0x7fffeecfeaf2: mov $0x7fffaeb000e4, %r11
          0x7fffeecfeafc: mov $0xe03c, (%r11)
          0x7fffeecfeb03: mov 0x30(%rbp), %eax
      D@29:1:loc6>    GetLocal(Check:Untyped:D@2, JS|MustGen|UseAsOther, NonBoolInt32, arg2(C<Int32>/FlushedInt32), machine:arg2, R:Stack(arg2), bc#7, ExitValid)  predicting NonBoolInt32
          0x7fffeecfeb06: mov $0x7fffaeb000e4, %r11
          0x7fffeecfeb10: mov $0xe83c, (%r11)
          0x7fffeecfeb17: mov 0x38(%rbp), %esi
      D@30:2:loc6>    ArithAdd(Int32:D@28, Int32:D@29, JS|MustGen|UseAsOther, Int32, CheckOverflow, Exits, bc#7, ExitValid)
          0x7fffeecfeb1a: mov $0x7fffaeb0bba0, %r11
          0x7fffeecfeb24: mov (%r11), %r11
          0x7fffeecfeb27: test %r11, %r11
          0x7fffeecfeb2a: jz 0x7fffeecfeb37
          0x7fffeecfeb30: mov $0x113, %r11d
          0x7fffeecfeb36: int3 
          
//... truncated for brevity

    (End Of Main Path)
          0x7fffeecfebf4: mov $0x0, 0x24(%rbp)
          0x7fffeecfebfb: mov $0x7fffae3c4260, %rdi
          0x7fffeecfec05: mov $0x7fffaeb09fd8, %r11
          
//... truncated for brevity
          
          0x7fffeecfeded: mov $0x3, (%r11)
          0x7fffeecfedf4: jmp 0x7fffaecffc20
    Structures:
        %Bq:JSGlobalLexicalEnvironment = 0x7fffae3f9180:[0xf475, JSGlobalLexicalEnvironment, {}, NonArray, Leaf]

Once compilation and linking has been completed, execution then returns back up the call stack back to Plan::compileInThread after returning from Plan::compileInThreadImpl. On successful compilation and with the reportCompileTimes flag enabled in launch.json one should see the following log statement printed to stdout just before the function Plan::compileInThread returns:

Optimized jitMe#Dsl1pz:[0x7fffae3c4260->0x7fffae3c4130->0x7fffae3e5100, NoneFunctionCall, 15] using DFGMode with DFG into 1408 bytes in 64.088453 ms.

The function compileInThread returns to DFG::compileImpl which invokes the function Plan::finalizeWithoutNotifyingCallback before returning to DFG::compile:

plan->compileInThread(nullptr);
return plan->finalizeWithoutNotifyingCallback();

The function above does two important actions, among a number of validation checks, it first validates that the compilation has succeeded and that the CodeBlock, which was compiled, is still valid. The second most important action is that it invokes the finalizer created earlier which updates the CodeBlocks reference to the JITCode and the entry point to being execution from which is referenced by withArityCheck:

bool JITFinalizer::finalizeFunction()
{
    RELEASE_ASSERT(!m_withArityCheck.isEmptyValue());
    m_jitCode->initializeCodeRefForDFG(
        FINALIZE_DFG_CODE(*m_linkBuffer, JSEntryPtrTag, "DFG JIT code for %s", toCString(CodeBlockWithJITType(m_plan.codeBlock(), JITType::DFGJIT)).data()),
        m_withArityCheck);
    m_plan.codeBlock()->setJITCode(m_jitCode.copyRef());

    finalizeCommon();
    
    return true;
}

Once these references have been set, the DFG can now notify the engine on where to jump to in order to being execution in the optimised code. The next section will examine how execution transfers from the BaslineJIT into the optimised code generated by the DFG.

Tracing Execution

Having successfully compiled the CodeBlock with the DFG, execution control after the compilation returns to operationOpitmize in JITOperations.cpp:

    //... code truncated for brevity.

        CodeBlock* replacementCodeBlock = codeBlock->newReplacement();
        CompilationResult result = DFG::compile(
            vm, replacementCodeBlock, nullptr, DFG::DFGMode, bytecodeIndex,
            mustHandleValues, JITToDFGDeferredCompilationCallback::create());
        
        if (result != CompilationSuccessful) {
            CODEBLOCK_LOG_EVENT(codeBlock, "delayOptimizeToDFG", ("compilation failed"));
            return encodeResult(nullptr, nullptr);
        }
    }

    //... code truncated for brevity

Execution now need to jump to the optimised code and this is done via OSR Entry which will be discussed in the next section.

OSR Entry

This begins with the call to prepareOSREntry from operationOptimize which is shown in the snippet below:

CodeBlock* optimizedCodeBlock = codeBlock->replacement();
    ASSERT(optimizedCodeBlock && JITCode::isOptimizingJIT(optimizedCodeBlock->jitType()));
    
    if (void* dataBuffer = DFG::prepareOSREntry(vm, callFrame, optimizedCodeBlock, bytecodeIndex)) {
        //... truncated for brevity

        void* targetPC = vm.getCTIStub(DFG::osrEntryThunkGenerator).code().executableAddress();
        targetPC = retagCodePtr(targetPC, JITThunkPtrTag, bitwise_cast<PtrTag>(callFrame));
        return encodeResult(targetPC, dataBuffer);
    }

The function prepareOSREntry, determines if it is safe to OSR entry into the optimised code by performing a number of checks. If a check fails the function returns 0 which causes the execution to continue in the Baseline JIT and the tier-up threshold counters are adjusted on account of OSR Entry failing. When all checks pass, it returns a pointer to a dataBuffer that the OSR entry thunk will recognize and parse.

From the snippet above, prepareOSREntry takes four arguments: a reference to the JSC runtime, a reference to the currently executing call frame in the Baseline JIT, a reference to the CodeBlock that’s been optimized by the DFG and the bytecode index at which to OSR Enter.

Stepping into the function, it first gathers information on OSR Entry for the supplied bytecode index:

JITCode* jitCode = codeBlock->jitCode()->dfg();
OSREntryData* entry = jitCode->osrEntryDataForBytecodeIndex(bytecodeIndex);

if (!entry) {
   dataLogLnIf(Options::verboseOSR(), "    OSR failed because the entrypoint was optimized out.");
   return nullptr;
}

If valid OSREntryData was retrieved the function performs various checks to determine if it’s safe to OSR Enter. The developer comments in the source code document the various checks that are performed before OSR Entry. Once the checks pass and the DFG has committed to OSR Entry, the next step is to populate the dataBuffer and other data format conversions:

// 3) Set up the data in the scratch buffer and perform data format conversions.

    unsigned frameSize = jitCode->common.frameRegisterCount;
    unsigned baselineFrameSize = entry->m_expectedValues.numberOfLocals();
    unsigned maxFrameSize = std::max(frameSize, baselineFrameSize);

    Register* scratch = bitwise_cast<Register*>(vm.scratchBufferForSize(sizeof(Register) * (2 + CallFrame::headerSizeInRegisters + maxFrameSize))->dataBuffer());
    
    *bitwise_cast<size_t*>(scratch + 0) = frameSize;  <-- Frame size added to buffer
    
    void* targetPC = entry->m_machineCode.executableAddress();  <--- Memory address to optimised machine code at which to OSR Enter
    //... truncated for brevity
    *bitwise_cast<void**>(scratch + 1) = retagCodePtr(targetPC, OSREntryPtrTag, bitwise_cast<PtrTag>(callFrame)); <-- targetPC added to buffer

    Register* pivot = scratch + 2 + CallFrame::headerSizeInRegisters;
    
    for (int index = -CallFrame::headerSizeInRegisters; index < static_cast<int>(baselineFrameSize); ++index) { <-- Register values added to the buffer
        VirtualRegister reg(-1 - index);
        
        if (reg.isLocal()) {
            if (entry->m_localsForcedDouble.get(reg.toLocal())) {
                *bitwise_cast<double*>(pivot + index) = callFrame->registers()[reg.offset()].asanUnsafeJSValue().asNumber();
                continue;
            }
            
            if (entry->m_localsForcedAnyInt.get(reg.toLocal())) {
                *bitwise_cast<int64_t*>(pivot + index) = callFrame->registers()[reg.offset()].asanUnsafeJSValue().asAnyInt() << JSValue::int52ShiftAmount;
                continue;
            }
        }
        
        pivot[index] = callFrame->registers()[reg.offset()].asanUnsafeJSValue();
    }

The value of targetPC in the snippet above points to the memory address of the first optimised machine code instruction for the compiled bytecode at which the engine will OSR Enter at. This address is added to the buffer along with the various loc values from the current call frame.

This is followed by shuffling temporary locals and cleaning up the call frame of values that aren’t used by the DFG. Once the registers have been aligned in the buffer, the next step is to handle callee saves in the buffer.

// 6) Copy our callee saves to buffer.
#if NUMBER_OF_CALLEE_SAVES_REGISTERS > 0
    const RegisterAtOffsetList* registerSaveLocations = codeBlock->calleeSaveRegisters();
    RegisterAtOffsetList* allCalleeSaves = RegisterSet::vmCalleeSaveRegisterOffsets();
    RegisterSet dontSaveRegisters = RegisterSet(RegisterSet::stackRegisters(), RegisterSet::allFPRs());

    unsigned registerCount = registerSaveLocations->size();
    VMEntryRecord* record = vmEntryRecord(vm.topEntryFrame);
    for (unsigned i = 0; i < registerCount; i++) {
        RegisterAtOffset currentEntry = registerSaveLocations->at(i);
        if (dontSaveRegisters.get(currentEntry.reg()))
            continue;
        RegisterAtOffset* calleeSavesEntry = allCalleeSaves->find(currentEntry.reg());
        
        if constexpr (CallerFrameAndPC::sizeInRegisters == 2)
            *(bitwise_cast<intptr_t*>(pivot - 1) - currentEntry.offsetAsIndex()) = record->calleeSaveRegistersBuffer[calleeSavesEntry->offsetAsIndex()];
        else {
            // We need to adjust 4-bytes on 32-bits, otherwise we will clobber some parts of
            // pivot[-1] when currentEntry.offsetAsIndex() returns -1. This region contains
            // CallerFrameAndPC and if it is cloberred, we will have a corrupted stack.
            // Also, we need to store callee-save registers swapped in pairs on scratch buffer,
            // otherwise they will be swapped when copied to call frame during OSR Entry code.
            // Here is how we would like to have the buffer configured:
            //
            // pivot[-4] = ArgumentCountIncludingThis
            // pivot[-3] = Callee
            // pivot[-2] = CodeBlock
            // pivot[-1] = CallerFrameAndReturnPC
            // pivot[0]  = csr1/csr0
            // pivot[1]  = csr3/csr2
            // ...
            ASSERT(sizeof(intptr_t) == 4);
            ASSERT(CallerFrameAndPC::sizeInRegisters == 1);
            ASSERT(currentEntry.offsetAsIndex() < 0);

            int offsetAsIndex = currentEntry.offsetAsIndex();
            int properIndex = offsetAsIndex % 2 ? offsetAsIndex - 1 : offsetAsIndex + 1;
            *(bitwise_cast<intptr_t*>(pivot - 1) + 1 - properIndex) = record->calleeSaveRegistersBuffer[calleeSavesEntry->offsetAsIndex()];
        }
    }
#endif

Once the buffer has been successfully populated, execution returns to the calling function operationOptimize.

void* targetPC = vm.getCTIStub(DFG::osrEntryThunkGenerator).code().executableAddress();
targetPC = retagCodePtr(targetPC, JITThunkPtrTag, bitwise_cast<PtrTag>(callFrame));
return encodeResult(targetPC, dataBuffer);

The value of targetPC points to the thunk code generated by DFG::osrEntryThunkGenerator. This is the thunk code that will parse the dataBuffer generated by the function prepareOSREntry and transfer execution control to the optimised machine code pointed to by that buffer. When compilation succeeds and execution return to the BaselineJIT, the BaselineJIT will jump to the thunk code generated and the thunk code will in turn jump to the machine code generated for the bytecode at which OSR Entry will occur.

Let’s now attempt to trace this in our debugger by optimising the function jitMe in the following JavaScript program and OSR entering into the optimised code:

function jitMe(x,y) {
    return x + y
}

let x = 1;

for (let y = 0; y < 1000; y++) {
    jitMe(x,y)
}

OSR Entry occurs at bc#0 and the optimised code generated for this CodeBlock at the bytecode boundary is listed below:

    Block #0 (bc#0): (OSR target)
      Execution count: 1.000000
      Predecessors:
      Successors:
      Dominated by: #root #0
      Dominates: #0
      Dominance Frontier: 
      Iterated Dominance Frontier: 
          0x7fffeecfe8f7: test $0x7, %bpl  <-- Machine code of bc#0 
          0x7fffeecfe8fb: jz 0x7fffeecfe908
          0x7fffeecfe901: mov $0xa, %r11d
          0x7fffeecfe907: int3 
          0x7fffeecfe908: mov $0xfffe000000000000, %r11
          0x7fffeecfe912: cmp %r11, %r14
          0x7fffeecfe915: jz 0x7fffeecfe923
          0x7fffeecfe91b: mov $0x82, %r11d
          //... truncated for brevity

In the screenshot below, the debugger is paused at the return statement in operationOptimize and one can inspect the values of targetPC and dataBuffer. Examining the contents of the memory address pointed to by dataBuffer and notice that the second double word value listed is the memory address of the optimised code for block #0 listed in the dump above.

Setting a breakpoint at the memory address listed in the buffer would allow pausing execution at the start of OSR Entry into the optimised code.

OSR Exit

Now let’s consider a scenario when a speculation check fails and it becomes necessary to bail out of the DFG optimised code back to the Baseline JIT or LLInt. First let’s look at how the checks are generated from the DFG and trace execution to compile the bailout code. Consider the following JavaScript program:

function jitMe(x,y) {
    return x + y
}

let x = 1;

for (let y = 0; y < 1000; y++) {
    jitMe(x,y)
}

// Trigger OSR Exit
jitMe("a", "b")

The function jitMe has been optimised to handle integer values for x and y. Supplying non-integer values to the function would could cause the speculation checks on x and y to fail and execution would bail out of the optimised code and run in a lower tier such as the Baseline JIT or the LLInt. Let’s now trace this bailout in our debugger. As we’ve seen in the [Code Generation section], the OSR Exits are implemented as a thunk which is added to the linkBuffer. When a speculation check fails, execution jumps to the OSR Exit thunk which is a trampoline to the function that initiates OSR Exit by reconstructing the callframe and emitting OSR Exit code to transfer execution to a lower tier.

There is a useful helper function that one can add to the target that will let the reader emit breakpoints from JavaScript source which will then be trap in our debugger¹. This will help with tracing OSR Exits as they occur.

diff --git a/Source/JavaScriptCore/jsc.cpp b/Source/JavaScriptCore/jsc.cpp
index 1226f84b461d..5f456766e3a8 100644
--- a/Source/JavaScriptCore/jsc.cpp
+++ b/Source/JavaScriptCore/jsc.cpp
@@ -261,6 +261,9 @@ static EncodedJSValue JSC_HOST_CALL functionIsHeapBigInt(JSGlobalObject*, CallFr
 static EncodedJSValue JSC_HOST_CALL functionPrintStdOut(JSGlobalObject*, CallFrame*);
 static EncodedJSValue JSC_HOST_CALL functionPrintStdErr(JSGlobalObject*, CallFrame*);
 static EncodedJSValue JSC_HOST_CALL functionDebug(JSGlobalObject*, CallFrame*);
+
+static EncodedJSValue JSC_HOST_CALL functionDbg(JSGlobalObject*, CallFrame*);
+
 static EncodedJSValue JSC_HOST_CALL functionDescribe(JSGlobalObject*, CallFrame*);
 static EncodedJSValue JSC_HOST_CALL functionDescribeArray(JSGlobalObject*, CallFrame*);
 static EncodedJSValue JSC_HOST_CALL functionSleepSeconds(JSGlobalObject*, CallFrame*);
@@ -488,6 +491,7 @@ private:
 
         addFunction(vm, "debug", functionDebug, 1);
         addFunction(vm, "describe", functionDescribe, 1);
+        addFunction(vm, "dbg", functionDbg, 0);
         addFunction(vm, "describeArray", functionDescribeArray, 1);
         addFunction(vm, "print", functionPrintStdOut, 1);
         addFunction(vm, "printErr", functionPrintStdErr, 1);
@@ -1277,6 +1281,12 @@ EncodedJSValue JSC_HOST_CALL functionDebug(JSGlobalObject* globalObject, CallFra
     return JSValue::encode(jsUndefined());
 }
 
+EncodedJSValue JSC_HOST_CALL functionDbg(JSGlobalObject* globalObject, CallFrame* callFrame)
+{
+    asm("int3");
+    return JSValue::encode(jsUndefined());
+}
+
 EncodedJSValue JSC_HOST_CALL functionDescribe(JSGlobalObject* globalObject, CallFrame* callFrame)
 {
     VM& vm = globalObject->vm();

By adding this helper function to jsc, one can invoke this from our test program to pause execution before our call jitMe that triggers the OSR Exit. The test program is updated to include a call to dbg as follows:

function jitMe(x,y) {
    return x + y
}

let x = 1;

for (let y = 0; y < 1000; y++) {
    jitMe(x,y)
}

dbg();

// Trigger OSR Exit
jitMe("a", "b")

The function dbg will now generate an interrupt that will be caught by our debugger before the OSR Exit is triggered when jitMe is called in the next JS instruction. Once the breakpoint is hit, the next step is to add another breakpoint at the start of the optimised code for jitMe. With disassembly dumps enabled, this should be easy to find:

Generated DFG JIT code for jitMe#Dsl1pz:[0x7fffae3c4260->0x7fffae3c4130->0x7fffae3e5100, DFGFunctionCall, 15], instructions size = 15:
    Optimized with execution counter = 1005.000000/1072.000000, 5
    Code at [0x7fffeecfe880, 0x7fffeecfee00):
          0x7fffeecfe880: push %rbp
          0x7fffeecfe881: mov %rsp, %rbp
          0x7fffeecfe884: mov $0x7fffae3c4260, %r11
          0x7fffeecfe88e: mov %r11, 0x10(%rbp)
          0x7fffeecfe892: lea -0x40(%rbp), %rsi

Setting a breakpoint at 0x7fffeecfe880 and stepping through the instructions the following instructions are encountered:

[Switching to thread 2 (Thread 0x7fffef6ed700 (LWP 20434))](running)
=thread-selected,id="2"
0x00007fffeecfe8e3 in ?? ()
-exec x/10i $rip
=> 0x7fffeecfe8e3:  cmp    QWORD PTR [rbp+0x30],r14
   0x7fffeecfe8e7:  jb     0x7fffeecfed5d
   0x7fffeecfe8ed:  cmp    QWORD PTR [rbp+0x38],r14
   0x7fffeecfe8f1:  jb     0x7fffeecfed84

At the memory address pointed to by rbp+0x30 is the value of the first parameter passed to jitMe and at rbp+0x38 lies the second parameter. r14 contains the value 0xfffe000000000000 which is the encoding used for Integer values in JSC. The cmp operations in the snippet above compare the values on the stack (speculated to be integers) with the integer encoding tag. If the values on the stack are less than the value in r14 the jumps to 0x7fffeecfed5d if speculation on the first parameter fails or 0x7fffeecfed5d if speculation on the second parameter fails.

-exec x/4i $rip
=> 0x7fffeecfe8e3:  cmp    QWORD PTR [rbp+0x30],r14
   0x7fffeecfe8e7:  jb     0x7fffeecfed5d
   0x7fffeecfe8ed:  cmp    QWORD PTR [rbp+0x38],r14
   0x7fffeecfe8f1:  jb     0x7fffeecfed84

-exec x/gx $rbp+0x30
0x7fffffffca10: 0x00007fffae3fc5a0

-exec p/x $r14
$2 = 0xfffe000000000000

Execution continues up taking the jump 0x7fffeecfed5d which is a trampoline to the OSRExit thunk at 0x0x7fffaecffc20:

0x00007fffeecfed5d in ?? ()
-exec x/10i $rip
=> 0x7fffeecfed5d:  test   bpl,0x7

//... truncated for brevity

   0x7fffeecfed78:  mov    DWORD PTR [r11],0x0
   0x7fffeecfed7f:  jmp    0x7fffaecffc20

The OSRExit thunk ends up calling operationCompileOSRExit which begins the process of compiling an OSR Exit:

void JIT_OPERATION operationCompileOSRExit(CallFrame* callFrame)
{
    //... truncated for brevity

    uint32_t exitIndex = vm.osrExitIndex;
    OSRExit& exit = codeBlock->jitCode()->dfg()->osrExit[exitIndex];

   //... truncated for brevity
    
    // Compute the value recoveries.
    Operands<ValueRecovery> operands;
    codeBlock->jitCode()->dfg()->variableEventStream.reconstruct(codeBlock, exit.m_codeOrigin, codeBlock->jitCode()->dfg()->minifiedDFG, exit.m_streamIndex, operands);

    SpeculationRecovery* recovery = nullptr;
    if (exit.m_recoveryIndex != UINT_MAX)
        recovery = &codeBlock->jitCode()->dfg()->speculationRecovery[exit.m_recoveryIndex];

    {
        CCallHelpers jit(codeBlock);

        //... truncated for brevity

        jit.addPtr(
            CCallHelpers::TrustedImm32(codeBlock->stackPointerOffset() * sizeof(Register)),
            GPRInfo::callFrameRegister, CCallHelpers::stackPointerRegister);

        //... truncated for brevity

        OSRExit::compileExit(jit, vm, exit, operands, recovery);

        LinkBuffer patchBuffer(jit, codeBlock);
        exit.m_code = FINALIZE_CODE_IF(
            shouldDumpDisassembly() || Options::verboseOSR() || Options::verboseDFGOSRExit(),
            patchBuffer, OSRExitPtrTag,
            "DFG OSR exit #%u (D@%u, %s, %s) from %s, with operands = %s",
                exitIndex, exit.m_dfgNodeIndex, toCString(exit.m_codeOrigin).data(),
                exitKindToString(exit.m_kind), toCString(*codeBlock).data(),
                toCString(ignoringContext<DumpContext>(operands)).data());
    }

    MacroAssembler::repatchJump(exit.codeLocationForRepatch(), CodeLocationLabel<OSRExitPtrTag>(exit.m_code.code()));

    vm.osrExitJumpDestination = exit.m_code.code().executableAddress();
}

This function performs three main actions:

It recovers register/operand values to reconstruct the call frame for the Baseline JIT.
Generates machine code for the OSR Exit.
Sets a OSR Exit jump destination, which is the start of the machine code generated in #2.

One can add the --verboseDFGOSRExit=true flag to launch.json or the command line would print the generated OSR Exit code to stdout:

Generated JIT code for DFG OSR exit #0 (D@0, bc#0, BadType) from jitMe#Dsl1pz:[0x7fffae3c4260->0x7fffae3c4130->0x7fffae3e5100, DFGFunctionCall, 15 (DidTryToEnterInLoop)], with operands = arg2:*arg2 arg1:*arg1 arg0:*this loc0:*loc0 loc1:*loc1 loc2:*loc2 loc3:*loc3 loc4:*loc4 loc5:*loc5 loc6:*loc6 loc7:*loc7:
    Code at [0x7fffeecfe3a0, 0x7fffeecfe880):
      0x7fffeecfe3a0: lea -0x40(%rbp), %rsp
      0x7fffeecfe3a4: test $0x7, %bpl
      0x7fffeecfe3a8: jz 0x7fffeecfe3b5
      0x7fffeecfe3ae: mov $0xa, %r11d
      0x7fffeecfe3b4: int3 
      0x7fffeecfe3b5: mov $0x7fffeedfac28, %r11
      0x7fffeecfe3bf: inc (%r11)
      0x7fffeecfe3c2: mov $0xfffe000000000000, %r11
      0x7fffeecfe3cc: cmp %r11, %r14
      0x7fffeecfe3cf: jz 0x7fffeecfe3dd
      //... truncated for brevity

Execution now jumps to 0x7fffeecfe3a0 which is the start of the JIT code for OSR Exit at the end of which execution of the function call completes in the Baseline JIT. A useful JSC command line flag to that let’s trace OSR Exits is --printEachOSRExit. Adding this flag prints details of each OSR Exit that occurs from optimised code. An example of this from the test script above is shown below:

Speculation failure in jitMe#Dsl1pz:[0x7fffae3c4260->0x7fffae3c4130->0x7fffae3e5100, DFGFunctionCall, 15 (DidTryToEnterInLoop)] @ exit #0 (bc#0, BadType) with executeCounter = 0.000000/1072.000000, -1000, reoptimizationRetryCounter = 0, optimizationDelayCounter = 0, osrExitCounter = 0
    GPRs at time of exit: rax:0x7fffeecfe880 rsi:0x7fffffffc9a0 rdx:(nil) rcx:0x4 r8:(nil) r10:0x7ffff5e1d32b rdi:0x7fffffffc970 r9:0x7fffffffc9f0 rbx:0xeeda7a00 r12:0x7fffeeda0250 r13:0x7fffeedabe10
    FPRs at time of exit: xmm0:41d800b5832e41dd:1610798604.722770 xmm1:41d800b583000000:1610798604.000000 xmm2:412e848000000000:1000000.000000 xmm3:3630633030646561:0.000000 xmm4:2020202020202020:0.000000 xmm5:3365616666663778:0.000000

The snippet above indicates the reason for OSR Exit (in this case BadType), the bytecode at which the OSR Exit occurred (exit at #0 to bc#0) and the number of times this OSR Exit has occurred from this codeblock (indicated by the counter osrExitCounter). If the osrExitCounter exceed a certain value, the optimised code is jettisoned and future calls to the function are directed to the Baseline JIT and in some cases to the LLInt. The next section will explore how jettison occurs and how this affects recompilation.

Jettison and Recompilation

With each OSR Exit from an optimised CodeBlock, the OSR Exit counter for that CodeBlock is incremented. Once a threshold on number of exits has been breached, the optimized code is jettisoned and all future calls to the CodeBlock are executed in the Baseline JIT or the LLInt. When a function is jettisoned, the optimised code is discarded and a recompilation counter is incremented. In addition, the threshold values to tier up into the DFG from the Baseline JIT are now updated to a much larger value to allow bytecodes to execute longer in the lower tier which in turn allows the lower tier to gather more accurate profiling data before optimising the function again.

Let’s examine this by updating our test script as shown below:

function jitMe(x,y) {
    return x + y
}

let x = 1;

// Optimise jitMe using DFG
for (let y = 0; y < 1000; y++) {
    jitMe(x,y)
}


// Trigger OSR Exits
for(let y = 0; y < 100; y++){
    jitMe("a","b")
}

// Trigger jettison
jitMe("a","b")

The program above first optimises jitMe using the DFG, which is optimised to handle integer values. It then triggers several OSR Exits by supplying string values to jitMe instead of integers. This increments the OSR Exit counter but not enough to cause jettison. The final call to jitMe triggers OSR Exit and jettison. To understand how this is constructed one needs to revisit OSRExit::compileExit which is invoked when compiling the OSR Exit code that we’ve seen in th previous section. Within the function compileExit is a call to handleExitCounts which as the name suggests is responsible for counting OSR exits and triggering reoptimisation. The function handleExitCounts is defined in dfg/DFGOSRExitCompilerCommon.cpp and a truncated version of this function is listed below:

void handleExitCounts(VM& vm, CCallHelpers& jit, const OSRExitBase& exit)
{
    //... truncated for brevity
    
    jit.load32(AssemblyHelpers::Address(GPRInfo::regT3, CodeBlock::offsetOfOSRExitCounter()), GPRInfo::regT2);
    jit.add32(AssemblyHelpers::TrustedImm32(1), GPRInfo::regT2);
    jit.store32(GPRInfo::regT2, AssemblyHelpers::Address(GPRInfo::regT3, CodeBlock::offsetOfOSRExitCounter()));
    
    //... truncated for brevity

    jit.move(
        AssemblyHelpers::TrustedImm32(jit.codeBlock()->exitCountThresholdForReoptimization()),
        GPRInfo::regT1);

    //... truncated for brevity

    tooFewFails = jit.branch32(AssemblyHelpers::BelowOrEqual, GPRInfo::regT2, GPRInfo::regT1);
    
    //... truncated for brevity

    jit.setupArguments<decltype(operationTriggerReoptimizationNow)>(GPRInfo::regT0, GPRInfo::regT3, AssemblyHelpers::TrustedImmPtr(&exit));
    jit.prepareCallOperation(vm);
    jit.move(AssemblyHelpers::TrustedImmPtr(tagCFunction<OperationPtrTag>(operationTriggerReoptimizationNow)), GPRInfo::nonArgGPR0);
    jit.call(GPRInfo::nonArgGPR0, OperationPtrTag);
    AssemblyHelpers::Jump doneAdjusting = jit.jump();
    
    tooFewFails.link(&jit);
    
    // Adjust the execution counter such that the target is to only optimize after a while.
    //... truncated for brevity 
}

In the snippet above, the function begins by emitting code that first gets a reference to the osrExitCounter for the CodeBlock and increments it by one which is stored in a temporary register regT2. Next the value of the exit count threshold for reoptimisation is then stored to a temporary register regT1. A branching instruction is emitted which checks if the OSR exit count for the CodeBlock is greater than that of the threshold count, then calls the JIT operation operationTriggerReoptimizationNow. Let’s now run the test script in our debugger and set a breakpoint at triggerReoptimizationNow which is invoked by operationTriggerReoptimizationNow:

void triggerReoptimizationNow(CodeBlock* codeBlock, CodeBlock* optimizedCodeBlock, OSRExitBase* exit)
{
    //... truncated for brevity

    // In order to trigger reoptimization, one of two things must have happened:
    // 1) We exited more than some number of times.
    // 2) We exited and got stuck in a loop, and now we're exiting again.
    bool didExitABunch = optimizedCodeBlock->shouldReoptimizeNow();
    bool didGetStuckInLoop =
        (codeBlock->checkIfOptimizationThresholdReached() || didTryToEnterIntoInlinedLoops)
        && optimizedCodeBlock->shouldReoptimizeFromLoopNow();
    
    if (!didExitABunch && !didGetStuckInLoop) {
        dataLogLnIf(Options::verboseOSR(), *codeBlock, ": Not reoptimizing ", *optimizedCodeBlock, " because it either didn't exit enough or didn't loop enough after exit.");
        codeBlock->optimizeAfterLongWarmUp();
        return;
    }
    
    optimizedCodeBlock->jettison(Profiler::JettisonDueToOSRExit, CountReoptimization);
}

If the two conditions listed above (i.e. several OSR Exits and getting stuck in a loop), the optimised code is jettisoned with the call to CodeBlock::jettison:

void CodeBlock::jettison(Profiler::JettisonReason reason, ReoptimizationMode mode, const FireDetail* detail)
{

    //... code truncated for brevity
    
    // We want to accomplish two things here:
    // 1) Make sure that if this CodeBlock is on the stack right now, then if we return to it
    //    we should OSR exit at the top of the next bytecode instruction after the return.
    // 2) Make sure that if we call the owner executable, then we shouldn't call this CodeBlock.

#if ENABLE(DFG_JIT)
    if (JITCode::isOptimizingJIT(jitType()))
        jitCode()->dfgCommon()->clearWatchpoints();
    
    if (reason != Profiler::JettisonDueToOldAge) {
        Profiler::Compilation* compilation = jitCode()->dfgCommon()->compilation.get();
        if (UNLIKELY(compilation))
            compilation->setJettisonReason(reason, detail);
        
        // This accomplishes (1), and does its own book-keeping about whether it has already happened.
        if (!jitCode()->dfgCommon()->invalidate()) {
            // We've already been invalidated.
            RELEASE_ASSERT(this != replacement() || (vm.heap.isCurrentThreadBusy() && !vm.heap.isMarked(ownerExecutable())));
            return;
        }
    }
    
    //... truncated for brevity
    
    if (this != replacement()) {
        // This means that we were never the entrypoint. This can happen for OSR entry code
        // blocks.
        return;
    }

    if (alternative())
        alternative()->optimizeAfterWarmUp();

    //... code truncated for brevity

    // This accomplishes (2).
    ownerExecutable()->installCode(vm, alternative(), codeType(), specializationKind());
}

The function first determines the reason for jettison (in this is case it’s due to OSR Exits) and then invalidates the optimised code generated by the DFG. It ensures that the CodeBlock is on the stack and finally calls installCode to install the Baseline JIT code. Enabling the flags dumpDFGDisassembly and verboseOSR on the command line prints information on the reason for jettison and tier code that future function calls will execute:

jitMe#Dsl1pz:[0x7fffae3c4130->0x7fffae3e5100, BaselineFunctionCall, 15 (DidTryToEnterInLoop) (FTLFail)]: Entered reoptimize
Jettisoning jitMe#Dsl1pz:[0x7fffae3c4260->0x7fffae3c4130->0x7fffae3e5100, DFGFunctionCall, 15 (DidTryToEnterInLoop)] and counting reoptimization due to OSRExit.
    Did invalidate jitMe#Dsl1pz:[0x7fffae3c4260->0x7fffae3c4130->0x7fffae3e5100, DFGFunctionCall, 15 (DidTryToEnterInLoop)]
    Did count reoptimization for jitMe#Dsl1pz:[0x7fffae3c4260->0x7fffae3c4130->0x7fffae3e5100, DFGFunctionCall, 15 (DidTryToEnterInLoop)]
jitMe#Dsl1pz:[0x7fffae3c4130->0x7fffae3e5100, BaselineFunctionCall, 15 (DidTryToEnterInLoop) (FTLFail)]: Optimizing after warm-up.
jitMe#Dsl1pz:[0x7fffae3c4130->0x7fffae3e5100, BaselineFunctionCall, 15 (DidTryToEnterInLoop) (FTLFail)]: bytecode cost is 15.000000, scaling execution counter by 1.072115 * 1
Installing jitMe#Dsl1pz:[0x7fffae3c4130->0x7fffae3e5100, BaselineFunctionCall, 15 (DidTryToEnterInLoop) (FTLFail)]
    Did install baseline version of jitMe#Dsl1pz:[0x7fffae3c4260->0x7fffae3c4130->0x7fffae3e5100, DFGFunctionCall, 15 (DidTryToEnterInLoop)]

Once jettisoned, the bytecode will continue to run in the Baseline JIT until it tiers-up again into the DFG. The tier-up mechanism is similar to what we’ve discussed at the start of this blog post. The main difference however is the updated tier-up threshold counts that need to be reached in order to trigger re-optimisation.

Conclusion

This post explored the components that make up the DFG JIT tier in JavaScriptCore by understanding how the optimised graph is lowered to optimised machine code. The post also covered how execution transitions from the Baseline JIT to the DFG via OSR Entry and transitions from the DFG to a lower tier via OSR Exits which are causes due to failing speculation checks. This concludes our discussion on the DFG JIT.

Part VI of this blog series will dive into the details of the FTL (Faster Than Light) JIT engine the final execution tier in JavaScriptCore. The post will explore how the DFG tiers-up into the FTL, how the DFG IR is further optimised by this tier and transformed to additional FTL specific IRs, some of the key optimisation phases of the FTL and finally OSR Entry and Exit to and from this final tier.

As always, thank you for reading and if you have questions do reach out to the author @amarekano or @Zon8Research on Twitter. We would appriciate your feedback.

Appendix

https://doar-e.github.io/blog/2018/07/14/cve-2017-2446-or-jscjsglobalobjectishavingabadtime/#target-modifications ↩︎

JavaScriptCore Internals Part II: The LLInt and Baseline JIT

Thu, 31 Dec 2020 00:00:00 +0000

Introduction

Historically, the LLInt and Baseline JIT haven’t been the source for may publicly disclosed security related bugs in JavaScriptCore but there are a few reasons why it felt necessary to dedicate an entire post solely to the LLInt and Baseline JIT. The main goal of this post and the blog series is to help researchers navigate the code base and to help speed up the analysis process when triaging bugs/crashes. Understanding how the LLInt and Baseline JIT work and the various components that aid in the functioning of these two tier will help speed up this analysis by helping one finding their bearings within the code base and narrowing the search space being able to skip over components that don’t impact the bug/crash. The second reason to review these two tiers is to gain an appreciation for how code generation and execution flow is achieved for unoptimised bytecode. The design principles used by the LLInt and Baseline JIT are shared across the higher tiers and gaining an understanding of these principles makes for a gentle learning curve when exploring the DFG and FTL.

Part I of this blog series traced the journey from source code to bytecode and concluded by briefly discussing how bytecodes are passed to the LLInt and how the LLInt initiates execution. This post dives into the details on how bytecode is executed in the LLInt and how the Baseline JIT is invoked to optimise the bytecode. These are the first two tiers in JavaScriptCore and the stages of the execution pipeline that will be explored are shown in the slide¹ reproduced below:

This blog post begins by exploring how the LLInt is constructed using a custom assembly called offlineasm and how one can debug and trace bytecode execution in this custom assembly. It also covers the working of the Baseline JIT and demonstrates how the LLInt determines when bytecode being executed is hot code and should be compiled and executed by the Baseline JIT. The LLInt and Baseline JIT are considered as profiling tiers and this post concludes with a quick introduction on the various profiling sources that the two tiers use. Part III dives into the internals of the Data Flow Graph (DFG) and how bytecode is optimised and generated by this JIT compiler.

Existing Work

In addition to the resources mentioned in Part I, there are a couple of resources from that discuss several aspects of JavaScript code optimisation techniques, some of which will be covered in this post and posts that will follow.

The WebKit blog: Speculation in JavaScriptCore is a magnum opus by Filip Pizlo that goes into the great detail of how speculative compilation is performed in JavaScriptCore and is a fantastic complementary resource to this blog series. The key areas that the WebKit blog discusses which will be relevant to our discussion here are the sections on Control and Profiling.

Another useful resource that will come in handy as you debug and trace the LLInt and Baseline JIT is the WebKit blog JavaScriptCore CSI: A Crash Site Investigation Story. This is also a good resource to get you started with debugging WebKit/JavaScriptCore crashes.

LLInt

This section beings by introducing the LLInt and the custom assembly that is used to construct the LLInt. The LLInt was first introduced in WebKit back in 2012 with the following revision. The revision comment below states the intent of why the LLInt was introduced.

Implemented an interpreter that uses the JIT’s calling convention. This interpreter is called LLInt, or the Low Level Interpreter. JSC will now will start by executing code in LLInt and will only tier up to the old JIT after the code is proven hot.

LLInt is written in a modified form of our macro assembly. This new macro assembly is compiled by an offline assembler (see offlineasm), which implements many modern conveniences such as a Turing-complete CPS-based macro language and direct access to relevant C++ type information (basically offsets of fields and sizes of structs/classes).

Code executing in LLInt appears to the rest of the JSC world “as if” it were executing in the old JIT. Hence, things like exception handling and cross-execution-engine calls just work and require pretty much no additional overhead.

Essentially the LLInt loops over bytecodes and executes each bytecode based on what it’s supposed to do and then moves onto the next bytecode instruction. In addition to bytecode execution, it also gathers profiling information about the bytecodes being executed and maintains counters that measure how often code was executed. Both these parameters (i.e. profiling data and execution counts) are crucial in aiding code optimisation and tiering up to the various JIT tiers via a technique called OSR (On Stack Replacement). The screenshot² below describes the Four JIT tiers and profiling data and OSRs propagate through the engine.

The source code to the LLInt is located at JavaScriptCore/llint and the starting point to this post’s investigation will be the LLIntEntrypoint.h which is also the first instance where the LLInt was first encountered in Part I.

Recap

Lets pick up from where Part I left off in Interpreter::executeProgram.

CodeBlock* tempCodeBlock;
Exception* error = program->prepareForExecution<ProgramExecutable>(vm, nullptr, scope, CodeForCall, tempCodeBlock);

The pointer to the program object which has a reference to the CodeBlock that now contains linked bytecode. The call to prepareForExecution through a series of calls ends up calling setProgramEntrypoint(CodeBlock* codeBlock). This function as the name suggests is responsible for setting up the entry point into the LLInt to being executing bytecode. The call stack at this point should look similar to the one below:

libJavaScriptCore.so.1!JSC::LLInt::setProgramEntrypoint(JSC::CodeBlock * codeBlock) (/home/amar/workspace/WebKit/Source/JavaScriptCore/llint/LLIntEntrypoint.cpp:112)
libJavaScriptCore.so.1!JSC::LLInt::setEntrypoint(JSC::CodeBlock * codeBlock) (/home/amar/workspace/WebKit/Source/JavaScriptCore/llint/LLIntEntrypoint.cpp:161)
libJavaScriptCore.so.1!JSC::setupLLInt(JSC::CodeBlock * codeBlock) (/home/amar/workspace/WebKit/Source/JavaScriptCore/runtime/ScriptExecutable.cpp:395)
libJavaScriptCore.so.1!JSC::ScriptExecutable::prepareForExecutionImpl(JSC::ScriptExecutable * const this, JSC::VM & vm, JSC::JSFunction * function, JSC::JSScope * scope, JSC::CodeSpecializationKind kind, JSC::CodeBlock *& resultCodeBlock) (/home/amar/workspace/WebKit/Source/JavaScriptCore/runtime/ScriptExecutable.cpp:432)
libJavaScriptCore.so.1!JSC::ScriptExecutable::prepareForExecution<JSC::ProgramExecutable>(JSC::ScriptExecutable * const this, JSC::VM & vm, JSC::JSFunction * function, JSC::JSScope * scope, JSC::CodeSpecializationKind kind, JSC::CodeBlock *& resultCodeBlock) (/home/amar/workspace/WebKit/Source/JavaScriptCore/bytecode/CodeBlock.h:1086)
libJavaScriptCore.so.1!JSC::Interpreter::executeProgram(JSC::Interpreter * const this, const JSC::SourceCode & source, JSC::JSObject * thisObj) (/home/amar/workspace/WebKit/Source/JavaScriptCore/interpreter/Interpreter.cpp:816)
...

Within the function setProgramEntrypoint exists a call to getCodeRef which attempts to get a reference pointer to the executable address for opcode llint_program_prologue. This this reference pointer is where the interpreter (LLInt) beings execution for the CodeBlock.

ALWAYS_INLINE MacroAssemblerCodeRef<tag> getCodeRef(OpcodeID opcodeID)
{
    return MacroAssemblerCodeRef<tag>::createSelfManagedCodeRef(getCodePtr<tag>(opcodeID));
}

Once a reference pointer to llint_program_prologue has been retrieved, a NativeJITCode object is created which stores this code pointer and then initialises the codeBlock with a reference to the NativeJITCode object.

std::call_once(onceKey, [&] {
        jitCode = new NativeJITCode(getCodeRef<JSEntryPtrTag>(llint_program_prologue), JITType::InterpreterThunk, Intrinsic::NoIntrinsic, JITCode::ShareAttribute::Shared);
    });
codeBlock->setJITCode(makeRef(*jitCode));

Finally, the linked bytecode is ready to execute with a call to JITCode::execute. The function is as follows:

ALWAYS_INLINE JSValue JITCode::execute(VM* vm, ProtoCallFrame* protoCallFrame)
{
    //... code truncated for brevity

    void* entryAddress;
    entryAddress = addressForCall(MustCheckArity).executableAddress();
    JSValue result = JSValue::decode(vmEntryToJavaScript(entryAddress, vm, protoCallFrame));
    return scope.exception() ? jsNull() : result;
}

The key function in the snippet above is vmEntryToJavaScript which is a thunk defined in the LowLevelInterpreter.asm. The WebKit blog JavaScriptCore CSI: A Crash Site Investigation Story describes the thunk as follows:

vmEntryToJavaScript is implemented in LLInt assembly using the doVMEntry macro (see LowLevelInterpreter.asm and LowLevelInterpreter64.asm). The JavaScript VM enters all LLInt or JIT code via doVMEntry, and it will exit either via the end of doVMEntry (for normal returns), or via _handleUncaughtException (for exits due to uncaught exceptions).

At this point, execution transfers to the LLInt which now has a reference to the CodeBlock and entryAddress to begin execution from.

Implementation

Before proceeding any further into the details of vmEntryToJavaScript and doVMEntry, it will be worth the readers time to understand the custom assembly that the LLInt is written in. The LLInt is generated using what is referred to as offlineasm assembly. offlineasm is written in Ruby and can be found under JavaScriptCore/offlineasm. The LLInt itself is defined in LowLevelInterpreter.asm and LowLevelInterpreter64.asm.

The machine code generated that forms part of the LLInt is located in LLIntAssembly.h which can be found under the /WebKitBuild/Debug/DerivedSources/JavaScriptCore/ directory. This header file is generated at compile time by invoking offlineasm/asm.rb. This build step is listed in JavaSctipCore/CMakeLists.txt:

# The build system will execute asm.rb every time LLIntOffsetsExtractor's mtime is newer than
# LLIntAssembly.h's mtime. The problem we have here is: asm.rb has some built-in optimization
# that generates a checksum of the LLIntOffsetsExtractor binary, if the checksum of the new
# LLIntOffsetsExtractor matches, no output is generated. To make this target consistent and avoid
# running this command for every build, we artificially update LLIntAssembly.h's mtime (using touch)
# after every asm.rb run.
if (MSVC AND NOT ENABLE_C_LOOP)
    #... truncated for brevity
else ()
    set(LLIntOutput LLIntAssembly.h)
endif ()

add_custom_command(
    OUTPUT ${JavaScriptCore_DERIVED_SOURCES_DIR}/${LLIntOutput}
    MAIN_DEPENDENCY ${JSCCORE_DIR}/offlineasm/asm.rb
    DEPENDS LLIntOffsetsExtractor ${LLINT_ASM} ${OFFLINE_ASM} ${JavaScriptCore_DERIVED_SOURCES_DIR}/InitBytecodes.asm ${JavaScriptCore_DERIVED_SOURCES_DIR}/InitWasm.asm
    COMMAND ${CMAKE_COMMAND} -E env CMAKE_CXX_COMPILER_ID=${CMAKE_CXX_COMPILER_ID} GCC_OFFLINEASM_SOURCE_MAP=${GCC_OFFLINEASM_SOURCE_MAP} ${RUBY_EXECUTABLE} ${JAVASCRIPTCORE_DIR}/offlineasm/asm.rb -I${JavaScriptCore_DERIVED_SOURCES_DIR}/ ${JAVASCRIPTCORE_DIR}/llint/LowLevelInterpreter.asm $<TARGET_FILE:LLIntOffsetsExtractor> ${JavaScriptCore_DERIVED_SOURCES_DIR}/${LLIntOutput} ${OFFLINE_ASM_ARGS}
    COMMAND ${CMAKE_COMMAND} -E touch_nocreate ${JavaScriptCore_DERIVED_SOURCES_DIR}/${LLIntOutput}
    WORKING_DIRECTORY ${JavaScriptCore_DERIVED_SOURCES_DIR}
    VERBATIM)

# The explanation for not making LLIntAssembly.h part of the OBJECT_DEPENDS property of some of
# the .cpp files below is similar to the one in the previous comment. However, since these .cpp
# files are used to build JavaScriptCore itself, we can just add LLIntAssembly.h to JavaScript_HEADERS
# since it is used in the add_library() call at the end of this file.
if (MSVC AND NOT ENABLE_C_LOOP)
    #... truncated for brevity
else ()
    # As there's poor toolchain support for using `.file` directives in
    # inline asm (i.e. there's no way to avoid clashes with the `.file`
    # directives generated by the C code in the compilation unit), we
    # introduce a postprocessing pass for the asm that gets assembled into
    # an object file. We only need to do this for LowLevelInterpreter.cpp
    # and cmake doesn't allow us to introduce a compiler wrapper for a
    # single source file, so we need to create a separate target for it.
    add_library(LowLevelInterpreterLib OBJECT llint/LowLevelInterpreter.cpp
        ${JavaScriptCore_DERIVED_SOURCES_DIR}/${LLIntOutput})
endif ()

As the snippet above indicates, this generated header file is included in llint/LowLeveInterpreter.cpp which embeds the interpreter into JavaScriptCore.

// This works around a bug in GDB where, if the compilation unit
// doesn't have any address range information, its line table won't
// even be consulted. Emit {before,after}_llint_asm so that the code
// emitted in the top level inline asm statement is within functions
// visible to the compiler. This way, GDB can resolve a PC in the
// llint asm code to this compilation unit and the successfully look
// up the line number information.
DEBUGGER_ANNOTATION_MARKER(before_llint_asm)

// This is a file generated by offlineasm, which contains all of the assembly code
// for the interpreter, as compiled from LowLevelInterpreter.asm.
#include "LLIntAssembly.h"

DEBUGGER_ANNOTATION_MARKER(after_llint_asm)

The offlineasm compilation at a high-level functions as follows:

asm.rb is invoked by supplying LowLevelInterpreter.asm and a target backend (i.e. cpu architecture) as input.
The .asm files are lexed and parsed by the offlineasm parser defined in parser.rb
Successful parsing generates an Abstract Syntax Tree (AST), the schema for which is defined in ast.rb
The generated AST is then transformed (see tranform.rb) before it is lowered to the target backend.
The nodes of the transformed AST are then traversed and machine code is emitted for each node. The machine code to be emitted for the different target backends is defined in its own ruby file. For example, the machine code for x86 is defined in x86.rb.
The machine code emitted for the target backend is written to LLIntAssembly.h

This process of offlineasm compilation is very similar to the way JavaScriptCore generates bytecodes from supplied javascript source code. In this case however, the machine code is generated from the offlineasm assembly. A list of all offlineasm instruction and registers can be found in instructions.rb and registers.rb respectively. offlineasm supports multiple cpu architectures and these are referred to as backends. The various supported backends are listed in backends.rb.

The reader may be wondering why the LLInt is written in offlineasm rather than C/C++, which is what pretty much the rest of the engine is written in. A good discussion on this matter can be found in the How Profiled Execution Works section of the WebKit blogpost³ and explains the trade offs between using a custom assembly vs C/C++. The blog also describes two key features of offlineasm:

Portable assembly with our own mnemonics and register names that match the way we do portable assembly in our JIT. Some high-level mnemonics require lowering. Offlineasm reserves some scratch registers to use for lowering.

The macro construct. It’s best to think of this as a lambda that takes some arguments and returns void. Then think of the portable assembly statements as print statements that output that assembly. So, the macros are executed for effect and that effect is to produce an assembly program. These are the execution semantics of offlineasm at compile time.

Offlineasm

At this point the reader should now know how the LLInt is implemented and where to find the machine code that’s generated for it. This section discuses the language itself and how to go about reading it. The developer comments at the start of the LowLevelInterpreter.asm provide an introduction to the language and its definitely worth reading. This section will highlight the various constructs of the offlineasm language and provide examples from the codebase.

Macros

Most instructions are grouped as macros, which according to the developer comments are lambda expressions.

A “macro” is a lambda expression, which may be either anonymous or named. But this has caveats. “macro” can take zero or more arguments, which may be macros or any valid operands, but it can only return code. But you can do Turing-complete things via continuation passing style: “macro foo (a, b) b(a, a) end foo(foo, foo)”. Actually, don’t do that, since you’ll just crash the assembler.

The following snippet is an example of the dispatch macro.

macro dispatch(advanceReg)
    addp advanceReg, PC
    nextInstruction()
end

The macro above takes one argument, which in this case is the advanceReg. The macro body contains two instructions, the first is a call of the addp instruction which takes two operands advanceReg and PC. The second is a call to the macro nextInstruction().

Another important aspect to consider about macros is the scoping of arguments. The developer comments has the following to say on this matter:

Arguments to macros follow lexical scoping rather than dynamic scoping. Const’s also follow lexical scoping and may override (hide) arguments or other consts. All variables (arguments and constants) can be bound to operands. Additionally, arguments (but not constants) can be bound to macros.

Macros are not always labeled and can exist as anonymous macros. The snippet below is an example of an anonymous macro being used in llint_program_prologue which is the glue code that allows the LLInt to find the entrypoint to the linked bytecode in the supplied code block:

op(llint_program_prologue, macro ()
    prologue(notFunctionCodeBlockGetter, notFunctionCodeBlockSetter, _llint_entry_osr, _llint_trace_prologue)
    dispatch(0)
end)

Instructions

The instructions in offlineasm generally follow GNU Assembler syntax. The developer comments for instructions are as follows:

Mostly gas-style operand ordering. The last operand tends to be the destination. So “a := b” is written as “mov b, a”. But unlike gas, comparisons are in-order, so “if (a < b)” is written as “bilt a, b, …”.

In the snippet below, the move instruction takes two operands lr and destinationRegister. The value in lr is moved to destinationRegister

move lr, destinationRegister

Some instructions will also contain postfixes which provide additional information on the behaviour of the instruction. The various postfixes that can be added to instructions are documented in the developer comment below:

“b” = byte, “h” = 16-bit word, “i” = 32-bit word, “p” = pointer. For 32-bit, “i” and “p” are interchangeable except when an op supports one but not the other.

In the snippet below, the instruction add which is postfixed with p, indicating this is a pointer addition operation where the value of advanceReg is added to PC.

macro dispatch(advanceReg)
    addp advanceReg, PC
    nextInstruction()
end

Operands

Instructions take one or more operands. A note on operands for instructions and macros from the developer comments is as follows:

In general, valid operands for macro invocations and instructions are registers (eg “t0”), addresses (eg “4[t0]”), base-index addresses (eg “7[t0, t1, 2]”), absolute addresses (eg “0xa0000000[]”), or labels (eg “_foo” or “.foo”). Macro invocations can also take anonymous macros as operands. Instructions cannot take anonymous macros.

The following snippet, shows some of the various operand types in use (i.e. registers, addresses, base-index addresses and labels):

.copyLoop:
    if ARM64 and not ADDRESS64
        subi MachineRegisterSize, temp2
        loadq [sp, temp2, 1], temp3
        storeq temp3, [temp1, temp2, 1]
        btinz temp2, .copyLoop
    else
        subi PtrSize, temp2
        loadp [sp, temp2, 1], temp3
        storep temp3, [temp1, temp2, 1]
        btinz temp2, .copyLoop
    end

    move temp1, sp
    jmp callee, callPtrTag
end

Registers

Some notes on the various registers in use by offlineasm, these have been reproduced from the developer comments.

cfr and sp hold the call frame and (native) stack pointer respectively. They are callee-save registers, and guaranteed to be distinct from all other registers on all architectures.

t0, t1, t2, t3, t4, and optionally t5, t6, and t7 are temporary registers that can get trashed on calls, and are pairwise distinct registers. t4 holds the JS program counter, so use with caution in opcodes (actually, don’t use it in opcodes at all, except as PC).

r0 and r1 are the platform’s customary return registers, and thus are two distinct registers

a0, a1, a2 and a3 are the platform’s customary argument registers, and thus are pairwise distinct registers. Be mindful that:

On X86, there are no argument registers. a0 and a1 are edx and ecx following the fastcall convention, but you should still use the stack to pass your arguments. The cCall2 and cCall4 macros do this for you.

There are additional assumptions and platform specific details about some of these registers that the reader is welcome to explore.

Labels

Labels are much like goto statements in C/C++ and the developer notes on labels has the following to say:

Labels must have names that begin with either “” or “.”. A “.” label is local and gets renamed before code gen to minimize namespace pollution. A “” label is an extern symbol (i.e. “.globl”). The “” may or may not be removed during code gen depending on whether the asm conventions for C name mangling on the target platform mandate a “” prefix.

The snippet below shows an examples of local labels (i.e. .afterHandlingTraps, .handleTraps, etc) in use:

llintOp(op_check_traps, OpCheckTraps, macro (unused, unused, dispatch)
    loadp CodeBlock[cfr], t1
    loadp CodeBlock::m_vm[t1], t1
    loadb VM::m_traps+VMTraps::m_needTrapHandling[t1], t0
    btpnz t0, .handleTraps
.afterHandlingTraps:
    dispatch()
.handleTraps:
    callTrapHandler(.throwHandler)
    jmp .afterHandlingTraps
.throwHandler:
    jmp _llint_throw_from_slow_path_trampoline
end)

An example of global labels (i.e. “_” labels) is shown in the snippet below:

if C_LOOP or C_LOOP_WIN
    _llint_vm_entry_to_javascript:
else
    global _vmEntryToJavaScript
    _vmEntryToJavaScript:
end
    doVMEntry(makeJavaScriptCall)

Global labels have a global scope and can be referenced anywhere in the assembly whereas Local labels are scoped to a macro and can only be referenced within the macro that defines them.

Conditional Statements

Another interesting construct in the previous snippet is the if statement. The developer comments on if statements are as follows:

An “if” is a conditional on settings. Any identifier supplied in the predicate of an “if” is assumed to be a #define that is available during code gen. So you can’t use “if” for computation in a macro, but you can use it to select different pieces of code for different platforms.

The snippet below shows an example of an if statement

if C_LOOP or C_LOOP_WIN or ARMv7 or ARM64 or ARM64E or MIPS
   # In C_LOOP or C_LOOP_WIN case, we're only preserving the bytecode vPC.
   move lr, destinationRegister
elsif X86 or X86_WIN or X86_64 or X86_64_WIN
    pop destinationRegister
else
    error
end

The predicates within the if statements, i.e. C_LOOP, ARM64, X86, etc are defined in the JavaScriptCore codebase and effectively perform the same function as #ifdef statements in C/C++.

Const Expressions

Const expressions allow offlineasm to define constant values to be used by the assembly or reference values implemented by the JIT ABI. The ABI references are translated to offsets at compile time by the offlineasm interpreter. An example of const declarations is shown in the snippet below:

# These declarations must match interpreter/JSStack.h.

const PtrSize = constexpr (sizeof(void*))
const MachineRegisterSize = constexpr (sizeof(CPURegister))
const SlotSize = constexpr (sizeof(Register))

if JSVALUE64
    const CallFrameHeaderSlots = 5
else
    const CallFrameHeaderSlots = 4
    const CallFrameAlignSlots = 1
end

The values PtrSize, MachineRegisterSize and SlotSize are determined at compile time when the relevant expressions are evaluated. The values of CPUResiter and Register are defined in stdlib.h for the target architecture. The CallFrameHeaderSlots and CallFrameAlignSlots are constant values that are referenced in LowLevelInterpreter.asm.

Tracing Execution

JavaScriptCore allows two commandline flags to enable tracing execution within the LLInt. These are traceLLIntExecution and traceLLIntSlowPath. However, in order to use these flags one would need to enable LLInt tracing in the LLInt configuration. This is achieved by setting LLINT_TRACING in LLIntCommon.h:

// Enables LLINT tracing.
// - Prints every instruction executed if Options::traceLLIntExecution() is enabled.
// - Prints some information for some of the more subtle slow paths if
//   Options::traceLLIntSlowPath() is enabled.
#define LLINT_TRACING 1

The two flags can now be added the run configuration launch.json or on the commandline. Here’s what launch.json should look like:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(gdb) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "/home/amar/workspace/WebKit/WebKitBuild/Debug/bin/jsc",
            "args": ["--reportBytecodeCompileTimes=true", "--dumpGeneratedBytecodes=true", "--useJIT=false", "--traceLLIntExecution=true","--traceLLIntSlowPath=true", "/home/amar/workspace/WebKit/WebKitBuild/Debug/bin/test.js"],

//... truncated for brevity

        }
    ]
}

Let’s quickly revisit our test script:

$ cat test.js
let x = 10;
let y = 20;
let z = x + y;

and the bytecodes generated for it:

<global>#AmfQ2h:[0x7fffee3bc000->0x7fffeedcb848, NoneGlobal, 96]: 18 instructions (0 16-bit instructions, 0 32-bit instructions, 11 instructions with metadata); 216 bytes (120 metadata bytes); 1 parameter(s); 12 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, Undefined(const0)
[  10] resolve_scope      loc7, loc4, 0, GlobalProperty, 0
[  17] put_to_scope       loc7, 0, Int32: 10(const1), 1048576<DoNotThrowIfNotFound|GlobalProperty|Initialization|NotStrictMode>, 0, 0
[  25] resolve_scope      loc7, loc4, 1, GlobalProperty, 0
[  32] put_to_scope       loc7, 1, Int32: 20(const2), 1048576<DoNotThrowIfNotFound|GlobalProperty|Initialization|NotStrictMode>, 0, 0
[  40] resolve_scope      loc7, loc4, 2, GlobalProperty, 0
[  47] resolve_scope      loc8, loc4, 0, GlobalProperty, 0
[  54] get_from_scope     loc9, loc8, 0, 2048<ThrowIfNotFound|GlobalProperty|NotInitialization|NotStrictMode>, 0, 0
[  62] mov                loc8, loc9
[  65] resolve_scope      loc9, loc4, 1, GlobalProperty, 0
[  72] get_from_scope     loc10, loc9, 1, 2048<ThrowIfNotFound|GlobalProperty|NotInitialization|NotStrictMode>, 0, 0
[  80] add                loc8, loc8, loc10, OperandTypes(126, 126)
[  86] put_to_scope       loc7, 2, loc8, 1048576<DoNotThrowIfNotFound|GlobalProperty|Initialization|NotStrictMode>, 0, 0
[  94] end                loc6
Successors: [ ]


Identifiers:
  id0 = x
  id1 = y
  id2 = z

Constants:
   k0 = Undefined
   k1 = Int32: 10: in source as integer
   k2 = Int32: 20: in source as integer

With the LLInt tracing enabled and the --traceLLIntExecution=true flag passed to the jsc shell via the commandline, allows dumping of the execution trace for each bytecode to stdout:

<0x7fffeedff000> 0x7fffee3bc000 / 0x7fffffffcb60: in prologue of <global>#AmfQ2h:[0x7fffee3bc000->0x7fffeedcb848, LLIntGlobal, 96]
<0x7fffeedff000> 0x7fffee3bc000 / 0x7fffffffcb60: executing bc#0, op_enter, pc = 0x7fffeedf49c0
Frame will eventually return to 0x7ffff4e61403
<0x7fffeedff000> 0x7fffee3bc000 / 0x7fffffffcb60: executing bc#1, op_get_scope, pc = 0x7fffeedf49c1
<0x7fffeedff000> 0x7fffee3bc000 / 0x7fffffffcb60: executing bc#3, op_mov, pc = 0x7fffeedf49c3
<0x7fffeedff000> 0x7fffee3bc000 / 0x7fffffffcb60: executing bc#6, op_check_traps, pc = 0x7fffeedf49c6
<0x7fffeedff000> 0x7fffee3bc000 / 0x7fffffffcb60: executing bc#7, op_mov, pc = 0x7fffeedf49c7
<0x7fffeedff000> 0x7fffee3bc000 / 0x7fffffffcb60: executing bc#10, op_resolve_scope, pc = 0x7fffeedf49ca
<0x7fffeedff000> 0x7fffee3bc000 / 0x7fffffffcb60: executing bc#17, op_put_to_scope, pc = 0x7fffeedf49d1
<0x7fffeedff000> 0x7fffee3bc000 / 0x7fffffffcb60: executing bc#25, op_resolve_scope, pc = 0x7fffeedf49d9
<0x7fffeedff000> 0x7fffee3bc000 / 0x7fffffffcb60: executing bc#32, op_put_to_scope, pc = 0x7fffeedf49e0
<0x7fffeedff000> 0x7fffee3bc000 / 0x7fffffffcb60: executing bc#40, op_resolve_scope, pc = 0x7fffeedf49e8
<0x7fffeedff000> 0x7fffee3bc000 / 0x7fffffffcb60: executing bc#47, op_resolve_scope, pc = 0x7fffeedf49ef
<0x7fffeedff000> 0x7fffee3bc000 / 0x7fffffffcb60: executing bc#54, op_get_from_scope, pc = 0x7fffeedf49f6
<0x7fffeedff000> 0x7fffee3bc000 / 0x7fffffffcb60: executing bc#62, op_mov, pc = 0x7fffeedf49fe
<0x7fffeedff000> 0x7fffee3bc000 / 0x7fffffffcb60: executing bc#65, op_resolve_scope, pc = 0x7fffeedf4a01
<0x7fffeedff000> 0x7fffee3bc000 / 0x7fffffffcb60: executing bc#72, op_get_from_scope, pc = 0x7fffeedf4a08
<0x7fffeedff000> 0x7fffee3bc000 / 0x7fffffffcb60: executing bc#80, op_add, pc = 0x7fffeedf4a10
<0x7fffeedff000> 0x7fffee3bc000 / 0x7fffffffcb60: executing bc#86, op_put_to_scope, pc = 0x7fffeedf4a16
<0x7fffeedff000> 0x7fffee3bc000 / 0x7fffffffcb60: executing bc#94, op_end, pc = 0x7fffeedf4a1e

Lets return to our discussion on vmEntryToJavaScript that was left off from in the recap section. As stated previously, this is the entry point into the LLInt. This is defined as a global label within LowLevelInterpreter.asm as follows:

# ... asm truncated for brevity 

    global _vmEntryToJavaScript
    _vmEntryToJavaScript:

    doVMEntry(makeJavaScriptCall)

This effectively calls the macro, doVMEntry with the macro makeJavaScriptCall passed as an argument. These two macros are defined in LowLevelInterpreter64.asm.

The macro doVMEntry does a number of actions before it calls the macro makeJavaScriptCall. These actions are setting up the function prologue, saving register state, checking stack pointer alignment, adding a VMEntryRecord and setting up the stack with arguments for the call to makeJavaScriptCall. A truncated assembly snippet is shown below:

macro doVMEntry(makeCall)
    functionPrologue()
    pushCalleeSaves()

    const entry = a0
    const vm = a1
    const protoCallFrame = a2

    vmEntryRecord(cfr, sp)

    checkStackPointerAlignment(t4, 0xbad0dc01)

    //... assembly truncated for brevity

    checkStackPointerAlignment(extraTempReg, 0xbad0dc02)

    makeCall(entry, protoCallFrame, t3, t4)     <-- call to makeJavaScriptCall which initiates bytecode execution

    checkStackPointerAlignment(t2, 0xbad0dc03)

    vmEntryRecord(cfr, t4)

    //... assembly truncated for brevity

    subp cfr, CalleeRegisterSaveSize, sp

    popCalleeSaves()
    functionEpilogue()
    ret

//... assembly truncated for brevity

end

When the call to makeJavaScriptCall returns, it performs actions to once again check stack alignment, update the VMEntryRecord, restore saved registers and invoke the function epilogue macro before returning control to its caller. makeCall in the snippet above invokes makeJavaScriptCall which is defined as follows:

# a0, a2, t3, t4
macro makeJavaScriptCall(entry, protoCallFrame, temp1, temp2)
    addp 16, sp
    //... assembly truncated for brevity
    call entry, JSEntryPtrTag

    subp 16, sp
end

The call parameter entry here refers to the glue code llint_program_prologue that was set during the LLInt setup stage. This glue code is defined in LowLevelInterpreter.asm as follows:

op(llint_program_prologue, macro ()
    prologue(notFunctionCodeBlockGetter, notFunctionCodeBlockSetter, _llint_entry_osr, _llint_trace_prologue)
    dispatch(0)
end)

This glue code when compiled by offlineasm gets emitted in LLIntAssembly.h, a truncated snippet of which is shown below:

OFFLINE_ASM_GLUE_LABEL(llint_program_prologue)
".loc 1 1346\n"
    // /home/amar/workspace/WebKit/Source/JavaScriptCore/llint/LowLevelInterpreter.asm:1346
    // /home/amar/workspace/WebKit/Source/JavaScriptCore/llint/LowLevelInterpreter.asm:777
".loc 1 777\n"
    "\tpush %rbp\n"
".loc 1 783\n"
    "\tmovq %rsp, %rbp\n"                                    // /home/amar/workspace/WebKit/Source/JavaScriptCore/llint/LowLevelInterpreter.asm:783

    //... code truncated for brevity

At runtime this resolves to the address of the . This can also be seen by setting a breakpoint within JITCode::execute and inspecting the value at entryAddress. The screenshot below show the the value of entryAddress at runtime and the instruction dump at that address.

Another handy feature of vscode is enabling the Allow Breakpoints Everywhere setting in vscode. This will allow setting breakpoints directly in LowLevelInterpreter.asm and LowLevelInterpreter64.asm. This will save a bit of time rather than having to set breakpoints in gdb to break in the LLInt.

This would now allow source-level debugging in offlineasm source files. However, this isn’t a foolproof method as vscode is unable to resolve branching instructions that rely on indirect address resolution. A good example of this is the call instruction to entry in makeJavaScriptCall.

call entry, JSEntryPtrTag

the jump address for entry is stored in register rdi and a breakpoint would need to be set manually at the address pointed to by rdi. In the screenshot below, the debugger pauses execution at call entry, JSEntryPtrTag and from within gdb allows listing of the current instruction the debugger is stopped at and the instructions that execution would jump to:

Fortunately, the WebKit developers have added a line table to LLIntAssembly.h, which allows the debugger to cross-reference the LowLevelInterpreter.asm and LowLevelInterpreter64.asm while stepping through instructions in gdb. The screenshot below is an example of what it would look like stepping through llint_op_enter_wide32:

With the locations in the offlineasm source files specified in the line table and the ability to set breakpoints directly at points of interest in the .asm files, one can continue debugging at the sourcecode level. The screenshot below shows an example of what that would look like in vscode:

At this point one should now be able to enable execution tracing in the LLInt and setup breakpoints in offlineasm source files. Also discussed was how the jump to the llint_program_prologue glue code initiates the execution of bytecode.

This section will now discuss the LLInt execution loop which iterates over the bytecodes and executes them sequentially. The high level overview of this execution loop is as follows:

call dispatch with an optional argument that would increment PC
Increment PC with the argument passed to dispatch
Lookup the opcode map and fetch the address of the llint opcode label for the corresponding bytecode to be executed
Jump to the llint opcode label that which is the start of the bytecode instructions to be executed
Once execution has completed, repeat #1

Let’s look a this loop in more detail by examining the execution of opcode mov which is at bytecode bc#3.

[   3] mov                loc5, loc4

Begin by setting a breakpoint at the start of the opcode macro dispatch definition in LowLevelInterpreter.asm. When the call to dispatch is made, advanceReg contains the value 0x2. PC currently points to bytecode bc#1and this is incremented by adding 0x2 to point to bytecode bc#3 which is the mov bytecode in our bytecode dump.

macro dispatch(advanceReg)
    addp advanceReg, PC
    nextInstruction()
end

with PC incremented and pointing to bc#3, a call to nextInstruction() is made. The macro nextInstruction looks up the _g_opcodeMap to find the opcode implementation in the LLInt. Once the jmp in nextInstruction() is taken, execution controls ends up in the LLInt assembly for llint_op_mov.

macro nextInstruction()
    loadb [PB, PC, 1], t0
    leap _g_opcodeMap, t1
    jmp [t1, t0, PtrSize], BytecodePtrTag
end

The bytecode opcodes are implemented in this section of the LowLevelInterpreter64.asm and are referenced via the llint opcode labels which are defined in LLIntAssembly.h. An example of this is the mov opcode which is referenced by the label op_mov:


llintOpWithReturn(op_mov, OpMov, macro (size, get, dispatch, return)
    get(m_src, t1)
    loadConstantOrVariable(size, t1, t2)
    return(t2)
end)

And the corresponding definition in the LLIntAssembly.h is as follows:

OFFLINE_ASM_OPCODE_LABEL(op_mov)
".loc 3 358\n"
    "\taddq %r13, %r8\n"                                     // /home/amar/workspace/WebKit/Source/JavaScriptCore/llint/LowLevelInterpreter64.asm:358
".loc 3 368\n"
    "\tmovq %rbp, %rdi\n"                                    // /home/amar/workspace/WebKit/Source/JavaScriptCore/llint/LowLevelInterpreter64.asm:368
".loc 3 369\n"
    "\tmovq %r8, %rsi\n"                                     // /home/amar/workspace/WebKit/Source/JavaScriptCore/llint/LowLevelInterpreter64.asm:369
".loc 1 704\n"
    "\tmovq %rsp, %r8\n"                                     // /home/amar/workspace/WebKit/Source/JavaScriptCore/llint/LowLevelInterpreter.asm:704
    "\tandq $15, %r8\n"

//... truncated for brevity

".loc 3 513\n"
    "\tcmpq $16, %rsi\n"                                     // /home/amar/workspace/WebKit/Source/JavaScriptCore/llint/LowLevelInterpreter64.asm:513
    "\tjge " LOCAL_LABEL_STRING(_offlineasm_llintOpWithReturn__llintOp__commonOp__fn__fn__makeReturn__fn__fn__loadConstantOrVariable__size__k__57_load__constant) "\n"
".loc 3 514\n"
    "\tmovq 0(%rbp, %rsi, 8), %rdx\n"                        // /home/amar/workspace/WebKit/Source/JavaScriptCore/llint/LowLevelInterpreter64.asm:514
".loc 3 515\n"
    "\tjmp " LOCAL_LABEL_STRING(_offlineasm_llintOpWithReturn__llintOp__commonOp__fn__fn__makeReturn__fn__fn__loadConstantOrVariable__size__k__57_load__done) "\n" // /home/amar/workspace/WebKit/Source/JavaScriptCore/llint/LowLevelInterpreter64.asm:515

  OFFLINE_ASM_LOCAL_LABEL(_offlineasm_llintOpWithReturn__llintOp__commonOp__fn__fn__makeReturn__fn__fn__loadConstantOrVariable__size__k__57_load__constant)
".loc 3 489\n"
    "\tmovq 16(%rbp), %rdx\n"                                // /home/amar/workspace/WebKit/Source/JavaScriptCore/llint/LowLevelInterpreter64.asm:489
".loc 3 490\n"
    "\tmovq 176(%rdx), %rdx\n"                               // /home/amar/workspace/WebKit/Source/JavaScriptCore/llint/LowLevelInterpreter64.asm:490
".loc 3 491\n"
    "\tmovq -128(%rdx, %rsi, 8), %rdx\n"                     // /home/amar/workspace/WebKit/Source/JavaScriptCore/llint/LowLevelInterpreter64.asm:491

  OFFLINE_ASM_LOCAL_LABEL(_offlineasm_llintOpWithReturn__llintOp__commonOp__fn__fn__makeReturn__fn__fn__loadConstantOrVariable__size__k__57_load__done)

//... truncated for brevity

One can also verify this by dumping the assembly from the debugger:

Dump of assembler code for function llint_op_mov:
   0x00007ffff4e65b4f <+0>: add    r8,r13
   0x00007ffff4e65b52 <+3>: mov    rdi,rbp
   0x00007ffff4e65b55 <+6>: mov    rsi,r8
   0x00007ffff4e65b58 <+9>: mov    r8,rsp
   0x00007ffff4e65b5b <+12>:    and    r8,0xf
   0x00007ffff4e65b5f <+16>:    test   r8,r8
   0x00007ffff4e65b62 <+19>:    je     0x7ffff4e65b6f <llint_op_mov+32>
   0x00007ffff4e65b64 <+21>:    movabs r8,0xbad0c002
   0x00007ffff4e65b6e <+31>:    int3   
   0x00007ffff4e65b6f <+32>:    call   0x7ffff5e89bd1 <JavaScript::LLInt::llint_trace(JavaScript::CallFrame*, JavaScript::Instruction const*)>
   0x00007ffff4e65b74 <+37>:    mov    r8,rax
   0x00007ffff4e65b77 <+40>:    sub    r8,r13
   0x00007ffff4e65b7a <+43>:    movsx  rsi,BYTE PTR [r13+r8*1+0x2]
   0x00007ffff4e65b80 <+49>:    cmp    rsi,0x10
   0x00007ffff4e65b84 <+53>:    jge    0x7ffff4e65b8d <llint_op_mov+62>
   0x00007ffff4e65b86 <+55>:    mov    rdx,QWORD PTR [rbp+rsi*8+0x0]
   0x00007ffff4e65b8b <+60>:    jmp    0x7ffff4e65b9d <llint_op_mov+78>
   0x00007ffff4e65b8d <+62>:    mov    rdx,QWORD PTR [rbp+0x10]
   0x00007ffff4e65b91 <+66>:    mov    rdx,QWORD PTR [rdx+0xb0]
   0x00007ffff4e65b98 <+73>:    mov    rdx,QWORD PTR [rdx+rsi*8-0x80]
   0x00007ffff4e65b9d <+78>:    movsx  rsi,BYTE PTR [r13+r8*1+0x1]
   0x00007ffff4e65ba3 <+84>:    mov    QWORD PTR [rbp+rsi*8+0x0],rdx
   0x00007ffff4e65ba8 <+89>:    add    r8,0x3
   0x00007ffff4e65bac <+93>:    movzx  eax,BYTE PTR [r13+r8*1+0x0]
   0x00007ffff4e65bb2 <+99>:    mov    rsi,QWORD PTR [rip+0x2e2264f]        # 0x7ffff7c88208
   0x00007ffff4e65bb9 <+106>:   jmp    QWORD PTR [rsi+rax*8]
   0x00007ffff4e65bbc <+109>:   int3   
   0x00007ffff4e65bbd <+110>:   int3   
   0x00007ffff4e65bbe <+111>:   add    al,0x2
   0x00007ffff4e65bc0 <+113>:   add    BYTE PTR [rax],al
End of assembler dump.

Fast Path/Slow Path

An important aspect of the LLInt is the concept and implementation of fast and slow paths. The LLInt, by design, is meant to generate fast code with a low latency as possible. The code generated, as seen earlier in this blog post, is typically machine code (e.g. x86 assembly) that implements bytecode operations. However, when executing bytecode the LLInt needs to determine the types of operands it receives with an opcode in order to pick the right execution path. For example consider the the following js code:

let x = 10; 
let y = 20;
let z = x+y;

The LLInt when when it executes the add opcode, it will check if the operands passed to it (i.e. x and y) are integers and if so it can implement the addition operation directly in machine code. Now consider the following js code:

let x = 10;
let y = {a : "Ten"};
let z = x+y;

The LLInt can no longer perform addition directly in machine code since the types of x and y are different. In this instance, the LLInt will take slow path of execution which is a call to C++ code to handle cases were there is an operand type mismatch. This is a simplified explanation on how fast and slow paths work and the add opcode in particular has several other checks on its operands in addition to integer checks.

Additionally, when the LLInt needs to call into C++ code, it makes a call to a slow path which is essentially a trampoline into C++. If you’ve been debugging along, you may have noticed calls to callSlowPath or cCall2 as one steps through the execution in the LLInt most of which has been calls to the tracing function which is implemented in C++.

Lets now attempt to debug execution in a slow path. For this exercise the following js program is used:

let x = 10;
let y = "Ten";
x === y;

Which generates the following bytecode dump:

bb#1
[   0] enter              
[   1] get_scope          loc4
[   3] mov                loc5, loc4
[   6] check_traps        
[   7] mov                loc6, Undefined(const0)
[  10] resolve_scope      loc7, loc4, 0, GlobalProperty, 0
[  17] put_to_scope       loc7, 0, Int32: 10(const1), 1048576, 0, 0
[  25] resolve_scope      loc7, loc4, 1, GlobalProperty, 0
[  32] put_to_scope       loc7, 1, String (atomic),8Bit:(1),length:(3): Ten, StructureID: 22247(const2), 1048576, 0, 0
[  40] mov                loc6, Undefined(const0)
[  43] resolve_scope      loc7, loc4, 0, GlobalProperty, 0
[  50] get_from_scope     loc8, loc7, 0, 2048, 0, 0
[  58] mov                loc7, loc8
[  61] resolve_scope      loc8, loc4, 1, GlobalProperty, 0
[  68] get_from_scope     loc9, loc8, 1, 2048, 0, 0
[  76] stricteq           loc6, loc7, loc9
[  80] end                loc6
Successors: [ ]

Identifiers:
  id0 = x
  id1 = y

Constants:
   k0 = Undefined
   k1 = Int32: 10: in source as integer
   k2 = String (atomic),8Bit:(1),length:(3): Ten, StructureID: 55445

The bytecode of interest is the stricteq opcode at bc#76. This opcode is defined in LowLevelInterpreter64.asm as follows:

macro strictEqOp(opcodeName, opcodeStruct, createBoolean)
    llintOpWithReturn(op_%opcodeName%, opcodeStruct, macro (size, get, dispatch, return)
        get(m_rhs, t0)
        get(m_lhs, t2)
        loadConstantOrVariable(size, t0, t1)
        loadConstantOrVariable(size, t2, t0)

        # At a high level we do
        # If (left is Double || right is Double)
        #     goto slowPath;
        # result = (left == right);
        # if (result)
        #     goto done;
        # if (left is Cell || right is Cell)
        #     goto slowPath;
        # done:
        # return result;

        # This fragment implements (left is Double || right is Double), with a single branch instead of the 4 that would be naively required if we used branchIfInt32/branchIfNumber
        # The trick is that if a JSValue is an Int32, then adding 1<<49 to it will make it overflow, leaving all high bits at 0
        # If it is not a number at all, then 1<<49 will be its only high bit set
        # Leaving only doubles above or equal 1<<50.
        move t0, t2
        move t1, t3
        move LowestOfHighBits, t5
        addq t5, t2
        addq t5, t3
        orq t2, t3
        lshiftq 1, t5
        bqaeq t3, t5, .slow

        cqeq t0, t1, t5
        btqnz t5, t5, .done #is there a better way of checking t5 != 0 ?

        move t0, t2
        # This andq could be an 'or' if not for BigInt32 (since it makes it possible for a Cell to be strictEqual to a non-Cell)
        andq t1, t2
        btqz t2, notCellMask, .slow

    .done:
        createBoolean(t5)
        return(t5)

    .slow:
        callSlowPath(_slow_path_%opcodeName%)
        dispatch()
    end)
end

One can set a breakpoint at this macro definition and step through the execution of this opcode. There are two reasons to pick this particular opcode, one being that it’s execution paths are simple to follow and don’t introduce unnecessary complexity and the second being that it comes with helpful developer comments to help the reader follow along.

Stepping through the execution, observe that the checks for numbers (i.e. integers and doubles) fails and execution control end up in the section that checks for JSCell headers. The rhs of the stricteq operation passes the isCell check and as a result execution jumps to the label .slow which calls the slow path:

//... truncated for brevity
        
        move t0, t2
        # This andq could be an 'or' if not for BigInt32 (since it makes it possible for a Cell to be strictEqual to a non-Cell)
        andq t1, t2
        btqz t2, notCellMask, .slow

 //... truncated for brevity

    .slow:
        callSlowPath(_slow_path_%opcodeName%)

//... truncated for brevity

Stepping into the call to callSlowPath leads to the C++ implementation of _slow_path_stricteq defined in CommonSlowPaths.cpp:

JSC_DEFINE_COMMON_SLOW_PATH(slow_path_stricteq)
{
    BEGIN();
    auto bytecode = pc->as<OpStricteq>();
    RETURN(jsBoolean(JSValue::strictEqual(globalObject, GET_C(bytecode.m_lhs).jsValue(), GET_C(bytecode.m_rhs).jsValue())));
}

This stub function retrieves the operand values and passes it to the function JSValue::strictEqual which is defined as follows:

inline bool JSValue::strictEqual(JSGlobalObject* globalObject, JSValue v1, JSValue v2)
{
    if (v1.isInt32() && v2.isInt32())
        return v1 == v2;

    if (v1.isNumber() && v2.isNumber())
        return v1.asNumber() == v2.asNumber();

#if USE(BIGINT32)
    if (v1.isHeapBigInt() && v2.isBigInt32())
        return v1.asHeapBigInt()->equalsToInt32(v2.bigInt32AsInt32());
    if (v1.isBigInt32() && v2.isHeapBigInt())
        return v2.asHeapBigInt()->equalsToInt32(v1.bigInt32AsInt32());
#endif

    if (v1.isCell() && v2.isCell())
        return strictEqualForCells(globalObject, v1.asCell(), v2.asCell());

    return v1 == v2;
}

This function is responsible for performing all the various slower checks to determine if the lhs is strictly equal to the rhs. This concludes our discussion on the fast path/slow path pattern that’s common across all JIT tiers in JavaScriptCore.

Tiering Up

When bytecode has been executed a certain number of times in the LLInt, the bytecodes gets profiled as being warm code and after an execution threshold is reached, the warm code is now considered hot and the LLInt can now tier up to a higher JIT tier. In this case JavaScriptCore would tier up into the Baseline JIT. The graph reproduced⁴ below shows a timeline on how the tiering up process functions:

The Control section of the WebKit blog³ describes the three main heuristics that are used by the various JIT tiers to determine thresholds for tiering up. These heuristics are execution counts for function calls and loop execution, count exits to count the number of times a function compiled by the optimising JIT tiers exits to a lower tier and recompilation counts which keeps track of the number of times a function is jettisoned to a lower tier.

The LLInt mainly uses execution counts to determine if a function or loop is hot and if the execution of this code should be tiered up. The execution counter in the LLInt utilises the following rules³ to calculate the threshold to tier up:

Each call to the function adds 15 points to the execution counter.

Each loop execution adds 1 point to the execution counter.

There are two threshold values used by the LLInt for execution counting. The static value of 500 points is used when no other information about the bytecodes execution or JIT status is captured. As the bytecode executes in the LLInt, tiers up and down, the engine generates a dynamic profile for the threshold value. The excerpt below³ describes how dynamic threshold counts are determined in the LLInt:

Over the years we’ve found ways to dynamically adjust these thresholds based on other sources of information, like:

Whether the function got JITed the last time we encountered it (according to our cache). Let’s call this wasJITed.

How big the function is. Let’s call this S. We use the number of bytecode opcodes plus operands as the size.

How many times it has been recompiled. Let’s call this R.

How much executable memory is available. Let’s use M to say how much executable memory we have total, and U is the amount we estimate that we would use (total) if we compiled this function.

Whether profiling is “full” enough.

We select the LLInt→Baseline threshold based on wasJITed. If we don’t know (the function wasn’t in the cache) then we use the basic threshold, 500. Otherwise, if the function wasJITed then we use 250 (to accelerate tier-up) otherwise we use 2000.

The values of S, R, M and U aren’t used by the LLInt to calculate a dynamic thresholds for tiering up but this will become relevant when exploring the optimising tiers later on in this blog series. The static execution counter thresholds are defined in OptionsList.h. The snippet below shows the values for LLInt→Baseline thresholds:

v(Int32, thresholdForJITAfterWarmUp, 500, Normal, nullptr) \
v(Int32, thresholdForJITSoon, 100, Normal, nullptr) \
\
//... code truncated for brevity
v(Int32, executionCounterIncrementForLoop, 1, Normal, nullptr) \
v(Int32, executionCounterIncrementForEntry, 15, Normal, nullptr) \

The execution counters that track these values are defined in ExecutionCounter.h. The snippet below shows the three key counters that are referenced and updated by the LLInt.

    // This counter is incremented by the JIT or LLInt. It starts out negative and is
    // counted up until it becomes non-negative. At the start of a counting period,
    // the threshold we wish to reach is m_totalCount + m_counter, in the sense that
    // we will add X to m_totalCount and subtract X from m_counter.
    int32_t m_counter;

    // Counts the total number of executions we have seen plus the ones we've set a
    // threshold for in m_counter. Because m_counter's threshold is negative, the
    // total number of actual executions can always be computed as m_totalCount +
    // m_counter.
    float m_totalCount;

    // This is the threshold we were originally targeting, without any correction for
    // the memory usage heuristics.
    int32_t m_activeThreshold;

Each CodeBlock parsed by the engine instantiates two ExecutionCounter objects. These are the m_llintExecuteCounter and the m_jitExecuteCounter. The m_llintExecuteCounter is most relevant for this blog post as it determines the threshold to tier up into the Baseline JIT.

    BaselineExecutionCounter m_llintExecuteCounter;

    BaselineExecutionCounter m_jitExecuteCounter;

With the understanding of how thresholds work, lets trace this in the code base to better understand this behaviour. To being, enable the Baseline JIT in launch.json to allow the LLInt to tier up and at the same time ensure that the optimising tiers are disabled. This is done by removing the --useJIT=false flag and adding the --useDFGJIT=false flag to the commandline arguments. The launch.json should look as follows:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(gdb) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "/home/amar/workspace/WebKit/WebKitBuild/Debug/bin/jsc",
            "args": ["--reportCompileTimes=true", "--dumpGeneratedBytecodes=true", "--useDFGJIT=false", "/home/amar/workspace/WebKit/WebKitBuild/Debug/bin/test.js"],
            //... truncated for brevity
        }
    ]
}

In addition, also add the --reportCompileTimes=true flag to log a notification to stdout when CodeBlock is compiled by the Baseline JIT and other tiers. Now that the debugging environment has been updated, lets create the following test script to trigger baseline compilation:

$ cat test.js

function jitMe(x,y){
    return x+y;
}

let x = 1;

for(let y = 0; y < 300; y++){
    jitMe(x,y)
}

In the javascript program above, our goal is to attempt to execute the function jitMe over several iterations of the for-loop in order for it to be optimised by the Baseline JIT. The LLInt determines when a function/codeblock should be optimised with the call the macro checkSwitchToJIT:

macro checkSwitchToJIT(increment, action)
    loadp CodeBlock[cfr], t0
    baddis increment, CodeBlock::m_llintExecuteCounter + BaselineExecutionCounter::m_counter[t0], .continue
    action()
    .continue:
end

Setting a breakpoint at this macro allows examining the counter values in the debugger. Pausing execution at this breakpoint and listing of instructions is shown below:

Thread 1 "jsc" hit Breakpoint 3, llint_op_ret () at /home/amar/workspace/WebKit/Source/JavaScriptCore/llint/LowLevelInterpreter.asm:1273
1273        baddis increment, CodeBlock::m_llintExecuteCounter + BaselineExecutionCounter::m_counter[t0], .continue
-exec x/4i $rip
=> 0x7ffff4e71e1c <llint_op_ret+47>:    add    DWORD PTR [rax+0xe8],0xa
   0x7ffff4e71e23 <llint_op_ret+54>:    js     0x7ffff4e71e50 <llint_op_ret+99>
   0x7ffff4e71e25 <llint_op_ret+56>:    add    r8,r13
   0x7ffff4e71e28 <llint_op_ret+59>:    mov    rdi,rbp

The memory address pointed to by rax+0xe8 is the value of m_counter which has a value of -500 and is incremented by a value of 15 (0xa). When this value reaches zero, it triggers Baseline optimisation with the call to action. Allowing the program to continue execution in our debugger and run to completion, generates the following output:

<global>#CLzrku:[0x7fffae3c4000->0x7fffeedcb768, NoneGlobal, 116]: 28 instructions (0 16-bit instructions, 0 32-bit instructions, 10 instructions with metadata); 236 bytes (120 metadata bytes); 1 parameter(s); 18 callee register(s); 6 variable(s); scope at loc4

bb#1
[   0] enter              
[   1] get_scope          loc4
#... truncated for brevity

jitMe#AQcl4Q:[0x7fffae3c4130->0x7fffae3e5100, NoneFunctionCall, 15]: 6 instructions (0 16-bit instructions, 0 32-bit instructions, 1 instructions with metadata); 135 bytes (120 metadata bytes); 3 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] add                loc6, arg1, arg2, OperandTypes(126, 126)
[  13] ret                loc6
Successors: [ ]


Optimized jitMe#AQcl4Q:[0x7fffae3c4130->0x7fffae3e5100, LLIntFunctionCall, 15] with Baseline JIT into 960 bytes in 1.078797 ms.

As can be seen from the last line of the output above, the function jitMe has been optimised by the Baseline JIT. The next section will explore both compilation and execution in the Baseline JIT.

Baseline JIT

In a nutshell, the Baseline JIT is a template JIT and what that means is that it generates specific machine code for the bytecode operation. There are two key factors that allow the Baseline JIT a speed up over the LLInt³:

Removal of interpreter dispatch. Interpreter dispatch is the costliest part of interpretation, since the indirect branches used for selecting the implementation of an opcode are hard for the CPU to predict. This is the primary reason why Baseline is faster than LLInt.

Comprehensive support for polymorphic inline caching. It is possible to do sophisticated inline caching in an interpreter, but currently our best inline caching implementation is the one shared by the JITs.

The following sections will trace how the execution thresholds are reached, how execution transitions from LLInt to the Baseline JIT code via OSR (On Stack Replacement) and the assembly emitted by the Baseline JIT.

Implementation

Majority of the code for the Baseline JIT can be found under JavaScriptCore/jit. The JIT ABI is defined in JIT.h which will be a key item to review as part of the Baseline JIT and defines the various optimised templates for opcodes.

The Baseline JIT templates call assemblers defined in JavaScriptCore/assembler to emit machine code for the target architecture. For example the assemblers used to emit machine code for x86 architectures can be found under MacroAssemblerX86_64.h and X86Assembler.h

Tracing Execution

To enhance tracing in the Baseline JIT one can enable the --verboseOSR=true commandline flag in our launch.json. This flag will enable printing of useful information on the stages of optimisation from the LLInt to the Baseline JIT. The key statistic being the threshold counts for tiering up. Here’s an example of what the output with verboseOSR enabled would look like when executing out test script from the previous section:

#... truncated for brevity

Installing <global>#CLzrku:[0x7fffae3c4000->0x7fffeedcb768, LLIntGlobal, 116]
jitMe#AQcl4Q:[0x7fffae3c4130->0x7fffae3e5100, NoneFunctionCall, 15]: Optimizing after warm-up.
jitMe#AQcl4Q:[0x7fffae3c4130->0x7fffae3e5100, NoneFunctionCall, 15]: bytecode cost is 15.000000, scaling execution counter by 1.072115 * 1
jitMe#AQcl4Q:[0x7fffae3c4130->0x7fffae3e5100, NoneFunctionCall, 15]: 6 instructions (0 16-bit instructions, 0 32-bit instructions, 1 instructions with metadata); 135 bytes (120 metadata bytes); 3 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] add                loc6, arg1, arg2, OperandTypes(126, 126)
[  13] ret                loc6
Successors: [ ]


Installing jitMe#AQcl4Q:[0x7fffae3c4130->0x7fffae3e5100, LLIntFunctionCall, 15]
jitMe#AQcl4Q:[0x7fffae3c4130->0x7fffae3e5100, LLIntFunctionCall, 15]: Entered entry_osr_function_for_call with executeCounter = 500.001038/500.000000, 0
jitMe#AQcl4Q:[0x7fffae3c4130->0x7fffae3e5100, LLIntFunctionCall, 15]: Entered replace with executeCounter = 100.000214/100.000000, 0
jitMe#AQcl4Q:[0x7fffae3c4130->0x7fffae3e5100, LLIntFunctionCall, 15]: Entered replace with executeCounter = 105.000214/100.000000, 5
jitMe#AQcl4Q:[0x7fffae3c4130->0x7fffae3e5100, LLIntFunctionCall, 15]: Entered replace with executeCounter = 105.000214/100.000000, 5

#... truncated for brevity

Optimized jitMe#AQcl4Q:[0x7f85f7ac4130->0x7f85f7ae5100, LLIntFunctionCall, 15] with Baseline JIT into 960 bytes in 0.810440 ms.
jitMe#AQcl4Q:[0x7f85f7ac4130->0x7f85f7ae5100, LLIntFunctionCall, 15]: Entered replace with executeCounter = 105.000351/100.000000, 5
    JIT compilation successful.
Installing jitMe#AQcl4Q:[0x7f85f7ac4130->0x7f85f7ae5100, BaselineFunctionCall, 15]
    Code was already compiled.

Compiling the CodeBlock is a concurrent process and JavaScriptCore spawns a JITWorker thread to being compiling the codeblock with the Baseline JIT. In the interest of simplifying our debugging process, disable concurrent compilation and force compilation to occur on the main jsc thread. In order to do this add the --useConcurrentJIT=false flag to launch.json or on the commandline.

Additionally, JavaScriptCore provides two useful flags that allows adjustment to the JIT compilation threshold counters. These flags are --thresholdForJITSoon and --thresholdForJITAfterWarmUp. By adding the flag --thresholdForJITAfterWarmUp=10 reduce the static threshold count to initiate Baseline JIT optimisation from the default JITAfterWarmUp value of 500 to 10. If the engine determines that the codeblock was JIT compiled previously, it will use the JIT threshold default JITSoon of 100 which will be reduced to the value of 10 by using --thresholdForJITSoon=10.

Our launch.json should now look as follows:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(gdb) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "/home/amar/workspace/WebKit/WebKitBuild/Debug/bin/jsc",
            "args": ["--reportCompileTimes=true", "--dumpGeneratedBytecodes=true", "--useDFGJIT=false", "--verboseOSR=true", "--useConcurrentJIT=false", "--thresholdForJITAfterWarmUp=10", "--thresholdForJITSoon=10", "/home/amar/workspace/WebKit/WebKitBuild/Debug/bin/test.js"],
            //... truncated for brevity
        }
    ]
}

With these additional flags, lets now attempt to trace the optimisation of the following test program:

$ cat test.js

for(let x = 0; x < 5; x++){
    let y = x+10;
}

The bytecodes generated for this program are listed below:

#DETOqr:[0x7fffae3c4000->0x7fffeedcb768, NoneGlobal, 43]: 16 instructions (0 16-bit instructions, 0 32-bit instructions, 2 instructions with metadata); 163 bytes (120 metadata bytes); 1 parameter(s); 10 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, Undefined(const0)
[  10] mov                loc6, Undefined(const0)
[  13] mov                loc7, ()>(const1)
[  16] mov                loc7, Int32: 0(const2)
[  19] jnless             loc7, Int32: 5(const3), 22(->41)
Successors: [ #3 #2 ]

bb#2
[  23] loop_hint          
[  24] check_traps        
[  25] mov                loc8, ()>(const1)
[  28] add                loc8, loc7, Int32: 10(const4), OperandTypes(126, 3)
[  34] inc                loc7
[  37] jless              loc7, Int32: 5(const3), -14(->23)
Successors: [ #2 #3 ]

bb#3
[  41] end                loc6
Successors: [ ]


Constants:
   k0 = Undefined
   k1 = ()>
   k2 = Int32: 0: in source as integer
   k3 = Int32: 5: in source as integer
   k4 = Int32: 10: in source as integer

The opcode loop_hint in basic block bb#2 is responsible for incrementing the JIT threshold counters, initiating compilation by the Baseline JIT if the execution threshold is breached and performing OSR entry. The loop_hint opcode is defined in LowLevelInterpreter.asm which essentially calls the macro checkSwitchToJITForLoop to determine if an OSR is required.

macro checkSwitchToJITForLoop()
    checkSwitchToJIT(
        1,
        macro()
            storePC()
            prepareStateForCCall()
            move cfr, a0
            move PC, a1
            cCall2(_llint_loop_osr)
            btpz r0, .recover
            move r1, sp
            jmp r0, JSEntryPtrTag
        .recover:
            loadPC()
        end)
end

The macro checkSwitchToJIT as seen in the previous section determines if the JIT threshold has been breached and performs a slow path call to _llint_loop_osr. This slow path, loop_osr is defined LLIntSlowPaths.cpp and is listed below:

LLINT_SLOW_PATH_DECL(loop_osr)
{
    //... code truncated for brevity
        
    auto loopOSREntryBytecodeIndex = BytecodeIndex(codeBlock->bytecodeOffset(pc));

    //... code truncated for brevity
    
    if (!jitCompileAndSetHeuristics(vm, codeBlock, loopOSREntryBytecodeIndex))  <-- Compilation with Baseline JIT
        LLINT_RETURN_TWO(nullptr, nullptr);
    
    //... code truncated for brevity

    const JITCodeMap& codeMap = codeBlock->jitCodeMap();
    CodeLocationLabel<JSEntryPtrTag> codeLocation = codeMap.find(loopOSREntryBytecodeIndex); <-- Retrieve location of the compiled code
    ASSERT(codeLocation);

    void* jumpTarget = codeLocation.executableAddress();
    ASSERT(jumpTarget);
    
    LLINT_RETURN_TWO(jumpTarget, callFrame->topOfFrame()); <-- Perform OSR to the location of the compiled code
}

As the truncated snippet above indicates, the function will first compile codeBlock with the call to jitCompileAndSetHeuristics and if the compilation succeeds, it will jump to the target address of the compiled code and resume execution. In addition to loop_osr there are additional flavours of OSR supported by the LLInt. These are entry_osr, entry_osr_function_for_call, entry_osr_function_for_construct, entry_osr_function_for_call_arityCheck and entry_osr_function_for_construct_arityCheck an essentially perform the same function as loop_osr and are defined here in LLIntSlowPaths.cpp.

Compilation

Let’s now examine how codeblock compilation works by stepping through the function jitCompileAndSetHeuristics:

inline bool jitCompileAndSetHeuristics(VM& vm, CodeBlock* codeBlock, BytecodeIndex loopOSREntryBytecodeIndex = BytecodeIndex(0))
{
    //... code truncated for brevity
    
    JITWorklist::ensureGlobalWorklist().poll(vm);
    
    switch (codeBlock->jitType()) {
    case JITType::BaselineJIT: {
        dataLogLnIf(Options::verboseOSR(), "    Code was already compiled.");
        codeBlock->jitSoon();
        return true;
    }
    case JITType::InterpreterThunk: {
        JITWorklist::ensureGlobalWorklist().compileLater(codeBlock, loopOSREntryBytecodeIndex);
        return codeBlock->jitType() == JITType::BaselineJIT;
    }
    default:
        dataLog("Unexpected code block in LLInt: ", *codeBlock, "\n");
        RELEASE_ASSERT_NOT_REACHED();
        return false;
    }
}

The function performs a simple check to determine if the codeBlock supplied needs to be JIT compiled and if compilation is required initiates a compilation thread with the call to JITWorkList::compileLater:

JITWorklist::ensureGlobalWorklist().compileLater(codeBlock, loopOSREntryBytecodeIndex);
return codeBlock->jitType() == JITType::BaselineJIT;

Since concurrent JIT is disabled (from adding the --useConcurrentJIT=false flag), the function JITWorkList::compileLater calls Plan::compileNow to initiate compilation on the main jsc thread:

static void compileNow(CodeBlock* codeBlock, BytecodeIndex loopOSREntryBytecodeIndex)
    {
        Plan plan(codeBlock, loopOSREntryBytecodeIndex);
        plan.compileInThread();
        plan.finalize();
    }

The function Plan::compileInThread ends up calling JIT::compileWithoutLinking which essentially compiles the codeblock by utilising the MacroAssemblers to emit specific machine code for each bytecode in the instruction stream. The function compileWithoutLinking is listed below with the unimportant code truncated out:

void JIT::compileWithoutLinking(JITCompilationEffort effort)
{
    //... code truncated for brevity
    
    m_pcToCodeOriginMapBuilder.appendItem(label(), CodeOrigin(BytecodeIndex(0)));

    //... code truncated for brevity

    emitFunctionPrologue();
    emitPutToCallFrameHeader(m_codeBlock, CallFrameSlot::codeBlock);

    //... code truncated for brevity

    move(regT1, stackPointerRegister);
    checkStackPointerAlignment();

    emitSaveCalleeSaves();
    emitMaterializeTagCheckRegisters();

    //... code truncated for brevity

    privateCompileMainPass();
    privateCompileLinkPass();
    privateCompileSlowCases();
    
    //... code truncated for brevity

    m_bytecodeIndex = BytecodeIndex(0);

    //... code truncated for brevity
    
    privateCompileExceptionHandlers();
    
    //... code truncated for brevity

    m_pcToCodeOriginMapBuilder.appendItem(label(), PCToCodeOriginMapBuilder::defaultCodeOrigin());

    m_linkBuffer = std::unique_ptr<LinkBuffer>(new LinkBuffer(*this, m_codeBlock, effort));

    //... code truncated for brevity
}

The first few function calls emitFunctionPrologue() up until emitMaterializeTagCheckRegisters() emit machine code to perform stack management routines to be included in the Baseline JIT compiled code.

A handy setting to enable with the codebase to allow tracing of the various compilation passes would be the JITInternal::verbose flag.

namespace JITInternal {
static constexpr const bool verbose = true;
}

By enabling this flag, each bytecode being compiled would now be logged to stdout. This should look something similar to the snippet below:

Compiling <global>#DETOqr:[0x7fffae3c4000->0x7fffeedcb768, NoneGlobal, 43]
Baseline JIT emitting code for bc#0 at offset 168
At 0: 0
Baseline JIT emitting code for bc#1 at offset 294
At 1: 0
Baseline JIT emitting code for bc#3 at offset 306
At 3: 0
Baseline JIT emitting code for bc#6 at offset 314
//... truncated for brevity

The first interesting function call is privateCompileMainPass().

void JIT::privateCompileMainPass()
{
    //... truncated for brevity

    auto& instructions = m_codeBlock->instructions();
    unsigned instructionCount = m_codeBlock->instructions().size();

    m_callLinkInfoIndex = 0;

    VM& vm = m_codeBlock->vm();
    BytecodeIndex startBytecodeIndex(0);
    
    //... code truncated for brevity

    m_bytecodeCountHavingSlowCase = 0;
    for (m_bytecodeIndex = BytecodeIndex(0); m_bytecodeIndex.offset() < instructionCount; ) {
        unsigned previousSlowCasesSize = m_slowCases.size();
        if (m_bytecodeIndex == startBytecodeIndex && startBytecodeIndex.offset() > 0) {
            // We've proven all bytecode instructions up until here are unreachable.
            // Let's ensure that by crashing if it's ever hit.
            breakpoint();
        }

        //... code truncated for brevity
        const Instruction* currentInstruction = instructions.at(m_bytecodeIndex).ptr();

        //... code truncated for brevity
        
        OpcodeID opcodeID = currentInstruction->opcodeID();

        //... code truncated for brevity

        unsigned bytecodeOffset = m_bytecodeIndex.offset();
        
        //... code truncated for brevity

        switch (opcodeID) {
        
        //... code truncated for brevity

        DEFINE_OP(op_del_by_id)
        DEFINE_OP(op_del_by_val)
        DEFINE_OP(op_div)
        DEFINE_OP(op_end)
        DEFINE_OP(op_enter)
        DEFINE_OP(op_get_scope)
        
        //... code truncated for brevity

        DEFINE_OP(op_lshift)
        DEFINE_OP(op_mod)
        DEFINE_OP(op_mov)
        //... code truncated for brevity
        default:
            RELEASE_ASSERT_NOT_REACHED();
        }

        //... code truncated for brevity
    }
}

The function loops over the bytecodes and calls the relevant JIT opcode for each bytecode. For example the first bytecode to be evaluated is op_enter which, via the switch case DEFINE_OP(op_enter), calls the function JIT::emit_op_enter. Let’s trace the mov opcode at bc#3, which moves the value in loc4 into loc5:

[   3] mov                loc5, loc4

setting a breakpoint at DEFINE_OP(op_mov) and stepping into the function call leads to JIT::emit_op_mov

void JIT::emit_op_mov(const Instruction* currentInstruction)
{
    auto bytecode = currentInstruction->as<OpMov>();
    VirtualRegister dst = bytecode.m_dst;
    VirtualRegister src = bytecode.m_src;

    if (src.isConstant()) {
        JSValue value = m_codeBlock->getConstant(src);
        if (!value.isNumber())
            store64(TrustedImm64(JSValue::encode(value)), addressFor(dst));
        else
            store64(Imm64(JSValue::encode(value)), addressFor(dst));
        return;
    }

    load64(addressFor(src), regT0);
    store64(regT0, addressFor(dst));
}

The functions load64 and store64 are defined in assembler/MacroAssemblerX86_64.h. The functions call an assembler which is responsible for emitting machine code for the operation. Lets examine the following load64 call:

void load64(ImplicitAddress address, RegisterID dest)
{
    m_assembler.movq_mr(address.offset, address.base, dest);
}

The function movq_mr is defined in X86Assembler.h as follows:

void movq_mr(int offset, RegisterID base, RegisterID dst)
    {
        m_formatter.oneByteOp64(OP_MOV_GvEv, dst, base, offset);
    }

The function oneByteOp64 listed above finally generates the machine code that gets written to an instruction buffer:

void oneByteOp64(OneByteOpcodeID opcode, int reg, RegisterID base, int offset)
{
            SingleInstructionBufferWriter writer(m_buffer);
            writer.emitRexW(reg, 0, base);
            writer.putByteUnchecked(opcode);
            writer.memoryModRM(reg, base, offset);
}

In this fashion, each bytecode is processed by the function JIT::privateCompileMainPass to emit Baseline JIT optimised machine code. The second function that needs to be considered is JIT::privateCompileLinkPass, which is responsible for adjusting the jump table to ensure the optimised bytecodes can reach the right execution branches (e.g. labels):

void JIT::privateCompileLinkPass()
{
    unsigned jmpTableCount = m_jmpTable.size();
    for (unsigned i = 0; i < jmpTableCount; ++i)
        m_jmpTable[i].from.linkTo(m_labels[m_jmpTable[i].toBytecodeOffset], this);
    m_jmpTable.clear();
}

Once the jump table has been re-linked appropriately, the next function of note to be called is JIT::privateCompileSlowCases.

Fast Path/Slow Path

As seen in previous sections when reviewing the LLInt, some opcodes define two types of execution paths: fast path and slow paths. The Baseline JIT when compiling bytecodes performs additional optimisations on opcodes that implement fast and slow paths. This compilation phase is performed by the call to JIT::privateCompileSlowCases:

void JIT::privateCompileSlowCases()
{
    m_getByIdIndex = 0;
    m_getByValIndex = 0;
    m_getByIdWithThisIndex = 0;
    m_putByIdIndex = 0;
    m_inByIdIndex = 0;
    m_delByValIndex = 0;
    m_delByIdIndex = 0;
    m_instanceOfIndex = 0;
    m_byValInstructionIndex = 0;
    m_callLinkInfoIndex = 0;

    //... code truncated for brevity
    unsigned bytecodeCountHavingSlowCase = 0;
    for (Vector<SlowCaseEntry>::iterator iter = m_slowCases.begin(); iter != m_slowCases.end();) {
        m_bytecodeIndex = iter->to;

        //... code truncated for brevity

        BytecodeIndex firstTo = m_bytecodeIndex;

        const Instruction* currentInstruction = m_codeBlock->instructions().at(m_bytecodeIndex).ptr();
        
        //... code truncated for brevity

        switch (currentInstruction->opcodeID()) {
        DEFINE_SLOWCASE_OP(op_add)
        DEFINE_SLOWCASE_OP(op_call)
        //... code truncated for brevity
        DEFINE_SLOWCASE_OP(op_jstricteq)
        case op_put_by_val_direct:
        DEFINE_SLOWCASE_OP(op_put_by_val)
        DEFINE_SLOWCASE_OP(op_del_by_val)
        DEFINE_SLOWCASE_OP(op_del_by_id)
        DEFINE_SLOWCASE_OP(op_sub)
        DEFINE_SLOWCASE_OP(op_has_indexed_property)
        DEFINE_SLOWCASE_OP(op_get_from_scope)
        DEFINE_SLOWCASE_OP(op_put_to_scope)

        //... code truncated for brevity
        default:
            RELEASE_ASSERT_NOT_REACHED();
        }

        //... code truncated for brevity

        emitJumpSlowToHot(jump(), 0);
        ++bytecodeCountHavingSlowCase;
    }

    //... code truncated for brevity
}

The function iterates over bytecodes that implement a slow path and emit machine code for each of these opcodes and also updates the jump table as required. Tracing the execution of emitted machine code for opcodes that implement a slow path is left to the reader as an exercise.

Linking

Once the codeblock has been successfully compiled, the next step is to link the machine code emitted by the assembler in order for the LLInt to OSR into the Baseline JIT optimised code. This beings by generating a LinkBuffer for the codeblock:

m_linkBuffer = std::unique_ptr<LinkBuffer>(new LinkBuffer(*this, m_codeBlock, effort));

The developer comments have the following to note about LinkBuffer:

LinkBuffer:

This class assists in linking code generated by the macro assembler, once code generation has been completed, and the code has been copied to is final location in memory. At this time pointers to labels within the code may be resolved, and relative offsets to external addresses may be fixed.

Specifically:

Jump objects may be linked to external targets,

The address of Jump objects may taken, such that it can later be relinked.

The return address of a Call may be acquired.

The address of a Label pointing into the code may be resolved.

The value referenced by a DataLabel may be set.

Initialisation of the LinkBuffer, eventually leads to a call to LinkBuffer::linkCode which is listed below:

void LinkBuffer::linkCode(MacroAssembler& macroAssembler, JITCompilationEffort effort)
{
    //... code truncated for brevity
    allocate(macroAssembler, effort);
    if (!m_didAllocate)
        return;
    ASSERT(m_code);
    AssemblerBuffer& buffer = macroAssembler.m_assembler.buffer();
    void* code = m_code.dataLocation();
    //... code truncated for brevity

    performJITMemcpy(code, buffer.data(), buffer.codeSize());

    //.. code truncated for brevity
    m_linkTasks = WTFMove(macroAssembler.m_linkTasks);
}

The key function in the snippet above is performJITMemcpy, which is a wrapper to memcpy. The emitted unlinked machine code which is stored in the assembler buffer is is copied over to the LinkeBuffer which is pointed to via code:

performJITMemcpy(code, buffer.data(), buffer.codeSize());

Once the LinkBuffer has been populated, the machine code is linked with the call to JIT::link which is invoked from JITWorklist::Plan::finalize:

CompilationResult JIT::link()
{
    LinkBuffer& patchBuffer = *m_linkBuffer;
    
    if (patchBuffer.didFailToAllocate())
        return CompilationFailed;

    // Translate vPC offsets into addresses in JIT generated code, for switch tables.
    for (auto& record : m_switches) {
        //... code to handle swtich cases truncated for brevity
    }

    for (size_t i = 0; i < m_codeBlock->numberOfExceptionHandlers(); ++i) {
        //... code to handle exception handlers truncated for brevity
    }

    for (auto& record : m_calls) {
        if (record.callee)
            patchBuffer.link(record.from, record.callee);
    }
    
    finalizeInlineCaches(m_getByIds, patchBuffer);
    finalizeInlineCaches(m_getByVals, patchBuffer);
    finalizeInlineCaches(m_getByIdsWithThis, patchBuffer);
    finalizeInlineCaches(m_putByIds, patchBuffer);
    finalizeInlineCaches(m_delByIds, patchBuffer);
    finalizeInlineCaches(m_delByVals, patchBuffer);
    finalizeInlineCaches(m_inByIds, patchBuffer);
    finalizeInlineCaches(m_instanceOfs, patchBuffer);

    //... code truncated for brevity

    {
        JITCodeMapBuilder jitCodeMapBuilder;
        for (unsigned bytecodeOffset = 0; bytecodeOffset < m_labels.size(); ++bytecodeOffset) {
            if (m_labels[bytecodeOffset].isSet())
                jitCodeMapBuilder.append(BytecodeIndex(bytecodeOffset), patchBuffer.locationOf<JSEntryPtrTag>(m_labels[bytecodeOffset]));
        }
        m_codeBlock->setJITCodeMap(jitCodeMapBuilder.finalize());
    }

    MacroAssemblerCodePtr<JSEntryPtrTag> withArityCheck = patchBuffer.locationOf<JSEntryPtrTag>(m_arityCheck);

    //... code truncated for brevity

    CodeRef<JSEntryPtrTag> result = FINALIZE_CODE(
        patchBuffer, JSEntryPtrTag,
        "Baseline JIT code for %s", toCString(CodeBlockWithJITType(m_codeBlock, JITType::BaselineJIT)).data());

    //... code truncated for brevity

    m_codeBlock->setJITCode(
        adoptRef(*new DirectJITCode(result, withArityCheck, JITType::BaselineJIT)));

    if (JITInternal::verbose)
        dataLogF("JIT generated code for %p at [%p, %p).\n", m_codeBlock, result.executableMemory()->start().untaggedPtr(), result.executableMemory()->end().untaggedPtr());

    return CompilationSuccessful;
}

Once linking has completed, a reference pointer to the JITed code is set in the codeblock. The Baseline JIT optimised code is now ready to be executed. The call stack at this point should resemble something similar to the snippet below:

libJavaScriptCore.so.1!JSC::JIT::link(JSC::JIT * const this) (/home/amar/workspace/WebKit/Source/JavaScriptCore/jit/JIT.cpp:970)
libJavaScriptCore.so.1!JSC::JITWorklist::Plan::finalize(JSC::JITWorklist::Plan * const this) (/home/amar/workspace/WebKit/Source/JavaScriptCore/jit/JITWorklist.cpp:55)
libJavaScriptCore.so.1!JSC::JITWorklist::Plan::compileNow(JSC::CodeBlock * codeBlock, JSC::BytecodeIndex loopOSREntryBytecodeIndex) (/home/amar/workspace/WebKit/Source/JavaScriptCore/jit/JITWorklist.cpp:87)
libJavaScriptCore.so.1!JSC::JITWorklist::compileLater(JSC::JITWorklist * const this, JSC::CodeBlock * codeBlock, JSC::BytecodeIndex loopOSREntryBytecodeIndex) (/home/amar/workspace/WebKit/Source/JavaScriptCore/jit/JITWorklist.cpp:238)
libJavaScriptCore.so.1!JSC::LLInt::jitCompileAndSetHeuristics(JSC::VM & vm, JSC::CodeBlock * codeBlock, JSC::BytecodeIndex loopOSREntryBytecodeIndex) (/home/amar/workspace/WebKit/Source/JavaScriptCore/llint/LLIntSlowPaths.cpp:386)
libJavaScriptCore.so.1!JSC::LLInt::llint_loop_osr(JSC::CallFrame * callFrame, const JSC::Instruction * pc) (/home/amar/workspace/WebKit/Source/JavaScriptCore/llint/LLIntSlowPaths.cpp:481)
libJavaScriptCore.so.1!llint_op_loop_hint() (/home/amar/workspace/WebKit/Source/JavaScriptCore/llint/LowLevelInterpreter64.asm:97)
[Unknown/Just-In-Time compiled code] (Unknown Source:0)

One can dump the disassembly of the JITed code by adding the --dumpDisassembly=true flag to launch.json or to the commandline. The disassembly for the compiled bytecodes printed to stdout would appear as follows:

Generated Baseline JIT code for <global>#DETOqr:[0x7fffae3c4000->0x7fffeedcb768, BaselineGlobal, 43], instructions size = 43
   Source: for(let x = 0; x < 5; x++){ let y = x+10; }
   Code at [0x7fffaecff680, 0x7fffaecfffc0):
          0x7fffaecff680: nop 
          0x7fffaecff681: push %rbp
          0x7fffaecff682: mov %rsp, %rbp
          0x7fffaecff685: mov $0x7fffae3c4000, %r11
          #... truncated for brevity
    [   0] enter              
          0x7fffaecff728: push %rax
          0x7fffaecff729: mov $0x7ffff4f69936, %rax
          0x7fffaecff733: push %rcx
          #... truncated for brevity
    [   1] get_scope          loc4
          0x7fffaecff7d4: push %rax
          0x7fffaecff7d5: mov $0x7ffff4f69936, %rax
          0x7fffaecff7df: push %rcx
          #... truncated for brevity
    [  23] loop_hint          
          0x7fffaecff9a8: push %rax
          0x7fffaecff9a9: mov $0x7ffff4f69936, %rax
          0x7fffaecff9b3: push %rcx
          0x7fffaecff9b4: mov $0x7ffff4f6a88b, %rcx
          0x7fffaecff9be: push %rdx
          0x7fffaecff9bf: mov $0x7ffff4f63e72, %rdx
          0x7fffaecff9c9: push %rbx
          0x7fffaecff9ca: mov $0x7fffeedfe628, %rbx
          0x7fffaecff9d4: call *%rax
    (End Of Main Path)
    (S) [   6] check_traps        
          0x7fffaecffb70: push %rax
          0x7fffaecffb71: mov $0x7ffff4f69936, %rax
          0x7fffaecffb7b: push %rcx
          0x7fffaecffb7c: mov $0x7ffff4f6a88b, %rcx
          #... truncated for brevity
    (S) [  28] add                loc8, loc7, Int32: 10(const4), OperandTypes(126, 3)
          0x7fffaecffd0d: push %rax
          0x7fffaecffd0e: mov $0x7ffff4f69936, %rax
          0x7fffaecffd18: push %rcx
          #... truncated for brevity
    (S) [  34] inc                loc7
          0x7fffaecffd99: push %rax
          0x7fffaecffd9a: mov $0x7ffff4f69936, %rax
          0x7fffaecffda4: push %rcx
          #... truncated for brevity
    (S) [  37] jless              loc7, Int32: 5(const3), -14(->23)
          0x7fffaecffe10: push %rax
          0x7fffaecffe11: mov $0x7ffff4f69936, %rax
          0x7fffaecffe1b: push %rcx
          0x7fffaecffe1c: mov $0x7ffff4f6a88b, %rcx
          0x7fffaecffe26: push %rdx
          #... truncated for brevity
    (End Of Slow Path)
          0x7fffaecffec5: mov $0x7fffae3c4000, %rdi
          0x7fffaecffecf: mov $0x0, 0x24(%rbp)
          0x7fffaecffed6: mov $0x7fffaeb09fd8, %r11
          #... truncated for brevity
JIT generated code for 0x7fffae3c4000 at [0x7fffaecff680, 0x7fffaecfffc0).

JIT Execution

Stepping back up the call stack, execution returns to llint_loop_osr. The compiled and linked machine code is now referenced by codeBlock and to complete the OSR to the JITed code, the engine needs to retrieve the executableAddress to the JITed code and have the LLInt jump to this address and continue execution:

if (!jitCompileAndSetHeuristics(vm, codeBlock, loopOSREntryBytecodeIndex))
        LLINT_RETURN_TWO(nullptr, nullptr);
    
    //... code truncated for brevity

    const JITCodeMap& codeMap = codeBlock->jitCodeMap();
    CodeLocationLabel<JSEntryPtrTag> codeLocation = codeMap.find(loopOSREntryBytecodeIndex);

    void* jumpTarget = codeLocation.executableAddress();
    
    LLINT_RETURN_TWO(jumpTarget, callFrame->topOfFrame());

The snippet code demonstrates how the engine first retrieves a codeMap of the compiled codeBlock and then looks up the codeLocation of the bytecode index that OSR entry is to be performed. In our example, this is the loop_hint bytecode index. The executable address is retrieved from codeLocation and along with the callFrame is passed as arguments to LLINT_RETURN_TWO. The call to LLINT_RETURN_TWO returns execution back to the checkSwitchToJITForLoop:

macro checkSwitchToJITForLoop()
    checkSwitchToJIT(
        1,
        macro()
            storePC()
            prepareStateForCCall()
            move cfr, a0
            move PC, a1
            cCall2(_llint_loop_osr)
            btpz r0, .recover      <-- execution returns here after Baseline JIT compilation
            move r1, sp
            jmp r0, JSEntryPtrTag  <-- jump to JITed code
        .recover:
            loadPC()
        end)
end

Setting a breakpoint at jmp r0, JSEntryPtrTag and inspecting the value of r0 (which is rax), it is observed that it contains the executable address into our JITed code. More specifically the executable address to the start of the compiled loop_hint bytecode.

One can enable tracing execution of our compiled code in the Baseline JIT by adding the "--traceBaselineJITExecution=true" flag to launch.json or on the commandline. This will force the Baseline JIT to insert tracing probes in the compiled code. These logging probes will print to stdout:

Optimized <global>#DETOqr:[0x7fffae3c4000->0x7fffeedcb768, LLIntGlobal, 43] with Baseline JIT into 2368 bytes in 1.509752 ms.
JIT generated code for 0x7fffae3c4000 at [0x7fffaecff680, 0x7fffaecfffc0).
    JIT compilation successful.
Installing <global>#DETOqr:[0x7fffae3c4000->0x7fffeedcb768, BaselineGlobal, 43]
JIT [23] op_loop_hint cfr 0x7fffffffcb40 @ <global>#DETOqr:[0x7fffae3c4000->0x7fffeedcb768, BaselineGlobal, 43]
JIT [24] op_check_traps cfr 0x7fffffffcb40 @ <global>#DETOqr:[0x7fffae3c4000->0x7fffeedcb768, BaselineGlobal, 43]
JIT [25] op_mov cfr 0x7fffffffcb40 @ <global>#DETOqr:[0x7fffae3c4000->0x7fffeedcb768, BaselineGlobal, 43]
JIT [28] op_add cfr 0x7fffffffcb40 @ <global>#DETOqr:[0x7fffae3c4000->0x7fffeedcb768, BaselineGlobal, 43]
JIT [34] op_inc cfr 0x7fffffffcb40 @ <global>#DETOqr:[0x7fffae3c4000->0x7fffeedcb768, BaselineGlobal, 43]
JIT [37] op_jless cfr 0x7fffffffcb40 @ <global>#DETOqr:[0x7fffae3c4000->0x7fffeedcb768, BaselineGlobal, 43]
JIT [41] op_end cfr 0x7fffffffcb40 @ <global>#DETOqr:[0x7fffae3c4000->0x7fffeedcb768, BaselineGlobal, 43]

Profiling Tiers

As bytecode is executed in the LLInt and in the Baseline JIT tier, the two JIT tiers gather profile data on the bytecodes being executed which is then propagated to the higher optimising JIT tiers (i.e. DFG and FTL). Profiling aids in speculative compilation³ which is a key aspect of JIT engine optimisations. The Profiling section³ of the WebKit blog does an excellent job of describing the need for profiling, the philosophy behind JavaScriptCore’s profiling goals and details on profiling implementation in the two profiling tiers. It is recommended that the reader first familiarise themselves with this before continuing with the rest of this section.

To re-iterate, the key design goals of profiling in JavaScriptCore are summarised in the excerpt below³:

Profiling needs to focus on noting counterexamples to whatever speculations we want to do. We don’t want to speculate if profiling tells us that the counterexample ever happened, since if it ever happened, then the effective value of this speculation is probably negative. This means that we are not interested in collecting probability distributions. We just want to know if the bad thing ever happened.

Profiling needs to run for a long time. It’s common to wish for JIT compilers to compile hot functions sooner. One reason why we don’t is that we need about 3-4 “nines” of confidence that that the counterexamples didn’t happen. Recall that our threshold for tiering up into the DFG is about 1000 executions. That’s probably not a coincidence.

Profiling Sources

The profiling tier gathers profiling data from six main sources these are listed as follows³:

Case Flags – support branch speculation
Case Counts – support branch speculation
Value Profiling – type inference of values
Inline Caches – type inference of object structure
Watchpoints – support heap speculation
Exit Flags – support speculation backoff

Case Flags aid branch speculation and the engine uses bit flags to determine if a branch was taken and speculate accordingly. Case Counts are a legacy version of Case Flags where instead of setting a bit flag, it would count the number of times a branch was taken. This approach proved less optimal (details of which are discussed in the webkit blog³) and with a few exceptions this profiling method has largely been made obsolete. Tracing the add opcode is good exercise in exploring how Case Flags function.

Value profiling is the most common profiling method used by JavaScriptCore. Since JavaScript is a dynamic language, JavaScriptCore needs a way to infer the runtime types of the raw values (e.g. integers, doubles, strings, objects, etc) being used by the program. In order to do this JavaScriptCore encode raw values by a process called NaN-boxing which allows the engine to infer the type of data being operated on. This encoding mechanism is documented in JavaScriptJSValue.h.

Inline Caches play a huge role not only in speculative compilation but also in optimising property access and function calls. Inline caches allow the engine to infer the type of a value based on the operation that was performed (e.g. property access and function calls). Discussing the subject of Inline caches would take a blog post in itself and indeed the webkit blog³ devotes a fair chunk of it to discussing Inline Caches in great detail and the speculation it allows JavaScriptCore to perform. It is highly recommended that the reader take the time to explore Inline Caches as an exercise.

Both Watchpoints and Exit Flags become more relevant when exploring the optimising tiers in later parts of this blog series. For the moment it is sufficient to briefly describe them as defined in the webkit blog³:

A watchpoint in JavaScriptCore is nothing more than a mechanism for registering for notification that something happened. Most watchpoints are engineered to trigger only the first time that something bad happens; after that, the watchpoint just remembers that the bad thing had ever happened.

watchpoints let inline caches and the speculative compilers fold certain parts of the heap’s state to constants by getting a notification when things change.

Previous this post touched upon Exit counts briefly in the Tiering Up section of the LLInt, Exit flags are functionally similar in the sense that they record why an OSR Exit occurred. The WebKit blog summarise Exit flags as follows:

The exit flags are a check on the rest of the profiler. They are telling the compiler that the profiler had been wrong here before, and as such, shouldn’t be trusted anymore for this code location.

Given the length of this blog post, a conscious decision was made to avoid deep dives into each of these profiling methods. To reiterate a point made earlier, its is recommended that the reader utilise the WebKit blog³ and the debugging methodology demonstrated in this blog to explore the various profiling methods themselves.

JavaScriptCore Profiler

The jsc shell provides a commandline line option to record profiling information for the code being executed, which can then be parsed into a human readable format. This can be achieved by adding the -p to the commandline args. The profiler captures data from the sources mentioned in the previous section and stores them as serialised JSON. This profile data can then be parsed using the display-profiler-output script which allows examining various aspects of the profiled information⁵ ⁶.

Let’s enable profiling in our debugging environment by adding the -p flag to the commandline arguments. Note this can also be setup by adding the --enableProfiler=true commandline flag and setting up the environment variable JavaScript_PROFILER_PATH to output the profile data. Updating launch.json to enable profile data gathering should be similar to the one below:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(gdb) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "/home/amar/workspace/WebKit/WebKitBuild/Debug/bin/jsc",
            "args": [ "--useDFGJIT=false", "-p", "/home/amar/workspace/WebKit/WebKitBuild/Debug/bin/profile_data.json", "/home/amar/workspace/WebKit/WebKitBuild/Debug/bin/test.js"],
            //... truncated for brevity
        }
    ]
}

Let’s now use the following test script to capture some profiling information. The one below will generate value profiling information for the add function:

$ cat test.js

function add(x,y){
    return x+y;
}

let x = 1;

for(let y = 0; y < 1000; y++){
    add(x,y)
}

In the snippet above the add function takes two arguments x and y. This function is called several times in the for loop to trigger Baseline JIT optimisation. From static inspection of the js code above we can determine that the arguments x and y are going to be Int32 values. Now let’s review the profile data collected for the js code above with display-profiler-output:

~/workspace/WebKit$ ./Tools/Scripts/display-profiler-output ./WebKitBuild/Debug/bin/profile_data.json

   CodeBlock    #Instr  Source Counts         Machine Counts      #Compil  Inlines     #Exits      Last Opts    Source                                                                            
                       Base/DFG/FTL/FTLOSR  Base/DFG/FTL/FTLOSR                       Src/Total   Get/Put/Call
  add#DzQYpR      15      967/0/0/0             967/0/0/0               1    0/0       0             0/0/0     function add(x,y){ return x+y; }
<global>#D5ICt4  116      506/0/0/0             506/0/0/0               1    0/0       0             0/0/0     function add(x,y){ return x+y; } let x = 1; for(let y = 0; y < 1000; y++){ add(x,y) }
>

This prints statistics on the execution counts of the various codeblocks that were generated, the number compilations that occurred, Exit counts, etc. It also drops into a prompt that allows us to query additional information on the profile data gathered. The help command outputs the various supported options:

> help
summary (s)     Print a summary of code block execution rates.
full (f)        Same as summary, but prints more information.
source          Show the source for a code block.
bytecode (b)    Show the bytecode for a code block, with counts.
profiling (p)   Show the (internal) profiling data for a code block.
log (l)         List the compilations, exits, and jettisons involving this code block.
events (e)      List of events involving this code block.
display (d)     Display details for a code block.
inlines         Show all inlining stacks that the code block was on.
counts          Set whether to show counts for 'bytecode' and 'display'.
sort            Set how to sort compilations before display.
help (h)        Print this message.
quit (q)        Quit.
>

To output the profiling data collected for the codeblock use the profiling command:

> p DzQYpR
Compilation add#DzQYpR-1-Baseline:
      arg0: predicting OtherObj
      arg1: predicting BoolInt32
      arg2: predicting NonBoolInt32
        [   0] enter              
        [   1] get_scope          loc4
        [   3] mov                loc5, loc4
        [   6] check_traps        
        [   7] add                loc6, arg1, arg2, OperandTypes(126, 126)
        [  13] ret                loc6
>

arg1 and arg2 represent the argument variables x and y in our test script. From the snippet above, one can see that the profile information gathered for the two arguments. JavaScriptCore has predicted that that arg1 could either be a Bool or an Int32 value and that arg2 can be a NonBool or an Int32 value.

Let’s attempt to modify the script to supply a mix of argument types to the add function:

$ cat test.js

function add(x,y){
    return x+y;
}

let x = 1.0;

for(let y = 0.1; y < 1000; y++){
    add(x,y)
}

The arguments x and y would now be passed floating point values. Lets re-generate profiling data and examine the predicted values:

~/workspace/WebKit$ ./Tools/Scripts/display-profiler-output ./WebKitBuild/Debug/bin/profile_data.json
   CodeBlock    #Instr  Source Counts       Machine Counts      #Compil  Inlines        #Exits     Last Opts    Source                                                                                           
                       Base/DFG/FTL/FTLOSR Base/DFG/FTL/FTLOSR                        Src/Total   Get/Put/Call
  add#DzQYpR      15      967/0/0/0             967/0/0/0              1       0/0       0          0/0/0        function add(x,y){ return x+y; }
<global>#AYjpyE  116      506/0/0/0             506/0/0/0              1       0/0       0          0/0/0        function add(x,y){ return x+y; } let x = 1.0; for(let y = 0.1; y < 1000; y++){ add(x,y) }
> p DzQYpR
Compilation add#DzQYpR-1-Baseline:
      arg0: predicting OtherObj
      arg1: predicting AnyIntAsDouble
      arg2: predicting NonIntAsDouble
        [   0] enter              
        [   1] get_scope          loc4
        [   3] mov                loc5, loc4
        [   6] check_traps        
        [   7] add                loc6, arg1, arg2, OperandTypes(126, 126)
        [  13] ret                loc6
>

As seen in the output above the predicted types for x and y are now any AnyIntAsDouble and NonIntAsDouble. The definitions for the various speculated types can be found in SpeculatedType.h which is generated at compile time and is located under /Debug/DerivedSources/ForwardingHeaders/JavaScriptCore/SpeculatedType.h. The table below⁷ shows the unique speculation types used in JavaScriptCore:

Conclusion

This post explored the LLInt and the Baseling JIT by diving into the details of their implementation and tracing execution of bytecodes in the two tiers. The post also provided an overview of offlineasm assembly and how to understand the LLInt implementation that is written in this assembly. With the understanding of how the LLInt is constructed and how execution in the LLInt works, the post discussed OSR which is the mechanism that allows execution to transition from a lower tier to a higher JIT tier. Finally the blog post concluded by briefly touching upon the subject of profiling bytecode and the various sources used by the engine to gather profiling data.

In Part III of this blog series dives into the details of the Data Flow Graph (DFG). The DFG is the first of two optimising compilers used by JavaScriptCore and the post will explore the process of tiering up from the Baseline JIT into the DFG, the DFG IR and the DFG compiler pipeline.

We hope you’ve found this post informative, if you have questions, spot something that’s incorrect or have suggestions on improving this writeup do reach out to the author @amarekano or @Zon8Research on Twitter. We are more than happy to discuss this at length with anyone interested in this subject and would love to hear your thoughts on it.

Appendix

JavaScriptCore Internals Part I: Tracing JavaScript Source to Bytecode

Sun, 08 Nov 2020 00:00:00 +0000

Introduction

Fuzzing Webkit’s JavaScriptCore (JSC) with Fuzzilli proved to be quite successful and produced a fair number of crashes over time. However, once a crash was detected, triaging the crashes for exploitability took a fair bit of time due to unfamiliarity with the WebKit codebase and the lack of easily available documentation on navigating the codebase. This motivated the creation of this blog series to dig into the internals of JSC and hopefully be useful to others who wish to bootstrap their knowledge on the engine. This blogpost series is also aimed at security researchers to help them navigate aspects of the engine that are relevant for vulnerability research.

Part I of this series explores how source code is parsed and converted to bytecode and trace this journey through the codebase. The image, reproduced from a presentation on JSC¹, below describes the three aspects of this pipeline that will be cover as part of the blog post.

This post will cover the source code parser in JSC, the bytecode compiler which takes an AST (Abstract Syntax Tree) generated at the end of the parsing phase and emit bytecode from it. The bytecode is the source of truth for the engine and is one of the key inputs to the various Just-In-Time (JIT) compilers in JSC. This post will explore generated bytecode and help understand some of the opcodes and their operands. Finally, the post concludes by touching upon bytecode execution by the Low Level Interpreter (LLInt). Part II of this blog series will dive into the details of Low Level Interpreter (LLInt) and the Baseline JIT.

Existing Work

An excellent talk on JSC architecture and JIT tiers that is highly recommended is Michael Saboff — JavaScriptCore, many compilers make this engine perform. Whilst it does not go into the internals of each JIT tier, it does provide an overview and the various optimisation techniques and profiling methods employed by the engine.

Another useful blog that on navigating the codebase was this WebKit wiki. This did provide a useful highlevel overview of the engine but lacked sufficient detail.

Saelo’s phrack paper on “Attacking JavaScript Engines: A case study of JavaScriptCore and CVE-2016-4622” is another good read to familiarise oneself with the JSC runtime which he discusses in the various sections of his research.

Getting Started

This section will demonstrate setting up a debugging environment and compile a debug build of the jsc shell utility. A working debugging environment will be important in being able to navigate the JSC codebase and examine various aspects of the engine execution at runtime.

Generating a debug build

The instructions below will clone the webkit repository mirrored on github and compile a debug build for the jsc shell.

$ git clone git://git.webkit.org/WebKit.git && cd WebKit
$ Tools/gtk/install-dependencies
$ Tools/Scripts/build-webkit --jsc-only --debug
$ cd WebKitBuild/Debug/bin/
$ ./jsc

Setting up a debugging environment

Once a debug binary has been generated, it is time to configure an IDE (Integrated Developement Environment) and debugger for code review and stepping through the execution of the engine. This post will use vscode with ccls for code review and integrated with gdb for interactive debugging. However, the reader is free to use an IDE and debugger that they are most comfortable with. Should the reader decide to continue with vscode and ccls, the following launch task will need to be added to launch.json in vscode. Note: Do ensure that the file paths (i.e. program and args) listed in the snippet below are appropriately modified to reflect the target debugging environment.

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(gdb) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "/home/amar/workspace/WebKit/WebKitBuild/Debug/bin/jsc",
            "args": ["--dumpGeneratedBytecodes=true", "--useJIT=false","/home/amar/workspace/WebKit/WebKitBuild/Debug/bin/test.js"],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": false,
            "MIMode": "gdb",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                }
            ],
            "preLaunchTask": "WebKit Debug Build"
        }
    ]
}

An optional but handy build task was added to launch configuration that would build jsc before launching the debugger. This step is optional but it’s generally a good idea to have the codebase in sync with the debug builds being generated. The build task added to tasks.json is listed below:

{
    "version": "2.0.0",
    "tasks": [
        {
            "label": "WebKit Debug Build",
            "type": "shell",
            "command": "/home/amar/workspace/WebKit/Tools/Scripts/build-jsc --jsc-only --debug"
        }
    ]
}

Should all go to plan, the debugging environment should now allow launching gdb (F5 in vscode) and hit breakpoints that have been setup like in the screenshot shown below:

JSC shell

This section will discuss the jsc shell that was generated in the previous section and its importance in being able to understand the engine internals. The jsc shell allows both researchers and developers to test JavaScriptCore as an independent library without the need to build the entire WebKit project. The jsc shell provides a Repeat-Eval-Print-Loop (REPL) environment for the javascript engine. In addition it also allows js scripts to be passed via the commandline, which is read by the jsc shell, parsed and executed by the engine.

The source code to the shell can be found in jsc.cpp

The entry point to the shell is jscmain. This function is responsible for initialising Web Template Framework (WTF), which is a set of commonly used functions from the Webkit codebase, and parsing options before a JSC vm can be created.

Initialisation of JSC begins with the call to runJSC which when invoked allocates memory for the VM object as well as initialises and retrieves a GlobalObject reference.

int runJSC(const CommandLine& options, bool isWorker, const Func& func)
{
    //... code truncated for brevity
    
    VM& vm = VM::create(LargeHeap).leakRef();
    //... code truncated for brevity
    
    GlobalObject* globalObject = nullptr;
    {
    //... code truncated for brevity
        globalObject = GlobalObject::create(vm, GlobalObject::createStructure(vm, jsNull()), options.m_arguments);
        globalObject->setRemoteDebuggingEnabled(options.m_enableRemoteDebugging);
        func(vm, globalObject, success);
        //... code truncated for brevity
    }
    //... code truncated for brevity

GlobalObject::create eventually ends up calling JSGlobalObject::init(VM& ) which is responsible to initialising the VM with the required builtins and other runtime setup activities. This post won’t go into the details of how the builtin code is parsed and linked to the VM but the interested reader should explore JavaScriptCore/builtins/ for all the builtin objects/constructors that form part of the JSC runtime. Alternatively, setting breakpoints and stepping through the execution of JSGlobalObject::init would be another approach.

Once VM and GlobalObject have been initialised, the lambda function, passed to runJSC is executed. The lambda function calls runWithOptions which takes three arguments; a pointer to the initialised GlobalObject, the commandline options passed to the jsc shell and a status variable.

runWithOptions’s primary goal is to create the necessary buffers to store the raw javascript that is supplied to the jsc shell. For the purpose of the blog the following script file (test.js) will be passed as a commandline parameter to jsc:

$ cat test.js 
let x = 10;
let y = 20;
let z = x + y;

$ ./WebKitBuild/Debug/bin/jsc test.js

Once the backing buffers have been setup and populated, the shell will now being evaluating and executing the script with a call to evaluate:

NakedPtr<Exception> evaluationException;
JSValue returnValue = evaluate(globalObject, jscSource(scriptBuffer, sourceOrigin , fileName), JSValue(), evaluationException);

In the snippet above scriptBuffer stores the contents of test.js passed via the commandline; sourceOrigin stores the URI to the script, which in this case is the absolute path to the script passed on the commandline. jscSource is a helper function that generates a SouceCode object from the scriptBuffer. The SourceCode object encapsulates the raw script data.

Runtime Setup

Now that the source code has been loaded into the engine via the jsc shell, the next step is to hand this over to the JSC engine and initiate processing of the loaded script. The function evaluate which is defined in runtime/Completion.cpp invokes executeProgram which is the point where the JSC engine takes over and begins processing:

JSValue evaluate(JSGlobalObject* globalObject, const SourceCode& source, JSValue thisValue, NakedPtr<Exception>& returnedException)
{
    VM& vm = globalObject->vm();
    
    //... code truncated for brevity

    JSObject* thisObj = jsCast<JSObject*>(thisValue.toThis(globalObject, ECMAMode::sloppy()));
    JSValue result = vm.interpreter->executeProgram(source, globalObject, thisObj);

    //... code truncated for brevity
    
    return result;
}

The function Interpreter::executeProgram performs three important tasks that will be the focal points of discussion throughout this blog post. The main tasks are as follows:

Initiating lexing and parsing of the sourcecode,
Generation of bytecode,
Execution of bytecode.

These have been highlighted in the truncated function code below:

JSValue Interpreter::executeProgram(const SourceCode& source, JSGlobalObject*, JSObject* thisObj)
{
    JSScope* scope = thisObj->globalObject()->globalScope();
    VM& vm = scope->vm();
    
    //.. truncated code

    ProgramExecutable* program = ProgramExecutable::create(globalObject, source);
    
    //... code truncated for brevity
    
    VMEntryScope entryScope(vm, globalObject);

    // Compile source to bytecode if necessary:
    JSObject* error = program->initializeGlobalProperties(vm, globalObject, scope); <-- 1. Initiates Lexing and Parsing of the source code
    
    //... code truncated for brevity

    ProgramCodeBlock* codeBlock;
    {
        CodeBlock* tempCodeBlock;
        Exception* error = program->prepareForExecution<ProgramExecutable>(vm, nullptr, scope, CodeForCall, tempCodeBlock); <-- 2. Generation of bytecode
        //... code truncated for brevity
        codeBlock = jsCast<ProgramCodeBlock*>(tempCodeBlock);
    }

    RefPtr<JITCode> jitCode;
    ProtoCallFrame protoCallFrame;
    {
        DisallowGC disallowGC; // Ensure no GC happens. GC can replace CodeBlock in Executable.
        jitCode = program->generatedJITCode();
        protoCallFrame.init(codeBlock, globalObject, globalCallee, thisObj, 1);
    }

    // Execute the code:
    //... code truncated for brevity
    JSValue result = jitCode->execute(&vm, &protoCallFrame); <-- 3. Execution of bytecode
    return checkedReturn(result);
}

The executeProgram beings by first allocating memory for the ProgramExecutable object and then calls the ProgramExecutable constructor with a call to ProgramExecutable::create. The call inturn calls the the base constructor (i.e. GlobalExecutable) which has the signature shown below:

GlobalExecutable(Structure* structure, VM& vm, const SourceCode& sourceCode, bool isInStrictContext, DerivedContextType derivedContextType, bool isInArrowFunctionContext, bool isInsideOrdinaryFunction, EvalContextType evalContextType, Intrinsic intrinsic)
        : Base(structure, vm, sourceCode, isInStrictContext, derivedContextType, isInArrowFunctionContext, isInsideOrdinaryFunction, evalContextType, intrinsic)
    {
    }

GlobalExecutable inturn calls its base constructor ScriptExecutable. The ScriptExecutable constructor performs two functions, it first initalises the ExecutableBase and initialise several other class members. ExecutableBase calls the JSCell constructor which effectively generates a JSCell for the ProgramExecutable.

The ExecutableBase and its derived classes (e.g. ProgramExecutable) is important to this discussion as it stores references to JIT code which gets executed at later stages.

Lets now return to Interpreter::executeProgram and continue the discussion on this function; once the ProgramExecutable object program has been initialised, the function performs a range of validation checks to evaluate whether the supplied script is a JSON script. Since test.js does not contain any JSON, these checks can be ignored for now and this has been truncated in the code snippet documented previously. The next interesting instruction that needs to be considered is ProgramExecutable::initializeGlobalProperties:

// Compile source to bytecode if necessary:
JSObject* error = program->initializeGlobalProperties(vm, globalObject, scope);

The function ProgramExecutable::initializeGlobalProperties uses the source object to generate an UnlinkedProgramCodeBlock:

UnlinkedProgramCodeBlock* unlinkedCodeBlock = vm.codeCache()->getUnlinkedProgramCodeBlock(vm, this, source(), strictMode, codeGenerationMode, error);

A CodeCache according to the developer comments in the source is a cache for top-level code such as

Posts on Zon8 Research

V8 Vulnerability PoCs

JavaScriptCore Internals Part III: The DFG (Data Flow Graph) JIT -- Graph Building

Introduction

Existing Work

Tiering Up

Graph Building

Bytecode Parsing

DFG IR

Graph Header

Block Head

Block Body

Nodes

Edges

Block Tail

Graph Footer

Branching Instructions

Function Inlining

Conclusion

Appendix

JavaScriptCore Internals Part IV: The DFG (Data Flow Graph) JIT -- Graph Optimisation

Introduction

Graph Optimisations

Live Catch Variable Preservation

CPS Rethreading

Unification

Prediction Injection

Static Execution Count Estimation

Backwards Propagation

Prediction Propagation

Fixup

Invalidation Point Injection

Type Check Hoisting

Strength Reduction

Control Flow Analysis

Constant Folding

CFG Simplification

Local Common Subexpression Elimination

Variable Arguments Forwarding

Tier Up Check Injection

Fast Store Barrier Insertion

Store Barrier Clustering

Cleanup

Dead Code Elimination

Phantom Insertion

Stack Layout

Virtual Register Allocation

Watchpoint Collection

Conclusion

Appendix

JavaScriptCore Internals Part V: The DFG (Data Flow Graph) JIT -- On Stack Replacement

Introduction

Graph Compilation

Code Generation

Slow Path Generation and OSR Linking

Code Linking

Tracing Execution

OSR Entry

OSR Exit

Jettison and Recompilation

Conclusion

Appendix

JavaScriptCore Internals Part II: The LLInt and Baseline JIT

Introduction

Existing Work

LLInt

Recap

Implementation

Offlineasm

Macros

Instructions

Operands

Registers

Labels

Conditional Statements

Const Expressions

Tracing Execution

Fast Path/Slow Path

Tiering Up

Baseline JIT