Make exception be ignored when trying to optimize.

src/runtime.cc

Index: src/runtime.cc
diff --git a/src/runtime.cc b/src/runtime.cc
index 48ff69f5d273071e0615743e2b2760f2abb71e70..c6df893d4701b61db0aa3923a853bb2f72289842 100644
--- a/src/runtime.cc
+++ b/src/runtime.cc
@@ -7000,7 +7000,7 @@ static MaybeObject* Runtime_LazyRecompile(Arguments args) {
     function->ReplaceCode(function->shared()->code());
     return function->code();
   }
-  if (CompileOptimized(function, AstNode::kNoNumber)) {
+  if (CompileOptimized(function, AstNode::kNoNumber, KEEP_EXCEPTION)) {
     return function->code();
   }
   if (FLAG_trace_opt) {
@@ -7169,7 +7169,8 @@ static MaybeObject* Runtime_CompileForOnStackReplacement(Arguments args) {
     // Try to compile the optimized code.  A true return value from
     // CompileOptimized means that compilation succeeded, not necessarily
     // that optimization succeeded.
-    if (CompileOptimized(function, ast_id) && function->IsOptimized()) {
+    if (CompileOptimized(function, ast_id, CLEAR_EXCEPTION) &&

[Lasse Reichstein, 2011/02/16 19:06:08]

The exception is thrown inside TryInline. Would it be reasonable to drop the
exception there instead, and just not inline that function call, instead of
failing to optimize the entire function?

[Kevin Millikin (Chromium), 2011/02/17 11:02:34]

That would be good to do, but it's blocked on a refactoring of the Hydrogren
graph construction that would allow us to do that.

+        function->IsOptimized()) {
       DeoptimizationInputData* data = DeoptimizationInputData::cast(
           function->code()->deoptimization_data());
       if (data->OsrPcOffset()->value() >= 0) {
@@ -7212,6 +7213,9 @@ static MaybeObject* Runtime_CompileForOnStackReplacement(Arguments args) {
     ASSERT(function->code()->kind() == Code::OPTIMIZED_FUNCTION);
     return Smi::FromInt(ast_id);
   } else {
+    if (function->IsMarkedForLazyRecompilation()) {
+      function->set_code(function->shared()->code());
+    }

[Lasse Reichstein, 2011/02/16 19:06:08]

I'm a little wary at this.
If I don't unmark the function again, it's attempted recompiled again and again
and again. Unmarking it again helps a little, but it is still attempted
recompiled a few times after a while.
That might be reasonable if the problem was, e.g., a stack overflow, or
something else that's potentially transient, but for a syntax error, it's
certain that it will happen again.

[Kevin Millikin (Chromium), 2011/02/17 11:02:34]

On the other hand, we don't really care about optimizing compilation time for
programs that have a long running loop in a function that calls a function with
a (compile-time) syntax error.

Isn't the most reasonable thing we could do is to catch those errors even
earlier, as if we didn't lazily compile those functions?

In any case, please don't call JSFunction::set_code directly here.  Call
JSFunction::ReplaceCode.

[Lasse Reichstein, 2011/02/17 11:44:59]

It *would* be better to catch those syntax errors earlier, and it might not be a
breaking change since both Webkit Nightlies and Firefox 4.0 betas are already
doing it.

With the current preparsing there are syntax errors that we cannot catch at
preparse-time (e.g., "continue x" where x isn't the label of a loop, because we
record neither labels nor loops during preparsing). We can't catch those until
the function is parsed properly the first time, and if it's lazy, that might be
when it's attempted inlined.

Another option is to make uncompiled functions not optimizable. Currently when
we check if we can optimize a function, if it's uncompiled we optimistically
assume that it is.

Changed to using ReplaceCode.

     return Smi::FromInt(-1);
   }
 }