1. 09 Jun, 2021 1 commit
  2. 19 May, 2021 1 commit
  3. 26 Apr, 2021 1 commit
  4. 12 Apr, 2021 1 commit
  5. 15 Mar, 2021 1 commit
  6. 29 Jan, 2021 1 commit
  7. 28 Jan, 2021 1 commit
    • Marja Hölttä's avatar
      Revert "Reland [super] Store home object in Context instead of JSFunction" · 12f8ac47
      Marja Hölttä authored
      This reverts commit f6450b97.
      
      Reason for revert: ClusterFuzz bugs
      
      Original change's description:
      > Reland [super] Store home object in Context instead of JSFunction
      >
      > 1) Computed property keys (esp functions in them) shouldn't be inside
      > the object literal scope.
      >
      > 2) I was using an imprecise "maybe uses super" and storing it to
      > preparse data. This won't fly, since it pollutes sister scopes and
      > leads to confusion wrt whether an object literal needs a home object
      > or not. Made it precise (mostly cancelling changes in the original CL).
      >
      > 3) PreParser::NewSuperPropertyReference was creating a VariableProxy for
      > this_function (which made it used) -> inconsistent scopes between
      > parsing and preparsing.
      >
      > 4) MultipleEntryBlockContextScope was messing up the accumulator
      >
      > Original: https://chromium-review.googlesource.com/c/v8/v8/+/2563275
      >
      > This saves memory (the home object doesn't need to be stored for each
      > method, but only once per class) and hopefully makes the home object
      > a constant in the optimized code.
      >
      > Detailed documentation of the changes:
      > https://docs.google.com/document/d/1ZVXcoQdf9IdMsnRI9iyUjyq9NDoEyx9nA3XqMgwflMs/edit?usp=sharing
      >
      > Bug: v8:9237, chromium:1167918, chromium:1167981, chromium:1167988, chromium:1168055
      > Change-Id: I4f53f18cc18762c33e53d8c802909b42f1c33538
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2637220
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Marja Hölttä <marja@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#72169}
      
      TBR=marja@chromium.org,leszeks@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:9237
      Bug: chromium:1167918
      Bug: chromium:1167981
      Bug: chromium:1167988
      Bug: chromium:1168055
      Bug: chromium:1171195
      Bug: chromium:1171600
      Change-Id: I15209f50c3fc8acf385a23f031ebb64139e2f519
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2653158Reviewed-by: 's avatarMarja Hölttä <marja@chromium.org>
      Commit-Queue: Marja Hölttä <marja@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72391}
      12f8ac47
  8. 19 Jan, 2021 2 commits
  9. 18 Jan, 2021 1 commit
  10. 20 Nov, 2020 1 commit
  11. 28 Sep, 2020 1 commit
  12. 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
  13. 06 Aug, 2020 1 commit
    • Leszek Swirski's avatar
      [runtime] Move string table off-heap · 1546be9c
      Leszek Swirski authored
      Changes the isolate's string table into an off-heap structure. This
      allows the string table to be resized without allocating on the V8 heap,
      and potentially triggering a GC. This allows existing strings to be
      inserted into the string table without requiring allocation.
      
      This has two important benefits:
      
        1) It allows the deserializer to insert strings directly into the
           string table, rather than having to defer string insertion until
           deserialization completes.
      
        2) It simplifies the concurrent string table lookup to allow resizing
           the table inside the write lock, therefore eliminating the race
           where two concurrent lookups could both resize the table.
      
      The off-heap string table has the following properties:
      
        1) The general hashmap behaviour matches the HashTable, i.e. open
           addressing, power-of-two sized, quadratic probing. This could, of
           course, now be changed.
      
        2) The empty and deleted sentinels are changed to Smi 0 and 1,
           respectively, to make those comparisons a bit cheaper and not
           require roots access.
      
        3) When the HashTable is resized, the old elements array is kept
           alive in a linked list of previous arrays, so that concurrent
           lookups don't lose the data they're accessing. This linked list
           is cleared by the GC, as then we know that all threads are in
           a safepoint.
      
        4) The GC treats the hash table entries as weak roots, and only walks
           them for non-live reference clearing and for evacuation.
      
        5) Since there is no longer a FixedArray to serialize for the startup
           snapshot, there is now a custom serialization of the string table,
           and the string table root is considered unserializable during weak
           root iteration. As a bonus, the custom serialization is more
           efficient, as it skips non-string entries.
      
      As a drive-by, rename LookupStringExists_NoAllocate to
      TryStringToIndexOrLookupExisting, to make it clearer that it returns
      a non-string for the case when the string is an array index. As another
      drive-by, extract StringSet into a separate header.
      
      Bug: v8:10729
      Change-Id: I9c990fb2d74d1fe222920408670974a70e969bca
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2339104
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69270}
      1546be9c
  14. 16 Jul, 2020 1 commit
  15. 15 Jul, 2020 2 commits
  16. 10 Jul, 2020 2 commits
  17. 11 May, 2020 1 commit
  18. 08 May, 2020 1 commit
  19. 06 May, 2020 1 commit
    • Leszek Swirski's avatar
      [parser] Move Compiler::Analyze into Parser · 65d738d4
      Leszek Swirski authored
      Move rewriting, scope analysis, and internalization, to be unconditional
      operations done after parsing rather than a separate compile phase. This
      removes some of the complexity about rememberering when to call
      Compiler::Analyze, and makes these paths a bit more uniform.
      
      Also, forbid allocating any more AST strings after AstValueFactory
      internalization, by nulling out the Zone. Add an InternalizePartial
      method which doesn't null out the zone for those cases where we do want
      to be able to allocate after internalizing (e.g. internalization before
      scope analysis).
      
      Change-Id: Id444246d8362a1d169baf664fc37657d9576fd96
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2182458Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67608}
      65d738d4
  20. 22 Apr, 2020 1 commit
    • Leszek Swirski's avatar
      Reland^5 "[parser] Introduce UnoptimizedCompileFlags" · a3228bfc
      Leszek Swirski authored
      This is a reland of e1b93a4f
      which was a reland of 313d4844
      which was a reland of 0a59e0cb
      which was a reland of 146f5375
      which was a reland of d91679bf
      
      Give up on using C++ bitfields, go back to having base::BitField and
      getters/setters.
      
      Original change's description:
      > [parser] Introduce UnoptimizedCompileFlags
      >
      > UnoptimizedCompileFlags defines the input flags shared between parse and
      > compile (currently parse-only). It is set initially with some values, and
      > is immutable after being passed to ParseInfo (ParseInfo still has getters
      > for the fields, but no setters).
      >
      > Since a few of the existing flags were output flags, ParseInfo now has a
      > new output_flags field, which will eventually migrate to a ParseOutputs
      > structure.
      >
      > Bug: v8:10314
      > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Simon Zünd <szuend@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66782}
      
      TBR=ulan@chromium.org,szuend@chromium.org
      
      Bug: v8:10314
      Change-Id: I54bcd107a0e85cf1a2ddeef0759100547eb65652
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157378Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67309}
      a3228bfc
  21. 21 Apr, 2020 4 commits
    • Leszek Swirski's avatar
      Revert "Reland^4 "[parser] Introduce UnoptimizedCompileFlags"" · 33ea5e55
      Leszek Swirski authored
      This reverts commit e1b93a4f.
      
      Reason for revert: MSVC failing https://ci.chromium.org/p/v8/builders/ci/V8%20Win64%20-%20msvc/13274
      
      Original change's description:
      > Reland^4 "[parser] Introduce UnoptimizedCompileFlags"
      > 
      > This is a reland of 313d4844
      > which was a reland of 0a59e0cb
      > which was a reland of 146f5375
      > which was a reland of d91679bf
      > 
      > Manually zero out flags with memset, since GCC appears not to initialize
      > the bitfield values to zero even with a default constructor.
      > 
      > Original change's description:
      > > [parser] Introduce UnoptimizedCompileFlags
      > >
      > > UnoptimizedCompileFlags defines the input flags shared between parse and
      > > compile (currently parse-only). It is set initially with some values, and
      > > is immutable after being passed to ParseInfo (ParseInfo still has getters
      > > for the fields, but no setters).
      > >
      > > Since a few of the existing flags were output flags, ParseInfo now has a
      > > new output_flags field, which will eventually migrate to a ParseOutputs
      > > structure.
      > >
      > > Bug: v8:10314
      > > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580
      > > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > Reviewed-by: Simon Zünd <szuend@chromium.org>
      > > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#66782}
      > 
      > TBR=ulan@chromium.org,szuend@chromium.org,rmcilroy@chromium.org
      > 
      > Bug: v8:10314
      > Change-Id: I23bd6f9f14e9d0bbdde91aad46be1a646fd9647d
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157372
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67271}
      
      TBR=ulan@chromium.org,rmcilroy@chromium.org,leszeks@chromium.org,szuend@chromium.org
      
      Change-Id: I0f41e847d4edae67e131cc6d0f782137ab73bac2
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:10314
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157377Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67275}
      33ea5e55
    • Leszek Swirski's avatar
      Reland^4 "[parser] Introduce UnoptimizedCompileFlags" · e1b93a4f
      Leszek Swirski authored
      This is a reland of 313d4844
      which was a reland of 0a59e0cb
      which was a reland of 146f5375
      which was a reland of d91679bf
      
      Manually zero out flags with memset, since GCC appears not to initialize
      the bitfield values to zero even with a default constructor.
      
      Original change's description:
      > [parser] Introduce UnoptimizedCompileFlags
      >
      > UnoptimizedCompileFlags defines the input flags shared between parse and
      > compile (currently parse-only). It is set initially with some values, and
      > is immutable after being passed to ParseInfo (ParseInfo still has getters
      > for the fields, but no setters).
      >
      > Since a few of the existing flags were output flags, ParseInfo now has a
      > new output_flags field, which will eventually migrate to a ParseOutputs
      > structure.
      >
      > Bug: v8:10314
      > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Simon Zünd <szuend@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66782}
      
      TBR=ulan@chromium.org,szuend@chromium.org,rmcilroy@chromium.org
      
      Bug: v8:10314
      Change-Id: I23bd6f9f14e9d0bbdde91aad46be1a646fd9647d
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157372Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67271}
      e1b93a4f
    • Sathya Gunasekaran's avatar
      Revert "Reland^3 "[parser] Introduce UnoptimizedCompileFlags"" · a709f779
      Sathya Gunasekaran authored
      This reverts commit 313d4844.
      
      Reason for revert: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20gcc/6354
      
      Original change's description:
      > Reland^3 "[parser] Introduce UnoptimizedCompileFlags"
      > 
      > This is a reland of 0a59e0cb
      > which was a reland of 146f5375
      > which was a reland of d91679bf
      > 
      > Initializes the BackgroundCompileTasks's language_mode in the
      > constructor (previously only initialized after successful parse) in case
      > the parse failed. We still need to reset it after parse in case the
      > language mode changed (because we encountered "use strict").
      > 
      > Original change's description:
      > > [parser] Introduce UnoptimizedCompileFlags
      > >
      > > UnoptimizedCompileFlags defines the input flags shared between parse and
      > > compile (currently parse-only). It is set initially with some values, and
      > > is immutable after being passed to ParseInfo (ParseInfo still has getters
      > > for the fields, but no setters).
      > >
      > > Since a few of the existing flags were output flags, ParseInfo now has a
      > > new output_flags field, which will eventually migrate to a ParseOutputs
      > > structure.
      > >
      > > Bug: v8:10314
      > > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580
      > > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > Reviewed-by: Simon Zünd <szuend@chromium.org>
      > > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#66782}
      > 
      > TBR=ulan@chromium.org,szuend@chromium.org,rmcilroy@chromium.org
      > 
      > Bug: v8:10314
      > Change-Id: Ieee0bbfade4fe0b56de03bff47a7364959608d6a
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157367
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67265}
      
      TBR=leszeks@chromium.org
      
      Change-Id: I90ac035caa76d4c4baf5ce207247d1ce5169fb2f
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:10314
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157370Reviewed-by: 's avatarSathya Gunasekaran  <gsathya@chromium.org>
      Commit-Queue: Sathya Gunasekaran  <gsathya@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67266}
      a709f779
    • Leszek Swirski's avatar
      Reland^3 "[parser] Introduce UnoptimizedCompileFlags" · 313d4844
      Leszek Swirski authored
      This is a reland of 0a59e0cb
      which was a reland of 146f5375
      which was a reland of d91679bf
      
      Initializes the BackgroundCompileTasks's language_mode in the
      constructor (previously only initialized after successful parse) in case
      the parse failed. We still need to reset it after parse in case the
      language mode changed (because we encountered "use strict").
      
      Original change's description:
      > [parser] Introduce UnoptimizedCompileFlags
      >
      > UnoptimizedCompileFlags defines the input flags shared between parse and
      > compile (currently parse-only). It is set initially with some values, and
      > is immutable after being passed to ParseInfo (ParseInfo still has getters
      > for the fields, but no setters).
      >
      > Since a few of the existing flags were output flags, ParseInfo now has a
      > new output_flags field, which will eventually migrate to a ParseOutputs
      > structure.
      >
      > Bug: v8:10314
      > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Simon Zünd <szuend@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66782}
      
      TBR=ulan@chromium.org,szuend@chromium.org,rmcilroy@chromium.org
      
      Bug: v8:10314
      Change-Id: Ieee0bbfade4fe0b56de03bff47a7364959608d6a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157367Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67265}
      313d4844
  22. 20 Apr, 2020 4 commits
    • Francis McCabe's avatar
      Revert "Reland^2 "[parser] Introduce UnoptimizedCompileFlags"" · b89397c5
      Francis McCabe authored
      This reverts commit 0a59e0cb.
      
      Reason for revert: Still causing UBSAN issues:
      
      https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/10729
      
      
      Original change's description:
      > Reland^2 "[parser] Introduce UnoptimizedCompileFlags"
      > 
      > This is a reland of d91679bf
      > which was a reland of d91679bf
      > 
      > Fixes missing initialization of ParserBase::allow_eval_cache_
      > 
      > Original change's description:
      > > [parser] Introduce UnoptimizedCompileFlags
      > >
      > > UnoptimizedCompileFlags defines the input flags shared between parse and
      > > compile (currently parse-only). It is set initially with some values, and
      > > is immutable after being passed to ParseInfo (ParseInfo still has getters
      > > for the fields, but no setters).
      > >
      > > Since a few of the existing flags were output flags, ParseInfo now has a
      > > new output_flags field, which will eventually migrate to a ParseOutputs
      > > structure.
      > >
      > > Bug: v8:10314
      > > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580
      > > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > Reviewed-by: Simon Zünd <szuend@chromium.org>
      > > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#66782}
      > 
      > TBR=rmcilroy@chromium.org,ulan@chromium.org,szuend@chromium.org
      > 
      > Bug: v8:10314
      > Change-Id: I470de963bdedad31fe7dd149c610f9a89bffa162
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157030
      > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67245}
      
      TBR=rmcilroy@chromium.org,leszeks@chromium.org
      
      Change-Id: I1c5f58cc5608217a149b04aa6f50bb3d7606c26d
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:10314
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157657Reviewed-by: 's avatarFrancis McCabe <fgm@chromium.org>
      Commit-Queue: Francis McCabe <fgm@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67250}
      b89397c5
    • Leszek Swirski's avatar
      Reland^2 "[parser] Introduce UnoptimizedCompileFlags" · 0a59e0cb
      Leszek Swirski authored
      This is a reland of d91679bf
      which was a reland of d91679bf
      
      Fixes missing initialization of ParserBase::allow_eval_cache_
      
      Original change's description:
      > [parser] Introduce UnoptimizedCompileFlags
      >
      > UnoptimizedCompileFlags defines the input flags shared between parse and
      > compile (currently parse-only). It is set initially with some values, and
      > is immutable after being passed to ParseInfo (ParseInfo still has getters
      > for the fields, but no setters).
      >
      > Since a few of the existing flags were output flags, ParseInfo now has a
      > new output_flags field, which will eventually migrate to a ParseOutputs
      > structure.
      >
      > Bug: v8:10314
      > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Simon Zünd <szuend@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66782}
      
      TBR=rmcilroy@chromium.org,ulan@chromium.org,szuend@chromium.org
      
      Bug: v8:10314
      Change-Id: I470de963bdedad31fe7dd149c610f9a89bffa162
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157030Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67245}
      0a59e0cb
    • Leszek Swirski's avatar
      Revert "Reland "[parser] Introduce UnoptimizedCompileFlags"" · 9f6eb557
      Leszek Swirski authored
      This reverts commit 146f5375.
      
      Reason for revert: UBSan (https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20UBSan/10726?)
      
      Original change's description:
      > Reland "[parser] Introduce UnoptimizedCompileFlags"
      > 
      > This is a reland of d91679bf
      > 
      > This reland adds initializers for the output flags.
      > 
      > Original change's description:
      > > [parser] Introduce UnoptimizedCompileFlags
      > >
      > > UnoptimizedCompileFlags defines the input flags shared between parse and
      > > compile (currently parse-only). It is set initially with some values, and
      > > is immutable after being passed to ParseInfo (ParseInfo still has getters
      > > for the fields, but no setters).
      > >
      > > Since a few of the existing flags were output flags, ParseInfo now has a
      > > new output_flags field, which will eventually migrate to a ParseOutputs
      > > structure.
      > >
      > > Bug: v8:10314
      > > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286
      > > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580
      > > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > > Reviewed-by: Simon Zünd <szuend@chromium.org>
      > > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > > Cr-Commit-Position: refs/heads/master@{#66782}
      > 
      > Bug: v8:10314
      > Change-Id: Ibade9658d99fa928709b3d56762c4c002ffff0dc
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2111213
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Simon Zünd <szuend@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67241}
      
      TBR=ulan@chromium.org,rmcilroy@chromium.org,leszeks@chromium.org,szuend@chromium.org
      
      Change-Id: I204eb9e4d0a5bfaeeefeb6b0f1c82856b57cb175
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:10314
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2157029Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67242}
      9f6eb557
    • Leszek Swirski's avatar
      Reland "[parser] Introduce UnoptimizedCompileFlags" · 146f5375
      Leszek Swirski authored
      This is a reland of d91679bf
      
      This reland adds initializers for the output flags.
      
      Original change's description:
      > [parser] Introduce UnoptimizedCompileFlags
      >
      > UnoptimizedCompileFlags defines the input flags shared between parse and
      > compile (currently parse-only). It is set initially with some values, and
      > is immutable after being passed to ParseInfo (ParseInfo still has getters
      > for the fields, but no setters).
      >
      > Since a few of the existing flags were output flags, ParseInfo now has a
      > new output_flags field, which will eventually migrate to a ParseOutputs
      > structure.
      >
      > Bug: v8:10314
      > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Simon Zünd <szuend@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66782}
      
      Bug: v8:10314
      Change-Id: Ibade9658d99fa928709b3d56762c4c002ffff0dc
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2111213
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67241}
      146f5375
  23. 19 Mar, 2020 2 commits
    • Leszek Swirski's avatar
      Revert "[parser] Introduce UnoptimizedCompileFlags" · fabea6af
      Leszek Swirski authored
      This reverts commit d91679bf.
      
      Reason for revert: Seems to cause UBSan errors
      
      Original change's description:
      > [parser] Introduce UnoptimizedCompileFlags
      > 
      > UnoptimizedCompileFlags defines the input flags shared between parse and
      > compile (currently parse-only). It is set initially with some values, and
      > is immutable after being passed to ParseInfo (ParseInfo still has getters
      > for the fields, but no setters).
      > 
      > Since a few of the existing flags were output flags, ParseInfo now has a
      > new output_flags field, which will eventually migrate to a ParseOutputs
      > structure.
      > 
      > Bug: v8:10314
      > Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580
      > Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Simon Zünd <szuend@chromium.org>
      > Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#66782}
      
      TBR=ulan@chromium.org,rmcilroy@chromium.org,leszeks@chromium.org,szuend@chromium.org
      
      Change-Id: Ica139e8862e00cd0560638a0236bbaccd7b2188c
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:10314
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2108548Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66783}
      fabea6af
    • Leszek Swirski's avatar
      [parser] Introduce UnoptimizedCompileFlags · d91679bf
      Leszek Swirski authored
      UnoptimizedCompileFlags defines the input flags shared between parse and
      compile (currently parse-only). It is set initially with some values, and
      is immutable after being passed to ParseInfo (ParseInfo still has getters
      for the fields, but no setters).
      
      Since a few of the existing flags were output flags, ParseInfo now has a
      new output_flags field, which will eventually migrate to a ParseOutputs
      structure.
      
      Bug: v8:10314
      Change-Id: If3890a5fad883bca80a97bf9dfe44d91797dc286
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2096580
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66782}
      d91679bf
  24. 18 Mar, 2020 1 commit
  25. 12 Mar, 2020 1 commit
  26. 02 Mar, 2020 1 commit
  27. 10 Feb, 2020 1 commit
  28. 04 Feb, 2020 1 commit
    • Leszek Swirski's avatar
      [offthread] Add an OffThreadIsolate · 7a20b6b9
      Leszek Swirski authored
      The Factory/OffThreadFactory allows us to cleanly separate object
      construction behaviour between main-thread and off-thread in a
      syntactically consistent way (so that methods templated on the factory
      type can be made to work on both).
      
      However, there are cases where we also have to access the Isolate, for
      handle creation or exception throwing. So far we have been pushing more
      and more "customization points" into the factories to allow these
      factory-templated methods to dispatch on this isolate behaviour via
      these factory methods. Unfortunately, this is an increasing layering
      violation between Factory and Isolate, particularly around exception
      handling.
      
      Now, we introduce an OffThreadIsolate, analogous to Isolate in the same
      way as OffThreadFactory is analogous to Factory. All methods which were
      templated on Factory are now templated on Isolate, and methods which
      used to take an Isolate, and which were recently changed to take a
      templated Factory, are changed/reverted to take a templated Isolate.
      OffThreadFactory gets an isolate() method to match Factory's.
      
      Notably, FactoryHandle is changed to "HandleFor", where the template
      argument can be either of the Isolate type or the Factory type (allowing
      us to dispatch on both depending on what is available).
      
      Bug: chromium:1011762
      Change-Id: Id144176f7da534dd76f3d535ab2ade008b6845e3
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2030909
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#66101}
      7a20b6b9
  29. 16 Jan, 2020 1 commit
    • Leszek Swirski's avatar
      [offthread] Add OffThreadFactory support to AST strings · bcbb553d
      Leszek Swirski authored
      Add support for internalizing an AstValueFactory using the off-thread
      factory. Includes adding ConsString support to OffThreadFactory.
      
      This introduces a Handle union wrapper, which is used in locations that
      can store a Handle or an OffThreadHandle. This is used in this patch for
      the internalized "string" field of AST strings, and will be able to be
      used for other similar fields in other classes (e.g. the ScopeInfo
      handle in Scope, object boilerplate descriptor handles, the inferred
      name handle on FunctionLiterals, etc.). It has a Factory-templated
      getter which returns the appropriate handle for the factory, and a
      debug-only tag to make sure the right getter is used at runtime. This
      union wrapper currently decomposes implicitly to a Handle if the getter
      is not called, to minimise code changes, but this implicit conversion
      will likely be removed for clarity.
      
      Bug: chromium:1011762
      Change-Id: I5dd3a7bbdc483b66f5ff687e0079c545b636dc13
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1993971
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#65816}
      bcbb553d
  30. 14 Jan, 2020 1 commit