Virtual Machine Optimisations

[jasonwilliams]

For all discussion relating to https://github.com/boa-dev/boa/projects/6

[jasonwilliams]

@HalidOdat why do we pushUndefined here?
https://github.com/boa-dev/boa/blob/master/boa/src/bytecompiler.rs#L871

[jasonwilliams]

function main() {
    const foo = 'foo';
    const bar = 'bar';
    return foo + bar;
}

main()

Generates the code block

----------------- name 'main' (length: 0) ------------------
    Location  Count   Opcode              Operands
    000000    0000    DefConst            0000: 'foo'
    000005    0001    PushLiteral         0
    000010    0002    InitLexical         0000: 'foo'
    000015    0003    DefConst            0001: 'bar'
    000020    0004    PushLiteral         1
    000025    0005    InitLexical         0001: 'bar'
    000030    0006    GetName             0000: 'foo'
    000035    0007    GetName             0001: 'bar'
    000040    0008    Add                 
    000041    0009    Return              
    000042    0010    PushUndefined       
    000043    0011    Return     

but the last 2 instructions feel redundant

[HalidOdat]

Yep. It's redundant, if the last statement is a return statement (it is dead code) otherwise it is needed.

To eliminate we can check if the last node is a return statement, if it is we don't add it.

[jasonwilliams]

I think each node is going to need its own compile_expr otherwise https://github.com/boa-dev/boa/blob/master/boa/src/bytecompiler.rs is going to get very big. Also should byteCompiler be in the vm folder?

[HalidOdat]

I think each node is going to need its own compile_expr otherwise master/boa/src/bytecompiler.rs is going to get very big.

I'm not sure if I want do that right now, it is a headache to do anything when the compilation code is separated in 20+ files. Right now the compiler and vm can change a lot, one we decide on a good foundation we can separate them.

Also should byteCompiler be in the vm folder?

I think we should keep compilation (the byte compiler) and runtime (the virtual machine) separate.

[Razican]

Dividing the byte compiler is being tracked in #1808, documenting it in #1608

[jasonwilliams]

Escape Analysis (compiler optimization)

Not something we need to focus on right now but putting here for future reference.
JS

function foo() {
    const a = 'hello';
    const b = 'world';
    return a + b
}

foo()

Instructions

------------------------------------- Call Frame -------------------------------------
Time         Opcode                   Operands                 Top Of Stack
9μs          DefConst                 0000: 'a'                <empty>
0μs          PushLiteral              0                        "hello"
3μs          InitLexical              0000: 'a'                <empty>
6μs          DefConst                 0001: 'b'                <empty>
1μs          PushLiteral              1                        "world"
5μs          InitLexical              0001: 'b'                <empty>
3μs          GetName                  0000: 'a'                "hello"
3μs          GetName                  0001: 'b'                "world"
5μs          Add                                               "helloworld"
2μs          Return                                            "helloworld"

a and b never leave foo, so it doesn't make sense to put them into the environment (this is expensive going back and forth to the heap). It would be useful to detect these variables as local and access them from the stack.
This will require some analysis to know which variables leave the function once its finished.

Then for a and b, instead of performing initLexical and GetName we would fetch them from the stack (or array for JSValues). In register machines this is a bit easier as you can just assign them to registers, we would need something similar here