1. 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
  2. 27 Jan, 2021 7 commits
  3. 26 Jan, 2021 5 commits
    • Michael Lippautz's avatar
      cppgc: Random style fixes and comment updates · 29b4d2a1
      Michael Lippautz authored
      Bug: chromium:1056170
      Change-Id: I00511c69e9681a80993bcb8ddb370030fc3d208c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649030
      Commit-Queue: Omer Katz <omerkatz@chromium.org>
      Auto-Submit: Michael Lippautz <mlippautz@chromium.org>
      Reviewed-by: 's avatarOmer Katz <omerkatz@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72343}
      29b4d2a1
    • Dominik Inführ's avatar
      [heap] Stop counting old-to-new slots in MinorMC · 4512066b
      Dominik Inführ authored
      The number of old-to-new slots was used as a heuristic in
      GetMaxConcurrency() to control the number of background jobs. The
      calculation already caused a bug that was fixed in
      https://crrev.com/c/2593247 and isn't used in a major mark-compact.
      Reduce complexity by removing that heuristic.
      
      Change-Id: I88989974a94230b7d6f59846f5b0cce14b4118ca
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649039Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72328}
      4512066b
    • Clemens Backes's avatar
      Revert "[wasm-gc] Remove abstract rtts" · f30c2681
      Clemens Backes authored
      This reverts commit b77deeca.
      
      Reason for revert: MSVC compile fails: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Win64%20-%20msvc/16535/overview
      
      Original change's description:
      > [wasm-gc] Remove abstract rtts
      >
      > In the latest wasm-gc spec, rtts of abstract types are no longer
      > allowed. Consequently, canonical rtts of concrete types always have
      > a depth of 0.
      >
      > Changes:
      > - Change the immediate argument of rtts to a type index over a heap
      >   type. Abstract it with TypeIndexImmediate in function body decoding.
      >   This affects:
      >   value_type.h, read_value_type(), decoding of relevant opcodes,
      >   wasm subtyping, WasmInitExpr, consume_init_expr(), and
      >   wasm-module-builder.cc.
      > - In function-body-decoder-impl.h, update rtt.canon to always produce
      >   an rtt of depth 0.
      > - Pass a unit32_t type index over a HeapType to all rtt-related
      >   utilities.
      > - Remove infrastructure for abstract-type rtts from the wasm compilers,
      >   setup-heap-internal.cc, roots.h, and module-instantiate.cc.
      > - Remove ObjectReferenceKnowledge::rtt_is_i31. Remove related branches
      >   from ref.test, ref.cast and br_on_cast implementations in the wasm
      >   compilers.
      > - Remove unused 'parent' field from WasmTypeInfo.
      > - Make the parent argument optional in NewWasmTypeInfo, CreateStructMap,
      >   and CreateArrayMap.
      > - Use more convenient arguments in IsHeapSubtypeOf.
      > - Update tests.
      >
      > Bug: v8:7748
      > Change-Id: Ib45efe0741e6558c9b291fc8b4a75ae303146bdc
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2642248
      > Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#72321}
      
      TBR=ulan@chromium.org,jkummerow@chromium.org,manoskouk@chromium.org
      
      Change-Id: I2f0d97f1a34f7c81c5a97d7c37925cb84c66eea3
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:7748
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2650206Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
      Commit-Queue: Clemens Backes <clemensb@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72322}
      f30c2681
    • Manos Koukoutos's avatar
      [wasm-gc] Remove abstract rtts · b77deeca
      Manos Koukoutos authored
      In the latest wasm-gc spec, rtts of abstract types are no longer
      allowed. Consequently, canonical rtts of concrete types always have
      a depth of 0.
      
      Changes:
      - Change the immediate argument of rtts to a type index over a heap
        type. Abstract it with TypeIndexImmediate in function body decoding.
        This affects:
        value_type.h, read_value_type(), decoding of relevant opcodes,
        wasm subtyping, WasmInitExpr, consume_init_expr(), and
        wasm-module-builder.cc.
      - In function-body-decoder-impl.h, update rtt.canon to always produce
        an rtt of depth 0.
      - Pass a unit32_t type index over a HeapType to all rtt-related
        utilities.
      - Remove infrastructure for abstract-type rtts from the wasm compilers,
        setup-heap-internal.cc, roots.h, and module-instantiate.cc.
      - Remove ObjectReferenceKnowledge::rtt_is_i31. Remove related branches
        from ref.test, ref.cast and br_on_cast implementations in the wasm
        compilers.
      - Remove unused 'parent' field from WasmTypeInfo.
      - Make the parent argument optional in NewWasmTypeInfo, CreateStructMap,
        and CreateArrayMap.
      - Use more convenient arguments in IsHeapSubtypeOf.
      - Update tests.
      
      Bug: v8:7748
      Change-Id: Ib45efe0741e6558c9b291fc8b4a75ae303146bdc
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2642248
      Commit-Queue: Manos Koukoutos <manoskouk@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72321}
      b77deeca
    • Georg Neis's avatar
      [cleanup] Remove unused root empty_property_cell · ca5da5b9
      Georg Neis authored
      Change-Id: I702f8c021490f0538a98cad9a61b1dbae60fb881
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2649027Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Georg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72314}
      ca5da5b9
  4. 22 Jan, 2021 5 commits
  5. 21 Jan, 2021 2 commits
  6. 20 Jan, 2021 4 commits
    • Ulan Degenbaev's avatar
      [heap] Skip global memory check for starting GC from a background thread · e4bc1efe
      Ulan Degenbaev authored
      Currently background thread cannot allocate embedder objects and
      checking the embedder heap size is not thread-safe. For simplicity,
      we can skip the check until concurrent allocation of embedder objects
      is supported.
      
      Bug: chromium:1162744, chromium:1160097
      Change-Id: I47d6299e77b986e4b2cb8da841e0149ef577918a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2640477Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72204}
      e4bc1efe
    • Seth Brenith's avatar
      [torque] Begin porting ScopeInfo to Torque · ecaac329
      Seth Brenith authored
      This change adds Torque field definitions for ScopeInfo and begins to
      use the Torque-generated accessors in some places. It does not change
      the in-memory layout of ScopeInfo.
      
      Torque compiler changes:
      
      - Fix an issue where the parser created constexpr types for classes
        based on the class name rather than the `generates` clause. This meant
        that generated accessors referred to the imaginary type HashTable
        rather than the real C++ type FixedArray.
      - Don't pass Isolate* through the generated runtime functions that
        implement Torque macros. Maybe we'll need it eventually, but we don't
        right now and it complicates a lot of things.
      - Don't emit `kSomeFieldOffset` if some_field has an unknown offset.
        Instead, emit a member function `SomeFieldOffset()` which fetches the
        slice for some_field and returns its offset.
      - Emit an `AllocatedSize()` member function for classes which have
        complex length expressions. It fetches the slice for the last field
        and performs the multiply&add to compute the total object size.
      - Emit field accessors for fields with complex length expressions, using
        the new offset functions.
      - Fix a few minor bugs where Torque can write uncompilable code.
      
      With this change, most code still treats ScopeInfo like a FixedArray, so
      I would like to follow up with some additional changes:
      
      1. Generate a GC visitor for ScopeInfo and use it
      2. Generate accessors for struct-typed fields (indexed or otherwise),
         and use them
      3. Get rid of the FixedArray-style get and set accessors; use
         TaggedField::load and similar instead
      4. Inherit from HeapObject rather than FixedArrayBase to remove the
         unnecessary `length` field
      
      After that, there will only be one ugly part left: initialization. I
      think it's possible to generate a factory function that takes a bunch of
      iterator parameters and returns a fully-formed, verifiably correct
      ScopeInfo instance, but doing so is more complicated than the four
      mostly-mechanical changes listed above.
      
      Bug: v8:7793
      Change-Id: I55fcfe9189e4d1613c68d49e378da5dc02597b36
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2357758Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarTobias Tebbi <tebbi@chromium.org>
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Cr-Commit-Position: refs/heads/master@{#72187}
      ecaac329
    • Camillo Bruni's avatar
      [api] Use FLAG_log to check whether logging is enabled · 1dd3e29b
      Camillo Bruni authored
      Doing a function call into the logger to decide whether logging is
      enabled or not is more costly than necessary.
      
      This CL changes logging to take FLAG_log as main signal whether logging
      could be active. If FLAG_log == false, logging cannot be active. In
      that case we always call into the logger and perform detailed checks
      there.
      
      This CL changes flag-definitions to set FLAG_log if they need logging.
      
      Change-Id: Ia51ed9fb7128451bf1dcf345fab257547aab4a47
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2602461Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Commit-Queue: Camillo Bruni <cbruni@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72186}
      1dd3e29b
    • Victor Gomes's avatar
      [cleanup] Remove ArgumentsAdaptorDeoptPCOffset · 73c399bb
      Victor Gomes authored
      Without the adaptor frame, this is dead code.
      
      Change-Id: Ica1ee102fcc068a58c5dcbca6122921cd1b5550a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2639760Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Victor Gomes <victorgomes@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#72185}
      73c399bb
  7. 19 Jan, 2021 4 commits
  8. 18 Jan, 2021 2 commits
  9. 14 Jan, 2021 2 commits
  10. 13 Jan, 2021 2 commits
  11. 12 Jan, 2021 2 commits
  12. 11 Jan, 2021 1 commit
    • Mythri A's avatar
      Evict deoptimized code on feedback vector after creating the closure · 85b1d24b
      Mythri A authored
      When creating a new closure, we check feedback vector for any optimized
      code and install it on the newly created closure. We evict the optimized
      code from the feedback vector if it is marked for deoptimization. We
      used to evict the code before creating the new closure. However,
      creating a new closure could cause allocation failures and hence trigger
      a GC. This could mark optimized code on feedback vector for
      deoptimization if any weak objects held by optimized code are GC'ed.
      
      This cl delays the eviction unitl after the closure was created.
      
      Bug: v8:1163184
      Change-Id: I217279e4a51f75b87bb7ae5a00fd1cf57805e3c8
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2613034
      Commit-Queue: Mythri Alle <mythria@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#71999}
      85b1d24b
  13. 09 Jan, 2021 1 commit
  14. 08 Jan, 2021 2 commits