Make exception be ignored when trying to optimize.

Handle exceptions thrown while parsing lazy functions for inlining.
We currently leave the exception as pending without returning a Failure::Exception() value. This is either caught immediately if running with --debug-code, or caught later by an assert in debug mode.

This change makes the pending exception be cleared before returning from the failed optimization attempt.


BUG=v8::1145
TEST=test/mjsunit/regress/regress-1145.js

Committed: http://code.google.com/p/v8/source/detail?r=6832

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

http://codereview.chromium.org/6524039/diff/2001/src/runtime.cc
File src/runtime.cc (right):

http://codereview.chromium.org/6524039/diff/2001/src/runtime.cc#newcode7172
src/runtime.cc:7172: if (CompileOptimized(function, ast_id, CLEAR_EXCEPTION) &&
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?

http://codereview.chromium.org/6524039/diff/2001/src/runtime.cc#newcode7218
src/runtime.cc:7218: }
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]

LGTM, except please call JSFunction::ReplaceCode to replace the code.

http://codereview.chromium.org/6524039/diff/2001/src/runtime.cc
File src/runtime.cc (right):

http://codereview.chromium.org/6524039/diff/2001/src/runtime.cc#newcode7172
src/runtime.cc:7172: if (CompileOptimized(function, ast_id, CLEAR_EXCEPTION) &&
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.

http://codereview.chromium.org/6524039/diff/2001/src/runtime.cc#newcode7218
src/runtime.cc:7218: }
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]

http://codereview.chromium.org/6524039/diff/2001/src/runtime.cc
File src/runtime.cc (right):

http://codereview.chromium.org/6524039/diff/2001/src/runtime.cc#newcode7218
src/runtime.cc:7218: }
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.