1. 07 Nov, 2016 1 commit
    • neis's avatar
      [modules] Maintain array of cells for imports and local exports. · 21463f73
      neis authored
      This makes use of the newly introduced cell indices to speed up variable
      accesses. Imports and local exports are now directly stored in (separate)
      arrays. In the future, we may merge the two arrays into a single one, or
      even into the module context.
      
      This CL also replaces the LoadImport and LoadExport runtime functions with
      a single LoadVariable taking a variable index as argument (rather than a
      name).
      
      BUG=v8:1569
      
      Review-Url: https://codereview.chromium.org/2465283004
      Cr-Commit-Position: refs/heads/master@{#40808}
      21463f73
  2. 28 Oct, 2016 1 commit
    • jgruber's avatar
      [debugger] Various break-related functionality in test wrapper · 83b560b0
      jgruber authored
      This CL adds simple implementation of break and stepping-related functionality
      as required by the debug-step.js test. This includes
      
      * stepOver, stepInto, stepOut
      * setBreakPoint
      * clearBreakPoint
      * evaluate
      
      Some of these, e.g. setBreakPoint are not fully implemented for all cases but
      only for the ones we need right now.
      
      One interesting result of this is that using the inspector protocol is roughly
      14x slower for debug-step.js (14s instead of 0.5s). One cause of this seems to
      be iteration over all object properties in toProtocolValue, which is used to
      serialize JS objects before being sent over the wire (e.g. FrameMirrors).  This
      is something that should be fixed at some point. In the meantime, the test now
      runs 100 instead of 1000 iterations.
      
      BUG=v8:5530
      
      Review-Url: https://codereview.chromium.org/2447073007
      Cr-Commit-Position: refs/heads/master@{#40636}
      83b560b0
  3. 27 Oct, 2016 3 commits
  4. 26 Oct, 2016 5 commits
    • bmeurer's avatar
      [compiler] Properly validate stable map assumption for globals. · 2bd7464e
      bmeurer authored
      For global object property cells, we did not check that the map on the
      previous object is still the same for which we actually optimized. So
      the optimized code was not in sync with the actual state of the property
      cell. When loading from such a global object property cell, Crankshaft
      optimizes away any map checks (based on the stable map assumption),
      leading to arbitrary memory access in the worst case.
      
      TurboFan has the same bug for stores, but is safe on loads because we
      do appropriate map checks there. However mixing TurboFan and Crankshaft
      still exposes the bug.
      
      R=yangguo@chromium.org
      BUG=chromium:659475
      
      Review-Url: https://codereview.chromium.org/2444233004
      Cr-Commit-Position: refs/heads/master@{#40592}
      2bd7464e
    • neis's avatar
      Don't wrap roots in Handle just to dereference immediately. · d5de8f0d
      neis authored
      R=adamk@chromium.org
      BUG=
      
      Review-Url: https://codereview.chromium.org/2452543003
      Cr-Commit-Position: refs/heads/master@{#40584}
      d5de8f0d
    • bmeurer's avatar
      Revert of [compiler] Properly validate stable map assumption for globals.... · d0a047d4
      bmeurer authored
      Revert of [compiler] Properly validate stable map assumption for globals. (patchset #3 id:40001 of https://codereview.chromium.org/2444233004/ )
      
      Reason for revert:
      Breaks tree: http://build.chromium.org/p/client.v8/builders/V8%20Linux64%20GC%20Stress%20-%20custom%20snapshot/builds/8789
      
      Original issue's description:
      > [compiler] Properly validate stable map assumption for globals.
      >
      > For global object property cells, we did not check that the map on the
      > previous object is still the same for which we actually optimized. So
      > the optimized code was not in sync with the actual state of the property
      > cell. When loading from such a global object property cell, Crankshaft
      > optimizes away any map checks (based on the stable map assumption),
      > leading to arbitrary memory access in the worst case.
      >
      > TurboFan has the same bug for stores, but is safe on loads because we
      > do appropriate map checks there. However mixing TurboFan and Crankshaft
      > still exposes the bug.
      >
      > R=yangguo@chromium.org
      > BUG=chromium:659475
      
      TBR=yangguo@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=chromium:659475
      
      Review-Url: https://codereview.chromium.org/2454513003
      Cr-Commit-Position: refs/heads/master@{#40582}
      d0a047d4
    • bmeurer's avatar
      [compiler] Properly validate stable map assumption for globals. · 3aa57eb9
      bmeurer authored
      For global object property cells, we did not check that the map on the
      previous object is still the same for which we actually optimized. So
      the optimized code was not in sync with the actual state of the property
      cell. When loading from such a global object property cell, Crankshaft
      optimizes away any map checks (based on the stable map assumption),
      leading to arbitrary memory access in the worst case.
      
      TurboFan has the same bug for stores, but is safe on loads because we
      do appropriate map checks there. However mixing TurboFan and Crankshaft
      still exposes the bug.
      
      R=yangguo@chromium.org
      BUG=chromium:659475
      
      Review-Url: https://codereview.chromium.org/2444233004
      Cr-Commit-Position: refs/heads/master@{#40578}
      3aa57eb9
    • cbruni's avatar
      [runtime] Fix Object.create(null) initialization order · f5d4f8f8
      cbruni authored
      A GC might cause the just created dictionary object to have an invalid backing
      store, which breaks heap verification.
      
      BUG=chromium:659088
      
      Review-Url: https://codereview.chromium.org/2452653002
      Cr-Commit-Position: refs/heads/master@{#40574}
      f5d4f8f8
  5. 25 Oct, 2016 5 commits
  6. 22 Oct, 2016 1 commit
  7. 21 Oct, 2016 4 commits
    • jgruber's avatar
      [regexp] Add fast-path for global, callable replace · a8e30c0e
      jgruber authored
      This adds a fast-path for calls to RegExp.prototype[@@replace] for cases in
      which the given regexp is unmodified and global, and the given replace argument
      is callable.
      
      The fast-path implementation itself is almost identical to the original JS
      implementation except that it currently does not reuse result_array.
      
      SunSpider/unpack-code relies heavily on this codepath.
      
      BUG=v8:5339
      
      Review-Url: https://chromiumcodereview.appspot.com/2433923003
      Cr-Commit-Position: refs/heads/master@{#40504}
      a8e30c0e
    • jgruber's avatar
      [regexp] Use consistent map checks for fast paths · eb10dc4c
      jgruber authored
      These map checks were implemented for TF code already. This CL makes
      sure that parts implemented in C++ follow the same logic, which is:
      
      An object is an unmodified regexp if:
      1) it's a receiver,
      2) its map is the initial regexp map,
      3) its prototype is a receiver,
      4) and its prototype's map is the initial prototype's initial map.
      
      We can now be smarter in @@replace and @@split since checking maps
      (unlike the previous check of RegExp.prototype.exec) is not observable,
      so we can perform fast-path checks at a time of our choosing.
      
      BUG=v8:5339,v8:5434,v8:5123
      
      Review-Url: https://chromiumcodereview.appspot.com/2434983002
      Cr-Commit-Position: refs/heads/master@{#40501}
      eb10dc4c
    • machenbach's avatar
      Revert of [regexp] Use consistent map checks for fast paths (patchset #7... · 0b7e35ff
      machenbach authored
      Revert of [regexp] Use consistent map checks for fast paths (patchset #7 id:120001 of https://chromiumcodereview.appspot.com/2434983002/ )
      
      Reason for revert:
      https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/10853
      
      Original issue's description:
      > [regexp] Use consistent map checks for fast paths
      >
      > These map checks were implemented for TF code already. This CL makes
      > sure that parts implemented in C++ follow the same logic, which is:
      >
      > An object is an unmodified regexp if:
      > 1) it's a receiver,
      > 2) its map is the initial regexp map,
      > 3) its prototype is a receiver,
      > 4) and its prototype's map is the initial prototype's initial map.
      >
      > We can now be smarter in @@replace and @@split since checking maps
      > (unlike the previous check of RegExp.prototype.exec) is not observable,
      > so we can perform fast-path checks at a time of our choosing.
      >
      > BUG=v8:5339,v8:5434,v8:5123
      
      TBR=yangguo@chromium.org,jgruber@chromium.org
      # Skipping CQ checks because original CL landed less than 1 days ago.
      NOPRESUBMIT=true
      NOTREECHECKS=true
      NOTRY=true
      BUG=v8:5339,v8:5434,v8:5123
      
      Review-Url: https://chromiumcodereview.appspot.com/2438283002
      Cr-Commit-Position: refs/heads/master@{#40499}
      0b7e35ff
    • jgruber's avatar
      [regexp] Use consistent map checks for fast paths · bac992a1
      jgruber authored
      These map checks were implemented for TF code already. This CL makes
      sure that parts implemented in C++ follow the same logic, which is:
      
      An object is an unmodified regexp if:
      1) it's a receiver,
      2) its map is the initial regexp map,
      3) its prototype is a receiver,
      4) and its prototype's map is the initial prototype's initial map.
      
      We can now be smarter in @@replace and @@split since checking maps
      (unlike the previous check of RegExp.prototype.exec) is not observable,
      so we can perform fast-path checks at a time of our choosing.
      
      BUG=v8:5339,v8:5434,v8:5123
      
      Review-Url: https://chromiumcodereview.appspot.com/2434983002
      Cr-Commit-Position: refs/heads/master@{#40495}
      bac992a1
  8. 19 Oct, 2016 5 commits
  9. 18 Oct, 2016 5 commits
  10. 17 Oct, 2016 5 commits
  11. 14 Oct, 2016 5 commits