.. as part of the big Code/CodeDataContainer name shuffle. In the
next step, CodeDataContainer will be renamed to Code.
Bug: v8:13654
Change-Id: Ia80ac984d46dd6c2a108098055a5cd60e22a837c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4171628
Auto-Submit: Jakob Linke <jgruber@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/main@{#85337}
This ensures that V8_EXPORT lines generated by
gen-postmortem-metadata.py have a deterministic order (the original
order) while removing duplicates.
Bug: chromium:1394626
Change-Id: I6d634962ed9f9f97c2b0dfa3b6d9c32b5894df54
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/4061864
Reviewed-by: Liviu Rau <liviurau@chromium.org>
Reviewed-by: Victor Gomes <victorgomes@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#84568}
A BoundedSize is just a regular size_t when the sandbox is disabled.
However, when the sandbox is enabled, a BoundedLength is guaranteed to
be in the range [0, kMaxSafeBufferSizeForSandbox]. This is (currently)
achieved by storing the length shifted to the left, then right-shifting
it when loading it. This guarantees that the top bits are zero.
BoundedSizes are used to ensure safe access to variable-sized buffers,
in particular ArrayBuffers and their views, located inside the sandbox.
If a full size_t is used to represent their size, it may allow an
attacker to "reach out of" the sandbox address space by setting the
length to a very large value. A BoundedSize prevents this.
Bug: chromium:1360375
Change-Id: I0579693db528af96c41eeaa64bd3ed71266aacd9
Cq-Include-Trybots: luci.v8.try.triggered:v8_linux64_no_sandbox_dbg_ng_triggered
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3876823
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Samuel Groß <saelo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#83631}
The infrastructure runs everything already in Python3, so this is
mostly a clean-up.
For MB, a python2 holdover was removed and new lint errors were
fixed.
The renames were automated with:
git grep -e "/usr/bin/python$" |
cut -d':' -f1 |
xargs
sed -i 's/#!\/usr\/bin\/python$/#!\/usr\/bin\/python3/1'
and
git grep -e "/usr/bin/env python$" |
cut -d':' -f1 |
xargs
sed -i 's/#!\/usr\/bin\/env python$/#!\/usr\/bin\/env python3/1'
Bug: v8:13148
Change-Id: If4f3c7635e72fa134798d55314ac1aa92ddd01bf
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3811499
Reviewed-by: Liviu Rau <liviurau@google.com>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/main@{#82231}
The generated code checks if the receiver is a JS_API_OBJECT and if the
receiver requires an access check, and if not it lowers the call to an
API call.
We also add compilation dependencies on the protector cell to deopt if
our invariants change. (Note - the actual invalidation of these cells
will be implemented in a follow up CL)
Bug: v8:11321
Change-Id: I15722f1e5fac7176e292da4a35186e4609636aba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2719563
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#80748}
Store the free registers as a RegList rather than stack of Register
values. This allows us to simplify some of the register freeing logic,
including passing the current free set to nodes for use as temporaries.
Drive-by: Replace ALWAYS_ALLOCATABLE_GENERAL_REGISTERS with
ALLOCATABLE_GENERAL_REGISTERS, which is the more general list (the former
is an implementation detail for optionally reserving a register for
the cage register).
Bug: v8:7700
Change-Id: I666e9a7547c2f4f4e578fbcbb4bd3fe3cb06dac5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3497767
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/main@{#79344}
Bug: v8:12092
Change-Id: Ibca6082c28cfd5b23680d554b692bc8ab60cb416
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3094013
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#76300}
I've noticed a few places where class fields as defined in Torque have
different names than the corresponding accessors in the C++ class. I
think they should match. Most of this change is just mechanically
updating the various places that use k##Field##Offset for those fields.
Change-Id: I8ba52aed7f6a1cd6b2d71158f71150b66c2c0da0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/3027263
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#75796}
This commit updates the gen-postmortem-metadaa.py script to
incorporate changes in V8 8.5. This removes the need to float a
patch to the script in Node.js.
Change-Id: I6532495bee906f51eb2b773ec38ff0a6e404dafe
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2582705
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#71699}
This commit updates the gen-postmortem-metadata.py script to
incorporate changes in V8 8.4. This removes the need to float a
patch to the script in Node.js.
Change-Id: I69da40e792f22748b0eee2952b9009b2f03d13f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2565275
Reviewed-by: Joyee Cheung <joyee@igalia.com>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#71646}
Extend gen-postmortem-metadata.py with selected register values.
This information is not present in DWARF debuginfo. Exposing it
enables detailed analysis of V8 JS execution by observing binary-level
execution:
https://robert.ocallahan.org/2020/05/omniscient-js-debugging-in-pernosco.html
Bug: v8:11106
Change-Id: I3bde7dd07ac5ba6ff00d4a5fa9b635871507a866
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2518957
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#71035}
Bug: v8:7790
Change-Id: I1ffb2289f613a03d0246db2d66c3caaf0e4d6d2a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2448796
Auto-Submit: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Nico Hartmann <nicohartmann@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70406}
... so that they match the corresponding DECL_* macros.
Change-Id: Idb26901eeb1219945a1e701dd7c28a58ce978bf9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2449977
Reviewed-by: Santiago Aboy Solanes <solanes@chromium.org>
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Auto-Submit: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#70322}
We can use existing macros to define this getter/setter rather than hand
writing it -- as a side effect this ends up defining an Isolate overload
of the getter which was otherwise missing.
Bug: v8:10506
Change-Id: I0bc5a3082b5ed0416c8099a94e7d2e32a2bd363f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2199350
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#67798}
Improve postmortem metadata generated by gen-postmortem-metadata by also
including weak and synchronous accessors, as well as CHECKED and
CHECKED2 variants of all accessors currently considered by
gen-postmortem-metadata. Also improve type collection by parsing
TORQUE_INSTANCE_CHECKERS_SINGLE_FULLY_DEFINED, as we were missing
several types with the previous heuristic (like StackTraceFrame,
PromiseReaction, and many others). This will include 96 new v8dbg
constants which can be used by debuggers like llnode.
R=hpayer@google.com, verwaest@google.com, victorgomes@google.com
Change-Id: Ia9bea21eec38b92d255c3636c6a284eb27e9ed9b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/2056126
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#66551}
This change moves the definitions of the bitfield flags used by Symbol
and Map to Torque. Symbol could directly follow the pattern established
by SharedFunctionInfo, but Map required some other changes:
- Until now, Torque bitfield definitions have required unsigned types. I
thought that this would be the least-surprising behavior, since we
never sign-extend when decoding bitfield values. However, I believe
that the amount of churn involved in making ElementsKind be unsigned
outweighs the benefit we were getting from this restriction (and
similar difficulties are likely to arise in converting other bitfield
structs to Torque), so this CL updates Torque to allow signed bitfield
values.
- If we try to make Map extend from all of the generated classes that
define its flags, we end up with class sizing problems because some
compilers only apply empty base class optimization to the first in a
row of empty base classes. We could work around this issue by
generating macros instead of classes, but I took this as an
opportunity for a minor clean-up instead: rather than having bitfield
definitions for several different bitfield structs all jumbled
together in Map, they can be split up. I think this makes the code a
little easier to follow, but if others disagree I'm happy to implement
macro generation instead.
Change-Id: Ibf339b0be97f72d740bf1daa8300b471912faeba
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1988934
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#65701}
This class used to describe unoptimized but compiled frames. All such
frames are by now covered via the architecture-independent description
in the {StandardFrameConstants} class (or one of its subclasses).
R=clemensb@chromium.org
BUG=v8:9810
Change-Id: I294cc6eec7d4a05e88e7aa336f1ebedfa0eb6e98
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1878708
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64556}
Original change's description:
> [runtime] Remove extension slots from context objects
>
> Context objects have an extension slot, which contains further
> additional data that depends on the type of the context.
>
> This CL removes the extension slot from contexts that don't need
> them, hence reducing memory.
>
> The following contexts will still have an extension slot: native,
> module, await, block and with contexts. See objects/contexts.h for
> what the slot is used for.
> The following contexts will not have an extension slot anymore (they
> were not used before): script, catch and builtin contexts.
> Eval and function contexts only have the extension slot if they
> contain a sloppy eval.
>
> Bug: v8:9744
> Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191
> Commit-Queue: Victor Gomes <victorgomes@google.com>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Auto-Submit: Victor Gomes <victorgomes@google.com>
> Cr-Commit-Position: refs/heads/master@{#64372}
TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org
Bug: v8:9744
Change-Id: I8700ed2fa62c89e86c39bb16ac3167f38ea8d63f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1873695
Commit-Queue: Victor Gomes <victorgomes@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64477}
This is a reland of c48096d442
Original change's description:
> Reland "[runtime] Remove extension slots from context objects"
>
> This is a reland of c07c02e1c4
>
> Original change's description:
> > [runtime] Remove extension slots from context objects
> >
> > Context objects have an extension slot, which contains further
> > additional data that depends on the type of the context.
> >
> > This CL removes the extension slot from contexts that don't need
> > them, hence reducing memory.
> >
> > The following contexts will still have an extension slot: native,
> > module, await, block and with contexts. See objects/contexts.h for
> > what the slot is used for.
> > The following contexts will not have an extension slot anymore (they
> > were not used before): script, catch and builtin contexts.
> > Eval and function contexts only have the extension slot if they
> > contain a sloppy eval.
> >
> > Bug: v8:9744
> > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191
> > Commit-Queue: Victor Gomes <victorgomes@google.com>
> > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> > Auto-Submit: Victor Gomes <victorgomes@google.com>
> > Cr-Commit-Position: refs/heads/master@{#64372}
>
> TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org
>
> Bug: v8:9744
> Change-Id: I0749cc2d8f59940c25841736634a70047116d647
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1869192
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Auto-Submit: Victor Gomes <victorgomes@google.com>
> Cr-Commit-Position: refs/heads/master@{#64380}
TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org
Bug: v8:9744
Change-Id: I621ffe98722f8c4defaf277b8d1666484ba2963f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1872400
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Victor Gomes <victorgomes@google.com>
Cr-Commit-Position: refs/heads/master@{#64451}
This reverts commit c48096d442.
Reason for revert: Flaky bot failures (https://bugs.chromium.org/p/v8/issues/detail?id=9744#c9)
Original change's description:
> Reland "[runtime] Remove extension slots from context objects"
>
> This is a reland of c07c02e1c4
>
> Original change's description:
> > [runtime] Remove extension slots from context objects
> >
> > Context objects have an extension slot, which contains further
> > additional data that depends on the type of the context.
> >
> > This CL removes the extension slot from contexts that don't need
> > them, hence reducing memory.
> >
> > The following contexts will still have an extension slot: native,
> > module, await, block and with contexts. See objects/contexts.h for
> > what the slot is used for.
> > The following contexts will not have an extension slot anymore (they
> > were not used before): script, catch and builtin contexts.
> > Eval and function contexts only have the extension slot if they
> > contain a sloppy eval.
> >
> > Bug: v8:9744
> > Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191
> > Commit-Queue: Victor Gomes <victorgomes@google.com>
> > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> > Auto-Submit: Victor Gomes <victorgomes@google.com>
> > Cr-Commit-Position: refs/heads/master@{#64372}
>
> TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org
>
> Bug: v8:9744
> Change-Id: I0749cc2d8f59940c25841736634a70047116d647
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1869192
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Commit-Queue: Leszek Swirski <leszeks@chromium.org>
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Auto-Submit: Victor Gomes <victorgomes@google.com>
> Cr-Commit-Position: refs/heads/master@{#64380}
TBR=ulan@chromium.org,jgruber@chromium.org,petermarshall@chromium.org,leszeks@chromium.org,verwaest@chromium.org,victorgomes@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:9744
Change-Id: Ia58067b41f1eb5880a52b36ead754d7190ff7f6f
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1871922
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64424}
This is a reland of c07c02e1c4
Original change's description:
> [runtime] Remove extension slots from context objects
>
> Context objects have an extension slot, which contains further
> additional data that depends on the type of the context.
>
> This CL removes the extension slot from contexts that don't need
> them, hence reducing memory.
>
> The following contexts will still have an extension slot: native,
> module, await, block and with contexts. See objects/contexts.h for
> what the slot is used for.
> The following contexts will not have an extension slot anymore (they
> were not used before): script, catch and builtin contexts.
> Eval and function contexts only have the extension slot if they
> contain a sloppy eval.
>
> Bug: v8:9744
> Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191
> Commit-Queue: Victor Gomes <victorgomes@google.com>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Auto-Submit: Victor Gomes <victorgomes@google.com>
> Cr-Commit-Position: refs/heads/master@{#64372}
TBR=verwaest@chromium.org,jgruber@chromium.org,ulan@chromium.org,leszeks@chromium.org,petermarshall@chromium.org
Bug: v8:9744
Change-Id: I0749cc2d8f59940c25841736634a70047116d647
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1869192
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@google.com>
Cr-Commit-Position: refs/heads/master@{#64380}
This reverts commit c07c02e1c4.
Reason for revert: MSAN failures:
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20MSAN/29251
Original change's description:
> [runtime] Remove extension slots from context objects
>
> Context objects have an extension slot, which contains further
> additional data that depends on the type of the context.
>
> This CL removes the extension slot from contexts that don't need
> them, hence reducing memory.
>
> The following contexts will still have an extension slot: native,
> module, await, block and with contexts. See objects/contexts.h for
> what the slot is used for.
> The following contexts will not have an extension slot anymore (they
> were not used before): script, catch and builtin contexts.
> Eval and function contexts only have the extension slot if they
> contain a sloppy eval.
>
> Bug: v8:9744
> Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191
> Commit-Queue: Victor Gomes <victorgomes@google.com>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Leszek Swirski <leszeks@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Auto-Submit: Victor Gomes <victorgomes@google.com>
> Cr-Commit-Position: refs/heads/master@{#64372}
TBR=ulan@chromium.org,jgruber@chromium.org,petermarshall@chromium.org,leszeks@chromium.org,verwaest@chromium.org,victorgomes@google.com
Change-Id: I98dee04ab4d3ae977053982ec884b738d2f6f623
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9744
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1868611
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64373}
Context objects have an extension slot, which contains further
additional data that depends on the type of the context.
This CL removes the extension slot from contexts that don't need
them, hence reducing memory.
The following contexts will still have an extension slot: native,
module, await, block and with contexts. See objects/contexts.h for
what the slot is used for.
The following contexts will not have an extension slot anymore (they
were not used before): script, catch and builtin contexts.
Eval and function contexts only have the extension slot if they
contain a sloppy eval.
Bug: v8:9744
Change-Id: I8ca56c22fa02437bbac392ea72174ebfca80e030
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863191
Commit-Queue: Victor Gomes <victorgomes@google.com>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Auto-Submit: Victor Gomes <victorgomes@google.com>
Cr-Commit-Position: refs/heads/master@{#64372}
This is a reland of c7c47c68f2.
This makes TSAN happy in addition to:
Previously I presumed that the context read from a frame in the profiler was
a valid context. Turns out that on non-intel we're not guaranteed that the
frame is properly set up. In the case we looked at, the profiler took a
sample right before writing the frame marker indicating a builtin frame,
causing the "context" pointer from that frame to be a bytecode array. Since
we'll read random garbage on the stack as a possible context pointer, I made
the code reading the native context from it a little more defensive.
Bug: v8:9860
Tbr: ulan@chromium.org, neis@chromium.org, ishell@chromium.org
Original change's description:
> [runtime] Move Context::native_context to the map
>
> Remove the native context slot from contexts by making context maps
> native-context-specific. Now we require 2 loads to go from a context to the
> native context, but we have 1 field fewer to store when creating contexts.
>
> Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64296}
Change-Id: I4d0ab4cbbb23a9ae616407f17ef8f35a0b68ddb4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864654
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64360}
This reverts commit c7c47c68f2.
Reason for revert: breaks TSAN
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux64%20TSAN/28738
Original change's description:
> Reland "[runtime] Move Context::native_context to the map"
>
> This is a reland of f05bae1e0d
>
> Previously I presumed that the context read from a frame in the profiler was
> a valid context. Turns out that on non-intel we're not guaranteed that the
> frame is properly set up. In the case we looked at, the profiler took a
> sample right before writing the frame marker indicating a builtin frame,
> causing the "context" pointer from that frame to be a bytecode array. Since
> we'll read random garbage on the stack as a possible context pointer, I made
> the code reading the native context from it a little more defensive.
>
> Bug: v8:9860
>
> Original change's description:
> > [runtime] Move Context::native_context to the map
> >
> > Remove the native context slot from contexts by making context maps
> > native-context-specific. Now we require 2 loads to go from a context to the
> > native context, but we have 1 field fewer to store when creating contexts.
> >
> > Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d
> > Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629
> > Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> > Reviewed-by: Igor Sheludko <ishell@chromium.org>
> > Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> > Reviewed-by: Maya Lekova <mslekova@chromium.org>
> > Reviewed-by: Georg Neis <neis@chromium.org>
> > Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> > Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#64296}
>
> Change-Id: If9461e9b21d35a260d71c79d7f95e518cc429e09
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864930
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Auto-Submit: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64314}
TBR=ulan@chromium.org,neis@chromium.org,petermarshall@chromium.org,ishell@chromium.org,verwaest@chromium.org,mslekova@chromium.org,victorgomes@google.com
Change-Id: I4f9edc62ea6f9f5857619ff0ad1a63cab4b33cc3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9860
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864937
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64316}
This is a reland of f05bae1e0d
Previously I presumed that the context read from a frame in the profiler was
a valid context. Turns out that on non-intel we're not guaranteed that the
frame is properly set up. In the case we looked at, the profiler took a
sample right before writing the frame marker indicating a builtin frame,
causing the "context" pointer from that frame to be a bytecode array. Since
we'll read random garbage on the stack as a possible context pointer, I made
the code reading the native context from it a little more defensive.
Bug: v8:9860
Original change's description:
> [runtime] Move Context::native_context to the map
>
> Remove the native context slot from contexts by making context maps
> native-context-specific. Now we require 2 loads to go from a context to the
> native context, but we have 1 field fewer to store when creating contexts.
>
> Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64296}
Change-Id: If9461e9b21d35a260d71c79d7f95e518cc429e09
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1864930
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Auto-Submit: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64314}
Symbol and *String classes are now declared on Torque with
generateCppClass, which means they don't use macro accessors anymore. As
such, the gen-postmortem-metadata script is not able to automatically
detect fields for those classes. Define metadata for those fields
manually for now. In the future we might want to generate it from Torque
for consistency.
Also renamed a few *String fields metadata to match the expected format
(className__fieldName__fieldType). For more context:
https://github.com/nodejs/llnode/issues/287#issuecomment-539707117.
R=bmeurer@chromium.org, hpayer@chromium.org, verwaest@chromium.org, yangguo@chromium.org
Change-Id: I82fe8315cdbfd1b8c64c6a8d5dc011b1edaec39e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1847783
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64313}
This reverts commit f05bae1e0d.
Reason for revert: broke arm sim debug
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20debug/17714https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8899519852984476944/+/steps/Check_-_trusted/0/logs/FunctionDetailsInlining/0
Original change's description:
> [runtime] Move Context::native_context to the map
>
> Remove the native context slot from contexts by making context maps
> native-context-specific. Now we require 2 loads to go from a context to the
> native context, but we have 1 field fewer to store when creating contexts.
>
> Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629
> Commit-Queue: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Maya Lekova <mslekova@chromium.org>
> Reviewed-by: Georg Neis <neis@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64296}
TBR=ulan@chromium.org,neis@chromium.org,petermarshall@chromium.org,ishell@chromium.org,verwaest@chromium.org,mslekova@chromium.org,victorgomes@google.com
Change-Id: Ie7b4086c3a9ab2627ecac599da36b20cf8d1f948
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863200
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64299}
Remove the native context slot from contexts by making context maps
native-context-specific. Now we require 2 loads to go from a context to the
native context, but we have 1 field fewer to store when creating contexts.
Change-Id: I3c0d7c50c94060c4129db684f46a567de6f30e8d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859629
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64296}
Design doc:
https://docs.google.com/document/d/1ZU6rCvF2YHBGMLujWqqaxlPsjFfjKDE9C3-EugfdlAE/edit
Changes from the design doc:
- Changed to use 'class' declarations rather than 'type' declarations
for things that need instance types but whose layout is not known to
Torque. These declarations end with a semicolon rather than having a
full set of methods and fields surrounded by {}. If the class's name
should not be treated as a class name in generated output (because
it's actually a template, or doesn't exist at all), we use the
standard 'generates' clause to declare the most appropriate C++ class.
- Removed @instanceTypeName.
- @highestInstanceType became @highestInstanceTypeWithinParentClassRange
to indicate a semantic change: it no longer denotes the highest
instance type globally, but only within the range of values for its
immediate parent class. This lets us use it for Oddball, which is
expected to be the highest primitive type.
- Added new abstract classes JSCustomElementsObject and JSSpecialObject
to help with some range checks.
- Added @lowestInstanceTypeWithinParentClassRange so we can move the new
classes JSCustomElementsObject and JSSpecialObject to the beginning of
the JSObject range. This seems like the least-brittle way to establish
ranges that also include JSProxy (and these ranges are verified with
static assertions in instance-type.h).
- Renamed @instanceTypeValue to @apiExposedInstanceTypeValue.
- Renamed @instanceTypeFlags to @reserveBitsInInstanceType.
This change introduces the new annotations and adds the ability for
Torque to assign instance types that satisfy those annotations. Torque
now emits two new macros:
- TORQUE_ASSIGNED_INSTANCE_TYPES, which is used to define the
InstanceType enumeration
- TORQUE_ASSIGNED_INSTANCE_TYPE_LIST, which replaces the non-String
parts of INSTANCE_TYPE_LIST
The design document mentions a couple of other macro lists that could
easily be replaced, but I'd like to defer those to a subsequent checkin
because this one is already pretty large.
Bug: v8:7793
Change-Id: Ie71d93a9d5b610e62be0ffa3bb36180c3357a6e8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1757094
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64258}
In preparation for allowing Torque to generate the list of instance
types, I'd like to make the rules a bit more consistent for how instance
types are spelled. This CL is my proposal for a system where every
non-String instance type name is exactly equal to calling
CapifyStringWithUnderscores on the corresponding class name and
appending "_TYPE".
This change is almost all find&replace; the only manual changes are in:
- src/objects/instance-type.h
- src/torque/utils.cc
- tools/gen-postmortem-metadata.py
This change is in response to the review comment
https://chromium-review.googlesource.com/c/v8/v8/+/1757094/25/src/builtins/base.tq#132
Change-Id: Ife3857292669f54931708e934398b2684e60bea5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1814888
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Frank Tang <ftang@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64199}
This change makes the code compatible with both Python 2 and Python 3.
Change-Id: I99d68af9c3163607c3a2fdbafac339a98b7471e4
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1751331
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#63207}
This change is mostly mechanical, but it's worth mentioning a few
slightly interesting cases:
- A couple of field definitions didn't match the signedness of their
corresponding accessors.
- The generated accessors for Smi data use Smi values directly, but
usually we want C++ accessors to use ints instead. I added a macro
that hides the generated Smi accessors and exposes int accessors,
but we might consider generating int accessors directly.
- The data held in some fields is described in comments next to the
accessor definition for those fields. With automatically generated
accessors, those comments need a new home. In this change I put them
in the Torque object definition, but I'm open to other suggestions.
- gen-postmortem-metadata couldn't find updated class definitions after
they got split across multiple lines, so I changed its matching
logic. (Ideally debug-support.cc should be a Torque compiler output
rather than something that involves parsing C++ with regexes, but
this makes it correctly report subclass relationships for now.)
- The end offsets generated by Torque were off by one from the values
that would be generated by DEFINE_FIELD_OFFSET_CONSTANTS.
Change-Id: I3df4fcd27997b46c41ca879065b9d97f6c939f07
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1692192
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#62719}
The latter is better because it takes field type into account when
decompressing field value.
Drive-by: use [DECL_]ACCESSOR macros for some fields.
Bug: v8:9353
Change-Id: I3d7f07d11b1e379e3e6cf0310d836af6b48c1338
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1680539
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62444}
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/+/1672942
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62337}
This is a reland of 4b86fea530 with
copy&paste typo in CodeStubAssembler::AllocateByteArray() fixed
(bug led to holes in new space, which was crashing reproducibly
on the ia32 bot).
Original change's description:
> [typedarray] Move external/data pointer to JSTypedArray.
>
> As the next step in supporting huge typed arrays in V8, this moves the
> external/data pointer from the FixedTypedArrayBase backing store to the
> JSTypedArray instance itself, and replaces the special backing stores
> with a plain ByteArray (removing all the code for the FixedTypedArrayBase
> class hierarchy). By doing so, we can drastically simplify the system
> around typed arrays.
>
> Note: Several places in the code base used to check the instance type
> of the elements backing store of a JSTypedArray instead of checking the
> elements kind on the JSTypedArray map directly. Those had to be fixed,
> since the backing store is now always a ByteArray.
>
> Drive-by-fix: Move all the typed elements access related code into the
> elements.cc file to properly encapsulate the accesses.
>
> Doc: http://doc/1Z-wM2qwvAuxH46e9ivtkYvKzzwYZg8ymm0x0wJaomow
> Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
> Change-Id: I8cc06b190c53e34155000b4560f5f3ef40621646
> Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627535
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Simon Zünd <szuend@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61855}
Tbr: petermarshall@chromium.org
Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
Change-Id: I87fcdb28532c5f08cc227332a4d59546cb423810
Cq-Include-Trybots: luci.chromium.try:linux-rel, win7-rel
Cq-Include-Trybots: luci.v8.try:v8_linux_shared_compile_rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631592
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61864}
This reverts commit 4b86fea530.
Reason for revert: Fails on linux shared: https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20shared/31045
Original change's description:
> [typedarray] Move external/data pointer to JSTypedArray.
>
> As the next step in supporting huge typed arrays in V8, this moves the
> external/data pointer from the FixedTypedArrayBase backing store to the
> JSTypedArray instance itself, and replaces the special backing stores
> with a plain ByteArray (removing all the code for the FixedTypedArrayBase
> class hierarchy). By doing so, we can drastically simplify the system
> around typed arrays.
>
> Note: Several places in the code base used to check the instance type
> of the elements backing store of a JSTypedArray instead of checking the
> elements kind on the JSTypedArray map directly. Those had to be fixed,
> since the backing store is now always a ByteArray.
>
> Drive-by-fix: Move all the typed elements access related code into the
> elements.cc file to properly encapsulate the accesses.
>
> Doc: http://doc/1Z-wM2qwvAuxH46e9ivtkYvKzzwYZg8ymm0x0wJaomow
> Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
> Change-Id: I8cc06b190c53e34155000b4560f5f3ef40621646
> Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627535
> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
> Reviewed-by: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Simon Zünd <szuend@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61855}
TBR=ulan@chromium.org,yangguo@chromium.org,titzer@chromium.org,sigurds@chromium.org,petermarshall@chromium.org,bmeurer@chromium.org,szuend@chromium.org
Change-Id: I0bc1f935de6063acf75a0f4bb8c0ba67428603fd
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
Cq-Include-Trybots: luci.chromium.try:linux-rel, win7-rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631427
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61856}
As the next step in supporting huge typed arrays in V8, this moves the
external/data pointer from the FixedTypedArrayBase backing store to the
JSTypedArray instance itself, and replaces the special backing stores
with a plain ByteArray (removing all the code for the FixedTypedArrayBase
class hierarchy). By doing so, we can drastically simplify the system
around typed arrays.
Note: Several places in the code base used to check the instance type
of the elements backing store of a JSTypedArray instead of checking the
elements kind on the JSTypedArray map directly. Those had to be fixed,
since the backing store is now always a ByteArray.
Drive-by-fix: Move all the typed elements access related code into the
elements.cc file to properly encapsulate the accesses.
Doc: http://doc/1Z-wM2qwvAuxH46e9ivtkYvKzzwYZg8ymm0x0wJaomow
Bug: chromium:951196, chromium:965583, v8:4153, v8:7881, v8:9183
Change-Id: I8cc06b190c53e34155000b4560f5f3ef40621646
Cq-Include-Trybots: luci.chromium.try:linux-rel,win7-rel
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627535
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61855}
