Javascript - 上下文执行阶段

Question

I know that the "execution" in JavaScript happens in 2 phases:

1) The Creation phase when the functions and variables are added in the memory, hoisting,the this is create and outer environment

2) The second phases when the code is executed.

The question: The variables and functions insides a parent function are added in the memory when the script start or only when the parent function is invoked ?

There is any difference between behavior of parameters of a function and variables declared inside function, regarding this aspect ? (I ask this because in other languages they behave different - the parameters are in memory before function executes, but in the scope of function)

Answer 1

If the variables and functions inside all functions were been put into the memory when the script starts, you memory may be full at start. When a function executes, at that time the variables and inside functions are added into the memory. When the function ends its execution, the related variables are removed from the memory, if they are not used in closure .

There is any difference between behavior of parameters of a function and variables declared inside function

There is no obvious deference in the behavior, the parameters are also variables which are declared in the scope of the function, only they can have their values from the outer.

One difference can be when you passed a reference type to the function and change its property in the functions. So it will be changed outside the function itself. This means that parameters can be bounded to the outer world in some manners. But I think this is not related to the behavior of parameters and scoped variables. They both are scoped into the function.

the parameters are in memory before function executes, but in the scope of function

Javascript functions can take varied number of parameters. So it can't add the parameters to the memory. You can have a function with no parameters, but call it and pass 10 parameters to it.

Answer 2

You are essentially asking things that are dependent on the inner workings of the JS engine. A JavaScript program can go through many phases, including a "parsing" phase, but in practice there are different kinds of parsing occurring in multiple phases, at different levels, for different purposes. (I would not call this the "Creation" phase; that term is non-standard and confusing.) The result of various parsing stages can be an internal syntax tree, or an intermediate byte-code representation, or even machine code ready to be executed. The same code might be parsed in different ways at different points in time, or in some cases parsed and then the result thrown away and reparsed again later, etc.

The whole point is that, unless you are learning compiler theory, it doesn't matter. Yes, parsing can be considered to be where "hoisting" occurs. However, I would urge you to not spend too much time worrying about hoisting, unless you plan to enter some kind of JS trivia contest. Just declare all your variables (including variables to which you assign functions) at the top of each function, as you should have been doing all along, then stop worrying about it. While the other guys are patting themselves on the back for knowing whether or not ES6 class es are hoisted, you can be actually writing useful code.

The question of when and how and where memory is allocated is also an internal engine detail. Some items might be allocated on the "heap" (of which there might be more than one), and then garbage-collected later. Such allocation would almost always happen at run-time, but this is also not a hard-and-fast rule; for example, a regexp encountered identified during parsing might be cached in compiled form on the heap. Other variables, such as primitives, are likely to be allocated on the "stack", and de-allocated semi-automatically when the stack frame is released when returning from a function. Variables which need to be maintained for use in embedded functions ("closures") are allocated and stored in a particular way.

I doubt if knowing any of this is going to make you a better JavaScript programmer in any meaningful way. Learning how one engine does it is not going to necessarily help you understand how another engine does it, or even how that same engine is going to do it in the next version.

Do you have a specific reason for wanting to know this, other than curiosity, or a specific case where you think it would make a difference?