The more we discuss this, the more I think this problem isn't solvable
without something radical that makes Javascript more C like. Which, I
think, is probably some of the reason for asm.js.
The problem: People want to create realtime games, VR, animations,
without stutter. You can get away with this by pre-allocating
everything into global (I do a lot of that and get solid, predictable
frame rates: www.klinksoftware.com/ws) GC engines just aren't the place
for that.
A real multi-part solution would be:
1. Introduce types. Make them pass by value, and "set by value". This
allows local variables to be on the stack, and allows for faster to
compilation steps as you don't have to run functions to analyze the types.
foo(x)
{
int y; // local, on stack
foo2(y); // the y inside of foo2 is a local in foo2, passed by value
globalY=y; // this is also copying the value, y is still local
y=0.0; // probably an error, should be forced to convert
y=Math.trunc(0.0); // not an error
return(y); // also a copying of the value
// y is popped from the stack
}
This isn't new, it's how C obviously does it.
2. Introduce a new mode that changes the behavior of new in scripts to
require a free, say "use free"; . Heaps are compacted (if required) on
new, so realtime can avoid that by pre-allocating.
{
let x=new myClass(y);
free(x);
}
This would probably require a separate heap, away from the GC heap.
I'm just thinking that anytime spent on a solution that tries to put
some kind of control over GC is destined to meet resistance because of
the variety of GC schemes and worse, never actually solve the problem,
just move it around.
Yes, this is something really radical that would be years in showing up
in any browser. I think for now I'll just have to stick to a lot of
pre-allocated globals.
[>] Brian
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
