Skip to content

V
V8
Switch branch/tag
  1. 10 May, 2021 1 commit
  3. 04 May, 2021 1 commit
    • Benedikt Meurer's avatar
      [liveedit] Reduce peak memory usage of text diffing. · 3fa681db
      Benedikt Meurer authored 
      The algorithm used to compute the textual differences uses requires
quadratic space (in the size of the input scripts). Previously the
implementation was naively allocating a single matrix, which is commonly
very sparse, since the expectation for LiveEdit is that only a small
portion of the script is actually altered. So we can use a std::map here
instead to reduce the cost.

We can also significantly reduce the cost (especially of the stack grow
due to the recursion) by precomputing the common prefix, and pre-filling
the table for the common suffix, both of which are also assumed to make
up for the majority of the script in case of LiveEdit.

This is still only ducktape, but should mitigate the crashes in the wild
significantly. Ideally we'd eventually replace this with an
implementation of the Myers algorithm that runs in linear space.

Fixed: chromium:1199807
Change-Id: Ib5fa0b1aa63c67631f919dc3b6641dfc0b20ae74
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2867470Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74344}
      3fa681db
  5. 30 Apr, 2021 1 commit
  7. 29 Apr, 2021 2 commits
    • Benedikt Meurer's avatar
      [debugger] Remove "Restart frame" feature. · 93f85699
      Benedikt Meurer authored 
      The "Restart frame" feature was implemented as part of LiveEdit and
primarily used to support LiveEdit of active functions, but that was
previously disabled as part of https://crrev.com/c/2846892 because it's
too brittle and causes crashes when using seemingly unrelated features.
The "Restart frame" feature was also available as a context menu item
separately in the DevTools front-end, but that was also already removed
as part of https://crrev.com/c/2854681 earlier. So all uses are gone
now.

This change works by marking Debugger.restartFrame as deprecated and
having it respond with a ServerError all the time. It thus allows us to
remove a whole bunch of machinery that was essentially just put in
various places to support the restart_fp_ magic. In particular the
debugger no longer needs any machine specific builtins now.

Bug: chromium:1195927
Change-Id: I1153ba6b00e979620af57dd9f58aa1c035ec4484
Fixed: chromium:1203606
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2854750Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74276}
      93f85699
    • Toon Verwaest's avatar
      [debug] Include Token::CLASS in class scopes and ContainsPosition · 00845abb
      Toon Verwaest authored 
      While evaluating a class literal the containing function points to
Token::CLASS. It may have pushed a context for that class that uses
the range of the class scope. So far the class scope had a range that
started after the class name or class token in case of anonymous
classes. That means the source position of the function frame doesn't
point to a position that is included in the active context range. This
breaks the debugger because it relies on being able to find the
matching parser scope for the active context by looking at the source
position.

The fix is two-fold:
- extend the class scope source range to include Token::CLASS
- update ScopeChainRetriever::ContainsPosition to include the start
  position of class scopes as a valid source position. We can't always
  include start due to arrow functions that don't have braces.

Bug: chromium:1156498
Change-Id: I9ec640c6326289dadcb154bb0a329ca6f8188f8b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2857957Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74268}
      00845abb
  9. 28 Apr, 2021 1 commit
    • Benedikt Meurer's avatar
      [debug] Disallow LiveEdit of active frames. · 53fc4807
      Benedikt Meurer authored 
      Previously we'd allow to replace the source of functions that are on the
current execution stack under certain conditions, but this has resulted
in an endless stream of bugs due to weird edge cases, and so we're now
limiting LiveEdit to functions that don't have any activation (including
not a suspended generator / async function activation).

We might eventually add the ability to LiveEdit functions with
activations and have them "upgrade upon next invocation", but that
doesn't seem to be an extremely important use case right now.

Fixed: chromium:1195927
Change-Id: I87a45ba4d0ddcfbf867bd4e73738d76b2d789e04
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2846892
Auto-Submit: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#74249}
      53fc4807
  11. 23 Apr, 2021 1 commit
  13. 19 Apr, 2021 1 commit
  15. 12 Apr, 2021 4 commits
  17. 09 Apr, 2021 3 commits
  19. 22 Mar, 2021 3 commits
  21. 16 Mar, 2021 1 commit
  23. 15 Mar, 2021 1 commit
    • Kim-Anh Tran's avatar
      [debugger] Consider close-by functions when setting a breakpoint · a7c8a3ea
      Kim-Anh Tran authored 
      This changes the behavior of SetBreakpointForScript to find more
accurate break positions.

Previously, setting a breakpoint would only consider the shared
function info that contained the requested position for setting a
breakpoint. More intuitively, a breakpoint should not necessarily
be set in a function that contains the position, but in the closest
breakable location that comes after the position we requested.

To achieve this we:
1. find the shared function info of the inner most function
that contains the requested_position.
This function's end position is used to find other shared function
infos in step 2.

2. search for all shared function infos that intersect with the
range [requested_position, inner_most_function.break_position[.

3. From the shared function infos extracted in 2, find the one
that has the closest breakable location to requested_position.

Also-By: bmeurer@chromium.org
Fixed: chromium:1137141
Change-Id: I4f4c6c3aac1ebea50cbcad9543b539ab1ded2b05
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742198
Commit-Queue: Kim-Anh Tran <kimanh@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73392}
      a7c8a3ea
  25. 11 Mar, 2021 3 commits
    • Clemens Backes's avatar
      Reland "[no-wasm] Exclude src/wasm from compilation" · 3f9ff062
      Clemens Backes authored 
      This is a reland of 80f5dfda. A condition
in pipeline.cc was inverted, which lead to a CSA verifier error.

Original change's description:
> [no-wasm] Exclude src/wasm from compilation
>
> This is the biggest chunk, including
> - all of src/wasm,
> - torque file for wasm objects,
> - torque file for wasm builtins,
> - wasm builtins,
> - wasm runtime functions,
> - int64 lowering,
> - simd scala lowering,
> - WasmGraphBuilder (TF graph construction for wasm),
> - wasm frame types,
> - wasm interrupts,
> - the JSWasmCall opcode,
> - wasm backing store allocation.
>
> Those components are all recursively entangled, so I found no way to
> split this change up further.
>
> Some includes that were recursively included by wasm headers needed to
> be added explicitly now.
>
> backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc
> because it only tests wasm backing stores. This file is excluded from
> no-wasm builds then.
>
> R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org
>
> Bug: v8:11238
> Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b
> Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73344}

TBR=jgruber@chromium.org

Bug: v8:11238
Change-Id: I20bd2847a59c68738b5a336cd42582b7b1499585
Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
Cq-Include-Trybots: luci.v8.try:v8_linux_verify_csa_rel_ng
Cq-Include-Trybots: luci.v8.try:v8_linux64_verify_csa_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752867Reviewed-by: 's avatarClemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73348}
      3f9ff062
    • Clemens Backes's avatar
      Revert "[no-wasm] Exclude src/wasm from compilation" · 92bc3d38
      Clemens Backes authored 
      This reverts commit 80f5dfda.

Reason for revert: Fails CSA verification: https://ci.chromium.org/ui/p/v8/builders/ci/V8%20Linux%20-%20verify%20csa/21766/overview

Original change's description:
> [no-wasm] Exclude src/wasm from compilation
>
> This is the biggest chunk, including
> - all of src/wasm,
> - torque file for wasm objects,
> - torque file for wasm builtins,
> - wasm builtins,
> - wasm runtime functions,
> - int64 lowering,
> - simd scala lowering,
> - WasmGraphBuilder (TF graph construction for wasm),
> - wasm frame types,
> - wasm interrupts,
> - the JSWasmCall opcode,
> - wasm backing store allocation.
>
> Those components are all recursively entangled, so I found no way to
> split this change up further.
>
> Some includes that were recursively included by wasm headers needed to
> be added explicitly now.
>
> backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc
> because it only tests wasm backing stores. This file is excluded from
> no-wasm builds then.
>
> R=​jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org
>
> Bug: v8:11238
> Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b
> Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955
> Commit-Queue: Clemens Backes <clemensb@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#73344}

Bug: v8:11238
Change-Id: I93672002c1faa36bb0bb5b4a9cc2032ee2ccd814
Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2752866
Auto-Submit: Clemens Backes <clemensb@chromium.org>
Commit-Queue: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#73346}
      92bc3d38
    • Clemens Backes's avatar
      [no-wasm] Exclude src/wasm from compilation · 80f5dfda
      Clemens Backes authored 
      This is the biggest chunk, including
- all of src/wasm,
- torque file for wasm objects,
- torque file for wasm builtins,
- wasm builtins,
- wasm runtime functions,
- int64 lowering,
- simd scala lowering,
- WasmGraphBuilder (TF graph construction for wasm),
- wasm frame types,
- wasm interrupts,
- the JSWasmCall opcode,
- wasm backing store allocation.

Those components are all recursively entangled, so I found no way to
split this change up further.

Some includes that were recursively included by wasm headers needed to
be added explicitly now.

backing-store-unittest.cc is renamed to wasm-backing-store-unittest.cc
because it only tests wasm backing stores. This file is excluded from
no-wasm builds then.

R=jkummerow@chromium.org, jgruber@chromium.org, mlippautz@chromium.org, petermarshall@chromium.org

Bug: v8:11238
Change-Id: I7558f2d12d2dd6c65128c4de7b79173668c80b2b
Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2742955
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: 's avatarPeter Marshall <petermarshall@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarMichael Lippautz <mlippautz@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarJakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73344}
      80f5dfda
  27. 10 Mar, 2021 1 commit
  29. 08 Mar, 2021 2 commits
  31. 05 Mar, 2021 1 commit
  33. 03 Mar, 2021 2 commits
    • Benedikt Meurer's avatar
      [debug] Instantiate accessors only once. · e9873bf1
      Benedikt Meurer authored 
      When retrieving an API accessor function (i.e. either the getter or the
setter) for which the lazy accessor mechanism is used (i.e. where the
actual JSFunction is created lazily and only the FunctionTemplateInfo)
is around, we thus far created a fresh JSFunction every time the
accessor function is requested, but that's observably wrong behavior,
since the accessors are JavaScript objects with identity. We currently
rely on the instantiation cache to guarantee identity, but there's no
reason why we couldn't instead just put the instantiated JSFunction into
the AccessorPair.

Fixing this to only instantiate the lazy accessor pair only once, upon
first time it's requested, coincidentally also simplifies (and fixes)
the API accessor breakpoint machinery. This was previously lacking
support for walking dictionary prototype objects and forcibly
instantiating the lazy accessor pairs with break points. However, all
this magic in the debugger is no longer necessary when we ensure that
the lazy accessor pair component is generally only instantiated once.

Bug: v8:178, v8:7596, chromium:986063, chromium:496666
Change-Id: I41d28378010716c96c8ecf7c3f1247765f8bc669
Fixed: chromium:1163547
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2731527Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73163}
      e9873bf1
    • Seth Brenith's avatar
      Privatize FixedArray-style accessors on ScopeInfo · 3a366c4d
      Seth Brenith authored 
      This is a partial reland of https://crrev.com/c/2601880 .

In preparation for ScopeInfo not being a FixedArrayBase, this change
privatizes the FixedArray-style functions that provide access to
ScopeInfo fields by index, and moves them from scope-info-inl.h to
scope-info.cc. Those functions are still used pretty heavily during
initialization (ScopeInfo::Create, etc.), but at least we can avoid
presenting them to the rest of the world.

This change also introduces a new length() function in ScopeInfo which
hides the one inherited from FixedArrayBase and computes the ScopeInfo's
length based on its flags, so that there are no remaining readers of the
'length' field.

Change-Id: I609754010723b679e5cf00f386020faaab84c17a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2718275
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: 's avatarToon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73151}
      3a366c4d
  35. 02 Mar, 2021 2 commits
    • Clemens Backes's avatar
      [no-wasm] Remove wasm debugging support · 8890bb21
      Clemens Backes authored 
      This removes all wasm includes from src/debug and src/inspector if
webassembly is disabled (v8_enable_webassembly=false). It also removes
the definition of {WasmValueObject} and {v8::debug::WasmScript}.
This will allow to later fully exclude the src/wasm directory from
compilation (once other components are fixed).

R=bmeurer@chromium.org, machenbach@chromium.org

Bug: v8:11238
Change-Id: I41a1d83d01fbb6c015cdfd6cc063bad90052505d
Cq-Include-Trybots: luci.v8.try:v8_linux64_no_wasm_compile_rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2726506Reviewed-by: 's avatarMichael Achenbach <machenbach@chromium.org>
Reviewed-by: 's avatarBenedikt Meurer <bmeurer@chromium.org>
Reviewed-by: 's avatarJakob Kummerow <jkummerow@chromium.org>
Reviewed-by: 's avatarMaya Lekova <mslekova@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73138}
      8890bb21
    • Benedikt Meurer's avatar
      [debug] Don't put a source position on internal `Return`s. · 06359f74
      Benedikt Meurer authored 
      Be explicit about source positions for `Return`s in the
BytecodeGenerator, and only do self-healing explicitly in the
`ReturnStatement` translation, where an end position of
`kNoSourcePosition` is turned into the return position of the
function literal.

This allows us to reason more easily about which `Return`s actually
receive a meaningful source position, and in particular it allows us
to construct the internal `Return`s for `yield` and `yield*` with no
source position attached to them. Previously they'd get the source
position for the implicit (final) return attached to it, which confused
the debugger and led to breakpoints being set in the completely wrong
spot.

Considering the simplified example

```
function* foo(){
  var a = 1;
}
```

this would previously generate the following bytecode

```
        0 : SwitchOnGeneratorState r0, [0], [1] { 0: @20 }
        4 : Mov <closure>, r2
        7 : Mov <this>, r3
 13 E> 10 : InvokeIntrinsic [_CreateJSGeneratorObject], r2-r3
       14 : Star0
 13 E> 15 : SuspendGenerator r0, r0-r1, [0]
       20 : ResumeGenerator r0, r0-r1
       24 : Star2
       25 : InvokeIntrinsic [_GeneratorGetResumeMode], r0-r0
       29 : SwitchOnSmiNoFeedback [1], [2], [0] { 0: @39, 1: @36 }
       33 : Ldar r2
 13 E> 35 : Throw
       36 : Ldar r2
 30 S> 38 : Return    <=========================== internal Return
 27 S> 39 : LdaSmi [1]
       41 : Star1
       42 : LdaUndefined
 30 S> 43 : Return
```

where everything between offset 4 and 42 corresponds to the implicit
yield at the beginning of every generator function, in particular the
code between 20 and 42 corresponds to that initial yields resumption
logic. Notice how the internal Return at offset 38 gets assigned the
source position of the function literal (the same as the implicit
return at the end). This confuses the debugger quite a bit when trying
to set a breakpoint on the closing brace, since it's going in bytecode
order and will thus discover the `Return` at offset 38 first (matching
the source position 30 it's currently looking for) and setting the
breakpoint there. This `Return` bytecode however is only executed when
the generator is resumed via `GeneratorPrototype.return()`, and it'll
not hit when the developer uses the generator normally, which is not
the desired behavior and extremely confusing (especially since stepping
on the other hand works as expected).

With this patch, we no longer slap a source position (and in particular
not the function literal's return position) onto these internal
`Return`s as you can see from the generated bytecode below:

```
       0 : SwitchOnGeneratorState r0, [0], [1] { 0: @20 }
       4 : Mov <closure>, r2
       7 : Mov <this>, r3
13 E> 10 : InvokeIntrinsic [_CreateJSGeneratorObject], r2-r3
      14 : Star0
13 E> 15 : SuspendGenerator r0, r0-r1, [0]
      20 : ResumeGenerator r0, r0-r1
      24 : Star2
      25 : InvokeIntrinsic [_GeneratorGetResumeMode], r0-r0
      29 : SwitchOnSmiNoFeedback [1], [2], [0] { 0: @39, 1: @36 }
      33 : Ldar r2
13 E> 35 : Throw
      36 : Ldar r2
      38 : Return
27 S> 39 : LdaSmi [1]
      41 : Star1
      42 : LdaUndefined
30 S> 43 : Return
```

This also allows us to remove the break position finding hack that was
kept in BreakIterator::BreakIndexFromPosition() for generators and
modules.

Fixed: chromium:901819
Change-Id: If19a6b26e2622d49b6b5e54bf7a162747543f970
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2727820Reviewed-by: 's avatarYang Guo <yangguo@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#73119}
      06359f74
  37. 25 Feb, 2021 1 commit
  39. 24 Feb, 2021 2 commits
  41. 23 Feb, 2021 1 commit
  43. 22 Feb, 2021 1 commit
  45. 20 Feb, 2021 1 commit
  47. 19 Feb, 2021 2 commits
    • Mike Stanton's avatar
      [TurboFan] Mark Code object as never serialized · be699045
      Mike Stanton authored 
      Code objects are exposed through JSFunction and SharedFunctionInfo.
If they are builtins, we don't have to worry about background threads
seeing partially initialized code objects. If they are optimized code
objects, we may. Background threads read the code fields with
AcquireLoad semantics. The fields are set on the main thread with
ReleaseStore semantics when appropriate.

Special care is taken when setting an optimized code object in a closure
in the interpreter entry stub. Since the MacroAssembler doesn't support
ReleaseStore semantics, this CL ensures that the optimized code object
is stored with those semantics in the feedback vector, where the
interpreter entry stub finds it.

Bug: v8:7790
Change-Id: I41ecedfe0e9d1ad5091cbe9a97f66c66ca9e07dd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2676633
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: 's avatarUlan Degenbaev <ulan@chromium.org>
Reviewed-by: 's avatarSantiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: 's avatarLeszek Swirski <leszeks@chromium.org>
Reviewed-by: 's avatarGeorg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72869}
      be699045
    • Seth Brenith's avatar
      Revert "Remove 'length' field from ScopeInfo" · 6c922e39
      Seth Brenith authored 
      This reverts commit f731e13f.

Reason for revert: perf regressions, chromium:1179757

Original change's description:
> Remove 'length' field from ScopeInfo
>
> ScopeInfo has a vestigial 'length' field from when it used to be a
> FixedArray. This change removes that field, which saves some memory.
>
> More specifically:
>
> - Make ScopeInfo inherit from HeapObject, not FixedArrayBase which
>   supplied the 'length' field.
> - Privatize the FixedArray-style functions that provide access to
>   ScopeInfo fields by index, and move them from scope-info-inl.h to
>   scope-info.cc. Those functions are still used pretty heavily during
>   initialization (ScopeInfo::Create, etc.), but at least we can avoid
>   presenting them to the rest of the world.
> - Change FactoryBase::NewScopeInfo to allocate the updated object shape.
>   It maintains the existing behavior of filling the newly-allocated
>   object with undefined, even though that's not a valid ScopeInfo and
>   further initialization is required.
> - Move part of AccessorAssembler::ScriptContextTableLookup into a new
>   Torque macro, because it used to rely on casting ScopeInfo to
>   FixedArrayBase.
> - In V8HeapExplorer::AddEntry, don't claim that ScopeInfo objects are
>   arrays. I think it makes more sense to list them under "(system)" in
>   the dev tools, like most other V8 internal types.
>
> Bug: v8:8952
> Change-Id: I8278e3a90027d4409f0d268da0fe7080754c6b8c
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2601880
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
> Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
> Reviewed-by: Mythri Alle <mythria@chromium.org>
> Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#72830}

Bug: v8:8952
Change-Id: I00a69da79e5ac6aaae4436a41ce773ae014cc775
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2706086
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Seth Brenith <seth.brenith@microsoft.com>
Commit-Queue: Nico Hartmann <nicohartmann@chromium.org>
Reviewed-by: 's avatarNico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#72855}
      6c922e39
  49. 18 Feb, 2021 1 commit