Skip to content

V
V8
Switch branch/tag
  1. 27 Sep, 2021 1 commit
  3. 31 Aug, 2021 1 commit
    • Manos Koukoutos's avatar
      [wasm] Support reftypes tables in WasmModuleBuilder · 797e4afe
      Manos Koukoutos authored 
      WasmModuleBuilder is a class that is used to build Wasm modules in the
asm.js parser, in the fuzzer, as well as some tests. When it comes to
Wasm tables, WasmModuleBuilder currently supports only basic tables
(before the reftypes proposal) using an ad-hoc indirect-function index
vector.
This CL adds proper support for element sections and tables that use
them in the full potential of the reftypes extension. The new
functionality will only be used in the fuzzer and potentially some tests
in the future. Along this, we drop some functionality from
WasmModuleBuilder that was only used in tests and is redundant with the
new architecture.
Additionally, we remove tables other than externref and funcref from the
fuzzer (which were not supported properly or used anyway). We will
reintroduce them at a later time.

Bug: v8:11954
Change-Id: I0a4f6e7b63b6e3d9f7da03b5202fbf14d8678332
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3122162
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76597}
      797e4afe
  5. 06 Jul, 2021 1 commit
  7. 01 Jul, 2021 1 commit
  9. 24 Jun, 2021 3 commits
  11. 21 Jun, 2021 1 commit
  13. 18 Jun, 2021 1 commit
  15. 14 Jun, 2021 1 commit
  17. 07 Jun, 2021 1 commit
  19. 25 May, 2021 1 commit
    • Clemens Backes's avatar
      [wasm] Clean up spec'ed max memory vs dynamic max · 2d04a627
      Clemens Backes authored 
      There are two different limits for the maximum memory size in
WebAssembly:
1) A 4GB limit which is the same on all platforms, and is observable for
JS programs. It is used to limit the allowed declared maximum size of a
wasm memory.
2) A potentially lower limit (2GB on 32-bit systems, 4GB otherwise)
which can be further limited using a command-line flag. This limit is
used whenever actually allocating or growing a wasm memory. This limit
is not directly observable, but we make sure that no wasm memory will
ever be bigger than this limit.

The second limit is the one we should check against when allocating or
growing memory, while the first limit should be used when validating
a module (or the parameters for WebAssembly.Memory). The compiler can
rely on no memory being bigger than the second limit, which again is
never bigger than the first limit.

This CL adds some more documentation to the two limits, and cleans up
all usages.
This also makes {kPlatformMaxPages} and {kMaxMemoryPagesAtRuntime}
obsolete.

R=jkummerow@chromium.org

Bug: chromium:1207263
Change-Id: I43541aafd3f497d1c368bd9400e9bc667bdfd3d9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2910787
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74742}
      2d04a627
  21. 29 Mar, 2021 1 commit
  23. 25 Feb, 2021 1 commit
  25. 26 Nov, 2020 1 commit
  27. 11 Nov, 2020 1 commit
  29. 03 Nov, 2020 1 commit
  31. 02 Nov, 2020 1 commit
  33. 20 Oct, 2020 1 commit
  35. 29 Sep, 2020 1 commit
  37. 24 Sep, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] Remove --wasm-max-mem-pages-growth flag · 5f265c33
      Clemens Backes authored 
      This unifies {max_initial_mem_pages} and {max_maximum_mem_pages} into
{max_mem_pages}.
The {CompilationEnv} constructor was incorrectly using the former
instead of the latter anyway. This did not really matter though, since
they typically have the same value.
Also, there is not a single test that sets --wasm-max-mem-pages-growth.

R=manoskouk@chromium.org
CC=jkummerow@chromium.org

Bug: v8:10949
Change-Id: Ib7ab9b4c239d50b72013087eda5a214829c90369
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2426619Reviewed-by: 's avatarManos Koukoutos <manoskouk@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70114}
      5f265c33
  39. 28 Aug, 2020 1 commit
  41. 14 Aug, 2020 1 commit
    • Leszek Swirski's avatar
      [offthread] Change OffThreadIsolate to LocalIsolate · f1589bbe
      Leszek Swirski authored 
      This patch introduces a new LocalIsolate and LocalFactory, which use
LocalHeap and replace OffThreadIsolate and OffThreadFactory. This allows
us to remove those classes, as well as the related OffThreadSpace,
OffThreadLargeObjectSpace, OffThreadHeap, and OffThreadTransferHandle.
OffThreadLogger becomes LocalLogger.

LocalHeap behaves more like Heap than OffThreadHeap did, so this allows
us to additionally remove the concept of "Finish" and "Publish" that the
OffThreadIsolate had, and allows us to internalize strings directly with
the newly-concurrent string table (where the implementation can now move
to FactoryBase).

This patch also removes the off-thread support from the deserializer
entirely, as well as removing the LocalIsolateWrapper which allowed
run-time distinction between Isolate and OffThreadIsolate. LocalHeap
doesn't support the reservation model used by the deserializer, and we
will likely move the deserializer to use LocalIsolate unconditionally
once we figure out the details of how to do this.

Bug: chromium:1011762

Change-Id: I1a1a0a72952b19a8a4c167c11a863c153a1252fc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2315990
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69397}
      f1589bbe
  43. 24 Jul, 2020 1 commit
    • Leszek Swirski's avatar
      [compiler] Off-thread finalize each function immediately · 198deea2
      Leszek Swirski authored 
      Allow "iterative" finalization when off-thread finalization is enabled,
meaning that each compiled function is finalized immediately after
compilation, rather than all functions being first compiled and then
finalized.

This is what we do on the main thread, and it reduces peak Zone memory
usage by being able to discard empty compilation Zones earlier.

One necessary functionality for this was being able to defer the
finalization of asm.js functions until the main thread pause, since
they can't be finalized off-thread -- previously we would just bail
out of doing the off-thread finalization if any inner function was
asm.js.

Bug: chromium:1011762
Change-Id: I21ff69d62eaa93b5ff908624b7115601e36f70f1
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2282536Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#69032}
      198deea2
  45. 17 Jul, 2020 1 commit
    • Clemens Backes's avatar
      [asm] Fix use-after-free in ZoneVectors · 7887ae6f
      Clemens Backes authored 
      The AsmParser kept pointers into ZoneVectors, which were accessed even
after those vector might have grown. For regular vectors, this would be
a use-after-free; with ZoneVectors it is technically allowed, since the
old memory stays alive. This will change with
https://crrev.com/c/2302895, which zaps zone memory which is
deallocated. Eventually, we might want to reuse large deallocations in
zone memory, hence this "use after free" needs to be fixed.

This CL fixes the issue by explicitly re-allocating in the zone instead
of using ZoneVectors. This makes sure that the old memory stays alive.
This is kind of a quick-fix, but since asm.js is more or less deprecated
anyway (in favor of Wasm), it's OK if this code does not profit from
future ZoneVector memory re-use optimizations.

Drive-by: Move field initializers to the field declaration.

R=ishell@chromium.org

Bug: v8:10717
Change-Id: I56c1feb49d05080e78a6620273b55b4e18156254
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2304581Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68917}
      7887ae6f
  47. 10 Jul, 2020 1 commit
  49. 09 Jul, 2020 1 commit
    • Manos Koukoutos's avatar
      [wasm-gc] Refactoring in preparation of generalizing WasmInitExpr · 01e59c4b
      Manos Koukoutos authored 
      Motivation: With rtt.sub now allowed in constant expressions, we have
to generalize WasmInitExpr to be able to handle expressions with
operands. This CL prepares the ground for this change and adds no
functionality.

Changes:
- ValueType::heap_representation and HeapType::representation now
  return HeapType::Representation.
- Add ValueType::is_rtt().
- WasmInitExpr:
  - Make kind private. Rename val -> operator, make it private. Add
    accessors.
  - Rename kGlobalIndex -> kGlobalGet.
  - Squash global_index and function_index into index.
  - Add heap_type Immediate. Use it for RefNullConst. TypeOf in
    module-decoder.cc can now fully determine the type of a
    WasmInitExpr.
  - Add class constructors/static method constructors for each Operator
    kind.
  - Delete copy constructor. WasmInitExpr will use std::unique_ptr for
    its operands.
- consume_init_expr now uses a stack.
- A few minor improvements.

Bug: v8:7748
Change-Id: I3ba3ee7ac2d6bc58e887790c37110ceb80658985
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2284483
Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#68759}
      01e59c4b
  51. 10 Jun, 2020 1 commit
  53. 06 May, 2020 1 commit
    • Leszek Swirski's avatar
      [offthread] Unify compiler.cc finalization logic · 58b12f63
      Leszek Swirski authored 
      This patch unfies the finalization logic between the various unoptimized
compilation paths in compiler.cc, taking the various post-processings and
fixups needed for off-thread finalization and performing them in the same
order for the other finalizations.

It also unifies the general compilation path between streaming script
compilation, main-thread script compilation, and main-thread lazy
compilation, making the main-thread paths both use an iterative execution
and finalization, and making all three use the same job helper methods
and overall finalization helper.

Bug: chromium:1011762
Change-Id: Ibe56f6d2f75a2deffbe9e0b600ded8a02293b722
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2172790
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67609}
      58b12f63
  55. 24 Apr, 2020 1 commit
  57. 01 Apr, 2020 2 commits
  59. 17 Mar, 2020 1 commit
  61. 03 Mar, 2020 2 commits
    • Leszek Swirski's avatar
      [offthread] Allow off-thread bytecode finalization · 455cb6c0
      Leszek Swirski authored 
      Add the remaining missing templatizations to allow an initial wiring in
of the off-thread factory into streaming compilation finalization.

The off-thread finalization is behind a flag, disabled by default:
    --finalize-streaming-on-background

When the flag is enabled, background tasks will perform perform the
finalization during their background execution, and will release the
parser and compilation jobs once they are no longer needed.

The implementation is complete enough for performance testing, but not
enough for launch. Notably, there is no support for:

  * Class boilerplates (the code is marked unreachable),
  * Exceptions during finalization, i.e. parse/compile warnings/errors,
  * Allocation sampling,
  * Logging,
  * Asm.js,
  * Parallel complication tasks
  * Forced source positions (for "NeedsDetailedOptimizedCodeLineInfo()")

This patch also adds some tracing events for the various stages of the
off-thread finalization (including the main-thread merge) for further
performance improvements.

Bug: chromium:1011762
Change-Id: Ia44fa56975dd689f0d92c1543b294cdb063eb199
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2066965
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66566}
      455cb6c0
    • Clemens Backes's avatar
      [wasm] Remove samples for obsolete histograms · 547e857b
      Clemens Backes authored 
      The histograms were removed from chrome. This CL cleans up the V8 code
to stop reporting samples.

R=ahaas@chromium.org

Bug: chromium:1053285
Change-Id: I7c6ff36ac9bb5d86e81e5f36849903a95a8ed618
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2083478Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66553}
      547e857b
  63. 24 Feb, 2020 1 commit
  65. 24 Jan, 2020 2 commits
  67. 21 Jan, 2020 1 commit
    • Clemens Backes's avatar
      Move decoded asm.js offset table off-heap · 87f09404
      Clemens Backes authored 
      The asm.js offset table exists in two forms: Delta-encoded in a byte
array, as generated during asm translation, and decoded, for faster
lookup.
This CL moves the encoded version from the {AsmWasmData} and
{WasmModuleObject} to the {WasmModule}, and stores it off-heap in a C++
array instead of a {ByteArray}.
Also, it moves the decoded version off-heap by storing it in a C++ data
structure that makes lookup easy, instead of encoding it again in
another {ByteArray}.

This change is a nice refactoring in itself, but it also prepares adding
more information to the offset table. For reconstructing the source code
of an asm.js function, we will need to store the start and end offsets
of the whole function as well (see linked bug).

R=jkummerow@chromium.org

Bug: chromium:667678
Change-Id: I79b789c3122dd8ba803cedc6bfdcc3d4b1fa0fd4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2011108
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#65900}
      87f09404
  69. 20 Jan, 2020 1 commit