Skip to content

V
V8
Switch branch/tag
  1. 27 May, 2020 1 commit
  3. 11 May, 2020 1 commit
  5. 08 May, 2020 1 commit
  7. 06 May, 2020 1 commit
  9. 04 May, 2020 1 commit
  11. 23 Apr, 2020 1 commit
  13. 22 Apr, 2020 1 commit
    • Dan Elphick's avatar
      [snapshot] Rename partial snapshot to context snapshot · 71bd50e1
      Dan Elphick authored 
      The partial snapshot/serializer/deserializer are renamed to context *,
while the partial snapshot cache is renamed to startup object cache in
line with the read-only object cache (as this better reflects where it
lives and what it does).

To avoid a gap in the file history due to renaming both the files and
identifiers simulataneously, this leaves all the partial-*.* files in
place. They will be renamed in a follow-up CL.

Bug: v8:10416
Change-Id: I5ef41cad751aaa24b35ee2b3c72bd0295832f2c6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2144115
Commit-Queue: Dan Elphick <delphick@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Auto-Submit: Dan Elphick <delphick@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67306}
      71bd50e1
  15. 06 Feb, 2020 1 commit
    • Steve Blackburn's avatar
      Serialization without heap assumptions. · 1d2c043a
      Steve Blackburn authored 
      Currently back references to regular objects are encoded in terms of
a relative address, index by chunk index and chunk offset.   This
approach has the advantage of avoiding the need for a table of
back-references at deserialization time, but makes strong assumptions
about the way objects are organized in memory (for example, this will
not work if the allocator uses a free list rather than a bump pointer).

I did some quick measurements and found that the absolute number of
objects and back-references is low, suggesting that simply indexing
objects would work with little (or no) observable impact on peak
memory use during deserialization.   Indexing only back referenced
objects is not implemented in this simple CL, but could fairly easily
be added.

Given that the existing mechanism will remain in place, I have
implemented the object index by simply making chunk size one, so
every object lives on its own chunk (with offset zero).   This is
the moral equivalent to indexing each object but is a more minimal
change.  Directly encoding an object index will be more efficient,
the trade off made here is just to keep the change absolutely minimal.

If using an object index becomes the default, this can be optimized
first by only using an index for each object that is actually back-
referenced (about half of all objects in my measurements), and more
aggressively, a technique like register allocation could be used at
serialization time to limit the number of indices to the maximum
number of outstanding back-references at any time (basically a live-
range analysis of back-references).

Bug: v8:9533
Change-Id: I1b7ae87e954f67f6405c2bbdf3b4a4f385af8579
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030742
Commit-Queue: Steve Blackburn <steveblackburn@google.com>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66154}
      1d2c043a
  17. 04 Feb, 2020 1 commit
  19. 19 Dec, 2019 2 commits
  21. 17 Dec, 2019 1 commit
  23. 13 Dec, 2019 2 commits
  25. 08 Jul, 2019 1 commit
  27. 17 May, 2019 1 commit
  29. 16 May, 2019 2 commits
  31. 15 Feb, 2019 1 commit
  33. 26 Dec, 2018 1 commit
  35. 07 Dec, 2018 1 commit
  37. 27 Nov, 2018 1 commit
  39. 26 Nov, 2018 1 commit
    • Marja Hölttä's avatar
      [iwyu] Include heap-inl.h less. · 0453d418
      Marja Hölttä authored 
      - Remove heap-inl.h includes from places where it looked unnecessary. (This is a
  non-scientific approach, because it's probably pulled in indirectly anyway.)

- Annotate places which include heap-inl.h because they need heap/ internals.

- ACCESSORS legitimately needs heap-inl.h because of Heap::FromWritableHeapObject.

- Add includes to heap/heap-write-barrier(-inl).h

- A bunch of IWYU fixes discovered when working on this CL (includes which were
  missing because heap-inl.h pulls them in indirectly).

BUG=v8:7490,v8:8238,v8:8499

Change-Id: I00f9a74d430f13d7c080dca77a92b03bcca7ef96
Reviewed-on: https://chromium-review.googlesource.com/c/1349241Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57814}
      0453d418
  41. 24 Oct, 2018 1 commit
  43. 23 Jul, 2018 1 commit
  45. 07 May, 2018 1 commit
  47. 22 Mar, 2018 1 commit
  49. 14 Feb, 2018 1 commit
  51. 07 Nov, 2017 1 commit
  53. 06 Nov, 2017 2 commits
  55. 17 Oct, 2017 1 commit
  57. 16 Oct, 2017 1 commit
  59. 11 Sep, 2017 1 commit
  61. 08 Aug, 2017 2 commits
    • Jakob Gruber's avatar
      [snapshot] Simplify deserializer APIs · 95f86859
      Jakob Gruber authored 
      This moves deserializer setup boilerplate inside the deserializers, and
makes improper usage less likely. For instance:

  ObjectDeserializer deserializer(&scd);
  /* ... deserializer setup ... */
  MaybeHandle<HeapObject> obj = deserializer.Deserialize(isolate);
  /* ... result checks and casts ... */

has now become:

  /* All setup and casts inside deserializer, impossible to illegally
     use the same instance multiple times. */
  MaybeHandle<SharedFunctionInfo> maybe_result =
      ObjectDeserializer::DeserializeSharedFunctionInfo(
          isolate, &scd, source);

Bug: v8:6624
Change-Id: Id5a1848e024e89cf86e5292389ba7c89f31d8e6b
Reviewed-on: https://chromium-review.googlesource.com/604791
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47219}
      95f86859
    • Jakob Gruber's avatar
      [snapshot] Continue splitting up Deserializer · 2e2069cd
      Jakob Gruber authored 
      Another pure refactoring CL. This extracts methods used only by Deserializer
subclasses.

Bug: v8:6624
Change-Id: Ib4dd7cdc591dff217e282e68a490c8c7129b9c96
Reviewed-on: https://chromium-review.googlesource.com/602188
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47211}
      2e2069cd
  63. 03 Aug, 2017 1 commit
    • jgruber's avatar
      [snapshot] Begin splitting up Deserializer · b68b63fc
      jgruber authored 
      This begins splitting up the Deserializer class into
{Object,Partial,Startup}Deserializer.  For now, all functionality remains in
the Deserializer base clase, to be refactored in future CLs.  Empty .cc files
are added here to avoid having to touch build files again.

Bug: v8:6624
Change-Id: If563e03492991bd55c91cd2e09312c0a26aaab2c
Reviewed-on: https://chromium-review.googlesource.com/598067Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47107}
      b68b63fc
  65. 11 Apr, 2017 1 commit
    • Caitlin Potter's avatar
      [prettyprinter] improve call-printing of GetIterator nodes · b086856f
      Caitlin Potter authored 
      Fix error message printed by Runtime_ThrowCalledNonCallable.

As noted on the bug, this has a slight problem in that it will always
print that "asyncIterator" was not callable for GetIterator with an
async IteratorType, though it may be referring to a different call.
This issue is present regardless of the change I introduced to perform
this desugaring in the BytecodeGenerator.

BUG=v8:6187
R=adamk@chromium.org, verwaest@chromium.org

Change-Id: I2077b7cd5976d9d9ba044f0dff44ee8c312d1263
Reviewed-on: https://chromium-review.googlesource.com/470806Reviewed-by: 's avatarAdam Klein <adamk@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#44543}
      b086856f
  67. 28 Feb, 2017 1 commit
  69. 17 Feb, 2017 1 commit
    • vabr's avatar
      Report unexpected lexical decl also without destructuring · 454816f0
      vabr authored 
      https://codereview.chromium.org/2694003002/ introduced
"SyntaxError: Lexical declaration cannot appear in a single-statement context"
for the case when let + desctructuring from a list happen.

As was pointed out in https://codereview.chromium.org/2694003002/#msg18, the
case without destructuring would also benefit from a better message: if a
single statement is expected and "let identifier = ..." is seen, the error is
indeed again that the lexical declaration is not a statement. However, the current
error is "Unexpected identifier", because the parser tries to accept "let" as
an identifier in an expression statement, and then gives up seeing the other
identifier after "let".

This CL ensures that the parser recognises the error properly and reports
accordingly. It also renames the existing test, which contains destructuring,
and adds the one with a non-destructuring lexical declaration.

BUG=v8:5686

Review-Url: https://codereview.chromium.org/2697193007
Cr-Commit-Position: refs/heads/master@{#43275}
      454816f0