417796 - Taking addresses of local variables in the interpreter can be costly

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect)

Description

[Igor Bukanov]

Currently the interpreter contains a code like:

    type local;
...
    byte_code_case_a
       some_api_call(..., &local);
    
...
    byte_code_case_b
       another_api_call(..., &local);
    

Since the compiler do not know that api calls do not store &local on a heap, it can not reuse the native stack cell that stores the local for other things. Potentially it may increase the stack size the compiler has to allocate for js_Interpreter stack and harm performance.

With a smart compiler this problem does not happen if one uses a structure like:

    byte_code_case_a {
       type local;

       some_api_call(..., &local);
    }
    
...
    byte_code_case_b {
       type local;

       another_api_call(..., &local);
    }

In this case the compiler is free to re-use the stack cell for local for other things. It would be interesting to see if the current compilers can take advantage of this.

Comment 1

[Jason Orendorff [:jorendorff]]

It's actually worse than that, right?  The variable cannot be stored in a register--not across function calls, anyway--so I imagine this would force a lot of reads and writes to the stack.

Comment 2

[Igor Bukanov]

(In reply to comment #1)
> It's actually worse than that, right?  The variable cannot be stored in a
> register--not across function calls, anyway--so I imagine this would force a
> lot of reads and writes to the stack.

I do not suggest to stop passing the addresses to function calls. In most cases this is hard to avoid. The idea is at least to allow for a compiler to use less native stack.

Comment 3

[Brendan Eich [:brendan]]

Jason: if you see out params that could be unoverloaded return values, please cite them in bug 408416. OBJ_LOOKUP_PROPERTY is an example, I suppose. This is not going to make a big difference on register-poor machines like x86-32, but it is worth optimizing in the context of bug 408416, I think.

/be

Comment 4

[Luke Wagner [:luke]]

jits make this level of optimization unnecessary.