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}
Since we have only unittests that are under GoogleTestSuite there
is no need to keep it as a default suite and we can make it
specific for unittests.
Bug: v8:6917
Change-Id: Ie2d57342773f228dea72184ab0f2abfc9d2daa70
Reviewed-on: https://chromium-review.googlesource.com/819253
Commit-Queue: Michał Majewski <majeski@google.com>
Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org>
Reviewed-by: Michael Achenbach <machenbach@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50011}
Includes drive-by fix of a small BigInt bug, as caught by
test262/built-ins/BigInt/constructor-from-string-syntax-errors
Cq-Include-Trybots: master.tryserver.v8:v8_linux_noi18n_rel_ng
Change-Id: Ic3b78310912f84bbf904a1fcb7ddf2d7eb2df013
Reviewed-on: https://chromium-review.googlesource.com/817775
Reviewed-by: Sathya Gunasekaran (ooo until 12/12) <gsathya@chromium.org>
Reviewed-by: Georg Neis <neis@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Commit-Queue: Daniel Ehrenberg <littledan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50010}
This reverts commit 1e49864fa7.
Reason for revert: Crashing test on the waterfall https://logs.chromium.org/v/?s=chromium%2Fbb%2Fclient.v8%2FV8_Linux_gcc_4.8%2F16871%2F%2B%2Frecipes%2Fsteps%2FCheck%2F0%2Flogs%2FReturnMultipleRandom%2F0
Original change's description:
> [turbofan] Implement on-stack returns (Intel)
>
> Add the ability to return (multiple) return values on the stack:
>
> - Extend stack frames with a new buffer region for return slots.
> This region is located at the end of a caller's frame such that
> its slots can be indexed as caller frame slots in a callee
> (located beyond its parameters) and assigned return values.
> - Adjust stack frame constructon and deconstruction accordingly.
> - Extend linkage computation to support register plus stack returns.
> - Reserve return slots in caller frame when respective calls occur.
> - Introduce and generate architecture instructions ('peek') for
> reading back results from return slots in the caller.
> - Aggressive tests.
> - Some minor clean-up.
>
> So far, only ia32 and x64 are implemented.
>
> Change-Id: I9532ad13aa307c1dec40548c5b84600fe2f762ce
> Reviewed-on: https://chromium-review.googlesource.com/766371
> Commit-Queue: Andreas Haas <ahaas@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49994}
TBR=titzer@chromium.org,rossberg@chromium.org,ahaas@chromium.org
Change-Id: Ib257e92448942f8ef07d5ef246f9381f4784f014
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/819637
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#50000}
Add the ability to return (multiple) return values on the stack:
- Extend stack frames with a new buffer region for return slots.
This region is located at the end of a caller's frame such that
its slots can be indexed as caller frame slots in a callee
(located beyond its parameters) and assigned return values.
- Adjust stack frame constructon and deconstruction accordingly.
- Extend linkage computation to support register plus stack returns.
- Reserve return slots in caller frame when respective calls occur.
- Introduce and generate architecture instructions ('peek') for
reading back results from return slots in the caller.
- Aggressive tests.
- Some minor clean-up.
So far, only ia32 and x64 are implemented.
Change-Id: I9532ad13aa307c1dec40548c5b84600fe2f762ce
Reviewed-on: https://chromium-review.googlesource.com/766371
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49994}
Moving a register to itself is not only unnecessary overhead, it also
breaks invariants in the StackTransferRecipe.
R=ahaas@chromium.org
Bug: v8:6600, chromium:793551
Change-Id: I659fd66b4f2d4564c437ed9fb048322af4299d97
Reviewed-on: https://chromium-review.googlesource.com/819231
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49992}
This relands commit e71b802279.
This can now back in as the fix for chromium:787301 had enough time to
be tested in Canary.
Original change's description:
> [deoptimizer] Staged materialization of objects.
>
> The existing object materialization in the deoptimizer has the following problems:
>
> - Objects do not necessarily verify during materialization (because during the
> depth first walk we might have inconsistent objects).
>
> - Stack can overflow (because we just materialize using recursive calls).
>
> - We generalize object fields.
>
>
> This CL re-implements the materialization algorithm to solve this problem. The
> new implementation creates the objects in two steps:
>
> 1. We allocate space for all the objects. In general, we allocate ByteArrays
> of the right size. For leaf objects that cannot participate in cycles,
> we build and initialize the materialized objects completely.
>
> For JS objects, we insert markers into the byte array at the positions
> where unboxed doubles are expected.
>
> 2. We initialize all the objects with the proper field values and change the
> map from the ByteArray map to the correct map. This requires some sync
> with the concurrent marker (Heap::NotifyObjectLayoutChange).
>
> When initializing the JS object fields, we make sure that we respect
> the unboxed double marker.
>
> Bug: chromium:770106, v8:3836
> Change-Id: I1ec466a9d19db9538df4ba915516d4c3ca825632
> Reviewed-on: https://chromium-review.googlesource.com/777559
> Commit-Queue: Jaroslav Sevcik <jarin@chromium.org>
> Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
> Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49821}
Bug: chromium:770106, v8:3836
Change-Id: Ied6c4e0fbae52713e55ae6dc13794a7521dbb8a5
Reviewed-on: https://chromium-review.googlesource.com/817745
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Commit-Queue: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49982}
await expressions are an invalid destructuring target, and should
result in a SyntaxError when used in a position where a destructuring
target is expected.
BUG=v8:7173
R=marja@chromium.org, adamk@chromium.org
Change-Id: I1bdb4bc13cb2e3e904fc4389a6e0abca1e0ed17f
Reviewed-on: https://chromium-review.googlesource.com/811946
Reviewed-by: Sathya Gunasekaran (ooo until 12/12) <gsathya@chromium.org>
Commit-Queue: Caitlin Potter <caitp@igalia.com>
Cr-Commit-Position: refs/heads/master@{#49977}
I also adjusted the update script because the output directory of the
run.py script we call has changed.
R=clemensh#chromium.org
Change-Id: I432c81f1a2ffd3c96a294f771064672f7edad250
Reviewed-on: https://chromium-review.googlesource.com/817275
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Commit-Queue: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49968}
This patch adds a field for the speculation mode to Call
nodes, and passes the speculation mode from the CallIC
to the Call node in the byte code graph builder.
Bug: v8:7127
Change-Id: I89fa10643b46143b36776de1d5ba6ebe3fa2c878
Reviewed-on: https://chromium-review.googlesource.com/814537
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49965}
This moves the verify-predictable logic from the test runner into
a python wrapper script.
This revealed two more tests that don't print allocations, which are
now skipped.
Bug: v8:7166, v8:7177
Change-Id: Ie4a541cb2a20900414ffe1caf4b3fccc4a5edb52
Reviewed-on: https://chromium-review.googlesource.com/808971
Commit-Queue: Michael Achenbach <machenbach@chromium.org>
Reviewed-by: Sergiy Byelozyorov <sergiyb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49964}
This CL uses bits of the call count as flags according
to CallCountField and SpeculationModeField defined in
CallICNexus.
Bug: v8:7127
Change-Id: I3f64c1807d61410f9029b46b9a59a1fcaa5a0a3b
Reviewed-on: https://chromium-review.googlesource.com/808926
Commit-Queue: Sigurd Schneider <sigurds@chromium.org>
Reviewed-by: Benedikt Meurer <bmeurer@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49959}
Bug: chromium:780819
Change-Id: I07c5ff3cf955edb087a175ea2d71a35e0f520ec3
Reviewed-on: https://chromium-review.googlesource.com/813839
Commit-Queue: Georg Neis <neis@chromium.org>
Reviewed-by: Adam Klein <adamk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49953}
- in certain cases, we need both modification scopes because we may
mutate JS functions, even in the jit-to-native case - e.g. JS-to-wasm
wrappers
- added handling for wasm-to-wasm wrappers in the context of lazy
compilation.
Bug: v8:7105
Change-Id: I085c14e03ef0b08d040998f2207abf7bc3fff01c
Reviewed-on: https://chromium-review.googlesource.com/811285
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49947}
This reverts commit 59f221740c.
Reason for revert: android build issue (https://build.chromium.org/p/client.v8.fyi/builders/Android%20Release%20%28Nexus%205X%29/builds/3583)
Original change's description:
> [wasm] Fix wasm-to-wasm handling in 'native heap' lazy compile
>
> Wasm-to-wasm uses a tail call mechanism to reach the target
> function. This means there is no frame for it. This CL ports
> the fix for that for the WasmCodeManager case, akin the current
> fix for the GC case.
>
> Bug: v8:7140
> Change-Id: I04c8a8da1de9cb837a0423493216d2226c53e756
> Reviewed-on: https://chromium-review.googlesource.com/814498
> Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
> Reviewed-by: Ben Titzer <titzer@chromium.org>
> Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#49942}
TBR=bradnelson@chromium.org,titzer@chromium.org,mtrofin@chromium.org,clemensh@chromium.org
Change-Id: Iae0e43b386f08d2d56aeef70e9fa0af141232023
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: v8:7140
Reviewed-on: https://chromium-review.googlesource.com/815180
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49943}
Wasm-to-wasm uses a tail call mechanism to reach the target
function. This means there is no frame for it. This CL ports
the fix for that for the WasmCodeManager case, akin the current
fix for the GC case.
Bug: v8:7140
Change-Id: I04c8a8da1de9cb837a0423493216d2226c53e756
Reviewed-on: https://chromium-review.googlesource.com/814498
Reviewed-by: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Mircea Trofin <mtrofin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49942}
The tests illustrate the use of v8::EmbedderHeapTracer.
Bug: v8:7176
Change-Id: Ic383c968691fddb0ec96d66cb33ee42b9c304a75
Reviewed-on: https://chromium-review.googlesource.com/811924
Commit-Queue: Michael Lippautz <mlippautz@chromium.org>
Reviewed-by: Ulan Degenbaev <ulan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49934}
When enabling any coverage mode (other than best-effort), we trigger
deoptimization of all functions on the heap.
Prior to the recent removal of the weak list of optimized functions [0],
we'd unlink optimized code from all relevant JSFunctions during the call
to DeoptimizeAll.
After the weak-list-removal, this was no longer the case, hence this [1]
change which attempts to reset the code object from the
SharedFunctionInfo for all found JSFunction objects.
But this can create a situation in which JSFunctions are set up
incorrectly s.t. they have unoptimized code but no feedback vector.
This CL fixes that by leaving JSFunction objects untouched and relying
on self-healing mechanisms (CompileLazyDeoptimizedCode) to fix up
JSFunction::code.
[0] https://crrev.com/f0acede9bb05155c25ee87e81b4b587e8a76f690
[1] https://crrev.com/c/647596/5/src/debug/debug-coverage.cc
Bug: chromium:786784, chromium:791940, v8:6637
Change-Id: I13191f4c8800a0d72894b959105189dc09ca693e
Reviewed-on: https://chromium-review.googlesource.com/813615
Commit-Queue: Jakob Gruber <jgruber@chromium.org>
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49932}
Ensure that the type is always stored correctly.
R=titzer@chromium.org
Bug: v8:6600, chromium:791810
Change-Id: Id3a3c20b14f8730b9550c548dec49ac47121e691
Reviewed-on: https://chromium-review.googlesource.com/811188
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49924}
The previous code assumed that trap handling was a global concept, defined
by function trap_handler::UseTrapHandler(). This CL does the first step
in changing the decision to be specifiable at a module level.
Therefore trap_handler::UseTrapHandler() is replaced by
trap_handler::IsTrapHandlerEnabled(), and communicates if compilation
supports the use of trap handlers (but still allowing the use of
bounds checking on memory accesses).
It then refactors the classes ModuleEnv and WasmCompiledModule to have
a field "use_trap_handler" that specifies if traps should be used for
the memory accesses in the module being compiled.
Bug: v8:7143
Change-Id: I9844842d5721c86c2dd55e911b42bf8b9922cf63
Reviewed-on: https://chromium-review.googlesource.com/802322
Commit-Queue: Eric Holk <eholk@chromium.org>
Reviewed-by: Ben Titzer <titzer@chromium.org>
Reviewed-by: Mircea Trofin <mtrofin@chromium.org>
Reviewed-by: Eric Holk <eholk@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49915}
Performed manual testing as well by making 20 CPU profile recordings of
loading http://meduza.io page. Without the patch the page renderer memory size
grows beyond 300MB. With the patch it remains below 200MB.
BUG=v8:6623
Change-Id: Ifce541b84bb2aaaa5175520f8dd49dbc0cb5dd20
Reviewed-on: https://chromium-review.googlesource.com/798020
Commit-Queue: Alexei Filippov <alph@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49914}
It will help us to preserve some scripts for user.
R=alph@chromium.orgTBR=jgruber@chromium.org
Bug: chromium:655701
Cq-Include-Trybots: master.tryserver.chromium.linux:linux_chromium_rel_ng
Change-Id: I6d42434148c2d9eb41c3a2af906e8c14ccf8d9a9
Reviewed-on: https://chromium-review.googlesource.com/806741
Commit-Queue: Aleksey Kozyatinskiy <kozyatinskiy@chromium.org>
Reviewed-by: Alexei Filippov <alph@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49913}
Exposing the existing Context::AllowCodeGenerationFromStrings(false) API
to the command line.
Bug: v8:7134
Change-Id: I062ccff0b03c5bcf6878c41c455c0ded37a1d743
Reviewed-on: https://chromium-review.googlesource.com/809631
Reviewed-by: Michael Starzinger <mstarzinger@chromium.org>
Commit-Queue: Jakob Kummerow <jkummerow@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49911}
This saves us 14.2kB binary size in libv8.so (in release mode), and
probably also improves performance a little bit.
R=titzer@chromium.org
Bug: v8:7109
Change-Id: I345a48369aaf054572a4fd4368bf5cd526ed146a
Reviewed-on: https://chromium-review.googlesource.com/797270
Reviewed-by: Ben Titzer <titzer@chromium.org>
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49905}
- When a global object changes, invalidate its validity cell.
- The global object prototypes don't need to be gathered into an array in InitPrototypeChecks.
Bug: v8:7159
Change-Id: I3621c914d08b83e49e8a391800a92eb53ba19feb
Reviewed-on: https://chromium-review.googlesource.com/808588
Reviewed-by: Toon Verwaest <verwaest@chromium.org>
Commit-Queue: Igor Sheludko <ishell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49901}
When implementing Liftoff I realized that these are not tested at all
in our cctests.
R=ahaas@chromium.org
Bug: v8:6600
Change-Id: I9f4da9bb93580f556bc67ebe8b79427373e656ba
Reviewed-on: https://chromium-review.googlesource.com/808385
Commit-Queue: Clemens Hammacher <clemensh@chromium.org>
Reviewed-by: Andreas Haas <ahaas@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49894}
We cannot remove a speculative operation when it's type relies on it to deopt.
Fix this by only relying on the lowering to remove operations.
Bug: chromium:786521
Change-Id: I2cf45e8d45b76cfeb06e6329f323cade74719124
Reviewed-on: https://chromium-review.googlesource.com/793043
Reviewed-by: Jaroslav Sevcik <jarin@chromium.org>
Commit-Queue: Tobias Tebbi <tebbi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#49882}
