Skip to content

V
V8
Switch branch/tag
  1. 14 Feb, 2022 1 commit
    • Victor Gomes's avatar
      Reland "[runtime] Refactor TransitionsAccessor" · 24ff6e28
      Victor Gomes authored 
      This is a reland of c927ada7

Fix: Recalculate encoding after an allocation (that can potentially
trigger GC) in EnsureHasFullTransitionArray.

Original change's description:
> [runtime] Refactor TransitionsAccessor
>
> Problems:
> - The class uses a bare Map field, but some methods can trigger GC
> causing it to have a potential dangling pointer in case of map
> compaction.
> - Some methods invalidate the object state and should not be used again.
> - Complicate logic with a no_gc and a gc aware constructors. Some
> methods can only be called if the object is constructed with a
> particular constructor (e.g, Insert and PutPrototypeTransition).
>
> Note: Most usages of this class is done by constructing an object and
> calling a single method:
> `TransitionAccessor(...).Method(...)`
> So we can easily change them to a static method.
>
> This CL:
> 1. Adds DISALLOW_GARBAGE_COLLECTION to the class.
> 2. Makes methods that can trigger GC static.
> 3. Creates static helper functions that wrap the class in a different
> scope, since TransitionsAccessor now forces the scope to disallow gc.
> 4. Removes now unnecessary "Reload" logic.
>
> Bug: chromium:1295133, v8:12578
> Change-Id: I85484e7235fbd5e69894e26f5e1c491c6f69635e
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3450416
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Victor Gomes <victorgomes@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#79051}

Bug: chromium:1295133, v8:12578
Change-Id: If3880c2480433b78567870c8d14508d6ad9eccbd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3460405Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79069}
      24ff6e28
  3. 11 Feb, 2022 2 commits
    • Deepti Gandluri's avatar
      Revert "[runtime] Refactor TransitionsAccessor" · 7c602011
      Deepti Gandluri authored 
      This reverts commit c927ada7.

Reason for revert: GC stress failures: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20gc%20stress/37276/overview

Original change's description:
> [runtime] Refactor TransitionsAccessor
>
> Problems:
> - The class uses a bare Map field, but some methods can trigger GC
> causing it to have a potential dangling pointer in case of map
> compaction.
> - Some methods invalidate the object state and should not be used again.
> - Complicate logic with a no_gc and a gc aware constructors. Some
> methods can only be called if the object is constructed with a
> particular constructor (e.g, Insert and PutPrototypeTransition).
>
> Note: Most usages of this class is done by constructing an object and
> calling a single method:
> `TransitionAccessor(...).Method(...)`
> So we can easily change them to a static method.
>
> This CL:
> 1. Adds DISALLOW_GARBAGE_COLLECTION to the class.
> 2. Makes methods that can trigger GC static.
> 3. Creates static helper functions that wrap the class in a different
> scope, since TransitionsAccessor now forces the scope to disallow gc.
> 4. Removes now unnecessary "Reload" logic.
>
> Bug: chromium:1295133, v8:12578
> Change-Id: I85484e7235fbd5e69894e26f5e1c491c6f69635e
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3450416
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Commit-Queue: Victor Gomes <victorgomes@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#79051}

Bug: chromium:1295133, v8:12578
Change-Id: Ia567cdcae73bc7fdfaf08b62eeeb899d6a933e21
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3456682
Auto-Submit: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Owners-Override: Deepti Gandluri <gdeepti@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79052}
      7c602011
    • Victor Gomes's avatar
      [runtime] Refactor TransitionsAccessor · c927ada7
      Victor Gomes authored 
      Problems:
- The class uses a bare Map field, but some methods can trigger GC
causing it to have a potential dangling pointer in case of map
compaction.
- Some methods invalidate the object state and should not be used again.
- Complicate logic with a no_gc and a gc aware constructors. Some
methods can only be called if the object is constructed with a
particular constructor (e.g, Insert and PutPrototypeTransition).

Note: Most usages of this class is done by constructing an object and
calling a single method:
`TransitionAccessor(...).Method(...)`
So we can easily change them to a static method.

This CL:
1. Adds DISALLOW_GARBAGE_COLLECTION to the class.
2. Makes methods that can trigger GC static.
3. Creates static helper functions that wrap the class in a different
scope, since TransitionsAccessor now forces the scope to disallow gc.
4. Removes now unnecessary "Reload" logic.

Bug: chromium:1295133, v8:12578
Change-Id: I85484e7235fbd5e69894e26f5e1c491c6f69635e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3450416Reviewed-by: 's avatarDominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79051}
      c927ada7
  5. 07 Feb, 2022 1 commit
    • Dominik Inführ's avatar
      [json, parsing] Switch to internal GC callbacks · becce45b
      Dominik Inführ authored 
      We have two different kinds of GC prologues/epilogues. The user-exposed
one in Heap and the internal one in LocalHeap. During parsing and in
the JSON parser we were using the former. While this is definitely
correct and at the time of implementation it was the only existing
mechanism, I believe the internal callbacks are now a better fit for
these use cases.

Internal callbacks are simpler since they don't allow allocations, which
allows us to run them during the GC safepoint. The user-exposed
interfaces are allowed to allocate and are run either before or after
the safepoint. Such allocations could cause recursive GCs, which is
impossible for internal callbacks.

Bug: v8:12545
Change-Id: Ie697556cec9aa77b2f70704445aa5bd58e0a381a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3435188Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#78971}
      becce45b
  7. 05 Feb, 2022 2 commits
  9. 09 Dec, 2021 1 commit
  11. 08 Dec, 2021 2 commits
  13. 01 Dec, 2021 1 commit
  15. 15 Nov, 2021 1 commit
  17. 11 Nov, 2021 1 commit
  19. 10 Nov, 2021 1 commit
  21. 08 Nov, 2021 1 commit
  23. 05 Nov, 2021 1 commit
    • Camillo Bruni's avatar
      Reland "[runtime] Optimise paired instance type checks" · ed0a8599
      Camillo Bruni authored 
      This is a reland of 92edf9a1

Introduce map handle again to prevent corruption.

Drive-by-fix:
Make some PropertyDetails and Representation methods constexpr.

Original change's description:
> [runtime] Optimise paired instance type checks
>
> Clang doesn't optimise over handle derefs. Change the ValueSerializer
> and the JsonStringifier to use InstanceType directly for checks.
> This CL squeezes another 1.5% of JSON.stringify in local benchmarks.
>
> Drive-by-fix:
> - Avoid a few more derefs in the JsonStringifier
> - Make JsonStringifier::SerializeJSArray a bit more readable
>
> Change-Id: I37626a6d92a8d9275611a4e6d1d908f2e0c6d43b
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3247637
> Commit-Queue: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#77697}

Change-Id: I8915a82aab6dd7966223a4d7a8dd1363258b7c81
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3260512
Commit-Queue: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarIgor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/main@{#77735}
      ed0a8599
  25. 04 Nov, 2021 2 commits
  27. 13 Oct, 2021 1 commit
  29. 28 Sep, 2021 1 commit
  31. 20 Sep, 2021 1 commit
  33. 15 Sep, 2021 1 commit
  35. 24 Aug, 2021 1 commit
    • Dan Elphick's avatar
      Reland "[include] Split out v8.h" · ec06bb6c
      Dan Elphick authored 
      This is a reland of d1b27019

Fixes include:
Adding missing file to bazel build
Forward-declaring classing before friend-classing them to fix win/gcc
Add missing v8-isolate.h include for vtune builds

Original change's description:
> [include] Split out v8.h
>
> This moves every single class/function out of include/v8.h into a
> separate header in include/, which v8.h then includes so that
> externally nothing appears to have changed.
>
> Every include of v8.h from inside v8 has been changed to a more
> fine-grained include.
>
> Previously inline functions defined at the bottom of v8.h would call
> private non-inline functions in the V8 class. Since that class is now
> in v8-initialization.h and is rarely included (as that would create
> dependency cycles), this is not possible and so those methods have been
> moved out of the V8 class into the namespace v8::api_internal.
>
> None of the previous files in include/ now #include v8.h, which means
> if embedders were relying on this transitive dependency then it will
> give compile failures.
>
> v8-inspector.h does depend on v8-scripts.h for the time being to ensure
> that Chrome continue to compile but that change will be reverted once
> those transitive #includes in chrome are changed to include it directly.
>
> Full design:
> https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing
>
> Bug: v8:11965
> Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Dan Elphick <delphick@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76424}

Cq-Include-Trybots: luci.v8.try:v8_linux_vtunejit
Bug: v8:11965
Change-Id: I99f5d3a73bf8fe25b650adfaf9567dc4e44a09e6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113629Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarSimon Zünd <szuend@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76460}
      ec06bb6c
  37. 23 Aug, 2021 2 commits
    • Dan Elphick's avatar
      Revert "[include] Split out v8.h" · 44fe02ce
      Dan Elphick authored 
      This reverts commit d1b27019.

Reason for revert: Broke vtune build, tsan build and possibly others

Original change's description:
> [include] Split out v8.h
>
> This moves every single class/function out of include/v8.h into a
> separate header in include/, which v8.h then includes so that
> externally nothing appears to have changed.
>
> Every include of v8.h from inside v8 has been changed to a more
> fine-grained include.
>
> Previously inline functions defined at the bottom of v8.h would call
> private non-inline functions in the V8 class. Since that class is now
> in v8-initialization.h and is rarely included (as that would create
> dependency cycles), this is not possible and so those methods have been
> moved out of the V8 class into the namespace v8::api_internal.
>
> None of the previous files in include/ now #include v8.h, which means
> if embedders were relying on this transitive dependency then it will
> give compile failures.
>
> v8-inspector.h does depend on v8-scripts.h for the time being to ensure
> that Chrome continue to compile but that change will be reverted once
> those transitive #includes in chrome are changed to include it directly.
>
> Full design:
> https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing
>
> Bug: v8:11965
> Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Reviewed-by: Camillo Bruni <cbruni@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Dan Elphick <delphick@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#76424}

Bug: v8:11965
Change-Id: Id57313ae992e720c8b19abc975cd69729e1344aa
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3113627
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Owners-Override: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76428}
      44fe02ce
    • Dan Elphick's avatar
      [include] Split out v8.h · d1b27019
      Dan Elphick authored 
      This moves every single class/function out of include/v8.h into a
separate header in include/, which v8.h then includes so that
externally nothing appears to have changed.

Every include of v8.h from inside v8 has been changed to a more
fine-grained include.

Previously inline functions defined at the bottom of v8.h would call
private non-inline functions in the V8 class. Since that class is now
in v8-initialization.h and is rarely included (as that would create
dependency cycles), this is not possible and so those methods have been
moved out of the V8 class into the namespace v8::api_internal.

None of the previous files in include/ now #include v8.h, which means
if embedders were relying on this transitive dependency then it will
give compile failures.

v8-inspector.h does depend on v8-scripts.h for the time being to ensure
that Chrome continue to compile but that change will be reverted once
those transitive #includes in chrome are changed to include it directly.

Full design:
https://docs.google.com/document/d/1rTD--I8hCAr-Rho1WTumZzFKaDpEp0IJ8ejZtk4nJdA/edit?usp=sharing

Bug: v8:11965
Change-Id: I53b84b29581632710edc80eb11f819c2097a2877
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3097448Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarCamillo Bruni <cbruni@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Commit-Queue: Dan Elphick <delphick@chromium.org>
Cr-Commit-Position: refs/heads/main@{#76424}
      d1b27019
  39. 06 Jul, 2021 2 commits
    • Mike Stanton's avatar
      [compiler] TSAN data race on HeapNumber::value_as_bits() · 6a1063c8
      Mike Stanton authored 
      TurboFan reads the value in HeapNumber, and TSAN detects a data
race between this read and sets on the main thread elsewhere.
We mark this as relaxed atomic (meaning, correct value of the read
is not guaranteed). The compiler uses the dependency mechanism
to re-read the value safely on the main thread later, and aborts
compilation if a change is detected.

Bug: chromium:1224277, v8:7790
Change-Id: I8931d8989812550c0c57b6bd27aa796f6f5e779d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2996201Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarAndreas Haas <ahaas@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75586}
      6a1063c8
    • Dominik Inführ's avatar
      [heap] Support transitioning of code objects · d1f2a83b
      Dominik Inführ authored 
      This CL adds support for updating code objects. So far code objects
were immutable. Sparkplug makes compilation a very frequent operation
and thus wants to avoid copying the instruction stream from the
AssemblerBuffer into the code object (with more overhead that entails).
The idea is to allocate an "empty" Code object initially, which is
likely large enough to hold the full instruction stream. Then Sparkplug
will compile the given function and write the instruction stream
directly into the code object. After compilation is done Sparkplug trims
the Code to the right size and finishes its initialization.

We use relocation_info to determine whether a Code object is fully
initialized: undefined means that this object is filled by SparkPlug
at the moment. If it's a proper ByteArray, this code object is assumed
to be initialized. Turbofan still fully initializes the Code object
immediately.

Before changing the size of the code object, EnsureSweepingCompleted()
makes sure that the code object's page is swept already. This prevents
that the concurrent sweeper loads the new and smaller object size and
stores that memory in the free list.

NotifyCodeObjectChanged() signals the GC that the code object is now
fully initialized and revisits that object (even if it is black already)
to find and record outgoing references in the instruction stream.

Design doc: https://docs.google.com/document/d/12LHGkRXY1H3IFMBrdxs2vhgtG9bfJTdquQUsX1oPoSE/edit?usp=sharing

Bug: v8:11872
Change-Id: Ie1b95b27842eea5ec7e9d345052585a27d6ea7f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2999087
Commit-Queue: Dominik Inführ <dinfuehr@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75582}
      d1f2a83b
  41. 24 Jun, 2021 3 commits
  43. 18 Jun, 2021 1 commit
  45. 07 Jun, 2021 1 commit
  47. 31 May, 2021 1 commit
  49. 17 May, 2021 1 commit
  51. 08 Apr, 2021 1 commit
  53. 12 Mar, 2021 1 commit
  55. 08 Mar, 2021 1 commit
  57. 11 Feb, 2021 1 commit
  59. 26 Nov, 2020 1 commit
  61. 24 Nov, 2020 2 commits