Now we can pass in the prefix size to OrderedHashTable directly from
the Derived class and have it calculate the hash table start offset
based on this.
Bug: v8:6443, v8:7569
Change-Id: I80d54b65116e18f5a0cab18eb51649adad447cce
Reviewed-on: https://chromium-review.googlesource.com/c/1333682
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57499}
This makes the above factory function use a fine-grained scope when
unlocking code space for modification. It is now based on the memory
chunk of the resulting code object.
R=ulan@chromium.org
Change-Id: Iabe6fba7595ba3264b21bcd6f6634ab9725eaad9
Reviewed-on: https://chromium-review.googlesource.com/c/1335687
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57498}
Always generate a token for the first character in ScanSingleToken, and
switch on that. If the token could change with subsequent characters, e.g.
Token::ADD into Token::ASSIGN_ADD, then handle that in that token's case
rather than going character-by-character.
This allows us to have a tighter packing of the cases, and early detect
numbers, keywords and identifiers.
Change-Id: I8c3ac7a5453547abeb09fc90826a26390b15a415
Reviewed-on: https://chromium-review.googlesource.com/c/1335547
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57497}
This CL implements AtomicPair operators: Load, Store,
Add, Sub, Or, Xor, And, Exchange and CompareExchange using
runtime on MIPS32R2 and older. MIPS32R6 includes instructions
for 64-bit atomic access so they are implemented using those.
Change-Id: I1309c1ea4771480516ec5a92f7592533bdcb205c
Reviewed-on: https://chromium-review.googlesource.com/c/1326466
Reviewed-by: Sreten Kovacevic <skovacevic@wavecomp.com>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Ivica Bogosavljevic <ibogosavljevic@wavecomp.com>
Cr-Commit-Position: refs/heads/master@{#57496}
- Removes IsRegExp check and special handling when false
- Removes MatchAllIterator
- Extracts previously inlined CreateRegExpStringIterator
- Update comments to match spec text and numbering
Bug: v8:6890
Change-Id: Ie81757a499acc77910f029835fb042e70d86d83d
Reviewed-on: https://chromium-review.googlesource.com/c/1317830
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57488}
This is to prevent errors like:
https://ci.chromium.org/p/v8/builders/luci.v8.ci/V8%20Arm/8792
The error code suggests the OS killed the tests due to OOM. The time it took
suggests OS paging. Fewer tests in parallel should mitigate this.
NOTRY=true
Change-Id: I847058cfb02a9a36795581df47760d921d695141
Reviewed-on: https://chromium-review.googlesource.com/c/1333674
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57486}
Port bd0a7fd64c
Original Commit Message:
This reduces the build steps after touching counters.h from 710 to 191, thus
detaching counters.h from the giant include cluster.
R=marja@chromium.org, joransiu@ca.ibm.com, michael_dawson@ca.ibm.com
BUG=v8:7490,v8:8238
LOG=N
Change-Id: I7694a21856c228c6d0335c1f1e5e9177c96cc7da
Reviewed-on: https://chromium-review.googlesource.com/c/1333940
Reviewed-by: Joran Siu <joransiu@ca.ibm.com>
Commit-Queue: Junliang Yan <jyan@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#57485}
This CL is an experiment to get more performance data from the perf-bots
and will likely lead to regressions. The try-bots (see patcheset 9)
indicate some regressions, but it doesn't seem too bad.
Change-Id: Ia173ab20ee2a4904663db0f4ca2ffb196b203c77
Reviewed-on: https://chromium-review.googlesource.com/c/1319763
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57483}
Now you can type:
tools/torque/format-torque.py -i src/builtins/*.tq
to format all the torque files in a particular directory. Is handy.
TBR=danno@chromium.org
Bug: v8:7793
Change-Id: Ifba85c4db553e19a65b87217fd2f670698c6b2c9
Reviewed-on: https://chromium-review.googlesource.com/c/1333679
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57482}
With this we can just shortcircuit parsing if we see an incorrect
Token::COMMA or Token::COLON when parsing class literals.
Change-Id: Idd0c0c33b035b821ed23174f9cb1b12616a2a621
Reviewed-on: https://chromium-review.googlesource.com/c/1333678
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57481}
This reverts commit 96a17c03da.
Reason for revert: Caused the tree to close
Original change's description:
> [Torque] format-torque.py accepts wildcards
>
> Now you can type:
> tools/torque/format-torque.py -i src/builtins/*.tq
>
> to format all the torque files in a particular directory. Is handy.
>
> Bug: v8:7793
> Change-Id: I334b2c555c63fd7864636ebfd83a2631a5d44806
> Reviewed-on: https://chromium-review.googlesource.com/c/1333671
> Reviewed-by: Daniel Clifford <danno@chromium.org>
> Commit-Queue: Michael Stanton <mvstanton@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#57479}
TBR=danno@chromium.org,mvstanton@chromium.org
Change-Id: Ib531bd2f20f438ef95b657eb86356ee724fa5b39
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7793
Reviewed-on: https://chromium-review.googlesource.com/c/1333677
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57480}
Now you can type:
tools/torque/format-torque.py -i src/builtins/*.tq
to format all the torque files in a particular directory. Is handy.
Bug: v8:7793
Change-Id: I334b2c555c63fd7864636ebfd83a2631a5d44806
Reviewed-on: https://chromium-review.googlesource.com/c/1333671
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57479}
This is important for transient types, which might be invalidated
in a loop syntactically below the vulnerable use.
Bug: v8:7793
Change-Id: Ia97c03282eefbc44d54beb8edc61f5d44af2c947
Reviewed-on: https://chromium-review.googlesource.com/c/1331547
Reviewed-by: Daniel Clifford <danno@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57478}
This refactoring hides the fact that some wrappers are first generated
in the GC'ed heap and then copied into the native module. It is a first
step towards avoiding the redundant copy.
R=clemensh@chromium.org
Change-Id: I531fa42e8b4c210948d306624007348a39b981e0
Reviewed-on: https://chromium-review.googlesource.com/c/1333673
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57477}
In the process, move the rest of the implementation PLabels into the
CodeAssembler for consistency.
Change-Id: I56872d9fc756db066f0d13d87aeb55ec04de2495
Reviewed-on: https://chromium-review.googlesource.com/c/1329687
Commit-Queue: Daniel Clifford <danno@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57474}
Use same value to rethrow as was used before this change. This doesn't
appear to be explicitly tested anywhere, but the behavior should stay
unchanged nevertheless.
Change-Id: Idaed90a143e9775746f034190918065897094acb
Reviewed-on: https://chromium-review.googlesource.com/c/1329684
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57472}
This reduces the build steps after touching counters.h from 710 to 191, thus
detaching counters.h from the giant include cluster.
BUG=v8:7490,v8:8238
Change-Id: I0c7e707fb945e293f8a5604cc8da438cd35b3210
Reviewed-on: https://chromium-review.googlesource.com/c/1329695
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57468}
Just moving code around a bit.
R=ahaas@chromium.org
Bug: v8:7921
Change-Id: I6a9f9dab41360e9a0d8249fe77260788151cd88b
Reviewed-on: https://chromium-review.googlesource.com/c/1333411
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57466}
We were outputting the address of the WasmCodeManager instead of the
native module.
R=ahaas@chromium.org
Change-Id: I70f0aca4ef9126b91fcc3716570bfc69e71d27c7
Reviewed-on: https://chromium-review.googlesource.com/c/1326024
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57465}
For some reason the C++ compiler fails to realise that next_ cannot
change on entry into Scan from Next, and re-loads it, creating what
looks like a data dependency that stalls the next instruction.
Passing through a cached next_ value cleans up the generated code.
Change-Id: Iab62ed1890a3a720e5fa90a90e802305e3d55a82
Reviewed-on: https://chromium-review.googlesource.com/c/1331551
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57464}
Use a flag int instead of bit fields in LiteralBuffer, so that
cache the output of next() in Scanner::Scan() so that it doesn't get
reloaded between LiteralBuffer::Drop() calls.
LiteralBuffer: :Drop can set a single value rather than masking. Also,
Change-Id: I977703488ac41e3b091f46ce0840e7c464639073
Reviewed-on: https://chromium-review.googlesource.com/c/1331548
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57463}
We're fetching the symbols anyway, so we might as well use those instead in the
preparser.
Change-Id: Ie937c755690cdd7b15e8486aa9680d530eff602e
Reviewed-on: https://chromium-review.googlesource.com/c/1332296
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57460}
An oversight in my previous change (3b64764b1d) could
cause a CHECK failure.
Bug: chromium:904707
Change-Id: Ie5f1c500bddc00741b889f78ae9ecd9af581ba5c
Reviewed-on: https://chromium-review.googlesource.com/c/1333409
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57459}
Previously, the following call sequence was always made when creating resulting
subsetted TypedArray:
1) TFJ TypedArrayPrototypeSubArray
2) TFS TypedArrayConstructor
3) TFS CreateTypedArray
This CL, skips #2 and goes straight to #3 when the default constructor (builtin) is
safe to use (IsPrototypeTypedArrayPrototype and
!IsTypedArraySpeciesProtectorCellInvalid).
Local TypedArrays/SubarrayNoSpecies microbenchmark shows ~35-40% improvement...
BEFORE
TypedArrays-SubarrayNoSpecies(Score): 1033530
TypedArrays-SubarrayNoSpecies(Score): 1018490
TypedArrays-SubarrayNoSpecies(Score): 1037030
AFTER
TypedArrays-SubarrayNoSpecies(Score): 1439030
TypedArrays-SubarrayNoSpecies(Score): 1417540
TypedArrays-SubarrayNoSpecies(Score): 1405980
Bug: v8:7161
Change-Id: I356dace36570aa161ffe208a57a80e46714121a2
Reviewed-on: https://chromium-review.googlesource.com/c/1331154
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57458}
It's not sufficient to check the NoElements protector because that
doesn't guard against the array having a custom prototype.
Bug: v8:8449
Change-Id: I843815466a1e4ae197a2b76eec62d04cdc2d619d
Reviewed-on: https://chromium-review.googlesource.com/c/1332232
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57457}
This matches the pre-torque behavior when the receiver's length
was greater than the max array length.
Bug: chromium:902672
Change-Id: Icf8ae3a1a4acc0680ce1b709f5b3372892337203
Reviewed-on: https://chromium-review.googlesource.com/c/1330921
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57456}
This CL updates DetachableVector to store the data at a known place
instead of in an std::vector<>, so that builtins can update it directly.
Bug: v8:8124
Change-Id: Iba5fb2e9d4e0ddc689d0f7eeaea40bc3218edf3a
Reviewed-on: https://chromium-review.googlesource.com/c/1297783
Commit-Queue: Taiju Tsuiki <tzik@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57452}
See the WebAssembly bulk memory proposal here:
https://github.com/WebAssembly/bulk-memory-operations
This initial CL adds a wasm experimental flag:
`--experimental-wasm-bulk-memory`, and also parsing of passive segments.
A passive segment is one that is not copied into the table/memory on
instantiation, but instead later via the `{table,memory}.init`
instructions.
The binary format of passive data segments is unlikely to change, but
the format for passive element segments may change (see
https://github.com/WebAssembly/bulk-memory-operations/pull/39).
Bug: v8:7747
Change-Id: I2a7fb9bc7648a722a8c4aab4185c68d3d0843858
Reviewed-on: https://chromium-review.googlesource.com/c/1330015
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#57451}