Skip to content

V
V8
Switch branch/tag
  1. 29 Oct, 2018 1 commit
  3. 25 Oct, 2018 1 commit
  5. 23 Oct, 2018 1 commit
    • Clemens Hammacher's avatar
      [wasm] Do not store ModuleEnv · 9716f689
      Clemens Hammacher authored 
      Instead, create it when needed and pass it down to the actual
compilation.
This saves memory by making the WasmCompilationUnit smaller and will
eventually allow us to implement the trap handler fallback correctly by
using an updated ModuleEnv in background compilation and tier up.

R=mstarzinger@chromium.org

Bug: v8:5277, v8:8343
Change-Id: I0dc3a37fb88e54eb4822dc99d58ff024f4b2a367
Reviewed-on: https://chromium-review.googlesource.com/c/1293953
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56896}
      9716f689
  7. 19 Oct, 2018 1 commit
  9. 16 Oct, 2018 1 commit
  11. 05 Oct, 2018 1 commit
  13. 02 Oct, 2018 1 commit
  15. 21 Sep, 2018 1 commit
  17. 14 Sep, 2018 1 commit
  19. 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
  21. 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
  23. 06 Aug, 2018 1 commit
  25. 02 Aug, 2018 2 commits
    • 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
    • Florian Sattler's avatar
      Reland "Applied noexcept to all mctors and massigns" · e2201a44
      Florian Sattler authored 
      This is a reland of baa055c7

Original change's description:
> Applied noexcept to all mctors and massigns
> 
> Refactoring the code base to use noexcept for their move constructors and move
> assignment operators.
> 
> Bug: v8:7999
> 
> Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel
> Change-Id: I13d24eddba3bfa601cff26fd680a040cf4e71426
> Reviewed-on: https://chromium-review.googlesource.com/1152817
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Marja Hölttä <marja@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Andreas Haas <ahaas@chromium.org>
> Commit-Queue: Florian Sattler <sattlerf@google.com>
> Cr-Commit-Position: refs/heads/master@{#54841}

Bug: v8:7999
Change-Id: I72394e326a4f8da462ee6285511d721440ceb21d
Cq-Include-Trybots: luci.chromium.try:linux_chromium_headless_rel;master.tryserver.blink:linux_trusty_blink_rel
Reviewed-on: https://chromium-review.googlesource.com/1158646Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Florian Sattler <sattlerf@google.com>
Cr-Commit-Position: refs/heads/master@{#54863}
      e2201a44
  27. 01 Aug, 2018 3 commits
  29. 26 Jul, 2018 1 commit
  31. 25 Jul, 2018 3 commits
  33. 24 Jul, 2018 1 commit
  35. 23 Jul, 2018 1 commit
  37. 19 Jul, 2018 1 commit
    • Andreas Haas's avatar
      [wasm][fuzzer] Do not execute code with potential non-determinism · 8f07a87d
      Andreas Haas authored 
      The WebAssembly spec is not fully deterministic: the sign bit of NaN
can be arbitrary. This sign bit can be observed by several WebAssembly
opcodes. In the testcase the sign bit of NaN makes the difference
between terminating code and an infinite loop.

In the libfuzzer fuzzer we have to prevent infinite loops ourselves.
At the moment we do this by only execute generated code of WebAssembly
modules for which the interpretation of the code ends in a limited
number of steps. With the non-determinism described above we cannot
guarantee the absence of infinite loops with this method. Therefore
we stop now to execute generated code of WebAssembly modules for which
we observe possible non-determinism in the interpreter.

R=clemensh@chromium.org

Bug: chromium:863829
Change-Id: I461d67df87d672bed25d6c915ba7ea5134cb5890
Reviewed-on: https://chromium-review.googlesource.com/1141945Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54541}
      8f07a87d
  39. 17 Jul, 2018 1 commit
  41. 16 Jul, 2018 1 commit
  43. 13 Jul, 2018 2 commits
  45. 12 Jul, 2018 2 commits
  47. 06 Jul, 2018 1 commit
  49. 05 Jul, 2018 1 commit
    • Andreas Haas's avatar
      [wasm][fuzzer] Do not execute modules with start function · df41fa7a
      Andreas Haas authored 
      In the WebAssembly fuzzers we detect infinite loops with the
interpreter: if the interpreter does not finish after a finite number
of steps, we do not execute the compiled code. However, we cannot
redirect the start function to the interpreter in the fuzzer, and
therefore we cannot detect infinite loops in the start function. With
this CL we avoid the problem completely by not instantiating a module
in the fuzzer which has a start function. Note that the module still
gets compiled.

R=clemensh@chromium.org

Bug: chromium:858914
Change-Id: Icbbe9a003544918d5267cdd1d9405b21bb681133
Reviewed-on: https://chromium-review.googlesource.com/1126766
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#54246}
      df41fa7a
  51. 03 Jul, 2018 1 commit
  53. 28 Jun, 2018 1 commit
  55. 23 Jun, 2018 1 commit
  57. 22 Jun, 2018 1 commit
  59. 21 Jun, 2018 1 commit
  61. 19 Jun, 2018 1 commit
  63. 18 Jun, 2018 1 commit
    • Clemens Hammacher's avatar
      [wasm] Store WasmModule in shared_ptr during async compilation · 6be6ec00
      Clemens Hammacher authored 
      We currently store the {WasmModule} (generated during decoding) in a
unique_ptr and pass ownership to the {WasmModuleObject} after
compilation.
I plan to move the {Managed<NativeModule>} from {WasmCompiledModule} to
{WasmModuleObject}, which will force us to create the
{WasmModuleObject} *before* compilation, so that the {CompilationState}
is available during compilation.

This CL prepares that refactoring by storing the {WasmModule} in a
{shared_ptr} in the {AsyncCompileJob}. Note that it will eventually be
stored in a {shared_ptr} in the {Managed} anyway.

R=titzer@chromium.org

Change-Id: Iac5e3c1067af2801e938f77a455a68807801526a
Reviewed-on: https://chromium-review.googlesource.com/1104117
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53801}
      6be6ec00
  65. 14 Jun, 2018 1 commit
    • Clemens Hammacher's avatar
      Reland "Introduce StdoutStream which prints to Android log or stdout" · 8e2e1257
      Clemens Hammacher authored 
      This is a reland of 0909dbe3.
Added missing V8_EXPORT_PRIVATE to AndroidLogStream.

TBR=mstarzinger@chromium.org

Original change's description:
> Introduce StdoutStream which prints to Android log or stdout
>
> The often used construct {OFStream(stdout)} does not work on Android.
> This CL introduces an {StdoutStream} which behaves exactly like
> {OFStream(stdout)} on non-android platforms, and redirects to the
> Android log on appropriate systems and configurations.
>
> R=mstarzinger@chromium.org
>
> Bug: v8:7820
> Change-Id: Ia682fdf6d064e37c605c19b032f5a10b96ac825b
> Reviewed-on: https://chromium-review.googlesource.com/1088911
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#53692}

Bug: v8:7820
Change-Id: I8164bad78a401dbe4246c9ffcacd050fe511ed58
Reviewed-on: https://chromium-review.googlesource.com/1100636Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53733}
      8e2e1257