1. 26 Sep, 2019 1 commit
    • Dominik Inführ's avatar
      [heap] Invalidate objects unconditionally · a2db7166
      Dominik Inführ authored
      InvalidateRecordedSlots needs to invalidate old-to new objects
      unconditionally. Checking slot_set_[OLD_TO_NEW] is not enough, since the
      sweeping_slot_set_ could still contain slots.
      
      ClearRecordedSlot in MigrateFastToFast is not necessary as well. This is
      only required in DeleteObjectPropertyFast since we might potentially
      shrink the object.
      
      Bug: chromium:1008301,chromium:1008046
      Change-Id: If2c757a619b52d070825e4faadce7710eae61a07
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1826717Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63985}
      a2db7166
  2. 25 Sep, 2019 1 commit
  3. 23 Sep, 2019 1 commit
  4. 16 Sep, 2019 1 commit
    • Dominik Inführ's avatar
      [heap] Split old-to-new remembered set · 167a8946
      Dominik Inführ authored
      Split OLD_TO_NEW remembered set and add OLD_TO_NEW_SWEEPING. The
      OLD_TO_NEW remembered set is moved to OLD_TO_NEW_SWEEPING during
      mark-compact. OLD_TO_NEW_SWEEPING is then modified by the sweeper.
      Before using the page again, OLD_TO_NEW and OLD_TO_NEW_SWEEPING are
      merged again.
      
      This means only the main thread modifies OLD_TO_NEW, the sweeper only
      removes entries from OLD_TO_NEW_SWEEPING. We can use this property
      to make accesses non-atomic in a subsequent CL.
      
      Bug: v8:9454
      Change-Id: I9057cf85818d647775ae4c7beec4c8ccf73e18f7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1771783Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63807}
      167a8946
  5. 13 Sep, 2019 1 commit
  6. 10 Sep, 2019 1 commit
  7. 09 Sep, 2019 1 commit
  8. 04 Sep, 2019 1 commit
  9. 03 Sep, 2019 1 commit
    • Dominik Inführ's avatar
      Revert "[heap] Remove size from invalidated slots" · d4e168a3
      Dominik Inführ authored
      This reverts commit 93063ade.
      
      Reason for revert: Clusterfuzz found issue.
      
      Original change's description:
      > [heap] Remove size from invalidated slots
      > 
      > Slots are always valid inside an invalidated area when outside the
      > respective object's current size. This allows us to remove the size
      > from the InvalidatedSlots data structure.
      > 
      > This change was enabled by https://crrev.com/c/1771793.
      > 
      > Bug: v8:9454
      > Change-Id: I2b5a7234d47227cb6ad8d67de20e9b5a2028ae83
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1773242
      > Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63510}
      
      TBR=ulan@chromium.org,sigurds@chromium.org,tebbi@chromium.org,dinfuehr@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:9454
      Change-Id: I7daf96cf50aaedd4dbdab48fd550182df94e54bf
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1783106Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63535}
      d4e168a3
  10. 02 Sep, 2019 2 commits
  11. 28 Aug, 2019 1 commit
    • Z Nguyen-Huu's avatar
      Add new nonextensible element kinds · 1f4bec27
      Z Nguyen-Huu authored
      Currently the backing store and elements kind might not aligned aka
      backing store can be dictionary where elements kind is frozen/sealed
      element kinds or the other way around. The reason is that
      Object.preventExtensions change elements kind to DICTIONARY while
      Object.seal/freeze change elements kind to SEALED/FROZEN element kind.
      Apply both these operations can lead to that problem as in
      chromium:992914
      
      To solve this issue, we avoid Object.preventExtensions to change backing
      store to dictionary by introducing new nonextensible elements kind.
      These new nonextensible elements kind are handled similar to frozen,
      sealed element kinds. This change not only fixes the problem but also
      optimize the performance of nonextensible objects.
      
      Change-Id: Iffc7f14eb48223c11abf3c577f305d2d072eb65b
      Bug: chromium:992914, v8:6831
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1760976
      Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
      Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
      Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63432}
      1f4bec27
  12. 22 Aug, 2019 2 commits
  13. 20 Aug, 2019 3 commits
  14. 19 Aug, 2019 2 commits
    • Dominik Inführ's avatar
      Revert "Use list of invalidated objects for old-to-new refs" · 9a9ba762
      Dominik Inführ authored
      This reverts commit 60843b42.
      
      Reason for revert: TSAN detected issue between Scavenge workers.
      One task could invoke RefillFreeList(), while the other task iterates the remembered set of a swept page.
      
      Original change's description:
      > Use list of invalidated objects for old-to-new refs
      > 
      > Instead of inserting "deletion" entries into the store buffer, keep a
      > list of invalidated objects to filter out invalid old-to-new slots.
      > 
      > The first CL https://crrev.com/c/1704109 got reverted because both the
      > sweeper and the main task were modifying the invalidated slots data
      > structure concurrently. This CL changes this, such that the sweeper
      > only modifies the invalidated slots during the final atomic pause when
      > the main thread is not running. The sweeper does not need to clean this
      > data structure after the pause, since the "update pointers" phase
      > already removed all invalidated slots.
      > 
      > The second CL https://crrev.com/c/1733081 got reverted because the
      > sweeper might find more free space than the full GC before it. If an
      > object shrinks after the pause but before the sweep, the invalidated
      > object might span free memory and potentially new allocated objects.
      > Therefore shrink invalidated objects when processing swept pages on
      > the main thread. Also clean recorded slots in the gap.
      > 
      > TBR=petermarshall@chromium.org
      > 
      > Bug: v8:9454
      > Change-Id: I80d1fa3bbc24e97f7c97a373aaad66f105456f12
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1751795
      > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63239}
      
      TBR=ulan@chromium.org,hpayer@chromium.org,dinfuehr@chromium.org
      
      Change-Id: I9c6a371ebe36a1873acbe0d6c6a75dd2f5a55f4e
      No-Presubmit: true
      No-Tree-Checks: true
      No-Try: true
      Bug: v8:9454
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1760817Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63253}
      9a9ba762
    • Dominik Inführ's avatar
      Use list of invalidated objects for old-to-new refs · 60843b42
      Dominik Inführ authored
      Instead of inserting "deletion" entries into the store buffer, keep a
      list of invalidated objects to filter out invalid old-to-new slots.
      
      The first CL https://crrev.com/c/1704109 got reverted because both the
      sweeper and the main task were modifying the invalidated slots data
      structure concurrently. This CL changes this, such that the sweeper
      only modifies the invalidated slots during the final atomic pause when
      the main thread is not running. The sweeper does not need to clean this
      data structure after the pause, since the "update pointers" phase
      already removed all invalidated slots.
      
      The second CL https://crrev.com/c/1733081 got reverted because the
      sweeper might find more free space than the full GC before it. If an
      object shrinks after the pause but before the sweep, the invalidated
      object might span free memory and potentially new allocated objects.
      Therefore shrink invalidated objects when processing swept pages on
      the main thread. Also clean recorded slots in the gap.
      
      TBR=petermarshall@chromium.org
      
      Bug: v8:9454
      Change-Id: I80d1fa3bbc24e97f7c97a373aaad66f105456f12
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1751795
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63239}
      60843b42
  15. 08 Aug, 2019 1 commit
    • Dominik Inführ's avatar
      Revert "Use list of invalidated objects for old-to-new refs" · c9f9d1b0
      Dominik Inführ authored
      This reverts commit e2f98ec2.
      
      Reason for revert: Caused performance regression in ArrayLiteralInitialSpreadSmallHoley.
      
      Original change's description:
      > Use list of invalidated objects for old-to-new refs
      >
      > Instead of inserting "deletion" entries into the store buffer, keep
      > a list of invalidated objects to filter out invalid old-to-new slots.
      >
      > The first CL https://crrev.com/c/1704109 got reverted because both the sweeper and the main task were modifying the invalidated slots data structure concurrently. This CL changes this, such that the sweeper only modifies the invalidated slots during the final atomic pause when the main thread is not running. The sweeper does not need to clean this data structure after the pause, since the "update pointers" phase already removed all invalidated slots.
      >
      > Bug: v8:9454
      > Change-Id: Iffb5bf96de2c89eee1ee1231a3414a0f2a155cbc
      > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1733081
      > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
      > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
      > Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      > Cr-Commit-Position: refs/heads/master@{#63087}
      
      TBR=ulan@chromium.org,petermarshall@chromium.org,dinfuehr@chromium.org
      
      # Not skipping CQ checks because original CL landed > 1 day ago.
      
      Bug: v8:9454
      Change-Id: I328b9f72df45fc9570d4a4d1b5389eac010638c7
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1743970
      Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
      Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#63131}
      c9f9d1b0
  16. 07 Aug, 2019 1 commit
  17. 06 Aug, 2019 1 commit
  18. 05 Aug, 2019 1 commit
  19. 30 Jul, 2019 1 commit
  20. 23 Jul, 2019 1 commit
  21. 18 Jul, 2019 1 commit
    • Ross McIlroy's avatar
      [Compile] Ensure we don't reuse a feedback vector with a different layout than expected. · b06a134c
      Ross McIlroy authored
      If we flush the bytecode from a SFI we might recompile a JSFunction while the function
      still has its old feedback vector. This should usually be fine since the new and old
      feedback vectors have the same layout, however some bugs in the parser mean that it's
      possible for eagerly and lazily compiled eval functions to have different bytecode and
      so potentially different feedback vector layouts.
      
      For now reset the feedback vector if it doesn't have the same size when we compile the
      JSFunction, and recreate a new one of the correct layout. This will be replaced with a
      CHECK once the parser bugs are fixed.
      
      BUG=chromium:984344,v8:9511
      
      Change-Id: Ib8976f2541516f7a07e4d4ab7dc3c750dfe9b5d4
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1708474
      Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
      Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Auto-Submit: Ross McIlroy <rmcilroy@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62800}
      b06a134c
  22. 16 Jul, 2019 2 commits
  23. 12 Jul, 2019 1 commit
  24. 09 Jul, 2019 2 commits
  25. 08 Jul, 2019 1 commit
  26. 03 Jul, 2019 1 commit
  27. 01 Jul, 2019 1 commit
  28. 26 Jun, 2019 1 commit
  29. 24 Jun, 2019 1 commit
    • Mathias Bynens's avatar
      [objects] Rename JSValue to JSPrimitiveWrapper · e428dfd7
      Mathias Bynens authored
      We currently use the class name “JSValue” for JSObjects that wrap
      primitive values. This name is a common source of confusion. This patch
      switches to a name that’s more clear.
      
      In addition to manual tweaks, the patch applies the following mechanical
      global replacements:
      
      before                          | after
      --------------------------------|--------------------------------------
      if_valueisnotvalue              | if_valueisnotwrapper
      if_valueisvalue                 | if_valueiswrapper
      js_value                        | js_primitive_wrapper
      JS_VALUE_TYPE                   | JS_PRIMITIVE_WRAPPER_TYPE
      JSPrimitiveWrapperType          | JSPrimitiveWrapper type
      jsvalue                         | js_primitive_wrapper
      JSValue                         | JSPrimitiveWrapper
      _GENERATED_JSVALUE_FIELDS       | _GENERATED_JSPRIMITIVE_WRAPPER_FIELDS
      
      Change-Id: I9d9edea784eab6067b013e1f781e4db2070f807c
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1672942Reviewed-by: 's avatarTamer Tas <tmrts@chromium.org>
      Reviewed-by: 's avatarMichael Stanton <mvstanton@chromium.org>
      Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
      Commit-Queue: Mathias Bynens <mathias@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62337}
      e428dfd7
  30. 19 Jun, 2019 1 commit
  31. 13 Jun, 2019 1 commit
  32. 12 Jun, 2019 1 commit
    • Seth Brenith's avatar
      [torque] Stricter object field verification, part 1 · 3834c637
      Seth Brenith authored
      This change adjusts object initialization order for a few classes so
      that the GC can never see those objects in an invalid, partially-
      initialized state.
      
      AccessorInfo: Just zeros out a few fields upon construction. This is the
      simplest case.
      
      FunctionTemplateInfo: Slightly changes the order in which fields are
      set, so that the Smi field is set ahead of the call to SetCallHandler,
      which can GC. Also a pretty simple case.
      
      JSListFormat, JSPluralRules, JSRelativeTimeFormat, JSSegmenter: The spec
      requires that we start with OrdinaryCreateFromConstructor, which has
      observable side effects (it fetches the prototype from the new.target).
      So we split JSObject::New in half: the first half does all of the user-
      visible things and returns a Map, which we can pass to the second half
      when we're ready to actually allocate the object.
      
      JSTypedArray: Extends the pattern from JSListFormat into Torque code:
      start with a Map and don't allocate the object until we're ready to set
      all of its properties.
      
      Bug: v8:9311
      Change-Id: Id7703e8a0727ec756c774cfbb56af787658a111a
      Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1646844
      Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
      Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
      Reviewed-by: 's avatarSigurd Schneider <sigurds@chromium.org>
      Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
      Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
      Cr-Commit-Position: refs/heads/master@{#62123}
      3834c637
  33. 11 Jun, 2019 1 commit