Skip to content

V
V8
Switch branch/tag
  1. 20 Apr, 2015 1 commit
  3. 17 Apr, 2015 1 commit
  5. 15 Apr, 2015 3 commits
  7. 14 Apr, 2015 2 commits
  9. 13 Apr, 2015 2 commits
  11. 09 Apr, 2015 1 commit
  13. 08 Apr, 2015 1 commit
  15. 07 Apr, 2015 3 commits
  17. 01 Apr, 2015 3 commits
  19. 30 Mar, 2015 4 commits
  21. 26 Mar, 2015 2 commits
  23. 25 Mar, 2015 3 commits
  25. 24 Mar, 2015 3 commits
    • titzer's avatar
      Set test expectations prior to enabling --turbo-osr. · 006ae96d
      titzer authored 
      R=mstarzinger@chromium.org
BUG=

Review URL: https://codereview.chromium.org/1018513003

Cr-Commit-Position: refs/heads/master@{#27425}
      006ae96d
    • erikcorry's avatar
      Fix OOM bug 3976. · 4c806802
      erikcorry authored 
      Also introduce --trace-fragmentation-verbose, and fix --always-compact.

R=ulan@chromium.org
BUG=v8:3976
LOG=y

Review URL: https://codereview.chromium.org/1024823002

Cr-Commit-Position: refs/heads/master@{#27414}
      4c806802
    • jarin's avatar
      Test for wrong arguments object materialization. · 0f94c96c
      jarin authored 
      The test demonstrates a bad interaction between arguments object
materialization, escape analysis and exception handling.

We can return a wrong arguments object if we materialize arguments
object (using f.arguments) and then throw around f's frame so that f
does not clean up the materialized frame information (see the
MaterializedObjectStore in deoptimizer.h/.cc). If we enter another
function that has the same frame pointer and request an arguments object
of (or lazily deoptimize) that function, we can get the materialized
object of the original function.

We should clean up the materialized object store when we unwind the
stack.

BUG=v8:3985
LOG=n

Review URL: https://codereview.chromium.org/1032623003

Cr-Commit-Position: refs/heads/master@{#27406}
      0f94c96c
  27. 23 Mar, 2015 2 commits
  29. 20 Mar, 2015 3 commits
    • Toon Verwaest's avatar
      Ensure we don't overflow in BCE · 0f573464
      Toon Verwaest authored 
      BUG=chromium:469148
LOG=y
R=dcarney@chromium.org

Review URL: https://codereview.chromium.org/1023123003

Cr-Commit-Position: refs/heads/master@{#27346}
      0f573464
    • rossberg's avatar
      [harmony] Move some regression tests to the right place · d0e20d82
      rossberg authored 
      TBR=dslomov@chromium.org
BUG=

Review URL: https://codereview.chromium.org/1027693003

Cr-Commit-Position: refs/heads/master@{#27339}
      d0e20d82
    • aperez's avatar
      Parser: Fix crash on stack overflow when lazy-parsing arrow functions · 3c3ce1bc
      aperez authored 
      The problem manifests itself when parsing manages to return something
meaningful in the presence of a stack overflow. This happens because
calling ParserBase::Next() will still return one valid token on stack
overflow, before starting to return invalid tokens.

Take the following input as example:

        a.map(v => v + 1);
              | |
       already   next token
        parsed   (which will be an invalid token
  (identifier)   because of a stack overflow)

The "v" may have been already parsed into a VariableProxy, then if a
stack overflow occurs, next token will be an invalid token (instead
of Token::ARROW), but the parser will return the VariableProxy.

This always happens when lazy-parsing arrow functions, so the position
in the input stream where the the arrow function code ends is known.
This fix adds a check that ensures that parsing ended at the end
position of the arrow function.

BUG=465671
LOG=N

Review URL: https://codereview.chromium.org/1023483003

Cr-Commit-Position: refs/heads/master@{#27325}
      3c3ce1bc
  31. 19 Mar, 2015 1 commit
  33. 17 Mar, 2015 2 commits
  35. 16 Mar, 2015 1 commit
  37. 13 Mar, 2015 2 commits