1. 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
  2. 05 Aug, 2020 1 commit
    • Jakob Gruber's avatar
      [nci] Replace CompilationTarget with a new Code::Kind value · c51041f4
      Jakob Gruber authored
      With the new Turbofan variants (NCI and Turboprop), we need a way to
      distinguish between them both during and after compilation. We
      initially introduced CompilationTarget to track the variant during
      compilation, but decided to reuse the code kind as the canonical spot to
      store this information instead.
      
      Why? Because it is an established mechanism, already available in most
      of the necessary spots (inside the pipeline, on Code objects, in
      profiling traces).
      
      This CL removes CompilationTarget and adds a new
      NATIVE_CONTEXT_INDEPENDENT kind, plus helper functions to determine
      various things about a given code kind (e.g.: does this code kind
      deopt?).
      
      As a (very large) drive-by, refactor both Code::Kind and
      AbstractCode::Kind into a new CodeKind enum class.
      
      Bug: v8:8888
      Change-Id: Ie858b9a53311b0731630be35cf5cd108dee95b39
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2336793
      Commit-Queue: Jakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#69244}
      c51041f4
  3. 28 Jul, 2020 2 commits
  4. 22 Jul, 2020 1 commit
  5. 06 Jul, 2020 1 commit
  6. 23 Jun, 2020 1 commit
  7. 22 Jun, 2020 1 commit
  8. 15 Jun, 2020 1 commit
  9. 10 Jun, 2020 3 commits
  10. 09 Jun, 2020 1 commit
  11. 03 Jun, 2020 1 commit
  12. 02 Jun, 2020 2 commits
    • Clemens Backes's avatar
      [codegen] Move SourcePositionTableBuilder to Zone · 447ad5cc
      Clemens Backes authored
      The SourcePositionTableBuilder unconditionally allocates heap memory for
      every Liftoff compilation. This shows up with 1-2% of compilation time
      in profiles. Hence move the vector contained in the
      SourcePositionTableBuilder into the compilation zone. Such a zone
      already exists for both Liftoff and TurboFan, so we can easily save
      allocations this way.
      
      R=thibaudm@chromium.org
      
      Bug: v8:10576
      Change-Id: Ia83d05cc8c36c775ebff6ec2064e9c3f8cc4d384
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2224221
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68112}
      447ad5cc
    • Clemens Backes's avatar
      [wasm][debug] Support multi-threaded breakpoints · 5fcb414a
      Clemens Backes authored
      This adds support for multiple isolates sharing the same module but
      setting different breakpoints. This is simulated by having a debugger
      test that runs in the "--isolates" variant, i.e. two isolates running
      the same test at the same time. Both isolates will set and remove
      breakpoints.
      
      The DebugInfo will keep a separate list of breakpoints per isolate, and
      when recompiling a function for debugging it will respect all
      breakpoints in all isolates.
      In order to ensure consistency if multiple isolates are setting or
      removing breakpoints simultaneously, we go back to a more coarse-grained
      locking scheme, where the DebugInfo lock is held while re-compiling
      Liftoff functions.
      
      While recompilation will install the code in the module-global code
      table and jump table (and hence all isolates will use it for future
      calls), only the stack of the requesting isolate is rewritten to
      immediately use new code. This is OK, because other isolates are not
      interested in the new breakpoint(s) anyway.
      On {SetBreakpoint}, we always need to rewrite the stack of the
      requesting isolate though, even if the breakpoint was set before by
      another isolate.
      
      Drive-by: Some fixes in SharedFunctionInfo in order to support setting
      breakpoints via the Debug mirror.
      
      R=thibaudm@chromium.org
      
      Bug: v8:10359
      Change-Id: If659afb273260fc5e8124b4b617fb4322de473c7
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_rel
      Cq-Include-Trybots: luci.v8.try:v8_linux64_tsan_isolates_rel_ng
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2218059Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Reviewed-by: 's avatarThibaud Michaud <thibaudm@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#68096}
      5fcb414a
  13. 20 May, 2020 1 commit
  14. 13 May, 2020 2 commits
  15. 11 May, 2020 1 commit
  16. 08 May, 2020 1 commit
  17. 07 May, 2020 1 commit
  18. 06 May, 2020 3 commits
  19. 05 May, 2020 2 commits
  20. 04 May, 2020 1 commit
  21. 01 May, 2020 1 commit
    • Seth Brenith's avatar
      [debug] Don't crash when breaking on entry to functions with heap vars · 3c20dfed
      Seth Brenith authored
      Any function with heap-allocated variables starts by creating and
      pushing a new context for its execution. When entering the debugger due
      to the stack check in the beginning of InterpreterEntryTrampoline, the
      function has not yet had a chance to push that new context. The code in
      ScopeIterator currently assumes that any function which needs a context
      already has one by the time the debugger attempts to iterate scopes, but
      in this case that assumption is invalid, which can cause a null deref.
      
      This change introduces a new function ScopeIterator::NeedsAndHasContext
      to replace previous calls to current_scope_->NeedsContext(). This new
      function checks for the case where the current scope matches the closure
      scope but the context matches the containing context for the function,
      which implies that the function has not yet pushed its own context.
      
      Bug: v8:10319, chromium:1038747
      Change-Id: I29636f269c44d35b68d8446769d17170eed50e89
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2168021
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67519}
      3c20dfed
  22. 28 Apr, 2020 3 commits
  23. 24 Apr, 2020 2 commits
    • Timothy Gu's avatar
      Reland "[builtins] Clean up the use of class_name / ES5 [[Class]]" · 1aa51b49
      Timothy Gu authored
      This is a reland of 29c1eab9
      
      Original change's description:
      > [builtins] Clean up the use of class_name / ES5 [[Class]]
      >
      > Before ES2015, the ES spec had a [[Class]] internal slot for all
      > objects, which Object.prototype.toString() would use to figure the
      > returned string. Post-ES2015, the [[Class]] slot was removed in spec for
      > all objects, with the @@toStringTag well-known symbol the proper way to
      > change Object.prototype.toString() output.
      >
      > At the time, spec-identical handling without the use of [[Class]] was
      > implemented in V8 for all objects other than API objects, where issues
      > with the Web IDL spec [1] prevented Blink, and hence V8, to totally
      > migrate to @@toStringTag. However, since 2016 [2] Blink has been setting
      > @@toStringTag on API class prototypes to manage the
      > Object.prototype.toString() output, so the legacy [[Class]] handling in
      > V8 has not been necessary for the past couple of years.
      >
      > This CL removes the remaining legacy [[Class]] handling in
      > Object.prototype.toString(), JSReceiver::class_name(), and
      > GetConstructorName(). However, it does not remove the class_name field
      > in FunctionTemplateInfo, as it is still used for the `name` property of
      > created functions.
      >
      > This CL also cleans up other places in the codebase that still reference
      > [[Class]].
      >
      > This change should have minimal impact on web-compatibility. For the
      > change to be observable, a script must do one of the following:
      >
      > 1. delete APIConstructor.prototype[Symbol.toStringTag];
      > 2. Object.setPrototypeOf(apiObject, somethingElse);
      >
      > Before this CL, these changes will not change the apiObject.toString()
      > output. But after this CL, they will make apiObject.toString() show
      > "[object Object]" (in the first case) or the @@toStringTag of the other
      > prototype (in the latter case).
      >
      > However, both are deemed unlikely. @@toStringTag is not well-known
      > feature of JavaScript, nor does it get tampered much on API
      > constructors. In the second case, setting the prototype of an API object
      > would effectly render the object useless, as all its methods (including
      > property getters/setters) would no longer be accessible.
      >
      > Currently, @@toStringTag-based API object branding is not yet
      > implemented by other browsers. This V8 bug in particular has been an
      > impediment to standardizing toString behavior. Fixing this bug will
      > unblock [3] and lead to a better Web IDL spec, and better toString()
      > compatibility for all.
      >
      > [1]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28244
      > [2]: https://crrev.com/909c0d7d5a53c8526ded351683c65ea7d17531d4
      > [3]: https://github.com/heycam/webidl/pull/357
      >
      > Bug: chromium:793406
      > Cq-Include-Trybots: luci.chromium.try:linux-rel
      > Change-Id: Iceded24e37afa2646ec385d5018909f55b177f93
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2146996
      > Commit-Queue: Timothy Gu <timothygu@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67327}
      
      Bug: chromium:793406
      Change-Id: Ia5d97bd4e1c44cadc6f18a17ffc9d06b038cf8f1
      Cq-Include-Trybots: luci.chromium.try:linux-rel
      Cq-Include-Trybots: luci.v8.try:v8_linux_blink_rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2163881
      Auto-Submit: Timothy Gu <timothygu@chromium.org>
      Commit-Queue: Toon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67361}
      1aa51b49
    • Bill Budge's avatar
      Revert "[builtins] Clean up the use of class_name / ES5 [[Class]]" · 213016d6
      Bill Budge authored
      This reverts commit 29c1eab9.
      
      Reason for revert: Causes Blink test failures:
      https://ci.chromium.org/p/v8/builders/ci/V8%20Blink%20Linux/4222
      
      Original change's description:
      > [builtins] Clean up the use of class_name / ES5 [[Class]]
      > 
      > Before ES2015, the ES spec had a [[Class]] internal slot for all
      > objects, which Object.prototype.toString() would use to figure the
      > returned string. Post-ES2015, the [[Class]] slot was removed in spec for
      > all objects, with the @@toStringTag well-known symbol the proper way to
      > change Object.prototype.toString() output.
      > 
      > At the time, spec-identical handling without the use of [[Class]] was
      > implemented in V8 for all objects other than API objects, where issues
      > with the Web IDL spec [1] prevented Blink, and hence V8, to totally
      > migrate to @@toStringTag. However, since 2016 [2] Blink has been setting
      > @@toStringTag on API class prototypes to manage the
      > Object.prototype.toString() output, so the legacy [[Class]] handling in
      > V8 has not been necessary for the past couple of years.
      > 
      > This CL removes the remaining legacy [[Class]] handling in
      > Object.prototype.toString(), JSReceiver::class_name(), and
      > GetConstructorName(). However, it does not remove the class_name field
      > in FunctionTemplateInfo, as it is still used for the `name` property of
      > created functions.
      > 
      > This CL also cleans up other places in the codebase that still reference
      > [[Class]].
      > 
      > This change should have minimal impact on web-compatibility. For the
      > change to be observable, a script must do one of the following:
      > 
      > 1. delete APIConstructor.prototype[Symbol.toStringTag];
      > 2. Object.setPrototypeOf(apiObject, somethingElse);
      > 
      > Before this CL, these changes will not change the apiObject.toString()
      > output. But after this CL, they will make apiObject.toString() show
      > "[object Object]" (in the first case) or the @@toStringTag of the other
      > prototype (in the latter case).
      > 
      > However, both are deemed unlikely. @@toStringTag is not well-known
      > feature of JavaScript, nor does it get tampered much on API
      > constructors. In the second case, setting the prototype of an API object
      > would effectly render the object useless, as all its methods (including
      > property getters/setters) would no longer be accessible.
      > 
      > Currently, @@toStringTag-based API object branding is not yet
      > implemented by other browsers. This V8 bug in particular has been an
      > impediment to standardizing toString behavior. Fixing this bug will
      > unblock [3] and lead to a better Web IDL spec, and better toString()
      > compatibility for all.
      > 
      > [1]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28244
      > [2]: https://crrev.com/909c0d7d5a53c8526ded351683c65ea7d17531d4
      > [3]: https://github.com/heycam/webidl/pull/357
      > 
      > Bug: chromium:793406
      > Cq-Include-Trybots: luci.chromium.try:linux-rel
      > Change-Id: Iceded24e37afa2646ec385d5018909f55b177f93
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2146996
      > Commit-Queue: Timothy Gu <timothygu@chromium.org>
      > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#67327}
      
      TBR=verwaest@chromium.org,timothygu@chromium.org
      
      Change-Id: I678d2ffc1064b1d1ddb62024cc23c6c41b216ef4
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: chromium:793406
      Cq-Include-Trybots: luci.chromium.try:linux-rel
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2163956Reviewed-by: 's avatarBill Budge <bbudge@chromium.org>
      Commit-Queue: Bill Budge <bbudge@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67349}
      213016d6
  24. 23 Apr, 2020 2 commits
    • Leszek Swirski's avatar
      [compile] Add an UnoptimizedCompileState class · 6458a529
      Leszek Swirski authored
      Move the persistent compilation state and Isolate inputs (such as the
      allocator, shared AST constants, hash seed, logger, etc.) which survives
      across both parse and compile, out of ParseInfo and into a new
      UnoptimizedCompileState class. Also add UnoptimizedCompilePerThreadState
      for per-thread state such as stack limit and RCS.
      
      In particular, this new state survives the ParseInfo being destructed,
      which means it is available after off-thread finalization. This allows a
      followup to access the PendingCompilationErrorHandler after finalization
      and report errors on merge.
      
      Bug: v8:10314
      Change-Id: Ia186bc0f267c704efd771aa1895f50a4525a8364
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2105636
      Commit-Queue: Leszek Swirski <leszeks@chromium.org>
      Reviewed-by: 's avatarRoss McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67329}
      6458a529
    • Timothy Gu's avatar
      [builtins] Clean up the use of class_name / ES5 [[Class]] · 29c1eab9
      Timothy Gu authored
      Before ES2015, the ES spec had a [[Class]] internal slot for all
      objects, which Object.prototype.toString() would use to figure the
      returned string. Post-ES2015, the [[Class]] slot was removed in spec for
      all objects, with the @@toStringTag well-known symbol the proper way to
      change Object.prototype.toString() output.
      
      At the time, spec-identical handling without the use of [[Class]] was
      implemented in V8 for all objects other than API objects, where issues
      with the Web IDL spec [1] prevented Blink, and hence V8, to totally
      migrate to @@toStringTag. However, since 2016 [2] Blink has been setting
      @@toStringTag on API class prototypes to manage the
      Object.prototype.toString() output, so the legacy [[Class]] handling in
      V8 has not been necessary for the past couple of years.
      
      This CL removes the remaining legacy [[Class]] handling in
      Object.prototype.toString(), JSReceiver::class_name(), and
      GetConstructorName(). However, it does not remove the class_name field
      in FunctionTemplateInfo, as it is still used for the `name` property of
      created functions.
      
      This CL also cleans up other places in the codebase that still reference
      [[Class]].
      
      This change should have minimal impact on web-compatibility. For the
      change to be observable, a script must do one of the following:
      
      1. delete APIConstructor.prototype[Symbol.toStringTag];
      2. Object.setPrototypeOf(apiObject, somethingElse);
      
      Before this CL, these changes will not change the apiObject.toString()
      output. But after this CL, they will make apiObject.toString() show
      "[object Object]" (in the first case) or the @@toStringTag of the other
      prototype (in the latter case).
      
      However, both are deemed unlikely. @@toStringTag is not well-known
      feature of JavaScript, nor does it get tampered much on API
      constructors. In the second case, setting the prototype of an API object
      would effectly render the object useless, as all its methods (including
      property getters/setters) would no longer be accessible.
      
      Currently, @@toStringTag-based API object branding is not yet
      implemented by other browsers. This V8 bug in particular has been an
      impediment to standardizing toString behavior. Fixing this bug will
      unblock [3] and lead to a better Web IDL spec, and better toString()
      compatibility for all.
      
      [1]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=28244
      [2]: https://crrev.com/909c0d7d5a53c8526ded351683c65ea7d17531d4
      [3]: https://github.com/heycam/webidl/pull/357
      
      Bug: chromium:793406
      Cq-Include-Trybots: luci.chromium.try:linux-rel
      Change-Id: Iceded24e37afa2646ec385d5018909f55b177f93
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2146996
      Commit-Queue: Timothy Gu <timothygu@chromium.org>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#67327}
      29c1eab9
  25. 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
  26. 21 Apr, 2020 3 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