It won't help anything. Imagine following example:
class Foo{
constructor() {
global.someArray.push(this)
}
}
function baz() {
temp foo = new Foo()
}
You still have to perform garbage collection to reach global.someArray. So
"stack allocation" that you have proposed won't help engine to optimize
anything except primitives.
And primitives can be optimised anyway by escape analysis without special
syntax.
On 23 Mar 2016 11:13 p.m., "Brian Barnes" <[email protected]> wrote:
> Another of my "throw ideas at the wall to deal with high performance code
> in a GC world.” Thanks for putting up with this!
>
> A new variable declaration keyword “temp” that declared variables that are:
>
> 1) Stack based
> 2) Locked to their declared type
>
> I know engines probably do some of this work already, or at least try to
> as a optimization.
>
> Usage would be:
>
> foo()
> {
> temp x=0;
> temp y=0.1;
> var z;
> …
> }
>
> z would be on the heap. X is an integer, on the stack, and y is a float,
> on the stack.
>
> Requirements:
>
> 1) temp variables would always have to be initially declared for typing
> (i.e., temp x=0;) It’s also possible you could instead do a pseudo forward
> thinking type system, temp x:int32;
> 2) changing the type results in an error
> 3) returning a temp results in an error
> 4) popped off the stack on the function epilogue
> 5) always has to be something that can be expressed as a primitive (i.e.,
> no strings or other objects, they are errors)
> 6) Would always be hoisted to help the engine
>
> An open question would be — what happens if they are passed into a further
> function? In my mind, from least to best:
>
> 1) error
> 2) they are passed as if constants, i.e.,
>
> foo()
> {
> temp x=0;
> x++;
> foo2(x); // would actually be as if the code was foo2(1);
> eventually would be making a new heap object (I assume)
> }
>
> 3) “temp” is carried through to the next function
>
> Pros: Keeps things out of GC
>
> Cons: Would probably be difficult to implement and if javascript got
> types, this could be done automatically if the type was something that
> could be stack based which would make this vestigial and ultimately useless
> code, something I wouldn’t want in an engine
>
> [>] Brian
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
