I am trying to understand how functions — which could have dozens of parameters that could themselves be functions or complex objects (I’m thinking JavaScript) — get passed the arguments when compiled.
I have seen before simple examples like this in C, which shows:
foo(1, 2, 3);
getting compiled down to:
push $3
push $2
push $1
call _foo
That makes sense, but this is a simple case. I’m wondering for more complicated cases like in JavaScript where you might have:
foo(new Date, /asdf/i, { a: 1, b: 2 }, function(err){
})
Or more naturally, something like:
function a(a, b, c) {
c.a = 1
c.b = 2
var d = []
foo(a, b, c, function(err, value){
d.push(value)
})
return d
}
a(new Date, /asdf/i, {})
I’m basically wondering in this last case, if foo(a, b, c, ...) gets a new scope object created, with these variables named and assigned to the parent scopes values, sort of like this
var newScope = {
a: parentScope.a,
b: parentScope.b,
c: parentScope.c
}
Or does it just directly pass in the parent scope, as in
foo(parentScope.a, parentScope.b, parentScope.c)
In that way it wouldn’t have to construct all kinds of extra data.
Basically wondering generally how arguments literally get passed to the functions when compiled in JavaScript.
Creates the Activation object or the variable object: Activation object is a special object in JS which contain all the variables, function arguments and inner functions declarations information. As activation object is a special object it does not have the dunder proto property.
https://hackernoon.com/execution-context-in-javascript-319dd72e8e2c
4
You should keep three different kinds of things conceptually separate:
- How JavaScript is defined to work in the ECMA 262 standard
- How programming language functionality is commonly explained
- How a JavaScript implementation actually works
For example your stack operation example is a kind of white lie that is useful for explaining how things work, but not how a real-world implementation like V8 operates. Execution Contexts are part of the formal semantics of the ECMA 262 standard, but they might not actually be represented in an implementation – as long as the implementation works as if it implemented those semantics, everything is fine. ECMA 262 does not mention “activation objects” and only mentions the technical term “activation record” in a note.
This answer will only focus on the general concepts, not on the ECMA standard.
A variable is a name–value association, also called a binding. A scope or environment consists of bindings. So the scope is a bit like a JavaScript object, where each variable is a property of this scope object.
When a function is called, it receives values as parameters, not variables. This is why function arguments can be arbitrary expressions, for example like foo(x*2): that calls foo with the value of x*2. Therefore, a called function is not connected with the calling scope. It only gets some values, no bindings.
When a function is executed, it gets its own set of bindings with its local variables. This also includes any function parameters. If this helps, you can imagine the start of a function popping values of a call stack and placing the values into local variables:
a = pop
b = pop
c = pop
...
For compiled code (and V8 compiles the code) this actually happens to be for free. The variables are not actually stored in a JavaScript object, but in a flat piece of memory that is accessed like a C struct, sometimes called the activation record or stack frame. During compilation the compiler doesn’t know where in memory that record will be, but it knows the offset of each variable’s storage relative to the start of the record. Then at run time, the record will be placed on the call stack, a memory region laid aside for function parameters, return values, and these records. The relative position of each function argument is already known, so it doesn’t have to be moved. The typical layout of a call stack might be:
| ... | data of caller
+---------+
| result | space for return value
+---------+
| a | function arguments
| b |
| c |
+---------+
| return | call metadata such as return location
+---------+
| ... | space for activation record
Things are more difficult with nested functions. In a way, a function is just an ordinary object that can be passed around as a value. However, the code in a function can access variables in surrounding scopes. Example:
function outer() {
var x = 2;
takesCallback(function inner() {
x++;
});
return x;
}
Here, the inner() function accesses the outer scope’s x variable. We call such functions a closure.
In our “scopes are like JS objects” analogy, this would mean that our inner scope object has the outer scope object as prototype.
In the reality of call stacks, this causes a problem. Where bindings of an outer scope are captured by a closures, that part of the activation record might have to live longer than the stack frame. Then, a part of the activation record might be allocated outside of the stack (on the heap). This record will be garbage collected when no closures continue to reference these variables. The reference to the outer activation record is just a pointer that is passed as an implicit argument to the function. Since accesses to outer variables must go through a pointer, they are generally compiled differently to local variables.
| inner() function
v
+----------+----------+---------------+
| metadata | captures | compiled code |
+----------+----------+---------------+
|
v outer() activation record
+-------+
| x = 2 |
+-------+
There is a deep correspondence between closures and objects. When you call an object method, the object is passed as an implicit this parameter. Similarly, when you call a closure, the outer scope needs to be passed as an implicit parameter. A captured outer variable of a function is similar to a property of an object. But again: the scope is not actually implemented in terms of JavaScript objects.