1. 17 May, 2018 1 commit
  2. 16 May, 2018 1 commit
  3. 09 May, 2018 1 commit
  4. 08 May, 2018 1 commit
  5. 04 May, 2018 4 commits
  6. 03 May, 2018 1 commit
  7. 02 May, 2018 2 commits
  8. 01 May, 2018 1 commit
  9. 26 Apr, 2018 2 commits
  10. 25 Apr, 2018 2 commits
  11. 23 Apr, 2018 1 commit
  12. 20 Apr, 2018 1 commit
  13. 18 Apr, 2018 1 commit
    • Christian O. Andersson's avatar
      [ignition] Optimizing Smi only comparisons · 894b95fe
      Christian O. Andersson authored
      There are various situations where we explicitly compare a SMI against
      another SMI (e.g., BuildIndexedJump). This is also a common pattern for
      generated code (e.g., comparing a loop variable with an integer). Instead
      of using the generic equality/strict-equality stub for this, which is
      expensive, this CL offers a simple comparison stub, repurposing the
      TestEqualStrictNoFeedback bytecode to TestReferenceEqual
      
      Bug: v8:5310
      Change-Id: Ib2b47cd24d5386cf0d20d3bd794776dc6e3a02a5
      Reviewed-on: https://chromium-review.googlesource.com/1007542Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Christian O. Andersson <cricke@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52655}
      894b95fe
  14. 14 Apr, 2018 2 commits
    • Alexey Kozyatinskiy's avatar
      Reland "[inspector] added timeout argument for Runtime.evaluate" · edf15167
      Alexey Kozyatinskiy authored
      This is a reland of deb875f7
      
      Original change's description:
      > [inspector] added timeout argument for Runtime.evaluate
      > 
      > R=yangguo@chromium.org,dgozman@chromium.org
      > 
      > Bug: none
      > Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
      > Change-Id: I31667b3d5f39db9d899d58acd5205a9c34e570db
      > Reviewed-on: https://chromium-review.googlesource.com/1005985
      > Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#52594}
      
      Bug: none
      Change-Id: Ib8aff5d9f83e41fc6c2019712708fda074bd1ad9
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
      Reviewed-on: https://chromium-review.googlesource.com/1012724Reviewed-by: 's avatarAleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52603}
      edf15167
    • Jakob Kummerow's avatar
      [ubsan] Change Address typedef to uintptr_t · 2459046c
      Jakob Kummerow authored
      The "Address" type is V8's general-purpose type for manipulating memory
      addresses. Per the C++ spec, pointer arithmetic and pointer comparisons
      are undefined behavior except within the same array; since we generally
      don't operate within a C++ array, our general-purpose type shouldn't be
      a pointer type.
      
      Bug: v8:3770
      Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
      Change-Id: Ib96016c24a0f18bcdba916dabd83e3f24a1b5779
      Reviewed-on: https://chromium-review.googlesource.com/988657
      Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52601}
      2459046c
  15. 13 Apr, 2018 2 commits
  16. 12 Apr, 2018 1 commit
  17. 11 Apr, 2018 1 commit
  18. 10 Apr, 2018 2 commits
  19. 09 Apr, 2018 2 commits
  20. 06 Apr, 2018 6 commits
  21. 05 Apr, 2018 2 commits
  22. 04 Apr, 2018 3 commits
    • Aleksey Kozyatinskiy's avatar
      Revert "[debug] introduced runtime side effect check" · 539a2443
      Aleksey Kozyatinskiy authored
      This reverts commit 7a2c3713.
      
      Reason for revert: msan is broken
      
      Original change's description:
      > [debug] introduced runtime side effect check
      > 
      > This CL demonstrates minimum valuable addition to existing debug evaluate
      > without side effects mechanism.
      > With this CL user can evaluate expressions like:
      > [a,b] // create any kind of temporary array literals
      > [a,b].reduce((x,y) => x + y, 0); // use reduce method
      > [1,2,3].fill(2); // change temporary arrays
      > 
      > The core idea: any change of the object created during evaluation without
      > side effects is side effect free. As soon as we try to store this temporary
      > object to object existed before evaluation we will terminate execution.
      > 
      > Implementation:
      > - track all objects allocated during evaluation and mark them as temporary,
      > - patch all bytecodes which change objects.
      > 
      > A little more details (including performance analysis): [1].
      > 
      > [1] https://docs.google.com/document/d/10qqAtZADspPnpYa6SEdYRxrddfKIZJIzbLtGpsZQkRo/edit#
      > 
      > Bug: v8:7588
      > Change-Id: I69f7b96e1ebd7ad0022219e8213211c7be72a111
      > Reviewed-on: https://chromium-review.googlesource.com/972615
      > Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      > Reviewed-by: Yang Guo <yangguo@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#52370}
      
      TBR=ulan@chromium.org,rmcilroy@chromium.org,yangguo@chromium.org,kozyatinskiy@chromium.org,leszeks@chromium.org
      
      Change-Id: Ied1739c6308b13a4981189e0999f5912316cf456
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7588
      Reviewed-on: https://chromium-review.googlesource.com/996135Reviewed-by: 's avatarAleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52371}
      539a2443
    • Alexey Kozyatinskiy's avatar
      [debug] introduced runtime side effect check · 7a2c3713
      Alexey Kozyatinskiy authored
      This CL demonstrates minimum valuable addition to existing debug evaluate
      without side effects mechanism.
      With this CL user can evaluate expressions like:
      [a,b] // create any kind of temporary array literals
      [a,b].reduce((x,y) => x + y, 0); // use reduce method
      [1,2,3].fill(2); // change temporary arrays
      
      The core idea: any change of the object created during evaluation without
      side effects is side effect free. As soon as we try to store this temporary
      object to object existed before evaluation we will terminate execution.
      
      Implementation:
      - track all objects allocated during evaluation and mark them as temporary,
      - patch all bytecodes which change objects.
      
      A little more details (including performance analysis): [1].
      
      [1] https://docs.google.com/document/d/10qqAtZADspPnpYa6SEdYRxrddfKIZJIzbLtGpsZQkRo/edit#
      
      Bug: v8:7588
      Change-Id: I69f7b96e1ebd7ad0022219e8213211c7be72a111
      Reviewed-on: https://chromium-review.googlesource.com/972615
      Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52370}
      7a2c3713
    • jgruber's avatar
      [coverage] Fix invalid coverage block transformation · e42ce200
      jgruber authored
      Before reporting coverage data, we attempt to reduce clutter by
      merging nested and consecutive ranges. Nested ranges are merged, if
      the child range has the same execution count as the parent range.
      Sibling ranges are merged, if one sibling begins where the other ends
      and execution counts are identical.
      
      This allowed an invalid transformation in which a range with an
      execution count of 1 would be merged into the parent change, but the
      sibling range with identical start and end points and a count of 0
      would remain, effectively deleting the covered range.
      
      For example:
      
      {start: 0, end: 10, count: 1},
      {start: 5, end:  8, count: 1},  // It's invalid to remove this.
      {start: 5, end:  8, count: 0}
      
      The fix is to separate the parent and sibling merge passes, and
      removing duplicate ranges in-between.
      
      Bug: chromium:827530
      Change-Id: Ic35eae1d4a106746570ce9cb412ed6710ef6da53
      Reviewed-on: https://chromium-review.googlesource.com/992114Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#52352}
      e42ce200