The wasm call fuzzer is superseded by the wasm compile fuzzer, thus
remove it.
The chromium side will land in https://crrev.com/c/895531.
R=ahaas@chromium.org
Change-Id: I211d9f8ad2ca5432dbbc6ecce0b6e13760f1af60
Reviewed-on: https://chromium-review.googlesource.com/895534
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51034}
If enabled, this mode moves code for isolate-independent builtins off
the JS heap at Isolate creation. The Code object itself is rewritten
to tail-call the off-heap instruction stream.
Drive-by-fix: Support lazy deserialization in asm-wasm instantiation.
Bug: v8:6666
Change-Id: Ic109527ff478cfc6e8942e924413fc7532da6eaf
Reviewed-on: https://chromium-review.googlesource.com/888562
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#51015}
For mips, if 'mips_arch_variant=="r6"' and if 'mips_use_msa' flag is set
to 'true', then test-run-wasm-simd tests won't be skipped for mips. It
will also force 'MIPS_SIMD' bit in CpuFeatures to be set.
ARM processors are assumed to support SIMD.
Change-Id: Iea668b97ef995ca4949ddbf2ffc734aad89d3aa3
Reviewed-on: https://chromium-review.googlesource.com/868430
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Ivica Bogosavljevic <ivica.bogosavljevic@mips.com>
Commit-Queue: Ivica Bogosavljevic <ivica.bogosavljevic@mips.com>
Cr-Commit-Position: refs/heads/master@{#50981}
This makes the ArrayBuiltinsAssembler consistent with the StringBuiltinsAssembler
and paves the way for tools that expect the assemblers to have a common structure.
Change-Id: I7470fc2cf144f9cc2fdbcee99b31daed267550be
Reviewed-on: https://chromium-review.googlesource.com/889933
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Commit-Queue: Daniel Clifford <danno@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50920}
This adds the benchmarks suite to the deopt fuzzer and removes the
obsolete deopt configs, which since a while are part of the num-fuzz
configs.
TBR=sergiyb@chromium.org
Bug: v8:6900
Change-Id: I9202e2a66a132eca5940b4444fda97816b034e54
Reviewed-on: https://chromium-review.googlesource.com/876085
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50720}
This fuzzer randomly generates calls to regexp builtins, runs each on
the slow and fast path, and verifies that their result is the same.
Change-Id: Ia91b0c8afcdaf64835a9bb7b9a470610fbb75fc8
Reviewed-on: https://chromium-review.googlesource.com/833922
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50670}
This is the first in a series of CLs that will separate the JS API
from the implementation of WebAssembly by bottlenecking interactions
through the WasmEngine. In the long run, the JS API and much of V8
should rely only on the WasmEngine interface, which will represent
the "public interface" for embedding WebAssembly.
Next: hide compilation-related methods behind WasmEngine.
Bug: v8:7316
Change-Id: I93404f0dc8a201ae99d30b4c1ca34606e3dddbca
Reviewed-on: https://chromium-review.googlesource.com/868590
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50660}
This will switch on various testing features in sanitizer builds and
for correctness fuzzer builds.
Currently we group enabling the slow-path runtime flag and allocation
timeout for atomic gc stress, but more features could be added in the
future.
This will enable gc fuzzer, clusterfuzz and correctness fuzzer to use
both slow-path and atomic gc stress in release sanitizer builds.
Bug: v8:6972
Change-Id: I5cade68241a8a0711f8a388be7e1543aab0035fa
Reviewed-on: https://chromium-review.googlesource.com/869932
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50656}
This CL makes a fuzzer out of the cctest
test-multiple-return/ReturnMultipleRandom. The fuzzer creates a
CallDescriptor with input parameters and returns, and a function which
maps input parameters to returns. The fuzzer then calls this function
with a wrapper which checks that the correct mapping happened.
R=clemensh@chromium.org
Change-Id: Ib89c4063638baae69540a44486d7b2e9d13f8c1f
Reviewed-on: https://chromium-review.googlesource.com/859768
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50532}
This CL centralizes constants related to decoding from several places
into one place and makes it no longer necessary to include
wasm-opcodes.h for some simple constants.
R=clemensh@chromium.org
Bug:
Change-Id: I53aa81e34167df467bc7455b717bf67083033943
Reviewed-on: https://chromium-review.googlesource.com/859764
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50503}
Otherwise dynamic linking with dlopen, as is the case with Node.js
addons, would not work.
R=fhinkel@chromium.org
Bug: v8:6105
Change-Id: I5a884afc003fdfdb9de7e9b0c736f1894ba0019a
Reviewed-on: https://chromium-review.googlesource.com/850112
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50384}
This adds the gn flag 'v8_untrusted_code_mitigations', which defaults to
true. If false, the DISABLE_UNTRUSTED_CODE_MITIGATIONS preprocessor
macro will be defined, which sets the default for the
--untrusted-code-mitigations runtime flag to false.
R=machenbach@chromium.org, hablich@chromium.org
CC=bmeurer@chromium.org
Bug: chromium:798964
Change-Id: Ief037e194dc9eeb7fe224b5d414a4ea8e69beb20
Reviewed-on: https://chromium-review.googlesource.com/852074
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50380}
- Adds abstract base class PageAllocator, defined in v8-platform.h. Adds
GetPageAllocator method to v8::Platform.
- Implements a DefaultPageAllocator, implemented in terms of base::OS
page allocation methods.
Bug: chromium:756050
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Iece0b261a07294a49c30ac25e848dc39cb1a32e2
Reviewed-on: https://chromium-review.googlesource.com/809778
Commit-Queue: Bill Budge <bbudge@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50282}
This is a reland of ab38b03d1b
Original change's description:
> [builtins] Port Object.p.toLocaleString to CSA from JS
>
> - Added ObjectPrototypeToLocaleString TFJ
> - Remove v8natives.js
> - Move GetMethod and GetIterator into prologue.js
>
> TBR=adamk@chromium.org
>
> Bug: v8:6005
> Change-Id: I2b5b65892304e62bf64375458f8ffb9473b2c9b7
> Reviewed-on: https://chromium-review.googlesource.com/826479
> Reviewed-by: Peter Wong <peter.wm.wong@gmail.com>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
> Cr-Commit-Position: refs/heads/master@{#50120}
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
TBR=adamk@chromium.org
Bug: v8:6005
Change-Id: Ie8c8810c5231e933e61ea8babe963e58bb6dcaed
Reviewed-on: https://chromium-review.googlesource.com/831156
Reviewed-by: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Cr-Commit-Position: refs/heads/master@{#50218}
- Added ObjectPrototypeToLocaleString TFJ
- Remove v8natives.js
- Move GetMethod and GetIterator into prologue.js
TBR=adamk@chromium.org
Bug: v8:6005
Change-Id: I2b5b65892304e62bf64375458f8ffb9473b2c9b7
Reviewed-on: https://chromium-review.googlesource.com/826479
Reviewed-by: Peter Wong <peter.wm.wong@gmail.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Peter Wong <peter.wm.wong@gmail.com>
Cr-Commit-Position: refs/heads/master@{#50120}
This refactors the list of redirections of runtime call targets that
simulators maintain to be process-wide (as opposed to be per Isolate).
Such redirections are used for static C++ call targets which themselves
are process-wide, which makes this model a closer fit. Access is already
properly synchronized via a mutex.
Along the way this also introduces the {SimulatorBase} class as a common
base class for all simulator implementations.
R=clemensh@chromium.org
Change-Id: Iae8602c44b1b34cb916dde2b22c9403b0496b3d4
Reviewed-on: https://chromium-review.googlesource.com/823966
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50074}
This is a separation of the DFA Unicode Decoder from
https://chromium-review.googlesource.com/c/v8/v8/+/789560
I attempted to make the DFA's table a bit more explicit in this CL. Still, the
linter prevents me from letting me present the array as a "table" in source
code. For a better representation, please refer to
https://docs.google.com/spreadsheets/d/1L9STtkmWs-A7HdK5ZmZ-wPZ_VBjQ3-Jj_xN9c6_hLKA
- - - - -
Now for a big copy-paste from 789560:
Essentially, reworks a standard FSM (imagine an
array of structs) and flattens it out into a single-dimension array.
Using Table 3-7 of the Unicode 10.0.0 standard (page 126 of
http://www.unicode.org/versions/Unicode10.0.0/ch03.pdf), we can nicely
map all bytes into one of 12 character classes:
00. 0x00-0x7F
01. 0x80-0x8F (split from general continuation because this range is not
valid after a 0xF0 leading byte)
02. 0x90-0x9F (split from general continuation because this range is not
valid after a 0xE0 nor a 0xF4 leading byte)
03. 0xA0-0xBF (the rest of the continuation range)
04. 0xC0-0xC1, 0xF5-0xFF (the joined range of invalid bytes, notice this
includes 255 which we use as a known bad byte during hex-to-int
decoding)
05. 0xC2-0xDF (leading bytes which require any continuation byte
afterwards)
06. 0xE0 (leading byte which requires a 0xA0-0xBF afterwards then any
continuation byte after that)
07. 0xE1-0xEC, 0xEE-0xEF (leading bytes which requires any continuation
afterwards then any continuation byte after that)
08. 0xED (leading byte which requires a 0x80-0x9F afterwards then any
continuation byte after that)
09. 0xF1-F3 (leading bytes which requires any continuation byte
afterwards then any continuation byte then any continuation byte)
10. 0xF0 (leading bytes which requires a 0x90-0xBF afterwards then any
continuation byte then any continuation byte)
11. 0xF4 (leading bytes which requires a 0x80-0x8F afterwards then any
continuation byte then any continuation byte)
Note that 0xF0 and 0xF1-0xF3 were swapped so that fewer bytes were
needed to represent the transition state ("9, 10, 10, 10" vs.
"10, 9, 9, 9").
Using these 12 classes as "transitions", we can map from one state to
the next. Each state is defined as some multiple of 12, so that we're
always starting at the 0th column of each row of the FSM. From each
state, we add the transition and get a index of the new row the FSM is
entering.
If at any point we encounter a bad byte, the state + bad-byte-transition
is guaranteed to map us into the first row of the FSM (which contains no
valid exiting transitions).
The key differences from Björn's original (or his self-modified) DFA is
the "bad" state is now mapped to 0 (or the first row of the FSM) instead
of 12 (the second row). This saves ~50 bytes when gzipping, and also
speeds up determining if a string is properly encoded (see his sample
code at http://bjoern.hoehrmann.de/utf-8/decoder/dfa/#performance).
Finally, I've replace his ternary check with an array access, to make
the algorithm branchless. This places a requirement on the caller to 0
out the code point between successful decodings, which it could always
have done because it's already branching.
R=marja@google.com
Bug:
Change-Id: I574f208a84dc5d06caba17127b0d41f7ce1a3395
Reviewed-on: https://chromium-review.googlesource.com/805357
Commit-Queue: Justin Ridgewell <jridgewell@google.com>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Mathias Bynens <mathias@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50012}
This is a preparation for a larger CL that needs VectorSlotPair
throughtout the compilation chain (including deoptimizer.cc).
Bug: v8:7127
Change-Id: Ia746805ca3fa294eedba19d23656f858840cd501
Reviewed-on: https://chromium-review.googlesource.com/813934
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49928}
Introduce new flag for starting young generation collection early
based on the current new space size.
Bug: v8:6972
Change-Id: I73dd28b8ac7df873b5c3e6ca4b3e55bdec5295a1
Reviewed-on: https://chromium-review.googlesource.com/811304
Commit-Queue: Michał Majewski <majeski@google.com>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49927}
They will eventually be used instead of Tuple3/FixedArray by the IC system.
Bug: v8:5561, v8:7159
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I39faad1b2dc10ce7d42cb7477ea87b64d1e0b44c
Reviewed-on: https://chromium-review.googlesource.com/806178
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49908}
Observer that increases frequency of checking if we reached
marking limit. Works only with --stress-marking.
Bug: v8:6972
Change-Id: I13544fdd8bb33738d78adbac96feb70222b5b634
Reviewed-on: https://chromium-review.googlesource.com/802434
Commit-Queue: Michał Majewski <majeski@google.com>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49907}
Rename to better capture what the files contain.
Removed includes of wasm-code-manager.h from .h files to improve
build time.
Bug:
Change-Id: I0f0108cfb00b061c4433b6ff9670e9c4cae9c699
Reviewed-on: https://chromium-review.googlesource.com/807368
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49875}
This is a small refactoring that moves the WasmCodeManager and
CompilationManager from being a part of the Isolate directly to living in a new
WasmEngine object. This makes it easier to change Wasm components without
rebuilding so much of V8, and also enables future changes to Wasm without
affecting unrelated parts of V8.
Bug: v8:7109
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ic89bfc3974483aa909d12556d1386e18785a1d71
Reviewed-on: https://chromium-review.googlesource.com/804824
Commit-Queue: Eric Holk <eholk@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49848}
The motivation is to avoid bugs such as the one fixed in
https://chromium-review.googlesource.com/c/v8/v8/+/800270.
Bug: v8:7109
Change-Id: I82a55f4a78d289d00ae7bafe78b45d92bab07a6b
Reviewed-on: https://chromium-review.googlesource.com/800291
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49829}
LiftoffRegister is an abstraction over Register and DoubleRegister.
Many functions in Liftoff do not need to distinguish GP and FP
registers. LiftoffRegister allows to implement most functions
generically. Accessors allow to convert them back to Register or
DoubleRegister.
Both register types are represented in a unified index space, which
allows to extend this concept to more register types and implement
aliasing in a straight-forward manner.
Many functions currently only implement the GP case. FP will be added
later.
R=titzer@chromium.org
Bug: v8:6600
Change-Id: I043b787bc09dd1a06506ad515eb325b8ea19746d
Reviewed-on: https://chromium-review.googlesource.com/793390
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49780}
This prefixes the flag to be more uniform with existing flags and makes
it available as a gn argument.
The switch feature is enabled on a subset of bots, the linux64 release
trybot and all sanitizers. Note, this doesn't switch to slow paths -
it just allows to use the runtime flag on those bots.
Bug: v8:7120
Change-Id: I706a7a9bd503c13d5432cac9a13a909f4f32a0a7
Reviewed-on: https://chromium-review.googlesource.com/798412
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49739}
Prior to this change, the exponentiation operator was rewritten by the
parser to a call of the Math.pow builtin. However, Math.pow does not
accept BigInt arguments, while the exponentiation operator must accept
them.
This CL
- removes the parser's special treatment of ** and **=, treating them
like any other binary op instead.
- adds a TFC builtin Exponentiate that does the right thing for
all inputs.
- adds interpreter bytecodes Exp and ExpSmi whose handlers call the
Exponentiate builtin. For simplicity, they currently always collect
kAny feedback.
- adds a Turbofan operator JSExponentiate with a typed-lowering to
the existing NumberPow and a generic-lowering to the Exponentiate
builtin. There is currently no speculative lowering.
Note that exponentiation for BigInts is actually not implemented yet,
so we can't yet test it.
Bug: v8:6791
Change-Id: Id90914c9c3fce310ce01e715c09eaa9f294f4f8a
Reviewed-on: https://chromium-review.googlesource.com/785694
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Sathya Gunasekaran <gsathya@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49696}
This is the first step towards wasm code sharing. This CL moves wasm
code generation outside the JavaScript GC heap using the previously -
introduced WasmCodeManager (all this, behind the --wasm-jit-to-native
flag).
See design document: go/wasm-on-native-heap-stage-1
This CL doesn't change other wasm architectural invariants. We still
have per-Isolate wasm code generation, and per-wasm module instance
code specialization.
Bug:v8:6876
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I1e08cecad75f93fb081545c31228a4568be276d3
Reviewed-on: https://chromium-review.googlesource.com/674086
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49689}
Free ArrayBuffer backing stores on a background thread, rather than
blocking the main thread after processing. Could potentially cause
contention with the array buffer allocator once JS execution resumes.
The new ArrayBufferCollector class tracks these dead allocations.
Later, the processing of array buffers can happen in parallel.
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng;master.tryserver.v8:v8_linux64_tsan_rel;master.tryserver.v8:v8_linux64_tsan_concurrent_marking_rel_ng;master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_optional_gpu_tests_rel;master.tryserver.chromium.mac:mac_optional_gpu_tests_rel;master.tryserver.chromium.win:win_optional_gpu_tests_rel;master.tryserver.chromium.android:android_optional_gpu_tests_rel
Bug: v8:6992
Change-Id: I2b74f008f79521414374f607ed510f66508af160
Reviewed-on: https://chromium-review.googlesource.com/779182
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49505}
This reverts commit b6658adee0.
Reason for revert: Breaks TSAN :(
Original change's description:
> [heap] Concurrently free ArrayBuffer allocations.
>
> Free ArrayBuffer backing stores on a background thread, rather than
> blocking the main thread after processing. Could potentially cause
> contention with the array buffer allocator once JS execution resumes.
>
> The new ArrayBufferCollector class tracks these dead allocations.
>
> Later, the processing of array buffers can happen in parallel.
>
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
>
> Bug: v8:6992
> Change-Id: I49ae4db12ed62d8400ba2bbafeda05a11479d904
> Reviewed-on: https://chromium-review.googlesource.com/739829
> Commit-Queue: Peter Marshall <petermarshall@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Hannes Payer <hpayer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49485}
TBR=hpayer@chromium.org,mlippautz@chromium.org,petermarshall@chromium.org
Change-Id: If6743b83f871c0fd0d6e83a3083dce0eecd99021
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:6992
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/779159
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49488}
Free ArrayBuffer backing stores on a background thread, rather than
blocking the main thread after processing. Could potentially cause
contention with the array buffer allocator once JS execution resumes.
The new ArrayBufferCollector class tracks these dead allocations.
Later, the processing of array buffers can happen in parallel.
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Bug: v8:6992
Change-Id: I49ae4db12ed62d8400ba2bbafeda05a11479d904
Reviewed-on: https://chromium-review.googlesource.com/739829
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Hannes Payer <hpayer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49485}
When using ninja to build without specifying explicit targets,
all existing targets in any BUILD.gn file are built/executed.
We now hide the snapshot targets behind the snapshot condition
to prevent them from being built and executed in nosnap builds.
CQ_INCLUDE_TRYBOTS=master.tryserver.v8:v8_linux_nosnap_rel
Bug: v8:7089
Change-Id: I4cd8ebadc377fd20b3887e9628990a75732ab74c
Reviewed-on: https://chromium-review.googlesource.com/778320
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49477}
This CL creates the invariant that the BigInt class treats
BigInt objects as immutable. Writing to new BigInt objects
as part of their construction is done by the MutableBigInt
helper class, which in turn is hidden as an implementation
detail in bigint.cc.
As a side effect, this refactoring enforces right-trimming
checks for all newly created BigInts, and ensures that all
BigInt allocations possibly exceeding kMaxLength check for
this case and throw a RangeError instead of crashing.
Bug: v8:6791
Tbr: mlippautz@chromium.org
Change-Id: Id239746108e6b076b47a03ba37462001eb501507
Reviewed-on: https://chromium-review.googlesource.com/742329
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49462}
This CL also includes fixes for CF issues found while the previous
reland was active.
Bug: v8:5799, chromium:783902, chromium:783926, chromium:783822
Change-Id: I1f7d9b037d90838469c45f5d72771a77444c662e
Reviewed-on: https://chromium-review.googlesource.com/764067
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49457}
There was a data race in the access of the foreground_task_runner_map_.
I protect each access to foreground_task_runner_map_ with a lock now.
Original change's description:
> [platform] Implement TaskRunners in the DefaultPlatform
>
> This CL implements the TaskRunners in the DefaultPlatform which has been
> added recently to the platform API. In addition I changed how task
> posting works on the DefaultPlatform.
>
> With this implementation the DefaultPlatform keeps one
> DefaultForegroundTaskRunner per isolate, plus one
> DefaultBackgroundTaskRunner. The DefaultPlatform owns these TaskRunners
> with a shared_ptr, which is also shared with any caller of
> GetForegroundTaskRunner or GetBackgroundTaskrunner.
>
> This CL moves the task management from the DefaultPlatform to the
> TaskRunners. The DefaultForegroundTaskRunner owns and manages the the
> task queue, the delayed task queue, and the idle task queue. The
> DefaultBackgroundTaskRunner owns the WorkerThread pool and the
> background task queue.
>
> In addition changed many Task* to std::unique_ptr<Task> to document task
> ownership.
>
> R=rmcilroy@chromium.org
>
> Change-Id: Ib9a01f1f45e5b48844a37d801f884210ec3f6c27
> Reviewed-on: https://chromium-review.googlesource.com/753583
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49354}
Change-Id: Iddccdb07bde1a799815ec6ed6af37082df4987c7
Reviewed-on: https://chromium-review.googlesource.com/770970
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49379}
This reverts commit 8de2e6db02.
Reason for revert: Suspect for:
https://build.chromium.org/p/client.v8/builders/V8%20Win32%20-%20nosnap%20-%20shared/builds/24237https://build.chromium.org/p/client.v8/builders/V8%20Win64/builds/20896
Original change's description:
> [platform] Implement TaskRunners in the DefaultPlatform
>
> This CL implements the TaskRunners in the DefaultPlatform which has been
> added recently to the platform API. In addition I changed how task
> posting works on the DefaultPlatform.
>
> With this implementation the DefaultPlatform keeps one
> DefaultForegroundTaskRunner per isolate, plus one
> DefaultBackgroundTaskRunner. The DefaultPlatform owns these TaskRunners
> with a shared_ptr, which is also shared with any caller of
> GetForegroundTaskRunner or GetBackgroundTaskrunner.
>
> This CL moves the task management from the DefaultPlatform to the
> TaskRunners. The DefaultForegroundTaskRunner owns and manages the the
> task queue, the delayed task queue, and the idle task queue. The
> DefaultBackgroundTaskRunner owns the WorkerThread pool and the
> background task queue.
>
> In addition changed many Task* to std::unique_ptr<Task> to document task
> ownership.
>
> R=rmcilroy@chromium.org
>
> Change-Id: Ib9a01f1f45e5b48844a37d801f884210ec3f6c27
> Reviewed-on: https://chromium-review.googlesource.com/753583
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49354}
TBR=rmcilroy@chromium.org,ahaas@chromium.org
Change-Id: I6c381915a2cae8ea1a0d21d6cfa6e797ccd2d947
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/768748
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49357}
This CL implements the TaskRunners in the DefaultPlatform which has been
added recently to the platform API. In addition I changed how task
posting works on the DefaultPlatform.
With this implementation the DefaultPlatform keeps one
DefaultForegroundTaskRunner per isolate, plus one
DefaultBackgroundTaskRunner. The DefaultPlatform owns these TaskRunners
with a shared_ptr, which is also shared with any caller of
GetForegroundTaskRunner or GetBackgroundTaskrunner.
This CL moves the task management from the DefaultPlatform to the
TaskRunners. The DefaultForegroundTaskRunner owns and manages the the
task queue, the delayed task queue, and the idle task queue. The
DefaultBackgroundTaskRunner owns the WorkerThread pool and the
background task queue.
In addition changed many Task* to std::unique_ptr<Task> to document task
ownership.
R=rmcilroy@chromium.org
Change-Id: Ib9a01f1f45e5b48844a37d801f884210ec3f6c27
Reviewed-on: https://chromium-review.googlesource.com/753583
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49354}
- Remove weak-collection.js
- Adds TFJ builtins for WeakSet and WeakMap constructors
- Unified helpers and constructor behavior into a BaseCollectionsAssembler
- Fast paths for...
- unmodified constructor function
- argument is a fast JS array
- entries are fast JS arrays, for Map/WeakMap
- no arguments passed
Quick benchmarks shows significant improvements (1.12x - 5.7x!) for ALL collection constructors (weak and non-weak):
https://github.com/peterwmwong/v8-perf/blob/master/weakcollection-constructor/README.md
More could be done for performance. Currently we always call out to JS to add entries, if we knew the prototype was unmodified, we could call the builtins directly.
Bug: v8:5049, v8:6604
Change-Id: Id7912c1eed5bcf512df7fd6238f04166a8a5937e
Reviewed-on: https://chromium-review.googlesource.com/760385
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49343}
Since each Array literal containing a spread is individually queued for
rewriting, there's no need for an AstVisitor here: a simple linear
pass through the queue is sufficient.
This patch deletes AstExpressionRewriter and all the machinery supporting
it in the AST. This code was built with the idea of using it as
a general expression rewriting mechanism in the parser, but those use
cases never materialized, and Array spread remains the only thing
that used this code.
Bug: v8:6092
Change-Id: I754c4883099e840881b005f20216f86e57721d5a
Reviewed-on: https://chromium-review.googlesource.com/765051
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49337}
We'll use one generic isolate for all number fuzzers. The previous
deopt isolate will be deleted, once the infra hooks have changed.
Bug: v8:6917
Change-Id: I809613548cd935a0208febb002572cc063697324
Reviewed-on: https://chromium-review.googlesource.com/763534
Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49297}
Thanks Igor and Jakob for the hard work to migrate ICs to data-driven handlers!
This is done as of this CL.
Bug: v8:5561
Change-Id: Icf1ddf0065e3aa85ac7efe4b99f74821ce3c0ac2
Reviewed-on: https://chromium-review.googlesource.com/756842
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49203}
This commit updates the jobs for generating postmortem
metadata. I96a8a7cdded6f7c37b6f1da659d63df9e3a5de2b moved
the Code class to a new file without updating the postmortem
jobs. This resulted in some constants used by Node.js to
disappear, leading to build failures on SmartOS.
See: https://github.com/nodejs/node-v8/issues/21
Bug:
Change-Id: Icf5f59fe464d933c4f5a3f622b08c01bc43c6a80
Reviewed-on: https://chromium-review.googlesource.com/741919
Commit-Queue: Yang Guo <yangguo@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49168}
This is a reland of a9a50dc9a8
Buildbot crashes are fixed by a274fc6.
Original change's description:
> [heap] Temporarily disable concurrent marking.
>
> The 6.3 branch has a data race that is fixed in 6.4 but the fix is too
> large for back merging.
>
> This CL will be back-merged to 6.3 after getting Canary coverage.
>
> Concurrent marking will be re-enabled afterwards.
>
> Bug: chromium:774644
> Change-Id: I4112da0e133a637cc4fb52dee2e4c165cdc74f1f
> Reviewed-on: https://chromium-review.googlesource.com/749811
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49080}
Bug: chromium:774644
Change-Id: Idf5d179eca25a1481c70c6ca3bccde4869deb544
Reviewed-on: https://chromium-review.googlesource.com/751271
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49090}
This reverts commit a9a50dc9a8.
Reason for revert: buildbot crashes.
Original change's description:
> [heap] Temporarily disable concurrent marking.
>
> The 6.3 branch has a data race that is fixed in 6.4 but the fix is too
> large for back merging.
>
> This CL will be back-merged to 6.3 after getting Canary coverage.
>
> Concurrent marking will be re-enabled afterwards.
>
> Bug: chromium:774644
> Change-Id: I4112da0e133a637cc4fb52dee2e4c165cdc74f1f
> Reviewed-on: https://chromium-review.googlesource.com/749811
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49080}
TBR=ulan@chromium.org,hpayer@chromium.org,mlippautz@chromium.org
Change-Id: Ia9d2128c01b811073c1c8f0392eb13b7d7745cd1
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:774644
Reviewed-on: https://chromium-review.googlesource.com/751501
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49083}
The 6.3 branch has a data race that is fixed in 6.4 but the fix is too
large for back merging.
This CL will be back-merged to 6.3 after getting Canary coverage.
Concurrent marking will be re-enabled afterwards.
Bug: chromium:774644
Change-Id: I4112da0e133a637cc4fb52dee2e4c165cdc74f1f
Reviewed-on: https://chromium-review.googlesource.com/749811
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49080}
Add the --trace-feedback-updates flag (disabled by default, enabled by
the v8_enable_trace_feedback_updates gn arg), which traces updates to
feedback slots.
Change-Id: Ib8f02f958e2adf04abda5d4ed680e29fa04895ab
Reviewed-on: https://chromium-review.googlesource.com/725814
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48983}
This is the first step towards lazy-deserializing bytecode handlers.
Bytecode handler code objects are now serialized into the builtins
snapshot area (which, like many other related concepts, has become
somewhat of a misnomer now that it contains both builtins and
handlers).
Handlers are still eagerly-deserialized upon Isolate creation. This will
change in follow-up CLs.
Bug: v8:6624
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I7b257f76f5e9e90d5f7b183980bae7bc621171fc
Reviewed-on: https://chromium-review.googlesource.com/738030
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Mythri Alle <mythria@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48977}
The current_cpu value was erroneously removed from the build config json.
In multi-arch builds, each toolchain subdirectory in the build-product
output emits its own build-config json, where current_cpu determines
the architecture type of the sub-build.
Correctness-fuzzer runs could wrongly determined x86 sub-builds as x64.
Bug: chromium:777285
Change-Id: I5104630cd8ebbd263d557fb29771a31a2a1d78c2
Reviewed-on: https://chromium-review.googlesource.com/737797
Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48950}
Port 266e803ea9
Original Commit Message:
This CL adds a first implementation of Liftoff, the new wasm baseline
compiler, for x64 and ia32. It currently supports the most important
i32 instructions and control instructions. Whenever it encounters an
instruction it does not support yet, it aborts.
In a subsequent CL, Liftoff will be called from the
WasmCompilationUnit, falling back to Turbofan compilation if the
baseline compiler bails out.
R=joransiu@ca.ibm.com, jyan@ca.ibm.com, michael_dawson@ca.ibm.com, clemensh@chromium.org, titzer@chromium.org
BUG=
LOG=N
Change-Id: I35ad2b0230c37f523e24aa90b637a67e5ce59083
Reviewed-on: https://chromium-review.googlesource.com/735784
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Junliang Yan <jyan@ca.ibm.com>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48935}
This CL adds a first implementation of Liftoff, the new wasm baseline
compiler, for x64 and ia32. It currently supports the most important
i32 instructions and control instructions. Whenever it encounters an
instruction it does not support yet, it aborts.
In a subsequent CL, Liftoff will be called from the
WasmCompilationUnit, falling back to Turbofan compilation if the
baseline compiler bails out.
R=titzer@chromium.org
Bug: v8:6600
Change-Id: Ifa78fb9d546dce72c241ff01a251dfa13cb31c1d
Reviewed-on: https://chromium-review.googlesource.com/716480
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48832}
Encapsulates special reservation / allocation behavior for builtin
serialization.
This allows us to remove special logic around kNextChunk in builtin
deserialization (since we don't generate that bytecode anymore for
builtins).
Bug: v8:6624
Change-Id: Ice7673006cee53b9d11cdfb7f84d4175221c7984
Reviewed-on: https://chromium-review.googlesource.com/720357
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48725}
This ports the build_config json from GN to GYP to prepare deprecating
tedious flags passing to the test runner.
This also removes two unused GN flags that only hold temporary values.
Bug: v8:6917
Change-Id: I976185f1541277dc5c9bfbaa7578f35c19dd254c
Reviewed-on: https://chromium-review.googlesource.com/725706
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48715}
A continuation of the work in 59e4b751, this extracts logic around
memory reservation and allocations out of the Deserializer class.
Follow-up work is planned to create a specialized allocator for
builtin deserialization.
Bug: v8:6624
Change-Id: I7081cdc557ab8fb2571aadb816399e136ea2cdbb
Reviewed-on: https://chromium-review.googlesource.com/716036
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48634}
Port the baseline version of Reflect.has to the CodeStubAssembler and
reuse the existing logic for HasProperty (i.e. the HasProperty builtin).
Also inline the Reflect.has builtin into TurboFan, by adding a check
on the target in front of a use of the JSHasProperty operator.
Technically this additional check is not necessary, because the
JSHasProperty operator already throws if the target is not a JSReceiver,
but the exception message is confusing then.
This improves the performance of the micro-benchmark from
reflectHasPresent: 337 ms.
reflectHasAbsent: 472 ms.
to
reflectHasPresent: 121 ms.
reflectHasAbsent: 216 ms.
which is a nice 2.8x improvement in the best case. It also improves the
chai test on the web-tooling-benchmark by around 1-2%, which is roughly
the expected win (since Reflect.has overall accounts for around 3-4%).
Bug: v8:5996, v8:6936, v8:6937
Change-Id: I856183229677a71c19936f06f2a4fc7a794a9a4a
Reviewed-on: https://chromium-review.googlesource.com/720959
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48608}
This file was somehow inexplicably not moved when other parsing files were.
BUG=v8:6921
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Iea92c61f83dbb5a8688c404ba87d35fa58e749b9
Reviewed-on: https://chromium-review.googlesource.com/718197
Commit-Queue: Marja Hölttä <marja@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48522}
This makes all inline allocation constructions go through the existing
{AllocationBuilder} helper class. It hence ensures there is a single
place for all sanity checking and and makes use-sites easier to read.
R=jarin@chromium.org
Change-Id: Ib5daf48acd93c631fccdfa095eda1afda7048115
Reviewed-on: https://chromium-review.googlesource.com/709056
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Stanton <mvstanton@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48502}
Sometimes, the embedder might want to merge a fix to an abandoned branch
or to a supported branch but the fix is not relevant to Chromium.
This adds a new version string that the embedder can set at compile time
and that will be appended to the official V8 version.
The separator must be provided in the string. For instance, to have a
full version string like "6.0.287.53-emb.1", the embedder must set
V8_EMBEDDER_STRING to "-emb.1".
Related Node.js issue: https://github.com/nodejs/node/pull/9754
BUG=v8:5740
R=machenbach@chromium.org
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ifa2d9bd213795e6d54886436f8c3787ac6162823
Reviewed-on: https://chromium-review.googlesource.com/690475
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Michaël Zasso <mic.besace@gmail.com>
Cr-Commit-Position: refs/heads/master@{#48301}
With --wasm-trace-memory, both compiled code and the interpreter will
output each memory load or store. This helps to debug miscompilations in
emscripten or in V8, like the referenced bug.
R=titzer@chromium.org
Bug: chromium:718858
Change-Id: I90704d164975b11c65677f86947ab102242d5153
Reviewed-on: https://chromium-review.googlesource.com/684316
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48255}
There are only very few custom compiled IC handlers left that go in there, and for each compiled handler we only have 1 cache hit on top25; maximally saving 60ms over 33s. Additionally we'll migrate the remaining handlers to data-driven handlers anyway. Let's try to remove this code.
Bug:
Change-Id: Ib874cc498015046a3ff67c83ea8b10b3c4eb7d0f
Reviewed-on: https://chromium-review.googlesource.com/668409
Commit-Queue: Toon Verwaest <verwaest@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48201}
ZoneList still used List as a base class, so this CL merges the two
classes together. We also remove unused functions in List and ZoneList.
We keep the inline header but move it to src/zone/zone-list-inl.h. The
includes that use this header are still quite tangled, but we can fix
that later.
Bug: v8:6333
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Ia809813834b2328ff616623f8a843812a1eb42a7
Reviewed-on: https://chromium-review.googlesource.com/681658
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48200}
The members of HandleScopeImplementer are copied with memcpy when
the isolate is transferred to another thread. List contained some
primitives which allowed us to manually free the backing store, which
was needed in order to ensure that threads would not hold on to
old pointers and use them later. With std::vector, we can't do that.
Here we change the HandleScopeImplementer to instead use a custom
structure DetachableVector, which contains a std::vector but allows
manual detaching and freeing of the backing store. This allows us to
maintain the old behavior.
Bug: v8:6333
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I6361d161cdb19878ba19ed51d6ba2fae99e8cdc0
Reviewed-on: https://chromium-review.googlesource.com/660125
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48197}
Tagged templates were previously desugared during parsing using some
combination of runtime support written in JavaScript and C++, which
prevented some optimizations from happening, namely the constant folding
of the template object in TurboFan optimized code. This CL adds a new
bytecode GetTemplateObject (with a corresponding GetTemplateObject AST
node), which represents the abstract operation in the ES6 specification
and allows TurboFan to simply constant-fold template objects at compile
time (which is explicitly supported by the specification).
This also pays down some technical debt by removing the template.js
runtime support and therefore should reduce the size of the native
context (snapshot) a bit.
With this change in-place the ES6 version microbenchmark in the
referenced tracking bug is now faster than the transpiled Babel
code, it goes from
templateStringTagES5: 4552 ms.
templateStringTagES6: 14185 ms.
templateStringTagBabel: 7626 ms.
to
templateStringTagES5: 4515 ms.
templateStringTagES6: 7491 ms.
templateStringTagBabel: 7639 ms.
which corresponds to a solid 45% reduction in execution time. With some
further optimizations the ES6 version should be able to outperform the
ES5 version. This micro-benchmark should be fairly representative of the
six-speed-templatestringtag-es6 benchmark, and as such that benchmark
should also improve by around 50%.
Bug: v8:6819,v8:6820
Tbr: mlippautz@chromium.org
Change-Id: I821085e3794717fc7f52b5c306fcb93ba03345dc
Reviewed-on: https://chromium-review.googlesource.com/677462
Reviewed-by: Mythri Alle <mythria@chromium.org>
Reviewed-by: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Adam Klein <adamk@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48126}
This changes CPU check to use 'target_cpu' instead of 'v8_target_cpu'.
Bug: chromium:694255
Change-Id: Ic3ad5253e4e0b66b13e9f16a5842bcf49881fa52
Reviewed-on: https://chromium-review.googlesource.com/677994
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48119}
Along with BigInt.prototype. Their functions only have skeleton
implementations. The purpose of this change is to make it easier
to gradually increase test coverage (e.g. for toString(radix)).
Of course this is still behind the --harmony-bigint flag.
Bug: v8:6791
Change-Id: Ic307fd9165c56ac782fba18d648ce893daaa718f
Reviewed-on: https://chromium-review.googlesource.com/671209
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48094}
Removes
- SequentialMarkingDeque
- The ability to handle marking deque overflow
- BlackToGrey transitions
We switched to a different marking work list on M61 that fails
in OOM upon failing to allocate Segments used in the work list.
Bug: chromium:758570
Change-Id: I66e2ab912271bf84b085dccc9b4bdd96076b64fb
Reviewed-on: https://chromium-review.googlesource.com/632676
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48078}
This CL refactors allocation & reservation logic into a new
DefaultSerializerAllocator class. In upcoming work, this will be
further extended by a custom allocator for builtin serialization.
Additionally, this cleans up a bunch of cosmetics (encapsulation and
other nits).
Bug: v8:6624
Change-Id: Ibcf12a525c8fcb26d9c16b7a12fd598c37a0e10a
Reviewed-on: https://chromium-review.googlesource.com/650357
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48077}
This reverts commit ee5c31f335.
Reason for revert: Fixed compiler failure
Original change's description:
> Revert "[wasm] A simple allocator datastructure for off-the heap"
>
> This reverts commit 110d9ab005.
>
> Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug%20builder/builds/26607
>
> Surprising we're seeing a failure on Linux 64 *after* CQ. Is the compiler there different?
>
> Original change's description:
> > [wasm] A simple allocator datastructure for off-the heap
> >
> > We'll use this allocator in a follow-up CL to:
> > - allocate speculative sizes of memory for a module that's being
> > compiled (e.g. 2*size of wasm code).
> > - each module will own such a sub-pool, and then use it to allocate
> > contiguous chunks of memory for code.
> >
> > The underlying assumptions for the chosen allocation strategy is that:
> > - the allocation granularity for pools is 1 page, so that no one page
> > is owned by more than one wasm module
> > - typical pool sizes (given module sizes) are multiple pages.
> > - modules and module instances are typically few and long lived. Typically,
> > we expect one module and one instance.
> >
> > This means we shouldn't expect fragmentations that lead to code being
> > non-allocatable, or prohibitively many ranges.
> >
> > The data structure just manages ranges of addresses. Virtual memory management
> > will be separate, as part of the responsibility of a "WasmHeap"
> > that will be introduced in the future. So will concurrency control.
> >
> > Bug:
> > Change-Id: Id99f46d10c25553b013054d994760f3c2a737c39
> > Reviewed-on: https://chromium-review.googlesource.com/669296
> > Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
> > Reviewed-by: Eric Holk <eholk@chromium.org>
> > Reviewed-by: Brad Nelson <bradnelson@chromium.org>
> > Cr-Commit-Position: refs/heads/master@{#48053}
>
> TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org
>
> Change-Id: Id82fa341b77624e4971f24c4757a9a666a65930c
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Reviewed-on: https://chromium-review.googlesource.com/670141
> Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
> Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48054}
TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org
Change-Id: Ib6a7a3e6098d2689e60cdca85ec77e57e5295e48
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/670142
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48055}
This reverts commit 110d9ab005.
Reason for revert: https://build.chromium.org/p/client.v8/builders/V8%20Linux64%20-%20debug%20builder/builds/26607
Surprising we're seeing a failure on Linux 64 *after* CQ. Is the compiler there different?
Original change's description:
> [wasm] A simple allocator datastructure for off-the heap
>
> We'll use this allocator in a follow-up CL to:
> - allocate speculative sizes of memory for a module that's being
> compiled (e.g. 2*size of wasm code).
> - each module will own such a sub-pool, and then use it to allocate
> contiguous chunks of memory for code.
>
> The underlying assumptions for the chosen allocation strategy is that:
> - the allocation granularity for pools is 1 page, so that no one page
> is owned by more than one wasm module
> - typical pool sizes (given module sizes) are multiple pages.
> - modules and module instances are typically few and long lived. Typically,
> we expect one module and one instance.
>
> This means we shouldn't expect fragmentations that lead to code being
> non-allocatable, or prohibitively many ranges.
>
> The data structure just manages ranges of addresses. Virtual memory management
> will be separate, as part of the responsibility of a "WasmHeap"
> that will be introduced in the future. So will concurrency control.
>
> Bug:
> Change-Id: Id99f46d10c25553b013054d994760f3c2a737c39
> Reviewed-on: https://chromium-review.googlesource.com/669296
> Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
> Reviewed-by: Eric Holk <eholk@chromium.org>
> Reviewed-by: Brad Nelson <bradnelson@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#48053}
TBR=bradnelson@chromium.org,mtrofin@chromium.org,eholk@chromium.org
Change-Id: Id82fa341b77624e4971f24c4757a9a666a65930c
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/670141
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48054}
We'll use this allocator in a follow-up CL to:
- allocate speculative sizes of memory for a module that's being
compiled (e.g. 2*size of wasm code).
- each module will own such a sub-pool, and then use it to allocate
contiguous chunks of memory for code.
The underlying assumptions for the chosen allocation strategy is that:
- the allocation granularity for pools is 1 page, so that no one page
is owned by more than one wasm module
- typical pool sizes (given module sizes) are multiple pages.
- modules and module instances are typically few and long lived. Typically,
we expect one module and one instance.
This means we shouldn't expect fragmentations that lead to code being
non-allocatable, or prohibitively many ranges.
The data structure just manages ranges of addresses. Virtual memory management
will be separate, as part of the responsibility of a "WasmHeap"
that will be introduced in the future. So will concurrency control.
Bug:
Change-Id: Id99f46d10c25553b013054d994760f3c2a737c39
Reviewed-on: https://chromium-review.googlesource.com/669296
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Eric Holk <eholk@chromium.org>
Reviewed-by: Brad Nelson <bradnelson@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48053}
This is a reland of dbfdd4f9e9
Original change's description:
> [heap] Turn on v8_enable_csa_write_barrier
>
> With this commit, write barrier is switched to use CodeStubAssembler.
>
> Bug: chromium:749486
> Change-Id: I7e0914bee971e4f3a3257740ae7c83b31f791bd9
> Reviewed-on: https://chromium-review.googlesource.com/598088
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Albert Mingkun Yang <albertnetymk@google.com>
> Cr-Commit-Position: refs/heads/master@{#48006}
Bug: chromium:749486
Change-Id: I00933d989568c82b5fbaf6203bb146c65f8e4282
Reviewed-on: https://chromium-review.googlesource.com/668636
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Albert Mingkun Yang <albertnetymk@google.com>
Cr-Commit-Position: refs/heads/master@{#48045}
This reverts commit dbfdd4f9e9.
Reason for revert: https://clusterfuzz.com/v2/testcase-detail/5493096547876864?noredirect=1
Original change's description:
> [heap] Turn on v8_enable_csa_write_barrier
>
> With this commit, write barrier is switched to use CodeStubAssembler.
>
> Bug: chromium:749486
> Change-Id: I7e0914bee971e4f3a3257740ae7c83b31f791bd9
> Reviewed-on: https://chromium-review.googlesource.com/598088
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Commit-Queue: Albert Mingkun Yang <albertnetymk@google.com>
> Cr-Commit-Position: refs/heads/master@{#48006}
TBR=ulan@chromium.org,albertnetymk@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: chromium:749486
Change-Id: I8cf6a3f1d2ea607a0160b37b797d743b88b004b5
Reviewed-on: https://chromium-review.googlesource.com/667018
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Albert Mingkun Yang <albertnetymk@google.com>
Cr-Commit-Position: refs/heads/master@{#48036}
This was supposedly a runtime flag, but we baked it into the snapshot
anyway.
Change-Id: I09d43183c4c2d59336c1077089119d6cb65dfd87
Reviewed-on: https://chromium-review.googlesource.com/664721
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Peter Marshall <petermarshall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48026}
With this commit, write barrier is switched to use CodeStubAssembler.
Bug: chromium:749486
Change-Id: I7e0914bee971e4f3a3257740ae7c83b31f791bd9
Reviewed-on: https://chromium-review.googlesource.com/598088
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Albert Mingkun Yang <albertnetymk@google.com>
Cr-Commit-Position: refs/heads/master@{#48006}
Previously instructions-arm64.h was alternatively defining or declaring
some constants based on whether or not ARM64_DEFINE_FP_STATICS was defined,
and it was assumed that exactly one file would include this header with
the macro defined.
In jumbo builds, the header guards in instructions-arm64.h meant that the
resulting state of the header file would be whichever of the two cases
that appeared first in the compilation unit. This would cause multiple
definitions in some cases and no definitions in some other cases (or if
you were really lucky, it would work out ok).
Let's move these constants to a separate source file temporarily, to be
excluded from jumbo compilation units. This code should eventually be
replaced with a cleaner solution.
Bug: chromium:746958
Change-Id: I7edb1821ef408afd50c6b236d63d3c07f955b58f
Reviewed-on: https://chromium-review.googlesource.com/663898
Commit-Queue: Mostyn Bramley-Moore <mostynb@opera.com>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#48003}
BigInt is a new primitive type of arbitrary precision integers,
proposed in https://tc39.github.io/proposal-bigint.
This CL introduces a corresponding instance type, map, and C++
class to V8 and adds BigInt support to a few operations (see the
test file). Much more is to come. Also, the concrete representation
of BigInts is not yet fixed, currently a BigInt is simply a wrapped
Smi.
Bug: v8:6791
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Ia2901948efd7808f17cfc945f0d56e23e8ae0b45
Reviewed-on: https://chromium-review.googlesource.com/657022
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47956}
TSAN finds data races in generated JavaScript code that use
access the SharedArrayBuffer backing store racily. These are races, but
they are OK in the sense that the JavaScript memory model allows for the
potential bad behavior they could introduce (e.g. potentially tearing
reads). Relaxed atomics could be used here instead, but that could
introduce performance regressions.
This change adds TSAN annotations to the TypedArray reads/writes to
prevent TSAN from warning about them.
Bug: chromium:722871
Change-Id: I0776475f02a352b678ade7d32ed6bd4a6be98c36
Reviewed-on: https://chromium-review.googlesource.com/656509
Commit-Queue: Ben Smith <binji@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47929}
This removes the ability to create a copy of a code-stub with a given
replacement pattern applied. It is in preparation of having the ability
to write-protect code objects.
R=ishell@chromium.org
BUG=v8:6409
Change-Id: Id7528b3bfc53ece73d8c58b0ac96c6e5702a9d45
Reviewed-on: https://chromium-review.googlesource.com/654605
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47914}
This finally allows to include the factory.h header without having to
also inlcude the object-inl.h inline header. It will in turn enable the
removal of the last inline header inclusion violation.
R=marja@chromium.org
Change-Id: Ice2821e1f74cf428d80c8ebf606a218026f37677
Reviewed-on: https://chromium-review.googlesource.com/654862
Reviewed-by: Marja Hölttä <marja@chromium.org>
Commit-Queue: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47880}
This reduces the arm32 binary by around 20kB.
R=jkummerow@chromium.org, mstarzinger@chromium.org
Bug: v8:6055
Change-Id: If9098e49793b29dceb8292aff6f668ca28a07728
Reviewed-on: https://chromium-review.googlesource.com/652427
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47863}
This CL adds support to optimize for..in in fast enum-cache mode to the
same degree that it was optimized in Crankshaft, without adding the same
deoptimization loop that Crankshaft had with missing enum cache indices.
That means code like
for (var k in o) {
var v = o[k];
// ...
}
and code like
for (var k in o) {
if (Object.prototype.hasOwnProperty.call(o, k)) {
var v = o[k];
// ...
}
}
which follows the https://eslint.org/docs/rules/guard-for-in linter
rule, can now utilize the enum cache indices if o has only fast
properties on the receiver, which speeds up the access o[k]
significantly and reduces the pollution of the global megamorphic
stub cache.
For example the micro-benchmark in the tracking bug v8:6702 now runs
faster than ever before:
forIn: 1516 ms.
forInHasOwnProperty: 1674 ms.
forInHasOwnPropertySafe: 1595 ms.
forInSum: 2051 ms.
forInSumSafe: 2215 ms.
Compared to numbers from V8 5.8 which is the last version running with
Crankshaft
forIn: 1641 ms.
forInHasOwnProperty: 1719 ms.
forInHasOwnPropertySafe: 1802 ms.
forInSum: 2226 ms.
forInSumSafe: 2409 ms.
and V8 6.0 which is the current stable version with TurboFan:
forIn: 1713 ms.
forInHasOwnProperty: 5417 ms.
forInHasOwnPropertySafe: 5324 ms.
forInSum: 7556 ms.
forInSumSafe: 11067 ms.
It also improves the throughput on the string-fasta benchmark by
around 7-10%, and there seems to be a ~5% improvement on the
Speedometer/React benchmark locally.
For this to work, the ForInPrepare bytecode was split into
ForInEnumerate and ForInPrepare, which is very similar to how it was
handled in Fullcodegen initially. In TurboFan we introduce a new
operator LoadFieldByIndex that does the dynamic property load.
This also removes the CheckMapValue operator again in favor of
just using LoadField, ReferenceEqual and CheckIf, which work
automatically with the EscapeAnalysis and the
BranchConditionElimination.
Bug: v8:6702
Change-Id: I91235413eea478ba77ace7bd14bb2f62e155dd9a
Reviewed-on: https://chromium-review.googlesource.com/645949
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47768}
heap-inl.h exposes the whole world, which is fine from other inline
files but not from regular headers.
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I09ec67c6558682cb0d5181031bc39341a3f4c5bf
Reviewed-on: https://chromium-review.googlesource.com/643294
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47729}
This is a reland of 49e3bfd572
Original change's description:
> [snapshot] Move builtins to dedicated snapshot area
>
> As a first step towards lazy builtin deserialization, this CL moves
> builtins to their own dedicated area in the snapshot blob, physically
> located after startup data and before context-specific data.
>
> The startup- and partial serializers now serialize all seen builtins as
> references, i.e. they only encode the relevant builtin id (taking care
> to preserve special behavior around the interpreter trampoline and
> CompileLazy). Builtins are later fully serialized by the
> BuiltinSerializer. The separate blobs are finally glued together by
> CreateSnapshotBlob.
>
> Deserialization takes the same steps: when we see builtin reference
> bytecodes before builtins have been deserialized, we push to a list of
> deferred builtin references. After builtin deserialization, this list is
> iterated and all builtin references are fixed up.
>
> Bug: v8:6624
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: Idee42fa9c92bdbe8d5b8c4b8bf3ca9dd39634004
> Reviewed-on: https://chromium-review.googlesource.com/610225
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47596}
Bug: v8:6624
Change-Id: I8bfac56c482d992987c270bf0fea7acd9e4ca0c7
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/638271
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47705}
Daniel Bratell reports:
> v8 had a couple of files that were very slow to compile before jumbo
> and if those now end up in the same translation unit, then I can see
> how that translation unit can take an extreme time to get through
> the compiler.
>
> From one of my test builds (times in seconds):
> 49.7 v8_base/objects.o
> 44.0 v8_base/code-stub-assembler.o
> 32.9 v8_base/api.o
> 30.5 v8_base/elements.o
> 25.9 v8_builtins_generators/builtins-regexp-gen.o
> 22.8 v8_base/parser.o
> 21.2 v8_base/heap.o
>
> All of these are in the slowest 0.1% ninja jobs so they are extreme
> in some way. I think I would just exclude them all (or at least the
> 30s+ ones) completely from jumbo.
BUG=chromium:746958
Change-Id: I01741109def4f9ac7c946319374076eb7b9d03b6
Reviewed-on: https://chromium-review.googlesource.com/637971
Commit-Queue: Mostyn Bramley-Moore <mostynb@opera.com>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47703}
This reverts commit 49e3bfd572.
Reason for revert: Primary suspect for blocked roll: 759552
Original change's description:
> [snapshot] Move builtins to dedicated snapshot area
>
> As a first step towards lazy builtin deserialization, this CL moves
> builtins to their own dedicated area in the snapshot blob, physically
> located after startup data and before context-specific data.
>
> The startup- and partial serializers now serialize all seen builtins as
> references, i.e. they only encode the relevant builtin id (taking care
> to preserve special behavior around the interpreter trampoline and
> CompileLazy). Builtins are later fully serialized by the
> BuiltinSerializer. The separate blobs are finally glued together by
> CreateSnapshotBlob.
>
> Deserialization takes the same steps: when we see builtin reference
> bytecodes before builtins have been deserialized, we push to a list of
> deferred builtin references. After builtin deserialization, this list is
> iterated and all builtin references are fixed up.
>
> Bug: v8:6624
> Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
> Change-Id: Idee42fa9c92bdbe8d5b8c4b8bf3ca9dd39634004
> Reviewed-on: https://chromium-review.googlesource.com/610225
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Reviewed-by: Yang Guo <yangguo@chromium.org>
> Commit-Queue: Jakob Gruber <jgruber@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47596}
TBR=yangguo@chromium.org,mlippautz@chromium.org,jgruber@chromium.org
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: v8:6624
Change-Id: I9906c9ea15a623226b890f63bc65876a6f5203f8
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Reviewed-on: https://chromium-review.googlesource.com/638331
Reviewed-by: Michael Hablich <hablich@chromium.org>
Commit-Queue: Michael Hablich <hablich@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47648}
As a first step towards lazy builtin deserialization, this CL moves
builtins to their own dedicated area in the snapshot blob, physically
located after startup data and before context-specific data.
The startup- and partial serializers now serialize all seen builtins as
references, i.e. they only encode the relevant builtin id (taking care
to preserve special behavior around the interpreter trampoline and
CompileLazy). Builtins are later fully serialized by the
BuiltinSerializer. The separate blobs are finally glued together by
CreateSnapshotBlob.
Deserialization takes the same steps: when we see builtin reference
bytecodes before builtins have been deserialized, we push to a list of
deferred builtin references. After builtin deserialization, this list is
iterated and all builtin references are fixed up.
Bug: v8:6624
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: Idee42fa9c92bdbe8d5b8c4b8bf3ca9dd39634004
Reviewed-on: https://chromium-review.googlesource.com/610225
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47596}
The v8_enable_fast_mksnapshot gn flag reduces time spent in mksnapshot
on x64 debug builds from 19s to 6s by disabling far jump rewrites and
register allocation verification. This flag should only be used locally
for development.
Bug: v8:6688
Change-Id: I02e8546a6a329b9cb377b95ab586d5857a3c6731
Reviewed-on: https://chromium-review.googlesource.com/632258
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47573}
This reverts commit 8bbc224243.
Reason for revert: On Canary 3195.
Original change's description:
> [heap] Enable concurrent marking for x86 and x64.
>
> This is an experiment and will be reverted after getting canary
> coverage.
>
> Bug: chromium:694255
> Change-Id: I40388d8c6db0e46e2ce64e88aba04c5ac8822e94
> Reviewed-on: https://chromium-review.googlesource.com/625959
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47541}
TBR=ulan@chromium.org,mlippautz@chromium.org
Change-Id: I642c1f778267a795bf1e1a6bba863552394ad1d4
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:694255
Reviewed-on: https://chromium-review.googlesource.com/631717
Reviewed-by: Michael Hablich <hablich@chromium.org>
Commit-Queue: Michael Hablich <hablich@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47564}
This is an experiment and will be reverted after getting canary
coverage.
Bug: chromium:694255
Change-Id: I40388d8c6db0e46e2ce64e88aba04c5ac8822e94
Reviewed-on: https://chromium-review.googlesource.com/625959
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47541}
This moves Module and other module-related classes and definitions out
of src/objects{.h,-inl.h,.cc} into src/objects/module{.h,-inl.h,.cc}.
Also moves the contents of src/objects/module-info.h there.
R=marja@chromium.org
Bug: v8:1569, v8:5402
Change-Id: I49064bb4a5c5a6f409274c287e06e8dda351d615
Reviewed-on: https://chromium-review.googlesource.com/626818
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47540}
Deletes the now unused Full-codegen compiler. Also removes some macro
assembler instructions which are no longer used.
Note: there is still additional cleanup work to do after this lands
(e.g., remove support for FCG frames support and FCG
debugger support, etc.), but this will be done in followup CLs to keep
this patch managable.
BUG=v8:6409
Change-Id: I8d828fe7a64d29f2c1252d5fda968a630a2e9ef2
Reviewed-on: https://chromium-review.googlesource.com/584773
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47307}
Deletes AstGraphBuilder and associated classes now that it is
unreachable. The following classes are also removed:
- ControlBuilders
- JSFrameSpecialization
- AstLoopAssignmentAnalysis
Also removes flags from compilation-info which are no longer used, and removes
the no-deoptimization paths from TypedOptimization, JsTypedLowering,
JSIntrinsicLowering and JSBuiltinLowering.
BUG=v8:6409
Change-Id: I63986e8e3497bf63c4a27ea8ae827b8a633d4a26
Reviewed-on: https://chromium-review.googlesource.com/583652
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47284}
To speed up compilation times, jumbo allows files to be compiled
together. This is a well known method ("unity builds") to both
compile faster and create a poor man's "full program optimization".
We are only interested in compile times.
Background:
https://chromium.googlesource.com/chromium/src/+/master/docs/jumbo.md
Note that jumbo builds are not enabled by default. To try this out,
add use_jumbo_build=true to your GN args.
BUG=chromium:746958
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel
Change-Id: Ieb9fdccb6c135e9806dbed91c09a29aa8b8bee11
Reviewed-on: https://chromium-review.googlesource.com/579090
Commit-Queue: Mostyn Bramley-Moore <mostynb@opera.com>
Reviewed-by: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Marja Hölttä <marja@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47239}
This reverts commit 15ef03cbf3.
Reason for revert: Found the following bugs
Bug: chromium:752846, chromium:752712, chromium:752850
Original change's description:
> Reland "[builtins] Port getting property from Proxy to CSA"
>
> This reland is after fix in [heap] Delete wrong DCHECK.
> It includes moving ProxyGetProperty to its own stub to reduce
> binary size.
>
> This is a reland of 47a97aa53b
> Original change's description:
> > [builtins] Port getting property from Proxy to CSA
> >
> > Bug: v8:6559, v8:6557
> > Change-Id: If6c51f5483adb73ddd2495cede5d85e887a3c298
> > Reviewed-on: https://chromium-review.googlesource.com/589212
> > Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> > Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> > Commit-Queue: Maya Lekova <mslekova@google.com>
> > Cr-Commit-Position: refs/heads/master@{#47113}
>
> Bug: v8:6559, v8:6557
> Change-Id: I76acd97ba1acb62b7e7983db1741441d997050f0
> Reviewed-on: https://chromium-review.googlesource.com/600215
> Commit-Queue: Maya Lekova <mslekova@google.com>
> Reviewed-by: Jakob Gruber <jgruber@chromium.org>
> Reviewed-by: Franziska Hinkelmann <franzih@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47159}
TBR=jkummerow@chromium.org,mstarzinger@chromium.org,franzih@chromium.org,jgruber@chromium.org,ishell@chromium.org,bmeurer@chromium.org,mslekova@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Change-Id: I51bef25a031b02cf4deab11282473acae57f1ed3
Reviewed-on: https://chromium-review.googlesource.com/603708
Commit-Queue: Maya Lekova <mslekova@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47200}
This patch allows the concurrent marker to process more objects before
checking for the interrupt request from the main thread.
Bug: chromium:694255
TBR: mlippautz@chromium.org
Change-Id: I876d3156ca9843196f2fdddbd8bd28d1a3f472b1
Reviewed-on: https://chromium-review.googlesource.com/602131
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47182}
This reland is after fix in [heap] Delete wrong DCHECK.
It includes moving ProxyGetProperty to its own stub to reduce
binary size.
This is a reland of 47a97aa53b
Original change's description:
> [builtins] Port getting property from Proxy to CSA
>
> Bug: v8:6559, v8:6557
> Change-Id: If6c51f5483adb73ddd2495cede5d85e887a3c298
> Reviewed-on: https://chromium-review.googlesource.com/589212
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
> Commit-Queue: Maya Lekova <mslekova@google.com>
> Cr-Commit-Position: refs/heads/master@{#47113}
Bug: v8:6559, v8:6557
Change-Id: I76acd97ba1acb62b7e7983db1741441d997050f0
Reviewed-on: https://chromium-review.googlesource.com/600215
Commit-Queue: Maya Lekova <mslekova@google.com>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Franziska Hinkelmann <franzih@chromium.org>
Reviewed-by: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47159}
Bug: 749486
The feature is off by default, and could be turned on via
`v8_enable_csa_write_barrier = true`. With this CL, only x64 uses this
feature
Change-Id: Ie024f08b7d796a4cc4d55285dc9fe796780f0e53
Reviewed-on: https://chromium-review.googlesource.com/588891
Reviewed-by: Yang Guo <yangguo@chromium.org>
Reviewed-by: Tobias Tebbi <tebbi@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Albert Mingkun Yang <albertnetymk@google.com>
Cr-Commit-Position: refs/heads/master@{#47122}
The ScheduledErrorThrower is also needed in the wasm-async fuzzer so I
moved the implementation from wasm-js.cc to wasm-api.[h|cc].
R=clemensh@chromium.org
Bug: chromium:749838
Change-Id: I49d7438d1ec0281285ce0c64ba462c22001be08e
Reviewed-on: https://chromium-review.googlesource.com/591447
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47112}
This begins splitting up the Deserializer class into
{Object,Partial,Startup}Deserializer. For now, all functionality remains in
the Deserializer base clase, to be refactored in future CLs. Empty .cc files
are added here to avoid having to touch build files again.
Bug: v8:6624
Change-Id: If563e03492991bd55c91cd2e09312c0a26aaab2c
Reviewed-on: https://chromium-review.googlesource.com/598067
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47107}
This reverts commit d4a742fdf1.
Reason for revert: gc-stress failures
Original change's description:
> Reland "[heap] Add mechanism for tracking invalidated slots per memory chunk."
>
> This reverts commit c59b81d7b8.
>
> Original change's description:
> > [heap] Add mechanism for tracking invalidated slots per memory chunk.
>
> > For correct slots recording in concurrent marker, we need to resolve
> > the race that happens when
> > 1) the mutator is invalidating slots for double unboxing or string
> > conversions
> > 2) and the concurrent marker is recording these slots.
>
> > This patch adds a data-structure for tracking the invalidated objects.
> > Thus we can allow the concurrent marker to record slots without
> > worrying about clearing them. During old-to-old pointer updating phase
> > we re-check all slots that belong to the invalidated objects.
>
> BUG=chromium:694255
>
> Change-Id: Idf8927d162377a7bbdff34f81a87e52db27d6a9f
> Reviewed-on: https://chromium-review.googlesource.com/596868
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47068}
TBR=ulan@chromium.org,mlippautz@chromium.org
Change-Id: I81c6059a092cc5834acd799c51fd30dc0ecf5b27
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:694255
Reviewed-on: https://chromium-review.googlesource.com/597787
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47078}
This reverts commit c59b81d7b8.
Original change's description:
> [heap] Add mechanism for tracking invalidated slots per memory chunk.
> For correct slots recording in concurrent marker, we need to resolve
> the race that happens when
> 1) the mutator is invalidating slots for double unboxing or string
> conversions
> 2) and the concurrent marker is recording these slots.
> This patch adds a data-structure for tracking the invalidated objects.
> Thus we can allow the concurrent marker to record slots without
> worrying about clearing them. During old-to-old pointer updating phase
> we re-check all slots that belong to the invalidated objects.
BUG=chromium:694255
Change-Id: Idf8927d162377a7bbdff34f81a87e52db27d6a9f
Reviewed-on: https://chromium-review.googlesource.com/596868
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47068}
This reverts commit 7a5a777c97.
Reason for revert: crashing in test-api
Original change's description:
> [heap] Add mechanism for tracking invalidated slots per memory chunk.
>
> For correct slots recording in concurrent marker, we need to resolve
> the race that happens when
> 1) the mutator is invalidating slots for double unboxing or string
> conversions
> 2) and the concurrent marker is recording these slots.
>
> This patch adds a data-structure for tracking the invalidated objects.
> Thus we can allow the concurrent marker to record slots without
> worrying about clearing them. During old-to-old pointer updating phase
> we re-check all slots that belong to the invalidated objects.
>
> BUG=chromium:694255
>
> Change-Id: Ifc3d82918cd3b96e5a5fb7125691626a56f4ab83
> Reviewed-on: https://chromium-review.googlesource.com/591810
> Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
> Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#47049}
TBR=ulan@chromium.org,mlippautz@chromium.org
Change-Id: I7f4f8e8cb027b921a82e9c0a0623536af02581fb
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: chromium:694255
Reviewed-on: https://chromium-review.googlesource.com/595994
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47052}
For correct slots recording in concurrent marker, we need to resolve
the race that happens when
1) the mutator is invalidating slots for double unboxing or string
conversions
2) and the concurrent marker is recording these slots.
This patch adds a data-structure for tracking the invalidated objects.
Thus we can allow the concurrent marker to record slots without
worrying about clearing them. During old-to-old pointer updating phase
we re-check all slots that belong to the invalidated objects.
BUG=chromium:694255
Change-Id: Ifc3d82918cd3b96e5a5fb7125691626a56f4ab83
Reviewed-on: https://chromium-review.googlesource.com/591810
Reviewed-by: Michael Lippautz <mlippautz@chromium.org>
Commit-Queue: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47049}
Register configuration data is not the same as frame configuration data.
This CL moves the last remnants of register configuration into
the assembler files, to be with the other register configuration
macros.
Next step: extract this register configuration data into
platform-specific files that can be included independent of the
assembler.
R=mstarzinger@chromium.org
Bug:
Change-Id: I10933b5090be94e90e2a1442197528dfe30bb566
Reviewed-on: https://chromium-review.googlesource.com/595590
Commit-Queue: Ben Titzer <titzer@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47044}
Change-Id: Idb6dfed1d0314c38c25b230faa7e28728cff2637
Reviewed-on: https://chromium-review.googlesource.com/587250
Commit-Queue: Adam Klein <adamk@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#47019}
in preparation for caching StoreIC-Transition handlers in there.
This CL should not change behavior or performance.
The TransitionArray class no longer serves a dual purpose; it is now
simply the data structure serving that role. Further, it now supports
storing transitioning handlers in its "target" slot, which in turn have
a WeakCell pointing to the transition target (but this functionality
is not being used yet).
The interface for accessing a map's transitions, previously implemented
as a set of static functions, is now handled by the TransitionsAccessor
class. It distinguishes the following internal states:
- kPrototypeInfo: map is a prototype map, will never cache any transitions.
- kUninitialized: map can cache transitions, but doesn't have any.
- kWeakCell: map caches a single transition, stored inline. Formerly known
as "IsSimpleTransition".
- kFullTransitionArray: map uses a TransitionArray to store transitions.
- kTuple3Handler, kFixedArrayHandler: to be used in the future for caching
transitioning handlers.
Change-Id: If2aa68390981f96f317b958445a6e0b935c2a14e
Reviewed-on: https://chromium-review.googlesource.com/550118
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46981}
This CL moves us much closer to the point where we can remove debugger-script.js and usage of debugger context from inspector.
There are three main parts left:
- managing breakpoints,
- inspecting stack and scopes (this CL),
- LiveEdit.
In this CL I moved all stack/scope inspection to native. As side effect running debugger and inspector tests are 10-20% faster (it's significant since not all of tests requesting break).
R=yangguo@chromium.org,jgruber@chromium.org
Bug: chromium:652939
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I409396a687e18e9c0554c0c9c35b6e1064627be8
Reviewed-on: https://chromium-review.googlesource.com/580645
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46947}
Reland of https://chromium-review.googlesource.com/c/558290/
Makes compiler dispatcher jobs an abstract interface, with unoptimized
compile jobs as an implementation of this interface.
Bug: v8:6537
Change-Id: Ia85781f72c7aaca497896ca4efa91ada97e43b1c
Reviewed-on: https://chromium-review.googlesource.com/589154
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@{#46940}
Makes compiler dispatcher jobs an abstract interface, with unoptimized
compile jobs as an implementation of this interface.
Bug: v8:6537
Change-Id: I6569060a89c92d35e4bc7962623f77082a354934
Reviewed-on: https://chromium-review.googlesource.com/558290
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Commit-Queue: Leszek Swirski <leszeks@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46931}
This adds a missing swarming config to the ubsan builders to fix
test isolation.
This also adds ubsan_vptr to the inferred options from build metadata.
For ubsan_vptr builds, the test runner makes sure to set up the
required options.
TBR=ishell@chromium.org
Bug: chromium:726584
Change-Id: I9667ba2b6d9d0f363f7cc94d23308e09da002d99
Reviewed-on: https://chromium-review.googlesource.com/577689
Reviewed-by: Igor Sheludko <ishell@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46866}
Apparently the name float.h causes problems on Windows when V8 is
compiled with Visual Studio, see the bug description.
R=clemensh@chromium.org
Bug: v8:6588
Change-Id: Iaa9c1e93e62509a779f1a8ddecbb03a53981cf8a
Reviewed-on: https://chromium-review.googlesource.com/578029
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46791}
There remained a few of regressions and we didn't see any significant
improvement in the real world with this turned on. This CL reverts all the
StringConcat bytecode work which landed.
BUG=v8:6243
Change-Id: I832eb72e880ad41411dbec8fe29f71ef0f2025c8
Reviewed-on: https://chromium-review.googlesource.com/575130
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Reviewed-by: Leszek Swirski <leszeks@chromium.org>
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46769}
This allows to reuse the class e.g. in the baseline compiler.
R=titzer@chromium.org
Change-Id: I7251af16e8c74f267834a9cefb676edf3c9f3a07
Reviewed-on: https://chromium-review.googlesource.com/570020
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46735}
This was previously used by our js builtins but they no longer
exist. This has been exposed to API which means we can't remove it
just yet. Moving to CPP for now to save binary size.
Bug: v8:5343
Change-Id: I2a3e5a4169310b2ba13ce13f0386336e9733d71f
Reviewed-on: https://chromium-review.googlesource.com/575024
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Sathya Gunasekaran <gsathya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46721}
Follow up on https://codereview.chromium.org/2740353002. Created
PosixDefaultTimezoneCache which is a subclass of PosixTimezoneCache
containing definition of LocalTimezone and LocalTimeOffset which is
separate for different OS.
R=littledan@chromium.org, ulan@chromium.org
BUG=v8:6578
LOG=N
Change-Id: I58342893aeefe79ac50e1df041d614fc473f15bf
Reviewed-on: https://chromium-review.googlesource.com/568686
Reviewed-by: Daniel Ehrenberg <littledan@chromium.org>
Commit-Queue: Jaideep Bajwa <bjaideep@ca.ibm.com>
Cr-Commit-Position: refs/heads/master@{#46604}
This CL moves collected source range information out of AST nodes
and into a side table stored on ParseInfo. The side table is only
created if block coverage is enabled, so there's almost no memory
overhead in the standard case.
Change-Id: I41871b8425ebbc6217d82d3ad26b5fc9e5d68ecb
Reviewed-on: https://chromium-review.googlesource.com/566808
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46590}
- Implements the Promise.race algorithm using CodeStubAssembler.
- Delete src/js/promise.js, which is no longer needed.
- Migrate Promise constructor from slow to fast object in bootstrapper
(per v8:5902)
Increases size of snapshot_blob.bin on an x64.release build by 1.27kb.
BUG=v8:5343
R=gsathya@chromium.org, cbruni@chromium.org
Change-Id: I751e7389bd6ba410109640fcd7960b6021540f2f
Reviewed-on: https://chromium-review.googlesource.com/535041
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Reviewed-by: Camillo Bruni <cbruni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46489}
This CL changes for floats what https://chromium-review.googlesource.com/c/558964/
changed for doubles.
Original message:
On x86, signalling NaNs get converted to quiet NaNs when they get push
on the stack and popped again. This happens in the code generation for
arm, specifically for the vmov instruction with the immediate parameter.
This CL replaces the vmov function in assembler-arm to take the
immediate as a uint64_t instead of a double, to guarantee that the bit
pattern does not change even if the parameter is a signalling NaN.
New in this CL:
Although src/double.h existed already, src/float.h did not exist yet.
I created the file in this CL, and moved the classes Float32 and
Float64 there, which already existed in src/deoptimizer.h.
R=titzer@chromium.org, martyn.capewell@arm.com, v8-arm-ports@googlegroups.com
BUG=v8:6564
Change-Id: I6a3f1f154af9c8cd4bb8e7e856235d3eee5e9edd
Reviewed-on: https://chromium-review.googlesource.com/561009
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Martyn Capewell <martyn.capewell@arm.com>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46473}
Adds a CheckElimination reducer to eliminate checks which have become
unecessary due to inlining of heap constants.
BUG=v8:6243, chromium:738312
Change-Id: Ie50b274bd07c86466eead08b2f21d2b63dd9e01c
Reviewed-on: https://chromium-review.googlesource.com/559129
Commit-Queue: Ross McIlroy <rmcilroy@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46460}
This is the first step in optimizing Map and Set iterators. This ports
all the base functionality including
- Set.prototype.entries
- Set.prototype.values
- %SetPrototypeIterator%.next
- Map.prototype.entries
- Map.prototype.keys
- Map.prototype.values
- %MapPrototypeIterator%.next
to C++ and removes all the dead code and the previous half JavaScript
implementation. The next step is to port core parts to CodeStubAssembler
and finally inline the fast-paths into TurboFan directly. The relevant
design document is at:
https://docs.google.com/document/d/13z1fvRVpe_oEroplXEEX0a3WK94fhXorHjcOMsDmR-8
Most of this work is very similar to how the Array iterator works and we
mostly follow the same process for the implementation.
R=jgruber@chromium.org
Bug: v8:6571
Change-Id: Ieb253d6705ba4077c697a5ff0cb6f87f9c4056ff
Reviewed-on: https://chromium-review.googlesource.com/561138
Reviewed-by: Jakob Gruber <jgruber@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46441}
This drops v8_hello_world, v8_parser_shell and v8_sample_process from the
official v8 archives.
This also adds a new option to differentiate library and executable
archives.
NOTRY=true
TBR=marja@chromium.org
Bug: v8:5918
Change-Id: I946708f2eeb030296c5ce284541ecf719522186c
Reviewed-on: https://chromium-review.googlesource.com/554753
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#46312}