I've found a v8 issue report which is precisely about what you're asking.

Now, To summarize what is said in that issue report... v8 can store the variables that are local to a function on the stack or in a context object which lives on the heap. It will allocate local variables on the stack so long as the function does not contain any inner function that refers to them. It is an optimization. If any inner function refers to a local variable, this variable will be put in a context object (i.e. on the heap instead of on the stack). The case of eval is special: if it is called at all by an inner function, all local variables are put in the context object.

The reason for the context object is that in general you could return an inner function from the outer one and then the stack that existed while the outer function ran won't be available anymore. So anything the inner function accesses has to survive the outer function and live on the heap rather than on the stack.

The debugger cannot inspect those variables that are on the stack. Regarding the problem encountered in debugging, one Project Member says:

The only solution I could think of is that whenever devtools is on, we would deopt all code and recompile with forced context allocation. That would dramatically regress performance with devtools enabled though.

Here's an example of the if any inner function refers to the variable, put it in a context object. If you run this you'll be able to access x at the debugger statement even though x is only used in the foo function, which is never called!

function baz() {

  var x = x value;

  var z = z value;



  function foo () {

    console.log(x);

  }



  function bar() {

    debugger;

  };



  bar();

}

baz();