Add support for lazy deoptimization from deferred stack checks

Add support for lazy deoptimization from deferred stack checks

The debugger can be entered from the deferred stack check in optimized code. This can cause both lazy deoptimization and debugger deoptimization (setting the first break point and inspecting the stack for optimized code respectively). This required deoptimization support from the deferred stack check.

The lazy deoptimiztion call is inserted when the deferred code is done including restoring the registers. The bailout to the full code is the begining of the loop body as that is where the stack check is sitting in the optimized code. The bailout is not to the stack check in the full code as that is sitting at the end of the loop.

R=kmillikin@chromium.org

BUG=none
TEST=none

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

[Kevin Millikin (Chromium), 2011-07-05 13:09:42]

LGTM.

[sra1, 2011-07-06 03:59:09]

http://codereview.chromium.org/7212025/diff/1/src/ia32/lithium-codegen-ia32.cc
File src/ia32/lithium-codegen-ia32.cc (right):

http://codereview.chromium.org/7212025/diff/1/src/ia32/lithium-codegen-ia32.c...
src/ia32/lithium-codegen-ia32.cc:273: // have room for lazy bailout.
I don't understand why the last piece of deferred code is special in the need
for some room for lazy bailout.  Is the last piece special?  If it is special,
this seems fragile.  Perhaps in the future the deferred code fragments get
sorted in some way, e.g. to optimize the number of exit jumps that can be in the
short form.  If the last piece of code is always a certain kind of deferred
code, the deferred code Generate method should allocate the nops.

Please take a look at http://codereview.chromium.org/7277081/.
This change invalidates your assumption that the deferred code ends in a jump to
the exit label.
You can still make the deferred stack check end with a jump but please don't
force that constraint on other deferred code fragments.  The constraint is
adding 2-3% extra code size.