1. 07 Nov, 2017 1 commit
  2. 06 Nov, 2017 3 commits
  3. 26 Oct, 2017 1 commit
  4. 17 Oct, 2017 1 commit
  5. 13 Oct, 2017 1 commit
  6. 28 Sep, 2017 1 commit
    • Peter Marshall's avatar
      [cleanup] Replace List with std::vector in api. · 329f6946
      Peter Marshall authored
      The members of HandleScopeImplementer are copied with memcpy when
      the isolate is transferred to another thread. List contained some
      primitives which allowed us to manually free the backing store, which
      was needed in order to ensure that threads would not hold on to
      old pointers and use them later. With std::vector, we can't do that.
      
      Here we change the HandleScopeImplementer to instead use a custom
      structure DetachableVector, which contains a std::vector but allows
      manual detaching and freeing of the backing store. This allows us to
      maintain the old behavior.
      
      Bug: v8:6333
      Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
      Change-Id: I6361d161cdb19878ba19ed51d6ba2fae99e8cdc0
      Reviewed-on: https://chromium-review.googlesource.com/660125Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Commit-Queue: Peter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#48197}
      329f6946
  7. 11 Sep, 2017 2 commits
  8. 05 Sep, 2017 1 commit
    • jgruber's avatar
      [builtins] Implement lazy deserialization for TFJ builtins · 79aee245
      jgruber authored
      This adds support for lazy deserialization of JS-linkage (TFJ) builtins,
      still gated behind the --lazy-deserialization flag. If enabled, we
      proceed as follows:
      
      During isolate initialization, only eager builtins are deserialized. All
      references to lazy builtins are replaced by the DeserializeLazy builtin.
      In particular, this happens in the builtin table (Builtins::builtins_)
      and in SharedFunctionInfo objects.
      
      When calling into a not-yet deserialized function (i.e. the JSFunction's
      code object is the DeserializeLazy builtin), the DeserializeLazy builtin
      takes over.  It checks the builtin table to see if the target builtin
      (determined by looking at the builtin id stored on the
      SharedFunctionInfo) has already been deserialized. If so, it simply
      copies the builtin code object to the JSFunction and SharedFunctionInfo.
      Otherwise, we enter Runtime::kDeserializeLazy to deserialize the
      builtin.
      
      With --lazy-deserialization, isolate deserialization is 11% faster
      (1.5ms vs.  1.7ms), and code_space->Size() is 33% lower (984K vs.
      1475K).
      
      Moving relocation infos & handler tables out of the partial snapshot
      cache would additionally let us save up to 30K per isolate. Adding code
      stubs to that list increases further potential savings to 262K.
      
      Bug: v8:6624
      Change-Id: I0ac7d05d165d2466998269bd431ac076a311cbeb
      Reviewed-on: https://chromium-review.googlesource.com/649166
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47818}
      79aee245
  9. 04 Sep, 2017 1 commit
    • jgruber's avatar
      [snapshot] Dynamically allocate builtin code objects in advance · b7b91142
      jgruber authored
      Our current deserializers (startup & partial) use a system of static memory
      reservations: required memory is determined at serialization time, which we
      then request before deserialization and dole out as-needed during
      deserialization.
      
      Lazy builtin deserialization needs a bit more flexibility. On the one hand, the
      amount of required memory varies since --lazy-deserialization can be switched
      on and off at runtime.
      
      On the other, builtin deserialization has been made order-independent, and we
      can encounter references to builtins before they have been deserialized.
      
      Both problems are solved by dynamically allocating required memory and
      initializing the builtins table with the (yet uninitialized) builtin Code
      objects.
      
      Bug: v8:6624
      Change-Id: Iee90992e91adb4ab45dae1acc81f64a108d12584
      Reviewed-on: https://chromium-review.googlesource.com/647748
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#47789}
      b7b91142
  10. 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
  11. 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
  12. 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
  13. 23 Aug, 2017 1 commit
  14. 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
  15. 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
  16. 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
  17. 28 Feb, 2017 1 commit
  18. 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
  19. 16 Feb, 2017 1 commit
  20. 16 Jan, 2017 1 commit
  21. 12 Jan, 2017 1 commit
  22. 04 Jan, 2017 1 commit