Skip to content

V
V8
Switch branch/tag
  1. 25 Sep, 2018 3 commits
    • Yang Guo's avatar
      Reland "[snapshot] add checksum to startup snapshot" · 8ff37bc7
      Yang Guo authored 
      This is a reland of bcb8d49b

TBR=petermarshall@chromium.org

Original change's description:
> [snapshot] add checksum to startup snapshot
>
> We already had checksumming for code cache data. We now extend
> checksumming to the startup snapshot to catch data corruption early.
>
> The performance impact for deserialization is a regression of 1-2%,
> which should be acceptable.
>
> Sample output for the included test with --profile-deserialization:
>
> [Verifying snapshot checksum took 0.023 ms]
> [Deserializing isolate (134348 bytes) took 1.891 ms]
> [Verifying snapshot checksum took 0.024 ms]
> [Deserializing isolate (134348 bytes) took 1.654 ms]
> [Deserializing context #0 (47208 bytes) took 0.331 ms]
> Deserialization will reserve:
>     208168 bytes per isolate
>     123368 bytes per context #0
> Snapshot blob consists of:
>     134492 bytes in 6 chunks for startup
>     115272 bytes for builtins
>      47152 bytes in 31 chunks for context #0
> [Verifying snapshot checksum took 0.048 ms]
> [Verifying snapshot checksum took 0.043 ms]
>
> R=peria@chromium.org, petermarshall@chromium.org
>
> Bug: chromium:881417
> Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
> Change-Id: Ibc57520d459c86be8972f731aa35045b5e3751d7
> Reviewed-on: https://chromium-review.googlesource.com/1241874
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Commit-Queue: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56217}

Bug: chromium:881417
Change-Id: I037f378fc2d45c3e0fa670bf538df68cbba5c53c
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/1243191Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56224}
      8ff37bc7
    • Clemens Hammacher's avatar
      Revert "[snapshot] add checksum to startup snapshot" · 0a04f263
      Clemens Hammacher authored 
      This reverts commit bcb8d49b.

Reason for revert: MSan compile error: https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/23025

Original change's description:
> [snapshot] add checksum to startup snapshot
> 
> We already had checksumming for code cache data. We now extend
> checksumming to the startup snapshot to catch data corruption early.
> 
> The performance impact for deserialization is a regression of 1-2%,
> which should be acceptable.
> 
> Sample output for the included test with --profile-deserialization:
> 
> [Verifying snapshot checksum took 0.023 ms]
> [Deserializing isolate (134348 bytes) took 1.891 ms]
> [Verifying snapshot checksum took 0.024 ms]
> [Deserializing isolate (134348 bytes) took 1.654 ms]
> [Deserializing context #0 (47208 bytes) took 0.331 ms]
> Deserialization will reserve:
>     208168 bytes per isolate
>     123368 bytes per context #0
> Snapshot blob consists of:
>     134492 bytes in 6 chunks for startup
>     115272 bytes for builtins
>      47152 bytes in 31 chunks for context #0
> [Verifying snapshot checksum took 0.048 ms]
> [Verifying snapshot checksum took 0.043 ms]
> 
> R=​peria@chromium.org, petermarshall@chromium.org
> 
> Bug: chromium:881417
> Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
> Change-Id: Ibc57520d459c86be8972f731aa35045b5e3751d7
> Reviewed-on: https://chromium-review.googlesource.com/1241874
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Commit-Queue: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#56217}

TBR=peria@chromium.org,yangguo@chromium.org,petermarshall@chromium.org

Change-Id: Iccb82092858ab68a5d6ae9552fa716108eda354b
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:881417
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/1243190Reviewed-by: 's avatarClemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56221}
      0a04f263
    • Yang Guo's avatar
      [snapshot] add checksum to startup snapshot · bcb8d49b
      Yang Guo authored 
      We already had checksumming for code cache data. We now extend
checksumming to the startup snapshot to catch data corruption early.

The performance impact for deserialization is a regression of 1-2%,
which should be acceptable.

Sample output for the included test with --profile-deserialization:

[Verifying snapshot checksum took 0.023 ms]
[Deserializing isolate (134348 bytes) took 1.891 ms]
[Verifying snapshot checksum took 0.024 ms]
[Deserializing isolate (134348 bytes) took 1.654 ms]
[Deserializing context #0 (47208 bytes) took 0.331 ms]
Deserialization will reserve:
    208168 bytes per isolate
    123368 bytes per context #0
Snapshot blob consists of:
    134492 bytes in 6 chunks for startup
    115272 bytes for builtins
     47152 bytes in 31 chunks for context #0
[Verifying snapshot checksum took 0.048 ms]
[Verifying snapshot checksum took 0.043 ms]

R=peria@chromium.org, petermarshall@chromium.org

Bug: chromium:881417
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: Ibc57520d459c86be8972f731aa35045b5e3751d7
Reviewed-on: https://chromium-review.googlesource.com/1241874Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#56217}
      bcb8d49b
  3. 22 Aug, 2018 1 commit
  5. 04 Jul, 2018 1 commit
  7. 30 May, 2018 1 commit
    • jgruber's avatar
      [api] Add option to consume code cache on module compilation · 70b5fd3b
      jgruber authored 
      This extends the ScriptCompiler::CompileModule function with a
CompileOptions argument. Accepted values are kNoCompileOptions (in
which case, behavior remains unmodified) and kConsumeCodeCache. If the
latter is passed, we try to fetch the given module from the code
cache.

Since it is possible to compile the same source code as both a script
and a module (and different code is generated for the two cases), a
new is_module bit is added to the SerializedCodeData header to
disambiguate between the two cases.

Bug: v8:7685
Cq-Include-Trybots: luci.chromium.try:linux_chromium_rel_ng
Change-Id: I34b3642505577ed9ed0caedbee5876308c5a53ea
Reviewed-on: https://chromium-review.googlesource.com/1073327
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#53432}
      70b5fd3b
  9. 16 Apr, 2018 1 commit
  11. 09 Apr, 2018 1 commit
  13. 06 Apr, 2018 1 commit
  15. 29 Mar, 2018 1 commit
  17. 13 Mar, 2018 1 commit
  19. 05 Mar, 2018 2 commits
  21. 21 Feb, 2018 1 commit
  23. 01 Dec, 2017 1 commit
  25. 26 Sep, 2017 3 commits
    • Yang Guo's avatar
      Reland "[snapshot] include version string in the startup snapshot." · dc7b2b2b
      Yang Guo authored 
      This is a reland of 629406d1
Original change's description:
> [snapshot] include version string in the startup snapshot.
> 
> This is to easier diagnose build issues involving the snapshot.
> Sample error message for mismatching snapshot:
> 
> #
> # Fatal error in ../../src/snapshot/snapshot-common.cc, line 286
> # Version mismatch between V8 binary and snapshot.
> #   V8 binary version: 6.3.1 (candidate)
> #    Snapshot version: 6.3.0 (candidate)
> # The snapshot consists of 2820444 bytes and contains 1 contexts.
> #
> 
> 
> R=machenbach@chromium.org
> 
> Bug: chromium:764327
> Change-Id: Icdc7aeac77819b113985b424feda814a072d5406
> Reviewed-on: https://chromium-review.googlesource.com/684295
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Commit-Queue: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48161}

Bug: chromium:764327
Change-Id: I3721689824e0a6909eede86d0829dc258ae40c4d
Reviewed-on: https://chromium-review.googlesource.com/684494Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48164}
      dc7b2b2b
    • Yang Guo's avatar
      Revert "[snapshot] include version string in the startup snapshot." · dc64a731
      Yang Guo authored 
      This reverts commit 629406d1.

Reason for revert: cross platform builds break.

Original change's description:
> [snapshot] include version string in the startup snapshot.
> 
> This is to easier diagnose build issues involving the snapshot.
> Sample error message for mismatching snapshot:
> 
> #
> # Fatal error in ../../src/snapshot/snapshot-common.cc, line 286
> # Version mismatch between V8 binary and snapshot.
> #   V8 binary version: 6.3.1 (candidate)
> #    Snapshot version: 6.3.0 (candidate)
> # The snapshot consists of 2820444 bytes and contains 1 contexts.
> #
> 
> 
> R=​machenbach@chromium.org
> 
> Bug: chromium:764327
> Change-Id: Icdc7aeac77819b113985b424feda814a072d5406
> Reviewed-on: https://chromium-review.googlesource.com/684295
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Commit-Queue: Yang Guo <yangguo@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48161}

TBR=machenbach@chromium.org,yangguo@chromium.org

Change-Id: I35a9b575e4f7fe5c45c9dc6f9e774c3e6d30049c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:764327
Reviewed-on: https://chromium-review.googlesource.com/684315Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48162}
      dc64a731
    • Yang Guo's avatar
      [snapshot] include version string in the startup snapshot. · 629406d1
      Yang Guo authored 
      This is to easier diagnose build issues involving the snapshot.
Sample error message for mismatching snapshot:

#
# Fatal error in ../../src/snapshot/snapshot-common.cc, line 286
# Version mismatch between V8 binary and snapshot.
#   V8 binary version: 6.3.1 (candidate)
#    Snapshot version: 6.3.0 (candidate)
# The snapshot consists of 2820444 bytes and contains 1 contexts.
#


R=machenbach@chromium.org

Bug: chromium:764327
Change-Id: Icdc7aeac77819b113985b424feda814a072d5406
Reviewed-on: https://chromium-review.googlesource.com/684295Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48161}
      629406d1
  27. 19 Sep, 2017 1 commit
  29. 30 Aug, 2017 1 commit
    • jgruber's avatar
      Reland "[snapshot] Move builtins to dedicated snapshot area" · 70a51638
      jgruber authored 
      This is a reland of 49e3bfd5
Original change's description:
> [snapshot] Move builtins to dedicated snapshot area
> 
> As a first step towards lazy builtin deserialization, this CL moves
> builtins to their own dedicated area in the snapshot blob, physically
> located after startup data and before context-specific data.
> 
> The startup- and partial serializers now serialize all seen builtins as
> references, i.e. they only encode the relevant builtin id (taking care
> to preserve special behavior around the interpreter trampoline and
> CompileLazy). Builtins are later fully serialized by the
> BuiltinSerializer. The separate blobs are finally glued together by
> CreateSnapshotBlob.
> 
> Deserialization takes the same steps: when we see builtin reference
> bytecodes before builtins have been deserialized, we push to a list of
> deferred builtin references. After builtin deserialization, this list is
> iterated and all builtin references are fixed up.
> 
> Bug: v8:6624
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: Idee42fa9c92bdbe8d5b8c4b8bf3ca9dd39634004
> Reviewed-on: https://chromium-review.googlesource.com/610225
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47596}

Bug: v8:6624
Change-Id: I8bfac56c482d992987c270bf0fea7acd9e4ca0c7
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/638271Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47705}
      70a51638
  31. 28 Aug, 2017 1 commit
    • Michael Hablich's avatar
      Revert "[snapshot] Move builtins to dedicated snapshot area" · a588411e
      Michael Hablich authored 
      This reverts commit 49e3bfd5.

Reason for revert: Primary suspect for blocked roll: 759552

Original change's description:
> [snapshot] Move builtins to dedicated snapshot area
> 
> As a first step towards lazy builtin deserialization, this CL moves
> builtins to their own dedicated area in the snapshot blob, physically
> located after startup data and before context-specific data.
> 
> The startup- and partial serializers now serialize all seen builtins as
> references, i.e. they only encode the relevant builtin id (taking care
> to preserve special behavior around the interpreter trampoline and
> CompileLazy). Builtins are later fully serialized by the
> BuiltinSerializer. The separate blobs are finally glued together by
> CreateSnapshotBlob.
> 
> Deserialization takes the same steps: when we see builtin reference
> bytecodes before builtins have been deserialized, we push to a list of
> deferred builtin references. After builtin deserialization, this list is
> iterated and all builtin references are fixed up.
> 
> Bug: v8:6624
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: Idee42fa9c92bdbe8d5b8c4b8bf3ca9dd39634004
> Reviewed-on: https://chromium-review.googlesource.com/610225
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47596}

TBR=yangguo@chromium.org,mlippautz@chromium.org,jgruber@chromium.org

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

Bug: v8:6624
Change-Id: I9906c9ea15a623226b890f63bc65876a6f5203f8
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/638331Reviewed-by: 's avatarMichael Hablich <hablich@chromium.org>
Commit-Queue: Michael Hablich <hablich@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47648}
      a588411e
  33. 25 Aug, 2017 1 commit
    • Jakob Gruber's avatar
      [snapshot] Move builtins to dedicated snapshot area · 49e3bfd5
      Jakob Gruber authored 
      As a first step towards lazy builtin deserialization, this CL moves
builtins to their own dedicated area in the snapshot blob, physically
located after startup data and before context-specific data.

The startup- and partial serializers now serialize all seen builtins as
references, i.e. they only encode the relevant builtin id (taking care
to preserve special behavior around the interpreter trampoline and
CompileLazy). Builtins are later fully serialized by the
BuiltinSerializer. The separate blobs are finally glued together by
CreateSnapshotBlob.

Deserialization takes the same steps: when we see builtin reference
bytecodes before builtins have been deserialized, we push to a list of
deferred builtin references. After builtin deserialization, this list is
iterated and all builtin references are fixed up.

Bug: v8:6624
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Idee42fa9c92bdbe8d5b8c4b8bf3ca9dd39634004
Reviewed-on: https://chromium-review.googlesource.com/610225Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47596}
      49e3bfd5
  35. 24 Aug, 2017 1 commit
  37. 23 Aug, 2017 1 commit
  39. 30 Mar, 2017 1 commit
  41. 27 Mar, 2017 1 commit
    • Clemens Hammacher's avatar
      [serializer] Fix wasm code serialization · bd8447af
      Clemens Hammacher authored 
      The SerializeGeneric method assumes that the object was not serialized
before. Hence, we should not call it repeatedly for the same builtin.
This CL now exposes SerializeBuiltin, and calls that directly.
We also serialize the Illegal builtin for wasm interpreter entries,
which are never reused across instantiations anyway.

R=ahaas@chromium.org, yangguo@chromium.org
BUG=v8:5822

Change-Id: Id74b86fe29171908ed35ddbc06c93f0d241e4917
Reviewed-on: https://chromium-review.googlesource.com/458380Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#44155}
      bd8447af
  43. 07 Mar, 2017 1 commit
  45. 18 Jan, 2017 1 commit
    • clemensh's avatar
      [wasm] Skip serialization of breakpoints and certion stubs · 3c897883
      clemensh authored 
      Breakpoints are always re-set by the embedder after compilation, so we
don't want to store the corresponding breakpoint objects.
Also don't serialize WASM_INTERPRETER_ENTRY stubs as they are replaced
by ordinary WASM_FUNCTION code at instantiation anyway, and skip
WASM_TO_JS wrappers which are recompiled on each instantiation.
Instead, we serialize the Illegal builtin, and also use that one
instead of the placeholder when compiling the wasm code initially.

R=titzer@chromium.org, yangguo@chromium.org
BUG=v8:5822

Review-Url: https://codereview.chromium.org/2629853004
Cr-Commit-Position: refs/heads/master@{#42451}
      3c897883
  47. 22 Oct, 2016 1 commit
  49. 19 Oct, 2016 1 commit
    • titzer's avatar
      [wasm] Use a Managed<WasmModule> to hold metadata about modules. · 418b239f
      titzer authored 
      This CL refactors the handling of metadata associated with WebAssembly
modules to reduce the duplicate marshalling of data from the C++ world
to the JavaScript world. It does this by wrapping the C++ WasmModule*
object in a Foreign that is rooted from the on-heap WasmCompiledModule
(which is itself just a FixedArray). Upon serialization, the C++ object
is ignored and the original WASM wire bytes are serialized. Upon
deserialization, the C++ object is reconstituted by reparsing the bytes.

This is motivated by increasing complications in implementing the JS
API, in particular WebAssembly.Table, which must perform signature
canonicalization across instances.

Additionally, this CL implements the proper base + offset initialization
behavior for tables.

R=rossberg@chromium.org,bradnelson@chromium.org,mtrofin@chromium.org,yangguo@chromium.org
BUG=v8:5507, chromium:575167, chromium:657316

Review-Url: https://chromiumcodereview.appspot.com/2424623002
Cr-Commit-Position: refs/heads/master@{#40434}
      418b239f
  51. 14 Oct, 2016 1 commit
  53. 06 Oct, 2016 1 commit
    • mtrofin's avatar
      [wasm] Support recompilation if deserialization fails. · 917ef616
      mtrofin authored 
      One step closer to the informally-agreed upon specification
that structured cloning will always succeed, meaning, if
we fail to deserialize (e.g. because version mismatch in
serialized format and v8 version), we recompile.

As part of this work, the deserializer will need to become
more resilient to invalid input data, and fail graciously
rather than CHECK-ing. This CL addresses some of that,
sufficient to unblock the current serialization tests.
Subsequent CLs will add more testing and the appropriate
fixes.

BUG=639090

Review-Url: https://codereview.chromium.org/2395793003
Cr-Commit-Position: refs/heads/master@{#40058}
      917ef616
  55. 12 Sep, 2016 1 commit
    • mtrofin's avatar
      [wasm] reuse the first compiled module. · b4dc310a
      mtrofin authored 
      This change avoids needing to keep around an unused compiled
module. Instead, the result of compiling the wasm bytes is
given to the first instance. The module object and that instance object
point to the same compiled module. Instances are, then, cloned from
the compiled module the module object points to. When an instance is
collected, we make sure that the module object still has a clone
available, and, if the last instance is GC-ed, we also reset the compiled
module so that it does not reference its heap, so that it (==heap) may
be collected.

This is achieved by linking the clones in a double-linked list and
registering a finalizer for each. When we create an instance, we tie it
in the front of the list, making the module object point to it (O(1)). When
the finalizer is called, we relink the list over the dying object (O(1)). The
costliest operation is finalizing the last instance, since we need to visit
all wasm functions and reset heap references.

BUG=v8:5316

Committed: https://crrev.com/01f5af515728aebe6c5246f4f7dd6c573e8748af
Review-Url: https://codereview.chromium.org/2305903002
Cr-Original-Commit-Position: refs/heads/master@{#39153}
Cr-Commit-Position: refs/heads/master@{#39361}
      b4dc310a
  57. 05 Sep, 2016 2 commits
    • machenbach's avatar
      Revert of [wasm] reuse the first compiled module (patchset #12 id:220001 of... · 359a00bf
      machenbach authored 
      Revert of [wasm] reuse the first compiled module (patchset #12 id:220001 of https://codereview.chromium.org/2305903002/ )

Reason for revert:
mac gc stress failures:
https://build.chromium.org/p/client.v8/builders/V8%20Mac%20GC%20Stress/builds/8341

Original issue's description:
> [wasm] reuse the first compiled module.
>
> This change avoids needing to keep around an unused compiled
> module. Instead, the result of compiling the wasm bytes is
> given to the first instance. The module object and that instance object
> point to the same compiled module. Instances are, then, cloned from
> the compiled module the module object points to. When an instance is
> collected, we make sure that the module object still has a clone
> available, and, if the last instance is GC-ed, we also reset the compiled
> module so that it does not reference its heap, so that it (==heap) may
> be collected.
>
> This is achieved by linking the clones in a double-linked list and
> registering a finalizer for each. When we create an instance, we tie it
> in the front of the list, making the module object point to it (O(1)). When
> the finalizer is called, we relink the list over the dying object (O(1)). The
> costliest operation is finalizing the last instance, since we need to visit
> all wasm functions and reset heap references.
>
> BUG=v8:5316
>
> Committed: https://crrev.com/01f5af515728aebe6c5246f4f7dd6c573e8748af
> Cr-Commit-Position: refs/heads/master@{#39153}

TBR=bradnelson@chromium.org,verwaest@chromium.org,vogelheim@chromium.org,yangguo@chromium.org,mtrofin@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=v8:5316

Review-Url: https://codereview.chromium.org/2306403002
Cr-Commit-Position: refs/heads/master@{#39154}
      359a00bf
    • mtrofin's avatar
      [wasm] reuse the first compiled module. · 01f5af51
      mtrofin authored 
      This change avoids needing to keep around an unused compiled
module. Instead, the result of compiling the wasm bytes is
given to the first instance. The module object and that instance object
point to the same compiled module. Instances are, then, cloned from
the compiled module the module object points to. When an instance is
collected, we make sure that the module object still has a clone
available, and, if the last instance is GC-ed, we also reset the compiled
module so that it does not reference its heap, so that it (==heap) may
be collected.

This is achieved by linking the clones in a double-linked list and
registering a finalizer for each. When we create an instance, we tie it
in the front of the list, making the module object point to it (O(1)). When
the finalizer is called, we relink the list over the dying object (O(1)). The
costliest operation is finalizing the last instance, since we need to visit
all wasm functions and reset heap references.

BUG=v8:5316

Review-Url: https://codereview.chromium.org/2305903002
Cr-Commit-Position: refs/heads/master@{#39153}
      01f5af51
  59. 12 Aug, 2016 1 commit
  61. 09 Aug, 2016 1 commit
  63. 10 Jun, 2016 2 commits
  65. 18 May, 2016 1 commit
    • yangguo's avatar
      [serializer] prepare attached references for general use. · 735fa0c4
      yangguo authored 
      Currently attached references are only used for global proxy, source
string and code stubs. Mid-term future we want to use attached
references for arbitrary objects (in fixed order) provided from outside.

This change renames BackReference to SerializerReference to include both
back references and attached references.

R=mtrofin@chromium.org, vogelheim@chromium.org

Review-Url: https://codereview.chromium.org/1992723002
Cr-Commit-Position: refs/heads/master@{#36318}
      735fa0c4