1. 19 Dec, 2016 1 commit
  2. 16 Dec, 2016 1 commit
  3. 26 Oct, 2016 3 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
    • 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
  4. 08 Aug, 2016 1 commit
  5. 14 Jul, 2016 1 commit
  6. 13 Jul, 2016 1 commit
    • mstarzinger's avatar
      [runtime] Fully remove RUNTIME_ASSERT for good. · 04062e92
      mstarzinger authored
      This fully deprecates all uses of the RUNTIME_ASSERT macro and removes
      the macro and underlying logging function in question. All uses have
      been replaces with CHECK macros which crash safely even in production.
      
      It makes sure we discover abuse of runtime functions in the wild early
      and also abort the process safely. Breaking assumptions in any runtime
      function can no longer accidentally be caught by JavaScript.
      
      R=yangguo@chromium.org
      BUG=v8:5066
      
      Review-Url: https://codereview.chromium.org/2132493002
      Cr-Commit-Position: refs/heads/master@{#37704}
      04062e92
  7. 14 Jun, 2016 1 commit
  8. 13 Jun, 2016 2 commits
  9. 06 Jun, 2016 1 commit
  10. 01 Mar, 2016 1 commit
    • littledan's avatar
      Make RUNTIME_ASSERT have more useful output in debug mode · 78d84530
      littledan authored
      Runtime asserts are were previously a bit annoying to debug, due to
      the lack of a useful error message, even in debug mode. This patch
      prints out some more information in debug mode for runtime assert
      failures while preserving their exception-throwing semantics. While
      we're at it, it requires a semicolon after RUNTIME_ASSERT macro
      invocations.
      
      ```
      $ rlwrap out/Debug/d8 --allow-natives-syntax
      V8 version 5.1.0 (candidate)
      d8> %ArrayBufferNeuter(1)
      
      #
      # Runtime error in ../../src/runtime/runtime-typedarray.cc, line 52
      #
      # args[0]->IsJSArrayBuffer()
      
      ==== C stack trace ===============================
      
       1: 0xf70ab5
       2: 0xadeebf
       3: 0xadedd4
       4: 0x2ef17630693b
      (d8):1: illegal access
      %ArrayBufferNeuter(1)
      ^
      
      d8>
      ```
      
      Also give the other 'illegal access' case (a special SyntaxError type) a more
      descriptive error message for its sole usage.
      
      R=adamk
      
      Review URL: https://codereview.chromium.org/1748183002
      
      Cr-Commit-Position: refs/heads/master@{#34401}
      78d84530
  11. 15 Jan, 2016 1 commit
    • rmcilroy's avatar
      [Interpreter] Add ForInPrepare runtime function which returns a ObjectTriple. · 84f8a506
      rmcilroy authored
      Adds a ForInPrepare Runtime function which returns a triple of
      cache_type, cache_array and cache_length.
      
      This requires adding support to CEntryStub to call runtime functions
      which return a ObjectTriple - a struct containing three Object*
      pointers. Also did some cleanup of the x64 CEntryStub to avoid
      replicated code.
      
      Replaces the interpreter's use of the ad-hock InterpreterForInPrepare
      Runtime function with ForInPrepare in preparation for fixing deopt in
      BytecodeGraphBuilder for ForIn (which will be done in a followup CL).
      
      MIPS port contributed by Balazs Kilvady <balazs.kilvady@imgtec.com>.
      
      BUG=v8:4280
      LOG=N
      
      Review URL: https://codereview.chromium.org/1576093004
      
      Cr-Commit-Position: refs/heads/master@{#33334}
      84f8a506
  12. 30 Sep, 2015 1 commit
  13. 03 Jun, 2015 1 commit
  14. 01 Jun, 2015 1 commit
    • bmeurer's avatar
      [turbofan] First step towards sanitizing for-in and making it optimizable. · e2e47f30
      bmeurer authored
      In a nutshell: The FILTER_KEY builtin is gone, and was replaced by a
      simple runtime call to ForInFilter, which does everything and is even
      cheaper (because FILTER_KEY used to call into the runtime anyway).
      And ForInFilter returns either the name or undefined, which makes it
      possible to remove the control flow construction from the AstGraphBuilder,
      and thereby make both the initialization and the per-loop code of for-in
      optimizable later (in typed lowering).
      
      R=jarin@chromium.org
      
      Review URL: https://codereview.chromium.org/1160983004
      
      Cr-Commit-Position: refs/heads/master@{#28711}
      e2e47f30
  15. 04 Feb, 2015 2 commits
  16. 20 Oct, 2014 1 commit
  17. 30 Sep, 2014 1 commit
  18. 25 Sep, 2014 1 commit