Account Options

  1. Sign in
The old Google Groups will be going away soon.
Switch to the new Google Groups.
Google Groups Home
« Groups Home
v8-dev
Home
+ new post
About this group
Join this group
Message from discussion Add support for lazy deoptimization from deferred stack checks (issue7212025)
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Søren Gjesse  
View profile  
 More options Jul 6 2011, 3:02 am
From: Søren Gjesse <sgje...@chromium.org>
Date: Wed, 6 Jul 2011 09:02:01 +0200
Local: Wed, Jul 6 2011 3:02 am
Subject: Re: Add support for lazy deoptimization from deferred stack checks (issue7212025)
Print | View thread | Show original | Report this message | Find messages by this author

I did notice http://codereview.chromium.org/7277081/ yesterday and noticed
that it might never reach the last jump. However the patching of the jump
back to inline code is only relevant if the deferred code have calls which
can lead to lazy deoptimization. And the deferred code for stack check is
exactly such a place as this might enter the debugger. The deferred code for
instance of is another such place I need to fix, as it might call into the
builtins JavaScript potentially leading to lazy deoptimization.

Lazy deoptimization is what happens when all code in a context is forced to
be deoptimized either due to starting debugging or due to a global
assumption on the optimized code that no longer holds. The reason for the
term "lazy" is that actual deoptimization will not happen until control
returns to the optimized function. The way we do this lazy deoptimization is
somewhat fragile and we have had quite a few bugs in that code. It is based
on destructively patching the optimized code placing a call just after each
call forcing deoptimization. And actually the patching is not right after
the return point but after the gap code inserted at the return point. For
the deferred stack check the code up to restoring the registers (popad in
IA-32) is considered the gap code.

Bottom line: The change to DeferredTaggedToI is not affected by this as it
has no lazy deoptimization points, and I will rename the label used for the
assertion and add a comment.

Regards,
Søren

On Wed, Jul 6, 2011 at 06:45, Kevin Millikin <kmilli...@chromium.org> wrote:
> Hi Stephen,

> The last piece of deferred code is different because it's last---there's no
> code after it so it has to make its own space for patching and not rely on
> stomping the code after it.

> Søren's change doesn't assume the jump (well, it does assume it because the
> identifier name "last_jump" used in the debug assertion is a bad name if
> there's not jump, but identifier's can be renamed---Søren, how about
> "deferred_end" or some such?).

> ;; Kevin

> On Wed, Jul 6, 2011 at 5:59 AM, <s...@google.com> wrote:

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

>> http://codereview.chromium.**org/7212025/diff/1/src/ia32/**
>> lithium-codegen-ia32.cc#**newcode273<http://codereview.chromium.org/7212025/diff/1/src/ia32/lithium-codege...>
>> 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/<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.

>> http://codereview.chromium.**org/7212025/<http://codereview.chromium.org/7212025/>


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2012 Google