"Temp" as a var type
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.
Sure, as I said, all this would only be good for is primitives. I never expected objects.
But the problem is primitives aren’t be optimized away, as far as I can tell, in any engine. For instance, my game engine (which uses classes) pre-allocates every object in the class constructor and the only variables created anywhere else are temporary and local to a function, and more importantly, primitives (There might be a string here and there, and I expect that to be garbage collected, and I might eventually deal with those in a different way, it depends on how engine treat strings as mutable/immutable things which I don’t know and need to look up.)
Even if dynamic analysis or a running function tells the engine it’s a primitive, I’m guessing it would just mean it’s marked immediately without having the reference count (which isn’t all that much more complex); and that’s still a GC. I don’t have knowledge of inner workings on the engine, but I’m attempting to starve the GC of objects, basically.
BTW, I know this is a wild thing that has little probably of going anywhere, but I post these to point out the problems myself and a lot of people have as they try to push javascript to do things that in a high performance, time sensitive way.
[>] Brian
This problem should already be solved quite well if the function is compiled with escape analysis.
I fail to see how temp is bringing anything useful to ECMAScript that can't already be achieved using let and const declarations. Recall both are block-scoped, which means they should logically be freed from memory after executing exits their scope (assuming there're no lingering pointers). Furthermore, having two keywords that're abbreviations of "temporary" and "variable" would undoubtedly invoke confusion among users.
Finally, the most practical reason to disallow a reserved identifier is the notion of breaking existing code. How many scripts do you envision have used the name temp as an identifier?
That's a good point, "temp" would be a bad keyword.
Again, just throwing some things out there to see what kind of discussion comes about. My goal is to find a way that hand-crafted javascript (i.e., not cross-compiled asm.js) could potentially avoid GC and can be compiled without needing to be dynamically analyzed.
My needs are very specific, but certainly something that a lot of people are looking for.
And, more and more, everything eventually comes back to the need for types. So much can be done automatically once a variable can be determined statically to be a primitive type.
[>] Brian
On 24 March 2016 at 14:40, Brian Barnes <ggadwa at charter.net> wrote:
That's a good point, "temp" would be a bad keyword.
Actually I think "temp" could be used with very little in the code break way. Why? Because it wouldn't be a single keyword construct. There are only a very few cases that are legal in code today where the token "temp" followed by an identifier token could appear, and those cases are mostly ASI related and would result in a nop. Since |"temp" ident| will in the vast majority of cases be a syntax error, the one in question would be |"temp" destructassign|. It does not necessarily clash with identifiers that spell out "temp". I think the actual clash that you would find there is when you try to use destructuring assignment of the array type. Possibly some with the object form and block statements, though I believe the only case where the "temp" reference is not a nop if written today is the array destructuring form.
Not that this would make it a a good idea, just that this particular argument isn't as strong as you'd maybe think.
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:
I know engines probably do some of this work already, or at least try to as a optimization.
Usage would be:
zwould be on the heap.Xis an integer, on the stack, andyis a float, on the stack.Requirements:
An open question would be — what happens if they are passed into a further function? In my mind, from least to best:
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
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