1. 01 Nov, 2019 1 commit
  2. 30 Oct, 2019 1 commit
  3. 29 Oct, 2019 1 commit
  4. 28 Oct, 2019 1 commit
  5. 24 Oct, 2019 1 commit
    • Anna Henningsen's avatar
      [api] Add possibility for BackingStore to keep Allocator alive · 6b0a9535
      Anna Henningsen authored
      Add an `array_buffer_allocator_shared` field to the
      `Isolate::CreateParams` struct that allows embedders to share
      ownership of the ArrayBuffer::Allocator with V8, and which in
      particular means that when this method is used that the
      BackingStore deleter will not perform an use-after-free access to the
      Allocator under certain circumstances.
      
      For Background:
      
      tl;dr: This is necessary for Node.js to perform the transition to
      V8 7.9, because of the way that ArrayBuffer::Allocators and their
      lifetimes currently work there.
      
      In Node.js, each Worker thread has its own ArrayBuffer::Allocator.
      Changing that would currently be impractical, as each allocator
      depends on per-Isolate state. However, now that backing stores
      are managed globally and keep a pointer to the original
      ArrayBuffer::Allocator, this means that when transferring an
      ArrayBuffer (e.g. from one Worker to another through postMessage()),
      the original Allocator has to be kept alive until the ArrayBuffer
      no longer exists in the receiving Isolate (or until that Isolate
      is disposed). See [1] for an example Node.js test that fails with
      V8 7.9.
      
      This problem also existed for SharedArrayBuffers, where Node.js
      was broken by V8 earlier for the same reasons (see [2] for the bug
      report on that and [3] for the resolution in Node.js).
      For SharedArrayBuffers, we already had extensive tracking logic,
      so adding a shared_ptr to keep alive the ArrayBuffer::Allocator
      was not a significant amount of work. However, the mechanism for
      transferring non-shared ArrayBuffers is quite different, and
      it seems both easier for us and better for V8 from an API standpoint
      to keep the Allocator alive from where it is being referenced.
      
      By sharing memory with the custom deleter function/data pair,
      this comes at no memory overhead.
      
      [1]: https://github.com/nodejs/node/pull/30044
      [2]: https://github.com/nodejs/node-v8/issues/115
      [3]: https://github.com/nodejs/node/pull/29637
      
      Bug: v8:9380
      Change-Id: Ibc2c4fb6341b53653cbd637bd8cb3d4ac43809c7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1874347
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64542}
      6b0a9535
  6. 23 Oct, 2019 3 commits
  7. 22 Oct, 2019 4 commits
  8. 21 Oct, 2019 4 commits
  9. 18 Oct, 2019 1 commit
  10. 17 Oct, 2019 3 commits
    • Toon Verwaest's avatar
      Reland^2 "[runtime] Move Context::native_context to the map" · 3cad6bf5
      Toon Verwaest authored
      This is a reland of c7c47c68.
      
      This makes TSAN happy in addition to:
      
      Previously I presumed that the context read from a frame in the profiler was
      a valid context. Turns out that on non-intel we're not guaranteed that the
      frame is properly set up. In the case we looked at, the profiler took a
      sample right before writing the frame marker indicating a builtin frame,
      causing the "context" pointer from that frame to be a bytecode array. Since
      we'll read random garbage on the stack as a possible context pointer, I made
      the code reading the native context from it a little more defensive.
      
      Bug: v8:9860
      Tbr: ulan@chromium.org, neis@chromium.org, ishell@chromium.org
      
      Original change's description:
      > [runtime] Move Context::native_context to the map
      >
      > Remove the native context slot from contexts by making context maps
      > native-context-specific. Now we require 2 loads to go from a context to the
      > native context, but we have 1 field fewer to store when creating contexts.
      >
      > Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629
      > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Maya Lekova <mslekova@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#64296}
      
      Change-Id: I4d0ab4cbbb23a9ae616407f17ef8f35a0b68ddb4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864654
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64360}
      3cad6bf5
    • Clemens Backes's avatar
      Update V8 version to 8.0 · 503917b1
      Clemens Backes authored
      TBR=machenbach@chromium.org
      CC=hablich@chromium.org
      
      No-Try: true
      Change-Id: I19512e953adce96c5d559e4552543fe2c11042d2
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863937Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64353}
      503917b1
    • Zhou, Zhiguo's avatar
      Log debug info of WASM for Intel VTune Amplifier · ec580709
      Zhou, Zhiguo authored
      This CL logs debug information of WASM in Intel VTune Amplifer via
      VTune's JIT Profiling API. With this CL, the profiling information
      of JITted code and its corresponding C/C++ source code is displayed
      optionally. To use this feature, a runtime flag "vtune_prof_annotat
      e_wasm" should be passed to the VTune-enabled V8 engine. Currently,
      the inline function in C/C++ is not well supported due to the
      limitation of source map.
      
      As a drive-by fix, the dynamically allocated event-specific data
      of JavaScript (src/third_party/vtune/vtune-jit.cc) is managed with
      C++ containers for safety.
      
      Change-Id: Ic27420fcdcd775bc5c7778abf5cff6edf0fb38b6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1782126Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Zhiguo Zhou <zhiguo.zhou@intel.com>
      Cr-Commit-Position: refs/heads/master@{#64351}
      ec580709
  11. 16 Oct, 2019 3 commits
    • Sathya Gunasekaran's avatar
      Revert "Reland "[runtime] Move Context::native_context to the map"" · 38301e7b
      Sathya Gunasekaran authored
      This reverts commit c7c47c68.
      
      Reason for revert: breaks TSAN
      https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/28738
      
      Original change's description:
      > Reland "[runtime] Move Context::native_context to the map"
      > 
      > This is a reland of f05bae1e
      > 
      > Previously I presumed that the context read from a frame in the profiler was
      > a valid context. Turns out that on non-intel we're not guaranteed that the
      > frame is properly set up. In the case we looked at, the profiler took a
      > sample right before writing the frame marker indicating a builtin frame,
      > causing the "context" pointer from that frame to be a bytecode array. Since
      > we'll read random garbage on the stack as a possible context pointer, I made
      > the code reading the native context from it a little more defensive.
      > 
      > Bug: v8:9860
      > 
      > Original change's description:
      > > [runtime] Move Context::native_context to the map
      > >
      > > Remove the native context slot from contexts by making context maps
      > > native-context-specific. Now we require 2 loads to go from a context to the
      > > native context, but we have 1 field fewer to store when creating contexts.
      > >
      > > Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629
      > > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      > > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > > Reviewed-by: Maya Lekova <mslekova@chromium.org>
      > > Reviewed-by: Georg Neis <neis@chromium.org>
      > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#64296}
      > 
      > Change-Id: If9461e9b21d35a260d71c79d7f95e518cc429e09
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864930
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      > Auto-Submit: Toon Verwaest <verwaest@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#64314}
      
      TBR=ulan@chromium.org,neis@chromium.org,petermarshall@chromium.org,ishell@chromium.org,verwaest@chromium.org,mslekova@chromium.org,victorgomes@google.com
      
      Change-Id: I4f9edc62ea6f9f5857619ff0ad1a63cab4b33cc3
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9860
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864937Reviewed-by: 's avatarSathya Gunasekaran  <gsathya@chromium.org>
      Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64316}
      38301e7b
    • Toon Verwaest's avatar
      Reland "[runtime] Move Context::native_context to the map" · c7c47c68
      Toon Verwaest authored
      This is a reland of f05bae1e
      
      Previously I presumed that the context read from a frame in the profiler was
      a valid context. Turns out that on non-intel we're not guaranteed that the
      frame is properly set up. In the case we looked at, the profiler took a
      sample right before writing the frame marker indicating a builtin frame,
      causing the "context" pointer from that frame to be a bytecode array. Since
      we'll read random garbage on the stack as a possible context pointer, I made
      the code reading the native context from it a little more defensive.
      
      Bug: v8:9860
      
      Original change's description:
      > [runtime] Move Context::native_context to the map
      >
      > Remove the native context slot from contexts by making context maps
      > native-context-specific. Now we require 2 loads to go from a context to the
      > native context, but we have 1 field fewer to store when creating contexts.
      >
      > Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629
      > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Reviewed-by: Maya Lekova <mslekova@chromium.org>
      > Reviewed-by: Georg Neis <neis@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#64296}
      
      Change-Id: If9461e9b21d35a260d71c79d7f95e518cc429e09
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864930Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Auto-Submit: Toon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64314}
      c7c47c68
    • Clemens Backes's avatar
      Rename V8_CAN_HAVE_DCHECK_IN_CONSTEXPR to V8_HAS_CXX14_CONSTEXPR · 14324148
      Clemens Backes authored
      DCHECKs are not really special, they just create a non-constexpr path
      within an otherwise constexpr function. Since C++14, this is allowed.
      Unfortunately, gcc only supports this since version 6, but we still
      need to support gcc 5.
      
      R=ulan@chromium.org
      
      Change-Id: If74486144abafa5bbdcdbb9a567ee9295ac4cfc7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1862568Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64310}
      14324148
  12. 15 Oct, 2019 4 commits
  13. 14 Oct, 2019 1 commit
  14. 12 Oct, 2019 1 commit
  15. 11 Oct, 2019 1 commit
  16. 10 Oct, 2019 1 commit
  17. 09 Oct, 2019 4 commits
  18. 08 Oct, 2019 2 commits
    • Irina Yatsenko's avatar
      Add full heap dump crash key trigger and use it for crashes under ScavengePage. · 557c745e
      Irina Yatsenko authored
      Bug: chromium:1010312
      Change-Id: I46ca9349f15f3dac896a4ab631be672c1979cc48
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1838927
      Commit-Queue: Irina Yatsenko <irinayat@microsoft.com>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64167}
      557c745e
    • Ingvar Stepanyan's avatar
      [wasm] Pretend that DWARF section is a fake source map · 1b5f3be0
      Ingvar Stepanyan authored
      Unfortunately, codebase contains lots of places that use one of the two
      formats as an internal representation for Wasm locations:
      1) {line: 0, column: byte offset within entire module}
      2) {line: function index, column: byte offset within function}
      
      These places choose these formats interchangeably and convert from one
      to another depending on the presence of source map URL in Wasm.
      
      This is not very convenient and makes it hard to add support for DWARF
      which should behave just like Wasm with source maps - that is, report a
      raw Wasm script instead of fake scripts per each disassembled function,
      and use representation (1) instead of (2) internally.
      
      I tried to refactor these locations and avoid checking for source map
      URLs in the previous CL - https://crrev.com/c/v8/v8/+/1833688. However,
      it quickly got out of hand, and updating code in one place just kept
      revealing yet another that gets broken by the changes, so I made a
      decision to abandon it and leave to someone who knows the codebase
      better.
      
      Instead, this CL is based on https://crrev.com/c/v8/v8/+/1809375, but,
      rather than trying to integrate DWARF separately and only for supported
      agents, it pretends that encountering DWARF section is the same as
      encountering a `sourceMappingURL` section with fake URL "wasm://dwarf".
      
      This ensures that Wasm with DWARF behaves exactly in the same way as
      Wasm with source maps, just like we want, with minimal changes to the
      codebase. The only downside is that frontends without DWARF support
      won't get even a disassembled version of Wasm that contains DWARF info.
      This is unfortunate, but, as per previous discussions, should be fine
      given current state of Wasm debugging.
      
      Change-Id: Ia7256075e4bfd2f407d001d02b96883d7267436e
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1834341
      Commit-Queue: Ingvar Stepanyan <rreverser@google.com>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64157}
      1b5f3be0
  19. 07 Oct, 2019 2 commits
  20. 04 Oct, 2019 1 commit