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 > On Mar 24, 2016, at 5:03 AM, Michał Wadas <[email protected]> wrote: > > 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] > <mailto:[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] <mailto:[email protected]> > https://mail.mozilla.org/listinfo/es-discuss > <https://mail.mozilla.org/listinfo/es-discuss>
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
