JS vars on the stack?

[Kyle]

Does anybody know of documentation in which is described the way browsers
handle what would normally be called the stack in programming?

Taking,

function test(t1,t2)
{
...
};

How are the vars t1 and t2 managed?

Can they safely be used to store data?

As in,
function test(t1)
{t1='data';
};

I know its valid to do this, I've done it, but is it safe, and what is
the mechanics behind it?

Also, what's the difference between that function and this one, in terms
of var management?

function test(t1,t2)
{this.t1=t1;
this.t2=t2;
};

I read somewhere about the functions being kept as arrays under the memory
management in JS, but I'm not clear on the true details about this subject
matter, and just how local vars work in this scheme.

[Earl Brown]

I am certainly no expert on this - so this is all just theory.

I figure that all JS constructs are being stored in a single memory
mechanism. I don't know how they're defining visibility and such, but it
seems that I can easily create a variable in a function that is referenced
after the function has terminated.

And with the functions being able to be assigned as a variable (even reviewed,
I believe), it seems to me that the best way to do that would be to treat a
function as a variable. Then every reference to anything is done as an
internal "eval()"...and all of the eval()s just refer to this global object
store.

Like I said, it's just a theory. It works fairly well for me.

Earl

[Eric Lippert (MS Scripting Dev)]

This gets complicated.

First of all, a quick rundown of how the JScript memory manager works (if
you want to know how Netscapes memory manager works, read their source code
or something...). Jscript uses a mark-and-sweep garbage collector to
destroy unused data. Function call arguments, local variables and temporary
working space are handled by a custom stack implementation that works with
the garbage collector. (The internal structures used to handle function
calls are stored on the system stack, not the custom stack -- it is
therefore possible to blow the system stack with deeply recursive
functions.)

Now let's take a look at your examples, with a few minor modifications.

function test(t1){
t1='data';
}
x = 'blah';
test(x);

In this case, 'blah' is copied into x. Then a new stack slot for t1 is
created and the contents of x are copied onto the stack for the call to
test. In the function call 'data' is copied into t1, destroying the
existing 'blah'. Note that x remains unchanged -- a copy of x was passed
in, not a reference. Once the function returns, t1 is destroyed and 'data'
is freed, returning those bytes back to the operating system. Later, the
same thing will happen to x and its contents.

It gets more complicated. JScript supports function closures:

function testClosure(t1){
function foo(t2){ return t1 + t2; }
return foo;
}
x = 'zoo';
y = test(x); // y = function foo(t2){ return 'zoo' + t2; }
z = y('logy'); // z = 'zoology'

In this case, t1 is NOT destroyed. When the closure is passed out, t1's
contents must be maintained so that the inner function works. When y is
destroyed then the closure is destroyed, and then t1 can be reclaimed. The
garbage collector takes care of all this work for you.

Similarly in this case:

function myobj(qaz)
{
this.blah = qaz;
}
x = new myobj(123);

In this case, the new operator produces a new object which is initialized by
the myobj constructor. The properties of "this" are assigned. A copy of
the contents of qaz are made in this.blah and qaz is destroyed when the
function constructor passes out of scope.

Does that answer your questions? The net result is that everything should
just work the way you expect it to -- you should not have to worry about
reclaiming resources except in some very specific circumstances which I can
discuss in greater detail should you need that information.

Eric

Earl Brown wrote in message <3548A92E...@bigfoot.com>...

[Kyle]

That was very concise and clear. Thanx. Feel free to add to this anytime.
This subject matter is a must have for anyone coming to JS from C++ and
other strict (chipset based) types of languages.