GetPropertyWithReceiver is similar to GetProperty, except that additional receiver parameter is used in TryPrototypeChainLookup to support GetPropertyWithReceiver stub.
We only use this stub in ProxyGetProperty builtin for now.
Bug: v8:8958
Change-Id: Ied60e4f6ee6e09bca2f161048b481a0bf37a78a7
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1676879
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62431}
d8 treats files with the .mjs extension as modules instead of
classic scripts. Thus, the `// MODULE` pragma and its corresponding
logic in test runners can be removed in favor of explicitly adding
the extension.
Bug: v8:7950, v8:9395, v8:9406
Also-By: tmrts@chromium.org
Change-Id: Ic74328dc5c5f176bb4bdf6d74bdd4d3966279ba5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1675958
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Tamer Tas <tmrts@chromium.org>
Auto-Submit: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62421}
If there was an assignment to a maybe-shadowing dynamic variable,
then the shadowing variable would be marked maybe_assigned, but the
maybe-shadowed variable would stay unchanged. This meant that in
non-shadowing cases, the not-actually-shadowed variable would have
the wrong maybe_assigned state, and e.g. would break context
specialization.
This patch pessimistically unconditionally sets maybe_assigned on
variables shadowed by a dynamic variable in a `with` scope. This
marking can cause false positives and sub-optimal optimization for
some functions with 'with' blocks, but it's also the simplest fix
for this issue which doesn't affect performance in the common case
of no 'with' blocks.
Bug: v8:9394
Change-Id: I6924bd7d48dda61232aa9d72c39df1c76c665c67
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1678365
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62407}
Boilerplate values may possess an unboxed double field filled with the kHoleNan64Int sentinel value, which indicates that the field is uninitialized. When a boilerplate value migrates away from the unboxed double representation to a tagged one, we should replace the sentinel value by the proper uninitialized oddball value.
This fixes an issue with JSCreateLowering::AllocateFastLiteral not detecting const stores of uninitialized values properly.
R=bmeurer@chromium.org, jarin@chromium.org
Bug: chromium:976598
Change-Id: I6bb216c0618a3105e6c8cfc04b1900d2f83a52ce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1674034
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Georg Schmid <gsps@google.com>
Cr-Commit-Position: refs/heads/master@{#62394}
Deprecated maps might not be updated before being passed to
PrepareForDataProperty. If the target map is a dictionary map,
then adding the data property can fail.
As a drive-by, remove the dead ForTransitionHandler code, which
was another (potentially unsafe) caller of PrepareForDataProperty
Bug: chromium:977012
Change-Id: I894bbc9bca2001555474a3570eb03fe6b0f69ddd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1674029
Auto-Submit: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62377}
Large regexp results may exceed kMaxRegularHeapObjectSize and must
thus be allocated in large object space.
Drive-by: Rename '%InNewSpace' to '%InYoungGeneration'.
Bug: chromium:976627
Change-Id: I38b5aecb95a95cf2fdbb24d19550cec34361a09d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1674027
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62368}
Makes the order of the generated calls to the Runtime function
DefineAccessorPropertyUnchecked fixed regardless of hashseed so that
recompilation for lazy source positions always generates the same
result.
Moves AccessorTable from src/ast/ast.h to bytecode-generator.cc since
that's the only place that uses it.
Bug: v8:9383, v8:8510
Change-Id: I89e0aad1683a793714bfb48eca1b00abe20cad0a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1669689
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62303}
CL https://chromium-review.googlesource.com/c/v8/v8/+/1660623
("[Turbofan] Brokerize more promise reductions in JSCallReducer")
introduced a bug where we bail out of a call reduction but failed
to remove graph constructs added by the MapInference class.
R=jarin@chromium.org
Bug: chromium:976256, chromium:976524
Change-Id: I97f142fe6c1caba5e679f7df742893536c83b2d8
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1666990
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62267}
We don't want to handle even non-growing stores when there are TypedArrays
in the prototype chain. Typed arrays handle the out-of-bounds accesses by
ignoring the stores unlike the regular array writes. We just let runtime
handle these cases instead of making ICs more complex.
There was an earlier cl (https://chromium-review.googlesource.com/c/v8/v8/+/1609790)
that fixed it for growing stores. This cl extends it for non-growing stores
as well to handle more cases.
Bug: chromium:961709
Change-Id: I65e079b88c10d2ba343f69a67134893319cd8f8a
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1662305
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62243}
This adds missing support when converting a Word32 value (either in
Signed32 or Unsigned32 range) to Word64 representation, for which the
type also includes MinusZero. This conversion is fine as long as the
difference between 0 and -0 is not observable (in other words, as long
as the truncation identifies zeros).
Bug: chromium:971782, chromium:225811, v8:4153, v8:7881, v8:8171, v8:8383
Change-Id: I9d350a25f57b1342eb7fd1279d55a8610bdaf7cd
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1664062
Reviewed-by: Sigurd Schneider <sigurds@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62235}
RegExp assertions (e.g.: '^', '$', '\b', ...) sequences have certain
properties that this rewriter exploits:
1. They are zero-width and order-independent, thus one can remove all
duplicate assertions.
2. If a subsequence is guaranteed to fail, the entire sequence fails.
Any sequence always known to fail (e.g. containing both '\b' and '\B')
can be rewritten to a single node that triggers failure.
This CL generalizes the previous optimization for repeated assertions
to be order-independent, i.e. assertions only have to be in the same
sequence but not next to each other.
Bug: v8:6515, v8:6126
Change-Id: I3f92f081ce8a55ad8c34c269a09a6686e3b008f3
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1657925
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62201}
The store element handlers don't check if the array length is writable
before updating the length. Since this is not expected to be a common
case no need of handling this in the element handlers. Just moving to
megamorphic would be sufficient.
Bug: chromium:967104
Change-Id: I7a7f9ea768266b9ffd6289328d61d2297d455619
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1658154
Commit-Queue: Mythri Alle <mythria@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62152}
With bytecode flushing and lazy feedback allocation, we need to call
%PrepareForOptimization before we call %OptimizeFunctionOnNextCall,
ideally after declaring the function.
Bug: v8:8801, v8:8394, v8:9183
Change-Id: I3fb257282a30f6526a376a3afdedb44786320d34
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1648255
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62119}
An error object's 'stack' property is lazily formatted once the
property is first read. It is thus possible that lazy formatting
happens in a different realm than where the error object was
constructed.
In this case, we should use the origin-realm's prepareStackTrace
function to format the stack trace.
This CL implements that behavior by fetching prepareStackTrace from
the given error object's context's error function.
Bug: v8:7848
Change-Id: Ibc383cf24f2c0dab2fd8bb7bc740f1488d9954a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1113438
Commit-Queue: Simon Zünd <szuend@chromium.org>
Auto-Submit: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62090}
Quotes have been added around the token to make the message clearer.
Bug: chromium:943636
Change-Id: Ic38f3e6d307157af2c0146e69fb611a2cfb46564
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1593307
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62074}
The path for sealed elements is handled by using the same path for SmiOrObjectElementKind, just need to extend a DCHECK in CodeStubAssembler::IsFixedArrayWithKind.
The only special case is when we write to a hole in holey sealed elements. Since we can not write in that case, just bail out.
Bug: chromium:967101
Change-Id: Ibf837ae053fe609bca83da432f298ef056f3aced
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1632830
Commit-Queue: Z Nguyen-Huu <duongn@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62071}
The DoubleToFloat32 helper takes care of everything, so use it
consistently.
Bug: chromium:969498
Change-Id: If71e5374684b89615006548cb0329f4d4cb7fd6d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1648253
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Ben Smith <binji@chromium.org>
Auto-Submit: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62062}
We need to hold onto the bytecode array so it doesn't get flushed.
Bug: v8:8394
Change-Id: Ia583a0a662740e369fcbc1c94041895e463be26e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1645329
Commit-Queue: Mythri Alle <mythria@chromium.org>
Auto-Submit: Mythri Alle <mythria@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#62011}
With bytecode flushing and lazy feedback allocation, we need to call
%PrepareForOptimization before we call %OptimizeFunctionOnNextCall,
ideally after declaring the function.
Bug: v8:8801, v8:8394, v8:9183
Change-Id: I6bf119e726426df8527d97546b6ce806112c894d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1643167
Auto-Submit: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61988}
Currently, Number.prototype.toString(radix) often fails to produce the
least significant bit for doubles near zero. For example, for the
minimum double, 5e-324, toString(2) produces "0". This means that a
user cannot reliably get the exact binary or hexdecimal value of a
double from JavaScript using toString.
This patch makes a slight amendment to the DoubleToRadixCString
function, so that doubles where the gap to the next double is 5e-324
(i.e. doubles less than 2**-1021), are represented exactly in binary and
other power-of-two bases, and close to exactly otherwise. It results
in Number.prototype.toString producing the correct binary value for all
doubles.
R=jkummerow@chromium.org, mathias@chromium.org, yangguo@chromium.org
Bug: v8:9294
Change-Id: I71506149b7c4c0eac8c38675a1ee15fb4f36f9ef
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1631601
Commit-Queue: Mathias Bynens <mathias@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61925}
According to the spec, in case where the property is non-configurable and
non-writable, the value passed to the set trap should be compared to the data.
Instead, the trap result was compared, because of the misleading name of the
CheckGetSetTrapResult parameter.
Regression was introduced in
https://chromium-review.googlesource.com/c/v8/v8/+/1604071
Bug: chromium:966450
Change-Id: I77501980475da3aeb4f6153321da39e6fc2e6bd9
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1632238
Auto-Submit: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61916}
Feedback pollution can create situations in which we statically see stores to the same field with incompatible representations; dynamically this should be impossible for a single TurboFan compilation unit. Instead of failing an assertion we produce Unreachable nodes.
R=tebbi@chromium.org
Bug: chromium:967434 chromium:967506
Change-Id: Id549ec84f28b4fed2d2e5ef05b40b48bc5b30e97
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1632169
Commit-Queue: Georg Schmid <gsps@google.com>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61894}
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}
When allocating large arrays on 32-bit systems, the length conversion
caused the work array capacity to become negative. As the sort range
is currently clamped at kSmiMaxValue anyway, the fix is to also
clamp the work capacity to that value.
R=jgruber@chromium.org
Bug: chromium:967065
Change-Id: I9ea60464c5b7f3796c5389cbaf668b990eddecf6
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1630672
Auto-Submit: Simon Zünd <szuend@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61845}
COW arrays were previously handled in the C++ pre-processing runtime
function. The Torque version forgot a "EnsureWritableFastElements".
This CL fixes that.
Bug: chromium:967254
Change-Id: Ifbf89e57cfe724e61316b8abc226f7e8a262fce2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1630675
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Auto-Submit: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61835}
This is a reland of 2b0ac2fb9f
The layout test that caused this revert was fixed with:
https://crrev.com/c/1627386
Original change's description:
> [array] Move Array#sort pre-processing to Torque
>
> This CL removes the "PrepareElementsForSort" runtime function, and
> replaces it with a simpler version in Torque. The biggest difference
> is that certain sparse configurations no longer have a fast-path.
>
> The Torque pre-processing step replaces the existing Torque mechanism that
> copied already pre-processed elements into the "work" FixedArray. The Torque
> compacting works as follows:
> - Iterate all elements from 0 to {length}
> - If the element is the hole: Do nothing.
> - If the element is "undefined": Increment undefined counter.
> - In all other cases, push the element into the "work" FixedArray.
>
> Then the "work" FixedArray is sorted as before. Writing the elements from
> the "work" array back into the receiver, after sorting, has three steps:
> 1. Copy the sorted elements from the "work" FixedArray to the receiver.
> 2. Add previously counted number of "undefined" to the receiver.
> 3. Depending on the backing store either delete properties or
> set them to the Hole up to {length}.
>
> Bug: v8:8714
> Change-Id: I14eccb7cfd2e4618bce2a85cba0689d7e0380ad2
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1619756
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61812}
TBR: jgruber@chromium.org
Bug: v8:8714
Change-Id: If7613f6e5f37c5e0d649e8192195594bc6c32100
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627977
Commit-Queue: Simon Zünd <szuend@chromium.org>
Auto-Submit: Simon Zünd <szuend@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61827}
This reverts commit 2b0ac2fb9f.
Reason for revert: Breaks scrollingcoordinator/non-fast-scrollable-region-nested.html layout test on https://ci.chromium.org/p/v8/builders/ci/V8-Blink%20Linux%2064/32241
Original change's description:
> [array] Move Array#sort pre-processing to Torque
>
> This CL removes the "PrepareElementsForSort" runtime function, and
> replaces it with a simpler version in Torque. The biggest difference
> is that certain sparse configurations no longer have a fast-path.
>
> The Torque pre-processing step replaces the existing Torque mechanism that
> copied already pre-processed elements into the "work" FixedArray. The Torque
> compacting works as follows:
> - Iterate all elements from 0 to {length}
> - If the element is the hole: Do nothing.
> - If the element is "undefined": Increment undefined counter.
> - In all other cases, push the element into the "work" FixedArray.
>
> Then the "work" FixedArray is sorted as before. Writing the elements from
> the "work" array back into the receiver, after sorting, has three steps:
> 1. Copy the sorted elements from the "work" FixedArray to the receiver.
> 2. Add previously counted number of "undefined" to the receiver.
> 3. Depending on the backing store either delete properties or
> set them to the Hole up to {length}.
>
> Bug: v8:8714
> Change-Id: I14eccb7cfd2e4618bce2a85cba0689d7e0380ad2
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1619756
> Commit-Queue: Simon Zünd <szuend@chromium.org>
> Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#61812}
TBR=peter.wm.wong@gmail.com,jgruber@chromium.org,tebbi@chromium.org,szuend@chromium.org
Change-Id: If1c1bc07f38dfbd4bf6b6ce8f9d70714e7526877
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:8714
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1627976
Reviewed-by: Simon Zünd <szuend@chromium.org>
Commit-Queue: Simon Zünd <szuend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61814}
This CL removes the "PrepareElementsForSort" runtime function, and
replaces it with a simpler version in Torque. The biggest difference
is that certain sparse configurations no longer have a fast-path.
The Torque pre-processing step replaces the existing Torque mechanism that
copied already pre-processed elements into the "work" FixedArray. The Torque
compacting works as follows:
- Iterate all elements from 0 to {length}
- If the element is the hole: Do nothing.
- If the element is "undefined": Increment undefined counter.
- In all other cases, push the element into the "work" FixedArray.
Then the "work" FixedArray is sorted as before. Writing the elements from
the "work" array back into the receiver, after sorting, has three steps:
1. Copy the sorted elements from the "work" FixedArray to the receiver.
2. Add previously counted number of "undefined" to the receiver.
3. Depending on the backing store either delete properties or
set them to the Hole up to {length}.
Bug: v8:8714
Change-Id: I14eccb7cfd2e4618bce2a85cba0689d7e0380ad2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1619756
Commit-Queue: Simon Zünd <szuend@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61812}
Unfortunately, we still have to keep the field because GC mole and Torque
do not support platform specific padding well
(see http://crbug.com/v8/9287).
Bug: v8:9183
Change-Id: I2210be4b8174c97bc82145605f9b862aac3bdc37
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1624791
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#61802}
