using more of the stack. Also ensuring a termination condition for the recursion limit search.
This commit is contained in:
parent
33a0c3ebe0
commit
c444c3568e
33
NOTES
33
NOTES
|
@ -2,7 +2,9 @@ Some possible optimizations with application:
|
|||
|
||||
If any of the operands are constant (either by being variable
|
||||
lookups or literal constants), and if all of them are side-effect
|
||||
free, then juggle-operands might not be necessary.
|
||||
free, then juggle-operands might not be necessary. I think this
|
||||
is similar to the "reorder" optimization described in casey's
|
||||
paper.
|
||||
|
||||
In a self-application, it's not necessary to compute the operator,
|
||||
since the value is in the top control frame. A parameterization
|
||||
|
@ -329,5 +331,32 @@ setting ControlLabel to 'val).
|
|||
|
||||
|
||||
|
||||
flush-output must set callsBeforeTrampoline to 0, just because
|
||||
flush-output must immediately yield control to the browser, because
|
||||
the browser needs control back to display changes to the dom.
|
||||
Basically, we're simulating an IO interrupt here...
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
April 17, 2011
|
||||
|
||||
The dynamic recomputation for gas is only controlling one parameter:
|
||||
how many times to run the trampoline before bouncing off to the
|
||||
browser. But we really have two parameters that need dynamic
|
||||
computation
|
||||
|
||||
* FN: the number of function calls before invoking the trampoline.
|
||||
|
||||
FN is necessarily bounded above by the browser. The larger it
|
||||
is, the more efficient the trampoline can be.
|
||||
|
||||
* TI: the number of trampoline invokations before yielding to the browser
|
||||
|
||||
Both of these should be under some dynamic controller. We want to
|
||||
optimize the efficiency of the runtime. I don't know what the
|
||||
function is, but we want to optimize the parameters FN and TI such
|
||||
that it maximizes FN and minimizes TI, and yet gives us the browser
|
||||
reactivity we want.
|
20
runtime.js
20
runtime.js
|
@ -1070,7 +1070,9 @@
|
|||
// Approximately find the stack limit.
|
||||
// This function assumes, on average, five variables or
|
||||
// temporaries per stack frame.
|
||||
// This will never report a number greater than MAXIMUM_CAP.
|
||||
var findStackLimit = function(after) {
|
||||
var MAXIMUM_CAP = 100000;
|
||||
var n = 1;
|
||||
var limitDiscovered = false;
|
||||
setTimeout(
|
||||
|
@ -1081,17 +1083,23 @@
|
|||
}
|
||||
},
|
||||
0);
|
||||
var infiniteLoop1 = function(x, y, z, w, k) {
|
||||
var loop1 = function(x, y, z, w, k) {
|
||||
// Ensure termination, just in case JavaScript ever
|
||||
// does eliminate stack limits.
|
||||
if (n >= MAXIMUM_CAP) { return; }
|
||||
n++;
|
||||
return 1 + infiniteLoop2(y, z, w, k, x);
|
||||
return 1 + loop2(y, z, w, k, x);
|
||||
};
|
||||
var infiniteLoop2 = function(x, y, z, w, k) {
|
||||
var loop2 = function(x, y, z, w, k) {
|
||||
n++;
|
||||
return 1 + infiniteLoop1(y, z, w, k, x);
|
||||
return 1 + loop1(y, z, w, k, x);
|
||||
};
|
||||
try {
|
||||
return 1 + infiniteLoop1(2, "seven", [1], {number: 8}, 2);
|
||||
var dontCare = 1 + loop1(2, "seven", [1], {number: 8}, 2);
|
||||
} catch (e) {
|
||||
// ignore exceptions.
|
||||
}
|
||||
if (! limitDiscovered) {
|
||||
limitDiscovered = true;
|
||||
after(n);
|
||||
}
|
||||
|
@ -1103,7 +1111,7 @@
|
|||
setTimeout(function() {
|
||||
findStackLimit(function(v) {
|
||||
// Trying to be a little conservative.
|
||||
STACK_LIMIT_ESTIMATE = Math.floor(v / 10);
|
||||
STACK_LIMIT_ESTIMATE = Math.floor(v / 2);
|
||||
});
|
||||
},
|
||||
0);
|
||||
|
|
Loading…
Reference in New Issue
Block a user