From c444c3568e45c92b34d5948669c4e859612cdd74 Mon Sep 17 00:00:00 2001
From: Danny Yoo <dyoo@cs.wpi.edu>
Date: Sun, 17 Apr 2011 12:56:59 -0400
Subject: [PATCH] using more of the stack.  Also ensuring a termination
 condition for the recursion limit search.

---
 NOTES      | 33 +++++++++++++++++++++++++++++++--
 runtime.js | 20 ++++++++++++++------
 2 files changed, 45 insertions(+), 8 deletions(-)

diff --git a/NOTES b/NOTES
index 670fd11..9df306b 100644
--- a/NOTES
+++ b/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.
\ No newline at end of file
diff --git a/runtime.js b/runtime.js
index f031ca7..48f4715 100644
--- a/runtime.js
+++ b/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);