Skip to content

V
V8
Switch branch/tag
  1. 24 Sep, 2018 1 commit
    • Dan Elphick's avatar
      [deprecation] Deprecate ToBoolean(Local<Context>) · d235f550
      Dan Elphick authored 
      ToBoolean and BooleanValue cannot throw exceptions so the Maybe versions
of the functions don't make sense. As such this deprecates the Maybe
versions and undeprecates ToBoolean(Isolate*). It also adds
BooleanValue(Isolate*).

Fix up all of the v8 code to not use the deprecated functions.

Bug: v8:7279, v8:8015
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: I50e7474d205c75baa153f0dea7f02dcf60232d1d
Reviewed-on: https://chromium-review.googlesource.com/1238476
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56163}
      d235f550
  3. 17 Sep, 2018 1 commit
  5. 13 Sep, 2018 1 commit
  7. 11 Sep, 2018 1 commit
    • Andreas Haas's avatar
      [wasm] Return immediately if code generation is not allowed · cecd2ed5
      Andreas Haas authored 
      There was a bug in WebAssembly.instantiate in the case where a CSP
disallows WebAssembly compilation. In this case the promise returned by
WebAssembly.instantiate was rejected immediately because of the CSP,
but then compilation was started anyways, and the promise was resolved
after compilation for a second time, which caused the crash. With this
CL we do not start compilation if CSP disallows WebAssembly compilation.

R=clemensh@chromium.org

Bug: chromium:881978
Change-Id: Iffdb3e02c3006eb7f86211ab197f81cf20438f0e
Reviewed-on: https://chromium-review.googlesource.com/1219706
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55788}
      cecd2ed5
  9. 10 Sep, 2018 1 commit
  11. 14 Aug, 2018 1 commit
    • Andreas Haas's avatar
      Reland "[wasm] Implement the new API for WebAssembly.instantiateStreaming" · 3e545e40
      Andreas Haas authored 
      The problem was that in AsyncCompileJob::FinishModule we allocate a
handle, but when this function is called from streaming compilation, then
there was no HandleScope around AsyncCompileJob::FinishModule. This issue
was fixed in another CL, https://crrev.com/c/1172357. This CL is just a
rebase of the original CL.

Original change's description:
> [wasm] Implement the new API for WebAssembly.instantiateStreaming

> This is the second V8 CL to refactor WebAssembly.instantiateStreaming to
> make it spec compliant again. The design doc where the whole change is
> discussed is available in the tracking bug. The tracking bug also
> references prototype implementations of the whole change, which includes
> the changes in this CL.

R=starzinger@chromium.org

Bug: chromium:860637
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: Ib0cb25488654d2b325b4f529d33b76b846c64436
Reviewed-on: https://chromium-review.googlesource.com/1172429Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55106}
      3e545e40
  13. 13 Aug, 2018 1 commit
    • Andreas Haas's avatar
      [wasm] Check the isolate if WebAssembly threads are enabled. · 1408e127
      Andreas Haas authored 
      With the origin trial for WebAssembly threads, threads can be turned on
and off by the embedder depending on the context we are currently in.
With this CL we call the embedder callback stored on the isolate to
determine whether threads are enabled in the current context or not.

Design decision:
I decided to extend the {WasmFeaturesFromIsolate} function to ask the
embedder if WebAssembly threads are enabled. This is the function which
defines dynamically which features are turned on. It would be awkward
to have two such functions, one which calls the embedder and one which
does not.
A downside is that in WasmJs::Install the embedder does not seem to be
ready to be called. That's why I changed the code there to call
{WasmFeaturesFromFlags} instead.

R=titzer@chromium.org, mstarzinger@chromium.org

Bug: chromium:868844
Change-Id: I6bfa89960a54cec71992756e3717bbb3a9fe195e
Reviewed-on: https://chromium-review.googlesource.com/1169180
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55076}
      1408e127
  15. 10 Aug, 2018 1 commit
  17. 09 Aug, 2018 1 commit
    • Ben L. Titzer's avatar
      [wasm] Add WasmFeatures to enable/detect features · 6aa2a253
      Ben L. Titzer authored 
      This CL introduces a set of configuration options implemented as
a struct of booleans that together comprise the set of enabled
or detected features. The configuration options replace command-line
flags that were checked deep in the implementation. As such, it is
necessary to plumb them through multiple levels of abstraction.

R=ahaas@chromium.org
CC=mstarzinger@chromium.org
BUG=chromium:868844

Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I1b82f5826e4fd263f68e8cafcd923bac5818a637
Reviewed-on: https://chromium-review.googlesource.com/1163670Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#55018}
      6aa2a253
  19. 07 Aug, 2018 1 commit
    • Andreas Haas's avatar
      [wasm] During instantiation, pending_exceptions dominate new exceptions · 5f105141
      Andreas Haas authored 
      For async instantiation of WebAssembly code we had the assumption that
a pending exceptions (an exception which comes from
execution JS code) and an ErrorThrower error cannot occur at the same
time. This assumption turned out to be wrong. With this CL we handle
this case by prefering pending_exceptions over ErrorThrower errors.

In addition I extended the tests for failing instantiation to also
exercise async instantiation, and I added a regression test.

R=clemensh@chromium.org

Bug: chromium:870646
Change-Id: I4cb54ff8642ad4ea193b20f79905c9f6508c2b2e
Reviewed-on: https://chromium-review.googlesource.com/1163511Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54940}
      5f105141
  21. 02 Aug, 2018 1 commit
    • Andreas Haas's avatar
      Revert "[wasm] Implement the new API for WebAssembly.instantiateStreaming" · fea9300d
      Andreas Haas authored 
      This reverts commit b556c9ea.

Reason for revert: Flakes in layout tests: https://crbug.com/870187

Original change's description:
> [wasm] Implement the new API for WebAssembly.instantiateStreaming
> 
> This is the second V8 CL to refactor WebAssembly.instantiateStreaming to
> make it spec compliant again. The design doc where the whole change is
> discussed is available in the tracking bug. The tracking bug also
> references prototype implementations of the whole change, which includes
> the changes in this CL.
> 
> R=​mstarzinger@chromium.org
> 
> Bug: chromium:860637
> Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
> Change-Id: I776c0f24959ab5663727d3dfee0248a9b0642a42
> Reviewed-on: https://chromium-review.googlesource.com/1143187
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#54834}

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

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

Bug: chromium:860637
Change-Id: Icbf2603143068a49c61de162aa7185a753703e5d
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/1160261Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54872}
      fea9300d
  23. 01 Aug, 2018 1 commit
  25. 31 Jul, 2018 1 commit
  27. 23 Jul, 2018 1 commit
  29. 13 Jul, 2018 1 commit
  31. 12 Jul, 2018 1 commit
    • Andreas Haas's avatar
      [wasm] Prepare API changes for WebAssembly.instantiateStreaming · 7971f9d6
      Andreas Haas authored 
      This is the first CL to refactor WebAssembly.instantiateStreaming to
make it spec compliant again. The design doc where the whole change is
discussed is available in the tracking bug. The tracking bug also
references prototype implementations of the whole change, which includes
the changes in this CL.

Tests for the new API functions will be added with the second V8 CL
which adds the implementation of the API functions.

R=ulan@chromium.org

Bug: chromium:860637
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: Ia1048b7ca0291c824ef4212ebde2c6054e102069
Reviewed-on: https://chromium-review.googlesource.com/1127667Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54393}
      7971f9d6
  33. 04 Jul, 2018 1 commit
  35. 23 Jun, 2018 1 commit
  37. 19 Jun, 2018 1 commit
  39. 30 May, 2018 1 commit
  41. 24 May, 2018 1 commit
    • Andreas Haas's avatar
      [wasm] Reimplement WebAssembly.instantiate without desugaring · 8a95da24
      Andreas Haas authored 
      At the moment, WebAssembly.instantiate(bytes) is implemented by
desugaring it to WebAssembly.compile(bytes).then(WebAssembly.instantiate).
The problem is that the {then} in this snippet is observable. With this
CL I introduce a CompilationResultResolver which allows to do the
desugaring internally and thereby make the {then} unobservable.
Unfortunately the result of WebAssembly.instantiate(bytes) is different
than the result of WebAssembly.instantiate(module). Therefore I also
introduced an InstantiationResultResolver for symmetry with
WebAssembly.compile.

R=mstarzinger@chromium.org
Bug: chromium:837417

Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I2d98e03d65f2ada19041d5a9e2df5da91b24ccca
Reviewed-on: https://chromium-review.googlesource.com/1059783
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53347}
      8a95da24
  43. 02 May, 2018 1 commit
  45. 27 Apr, 2018 3 commits
  47. 26 Apr, 2018 1 commit
  49. 24 Apr, 2018 1 commit
    • Andreas Haas's avatar
      [wasm] Call AsyncInstantiate directly when instantiating a module object · 49712d8a
      Andreas Haas authored 
      WebAssembly.instantiate is polymorphic, it can either take a module
object as parameter, or a buffer source which should be compiled first.
To share code between the two implementations, the module object was
first passed to a promise (i.e. which is the result of compilation).
However, passing the module object to a promise has a side effect if
the module object has a then function. To avoid this side effect I
remove this code sharing and call AsyncInstantiate directly in case
the parameter is a module object.

R=mstarzinger@chromium.org

Bug: chromium:836141
Change-Id: I67b76d0d7761c5aeb2cf1deda45b6842e494eed4
Reviewed-on: https://chromium-review.googlesource.com/1025774Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52755}
      49712d8a
  51. 16 Apr, 2018 1 commit
  53. 09 Apr, 2018 2 commits
  55. 06 Apr, 2018 3 commits
    • Michael Achenbach's avatar
      Revert "[cleanup] Refactor the Factory" · 503e07c3
      Michael Achenbach authored 
      This reverts commit f9a2e24b.

Reason for revert: gc stress failures not all fixed by follow up.

Original change's description:
> [cleanup] Refactor the Factory
> 
> There is no good reason to have the meat of most objects' initialization
> logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead,
> this CL changes the protocol between Heap and Factory to be AllocateRaw,
> and all object initialization work after (possibly retried) successful
> raw allocation happens in the Factory.
> 
> This saves about 20KB of binary size on x64.
> 
> Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
> Change-Id: Icbfdc4266d7be8b48d2fe085f03411743dc6a0ca
> Reviewed-on: https://chromium-review.googlesource.com/959533
> Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Hannes Payer <hpayer@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52416}

TBR=jkummerow@chromium.org,yangguo@chromium.org,mstarzinger@chromium.org,hpayer@chromium.org

Change-Id: Idbbc53478742f3e9525eee83342afc6aedae122f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/999414Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52420}
      503e07c3
    • Michael Achenbach's avatar
      Revert "[wasm] Always enable guard regions on 64-bit platforms" · ab572da2
      Michael Achenbach authored 
      This reverts commit ad221d14.

Reason for revert: Layout test failures:
https://build.chromium.org/p/client.v8.fyi/builders/V8-Blink%20Linux%2064/builds/22780

Original change's description:
> [wasm] Always enable guard regions on 64-bit platforms
> 
> This change makes full 8 GiB guard regions always enabled on 64-bit
> platforms.
> 
> Additionally, since all Wasm memory allocation paths have some form of
> guard regions, this removes and simplifies most of the logic around
> whether to enable guard regions.
> 
> This is a reland of https://crrev.com/c/985142.
> 
> Bug: v8:7619
> Change-Id: I8bf1f86d6f89fd0bb2144431c7628f15a6b00ba0
> Reviewed-on: https://chromium-review.googlesource.com/996466
> Reviewed-by: Brad Nelson <bradnelson@chromium.org>
> Commit-Queue: Eric Holk <eholk@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#52412}

TBR=bradnelson@chromium.org,eholk@chromium.org

Change-Id: Ic15d14c6fa69300bc0fdc036b9fee8ecf65fd397
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7619
Reviewed-on: https://chromium-review.googlesource.com/999412Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52418}
      ab572da2
    • Jakob Kummerow's avatar
      [cleanup] Refactor the Factory · f9a2e24b
      Jakob Kummerow authored 
      There is no good reason to have the meat of most objects' initialization
logic in heap.cc, all wrapped by the CALL_HEAP_FUNCTION macro. Instead,
this CL changes the protocol between Heap and Factory to be AllocateRaw,
and all object initialization work after (possibly retried) successful
raw allocation happens in the Factory.

This saves about 20KB of binary size on x64.

Cq-Include-Trybots: luci.v8.try:v8_linux_noi18n_rel_ng
Change-Id: Icbfdc4266d7be8b48d2fe085f03411743dc6a0ca
Reviewed-on: https://chromium-review.googlesource.com/959533
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarHannes Payer <hpayer@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52416}
      f9a2e24b
  57. 05 Apr, 2018 2 commits
  59. 04 Apr, 2018 1 commit
  61. 03 Apr, 2018 2 commits
  63. 30 Mar, 2018 1 commit
  65. 16 Mar, 2018 1 commit