Skip to content

V
V8
Switch branch/tag
  1. 07 Nov, 2013 1 commit
  3. 18 Apr, 2013 1 commit
  5. 18 Dec, 2012 1 commit
  7. 10 Dec, 2012 1 commit
  9. 05 Dec, 2012 1 commit
  11. 03 Dec, 2012 2 commits
  13. 30 Nov, 2012 2 commits
  15. 11 Jun, 2012 2 commits
  17. 16 Nov, 2011 1 commit
    • fschneider@chromium.org's avatar
      Fix lazy deoptimization at HInvokeFunction and enable target-recording call-function stub. · 84805694
      fschneider@chromium.org authored 
      Changes the way we do lazy deoptimization:

1. For side-effect instructions, we insert the lazy-deopt call at
the following LLazyBailout instruction.

     CALL
     GAP
     LAZY-BAILOUT ==> lazy-deopt-call

2. For other instructions (StackCheck) we insert it right after the
instruction since the deopt targets an earlier deoptimization environment.

   STACK-CHECK
   GAP ==> lazy-deopt-call

The pc of the lazy-deopt call that will be patched in is recorded in the
deoptimization input data. Each Lithium instruction can have 0..n safepoints.
All safepoints get the deoptimization index of the associated LAZY-BAILOUT
instruction. On lazy deoptimization we use the return-pc to find the safepoint.
The safepoint tells us the deoptimization index, which in turn finds us the
PC where to insert the lazy-deopt-call.

Additional changes:
 * RegExpLiteral marked it as having side-effects so that it 
   gets an explicitlazy-bailout instruction (instead of
   treating it specially like stack-checks)
 * Enable target recording CallFunctionStub to achieve
   more inlining on optimized code.

BUG=v8:1789
TEST=jslint and uglify run without crashing, mjsunit/compiler/regress-lazy-deopt.js
Review URL: http://codereview.chromium.org/8492004

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@10006 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      84805694
  19. 12 Sep, 2011 1 commit
  21. 18 Mar, 2011 3 commits
  23. 04 Feb, 2011 1 commit
  25. 03 Feb, 2011 1 commit
  27. 02 Feb, 2011 1 commit
    • kmillikin@chromium.org's avatar
      Partial fix for V8 issue 1079. · f1149734
      kmillikin@chromium.org authored 
      Record a safepoint with a deoptimization id for throw in optimized code.  We
don't seem to much care what the AST ID is because we will not be using it
for lazy deoptimization (throw doesn't return to the point of throw).  For
hygiene we use the actual ID of the throw expression.  Throw is no longer a
control-flow instruction, but it's followed by an unconditional abnormal
exit.  This is required to insert a simulate between the throw and the exit.

Make our optimized treatment of Function.prototype.apply act like a call and
have side effects.  This ensures that it will get a lazy deoptimization
environment.  Use that deoptimization ID in the safepoint for the call.

Deleting a property was also missing a deoptimization ID, though there was a
deoptimization environment assigned to the instruction.  Record the
environment and use the deoptimization ID at the safepoint.

Review URL: http://codereview.chromium.org/6250105

git-svn-id: http://v8.googlecode.com/svn/branches/bleeding_edge@6576 ce2b1a6d-e550-0410-aec6-3dcde31c8c00
      f1149734
  29. 26 Jan, 2011 1 commit
  31. 14 Jan, 2011 1 commit
  33. 12 Jan, 2011 1 commit
  35. 07 Dec, 2010 3 commits