Skip to content

V
V8
Switch branch/tag
  1. 18 Jul, 2019 1 commit
  3. 04 Jul, 2019 1 commit
    • Simon Zünd's avatar
      [stack-trace] Separate stack-trace symbolization and serialization · db24e200
      Simon Zünd authored 
      This CL moves the code responsible for serializing a stack trace frame into
a string, out of messages.cc and into stack-frame-info.cc. Instead of
symbolizing the stack trace frame while serializing, the code is changed to
work on top of StackTraceFrame and StackFrameInfo objects.

The result is that the serialization code no longer cares when a stack trace
frame is symbolized. Symbolization could happen eagerly during capturing, or
lazily the first time any of StackFrameInfo fields are accessed.

Drive-by: Existing users of StackFrameBase::ToString are adapted to the
new SerializeStackTraceFrame API. This includes Isolate::PrintCurrentStackTrace,
which is changed to re-use the existing capturing and serializing mechanism.

Bug: v8:8742
Change-Id: Ic7fd80668c9d993e99d586ef7fe022850104c34f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631414
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62522}
      db24e200
  5. 01 Jul, 2019 1 commit
  7. 19 Jun, 2019 1 commit
    • Ben Smith's avatar
      [wasm] Call OnAfterCompile when cloning Module · b7a7e2fb
      Ben Smith authored 
      The debugger should be notified whenever a new Module is created so it
displayed properly. Without this change, the Module is only displayed once,
regardless of the number of times it is referenced (by other Workers, say).
That is potentially reasonable behavior, but it doesn't match the way
JavaScript does it.

With this change, the debugger will display the sources like this:

```
▼ top
  :arrow_forward: localhost
  ▼ wasm
    ▼ wasm-82570336
        wasm-82570336-0

▼ worker.js
  :arrow_forward: localhost
  ▼ wasm
    :arrow_forward: wasm-82570336
```

Change-Id: I61177e8a07e36ea8e2234aa25e75b1489c9da95f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1666616Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Ben Smith <binji@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62297}
      b7a7e2fb
  9. 11 Jun, 2019 2 commits
  11. 21 May, 2019 1 commit
  13. 10 May, 2019 1 commit
  15. 08 May, 2019 1 commit
  17. 02 May, 2019 1 commit
  19. 29 Apr, 2019 1 commit
  21. 16 Mar, 2019 1 commit
  23. 15 Mar, 2019 2 commits
  25. 14 Mar, 2019 2 commits
  27. 04 Mar, 2019 1 commit
  29. 01 Mar, 2019 1 commit
  31. 27 Feb, 2019 1 commit
  33. 20 Feb, 2019 1 commit
  35. 03 Feb, 2019 1 commit
  37. 30 Jan, 2019 1 commit
  39. 25 Jan, 2019 1 commit
  41. 23 Jan, 2019 1 commit
  43. 14 Jan, 2019 1 commit
  45. 11 Jan, 2019 2 commits
  47. 09 Jan, 2019 1 commit
    • Leszek Swirski's avatar
      [parser] Don't desugar destructuring declarations. · 5e725a2b
      Leszek Swirski authored 
      Emit a single destructuring assignment for destructuring declarations,
which can be desugared by the bytecode generator. This allows us to
remove destructuring desugaring from the parser (specifically, the
pattern rewriter) entirely.

The pattern "rewriter" is now only responsible for walking the
destructuring pattern to declare variables, mark them assigned, and
potentially rewrite scopes for the edge case of parameters with a sloppy
eval.

Note that since the rewriter is no longer rewriting, we have to flip the
VariableProxy copying logic for var re-lookup, so that we now pass the
new VariableProxy to the variable declaration and leave the original
unresolved (rather than passing the original through and rewriting to a
new unresolved VariableProxy).

This change does have some effect on breakpoint locations, due to some
of the available information changing between the parser and bytecode
generator, however the new locations appear to be more consistent
between assignments and declarations.

Change-Id: I3a58dd0a387d2bfb8e5e9e22dde0acc5f440cb82
Reviewed-on: https://chromium-review.googlesource.com/c/1382462
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58670}
      5e725a2b
  49. 08 Jan, 2019 1 commit
  51. 24 Dec, 2018 1 commit
  53. 21 Dec, 2018 1 commit
  55. 20 Dec, 2018 1 commit
  57. 13 Dec, 2018 1 commit
    • Sigurd Schneider's avatar
      Reland "Reland "Reland "[code-comments] Put code comments into the code object""" · b55dd17f
      Sigurd Schneider authored 
      This is a reland of 9c0a4858

Original change's description:
> Reland "Reland "[code-comments] Put code comments into the code object""
>
> This is a reland of ed3d6472
>
> This reland fixes that padding at the end of Wasm instruction streams
> triggered asserts in the code printer.
>
> Original change's description:
> > Reland "[code-comments] Put code comments into the code object"
> >
> > This is a reland of e774cffe
> >
> > This reland disables a test as v8:8548 is blocking it, which was
> > broken by a recent CL. CQ did not catch this because the merge-base
> > CQ used did not yet contain the CL that caused v8:8548.
> >
> > Original change's description:
> > > [code-comments] Put code comments into the code object
> > >
> > > Code comments in the snapshot can now be enabled with gn
> > > arg 'v8_enable_snapshot_code_comments'
> > >
> > > Bug: v8:7989
> > > Change-Id: I8bd00cafa63132d00d849394c311ba15e6b6daf3
> > > Reviewed-on: https://chromium-review.googlesource.com/c/1329173
> > > Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
> > > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> > > Reviewed-by: Michael Stanton <mvstanton@chromium.org>
> > > Cr-Commit-Position: refs/heads/master@{#58020}
> >
> > TBR=mvstanton@chromium.org,mstarzinger@chromium.org,jgruber@chromium.org,tebbi@chromium.org
> >
> > Bug: v8:7989, v8:8548
> > Change-Id: I464fc897205fefdf2dfc2eadc54d699c4e08a0e9
> > Reviewed-on: https://chromium-review.googlesource.com/c/1361166
> > Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
> > Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#58028}
>
> Bug: v8:7989, v8:8548
> Change-Id: I254f55ff687ad049f8d92b09331ed26a2bd05d7d
> Reviewed-on: https://chromium-review.googlesource.com/c/1371784
> Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#58221}

TBR=jgruber@chromium.org,mstarzinger@chromium.org

Bug: v8:7989, v8:8548, v8:8593
Change-Id: I4f7ffc98e0281c7b744eb4a04ba0763896c7b59b
Reviewed-on: https://chromium-review.googlesource.com/c/1375919Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58232}
      b55dd17f
  59. 06 Dec, 2018 1 commit
    • Dmitry Gozman's avatar
      Revert "inspector: return [[StableObjectId]] as internal property" · 4401ac44
      Dmitry Gozman authored 
      This reverts commit d9fbfeb8.

Reason for revert: see bug.
Bug: 906847

Original change's description:
> inspector: return [[StableObjectId]] as internal property
> 
> This property might be useful for fast '===' check.
> 
> R=​dgozman@chromium.org,yangguo@chromium.org
> 
> Bug: none
> Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
> Change-Id: Iabc3555ce1ec2c14cf0ccd40b7d964ae144e7352
> Reviewed-on: https://chromium-review.googlesource.com/1226411
> Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56095}

TBR=dgozman@chromium.org,yangguo@chromium.org,kozyatinskiy@chromium.org,jgruber@chromium.org

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug: none
Change-Id: I68c700b7b8fd0a015f099460c15665d74e4da183
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Reviewed-on: https://chromium-review.googlesource.com/c/1363558Reviewed-by: 's avatarDmitry Gozman <dgozman@chromium.org>
Reviewed-by: 's avatarAlexei Filippov <alph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#58077}
      4401ac44
  61. 30 Nov, 2018 1 commit
    • Yang Guo's avatar
      Make termination exception more consistent. · 7e5cac2c
      Yang Guo authored 
      Termination exceptions tear down V8 to the bottom-most V8 call. If there is a
v8::TryCatch scope around that call, it returns true for HasTerminated() and
HasCaught(). However, Isolate::IsExecutionTerminating() returns false and we
can call into V8 from still inside the v8::TryCatch scope.

Changes that this patch introduces:
 - You need to leave the v8::TryCatch scope around the bottom-most call to
   reset the termination state, in order to resume.
 - Explicitly check for termination exception and reporting it through the
   DevTools protocol after Runtime.evaluate and Debugger.evaluateOnCallFrame.

Bug: v8:8455
Change-Id: I1f36f7a365985469813c2619bf16f18ee69aa4b8
Reviewed-on: https://chromium-review.googlesource.com/c/1337582Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarDmitry Gozman <dgozman@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57963}
      7e5cac2c
  63. 29 Nov, 2018 1 commit
  65. 06 Nov, 2018 2 commits
  67. 02 Nov, 2018 2 commits
    • Ross McIlroy's avatar
      Reland "Get BytecodeArray via current frame where possible." · 3530998c
      Ross McIlroy authored 
      This is a reland of 7350e7b2

Disabled LayoutTest that was causing issues and will rebaseline once this has rolled.

Original change's description:
> Get BytecodeArray via current frame where possible.
>
> With BytecodeArray flushing the SFI->BytecodeArray pointer will become pseudo weak.
> Instead of getting the bytecode array from the SFI, get it from the frame instead
> (which is a strong pointer). Note: This won't actually change behaviour since the
> fact that the bytecode array was on the frame will retain it strongly, however it
> makes the contract that the BytecodeArray must exist at these points more explicit.
>
> Updates code in runtime-profiler.cc, frames.cc and runtime-test.cc to do this.
>
> BUG=v8:8395
>
> Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel
> Change-Id: Id7a3e6857abd0e89bf238e9b0b01de4461df54e1
> Reviewed-on: https://chromium-review.googlesource.com/c/1310193
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Mythri Alle <mythria@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57198}

TBR=mythria@chromium.org

Bug: v8:8395
Change-Id: I63044138f876a1cdfb8bb71499732a257f30d29a
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel
Reviewed-on: https://chromium-review.googlesource.com/c/1314336Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57219}
      3530998c
    • Maya Lekova's avatar
      Revert "Get BytecodeArray via current frame where possible." · ea27a244
      Maya Lekova authored 
      This reverts commit 7350e7b2.

Reason for revert: Braking layout test, blocking the roll, see
https://bugs.chromium.org/p/v8/issues/detail?id=8405

Original change's description:
> Get BytecodeArray via current frame where possible.
> 
> With BytecodeArray flushing the SFI->BytecodeArray pointer will become pseudo weak.
> Instead of getting the bytecode array from the SFI, get it from the frame instead
> (which is a strong pointer). Note: This won't actually change behaviour since the
> fact that the bytecode array was on the frame will retain it strongly, however it
> makes the contract that the BytecodeArray must exist at these points more explicit.
> 
> Updates code in runtime-profiler.cc, frames.cc and runtime-test.cc to do this.
> 
> BUG=v8:8395
> 
> Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel
> Change-Id: Id7a3e6857abd0e89bf238e9b0b01de4461df54e1
> Reviewed-on: https://chromium-review.googlesource.com/c/1310193
> Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
> Reviewed-by: Mythri Alle <mythria@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57198}

TBR=rmcilroy@chromium.org,mythria@chromium.org

Change-Id: Ie5db0ec1d68ca01d62e9880a4476704ad4d013b5
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8395
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel
Reviewed-on: https://chromium-review.googlesource.com/c/1314330Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57205}
      ea27a244