This is somewhat of a revival of what used to be
UnseededNumberDictionary. The difference to NumberDictionary is that
each entry only has two fields (no field for property details) and there
is no header field for a bitfield.
The reason for this change is memory regression introduced when we
removed UnseededNumberDictionary (6e1c57eaa9). We now use
SimpleNumberDictionary for
- slow template instantiation cache
- code stubs table
- value serializer map
- stack frame cache
- type profile source positions
R=ishell@chromium.org, ulan@chromium.org
Bug: chromium:783695
Change-Id: I3cd32e485060bb379fb2279eeefbbbded7455f0e
Reviewed-on: https://chromium-review.googlesource.com/885811
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50869}
Also refactor the implementation of i32.eqz such that the same
platform-specific code can be reused.
As a next step, it should be straight-forward to add other i32
comparison operations.
R=titzer@chromium.org
Bug: v8:6600
Change-Id: I4e8768d4ceb7294ba35777b7777ddd69d1a58cf1
Reviewed-on: https://chromium-review.googlesource.com/877889
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50868}
- Introduce new helper IsFastJSArrayWithNoCustomIteration.
- Consolidates all entry array checks...
- Is a fast array (defers to BranchIfFastJSArray)
- No possibility that the Array's iteration protocol has been tampered with
- Introduce new BoolT constant helpers Int32TrueConstant and Int32FalseConstant.
Bug: chromium:804176, chromium:804188
Change-Id: I6b08396484682dc680b431ea564a7a28eeab8108
Reviewed-on: https://chromium-review.googlesource.com/883065
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50867}
In addition I added some comments in the update script which describes
steps which have to be takes the first time you run the script on a
new machine.
R=titzer@chromium.org
Change-Id: Ib360e6fcdcb63eaf225f398eff60041b48f86b62
Reviewed-on: https://chromium-review.googlesource.com/883344
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50863}
We cannot handle i64 values yet, so bail out if an indirect call
returns i64. The same bailout already exists for direct calls.
R=ahaas@chromium.org
Bug: v8:6600
Change-Id: I3ddf44a913ee79b5610862e3a93059c6d37a280c
Reviewed-on: https://chromium-review.googlesource.com/885813
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50862}
Bug:
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I0ecc0af1668f5036bb591e8236d9a28fba61cea5
Reviewed-on: https://chromium-review.googlesource.com/881782
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50861}
This reverts commit 181ac2b0dc.
Reason for revert: TF changes break load elimination.
Original change's description:
> [ic] Improve performance of KeyedStoreIC on literal-based arrays.
>
> In mode STORE_AND_GROW_NO_TRANSITION, the handler for elements stores
> used to bail out when seeing a COW array, even if the store that
> installed the handler had been operating on the very same array.
>
> This CL adds support for COW arrays to the mode (and renames it to
> STORE_AND_GROW_NO_TRANSITION_HANDLE_COW).
>
> Bug: v8:7334
> Change-Id: I6a15e8c1ff8d4ad4d5b8fc447745dce5d146c67c
> Reviewed-on: https://chromium-review.googlesource.com/876014
> Commit-Queue: Georg Neis <neis@chromium.org>
> Reviewed-by: Igor Sheludko <ishell@chromium.org>
> Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50840}
TBR=neis@chromium.org,ishell@chromium.org,bmeurer@chromium.org
Change-Id: Id841d91b12d199045e0a9c4ddae2c2ead20b5e21
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7334
Reviewed-on: https://chromium-review.googlesource.com/885814
Reviewed-by: Georg Neis <neis@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50860}
Refactor the PromiseHandle builtin and move the separate debug checks
into the PromiseHookBefore and PromiseHookAfter runtime calls, so they
are performed only when we've already hit the slow-path.
Bug: v8:7253
Change-Id: I01ab8592a474b6897280734b995cab0b90a5e010
Reviewed-on: https://chromium-review.googlesource.com/884583
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50856}
Do not start a new step when an existing step is in progress. We may
have partially updated information as part of the current step, and the
next step will assume consistency. A new step will be started once the
current in-progress step completes.
BUG=v8:7313
Change-Id: I4c0c47c4f4b5f8b9139be24408440189679b38dc
Reviewed-on: https://chromium-review.googlesource.com/882507
Reviewed-by: Ali Ijaz Sheikh <ofrobots@google.com>
Commit-Queue: Ali Ijaz Sheikh <ofrobots@google.com>
Cr-Commit-Position: refs/heads/master@{#50855}
When moving arguments for calls into the right registers and stack
slots, we were sometimes overwriting stack slots which would still be
used later to load arguments from. This is because we popped the (wasm)
value stack before executing the register moves, hence the stack
transfer would think the values are not being used any more and reuse
the stack slots.
With this CL, we only pop the arguments from the stack after executing
the stack transfer.
R=ahaas@chromium.org
Bug: v8:7366, v8:6600
Change-Id: I3aa5126c82634fd281959075e91e73465c39abaa
Reviewed-on: https://chromium-review.googlesource.com/883802
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50853}
This is a reland of fffa4555d0.
The win asan bots use win10 now which should fix the problems.
Original change's description:
> [build] Prepare switching win asan to 64 bits
>
> This switches the current win32 bots to win32 under the hood in MB. We'll
> remove them and replace them with win64 bots in a follow up on the infra
> side.
>
> This also infers the clang option from asan, because on windows we need
> to set clang explicitly.
>
> TBR=sergiyb@chromium.org
>
> Bug: chromium:786303
> Change-Id: I9dddd5050a21a364c302a761ff15ddd21e97c7dc
> Reviewed-on: https://chromium-review.googlesource.com/883103
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Commit-Queue: Michael Achenbach <machenbach@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50828}
TBR=sergiyb@chromium.org
Bug: chromium:786303
Change-Id: Ie344a7b6b16f575a061d13b5c3792fc9bd862734
Reviewed-on: https://chromium-review.googlesource.com/883522
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50850}
This adds a new operator JSCreatePromise, which currently allocates
a native JSPromise instance and initializes it to pending state.
In addition to that we introduce a new PromiseHookProtector, which
get's invalidated the first time someone enables the debugger or
installs a PromiseHook (via async_hooks for example). As long as
the protector is intact we lower AsyncFunctionPromiseCreate to
JSCreatePromise and AsyncFunctionPromiseRelease to a no-op in
optimized code.
This yields a speedup of roughly 33% on the benchmark mentioned
in the bug.
Bug: v8:7271, v8:7253
Change-Id: Ib5d219f2b6e052a7cc5e6ed5aa66dd3c8885a859
Reviewed-on: https://chromium-review.googlesource.com/883124
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50849}
When executing register moves, we might need to spill registers to the
stack. Ensure that we don't exceed the reserved stack space for the
current frame.
R=ahaas@chromium.org
Bug: v8:7366, v8:6600
Change-Id: Ic11ff2ff5f46535c3663ef4cf62b095f6c8ba637
Reviewed-on: https://chromium-review.googlesource.com/883282
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50847}
The SwitchOnGeneratorState bytecode now also falls through if the
generator object is undefined (so that we don't need that jump) and
restores generator context (so that we don't need that PushContext).
This saves 10 bytes per generator.
Change-Id: Ie0872c827119b9f1d1e9244d3be6496a30cd9620
Reviewed-on: https://chromium-review.googlesource.com/867051
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50845}
The CompilationUnitBuilder of the StreamingProcessor is cleared when an
error occurs in the streaming decoder. The clearing of the
CompilationUnitBuilder was guarded by the existence of the
ModuleCompiler, because this ModuleCompiler and the
CompilationUnitBuilder are created together. However, the
CompilationUnitBuilder is reset when the next section after the code
section is processed, whereas the ModuleCompiler exists until the end of
the AsyncCompileJob. With this CL the clearing of the
CompilationUnitBuilder is also guarded by its own existence.
R=clemensh@chromium.org
Bug: chromium:805346
Change-Id: I0e9e9eaff9239fadb21c0f17990da61cbfaa6856
Reviewed-on: https://chromium-review.googlesource.com/883527
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50844}
When reserving stack space by decrementing rsp/esp, we were ignoring
the constant size needed for the stack marker and the wasm context.
Later, we were using that space anyway, which can lead to errors if e.g.
interrupt handlers kick in and use that space below rsp/esp.
R=ahaas@chromium.org
Bug: v8:7366, v8:6600
Change-Id: I2f49ef5785d33e98c29c5cf4fe7624a02e8c7628
Reviewed-on: https://chromium-review.googlesource.com/883881
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50843}
Instead of collecting eagerly compilable inner function literals (IIFEs
etc.) during AST numbering, collect them during bytecode generation,
exposing them on the CompilationJob.
Bug: v8:7178
Change-Id: I47451f412d2796e5857b4bc38c4f29c80cb0745d
Reviewed-on: https://chromium-review.googlesource.com/873872
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50842}
It is analogous to Template::SetLazyDataProperty, but for a single
existing object. Similar to how SetNativeDataProperty exists on both.
Bug: v8:7303
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I634358ee455e28150198bd87a2bd79dc59e3e449
Reviewed-on: https://chromium-review.googlesource.com/867474
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Jeremy Roman <jbroman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50841}
In mode STORE_AND_GROW_NO_TRANSITION, the handler for elements stores
used to bail out when seeing a COW array, even if the store that
installed the handler had been operating on the very same array.
This CL adds support for COW arrays to the mode (and renames it to
STORE_AND_GROW_NO_TRANSITION_HANDLE_COW).
Bug: v8:7334
Change-Id: I6a15e8c1ff8d4ad4d5b8fc447745dce5d146c67c
Reviewed-on: https://chromium-review.googlesource.com/876014
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50840}
FixedArrays hanging off recursively of the constant pool without any
real objects in between can be considered as meta data. They are shared
with optimized code (embedder pointers).
Bug: v8:7266
Change-Id: I4006675e17e8eea3bdc8565254d80e2ffece0ad0
Reviewed-on: https://chromium-review.googlesource.com/883361
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50837}
This reverts commit 25ecc45f81.
Reason for revert: Two issues discovered with W^X in V8's 6.5 branch (see v8:7272 and chromium:793428). Still need a way to disable the feature.
Original change's description:
> [heap] Remove --write-protect-code-memory feature flag.
>
> R=hpayer@chromium.org
> BUG=v8:6792
>
> Change-Id: Id3413994de603dac1b7501c6fe376cdac1f9d7ce
> Reviewed-on: https://chromium-review.googlesource.com/866851
> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Hannes Payer <hpayer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50759}
TBR=mstarzinger@chromium.org,hpayer@chromium.org,hablich@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:6792
Change-Id: Ie0d4409b36f22c97a6777e512618beafdef8c2f4
Reviewed-on: https://chromium-review.googlesource.com/883502
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50835}
This reverts commit bf19e60cc5.
Reason for revert: Two issues discovered with W^X in V8's 6.5 branch (see v8:7272 and chromium:793428). Still need a way to disable the feature.
Original change's description:
> [platform] Remove {PageAllocator::kReadWriteExecute}.
>
> Now that write-protection of code memory is enabled everywhere and V8 is
> fully W^X compliant, we can remove the permission mode in question.
>
> R=hpayer@chromium.org
> BUG=v8:6792
>
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: I80fe95ac6bb0e2d1ad6d993154ce45d492d941be
> Reviewed-on: https://chromium-review.googlesource.com/866855
> Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Hannes Payer <hpayer@chromium.org>
> Reviewed-by: Bill Budge <bbudge@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50770}
TBR=bbudge@chromium.org,mstarzinger@chromium.org,hpayer@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:6792
Change-Id: If4a205497ac83084a4092560363affb13b391462
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/883461
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50834}
Add effect input and output to String.p.char[Code]At/codePointAt.
This is necessary to fix an hard to reproduce bug, a repro for
which is included. However, the only way to get the repro
included in this CL to fail is to run it with the patch of
873382:
[turbofan] Speculate on bounds checks for String#char[Code]At
but WITHOUT this patch. This fixes a scheduling problem triggered
by 873382 that caused a bounds check to get scheduled after the
associated access.
Bug: v8:7326
Change-Id: I4b97c1726caac92ff8f74c23df2788f0ecfb1304
Reviewed-on: https://chromium-review.googlesource.com/881781
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50832}
- Remove TypedArray.prototype.subarray in js/typedarray.js
- Implement TypedArray.prototype.subarray as a CSA
- Implement TypedArraySpeciesCreateByArrayBuffer as a CSA
- Move a helper function for relative index from builtins-string-gec.cc
to code-stub-assembler.cc
- Move SpeciesConstructor from builtins-promise-gen.cc to
code-stub-assembler.cc
Bug: v8:7161, v8:5929
Change-Id: If3340476e16aa21659540eb4b24e3ead54e6a313
Reviewed-on: https://chromium-review.googlesource.com/830992
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50831}
Instead of building suspend_ids in the AST numbering, collect suspend
counts in the parser and assigning suspend ids during bytecode
generation.
Bug: v8:7178
Change-Id: I53421442afddc894db789fb9d0d3e3cc10e32ff0
Reviewed-on: https://chromium-review.googlesource.com/817598
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50830}
This reverts commit fffa4555d0.
Reason for revert:
https://build.chromium.org/p/client.v8/builders/V8%20Win32%20ASAN/builds/1905
Original change's description:
> [build] Prepare switching win asan to 64 bits
>
> This switches the current win32 bots to win32 under the hood in MB. We'll
> remove them and replace them with win64 bots in a follow up on the infra
> side.
>
> This also infers the clang option from asan, because on windows we need
> to set clang explicitly.
>
> TBR=sergiyb@chromium.org
>
> Bug: chromium:786303
> Change-Id: I9dddd5050a21a364c302a761ff15ddd21e97c7dc
> Reviewed-on: https://chromium-review.googlesource.com/883103
> Reviewed-by: Michael Achenbach <machenbach@chromium.org>
> Commit-Queue: Michael Achenbach <machenbach@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#50828}
TBR=machenbach@chromium.org,sergiyb@chromium.org
Change-Id: I2e17aa6ddf44a03d9da29e8b7f7dd2c9f6fe4cb9
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:786303
Reviewed-on: https://chromium-review.googlesource.com/883501
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50829}
This switches the current win32 bots to win32 under the hood in MB. We'll
remove them and replace them with win64 bots in a follow up on the infra
side.
This also infers the clang option from asan, because on windows we need
to set clang explicitly.
TBR=sergiyb@chromium.org
Bug: chromium:786303
Change-Id: I9dddd5050a21a364c302a761ff15ddd21e97c7dc
Reviewed-on: https://chromium-review.googlesource.com/883103
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50828}
This will affect all manual test runs with x64. Most bots on x64 already
migrated.
TBR=sergiyb@chromium.org
NOTRY=true
Bug: v8:7343
Change-Id: I87f46f1848a813c0b320b3e9901481b9232025a5
Reviewed-on: https://chromium-review.googlesource.com/883101
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50825}
A while ago we introduced MutableBigInt in order to enforce this check.
R=jkummerow@chromium.org
Bug: v8:6791
Change-Id: I700ff0b1df854d4f6b8beff6f6c984e11cd07e40
Reviewed-on: https://chromium-review.googlesource.com/881174
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50823}
The chromium callers were updated in https://crrev.com/c/868287,
while the pdfium callers were updated in
https://pdfium-review.googlesource.com/c/pdfium/+/23058.
As a precaution to avoid a repeat of https://crbug.com/803330,
I've manually built pdfium, along with the additional gn flag
"pdf_enable_xfa = true".
Bug: v8:7269, v8:7282
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I5b8cfb629c2b78627447c940a133d75d7ef7c6e9
Reviewed-on: https://chromium-review.googlesource.com/875252
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50821}
The calls in Chromium were removed in https://crrev.com/c/865535.
Bug: v8:7269, v8:7276
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Iae9fadead1167363893b258ba2a21710a1e080a8
Reviewed-on: https://chromium-review.googlesource.com/869146
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50820}
