Skip to content

V
V8
Switch branch/tag
  1. 18 Nov, 2019 1 commit
  3. 11 Nov, 2019 1 commit
  5. 08 Nov, 2019 1 commit
  7. 07 Nov, 2019 1 commit
  9. 05 Nov, 2019 2 commits
    • Eric Leese's avatar
      V8 Wasm locations should always be based on byte offsets · 5c23e6b5
      Eric Leese authored 
      Currently there are two ways wasm locations are represented in the
inspector. This remains unchanged for now. Also, currently there are
multiple ways location is represented within V8, with the line number
sometimes being a function index and sometimes being 0, and the column
number being a byte offset which is sometimes function relative and
sometimes module relative. With this change, the line number is never
used within V8 (it is always 0), and the column number is always a
byte offset from the beginning of the module. This simplifies
translation logic and keeps it in one place, and will simplify future
changes to wasm location representation in the inspector API.

Bug: chromium:1013527
Change-Id: I8813d47c881988f9ab49d7529fb81fe10dbbccff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1886915
Commit-Queue: Eric Leese <leese@chromium.org>
Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64774}
      5c23e6b5
    • Stefano Sanfilippo's avatar
      [compiler, api] Allow modifying codegen hook to block non-strings. · 6c0825aa
      Stefano Sanfilippo authored 
      Instead of inferring allow_codegen from the state of MaybeLocal<String>, return it separately. This allows to distinguish "could not stringify this object" from "block execution of this object", regardless of whether the object is a string or not. Currently, the hook can trigger an EvalError only if the original source was a string.

Modify the logic so that one of the three mechanisms (unconditional, non-modifying, modifying) decides alone. Before, if the non-modifying callback rejected a value, the value would be forwarded to the modifying callback, but the unconditional would not forward to the non-modifying callback. This introduces a more uniform behaviour where the three mechanisms act in decreasing priority.

Change-Id: Iaaa9873227052653d714df65f31c4de914f48b7d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1776082Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarDaniel Vogelheim <vogelheim@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Commit-Queue: Stefano Sanfilippo <ssanfilippo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64763}
      6c0825aa
  11. 01 Nov, 2019 1 commit
  13. 30 Oct, 2019 1 commit
  15. 29 Oct, 2019 1 commit
  17. 28 Oct, 2019 1 commit
  19. 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
  21. 23 Oct, 2019 3 commits
  23. 22 Oct, 2019 3 commits
  25. 21 Oct, 2019 2 commits
  27. 18 Oct, 2019 1 commit
  29. 17 Oct, 2019 1 commit
    • 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
  31. 15 Oct, 2019 1 commit
  33. 12 Oct, 2019 1 commit
  35. 11 Oct, 2019 1 commit
  37. 10 Oct, 2019 1 commit
  39. 09 Oct, 2019 2 commits
  41. 08 Oct, 2019 1 commit
  43. 07 Oct, 2019 1 commit
    • Michael Lippautz's avatar
      [api, heap] Implement TracedReference · 36774683
      Michael Lippautz authored 
      TracedGlobalTrait was unable to override v8::TracedGlobal<v8::Object> for
avoiding the destructor because it is needed on the API surface itself and C++
ODR which prohibits specialization after template instantiation.

Avoid this problem by providing a separate type TracedReference
that, similar to TracedGlobal, is purely traced but avoids the destructor
completely. This only works for embedders that have their memory management
tied to V8 as it is prone to accessing already reclaimed objects otherwise.

Bug: chromium:995684
Change-Id: Iab4332ed417b26c58638a8f9389174cc355a305b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1840972
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64150}
      36774683
  45. 04 Oct, 2019 2 commits
  47. 02 Oct, 2019 1 commit
    • Jakob Gruber's avatar
      Remove JS natives support, step 1 · 28a9dc2b
      Jakob Gruber authored 
      The natives blob is deprecated and will be removed in the next
release.

This commit does two things, 1. it disables the v8_extra_library_files
gn argument which will make building natives_blob.bin through gn
impossible; 2. it marks API functions associated with the natives blob
as V8_DEPRECATE_SOON.

Embedders should remove any uses of SetNativesDataBlob and replace all
calls to

 InitializeExternalStartupData(const char*, const char*)

with the new function

 InitializeExternalStartupDataFromFile(const char*)

Step 2 is to mark API functions as V8_DEPRECATED.
Step 3, in the next V8 release, is to remove these functions and all
other natives support in V8.

Bug: v8:7624
Change-Id: I745e96c60204a9b94d9240be65dd59bb9bdd0699
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1824944
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64080}
      28a9dc2b
  49. 01 Oct, 2019 1 commit
  51. 19 Sep, 2019 2 commits
  53. 13 Sep, 2019 1 commit
  55. 11 Sep, 2019 1 commit
  57. 09 Sep, 2019 1 commit
    • Ulan Degenbaev's avatar
      Reland x6 [arraybuffer] Rearchitect backing store ownership · b6b7de0d
      Ulan Degenbaev authored 
      This reverts commit 9da34831

Original change's description:
> "Reland x4 [arraybuffer] Rearchitect backing store ownership"
>
> This is a reland of bc33f5ae
>
> Contributed by titzer@chromium.org
>
> Original change's description:
> > [arraybuffer] Rearchitect backing store ownership
> >
> > This CL completely rearchitects the ownership of array buffer backing stores,
> > consolidating ownership into a {BackingStore} C++ object that is tracked
> > throughout V8 using unique_ptr and shared_ptr where appropriate.
> >
> > Overall, lifetime management is simpler and more explicit. The numerous
> > ways that array buffers were initialized have been streamlined to one
> > Attach() method on JSArrayBuffer. The array buffer tracker in the
> > GC implementation now manages std::shared_ptr<BackingStore> pointers,
> > and the construction and destruction of the BackingStore object itself
> > handles the underlying page or embedder-allocated memory.
> >
> > The embedder API remains unchanged for now. We use the
> > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to
> > keep the backing store alive properly, even in the case of aliases
> > from live heap objects. Thus the embedder has a lower chance of making
> > a mistake. Long-term, we should move the embedder to a model where they
> > manage backing stores using shared_ptr to an opaque backing store object.
>
> TBR=yangguo@chromium.org
>
> BUG=v8:9380,v8:9221,chromium:986318
>
> Change-Id: If671a4a9ca0476e8f084efae46e0d2bf99ed99ef
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731005
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>

> Cr-Commit-Position: refs/heads/master@{#63041}

TBR=yangguo@chromium.org

Change-Id: I3cc4bb80081c662b1751234bc16a821c20e744be
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1792166
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63617}
      b6b7de0d
  59. 30 Aug, 2019 1 commit
    • Ulan Degenbaev's avatar
      Revert "Reland x5 [arraybuffer] Rearchitect backing store ownership" · 9da34831
      Ulan Degenbaev authored 
      This reverts commit 62e16830.

Reason for revert: it will be relanded after branch

Original change's description:
> Reland x5 [arraybuffer] Rearchitect backing store ownership
> 
> This reverts commit 8fdb2387.
> 
> Original change's description:
> > "Reland x4 [arraybuffer] Rearchitect backing store ownership"
> >
> > This is a reland of bc33f5ae
> >
> > Contributed by titzer@chromium.org
> >
> > Original change's description:
> > > [arraybuffer] Rearchitect backing store ownership
> > >
> > > This CL completely rearchitects the ownership of array buffer backing stores,
> > > consolidating ownership into a {BackingStore} C++ object that is tracked
> > > throughout V8 using unique_ptr and shared_ptr where appropriate.
> > >
> > > Overall, lifetime management is simpler and more explicit. The numerous
> > > ways that array buffers were initialized have been streamlined to one
> > > Attach() method on JSArrayBuffer. The array buffer tracker in the
> > > GC implementation now manages std::shared_ptr<BackingStore> pointers,
> > > and the construction and destruction of the BackingStore object itself
> > > handles the underlying page or embedder-allocated memory.
> > >
> > > The embedder API remains unchanged for now. We use the
> > > v8::ArrayBuffer::Contents struct to hide an additional shared_ptr to
> > > keep the backing store alive properly, even in the case of aliases
> > > from live heap objects. Thus the embedder has a lower chance of making
> > > a mistake. Long-term, we should move the embedder to a model where they
> > > manage backing stores using shared_ptr to an opaque backing store object.
> >
> > TBR=yangguo@chromium.org
> >
> > BUG=v8:9380,v8:9221,chromium:986318
> >
> > Change-Id: If671a4a9ca0476e8f084efae46e0d2bf99ed99ef
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1731005
> > Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#63041}
> 
> TBR=yangguo@chromium.org,clemensh@chromium.org,mstarzinger@chromium.org
> 
> Change-Id: Iba55c7ab71e5642b5cb6aeb699d6fc9cf9061486
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1771795
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#63461}

TBR=ulan@chromium.org,mlippautz@chromium.org

Change-Id: Id8f67a68ab398032eb2975b1b24ee125394d9c4b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1776095Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63471}
      9da34831
  61. 29 Aug, 2019 1 commit