Skip to content

V
V8
Switch branch/tag
  1. 26 Jul, 2018 1 commit
  3. 25 Jul, 2018 3 commits
  5. 24 Jul, 2018 1 commit
  7. 23 Jul, 2018 1 commit
  9. 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
  11. 17 Jul, 2018 1 commit
  13. 16 Jul, 2018 1 commit
  15. 13 Jul, 2018 2 commits
  17. 12 Jul, 2018 2 commits
  19. 06 Jul, 2018 1 commit
  21. 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
  23. 03 Jul, 2018 1 commit
  25. 28 Jun, 2018 1 commit
  27. 23 Jun, 2018 1 commit
  29. 22 Jun, 2018 1 commit
  31. 21 Jun, 2018 1 commit
  33. 19 Jun, 2018 1 commit
  35. 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
  37. 14 Jun, 2018 2 commits
    • 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
    • Michael Achenbach's avatar
      Revert "Introduce StdoutStream which prints to Android log or stdout" · d2e1620c
      Michael Achenbach authored 
      This reverts commit 0909dbe3.

Reason for revert: Blocks roll:
https://chromium-review.googlesource.com/c/chromium/src/+/1099143

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}

TBR=mstarzinger@chromium.org,jarin@chromium.org,jgruber@chromium.org,clemensh@chromium.org,bmeurer@chromium.org

Change-Id: Iadadd9a0df10dca0fad647138a83db50148e864d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7820
Reviewed-on: https://chromium-review.googlesource.com/1100635Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53725}
      d2e1620c
  39. 13 Jun, 2018 1 commit
  41. 12 Jun, 2018 1 commit
  43. 05 Jun, 2018 1 commit
  45. 01 Jun, 2018 1 commit
  47. 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
  49. 07 May, 2018 1 commit
  51. 30 Apr, 2018 2 commits
  53. 27 Apr, 2018 1 commit
    • Clemens Hammacher's avatar
      [wasm] Split off wasm-linkage.h · 8466b71a
      Clemens Hammacher authored 
      Linkage-related methods were declared in wasm-compiler.h and
implemented in wasm-linkage.cc. This required all users of e.g. wasm
call descriptors to include the whole wasm compiler header. Also, some
wasm linkage information is independent of turbofan and also used
outside of the compiler directory.

This CL splits off wasm-linkage.h (with minimal includes) and puts it
in src/wasm. This allows to use that information without including
compiler headers (will clean up several uses in follow-up CLs).

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

Bug: v8:7570
Change-Id: Ifcae70b4ea7932cda30953b325c2b87c4176c598
Reviewed-on: https://chromium-review.googlesource.com/1013701Reviewed-by: 's avatarBen Titzer <titzer@chromium.org>
Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52849}
      8466b71a
  55. 24 Apr, 2018 2 commits
  57. 16 Apr, 2018 1 commit
  59. 14 Apr, 2018 1 commit
    • Jakob Kummerow's avatar
      [ubsan] Change Address typedef to uintptr_t · 2459046c
      Jakob Kummerow authored 
      The "Address" type is V8's general-purpose type for manipulating memory
addresses. Per the C++ spec, pointer arithmetic and pointer comparisons
are undefined behavior except within the same array; since we generally
don't operate within a C++ array, our general-purpose type shouldn't be
a pointer type.

Bug: v8:3770
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ib96016c24a0f18bcdba916dabd83e3f24a1b5779
Reviewed-on: https://chromium-review.googlesource.com/988657
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#52601}
      2459046c
  61. 09 Apr, 2018 1 commit
  63. 06 Apr, 2018 2 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
    • 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