1. 26 Feb, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] Reduce size of {WasmCode} objects · c626bc5e
      Clemens Backes authored
      This is a first step to make {WasmCode} objects smaller. Many code
      offsets are currently stored in {size_t} even though there were
      originally (during assembly) an int. Others are stored in {uint32_t}.
      
      This CL switches the function index and all code lengths and offsets to
      int, because
      a) bigger code is not supported anyway, and
      b) the style guide recommends int over unsigned types.
      
      This makes the {WasmCode} 24 bytes smaller on x64 (from 144 to 120
      bytes).
      
      R=ahaas@chromium.org
      
      Bug: v8:10254
      Change-Id: I8f78bf4be64d59cf9393e3b6662d9d3bd153d387
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2074217Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66462}
      c626bc5e
  2. 21 Feb, 2020 1 commit
  3. 20 Feb, 2020 1 commit
    • Clemens Backes's avatar
      [wasm] Avoid unnecessary jump tables · 1403fd7d
      Clemens Backes authored
      If multiple code spaces are created, each of them currently gets its own
      jump table (on 64 bit platforms). Since we try to allocate new code
      spaces right after existing ones, this is often not necessary. We could
      instead reuse the existing jump table(s).
      This saves code space for the unneeded jump tables and avoid the cost of
      patching the redundant jump tables when we replace code objects.
      
      This CL implements this by checking whether an existing jump table (or
      pair of far jump table and (near) jump table) fully covers a new code
      space, and reuses the existing jump table in that case.
      
      R=ahaas@chromium.org
      
      Change-Id: Id8751b9c4036cf8f85f9baa2b0be8b2cfb5716ff
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2043846Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66364}
      1403fd7d
  4. 03 Feb, 2020 1 commit
    • Thibaud Michaud's avatar
      Reland "Reland "[wasm] Cache streaming compilation result"" · ab6c4669
      Thibaud Michaud authored
      This is a reland of 9781aa07
      
      Original change's description:
      > Reland "[wasm] Cache streaming compilation result"
      >
      > This is a reland of 015f379a
      >
      > Original change's description:
      > > [wasm] Cache streaming compilation result
      > >
      > > Before compiling the code section, check whether the
      > > bytes received so far match a cached module. If they do, delay
      > > compilation until we receive the full bytes, since we are likely to find
      > > a cache entry for them.
      > >
      > > R=clemensb@chromium.org
      > >
      > > Bug: v8:6847
      > > Change-Id: Ie5170d1274da3da6d52ff1b408abc7cb441bbe3c
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2002823
      > > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
      > > Reviewed-by: Clemens Backes <clemensb@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#66000}
      >
      > Bug: v8:6847
      > Change-Id: I0b5acffa01aeb7dade3dc966392814383d900015
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2022951
      > Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
      > Reviewed-by: Clemens Backes <clemensb@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66047}
      
      Bug: v8:6847
      Change-Id: I272f56eee28010f34cc99df475164581c8b63036
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
      Cq-Include-Trybots: luci.v8.try:v8_linux64_msan_rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030741
      Commit-Queue: Thibaud Michaud <thibaudm@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66081}
      ab6c4669
  5. 30 Jan, 2020 2 commits
  6. 27 Jan, 2020 2 commits
  7. 21 Jan, 2020 1 commit
  8. 17 Jan, 2020 1 commit
  9. 18 Dec, 2019 1 commit
  10. 10 Dec, 2019 1 commit
  11. 02 Dec, 2019 2 commits
  12. 26 Nov, 2019 1 commit
  13. 12 Nov, 2019 1 commit
    • Clemens Backes's avatar
      [wasm] Improve code size estimates · aadf812c
      Clemens Backes authored
      UMA data shows that we currently still allocate up to ten code spaces
      per module. This is because the code size estimates are vastly off,
      especially if both Liftoff and TurboFan is being used.
      Also, code sizes differ by platform.
      
      This CL adds more logic to the {EstimateNativeModuleCodeSize} function
      to distinguish Liftoff and TurboFan, and to use different constants per
      platform. A largeish comment explains how the numbers were generated,
      and that they are an extreme over-generalization. However, without
      further information about the module, this is the best we can do.
      After all, being off even by a factor of two does not hurt too much, as
      explained in the comment.
      
      R=jkummerow@chromium.org
      
      Change-Id: Icd178f5f4d0c7c8fa29b11b6eff7d14e64a1af1c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1910102
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64913}
      aadf812c
  14. 07 Nov, 2019 1 commit
    • Clemens Backes's avatar
      [wasm] Remove one {NewNativeModule} method · dde3166b
      Clemens Backes authored
      This makes the {code_size_estimate} computation explicit in the caller,
      and removes one of the two {NewNativeModule} constructors. It turns out
      that the calculation is totally off in the streaming calculation phase,
      since no function bodies have been parsed yet. So all
      {WasmFunction::code} fields are still empty, and we compute an estimate
      that is way too low.
      This CL prepares the actual fix for that (by computing a better estimate
      at specific call sites).
      
      R=ahaas@chromium.org
      
      Bug: v8:9950
      Change-Id: I68a891c97e5f65a9c7e73e21684bdfa7e261e216
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1901273
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64845}
      dde3166b
  15. 31 Oct, 2019 1 commit
  16. 07 Oct, 2019 1 commit
    • Clemens Backes's avatar
      [wasm] Fix regression caused by multiple code spaces · 44c3b7b5
      Clemens Backes authored
      The {GetNearRuntimeStubEntry} and {GetNearCallTargetForFunction}
      functions need to find the code space that contains the current
      function. This lookup requires a lock and is non-trivial. The repeated
      lookup caused severe regressions.
      
      This CL introduces a {JumpTablesRef} struct which holds information
      about the jump tables to use. It can be looked up once and then used
      for a whole function or even several functions within the same code
      space (in {NativeModule::AddCompiledCode} which adds a whole vector of
      compilation results).
      
      This fixes the regressions.
      
      R=ahaas@chromium.org
      
      Bug: chromium:1004262, v8:9477
      Change-Id: I50bd8327a131e3bee79d86b6d7e867a506959312
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1840153
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#64129}
      44c3b7b5
  17. 26 Sep, 2019 1 commit
  18. 13 Sep, 2019 1 commit
  19. 12 Sep, 2019 1 commit
  20. 30 Jul, 2019 1 commit
    • Thibaud Michaud's avatar
      Reland "[wasm] Simplify module creation" · fc1e98ac
      Thibaud Michaud authored
      Original CL:
      > [wasm] Simplify module creation
      >
      > This includes WasmEngine::NewNativeModule() and
      WasmModuleObject::New().
      > The intent is to make the various ways of creating a module (sync,
      > async, deserialize, import) more similar.
      >
      > After this change, a NativeModule will always be created before a
      > WasmModuleObject. This will make it easier to look up a cached
      > NativeModule given its wire bytes.
      >
      > The following changes are made:
      >
      > * Use WasmCodeManager::EstimateNativeModuleCodeSize() to find the code
      >   size estimate by default. A different code size estimate is only
      used in
      >   tests.
      > * Change CompileJsToWasmWrappers() to allocate a new FixedArray
      instead of
      >   assuming the array was created with the correct size. This
      simplifies
      >   WasmModuleObject::New(), and matches what CompileToNativeModule()
      >   does.
      > * Remove the WasmModuleObject::New() constructor that creates a
      >   NativeModule. This case was only used in DeserializeNativeModule()
      and
      >   in test code.
      >
      > Change-Id: I6bdfc425057f92de11abbbf702d052d40aa8267d
      > Reviewed-on:
      https://chromium-review.googlesource.com/c/v8/v8/+/1717497
      > Commit-Queue: Ben Smith <binji@chromium.org>
      > Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#62925}
      
      R=ahaas@chromium.org, clemensh@chromium.org
      CC=binji@chromium.org
      
      Change-Id: I03aa901a1df65af28f864d9aabe2b134ea132e99
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1724213
      Commit-Queue: Ben Smith <binji@chromium.org>
      Reviewed-by: 's avatarBen Smith <binji@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62996}
      fc1e98ac
  21. 25 Jul, 2019 2 commits
    • Zhi An Ng's avatar
      Revert "[wasm] Simplify module creation" · bf7284b9
      Zhi An Ng authored
      This reverts commit 425fa3ae.
      
      Reason for revert: test failure https://bugs.chromium.org/p/v8/issues/detail?id=9554 reverting the root cause has merge conflicts due to changes in same file
      
      Original change's description:
      > [wasm] Simplify module creation
      > 
      > This includes WasmEngine::NewNativeModule() and WasmModuleObject::New().
      > The intent is to make the various ways of creating a module (sync,
      > async, deserialize, import) more similar.
      > 
      > After this change, a NativeModule will always be created before a
      > WasmModuleObject. This will make it easier to look up a cached
      > NativeModule given its wire bytes.
      > 
      > The following changes are made:
      > 
      > * Use WasmCodeManager::EstimateNativeModuleCodeSize() to find the code
      >   size estimate by default. A different code size estimate is only used in
      >   tests.
      > * Change CompileJsToWasmWrappers() to allocate a new FixedArray instead of
      >   assuming the array was created with the correct size. This simplifies
      >   WasmModuleObject::New(), and matches what CompileToNativeModule()
      >   does.
      > * Remove the WasmModuleObject::New() constructor that creates a
      >   NativeModule. This case was only used in DeserializeNativeModule() and
      >   in test code.
      > 
      > Change-Id: I6bdfc425057f92de11abbbf702d052d40aa8267d
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1717497
      > Commit-Queue: Ben Smith <binji@chromium.org>
      > Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#62925}
      
      TBR=binji@chromium.org,ahaas@chromium.org,clemensh@chromium.org
      
      Change-Id: I8dcad7ddcd4601f657b6263bf22009907284fce3
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1719230Reviewed-by: 's avatarZhi An Ng <zhin@chromium.org>
      Commit-Queue: Zhi An Ng <zhin@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62926}
      bf7284b9
    • Ben Smith's avatar
      [wasm] Simplify module creation · 425fa3ae
      Ben Smith authored
      This includes WasmEngine::NewNativeModule() and WasmModuleObject::New().
      The intent is to make the various ways of creating a module (sync,
      async, deserialize, import) more similar.
      
      After this change, a NativeModule will always be created before a
      WasmModuleObject. This will make it easier to look up a cached
      NativeModule given its wire bytes.
      
      The following changes are made:
      
      * Use WasmCodeManager::EstimateNativeModuleCodeSize() to find the code
        size estimate by default. A different code size estimate is only used in
        tests.
      * Change CompileJsToWasmWrappers() to allocate a new FixedArray instead of
        assuming the array was created with the correct size. This simplifies
        WasmModuleObject::New(), and matches what CompileToNativeModule()
        does.
      * Remove the WasmModuleObject::New() constructor that creates a
        NativeModule. This case was only used in DeserializeNativeModule() and
        in test code.
      
      Change-Id: I6bdfc425057f92de11abbbf702d052d40aa8267d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1717497
      Commit-Queue: Ben Smith <binji@chromium.org>
      Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62925}
      425fa3ae
  22. 19 Jun, 2019 1 commit
    • Ben Smith's avatar
      [wasm] Call OnAfterCompile when cloning Module · b7a7e2fb
      Ben Smith authored
      The debugger should be notified whenever a new Module is created so it
      displayed properly. Without this change, the Module is only displayed once,
      regardless of the number of times it is referenced (by other Workers, say).
      That is potentially reasonable behavior, but it doesn't match the way
      JavaScript does it.
      
      With this change, the debugger will display the sources like this:
      
      ```
      ▼ top
        :arrow_forward: localhost
        ▼ wasm
          ▼ wasm-82570336
              wasm-82570336-0
      
      ▼ worker.js
        :arrow_forward: localhost
        ▼ wasm
          :arrow_forward: wasm-82570336
      ```
      
      Change-Id: I61177e8a07e36ea8e2234aa25e75b1489c9da95f
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1666616Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
      Commit-Queue: Ben Smith <binji@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62297}
      b7a7e2fb
  23. 24 May, 2019 1 commit
  24. 23 May, 2019 2 commits
  25. 21 May, 2019 1 commit
  26. 30 Apr, 2019 2 commits
  27. 29 Apr, 2019 3 commits
    • Ross McIlroy's avatar
      Revert "[ptr-compr] New RelocInfo for compressed pointers." · 7e677b2e
      Ross McIlroy authored
      This reverts commit b5da9fcb.
      
      Reason for revert: Breaks pointer compression bot:
      https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20-%20pointer%20compression/3098
      
      Original change's description:
      > [ptr-compr] New RelocInfo for compressed pointers.
      > 
      > New enum RelocInfo::COMPRESSED_EMBEDDED_OBJECT created to support
      > compressed pointers in generated code. Enum name EMBEDDED_OBJECT
      > changed to FULL_EMBEDDED_OBJECT.
      > 
      > RelocInfo::[set_]target_object() abstract away the difference between
      > FULL_EMBEDDED_OBJECT and COMPRESSED_EMBEDDED_OBJECT.
      > 
      > Compressed embedded objects can only be created at this time on
      > x64 with pointer compression turned on. Arm64 constant pools don't
      > support compressed objects at this time.
      > 
      > Bug: v8:7703
      > Change-Id: I03bfd84effa33c65cf9bcefa5df680ab7eace9dd
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1547661
      > Commit-Queue: Michael Stanton <mvstanton@chromium.org>
      > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
      > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
      > Reviewed-by: Igor Sheludko <ishell@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#61076}
      
      TBR=ulan@chromium.org,mvstanton@chromium.org,mstarzinger@chromium.org,jgruber@chromium.org,ishell@chromium.org
      
      Change-Id: I262b2b98315fa987c5a66b1050dc726563ccdb2d
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7703
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1588135Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61087}
      7e677b2e
    • Clemens Hammacher's avatar
      [cleanup] Use Vector::begin instead of Vector::start · 4b0f9c85
      Clemens Hammacher authored
      Our {Vector} template provides both {start} and {begin} methods. They
      return exactly the same value. Since the {begin} method is needed for
      iteration, and is also what standard containers provide, this CL
      switches all uses of the {start} method to use {begin} instead.
      
      Patchset 1 was auto-generated by using this clang AST matcher:
          callExpr(
              callee(
                cxxMethodDecl(
                  hasName("start"),
                  ofClass(hasName("v8::internal::Vector")))
              ),
              argumentCountIs(0))
      
      Patchset 2 was created by running clang-format. Patchset 3 then
      removes the now unused {Vector::start} method.
      
      R=jkummerow@chromium.org
      TBR=mstarzinger@chromium.org,yangguo@chromium.org,verwaest@chromium.org
      
      Bug: v8:9183
      Change-Id: Id9f01c92870872556e2bb3f6d5667463b0e3e5c6
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1587381Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61081}
      4b0f9c85
    • Mike Stanton's avatar
      [ptr-compr] New RelocInfo for compressed pointers. · b5da9fcb
      Mike Stanton authored
      New enum RelocInfo::COMPRESSED_EMBEDDED_OBJECT created to support
      compressed pointers in generated code. Enum name EMBEDDED_OBJECT
      changed to FULL_EMBEDDED_OBJECT.
      
      RelocInfo::[set_]target_object() abstract away the difference between
      FULL_EMBEDDED_OBJECT and COMPRESSED_EMBEDDED_OBJECT.
      
      Compressed embedded objects can only be created at this time on
      x64 with pointer compression turned on. Arm64 constant pools don't
      support compressed objects at this time.
      
      Bug: v8:7703
      Change-Id: I03bfd84effa33c65cf9bcefa5df680ab7eace9dd
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1547661
      Commit-Queue: Michael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarMichael Starzinger <mstarzinger@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#61076}
      b5da9fcb
  28. 03 Apr, 2019 2 commits
  29. 02 Apr, 2019 2 commits
  30. 01 Apr, 2019 1 commit