In Liftoff, we have a good estimate about how big the generated code
might get. Also, we often compile hundreds of functions which each hold
an assembler buffer alive until we finally add that code to the wasm
module.
In order to reduce memory consumption in Liftoff, this CL reduces
{AssemblerBase::kMinimalBufferSize} from 4096 to 128, and adds
{AssemblerBase::kDefaultBufferSize} to be used instead.
R=jkummerow@chromium.org
Change-Id: I7029bf501244770f4824a86b233d7f99c4b7910b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1914559
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64958}
This removes {CPURegister::Is} and {CPURegister::is}, and just uses
{CPURegister::operator==} instead.
Drive-by: Use DCHECK_EQ and DCHECK_NE where possible.
R=mstarzinger@chromium.org
Bug: v8:9810
Change-Id: I03aad8b4223bd4ae37d468326a734f7a5c3c8061
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1916202
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64956}
Just use the default {is_valid} method provided by RegisterBase.
Drive-by: Also rename {CPURegList::IsValid} to {CPURegList::is_valid}.
R=mstarzinger@chromium.org
Bug: v8:9810
Change-Id: Ia3bc3c477e6329d63ffd00bca59762d9a6cf2fcc
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1916201
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64952}
This reverts commit d46bd852ad.
Reason for revert: I suspect this breaks the 'V8 Linux - predictable' bot. Specifically, 'typedarray-copywithin' has been failing since this landed. I am not exactly sure what is wrong from the tests error message, but see this link for more information:
https://logs.chromium.org/logs/v8/buildbucket/cr-buildbucket.appspot.com/8896980452133814304/+/steps/Check_-_d8__flakes_/0/logs/typedarray-copywithin/0
Original change's description:
> [ic] Migrate Code-based handlers to use data driven handler.
>
> All usage of KeyedLoadIC_Slow, HasIC_Slow, StoreInArrayLiteralIC_Slow
> and KeyedStoreIC_Slow now use data driven handlers
>
> Bug: v8:9779
> Change-Id: Idd888c5c10b462a5fe155ba0add36f95169bd76d
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1895988
> Reviewed-by: Toon Verwaest <verwaest@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Commit-Queue: Suraj Sharma <surshar@microsoft.com>
> Cr-Commit-Position: refs/heads/master@{#64918}
TBR=rmcilroy@chromium.org,verwaest@chromium.org,surshar@microsoft.com
Change-Id: Id7c2b553f85b46048bed2c633b8bd24098f67147
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:9779
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1912092
Reviewed-by: Joshua Litt <joshualitt@chromium.org>
Commit-Queue: Joshua Litt <joshualitt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64922}
All usage of KeyedLoadIC_Slow, HasIC_Slow, StoreInArrayLiteralIC_Slow
and KeyedStoreIC_Slow now use data driven handlers
Bug: v8:9779
Change-Id: Idd888c5c10b462a5fe155ba0add36f95169bd76d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1895988
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Suraj Sharma <surshar@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#64918}
UMA data shows that we currently still allocate up to ten code spaces
per module. This is because the code size estimates are vastly off,
especially if both Liftoff and TurboFan is being used.
Also, code sizes differ by platform.
This CL adds more logic to the {EstimateNativeModuleCodeSize} function
to distinguish Liftoff and TurboFan, and to use different constants per
platform. A largeish comment explains how the numbers were generated,
and that they are an extreme over-generalization. However, without
further information about the module, this is the best we can do.
After all, being off even by a factor of two does not hurt too much, as
explained in the comment.
R=jkummerow@chromium.org
Change-Id: Icd178f5f4d0c7c8fa29b11b6eff7d14e64a1af1c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1910102
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64913}
This patch excludes brand symbols from the result of
JSReceiver::GetPrivateEntries so that the brands do not show up
when the instances are inspected from the DevTools (e.g. via
`Runtime.getProperties()`).
To implement this, we use a bit in the Symbols to denote whether
it's a brand symbol. A brand symbol is also a private name
symbol so that we can just reuse the IC for accessing private
names and do not need to jump through extra ORs.
Design doc: https://docs.google.com/document/d/1N91LObhQexnB0eE7EvGe57HsvNMFX16CaWu-XCTnnmY/edit
Bug: v8:8671, v8:9839, v8:8330
Change-Id: I24346aeedce3602395289052d1e1350ae9390354
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1909757
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Joyee Cheung <joyee@igalia.com>
Cr-Commit-Position: refs/heads/master@{#64899}
Instead of changing all of TryToName to do the conversion to array
index, this patch narrows this fast path just to the element load IC
handler.
This patch also restores the HeapNumber conversion in TryToIntPtr and
in Turbofan inlining as per the original state of things.
Bug: v8:9449, chromium:1016738, chromium:1016709
Change-Id: Ibf3a2c38637fc36e0ee037dc740f273848d1e8a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1902386
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64896}
The function-entry stack check should dominate all other
instructions in a function. Prior to this CL it was possible to create
paths not including a stack check due to SwitchOnGeneratorState: the
generator-creation branch had a stack check, while generator-resume
branches did not.
0 : af fb 00 01 SwitchOnGeneratorState r0, [0], [1] { 0: @22 }
4 : 27 fe fa Mov <closure>, r1
7 : 27 02 f9 Mov <this>, r2
10 : 64 0a fa 02 InvokeIntrinsic [_CreateJSGeneratorObject], r1-r2
14 : 26 fb Star r0
16 : a7 StackCheck
17 : b0 fb fb 01 00 SuspendGenerator r0, r0-r0, [0]
22 : b1 fb fb 01 ResumeGenerator r0, r0-r0
[... no stack check here ...]
This CL moves the stack check to the beginning of the bytecode array,
i.e. before SwitchOnGeneratorState.
Bug: chromium:1020031
Change-Id: I8ba8cba99611ddbe50c76023129d926cc84b1d5e
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1903440
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64888}
Including but not limiting to removing:
* BitcastCompressedXXX
* CheckedCompressedXXX
* ChangeXXXToCompressedYYY
* ChangeCompressedXXX
As a note, ChangeTaggedToCompressed can't be removed just yet as it
is still in use.
Bug: v8:7703
Change-Id: I98cf88a32adfa976d419e69702d1cac4d3e811a5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1903435
Commit-Queue: Santiago Aboy Solanes <solanes@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64880}
This makes the {code_size_estimate} computation explicit in the caller,
and removes one of the two {NewNativeModule} constructors. It turns out
that the calculation is totally off in the streaming calculation phase,
since no function bodies have been parsed yet. So all
{WasmFunction::code} fields are still empty, and we compute an estimate
that is way too low.
This CL prepares the actual fix for that (by computing a better estimate
at specific call sites).
R=ahaas@chromium.org
Bug: v8:9950
Change-Id: I68a891c97e5f65a9c7e73e21684bdfa7e261e216
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1901273
Commit-Queue: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64845}
Introduce new operator LoadTransform that holds a LoadTransformInfo param,
which describes the kind of load (normal, unaligned, protected), and a
transformation (splat or extend, signed or unsigned).
We have a new method that a full decoder needs to implement, LoadTransform,
which resuses the existing LoadType we have, but also takes a LoadTransform,
to distinguish between splats and extends at the decoder level.
This implements 4 out of the 10 suggested load splat/extend operations
(to keep the cl smaller), and is also missing interpreter support (will
be added in the future).
Change-Id: I1e65c693bfbe30e2a511c81b5a32e06aacbddc19
Bug: v8:9886
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863863
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64819}
The test coverage in question is by now provided by a different set of
mjsunit tests, namely the "mjsunit/wasm/anyref-globals-interpreter"
suite which run all globals tests in --wasm-interpret-all mode.
R=ahaas@chromium.org
TEST=cctest/test-run-wasm-interpreter/ReferenceTypeLocals
Change-Id: I439b1ee74da3c36995bb3d5819e35d4074400868
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1901266
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64812}
Currently there are two ways wasm locations are represented in the
inspector. This remains unchanged for now. Also, currently there are
multiple ways location is represented within V8, with the line number
sometimes being a function index and sometimes being 0, and the column
number being a byte offset which is sometimes function relative and
sometimes module relative. With this change, the line number is never
used within V8 (it is always 0), and the column number is always a
byte offset from the beginning of the module. This simplifies
translation logic and keeps it in one place, and will simplify future
changes to wasm location representation in the inspector API.
Bug: chromium:1013527
Change-Id: I8813d47c881988f9ab49d7529fb81fe10dbbccff
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1886915
Commit-Queue: Eric Leese <leese@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64774}
We were using 'strtoll' which returns a signed integer, we should have used
'strtoull' instead.
Change-Id: Ie2e48ecc1fa58cff4b61fcea30087608769a80bb
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893333
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#64765}
Instead of inferring allow_codegen from the state of MaybeLocal<String>, return it separately. This allows to distinguish "could not stringify this object" from "block execution of this object", regardless of whether the object is a string or not. Currently, the hook can trigger an EvalError only if the original source was a string.
Modify the logic so that one of the three mechanisms (unconditional, non-modifying, modifying) decides alone. Before, if the non-modifying callback rejected a value, the value would be forwarded to the modifying callback, but the unconditional would not forward to the non-modifying callback. This introduces a more uniform behaviour where the three mechanisms act in decreasing priority.
Change-Id: Iaaa9873227052653d714df65f31c4de914f48b7d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1776082
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Daniel Vogelheim <vogelheim@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Stefano Sanfilippo <ssanfilippo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64763}
This is a reland of 855591a54d
Fixes break in builds that verify ReadOnlyHeap by relaxing the requirement for
Code objects to be in CODE_SPACE in PagedSpaceObjectIterator::FromCurrentPage.
Original change's description:
> Reland: [builtins] Move non-JS linkage builtins code objects into RO_SPACE
>
> Reland of https://chromium-review.googlesource.com/c/v8/v8/+/1795358.
>
> [builtins] Move non-JS linkage builtins code objects into RO_SPACE
>
> Creates an allow-list of builtins that can still go in code_space
> including all TFJ builtins and a small manual list that should be pared
> down in the future.
>
> For builtins that go in RO_SPACE a Code object is created that contains an
> immediate trap instruction. Generally these Code objects are still no
> smaller than CODE_SPACE Code objects because of the Code object alignment
> requirements. This will hopefully be addressed in a follow-up CL either by
> relaxing them or removing the instruction stream completely.
>
> In the snapshot, this reduces code_space from ~152k to ~40k (-112k) and
> increases by the same amount.
>
> Change-Id: I76661c35c7ea5866c1fb16e87e87122b3e3ca0ce
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893336
> Commit-Queue: Dan Elphick <delphick@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64700}
Change-Id: I4eeb7dab3027b42fa58c5dfb2bad9873e9fff250
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893192
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64728}
This CL improves reporting for WeakMap entries: If a retaining chain
goes through a WeakMap entry (i.e. key and weak map are alive, and keep
value alive) then both the key and the value are reported. Additionally
the phrasing is clarified, such that entries in retaining paths are
easier to understand.
Bug: chromium:1020096
Change-Id: Ib05cd6f7939c6de41b554c682ad1fbf685b87608
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893335
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64721}
A window is a Blink concept. This API marks the context as backing
a detached window. This doesn't necessarily mean that the context is
detached.
Every time a JS function is called within a context that has a non-zero
DetachedWindowReason, Runtime::kReportDetachedWindowAccess is invoked,
which will report this call to Blink via a callback, which in turn can
report number of such calls via UKM metrics.
Bug: chromium:1018156
Change-Id: I67c89fef459f4efcb912229eed8a4f3ea3b60f54
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1862829
Auto-Submit: Bartek Nowierski <bartekn@chromium.org>
Commit-Queue: Bartek Nowierski <bartekn@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64707}
This reverts commit 855591a54d.
Reason for revert: Breaks arm64 sim tests
https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20debug/17957https://ci.chromium.org/p/v8/builders/ci/V8%20Linux%20-%20arm64%20-%20sim%20-%20gc%20stress/16585
Original change's description:
> Reland: [builtins] Move non-JS linkage builtins code objects into RO_SPACE
>
> Reland of https://chromium-review.googlesource.com/c/v8/v8/+/1795358.
>
> [builtins] Move non-JS linkage builtins code objects into RO_SPACE
>
> Creates an allow-list of builtins that can still go in code_space
> including all TFJ builtins and a small manual list that should be pared
> down in the future.
>
> For builtins that go in RO_SPACE a Code object is created that contains an
> immediate trap instruction. Generally these Code objects are still no
> smaller than CODE_SPACE Code objects because of the Code object alignment
> requirements. This will hopefully be addressed in a follow-up CL either by
> relaxing them or removing the instruction stream completely.
>
> In the snapshot, this reduces code_space from ~152k to ~40k (-112k) and
> increases by the same amount.
>
> Change-Id: I76661c35c7ea5866c1fb16e87e87122b3e3ca0ce
> Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893336
> Commit-Queue: Dan Elphick <delphick@chromium.org>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#64700}
TBR=ulan@chromium.org,jgruber@chromium.org,delphick@chromium.org
Change-Id: I4211c3bb7fe4741e0ba3898f92ce382dfc93c4f3
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893636
Reviewed-by: Bill Budge <bbudge@chromium.org>
Commit-Queue: Bill Budge <bbudge@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64701}
Reland of https://chromium-review.googlesource.com/c/v8/v8/+/1795358.
[builtins] Move non-JS linkage builtins code objects into RO_SPACE
Creates an allow-list of builtins that can still go in code_space
including all TFJ builtins and a small manual list that should be pared
down in the future.
For builtins that go in RO_SPACE a Code object is created that contains an
immediate trap instruction. Generally these Code objects are still no
smaller than CODE_SPACE Code objects because of the Code object alignment
requirements. This will hopefully be addressed in a follow-up CL either by
relaxing them or removing the instruction stream completely.
In the snapshot, this reduces code_space from ~152k to ~40k (-112k) and
increases by the same amount.
Change-Id: I76661c35c7ea5866c1fb16e87e87122b3e3ca0ce
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1893336
Commit-Queue: Dan Elphick <delphick@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64700}
These are SSE2 instructions that deal with scalar double precision
values, and look like the packed double precision variant of the
instructions, but with a prefix.
E.g. sqrtpd is 66 0F 51, sqrtss is F2 0F 51.
We don't put this in the same list, even though the implementation
is very similar, because SSE2_INSTRUCTION_LIST is used in other
macros which generate AVX versions of this, and that overlaps with
another macro which generates AVX versions of these X-sd instructions.
I will tease this apart and clean it up in subsequent changes.
Bug: v8:9810
Change-Id: I0db64fe0d37df5685158331ce9f48bd1c763cc59
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1874510
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64688}
Implement the possibility to revisit the same function in the
serializer using equality of its arguments.
Bug: v8:7790
Change-Id: I609a6009bf503e378e50d0b32c6f1c13721d2557
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1863198
Commit-Queue: Maya Lekova <mslekova@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64683}
These are SSE instructions that deal with scalar single precision
values, and look like the packed single precision variant of the
instructions, but with a prefix.
E.g. sqrtps is NP 0F 51, sqrtss is F3 0F 51.
Bug: v8:9810
Change-Id: I417ea6d4d85d8618ad6602a1b32d4428db0d66d2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1874509
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64658}
This is the first step in unification of concurrent and main thread
marking visitors. The new MarkingVisitorBase will become a base class
for all marking visitors and will remove the existing code duplication.
This is a refactoring without behavior change.
Subsequent CL will change the main thread marking visitor to derive
from the new base class.
Bug: chromium:1019218
Change-Id: I3d47030d396e0ba6706882fbd922bbcac46181b2
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1886920
Reviewed-by: Dominik Inführ <dinfuehr@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64632}
The new API with v8::BackingStore should be used instead as explained in
https://docs.google.com/document/d/1sTc_jRL87Fu175Holm5SV0kajkseGl2r8ifGY76G35k
This also relaxes the pre-condition for [Shared]ArrayBuffer::Detach to
not require externalization first.
Bug: v8:9380, v8:9908
Change-Id: Idd119fcd28be84a2fae74ae86f7381fd997766f5
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1859628
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Backes <clemensb@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64625}
There are a couple of bugs here:
1. The immediate used for vinsertps is wrong when lane == 1, the first
two bits specify which element of the source is copied, and it should
always be 00, 01 to copy the first 2 lanes of source.
2. For both cases, the second insertps call should be using dst as the
src, since dst was already updated by the first insertps call, it was
incorrectly using the old value of src. This was probably working
correctly because in many cases dst and src happened to be the same
register.
3. rep cannot be same as dst, because dst is overwritten, and rep should
stay the same
I also modified the F64x2ReplaceLane to test separately for replacing
lane 0 and lane 1.
Fixed bug 3. for arm and arm64.
Bug: v8:9728
Change-Id: Iec6e48bcfbc7d27908dd86d5f113a8b5dedd499b
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1877055
Reviewed-by: Deepti Gandluri <gdeepti@chromium.org>
Commit-Queue: Zhi An Ng <zhin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64620}
When inlined allocations are disabled, the space->limit() does not point to the
end of the current page. Instead, it points to the current allocation pointer so
is the same as space->top().
See how the limit is computed, if heap()->inline_allocation_disabled(), then the
limit will be the same as the requested allocation area:
```
Address SpaceWithLinearArea::ComputeLimit(Address start, Address end,
size_t min_size) {
DCHECK_GE(end - start, min_size);
if (heap()->inline_allocation_disabled()) {
// Fit the requested area exactly.
return start + min_size;
} else if (SupportsInlineAllocation() && AllocationObserversActive()) {
// ...
} else {
// The entire node can be used as the linear allocation area.
return end;
}
}
```
If we want to simulate filling up a whole page in the new space, we can instead
look at the ToSpace's page_high() which will be the end of the current page in
which we're allocating.
Bug: v8:9906
Change-Id: I81113d151bc083cd22d17ea1a4fbae7fef9dff6d
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1886914
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Pierre Langlois <pierre.langlois@arm.com>
Cr-Commit-Position: refs/heads/master@{#64612}
This change begins making use of the fact that Torque now knows about
the relationship between classes and instance types, to replace a few
repetitive lists:
- Instance type checkers (single and range), defined in
src/objects/instance-type.h
- Verification dispatch in src/diagnostics/objects-debug.cc
- Printer dispatch in src/diagnostics/objects-printer.cc
- Postmortem object type detection in
tools/debug_helper/get-object-properties.cc
Torque is updated to generate four macro lists for the instance types,
representing all of the classes separated in two dimensions: classes
that correspond to a single instance type versus those that have a
range, and classes that are fully defined in Torque (with fields and
methods inside '{}') versus those that are only declared. The latter
distinction is useful because fully-defined classes are guaranteed to
correspond to real C++ classes, whereas only-declared classes are not.
A few other changes were required to make the lists above work:
- Renamed IsFiller to IsFreeSpaceOrFiller to better reflect what it does
and avoid conflicts with the new macro-generated IsFiller method. This
is the part I'm most worried about: I think the new name is an
improvement for clarity and consistency, but I could imagine someone
typing IsFiller out of habit and introducing a bug. If we'd prefer to
keep the name IsFiller, my other idea is to rename FreeSpace to
VariableSizeFiller and Filler to FixedSizeFiller.
- Made Tuple3 extend from Struct, not Tuple2, because IsTuple2 is
expected to check for only TUPLE2_TYPE and not include TUPLE3_TYPE.
- Normalized the dispatched behavior for BigIntBase and HeapNumber.
- Added a few new object printers.
Bug: v8:7793
Change-Id: I5462bb105f8a314baa59bd6ab6ab6215df6f313c
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1860314
Commit-Queue: Seth Brenith <seth.brenith@microsoft.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Dan Elphick <delphick@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64597}
OrderedHashTableHandler::Delete was missed in the migration CL
crrev.com/c/1106160 because it had no callers. This CL also
migrates said function and adds usages in tests which force
instantiation (and ensure we catch these errors without MSVC).
Bug: v8:9905
Change-Id: Ieb1d1c89754f98e1d88d841d2933f46a6a4820d0
Reviewed-on: https://chromium-review.googlesource.com/c/v8/v8/+/1883891
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#64595}
